首先，讲解下Sprint开发过程的一些原则：

• 每日站会 - 面对面的交流，省去协调“日程安排”需要的时间
• 全员参加 - 每个人都清楚工作目标(我们一起计划的)，并一起工作
• 团队负责 - 同一个Story往往需要多个团队成员(UX/Service/Data etc.)
• 限制WIP（Work In Progress）数量 - 用集中的时间实现更快、可预测的开发

当仔细思考这些原则的时候，将会看到Agile宣言渗透其中。接下来详细讲解每一原则。

每日站会

• 两种形式的每日站会：
  • 标准Scrum站会 - 每个团队成员报告他们做了什么，接下来计划做什么，以及遇到的任何障碍。同时，据此更新Burndown Chart。
  • 前瞻性站会 - 会议组织者询问正在进行的工作内容，团队自由选择后续要完成内容

全员参与

• the Whole team is available to work on closing User Stories
  • PO 提供所开发的feature需要的输入信息，并可用于确认该Story完成
  • Scrum Master组织会议和工作研讨会，并通过优秀的Story和Story的关闭细则等确保任务的质量
  • 研发团队精诚合作完成任务，这意味着团队内部要相互帮助，作为一个整体对工作负责
• 持续进行规划/计划
  • 当产品成形时，PO与Stakeholder咨询协商以收集反馈
  • Scrum Master 确保反馈信息是有促进价值并且有效
  • Scrum Master的工作还包括必要时使stakeholder加入，或者在规模化敏捷的时候，使其他团队共同加入。
  • PO 编写Stories，这些Story同时将由ScrumMaster审查

团队负责

• 团队知道需要完成哪些工作，每个成员根据工作需要提供支持。
• 有时这意味着三个团队成员处理一个Story
  • UX -- 根据从stakeholder那里收集来的UI方面的需求，构建UI
  • Service -- 基于中间件以及后端（数据管理）实现Service技术方案。
  • Test -- 基于验收标准设计和构建测试/自动化测试
  • Scrum Master 可能需要组织同stakeholder的会议，促使快速生成UI原型
  • Product Owner 验证最终产品
• 如果用户故事出现滞后，那么可以通过结对编程或建立“作战室”来解决此问题
  • 团队成员清晰这项工作，可以加入进来提供帮助
  • 避免因某个人解决问题，而产生个人英雄主义
  • 团队要降低无法交付关键功能的风险
• “团队负责”确保最好优先级任务的进度，同时这些高优先级任务将给stakeholder带来最大的价值

限制WIP数量

• 限制WIP数量可以使所有过程进展得更快
  • 意味着团队成员可以在有需要的时候，及时提供支持
  • 意味着需要更少的会议和协调活动
  • 意味着更清晰、更小的任务，以便快速完成和回顾
  • 意味着更多的时间花在完成工作上，更少的时间组织许多活动上
• 减少WIP的主要方法和工具有Kanban 或者 "Scrumban" board
  • Kanban board - 将Story作为工作项管理，沿着价值流不停改变其状态，向前稳步推进
    • Stories一般有5个 (Planned, Ready, In-Development, Testing, Done)
    • 每个状态允许的故事数量是有限制的，例如一次测试中只有两个故事
    • 限制每个状态的WIP确保了必须先完成当前的工作，才可以进行新的工作
  • Scrumban Board - 将task作为工作项，沿着价值流不停改变task的状态，然后Story的状态，向前稳步推进
    • 同Kanban一样，通常有 (Planned, Ready, In-Development, Testing, Done)
    • Stories 只有在其包含的所有tasks状态向前推进的时候改变
      • 将一Story移动至"In-Development"状态，仅当其所有tasks 在此状态或者更往前一状态（比如“Testing"）时
      • Stories 和 tasks 在不同的行中进行管理
    • Scrumban 可能还会为高优先级任务添加一“快速通道”

请注意，这些技术中有许多是从精益方法中借来的，特别是WIP的看板。这是因为一旦故事计划好了，团队就应该像一台运转良好的机器一样运转。因此，持续改进和减少浪费的目标在此也绝对适用。

然而，Scrum与众不同且保持敏捷的一个关键方面是，产品负责人在团队中，他们可以增量地接受工作。另外，Sprint Backlog对所有人完全透明地显示了团队在Sprint结束前必须完成的工作，开发团队可以根据Sprint的需求来管理他们的时间。这些故事结合在一起形成了一个有意义的、可交付的产品增量。

正是基于这些原因，敏捷为开发团队提供了可持续性、目的性、掌控性和自主性，而不是纯粹的精益方法。这些要素已被证明是最能激励知识型员工团队的。