按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
敏捷圣贤：对于一个Scrum Master而言，并不一定就要自己亲自去解决问题，更关键的是你要去协调、去调度资源。
第6章 不仅仅是站立（4）
阿捷：嗯，这还差不多，吓死我了。对了，如果会议中间讨论起技术问题怎么办？上次我们也发生了这样的情况，大家争论了半天。
敏捷圣贤：呵呵，很简单，视情况而定。如果是几句话的讨论，就让它继续下去，不要刻意打断。这样解决问题的速度也快，效果会很好。如果有人说了太多的细节或者离题太远，你作为Scrum Master，完全有责任打断他们，以保证会议正常进行。需要详细讨论的，记下来，会后单独安排一个会议，专门讨论。
阿捷：OK。
敏捷圣贤：还需要提一下，Daily Scrum 的主要目的是让每个成员自己承诺要做什么，并且自己去发现进度中的障碍。原来我们只是强调了“自己去发现进度中的障碍”，而忽略了“自己承诺要做什么”。为什么要让每个成员自己承诺要做什么，而不是让Team Leader去安排呢？这个道理很简单，每个人对于自己亲口说出的事情，一定会用心去负责完成。如果事情是别人安排的，而不是自愿承诺的，那可能在积极性主动性上就会打一些折扣，就会影响事情完成的进度和质量。
阿捷：绝对赞同！
敏捷圣贤：第二指导原则：站立会议只允许“猪”说话，“鸡”不能讲话。
阿捷：猪？鸡？怎么站立会议里还有猪和鸡？什么意思啊？
敏捷圣贤：呵呵，在Scrum中，Scrum Master和团队被称为“Pigs——猪”，其他人员被称为“Chickens——鸡”，这些称谓源于这样一个笑话。
鸡说：嗨，猪！ 我想我们开一家餐厅咋样？
猪说：哦，我不知道我们卖什么？
鸡说：火腿和鸡蛋……咋样？
猪说：算了，我不这么认为，我全身投入，你却只是参与！
阿捷：哈哈！有意思，没想到Scrum中的典故还挺多！
敏捷圣贤：第三指导原则：所有人站立围成一圈，不能围坐在一个桌子周围。“站立”就暗示大家这个会会很短，强迫大家更专注和投入，还可以有效避免有人坐着收发E…mail和其他分心的事情。
阿捷：Got it。
敏捷圣贤：第四指导原则：确保整个团队都要参加每日Scrum会议。每个人，无论是开发、测试，还是文档撰写人员，只要属于“猪”，都要参加并且遵循会议规则。
阿捷：这个问题不大，我们的人都能保证参加的。
敏捷圣贤：第五指导原则：每日Scrum站立会议是团队交流会议，不是报告会议。每一与会者应该清楚，开发团队是在互相汇报和交流情况，并不是向Product Owner（Product Owner）、经理或Scrum Master汇报。
阿捷：虽然这个跟会议效率无关，但的确值得重视。
敏捷圣贤：第六指导原则：每日Scrum站立会议应该控制在15分钟之内。这个不需要多说。
敏捷圣贤：第七指导原则：不要把每日Scrum站立会议作为一天的开始。
阿捷：嗯？这是什么意思？
敏捷圣贤：如果你这么做，有些成员在开每日Scrum会议之前，不想做任何事情，这种懒惰实际上是对生产力的破坏。所以不要在上午太早时候开，避免有人从心理上把一天的开始跟这个会议联系在一起。当然，这个会议也不要太晚，一般10：00到10：30是比较适合的。
敏捷圣贤：第八指导原则：Scrum站立会议要在每日同一时间同一地点举行。这不仅可以给团队一种自己拥有站立会议的感觉，同时，任何对你们站立会议感兴趣的人，譬如Product Owner、其他项目经理或者部门经理，都可以随时走过来听一听。
阿捷：这就像宗教仪式一样。还有吗？
敏捷圣贤：在会议结束后，Scrum Master根据开发团队成员对其负责的Sprint Backlog 中的项目所做剩余时间的更新，记录在烧制图中。
阿捷：烧制图？
敏捷圣贤：英文是Sprint Burndown Chart，给你看看我们以前用Excel自动绘制的一个烧制图。
阿捷：主要用来做什么？
敏捷圣贤：它用来显示每日直至开发团队完成全部任务的剩余工作量（以小时或天计算）。理想的情况下，抛物线轨道在Sprint 的最后一天应该接触零点。有些时候会是这样，但是大多数情况不是这样。重要的是它体现了团队相对于他们的目标的实际进展情况。注意，并不是目前花费了的时间多少，这对于Scrum 来说这是不太相关的事项，而是仍剩余多少工作量——开发团队距离完成任务还有多远。如果此曲线的轨道在Sprint 末期不是趋于结束，那么开发团队应该加快速度，或简化和削减其工作内容。
阿捷：恩，这个图表确实很管用，非常直观，对项目进展一目了然。你说这个图表也可以使用Excel 表格管理？
敏捷圣贤：是的，我可以给你提供一个模板，同时管理Product Backlog、Sprint Backlog，自动生成这个Burndown Chart。但许多团队认为在他们工作室的墙上用图纸标明更为简单和有效，并可以用笔随时更新；这个技术含量不高的做法比电子表格更快速、简易，更可见。我建议你们也这样。
阿捷：好的！我想这个站立会议应该讨论得很充分了吧。那我们再讨论一下产品演示和回顾？我可不想把它们也搞砸了。
敏捷圣贤：下次再跟你讲吧！这个可比每日“立会”要讲的东西多。
阿捷：那好吧！什么时候？不要太晚啊，我想把Sprint2的产品演示和回顾做好！
敏捷圣贤：呵呵，肯定是那之前。 我也说不太好具体哪天！下个周末吧！我那会儿没那么忙。
阿捷：好！我随时在线等你！ 886！
敏捷圣贤：886！
阿捷决定按照敏捷圣贤的建议整理一个Daily Scrum的规则。于是趁着脑子里的“东西”还在，打开自己的Blog，写下了下面的文字。
第7章 镜子反射（1）
Using a bronze mirror； we can exam how we dress； Studying history； we can understand why there were rises and falls of powers； Observing other people's success and failure； we will know what to and what not to do。
以铜为镜，可以正衣冠；以古为镜，可以知兴替；以人为镜，可以明得失。
——魏征
周二，阿捷召开了第二个Sprint计划会议，上午用了两个小时，下午用了三个小时。因为事先准备充分，效果好多了，大家的心气又给聚起来了！因为周一阿捷跟李沙一起，用Excel重新整理了一份Product Backlog； 不仅列出了所有的用户故事，还让李沙对它们进行了优先级排序。并且在周一下午，阿捷还按照敏捷圣贤的建议，提前把计划会议日程发给大家，让大家能有所准备。
阿捷按照早就想好的规则，对每日站立会议进行了改进后，每天平均只花12分钟就能结束了！不仅仅大家相互沟通了信息，问题得到了及时解决，而且效率高多了，大家都很满意。
到了周末的晚上，阿捷在网上再次遇到敏捷圣贤，阿捷决定再向他请教一下如何开好Sprint评审会议和回顾会议。
阿捷：嗨！你好！
敏捷圣贤：你好！看起来心情不错！
阿捷：是啊！在当前的这个Sprint，我们的计划会议开得非常好，不仅请了Product Owner，还让他起草了最新的Product Backlog，而且对Sprint中每个细化的任务，给出了大家一致认同的“DONE”的定义。同时，按照你的指导原则，我们对Scrum每日站立会议做了改进。现在，每个人都总结性地回答四个问题，这样我们差不多12分钟左右就能结束会议，效率比以前高多了！
敏捷圣贤：恭喜你们！
阿捷：谢谢！这次多亏了你的建议呢。我们上次说要讨论一下Sprint的演示与回顾，还记得吗？
敏捷圣贤：嗯，当然记得。作为Scrum Master，回顾并总结一个刚结束的Sprint所做的工作，是非常有价值的，这就像镜子反射！
阿捷：镜子反射？
敏捷圣贤：对，每个人出门前都要照镜子，目的是什么？
阿捷：呵呵，我不照镜子的。
敏捷圣贤：别捣乱。目的有二：一是看看自己穿的衣服怎么样，化的妆怎么样，是不是又漂亮了；二是看看哪些方面还需要修整（如衣服的扣子扣得是否合适、穿的衣服是否合体，等等），以更利于展示自己最漂亮的一面。
阿捷暗想，这哥们儿真够逗的，还说化妆呢，难道还真的每天出门前照镜子？因为还不够熟悉，阿捷没表露出来，接着回复道：你的意思是作为一个团队，也应学会“照镜子”，要时时发扬自己的优点，找到自己的不足，及时加以改正。
敏捷圣贤：对！孺子可教也。
阿捷：不过，我有这样一个疑问！发生的已经发生了，都已经过去了！如果说一个团队，刚刚结束一次快跑地话，每个人都很累，为什么非要揭开旧伤疤？让大家再次痛苦呢？
敏捷圣贤：暂时的痛苦可以让你在未来的日子里过得更好，避免犯同样的错误。让我们先来看看演示。你是怎么理解的？
阿捷：我看了一些资料，在Scrum中，演示是说在一个Sprint 结束以后，进行Sprint 评审，团队在此期间展示他们所完成的工作、可运行的软件。出席此会议的有Product Owner、开发团队、ScrumMaster，加上客户、项目管理者、专家、高层人士等任何对此感兴趣的人。
第7章 镜子反射（2）
敏捷圣贤：不错，还有吗？
阿捷：会议可以持续10 分钟，也可以持续两个小时。因为会议目的只是对所做工作结果的展示，并听取反馈 。
敏捷圣贤：嗯，说得挺全面的
阿捷：我还是不想让我的团队，在Sprint快结束的时候花很多时间到演示上，实际上，他们可以做很多真正有意义的事情。为什么我们要浪费力气演示我们刚刚做过的工作？我们的目标不就是一个可以随时交付的软件吗？我们的目标已经完成了，就摆在那里。谁感兴趣，看看我们的Sprint Backlog就可以了啊。
敏捷圣贤：这是一种常见的误解。其实呢，演示主要是出于这样几个目的：
？ 演示可以让利益相关者虽然不直接参与Sprint，但可以获得第一手关于你们这个团队最新进展的印象。这里虽然提到利益相关者，其实你可以随意邀请任何没有直接参与Sprint工作的人。
？ 演示可以让客户或者Product Owner对你们所做的工作提供最直接的反馈，这样可以让Scrum团队，根据优先级更新产品Backlog，在下一个Sprint中融入最新的需求变化，并将这些反馈带到下一个Sprint的规划会议上。
？ 同时，演示是一个很好的机会，可以让团队庆祝他们在过去的Sprint中所取得的成就。看到可以工作的软件，可以真正鼓舞团队的士气。
阿捷：嗯，听上去好处多多。但准备一个演示，是要花费很多时间的。
敏捷圣贤：其实，你们不需要准备一个非常华丽的演示，只需要展示你们刚刚完成的最新功能即可。不需要额外修饰，只要让人印象深刻，就已经足够了。总之，这不是一个产品发布会，你不需要创造一个非常炫目的演示。
阿捷：但是，如果某些小组成员的工作不能直接通过软件演示怎么办？他们会感觉被排除在演示之外的。
敏捷圣贤：不要仅仅从字面上理解“演示”这两个字，范畴可以更广一些。这里的“演示”，还可以是对下列事情的回顾：如一个新建的wiki网页、某人新写的小工具、一份说明文档或其他任何具体的可以让该团队感觉到有价值的东西！
阿捷：嗯，这样就好办多了。我还担心如果涉及性能测试怎么办呢。看来我们只需要把我们做的性能测试对比结果展示给参加人员就可以了。
敏捷圣贤：非常正确，加十分！ 据我的经验，演示要安排在Sprint回顾会议之前。此外，更重要的是要让这个演示会议充满乐趣，不能搞成批斗会。
阿捷：我想我们可以准备一点小食品、饮料什么的，把它搞成一个庆祝会议，这应该是一个团队建设的好机会。
敏捷圣贤：非常好的想法。记得在每个人做完演示后，都让大家集体鼓掌庆祝。
阿捷：好的，我想我们会开好Sprint 评审会议，做好演示的。那么回顾呢？它的主要价值是什么？
敏捷圣贤：嗯，先不着急！你听说过印第安人灵魂的故事吗？
阿捷：啊，印第安人？灵魂？是个什么样的故事？恐怖吗？
敏捷圣贤：呵呵，又不是给你讲鬼故事，你怕什么？是这样的，从前，有个古老的传说，讲的是当印第安人在赶了3天路后，就会停下来小憩一天，因为他要等着自己的灵魂跟上来。这跟敏捷开发在经历了一次迭代或者冲刺（Sprint）后，也需要休整，是一个意思。我们也需要等待团队的灵魂跟上来，这一过程被称之为“敏捷回顾（Agile Retrospectives）”。如果将项目开发比作是一次征途，那么在项目中期进行短期休整是很有必要的。
第7章 镜子反射（3）
阿捷：我知道了！就是将团队成员集体拉出去*一次，或者K歌去，或者爬山、郊游去，目的是让大家放松一下。 我们现在每个月都有一次这样的活动，大家都很Enjoy的。
敏捷圣贤：这些是可以的，但不是必要的，因为这些都只能带来身体的休息与放松。
阿捷：这不是最重要的吗？那还有什么别的？
敏捷圣贤：你看很多运动员在比赛间歇期，会有队医给他按摩，有人帮他擦汗，有人给他喝饮料解渴。这些重要吗？当然重要，这的确可以让他们放松疲惫的身体，保持充沛的体力，通过短暂休整获得能量。但更重要的是灵魂的“反刍”，需要教练员针对其在上一局比赛的表现，给出盘点，分析他及对手的优与劣，给出具体战术指导，帮助制定出针对后面比赛的对策，方能最终击败对手，赢得比赛。
阿捷：嗯。
敏捷圣贤：Sprint回顾会议与平常我们经常提到的项目总结会议不同，它不是要对项目进行盖棺定论，而是通过及时回顾，总结上一次快跑中的得与失，找到改善与提高的办法，从而让下一个Sprint走得更好。
阿捷：那该怎么做Sprint回顾呢？
敏捷圣贤：也很简单，关注两点就可以了。第一点是找出在上一个Sprint中做得好的地方，并继续保持。分析那些导致成功的流程是非常重要的，这样我们才能有意识地保持下去。只有团队中的每一个成员都清楚什么才是最佳实践，才能有效地鼓励和保持这些实践。除了可以鼓舞士气外，还可以避免把回顾会议变成消极的抱怨会议。第二点是找出上一个Sprint中需要改进的地方，以及对应的改进措施。回顾的目标就是持续不断地改进，这也是敏捷开发的主要理念之一。让我们想一想如何才能在下一个Sprint中更加有效率，想一想在哪些方面如何做才能跟上一个Sprint不同。可以收集任何可以量化的数据，以便于做定量分析，推动改善。
阿捷： 还有其他一些什么事情是要特别注意的？
敏捷圣贤：首先，一定要明确这样一个最高指导原则。即“无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴”。
阿捷：啊哈！听起来，就是“和稀泥”的做法啊！这样的原则应该会让回顾会议的参与者都变成好好先生的。难道我们一定要善意地评价团队中的害群之马，对他们的过错视而不见，使其“逍遥法外”，并天真地以为我们的好心能够感化他们？难道我们要在项目开发中建立一个乌托邦式的大同世界，同薪同酬，为了团队利益而抹煞团队成员之间的个体差异？
敏捷圣贤：对团队成员的绩效评估，当然不能采用这样的指导原则。我们现在谈论的是Sprint回顾，回顾的最终目的是学习，而不是审判。如果敏捷回顾没有确定这样的“指导原则”，倡议团队成员信任自己的伙伴，就会让回顾会议成为互相攻讦、互相推诿的批斗大会，脱离了我们召开回顾会议的初衷。
阿捷：嗯。
敏捷圣贤：“指导原则”就是为回顾会议竖立一个标杆，那就是在项目开发中没有破坏者，没有替罪羊，没有关键人物，只有整个团队的利益。虽然某个人或许在上一次迭代中出现了错误，但我们会善意地相信此人之所以犯下错误，并非有意为之或者消极怠工，而是囿于当时之识见、经验、技能。我们的回顾会议必须指明这些错误，并试图总结出最佳实践以避免在下一次迭代中犯下同样的错误，而“指导原则”则能够消除因为错误的指出而给成员带来的负疚感，消除同事之间可能因此出现的隔阂与误解。换句话说，回顾会议提出的所有批评都应该“对事不对人”。
阿捷：嗯，这一点的确很重要！我们以前开项目总结会议时，总被美国同事揪小辫子，搞得大家都很不舒服！谁会是真的想故意捣蛋呢？
敏捷圣贤：是啊！人们总是容易犯常识性的错误。
阿捷：有什么好的方法来组织这个回顾会议？你上次给了我如何开好Daily Scrum站立会议的8个指导原则，对我帮助非常非常大！
敏捷圣贤：其实，组织Sprint 回顾的最简单方法是找个白板纸，在上面注明“哪些项工作顺利”，“哪些项不成功”或者“哪些项可以做得更好”，然后让与会者在每一类别下增加一些条目。当条目重复时，可以在该项旁边计正字累计，这样普遍出现的项目就一目了然了。最后团队成员共同讨论，找寻这些条目出现的根本原因，就如何在下一个 Sprint 中改进达成一致意见。
阿捷：嗯，很简单很直观。
敏捷圣贤：张瑞敏不是说“能够把简单的事情天天做好，就是不简单！”吗？其实，敏捷回顾的主要工作就是明确目标、持续改进、处理问题。敏捷开发之所以采用迭代的方