下载掌阅APP，畅读海量书库
立即打开
敏捷的方法是适应变化的一种方法，因时、因势、因事调整计划，它可以处理近期内即将发生或已经发生的变化，它不赞成去为未来的变化花费太多时间，变化会导致近期计划的调整，也使长期的计划难以预期。此外，敏捷最重要的是人和交流。如果不是一个很好的团队，或者说交流不通畅，敏捷和规范都会大打折扣。所以一定要先敏捷再规范，先做到再优化，先短期利益再长远利益，先实施再完备。
因为一步到位直接采用规范的方法，阻力比较大，效果难以预期，很可能事倍功半，敏捷方法以其短期内可以见效、对已有的开发过程调整幅度小等特点易于被开发人员接受，所以要先应用起来，然后再规范。否则，就容易出问题。
光阴似箭，转眼到了2007年的8月。阿捷的团队已经完成了三个Sprint，而第四个Sprint也在进行中，一切看起来都很顺利，大家的心气也很高。阿捷打开项目日志，仔细回顾着每个Sprint。为了增加趣味性，阿捷坚持为每个Sprint起一个名字，不仅可以体现阶段性目标，还可以记录团队当时的心情。
Sprint 1：兵不厌诈（the Big Con）
大家第一次采用Scrum，对这个Agile流程都很期待，同时呢，对于怎么做，如何用，还很模糊。
Sprint 2：越狱记（Breakout）
经过了第一个Sprint后，大家干劲十足，士气高涨，认为我们可以在第二个Sprint取得重大突破（breakout）。
Sprint 3，虎口余生（Hours to doom day）
这个Sprint里面有很多技术难点需要突破，如果解决不了，后面的工作就无法进行，这是非常关键的一次攻坚战。
Sprint 4，大结局（The Big End）
这次计划会议，作为Scrum Master，自己因为有事没有参加，汗！但大家认为阶段性工作基本可以做完了，起了个“大结局”的名字。
几个月以来，团队开始逐步地向自组织、自管理转变，虽然离Scrum的终极目标还有一段距离，但是进步明显。毕竟在阿捷他们的生活和工作经历中，受他人管理的习惯根深蒂固，从被管理到自我管理的转变是十分困难的。
有几次，阿捷因为部门的会议必须参加，而延误了回来参加每天的站立会议，等阿捷匆匆忙忙赶回来的时候，大家已经在自发地开会、交流，会后主动解决问题，防止自己的工作被阻塞，或者阻塞别人的工作，而没有等阿捷回来。现在，再遇到这种情形，阿捷已经不用担心每天的站立会议是否会按时召开，大家是否能够自发地沟通，自发地解决问题。同时，在生产力和工作愉悦度方面，大家反响颇高。
阿捷暗想，实践证明，当初在Scrum的选择上是非常正确的，必须坚持下去。但目前遇到的一些问题，要想办法解决，否则，以后可能就会因小失大。阿捷决定在Sprint 4的回顾会议上跟大家一起讨论一下，看看大家的意见和解决方法。毕竟现在走上了团队自我管理的道路，还是由团队来做这些决定好。
周五下午三点，桃花岛会议室，Sprint 4的回顾会议已经快结束了。
“我们的每日站立会议，虽然时间短，但有时候仍然会有人迟到，这样大家总要等待2～3分钟，才能开始……当然，迟到的人可能有自己的理由，但对大家的时间还是一个浪费，大家觉得呢？”阿捷抛出了想好的第一个问题。
“我觉得问题不大。”阿朱不假思索地说：“反正才2～3分钟嘛，我们人也不多。”
“以后要是人多了呢？”阿紫反问：“其实有时候我们总共也才花不到10分钟的！”
“嗯，要不然来点儿惩罚措施？”小宝一脸的坏笑。
“小宝，说说，怎么个惩罚呢？”大民唯恐天下不乱。
“如果有人迟到呢，让他给大家唱一首歌，或者讲一个笑话，这个笑话必须保证每个人都笑的，才符合咱们DONE的标准。再或者让他请大家吃冰淇淋，法子多的是。”看起来小宝在这方面真的很有经验。
“我觉得不错。”阿紫很快赞同。
“我觉得唱歌不太适合，这里可是办公室，还有其他团队呢。”阿朱分析的总是很有道理：“讲笑话，有可能更花时间，不就跟我们的初衷相违背了吗？”
“可也不能天天吃冰淇淋啊！”小宝补充道。
“要不然谁迟到，就让他交罚款吧，钱多了，我们可以在每次回顾的时候，买些瓜子、零食什么的。”大民的建议看似颇具有可行性。
在大家纷纷表示赞同的时候，阿紫又抛出来一个问题“我觉得，我们的计划会、评审会、回顾会，谁迟到，也都应该罚款。”阿紫是团队的CFO，负责每次团建的筹划和费用的计算，看来她想通过这个方式多收点钱！
“那有点太严格了吧？”经常迟到的小宝为了自己的钱袋子首先表示反对。
“要不这样吧，每日立会除外，其他会，迟到三分钟以上，再罚款，如何？”阿捷看这次大家没有异议，把这两条记到本子上。
“我还有个问题，是关于Product Backlog的。从Scrum的角度来讲，都是由Product Owner负责的，别人不应该干涉，不应该修改Product Backlog。我经常会有一些想法，是关于产品功能的，觉得应该加到Backlog中去，可又不能直接修改Backlog，我就只好记到别处，时间久了可能就忘记了。要是往Backlog中加吧，就得天天地打扰李沙，那他也烦啊！”大民提出了一个很关键的问题。
小宝马上表示赞同：“是啊是啊！我也有同感！”
“我和阿朱也讨论过，要是我们也能随时添加就好了。”阿紫瞅着阿朱，阿朱点了点头。
“我们不是在每个Sprint中间，都跟Product Owner有一次会议来梳理Backlog吗？”阿捷狐疑地问道。
“是有，但是不够及时，事情都等到那次会议，搞得会议也挺紧张的。”大民接着说。
“可要是我们每个人都能修改，都能添加的话，Product Owner也受不了啊！”小宝替李沙担心。
“嗯，是啊！咱们好不容易才劝说了李沙来当这个Product Owner，没有他就没有人维护Backlog，咱们这个Scrum也就不能算是真正的Scrum了”！阿朱皱着眉头说。
“要不然这个事情放一放，哪天跟李沙一起讨论讨论，可能更好些。”阿捷提议道。
“嗯，也行，咱们自己也不能定。”大民一脸的无奈。
“还有一个就是Code Review（代码评审）的问题。我发现我们的Code Review工作，一直都不能按时完成，这在每日例会上，就能看出来。总有人说我的代码做完了，自己也测试过了，但是还没有人给我评审意见，所以不能提交代码。”阿捷又提出一个令大家尴尬的问题，有些人不好意思地低下了头。
“其实吧，有时候也不是大家不想做代码评审，现在不是讲究冲刺嘛，大家都挺忙的，顾不上。”小宝首先打破了沉默，替大家圆场，不过也是实话。
阿捷点了点头，“是啊！这是我们实施Scrum以来出现的一个新问题，以前有大块的时间用于编码，所以评审也不会像现在这么急。现在，需要大家发表一下意见，看看我们有没有什么好的办法。”
“在做Sprint计划的时候，针对每个需要评审的文档或者代码，给需要评审的人都预留出来一定的评审时间，这样大家应该就不会紧张了。”小宝说道。
“让别人评审的时候，最好给出最迟答复时间，要不然别人也不知道紧迫性。”
“被邀请评审的人，如果不能及时评审，应该提前告诉对方。”
“最好是做一个邮件模板，把需要评审的内容，如文档或者代码的存储位置、修改原因、最迟答复时间等，都放在里面，这样信息集中。”
大家七嘴八舌地提着建议，看来这个问题还是比较容易解决的。
“好，那我们就按照上面大家的意见试验一段时间。”阿捷总结道。
“还有一个非常关键的问题，就是关于燃尽图的。大家都知道，想让这个燃尽图反映出我们项目的真实状况，那我们每天对每个任务剩余工作量的估计，就应该准确及时。可我发现，总有人忘记更新，譬如在每日立会上说某个任务已经完成了，但看Sprint Backlog，该任务的状态还是In Progress（进行中），还有一定的剩余时间。”
“这好办，忘记更新的接着罚款。”阿紫这个CFO时时不忘增加收入。
“有时候也不是故意不更新的，一忙就忘记了。”小宝好像不更新的次数最多，赶紧出来解释。
“要不这么着吧，我们就保留三次免罚机会吧。”阿捷建议。
“每个人三次？总共才三周的Sprint，这样下来还是不能反映实际状况。”大民立刻表示反对。
“就是就是！”阿朱表示赞同大民的意见，“要不然，咱们就给整个团队保留三次免罚机会，如何？”
“这个方法可以，跟100米赛跑的规则差不多，虽然不太公平，但可行。”大民表示赞同，小宝、阿紫等人也都没有异议。
“好！这个问题也有解决方案了。看看大家，谁还有啥建议？或者还有哪里需要改进？”大家一片沉默，看来已没有什么话题了。
“好！我们今天的成果还是挺丰富的，我下去整理一下，把我们今天讨论的这些东西跟以前的总结到一起，形成咱们自己的Scrum规则！那今天就到这！”
大家边走边聊，陆陆续续走出桃花岛。
阿紫说：“大家觉得我们下次团建去哪里玩比较好？”
“我提议去打真人CS，非周末的时候，平均每人100多些。”阿捷这个CS迷，本性不改。
“我觉得去爬爬香山也不错，好久没去了！”阿朱提议。
“去后海吧！先划船，然后泡吧！”大民这个腐败分子，每次的提议都很奢侈。
小宝插了一句：“去打高尔夫，或者去大连找伯薇玩帆船吧，我都建议好几次了！”
“好啊！好啊……你请客，我们就去！”阿紫开始起哄。
大家吵吵呼呼地回到格子间，引来其他团队的一阵侧目。阿捷这个团队的传统一直就是这样，人不多，但每次开会都能听到他们的笑声。
回来的路上，阿捷顺路到产品经理李沙那里，讨论了一下关于Product Backlog条目更改的问题。让阿捷没有想到的是，李沙认为这个问题根本不是问题，只要大家添加新条目的时候，利用ScrumWorks（一种敏捷项目管理软件）工具软件里面的主题功能，对每个新条目施加一个“Not Reviewed”【未评审】的主题即可，这样李沙就知道这些是新条目了。但是，李沙还是重复强调，对于其他已经存在的Backlog条目，一定不能修改，特别是先后顺序。
阿捷把重新整理的团队工作协议（Working Agreement），打印出来，贴在了办公室的墙上。
1. 每日站立例会迟到，罚款5元。
2. 对于未及时更新任务状态和剩余工作量的，整个Team保留三次免罚机会，以后再有人违反，罚款5元。
3. 对于Sprint计划会议、演示会议和回顾会议，迟到超过3分钟，罚款5元。
4. 进行任务细分时，每个任务估算最大不能超过两个工作日。
5. 对于每个需求，在进入迭代之前要满足DoR（Definition Of Ready/就绪定义）；对于进入迭代的需求要有DoD（Definition Of Done/完成定义）。
6. 对于复杂任务的估算和分解，采用DELPHI方法。
7. 每个人都可以添加新的Product Backlog条目，但必须标示为“Not Reviewed”【未评审】，以方便Product Owner审议。
8. 为提高Sprint回顾会议的效率，在Sprint回顾会议之前，每个人应该提前思考“我们做得好的地方、需要改进的地方”。
9. 在Sprint计划会议上，预留10%的估算时间作为缓冲，以应对突发事件。
10. 在Sprint计划会议上，进行关键路径、风险、外部依赖的分析。
11. 对于代码评审，发出评审的人必须给出截止日期；参与评审的人，必须在截止日期前给出答复。
12. 团队对于架构讨论等技术决策发生冲突时，由架构师拍板。
13. 每个Sprint外出团建一次。
1. 采用敏捷的方法并不意味着没有规矩，没有文档、没有计划，没有跟踪与控制并不意味着就是敏捷。
2. Scrum把迭代称之为“Sprint”（冲刺）的一个理由，就是希望所有人尽最大努力把事情做好，但团队不可能无休止地冲刺。每次冲刺需要回顾总结，持续改进。
3. 没有规矩，不成方圆。由团队共同制定出来的Scrum团队规则，是整个团队的工作协议（Working Agreement），可以更好地保证Scrum的顺利实施。
“个体和互动胜于流程和工具”，人们往往对敏捷宣言的这句话存在误解，认为敏捷是不需要流程与制度的。事实上，敏捷要做好，各种规矩必不可少。例如Scrum里面各类角色的定义与职责，各种会议的形式与目的，再比如对DoR与DoD的要求。
敏捷中的规矩，目的在于Build Quality In（内建质量），一切有利于高效的产出高质量产品的过程与规范，都应该恪守。所以从这个层面上讲，敏捷的纪律更多的是自律；而自律更应该是团队与团员自发的，而不是自上而下传达的。团队工作协议，就是最好的体现。
团队工作协议，是由团队成员共同协商、所达成的一致遵守的一组规则、纪律和流程，目的是让团队持续保持高效和成功。
站会迟到，是团队最常见的问题。迟到虽然不是个大事，但会直接影响到团队站会的效率。对于其他的会议也是如此。会议需要有仪式感，在固定的时间，甚至固定的地点发生。团员的迟到行为，往往会以并非故意为借口，偶尔一次可以理解，但如果今天你迟到，明天他迟到，长此以往，没有人会去恪守开会的时间。由此引发的，不只是简单的浪费几分钟而已，而是让团队成员之间产生摩擦，严重的甚至会失去对彼此的信任。
每个团队都需要有适合自己的工作协议。工作协议一定要让大家每天看到，固化习惯。工作协议一定是可执行的，并且共同监督的，否则就容易成为一纸空文。
纪律应该强调，但不建议太过强硬。基本的原则是让团队自发产生规约，无法完全达成一致的，可以投票决定，这样达成的共识，是团队共同产出的，更容易被遵守。团队自己达成的规则，表达了团队的自愿；只有自愿地承诺，才有动力坚持。
“种一棵树，最好的时间是十年前，其次是现在。”团队工作协议的制定，当然是越早越好。敏捷团队组建的一开始，是建立工作协议的最好时候。团队就共同需要遵守的流程、纪律达成共识，可以有效地避免团队中的个体以各自不同的工作方式来协作。
往往团队无法在组建初期就意识到需要这样的工作协议，即使是有经验的Scrum Master或者敏捷教练提出这样的要求，团队成员也未必可以意识到工作协议的重要性。那么次优的建立时间，是在发生问题时，在迭代的回顾会议上针对问题，提出解决方案并由此引出规约，逐渐形成团队工作协议。
“可工作的协议胜于面面俱到的规定”。工作协议的描述要足够简洁，应该扼要的讲明做什么，不做什么。工作协议应该是可视化，贴在所有人都能看到的地方，例如物理看板上。所以就更需要用几个字来讲清楚，而不是长篇大论的详述。
“响应变化胜于遵循计划”。流程和规则是演进式与时俱进的，随着项目和团队的需要而涌现出来的；工作协议不是一成不变的，在每个迭代的回顾会议上，针对所发现的问题，讨论是否需要对工作协议进行补充、修改；同时在回顾会议上，团队也应该有意识的回顾工作协议遵守的情况，以及工作协议是否依然有效；工作协议无须面面俱到，已然固化到团队行为中的，我们视为常识，不再需要强调，就可以从工作协议中剔除；当然也可以另行维护一份团队价值观或者守则的文档，作为团队文化建设与传承，这个的目的与团队工作守则就有所区别了。
________________________
________________________
________________________