友情提示：如果本网页打开太慢或显示不完整，请尝试鼠标右键“刷新”本网页！
敏捷无敌-第9部分
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！
阿捷：这个问题的意义在哪里呢？
敏捷圣贤：首先，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小时。
敏捷圣贤：我们把它用百分比表示，5/8，那么就是60％左右，然后用这个“负荷指标”（Load Factor）乘以总的工作时间小时数，你就得到了536×小时。
阿捷：嗯，这种估算很实际。
敏捷圣贤：然后从产品Backlog中，按照优先级从高到低，选择出你们认为能在322小时内完成的条目，作为你们当前Sprint的Backlog。注意：选择的Sprint Backlog Item一定要强内聚、松耦合，这样你们才能不受或者少受外界的干扰，目标明确。
阿捷：那个“负荷指标” 60％应该是变动吧？我们刚做一个项目，跟项目做了一段时间相比，肯定是不一样的。再譬如我有新员工加入时，他的效率肯定是要比老员工低的。
敏捷圣贤：对。你已经很好地理解了负荷指标，你可以利用它把Sprint计划得很准确。当你遇到低的“负荷指标”时，要试着找出根本原因，这会使你门的Sprint更有效率。
阿捷：下一步是不是该做任务细化？进行估算？
敏捷圣贤：不完全对，任务细化之外，还有一个非常重要的部分：对于每个细化后的任务，都需要一个非常明确“完成”（Done）的定义。这一点非常重要，必须保证每一个人的理解是正确的、一致的。
阿捷：嗯，否则每个人的估算就会千差万别。
敏捷圣贤：对！估算时，可以用“计划扑克牌”来估算完成时间。你知道怎么用计划扑克牌吗？
阿捷：不知道，我想我可以去查一下。
敏捷圣贤：嗯，你们应该尝试一下这个东西。
阿捷：还有什么值得注意的？
敏捷圣贤：做Sprint任务细化时，一个最佳实践就是把每个任务控制在2～16 小时之间。任务太细，会涉及更多的微观管理，太粗，估算就会不准确。
阿捷：OK！在这一点上，Scrum跟其他项目规划方法是一样的。
敏捷圣贤：下一步，就是让大家自己认领任务，而不是指派！这一点非常关键，一定要记住啊？
阿捷：为什么要认领？指派会更有效率，而且还能根据每个人的特长，让每个人做他擅长的事情。
敏捷圣贤：首先，每个人认领任务后，实际上就是对整个团队有了一个承诺，更能保证按计划完成。其次，让每个人选择自己愿意做的事情，这样才会更有主动性，毕竟“做自己有兴趣的事情，才会真的做好”。这样，不仅满足了个人发展的需要，还可以达到快速的知识共享、团队技能的整体提高。书包 网 。 想看书来
第5章 成长的烦恼（6）
阿捷：不错，以前是只对项目经理一个人承诺，这样认领后，就成了对所有人的承诺。
敏捷圣贤：此外，跟任何其他会议一样，对于跨度一天的计划会议，确定好会议日程非常重要。因为Sprint计划会议一定要基于Time…Boxed，在规定的时间内，一定要结束，就像一个Sprint一样，同样要有紧迫感。
阿捷：嗯，我会仔细计划的。
敏捷圣贤：还有，Sprint计划会议必须在一个完整天内开完。
阿捷：为什么？
敏捷圣贤：Sprint计划会议开始的那一天，也就是Sprint开始的一天。如果Sprint计划会议要跨越两天，可不是什么好玩儿的事情，你的Burndown Chart就会像我们的这样很难看。你会看到Sprint才一开始，似乎我们的工作量只有150，怎么第二天时工作量就快到了190，出现了一个凸起。如果不了解内情的话，一定还以为Sprint出了问题呢。而实际上是因为我们曾经在前一天的下午开了4小时，第二天上午又开了3小时，对任务进行细化，结果任务估算增加。
阿捷：嗯，还有其他的吗？
敏捷圣贤：有！采用Delphi方法进行任务工作量的估算。当进行任务细化的时候，每个人的估算是不一样的，如果最高估算值跟最低估算值相差一半以上，二者就要沟通一下，看看为什么二者的理解相差这么多。沟通明白后，再重新估算。即使这样，还是会有分歧的，此时采用Delphi估算方法，简单讲就是进行一次加权平均。
阿捷：嗯，我们以前也用过Delphi方法。
敏捷圣贤：为了提高任务细化的效率，可以将团队分成两个小组分别进行。
阿捷：为什么还要分组？不是让大家一起做细化、做估算的吗？
敏捷圣贤：是这样的，我曾经带过一个Team，有10个人。最初，我都是打开投影仪，把Product Backlog投到屏幕上去，大家一边说，我一边敲，我是挺忙活的，但是大家却不一定都能集中注意力。现在回头看看，这种方法真是有点蠢！当Team成员少的时候，在最初的几个Sprint，大家在兴趣还比较高的时候，这种方法还行。当Team成员超过6个的时候，问题出现了，首先是当讨论某一个问题的时候，总会有人问，刚才你们说什么来着？很显然，他走神了。另外，人多的时候，对同一个任务的细化，即使采用Delphi方法，沟通成本也很高，很费时间。
阿捷：那你们具体怎么做的？
敏捷圣贤：后来我就把Team分成两个小组，分别对任务进行细化。细化时，不再用投影仪，而是把Sprint Backlog中的内容按大块张贴在墙上，大家站在墙前，拿着记事帖直接进行细化和估算。当两个小组都进行完后，互相检查对方对任务的细化，解决争议，澄清模糊的地方。这样一来，就把大家的积极性调动起来，参与程度非常高，效率也高。
阿捷：虽然我们团队现在只有5个人，估计还用不上，但这个经验真的值得推广。
敏捷圣贤：产品负责人（Product Owner）一定要参加。实在不能参加的话，也要指定一个人授权代理。否则，就不要开Sprint计划会议。
阿捷：嗯，我一定会把他叫过来参加这个会议的。
敏捷圣贤：最后一点，虽然我们采用了Scrum，但即使不再采用Gatt图，但是传统的Risk/Dependency分析还是不要丢弃。在Sprint计划会议结束前，进行Risk/Dependency的分析，还是会帮助我们发现一些问题的，然后再稍微重新调整任务的优先级，更能保证Sprint的成功。
阿捷：好的！有了这些指导原则，我相信我们的第二个Sprint会走得更好的。
敏捷圣贤发过来一个不断眨眼的笑脸，似乎提醒阿捷不要过于乐观。
阿捷：还有一个问题就是，我感觉这个Scrum好像只定义了一个项目管理框架，没有给出具体的编程实践指导，是你还没告诉我吗？
敏捷圣贤：嗯，不是的。Scrum依靠的是经验管理，所以他没有定义出很细的工程实践。这样才能很好地跟组织原来的工程实践融合起来，譬如跟CMM、ISO 9000、RUP，甚至XP等都能很好地工作在一起。因为Scrum主要是想解决项目管理和组织实践范畴的东西，更多的是关注在敏捷团队建设上，它的终极目标就是自我管理自我组织的高效团队。作为一个敏捷框架，具体的编程实践，可以靠XP去补充。但我还是建议你们，最初先努力适应这个框架，待成熟后再考虑引入其他敏捷实践。
阿捷：好的！这次我不会冒进的。？
敏捷圣贤：那就好！凡事预则立，不预则废。对形势做出良好的判断并提前做好准备还是非常有必要的。我要下了，有事咱们再联系吧。
阿捷：多谢。886。
敏捷圣贤：886。
今天的收获太大了，阿捷重拾起了Scrum的信心，准备带领TD团队再次快跑。
。 最好的txt下载网
第6章 不仅仅是站立（1）
The way ahead is long； I see no ending； yet high and low I’ll search with my will unbending。
路漫漫其修远兮，吾将上下而求索。
——屈原《离骚》
根据敏捷圣贤的建议，如果想真正搞好Scrum，就必须有专门的Product Owner负责维护Product Backlog才行，这事得赶紧解决，否则，以后的Sprint Planning会议不仅开不好，而且每个Sprint肯定又问题多多。阿捷想了想，这事只有李沙最合适。李沙是负责Agile国内OSS产品的Product Manager，阿捷决定请他出山担任Product Owner。
李沙个子有米高，四方脸，稍微有点瘦，是个典型的东北大汉，平时总是西装革履。因为同是公司篮球队里面的，大家经常一起打球，所以关系一直很不错。
周五下午，阿捷决定找他聊聊。
“嗨，忙着呢啊？”阿捷走到李沙格子间时，李沙正在看Sohu体育新闻，没注意到阿捷过来。
李沙转过身来，笑了笑：“还行，你看这不火箭又赢了，国内的这帮人把姚明给吹的，不就是一个两双嘛！当家中锋你就得这个数据才行！”
“呵呵，胜者王侯败者寇！趁着赢球赶紧吹吹，也是有道理的。”
“嗯，对了。这周末的中智杯去不去？听说对手是双鹤药业。”
“去啊！没我哪成啊，你还不全靠我给你喂球呢。”
“好！打完球咱们涮肉去。对了！哥们儿，今天是不是有啥事？”
“有点小事儿。你现在不忙吧？”
“不忙，都周末了。说吧。”
“嗯，是这么回事”，阿捷先把自己团队要搞Scrum的事情介绍了一下，然后引到请李沙出任Product Owner的事情上来。
“噢，听起来你们这个流程似乎比原来的要灵活很多。我很愿意做这个事情，这样我们也能更好更及时地合作。可问题是我具体该做些什么呢？”
“首先，你要帮我们维护一个叫Product Backlog的东西。是我们所需要做的所有事情的高层次的列表，按照优先级排列起来。”
“你的意思是说把用户需求文档中的东西换一个形式？”
“嗯，差不多。原来我们用的需求文档太复杂了，有几百页。我们现在讨论到的Product Backlog是一个功能列表，可以组织得非常简单，既包括已经定下来的需求，也要包括那些还不清晰的需求。具体你可以用Excel，或者Word也行，看你用什么方便了！关键在于要方便修改、增删条目，以便于随时调整优先级。第一次，我可以帮你一起做一个初始版本。”
“那我们还是用Excel好了！”
“嗯，我也建议这样。我们现在计划每三个礼拜一个Sprint。那么你要根据根据实际情况随时修改这些内容：如增加新需求，修改已有需求，一定要实时，而且这些修改都要在下一次Sprint计划会议之前完成。这样，才能确保我们团队总是根据你排定的条目优先级，在处理最重要的需求。”
“没问题！”
“我们以后就将以这个文档跟你一起确认详细的需求。如果产生疑问，你得随时解释需求。如果我们做完了，你要帮我们把关，看看是不是你最初所要求的。”
“这些都是我本来就应该做的，除了维护这个Product Backlog外，流程上还需要我做什么？”
“参加两个会议：Sprint计划会议和Sprint评审会议。Sprint计划会议可能会占用很多时间，估计得大半天吧。Sprint评审会议应该比较简单，估计半小时或者一小时就够了。”
第6章 不仅仅是站立（2）
李沙皱了皱眉头：“哦？Sprint计划会议要这么久？我可不可以不参加？我保证开会之前把最新的Product Backlog给你。”
“那可不行！这个会议是我们最重要的会议，计划会议�
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部!
温馨提示： 温看小说的同时发表评论，说出自己的看法和其它小伙伴们分享也不错哦！发表书评还可以获得积分和经验奖励，认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦！