Scrum介绍系列4--- Sprint 计划会议

Sprint 计划会议是保证整个Scrum顺利进行的重要一环之一！如何开好，非常关键！

Sprint 计划会议在每一Sprint 的启始阶段进行。在Sprint 计划会议的第一部分，产品所有者和Scrum 开发团队（在ScrumMaster 的协助下）共同评审Product Backlog，讨论Backlog 中各项目的目标和背景，并提供Scrum 开发团队深入了解产品所有者想法的机会。在会议的第二部分，Scrum 开发团队从Product Backlog 中挑选项目并承诺在Sprint 的末期完成任务，从ProductBacklog 的顶端开始（换而言之，从对产品所有者具有最高优先权的项目开始）并按列表顺序依次工作。这是Scrum 的重要实践之一：开发团队决定承诺完成工作量的多少，而不是由产品所有者安排工作量。这就使任务的交付更可靠；第一，因为开发团队承诺工作量，而不是其他人代替其“承诺”工作量；第二，开发团队自己决定所需要的工作量，而不是其他人决定工作量“应该”是多少。产品的所有者对于开发团队承诺任务多少没有控制权，他或她只知道开发团队负责的项目是由Product Backlog 中按顺序从上至下进行的——换而言之，是从他或她选择的最重要的项目开始。开发团队可以从列表底层选择项目提前完成，如果其对于整个开发具有意义（比如，提升和快速完成较低优先权的项目，作为完成较高优先权项目的一部分）。


Sprint 计划会议通常会持续几个小时——开发团队对于承诺完成的任务作出认真地抉择，这些责任要求通过仔细地考虑以达到成功的目标。团队将从估算每一成员拥有的完 成Sprint 相关工作的时间开始——换句话说，是团队成员平均的工作时间减去他们花费在检修bug 和其他必要的维护工作，参加各种会议，回复电子邮件，午休等的时间。大多数人会有4 到6 个小时每个工作日可以完成Sprint 相关的工作。（图示3）

当可利用时间确定下来，开发团队会从Product Backlog 的顶端第一项开始工作——换句话说，从产品所有者的最高优先权项开始——团队共同工作，将其分配为小块任务，并记录在SprintBacklog 中（图示4）。当任务确定后，团队成员可以自愿承担任务，在考虑任务间依赖关系和次序的情况下，给每一项任务估算时间，并保证每一个人的工作量合理。在此流程中将会和产品所有者有往复交流，阐明要点，核实交易，将较大型Backlog 分割成小块，并保证开发团队真正全面了解开发的需求。开发团队将按Product Backlog 序列继续计划，直至消耗所有可利用时间。在会议的末期，开发团队将提供所有任务的列表，并写明每一项工作由谁完成和他们的估算时间（一般以小时计算或每天的一小部分）。许多开发团队也使用可视任务跟踪工具，利用墙体面积大小的任务板，任务（写在便签上）在Sprint 中跨越栏目，“未开始”，“在进行”，“需校验”，和“已完成”。



Scrum 的重要支柱之一是当Scrum 开发团队确认承诺任务后，产品所有者在此Sprint 期间不可以添加新的需求。这就意味着即使在Sprint 中途，产品所有者想要添加新要求，他或她在下一新的Sprint 开始前不可能作出任何变更的决定。如果一个外部情况出现致使项目优先级的变化，意味着如果开发团队按原计划工作将会是浪费时间，产品所有者此时可以结束该Sprint；意味着开发团队停止一切工作，重新开始Sprint 计划会议等等。此种决断会产生很大的影响,除非在非常特别情况下，不会采用这种方式。

保证开发团队在Sprint 中目标不被变换有着正面影响。首先，开发团队确信在工作开始时的承诺是不会变化，这样会集中开发团队的注意力。第二，这样也可以培养产品所有者在安排Product Backlog 中项目的优先权时，适时作出正确的抉择。他们知道任务的承诺是在整个Sprint 中不可变更的，使其在决定从哪一项目开始工作更为细心。

作为回报，产品所有者也可以得到两个好处。首先，他或她有充分的信心，开发团队对所承诺任务强烈负责，并随着时间推移，Scrum 开发团队将会做的很好。第二，产品所有者可以在下一Sprint 开始前，提出他或她希望的变动。在这一点上，增加条件，删减条件，更改条件和重新排列优先权都可以被接受。但产品所有者不可以在Sprint 进行中提出任何变更，他或她只是需要等待一个Sprint 的完成时间或更短。不再僵持于是否变化——方向的变更，条件的变更，或只是简单的想法的变更——可能正式此原因，使得产品所有者成为Scrum 拥护者中最热衷的成员。