敏捷无敌之成长的烦恼(16)

 成长的烦恼(16)

本文摘自《敏捷无敌》一书

阿捷：嗯，还有其他的吗？
敏捷圣贤：有！采用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团队再次快跑。

 

【敏捷精灵日记】

 

• Scrum注重的是管理和组织实践，XP关注的是编程实践，分别着重解决不同领域的问题。可以组合使用，互相补充。
• 一条可以实行的实践原则，会比长篇大论的理论有用许多，没有实践原则指导的方法论没有意义。Scrum因为缺乏有效的编程实践，必须通过XP或其他方法来补充。 
• 使用XP，可以使开发人员成为更好的Developer，但 Scrum方法能够迫使那些效率低的developer变得更有效率。
• Nokia的Scrum标准：  

  * Scrum 团队必须要有产品负责人(Product Onwer)，而且团队都清楚这个人是谁。
  * 产品负责人必须要有产品的Backlog，其中包括团队对它进行的估算。
  * 团队必须要有燃尽图，而且要了解他们自己的生产率。
  * 在一个Sprint中，外人不能干涉团队的工作。

 

• Scrum虽然强调文档、流程和管理的轻量化，但并不是意味着没有控制，没有计划，只是要做轻量的短期冲刺计划。强调的是每时每刻都要根据需求和开发情况对项目进行调整，从而达到提前交付    
• ScrumMaster与传统项目经理相比，必须从传统的控制者转变为引导者。
• Scrum中，对任务细分和时间估计，需要整个开发小组和Product Owner的参与。   
• Sprint计划会议议程：

  上午(2 Hours)
    1)充实并讲解Product Backlog[Product Owner] (50 Minutes)
    2)重新调整Product Backlog条目优先级[Product Owner] (10 Minutes)
    休息(10 Minutes)
    3)设定Sprint目标[Scrum Team] (10 Minutes)
    4)选择Product Backlog条目，组成Sprint Backlog[Scrum Team] (40 Minutes)
  下午(3-4 Hours)
    1) 分成两个小组，进行任务细分， 定义"DONE"，给出任务估算. (60 Minutes)
    2) 小组间互相评审，解决争议(20 Minutes)
    休息(15 Minutes)
    3) 关键路径分析(20 Minutes)
    4) 制定资源计划(20 Minutes)
    5) 任务领取(20 Minutes)
    6) 风险分析(20 Minutes)
    7) 其他事情(10 Minutes) 

 

    （当当购买 卓越购买）