下载掌阅APP，畅读海量书库
立即打开
时间过得很快，两周一晃就过去了。阿捷他们的第一个Sprint也结束了，但大家感觉并不怎么好。
在Sprint计划会议上，大家按照阿捷准备的一个Product Backlog，从中选择了一些用户需求进行开发。虽然阿捷事先对这个Product Backlog做了一定的细化，并设定了优先级，但在选择的时候，大家并没有按照优先级来选，而是找了几个刚好可以在两周内做完的东西。会议上，大家大致讨论了一下，阿捷就按照先前的惯例，根据每个人过去的经验，对每个模块的熟悉程度，基本上是直接指定一个人做哪个任务了。对于每个任务，没有做详细的估算和任务划分，因为以前一直是这样做，把任务交给一个人后，由这个人一直负责，自己做估算、做设计、实现，然后交给测试人员测试，测出Bug再返工，直到完成为止。这个过程基本上就是一个黑盒，如果负责这个任务的人不说，别人也不知道具体做得如何，当前是什么状态。
Sprint计划会议的第二天上午10：30，阿捷召集所有的人在“光明顶”举行了第一次站立会议，因为这是首次举行站立会议，大家相互看着对方，觉得很好玩，兴致也很高。阿捷首先把自己负责的任务讲了一下。包括自己将会如何设计、对不同的实现方式进行了比较，然后给出估算，觉得应该可以在一周内做完，然后交给测试人员进行测试。大民、小宝基本上都是同样的模式，也把自己的任务讲了一遍。小宝觉得自己那块有些复杂，可能要花上8个工作日才行，估计剩不了多少时间留给测试了。阿朱和阿紫因为要等着开发人员做完后，才能进行测试，所以也没开始具体做什么事情，讲起来自然简单，两个人总共花的时间还没有大民、阿捷一个人用的时间一半多。但即使如此，不知不觉的时间就到了11：40，大家差不多站了一个小时，腿都酸了，刚好都到了吃饭时间，大家一哄而散，下楼吃饭。
在接下来的日子里，如果有会议室，大家就到会议室里开站立会议；如果没有，大家就聚到阿捷的格子间凑合一下。有时候是上午10：00开，有时候是10：30，还有一次因为阿捷上午要开部门会议，大家的Scrum站立会议是在下午3：00开的。有时候大家会对一个技术问题展开激烈的讨论，有时候不知怎么的，大家就会扯到姚明、NBA、奥运会北京限行措施、抢购奥运门票的事情上去，偶尔还会聊聊公司的公积金政策、部门的人事变动等，反正每次的会议都挺长。有时候谁累了，就坐在椅子上或桌子上，听别人讲。当然还少不了阿紫、小宝这样的短信狂人，收到短信时所带来的噪音。有时候，阿捷也觉得这么做真的有点浪费时间，相信其他人也有同感，但即使如此，大家还是把站立会议坚持了下来，毕竟Scrum很重要的一点就是强调Daily Standup Meeting（每日立会）的！
大民和阿捷所负责的任务基本上都按期完成了，阿朱、阿紫分别进行了测试，虽然发现了一些小问题，但大民、阿捷还是在Sprint结束前就修正完了。但小宝所负责的任务，就像他自己第一天所说的，真的遇到了麻烦。一个模块总是出现Core Dump（系统崩溃的一种），无法运行，小宝换了好几种方法，甚至做了调试版本，进行单步跟踪，还是找不到问题。甚至在开站立会议时，大家等了他好几次，他才不情愿地从座位上站起来。在会议中间，还跑回去几次看看运行结果。因为小宝自己没有主动提出需要帮助，所以阿捷、大民也没好意思多问。直到Sprint结束前一天，小宝才兴奋地告诉大家，问题终于解决了。可留给阿朱的测试时间只有一天了，虽然阿朱早已准备好了测试用例，但对于这样一个复杂的特性，这点儿时间还是不够的。于是，在这个Sprint中，小宝负责的模块没有完成最终测试。这让阿朱很沮丧，因为这也导致她的工作没有完成。阿朱很委屈，自己的工作前松后紧，自己也想努力完成最初计划的事情，可是小宝的工作一直没完成，自己也只能是干着急，毫无办法。
对于这种现状，阿捷更着急。不仅仅是因为这个Sprint的原始计划没有完成，更重要的是团队的第一次冲刺就这么搞砸了。在Sprint结束后，阿捷组织大家进行了一次简单的回顾，谈谈大家对第一次冲刺的感受。在会上，阿捷虽然想了点破冰游戏，试图活跃一下气氛，但因为第一次冲刺的过程与结果都不令人满意，气氛还是很压抑。大家谈得不多，基本上觉得每天的状态报告会花了太多时间，其实应该把这个时间更好地用到项目本身才对；另外，因为Scrum本身只是一个框架，没有定义具体的编程实践，不如一些XP实践更具有可操作性，关键的还是大家都没看到这个Scrum流程的价值，这次冲刺让大家有点泄气。小宝和阿朱甚至说，干脆别搞Scrum了，似乎带来的问题更多。阿捷好说歹说，才使大家平静下来，最终达成的一致意见是暂时停下来，重新审视一下，看看是不是可以改善一下，在找到真正可行的办法或者操作实践后，再继续搞下一次冲刺。
这几天阿捷一直很苦恼，再加上7月的北京已经开始炎热起来，阿捷就有点着急上火，不仅仅睡觉不踏实，嘴边也起了大泡。从感觉上讲，Scrum应该是一个很好的项目管理模式，否则像谷歌和微软等大公司也早就放弃了。可能只是自己实践的方式不对吧，但却又不知道到底该怎么去改善。看来还是要求教敏捷圣贤了。阿捷每天都上网，并待到很晚才下去，希望能碰到敏捷圣贤。
这天晚上，阿捷跟美国方面开完电话会后，发现敏捷圣贤上线了！阿捷高兴得跳了起来。
阿捷： 你好！
敏捷圣贤： 你好啊！
阿捷： 现在有时间吗？我们遇到了麻烦。
敏捷圣贤： 我果然猜对了！我是专门上来找你的！我想你们的第一次冲刺结束了吧？
阿捷： 是的！我们遇到一些问题，大家的意见开始出现分歧了，有人甚至认为Scrum带来了更多的麻烦！
敏捷圣贤： 这可不是一个好兆头。说说你的问题，让我看看，怎么解决，我想多数是你们使用的方法有偏差。
阿捷： 我也觉得Scrum是一个很好的流程。
敏捷圣贤： 对！只做了一个Sprint，不要着急下结论说Scrum适合或不适合。Scrum可以让你从另外一个角度来思考如何进行项目管理。找到窍门总是需要花些时间的。我建议你们小组坚持这个流程，至少做完3个Sprint，然后再决定是否继续。第一次冲刺肯定会遇到问题的，你们可以回顾总结一下，把一些能操作的改进加到第2个Sprint中，逐步做出改善。这样，经过3个Sprint，你们才会真正地了解Scrum。
阿捷： 好！我会劝说大家继续跑完Sprint 2和Sprint 3的。
敏捷圣贤： 先给我讲一下你们是怎么做的？
阿捷： 大概是这样做的。我事先完成了产品的Backlog，然后大家一起做了一个执行计划。之后就是每天早上开“站立会议”，这个非常花时间，每次大概40～50分钟。在Sprint结束的时候，每个人做了几分钟的总结，并进行了回顾，会上大家都觉得Scrum问题不少。
敏捷圣贤： 哦，你们的产品Backlog是怎么组织的？
阿捷： 作为一个Scrum Master，我用Excel做了个列表，把我们下几周需要做的东西放进去，还按照优先级排了一下序。
敏捷圣贤： 等一下！你说，你做了一个Product Backlog？
阿捷： 是啊！有什么问题吗？
敏捷圣贤： 也就是说，你们没有找到一个Product Owner这个角色？没有让这个人去完成并维护Product Backlog？
阿捷： 嗯，我们没有。
阿捷心想敏捷圣贤的脸色一定很难看，估计这个问题很严重！
敏捷圣贤： 如果你们真的想实行Scrum，那么就一定要遵循Nokia的敏捷标准，遵循诺基亚制定的“Scrum规则”，这是诺基亚用了几年时间，对上百个Scrum团队进行了回顾后，才总结出来的建议，这可以帮助你们判断一个团队是否在真正实施Scrum。
阿捷： 那诺基亚怎么知道一个团队是否真的在实施Scrum呢？
敏捷圣贤： 首先，他们要看是否采取了迭代开发的方式。多年来，业界一直使用迭代式的、增量式的开发，这似乎已经成为所有敏捷过程的基础元素了。
阿捷： 这个应该比较好判断。那为什么团队是否“进行迭代开发”这么重要呢？
敏捷圣贤： 如果不这样做，甚至都不能称为敏捷的软件开发过程。这是因为敏捷希望整个软件开发流程中的所有人都可以一起工作，大家都要对产品非常了解：无论是构建产品的人，测试产品的人，还是将会使用产品的用户。
阿捷： 大家是应该一起工作？
敏捷圣贤： 对，如果把过程分隔成“这里的这些人编写需求说明和规范，然后他们把文档交给负责构建软件的人，软件构建者再将软件转给测试人员，最后测试人员把软件提供给客户”。客户如果说那不是他们真正需要的东西，一切就要回到开头，再来一次。如此反复三遍的话，客户就会取消这个项目了。这就是为什么世界上有那么多项目被砍掉的原因。
阿捷： 嗯，那在诺基亚，接下来要问什么问题？
敏捷圣贤： 他们会接着问“你们有固定的迭代周期吗？你们的迭代是否以某个特定的时间开始并以某个固定的时间结束？”
阿捷： 是不是迭代周期也应该有限制？
敏捷圣贤： 对！在诺基亚，迭代周期必须少于4周。如果不是这样做的，那么就没有进行迭代开发。
阿捷： 如果人们的回答是肯定的呢？
敏捷圣贤： 那他们接下来会问“那好，在每个迭代结束的时候，你们有可以工作的软件吗？”这个问题会把很多人排除在外，因为如果不能给出可以工作的软件的话，那也就是没有进行敏捷开发。
阿捷： 嗯，如果回答还是肯定的呢？
敏捷圣贤： 他们继续说“好，你希望在结束时拥有可工作的软件，那么在可以开始迭代之前，你们的团队是不是必须要有一个细节完整的需求说明？”如果需要的话，那就不是敏捷开发。
阿捷： 哦，我有些明白你的意思了。接着呢？
敏捷圣贤： 最后他们会说“要在迭代结束时拥有可以工作的软件，将测试作为迭代增量开发的一部分是非常重要的。你们在开发过程中进行测试吗？”这个问题有可能将一半左右的Scrum团队排除在外，这时甚至还没有谈到有关Scrum的话题呢。
阿捷： 我明白了，那他们的“Scrum规则”是什么？
敏捷圣贤： 嗯，对于应用Scrum，他们有四个附加的规则。团队被询问的第一个问题是“你们是否有Product Owner？是不是有人可以代表客户与你们一起工作？”
阿捷暗想，自己团队的Scrum还真没有啊，于是问道：Product Owner的作用是什么？
敏捷圣贤： 很简单，当团队在决定应该构建什么样的产品时，这个人就是他们要询问的对象，这个人代表着客户的需求与利益。这个人就像开车时，把握方向盘的人，决定着团队前进的方向，他要为产品的成功负责！
阿捷： 如果对这个问题回答“是”呢？
敏捷圣贤： 第二个问题是“如果有Product Owner，他们是否拥有一个待开发功能的Product Backlog？此Backlog是否根据业务价值排定了优先级？是否已经对其进行了估算？”。
阿捷： 哦。
敏捷圣贤： 这是一个Product Owner为一次版本发布构建路线图所需要的依据。如果得到了肯定的回答，他们会继续询问“团队在开发过程中，有没有使用Burndown Chat（燃尽图），来展示当前迭代中随着时间的推进，剩余工作量的变化，用以跟踪进度，并且能否基于燃尽图来推算团队的速度？”
阿捷： 这个问题的意义在哪里呢？
敏捷圣贤： 首先，Product Owner可以根据团队整体速度来构建发布规划；同时团队可以根据它来改进流程。只有知道自己的速度如何，才有助于一个团队进行更好的估算，同时帮助他们在继续后续工作时提升速度。通过燃尽图，可以有效地预测团队是否能够按时完成当前Sprint计划的工作；如果不能，可以及时进行调整。
阿捷： 嗯，这已经有三个规则了，最后一个是什么？
敏捷圣贤： Scrum团队依赖自组织的过程，这就意味着团队负责挑选工作、职责分配，并要找出最快交付工作的途径。所以，诺基亚的最后一条规则是：在迭代中，项目经理不能干涉团队工作，因为这会停止自组织的过程，并且得到解决方案的过程将不再是最优化的了。
阿捷再次想起了Product Owner的问题，赶紧问：为什么非要专门的Product Owner？我代替不可以吗？
敏捷圣贤： 首先，Product Backlog是Scrum的核心，从根本上说，它是一个需求或故事或特性组成的列表，并且按照重要性进行了排序，一定是客户想要的东西，并且用客户的语言进行描述。通常除了客户需求之外，还会包含技术性需求，譬如架构相关、性能相关的事情；还会包含Bug；还有探针Spike，这个属于探索性需求，是对未来的一个预研，不会真的发布给客户。此外，有的时候还需要把重构的事情也放进去，一起排序。
敏捷圣贤： 其次，在维护产品Backlog的时候，Product Owner（就是那个能代表最终客户发言的人）必须参加，由他排列优先级。Product Owner必须是离客户最近的人，你作为研发项目管理人员，不可能是离客户最近的人。如果没有这个角色，你们怎么知道哪个重要哪个不重要？和Product Owner交流，你们才可以得到一个有优先顺序的列表，把最重要的功能放在列表的前面。
阿捷： 我知道了，看来我得找Product Manager来担任这个角色才行。那这个Backlog条目除了优先级外，还有其他什么要求？
敏捷圣贤： 嗯，每一个条目应该有一个估算，这个并不需要很准确，只需要有一个大概的估算即可，这样才能够决定把多少工作放到一个Sprint里。
敏捷圣贤： 另外，在你开Sprint计划会议之前，你的Product Backlog应该保持一种合适的格式。你可以是把它们都放在一个Excel中，也可以是一个Word文档，或者是某种Scrum工具中，采用哪种形式都可以，只要你们自己觉得方便就行。
阿捷： 嗯，我用了Excel。
敏捷圣贤： Sprint计划会议除了你的团队成员和Product Owner外，还可以邀请更多的人参加。
阿捷： 我还以为我一个人规划Sprint就可以了呢。
敏捷圣贤： 那是旧的管理模式。在Scrum框架下，没有“个人”的概念，Scrum依靠的是团队的力量。尽管Scrum Master在这个框架下的作用很重要，但这个人不是独裁者。做Sprint计划时，一定要让整个团队参加。
阿捷： 那具体怎么做呢？大家一起做计划，岂不是很乱？
敏捷圣贤： 首先，你们要先定下来Sprint的目标，即作为一个团队，你们要完成什么，然后再决定完成多少。
阿捷： 我们当前没有任何历史参考数据，怎么知道完成多少呢？
敏捷圣贤： 事先计算出在一个Sprint内，团队的可能工作时间。譬如，在未来三周内，一个5人小组，每人每周工作40小时，那么总的工作时间=5×40×3=600小时。
阿捷： 理想情况是这样的，但肯定会有人休假的。
敏捷圣贤： 对，所以你要将总的工作时间扣除任何预期的非工作时间。譬如，有一个人要休一周的年假，还有人要看牙，需要占用3天，这样算起来是600-5×8-3×8=536小时。
阿捷： 还有，即使每人每天工作8小时，但也不是会真的有8小时工作在项目上，还要参加各种会议、培训、沟通等活动。
敏捷圣贤： 如果每天8小时，你们大概会有几小时工作在项目上？
阿捷： 平均差不多7小时吧。
敏捷圣贤： 你得把每天花在参加会议、谈话、处理邮件、上网等时间都除去。
阿捷： 那估计6小时。
敏捷圣贤： 我们把它用百分比表示，6/8，那么就是75%左右，然后用这个“负荷指标”（Load Factor）乘以总的工作时间小时数，你就得到了536×0.75=402小时。
阿捷： 嗯，这种估算很实际。
敏捷圣贤： 然后从产品Backlog中，按照优先级从高到低，选择出你们认为能在402小时内完成的条目，作为你们当前Sprint的Backlog。注意：选择的Sprint Backlog条目一定要强内聚、松耦合，这样你们才能不受或者少受外界的干扰，目标明确。
阿捷： 那个“负荷指标”75%应该是有变动的吧？我们刚上手一个项目，与过去的项目相比，肯定是不一样的。再譬如，当有新员工加入时，他的效率肯定是要比老员工低的。
敏捷圣贤： 对。你已经很好地理解了负荷指标，你可以利用它把Sprint计划得很准确。当你遇到低的“负荷指标”时，要试着找出原因，这会使你们的Sprint更有效率。
阿捷： 下一步是不是该做任务细化？进行估算？
敏捷圣贤： 不完全对。任务细化之外，还有一个非常重要的部分：对于每个细化后的任务，都需要一个非常明确“完成”（Done）的定义。这一点非常重要，必须保证每一个人的理解是正确的、一致的。
阿捷： 嗯，否则每个人的估算就会千差万别。
敏捷圣贤： 对！
阿捷： 还有什么值得注意的？
敏捷圣贤： 做Sprint任务细化时，一个最佳实践就是把每个任务控制在1～2天内完成。任务太细，会涉及更多的微观管理；太粗，估算就会不准确。
阿捷： OK！在这一点上，Scrum跟其他项目规划方法是一样的。
敏捷圣贤： 下一步，就是让大家自己认领任务，而不是指派！这一点非常关键，一定要记住啊？
阿捷： 为什么要认领？指派会更有效率，而且还能根据每个人的特长，让每个人做他擅长的事情。
敏捷圣贤： 首先，每个人认领任务后，实际上就是对整个团队有了一个承诺，更能保证按计划完成。其次，让每个人选择自己愿意做的事情，这样才会更有主动性，毕竟“做自己有兴趣的事情，才会真的做好”。这样，不仅满足了个人发展的需要，还可以达到快速的知识共享、团队技能的整体提高。
阿捷： 不错，以前是只对项目经理一个人的承诺，这样认领后，就成了对所有人的承诺。
敏捷圣贤： 此外，跟任何其他会议一样，对于计划会议，确定好会议日程非常重要。因为Sprint计划会议一定要基于Time-Boxed（时间盒），在规定的时间内，一定要结束，就像一个Sprint一样，同样要有紧迫感。
阿捷： 嗯，我会仔细计划的。
敏捷圣贤： 还有，Sprint计划会议必须在一个完整天内开完。
阿捷： 为什么？
敏捷圣贤： Sprint计划会议开始的那一天，也就是Sprint开始的一天。如果Sprint计划会议跨越了两天，可不是什么好玩儿的事情，你的Burndown Chart（燃尽图）就会像我们的这样很难看（见下图）。你会看到Sprint一开始，似乎我们的工作量只有150，怎么第二天时工作量就快到了190，出现了一个凸起。如果不了解内情的话，一定还以为Sprint出了问题呢。而实际上是因为我们曾经在前一天的下午开了2小时，第二天上午又开了2小时，对任务进行细化，结果任务估算增加。
阿捷： 嗯，还有其他的吗？
敏捷圣贤： 有！可以采用Delphi方法进行任务工作量的估算。当进行任务细化的时候，每个人的估算是不一样的，如果最高估算值与最低估算值相差很多，二者就要沟通一下，看看为什么二者的理解相差这么多。沟通明白后，再重新估算。即使这样，还是会有分歧的，此时采用Delphi估算方法，简单讲就是进行一次加权平均。
阿捷： 嗯，我们以前也用过Delphi方法。
敏捷圣贤： 为了提高任务细化的效率，可以将团队分成两个小组分别进行。
阿捷： 为什么还要分组？不是让大家一起做细化、做估算的吗？
敏捷圣贤： 是这样的，我曾经带过一个团队，有10个人。最初，我都是打开投影仪，把Product Backlog投到屏幕上去，大家一边说，我一边记，我是挺忙活的，但是大家却不一定都能集中注意力。现在回头看看，这种方法真是有点蠢！当团队成员少的时候，在最初的几个Sprint，大家的兴趣还比较高的时候，这种方法还行，当Team成员超过6个的时候，问题出现了，首先是当讨论某一个问题的时候，总会有人问，刚才你们说什么来着？很显然，他走神了。另外，人多的时候，对同一个任务的细化，即使采用Delphi方法，沟通成本也很高，很费时间。
阿捷： 那你们具体怎么做的？
敏捷圣贤： 后来我就把团队分成两个小组，分别对任务进行细化。细化时，不再用投影仪，而是把Sprint Backlog中的内容按大块张贴在墙上，大家站在墙前，拿着记事帖直接进行细化和估算。当两个小组都进行完后，互相检查对方对任务的细化，解决争议，澄清模糊的地方。这样一来，就把大家的积极性调动起来，参与程度非常高，效率也高。
阿捷： 现在我们团队只有5个人，估计还用不上，但这个经验真的值得推广。
敏捷圣贤： 产品负责人（Product Owner）一定要参加。实在不能参加的话，也要指定一个人授权代理。否则，就不要开Sprint计划会议。
阿捷： 嗯，我一定会把他叫过来参加这个会议的。
敏捷圣贤： 最后一点，虽然我们采用了Scrum，但即使不再采用甘特图，但是传统的风险/依赖分析还是不要丢弃。在Sprint计划会议结束前，进行风险/依赖分析，还是会帮助我们发现一些问题的，然后再稍微调整任务的优先级，更能保证Sprint的成功。
阿捷： 好的！有了这些指导原则，我相信我们的第二个Sprint会走得更好的。
敏捷圣贤发过来一个不断眨眼的笑脸，似乎提醒阿捷不要过于乐观。
阿捷： 还有一个问题就是，我感觉这个Scrum好像只定义了一个项目管理框架，没有给出具体的编程实践指导，是你还没告诉我吗？
敏捷圣贤： 嗯，不是的。Scrum依靠的是经验管理，所以它没有涉及工程实践。这样才能很好地与不同的工程实践融合起来，譬如和CMMI、ISO 9000、RUP，甚至XP（极限编程）等都能很好地工作在一起。因为Scrum主要是解决项目管理和组织实践范畴的东西，更多的是关注在敏捷团队建设上，它的终极目标就是打造自我管理、自我组织的高效团队。作为一个敏捷框架，具体的编程实践，可以靠XP等去补充。这也是Scrum这个框架有很大适用域的原因，HR、销售、家庭教育等各个领域都可以应用它，而且也都取得过很好的效果！但我还是建议你们，最初先努力适应这个框架，待成熟后再考虑引入其他敏捷实践。
阿捷： 好的！这次我不会冒进了。
敏捷圣贤： 那就好！凡事预则立，不预则废。对形势做出良好的判断并提前做好准备还是非常有必要的。我要下了，有事咱们再联系吧。
阿捷： 多谢。再见！
敏捷圣贤： 再见！
今天的收获太大了，阿捷重拾起了Scrum的信心，准备带领TD团队再次冲刺。
1. Scrum注重的是管理和组织实践，XP关注的是编程实践，分别着重解决不同领域的问题。可以组合使用，互相补充。
2. 一条可以实行的实践原则，会比长篇大论的理论有用许多，没有实践原则指导的方法论没有意义。Scrum因为缺乏有效的编程实践，必须通过XP或其他方法来补充。
3. 使用XP，可以使Developer（开发人员）成为更好的Developer，但Scrum方法
能够迫使那些效率低的Developer变得更有效率。
4. 诺基亚的Scrum标准如下
· Scrum团队必须要有产品负责人（Product Owner），而且团队都清楚这个人是谁。
· 产品负责人必须要有产品的Backlog，其中包括团队对它进行的估算。
· 团队应该要有燃尽图，通过它了解自己的生产率。
· 在一个Sprint中，外人不能干涉团队的工作。
5. Scrum虽然强调文档、流程和管理的轻量化，但并不是意味着没有控制，没有计划，只是要做轻量的短期冲刺计划。强调的是每时每刻都要根据需求和开发情况对项目进行调整，从而达到提前交付
6. Scrum Master与传统项目经理相比，必须从传统的控制者转变为引导者。
7. Scrum中，对任务细分和时间估计，需要整个开发小组和Product Owner的参与。
8. Sprint计划会议议程，根据迭代周期长短做调整。
· 充实并讲解Product Backlog[Product Owner]（20分钟）
· 重新调整Product Backlog条目优先级[Product Owner]（5分钟）
· 设定Sprint目标[Scrum Team]（5分钟）
· 选择Product Backlog条目组成Sprint Backlog[Scrum Team]（40分钟）
· 会间休息（10分钟）
· 分成两个小组，进行任务细分，定义DONE，给出任务估算。（40分钟）
· 小组间互相评审，解决争议（20分钟）
· 关键路径分析（10分钟）
· 任务领取（10分钟）
· 风险分析（10分钟）
· 总结
那些年，我们一起踩过的坑
敏捷路上各种坑，没踩过坑，你都不好意思说自己是在做敏捷。平平安安、一帆风顺的就把敏捷落地了的，恐怕你做的是假敏捷。
阿捷他们第一个冲刺经历的那些坑，例如不按优先级选取需求、指派任务、不是集体做出估算、过程不可见等都很常见。单以站会为例，就有时间不固定、人员迟到缺席、站会坐着开、不控制时间、讨论具体细节等诸多的坑。
历经踩过的坑，从坑里爬起来，分析总结持续改进的过程，是将敏捷固化，形成肌肉记忆的过程。
踩到的坑有大有小，有时甚至需要跨越鸿沟；转型的过程也并非一帆风顺，往往伴随一段时期的效率下降；要有心理预设，要给团队，甚至于给领导打预防针。如同跑步一样，习惯的养成需要时间，在此过程中，你会历经痛苦，会有疲劳期，但坚持过去，才会脱胎换骨。回首过往，你和团队会惊诧于自己的改变，以至于无法接受再回到以前的状态，此时你的敏捷才算是初见成效。
先僵化，后固化，再优化
诺基亚的Scrum标准，是一个很典型的Checklist（检查清单）。每一个方法论，无论是Scrum、Kanban还是XP，都有一套规则，这些规则之间彼此紧密关联，背后是对敏捷原则的遵从。初识敏捷，在对原则和实践没有深刻理解的时候，建议先以一种方法论框架为基础，先僵化地遵循规则，固化沉淀到团队日常工作行为甚至工具平台上；如同敏捷圣贤所说，真正跑过三个Sprint之后，对Scrum有了一定的理解之后，再考虑是否需要根据团队和项目的真实情况，进行适度的调整和优化。
需要注意的是，优化时始终要用敏捷原则进行检查，人是有惰性的，敏捷的很多实践在某种程度上是与人的天性相违背的；敏捷需要团队自律，甚至比传统的研发模式更强调纪律；因为惰性而偷工减料的，不是优化而是简化。
XP（极限编程）
我曾经坚持认为，XP就只是工程实践，重读了肯特·贝克（Kent Beck）的《解析极限编程》才意识到，极限编程的12个实践（计划游戏、小版本、隐喻、简单设计、测试驱动、重构、结对编程、集体所有权、持续集成、每周工作40小时、现场客户、编码标准），事实上囊括了计划、迭代、设计、架构、开发、测试、集成等较为完整的研发过程；虽然名为极限编程，事实上已经不只是工程类的实践而已。肯特·贝克（Kent Beck）作为敏捷宣言排名第一（按字母排序的）的大师，果然名不虚传，XP中测试驱动、持续集成、重构、集体所有权等实践，又进一步成为持续交付的核心内容，被捷兹·休伯（Jez Humble）在《持续交付》一书中继承。
要阅读经典，这是提升自己最直接的方式，是与大师精神相遇，思维碰撞的过程；而发现这些大师经典之间内在的关联，是真正理解方法论背后逻辑与模式的过程；梳理各方法论体系，尤其是彼此之间的差异与继承关系，是形成自己独立的方法论体系的过程。
________________________
________________________
________________________