第9部分(第1/4 页)

阿捷：这个问题的意义在哪里呢？

敏捷圣贤：首先，Product　Owner可以根据它来构建发布规划；同时团队可以根据它来真正改进流程。只有知道自己的速度如何，这有助于一个团队进行更好的估算，同时帮助他们在继续后续工作时提升速度。

阿捷：嗯，这已经有三个规则了，最后一个是什么？

敏捷圣贤：Scrum团队依赖自组织的过程，这就意味着团队负责挑选工作、职责分配，并要找出最快交付工作的途径。所以，Nokia的最后一条规则是：在迭代中，项目经理不能干涉团队工作，因为这会停止自组织的过程，并且得到解决方案的过程将不再是最优化的了。

阿捷再次想起了Product　Owner的问题，赶紧问：为什么非得要专门的Product　Owner？我代替不可以吗？

敏捷圣贤：首先，产品Backlog是Scrum的核心，从根本上说，它是一个需求或故事或特性组成的列表，并且按照重要性进行了排序，一定是客户想要的东西，并且用客户的语言进行描述。产品的Backlog应该仅仅由那些产品相关的较大的任务（ticket）组成，有关在产品开发中完成某项工作时候涉及的东西，太细了就不适合。

敏捷圣贤：其次，在维护产品Backlog的时候，Product　Owner（就是那个能替最终客户发言的人）必须参加，由他排列优先级。Product　Owner必须是离客户最近的人，你作为研发项目管理人员，不可能是离客户最近的人。如果没有这个角色，你们怎么知道哪个重要哪个不重要？和Product所有人交流，你们才可以做出来一个有优先顺序的列表，把最重要的功能放在列表的前面。

阿捷：我知道了，看来我得找Product　Manager来担任这个角色才行。那这个Backlog条目除了优先级外，还有其他什么要求？

敏捷圣贤：嗯，每一个条目应该有估计完成时间，这个并不需要很准确。我们只需要有一个大概的估算即可，这样才能够决定把多少工作放到一个Sprint里。

敏捷圣贤：另外，在你开sprint规划会议之前，你的产品Backlog应该保持一种合适的格式。你可以是把它们都放在一个Excel中，也可以是一个Word文档，或者是某种Scrum工具中……采用哪种形式都可以，只要你们自己觉得方便就行。

阿捷：嗯，我用了Excel。

敏捷圣贤：Sprint计划会议除了你的团队成员和Product　Owner外，还可以邀请更多的人参加。

阿捷：我还以为我一个人规划Sprint就可以了呢。

敏捷圣贤：那是旧的管理模式。在Scrum框架下，没有“个人”的概念，Scrum依靠的是团队的力量。尽管Scrum　Master在这个框架下的作用很重要，但这个人不是*者。做Sprint计划时，一定要让整个团队参加。

第5章　成长的烦恼（5）

阿捷：那具体怎么做呢？大家一起做计划，岂不是很乱？

敏捷圣贤：首先，你们要先定下来Sprint的目标，即作为一个团队，你们要完成什么，然后再决定完成多少。

阿捷：我们当前没有任何历史参考数据，怎么知道完成多少呢？

敏捷圣贤：事先计算出在一个Sprint内，团队的可能工作时间。譬如，在未来三周内，一个5人小组，每人每周工作40小时，那么总的工作时间=5×40×3=600小时。

阿捷：理想情况是这样的，但肯定会有人休假的。

敏捷圣贤：对，所以你要将总的工作时间扣除任何预期的非工作时间。譬如，有一个人要休一个礼拜的年假，还有人要看牙，需要占用3天，这样算起来是600…5x8…3x8=536小时。

阿捷：还有，即使每人每天工作8小时，但也不是会真的有8小时工作在项目上，还要参加各种Tea　Talk、培训、Team　Building等活动。

敏捷圣贤：如果每天8小时，你们大概会有几小时工作在项目上？

阿捷：平均差不多6小时吧。

敏捷圣贤：你得把每天花在参加会议、谈话、处理邮件、上网等时间都除去。

阿捷：那估计5小时。

敏捷圣贤：我们把它用百分比