敏捷无敌-第15章
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
“可是老板，中国大陆的通信行业，包括咱们公司，每到年底前的这个月，因为大多数客户都在做年终财务汇总，而下一年的预算还没有定下来，基本上不可能再有多少预算的，所以通常订单都会是非常弱的。我想您肯定比我们还清楚。所以我的问题是我们怎么可能在这样一个弱势的一个月的时间内完成剩余的40％的Order目标呢？”别看小宝刚加入Agile公司没多久，可是分析得入情入理，大家不禁点头称是。
“So what？”Charles显然被激怒了！以前只有他Challenge别人的，却从来没有员工当着这么多人的面，Challenge自己！“你们只需要做好自己的工作就行了，干吗关心这些？这跟你们每天要做的工作有关系吗？”
“可公司领导层不一直提倡和鼓励我们底层员工要关心公司的发展、公司的状况吗？”小宝很少一根筋的，这时不知道怎么了反而来了劲了。
一阵沉默，令人难以忍受的沉默。
“咚咚……咚咚……”有人敲门，“请问你们用完这个会议室了吗？从3：00到5：00我已经预订了！”
真是及时啊！所有的人都解脱了，大家飞速逃离黑木崖。
。。
第9章 没有规矩，不成方圆（1）
Without adding *all steps；one cannot walk in thousands of miles； without s*ing *all creeks； they may never converge into rivers or the ocean
不积跬步，无以至千里；不积小流，无以成江海。
——《荀子？劝学》
芸芸众生，大都是凡人。凡人都是注重短期利益的。只有那些领袖、思想家才是目光如炬，站得高看得远。过程改进要从凡人做起，凡人是体系的执行者，所以首先要满足凡人的需求，让凡人看到好处，否则，群众的力量是无穷的，这可以是建设的力量，也可以破坏的力量。
敏捷的方法是适应变化的一种方法，因时、因势、因事调整计划，它可以处理近期内即将发生或已经发生的变化，它不赞成去为未来的变化花费太多时间，变化会导致近期计划的调整，也使长期的计划难以预期。此外敏捷最重要的是人和交流。如果不是一个很好的团队，或者说交流不通畅，敏捷和规范都会大打折扣。所以一定要先敏捷再规范，先做到再写到，先短期利益再长远利益，先实施再完备。
这个策略源于实践。因为一步到位直接采用规范的方法，阻力比较大，效果难以持久，很可能事倍功半，敏捷方法以其短期内可以见效、对已有的开发过程调整幅度小等特点易于被开发人员接受，将敏捷作为通向规范的一个阶段。否则，就容易出问题。这好比一个没练过正统功夫的，突然有一天去练九阳真经，如果没人帮他打通任督二脉，是非常容易走火入魔的，必须一步一步来才行。
转眼时间已经到了2007年的8月，阿捷的团队已经完成了三个Sprint，而第四个Sprint也在按部就班地进行中，一切看起来都很顺利，大家的心气也很高。阿捷打开自己的Blog——敏捷软件开发随笔，仔细回顾着每个Sprint。
这几个月以来，团队开始逐步地向自我组织、自我管理转变，虽然离达到这个Scrum的终极目标还有一段距离，但是进步明显，毕竟在阿捷他们的生活和工作经历中，受他人管理的习惯根深蒂固，从被管理到自我管理的转变是十分困难的。
有几次，阿捷因为部门的会议必须参加，而延误了回来参加每天的站立会议，等阿捷匆匆忙忙赶回来的时候，大家已经在自发地开会、交流，会后主动解决问题，防止自己的工作被阻塞，或者阻塞别人的工作，而没有等阿捷回来。现在，再遇到这种情形，阿捷已经可以非常放心地继续开会，而不用担心每天的站立会议是否会按时召开，大家是否能够自发地沟通，自发地解决问题。同时，在生产力和工作愉悦度方面，大家反响颇高。
阿捷暗想，实践证明，当初在Scrum的选择上是非常正确的，必须坚持下去。但目前遇到的一些问题，得想办法解决，否则，以后可能就会因小失大。阿捷决定在Sprint 4的回顾会议上跟大家一起讨论一下，看看大家的意见和解决方法。毕竟现在走上了团队自我管理的道路，还是由团队来做这些决定好。
周五下午三点，会议室“桃花岛”，Sprint 4的回顾会议已经快结束了。
“我们的Standup Meeting，因为时间短，需要很高的效率，但是有时候有人迟到，这样大家总要等待2～3分钟，才能开始……当然每个人都可能有自己的理由，但对大家的时间还是一个浪费，大家觉得呢？”阿捷抛出了想好的第一个问题。
第9章 没有规矩，不成方圆（2）
“我觉得问题不大。”阿朱不假思索地说：“反正才2～3分钟嘛，我们人也不多。”
“以后要是人多了呢？”阿紫反问：“其实有时候我们现在总共也才花不到10分钟的！”
“嗯，要不然来点儿惩罚措施吧？”小宝一脸的坏笑。
“小宝，说说，怎么个惩罚呢？”大民唯恐天下不乱。
“如果有人迟到呢，让他给大家唱一首歌，或者讲一个笑话，这个笑话必须保证每个人都笑的，才符合咱们‘DONE’的标准。再或者让他请大家吃冰淇淋，法子多的是啊。”看起来小宝在这方面真的很有经验。
“我觉得不错。”阿紫很快赞同。
“我觉得唱歌不太适合，这里可是办公室，还有其他团队的。”阿朱分析的总是很有道理：“讲笑话，有可能更花时间，不就跟我们的初衷相违背了吗？”
“可也不能天天吃冰淇淋啊！”小宝补充道。
“要不然谁迟到，就让他交5块钱吧，钱多了，我们可以在每次回顾的时候，买些瓜子、零食什么的。”大民的建议很具有可行性。
在大家纷纷表示赞同的时候，阿紫又抛出来一个问题“我觉得，我们的Plan会议、演示会议、回顾会议，谁迟到，也都应该罚款。”阿紫是团队的CFO，负责每次的Team Building的筹划和费用的计算，看来她想通过这个方式多收点钱！
“那有点太严格了吧？”经常迟到的小宝为了自己的钱袋子首先表示反对。
“要不这样吧，Daily Standup Meeting除外，其他Meeting，迟到三分钟以上，再罚款5块，如何？”阿捷看这次大家没有异议，把这两条记到本子上。
“我还有个问题，是关于Product Backlog的，从Scrum的角度来讲，都是由Product Owner负责的，别人不应该干涉，不应该修改Product Backlog。我经常会有一些想法，是关于产品的功能的，觉得应该加入到Backlog中去，可又不能直接修改Backlog； 我就只好记到别处，时间久了可能就忘记了。要是往Backlog中加吧，就得天天地打扰Product Owner 李沙，那他也烦啊！”大民提出了一个很关键的问题。
小宝马上表示赞同：“是啊是啊！我也有同感！”
“我和阿朱也讨论过，要是我们也能随时添加就好了。”阿紫瞅着阿朱，阿朱点了点头。
“我们不是在每个Sprint中间，不都是跟Product Owner有一次会议，Review Backlog吗？”阿捷满怀疑问地问道。
“是有，但是不够及时，事情都等到那次会议，搞得会议也挺紧张的。”大民接着说。
“可要是我们每个人都能修改，都能添加的话，Product Owner也受不了啊！”小宝替李沙担心。
“嗯，是啊！咱们好不容易才劝说了李沙来当这个Product Owner，没有他就没有人维护Backlog，咱们这个Scrum也就不能算是真正的Scrum了”！阿朱皱着眉头说。
“要不然这个事情放一放，哪天跟李沙一起讨论讨论，可能更好些。”阿捷提议道。
“嗯，也行，咱们自己也不能定。”大民一脸的无奈。
“还有一个就是Review的问题，我发现我们的Review工作，一直都不能按时完成，这在每日例会上，就能看出来，总有人说我的Code做完了，自己也测试过了，但是还没有人没给我Review ments，所以还不能Deliver。”阿捷又提出一个令大家尴尬的问题，有些人不好意思地低下了头。
“其实吧，有时候也不是大家不想Review，现在不是讲究快跑嘛，就是都挺忙的，顾不上。”小宝首先打破了沉默，替大家圆场，不过也是实话。
第9章 没有规矩，不成方圆（3）
阿捷点了点头，“是啊！这是我们实施Scrum以来出现的一个新问题，以前有大块的时间用于Coding，所以Review也不会像现在这么急，所以需要大家发表一下意见，看看我们有没有什么好的办法。”
“在做Sprint计划的时候，针对每个需要Review的文档或者代码，给需要Review的每个人都预留出来一定的Review时间，这样大家应该就不会紧张了。”小宝说道。
“让别人Review的时候，应该给出最晚回复时间，要不然别人也不知道紧迫性。”
“被邀请Review的人，如果不能及时Review，应该提前告诉对方。”
“最好是做一个邮件模板，把需要Review的内容，如文档或者代码的存储位置、修改原因、最迟答复时间等，都放在里面，这样信息集中。”
大家七嘴八舌地提着建议，看来这个问题还是比较容易解决的。
“好，那我们就按照上面大家提的意见试验一段时间。”阿捷总结道。
“还有一个非常关键的问题，就是关于Burndown Chart的。大家都知道，想让这个Burndown Chart反映出我们项目的真实状况的话，那我们每天对每个任务剩余工作量的估计，就应该准确及时。可我发现，有时候我们中总有人忘记更新，譬如在 Daily Standup Meeting上说某个任务已经完成了，但看Sprint Backlog，该任务的状态还是In Progress，还有一定的剩余时间。”
“呵呵，这好办，忘记更新的接着罚款。”阿紫这个CFO时时不忘增加收入的机会。
“有时候也不是故意不更新的，一忙就忘记了。”小宝好像不更新的次数最多，赶紧出来解释。
“要不这么着吧，我们就留三次免罚机会吧。”阿捷建议。
“每个人三次？总共才三个礼拜的Sprint，这样下来还是不能反映实际状况。”大民立刻表示反对。
“就是就是！”阿朱也表示赞同大民的意见，“要不然，咱们就给整个Team留三次免罚机会，如何？”
“这个方法可以，跟100米赛跑的规则差不多，虽然不太公平，但可行。”大民表示赞同，小宝、阿紫等人也都没有异议。
“好！这个问题也有解决方案了，看看大家，谁还有啥建议？或者还有哪里需要改进？”
大家一片沉默，看来都没有什么话题了。
“好！我们今天的成果还是挺丰富的，我下去整理一下，把我们今天讨论的这些东西跟以前的总结到一起，形成咱们自己的Scrum Rule！那今天就到这！”
大家边走边聊，陆陆续续走出“桃花岛”。
阿紫说：“大家觉得我们下次Team Building去哪里玩比较好？”
“我提议去打真人CS，非周末的时候，平均每人100多些。”阿捷这个CS迷，本性不改。
“我觉得去爬爬香山也不错，好久没去了！”阿朱提议。
“去后海吧！先划船，然后泡吧、杀人！”大民这个*分子，每次的提议都很奢侈。
小宝插了一句：“去打Golf吧，我都建议了好几次了！”
“好啊！好啊……你请客我们就去！”阿紫开始起哄。
大家吵吵呼呼地回到格子间，引来其他Team的一阵侧目。阿捷这个团队的传统一直就是这样，人不多，但每次开会都能听到他们的笑声。
回来的路上，阿捷顺路到产品经理李沙那里，讨论了一下关于Product Backlog条目更改的问题。让阿捷没有想到的是，李沙认为这个问题根本不是问题，只要大家添加新条目的时候，利用ScrumWorks工具软件里面的主题功能，对每个新条目施加一个“Not Reviewed”的主题即可，这样李沙就知道这些新条目了。但是，李沙还是重复强调，对于其他已经存在的Backlog条目，一定不能修改，特别是先后顺序。
阿捷回来重新整理了一下Scrum Rule； 然后分发给大家。
1．每日站立例会迟到，罚款￥5。
2．对于未及时更新任务状态和剩余工作量的，整个Team留三次免罚机会，以后再有人违反，则罚款￥5。
3．对于Sprint计划会议、演示会议和回顾会议，迟到超过3分钟，罚款￥5。
4．进行任务细分时，每个任务估算最大不能超过18小时�
