敏捷无敌-第11部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！

　　敏捷圣贤：别捣乱。目的有二：一是看看自己穿的衣服怎么样，化的妆怎么样，是不是又漂亮了；二是看看哪些方面还需要修整（如衣服的扣子扣得是否合适、穿的衣服是否合体，等等），以更利于展示自己最漂亮的一面。
　　阿捷暗想，这哥们儿真够逗的，还说化妆呢，难道还真的每天出门前照镜子？因为还不够熟悉，阿捷没表露出来，接着回复道：你的意思是作为一个团队，也应学会“照镜子”，要时时发扬自己的优点，找到自己的不足，及时加以改正。
　　敏捷圣贤：对！孺子可教也。
　　阿捷：不过，我有这样一个疑问！发生的已经发生了，都已经过去了！如果说一个团队，刚刚结束一次快跑地话，每个人都很累，为什么非要揭开旧伤疤？让大家再次痛苦呢？
　　敏捷圣贤：暂时的痛苦可以让你在未来的日子里过得更好，避免犯同样的错误。让我们先来看看演示。你是怎么理解的？
　　阿捷：我看了一些资料，在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　中改进达成一致意见。
　　阿捷：嗯，很简单很直观。
　　敏捷圣贤：张瑞敏不是说“能够把简单的事情天天做好，就是不简单！”吗？其实，敏捷回顾的主要工作就是明确目标、持续改进、处理问题。敏捷开发之所以采用迭代的方式，实际上是利用蚕食方式逐步完成开发任务。将一个宏伟的目标切割为一个个小目标，会给予团队成员更大的信心，并且能够更加清晰地明确目标。而每次迭代后的回顾，则使得团队成员可以更加清晰地明确我们在这个征途中，已经走到了哪里，未来还有多远的路程，就像印第安人那样，等待自己的灵魂，否则就会不知身在何处了。
　　阿捷：嗯，我们一定会重视敏捷回顾会议的，我相信一定会从中得到意想不到的收获。
　　敏捷圣贤：嘻嘻……我这个老师还不错吧？
　　阿捷：那当然。你怎么发了个嘻嘻？怎么跟MM似的？
　　敏捷圣贤发过来一个鬼脸，外加一个886，就下线了。阿捷自己寻思，这人真怪，说话怎么神神道道的，难道世外高人都这样？阿捷没有多想，还是赶紧总结一下的好，能够跟高人过招并从中学习是多么宝贵的一次经历啊！阿捷把总结写入自己的Blog后，才放心地去睡觉。
　　　电子书　分享网站

第8章　我烧，我烧，我烧烧（1）
Attained　with　more　support；　and　enjoys　little　support。
　　得道者多助，失道者寡助。
　　——《孟子》
　　这天上午，阿捷他们正在开Daily　Scrum站立会议，老板Charles走了过来！似乎有什么事情，但为了保证自己团队的站立会议不受外人的打扰，阿捷仅仅礼貌性地点了点头，示意大家继续。
　　阿捷暗想，根据Scrum规则，我们正在开会的这些人，都是真正参与到当前这个Sprint的人，都是有mitment的！换句话说，我们都是“猪”，而其他人只能是旁听者，充其量就是“鸡”了。所以即使是老板来，也不能破坏这个规则。作为一个团队的Scrum　Master，要真正承担起“牧羊犬”的角色，要保护自己的团队不受外来打扰。没办法，即使你是老板，在这会儿，你也得到一旁凉快去！
　　Charles也还识趣，不仅没有打断大家，还饶有兴趣地站在一旁听起来。看到老板没有打断大家，阿捷不禁得意起来。
　　还好，今天的会议只花了8分钟，因为项目进行得很顺利，大家也没有提出任何阻碍团队向前快跑的问题。也就不需要在每人说完后，再单独开一个解决问题的短会了。
　　“你们现在是每天都开这个会议吗？”还未等阿捷开口，老板已经率先发问了，很显然，憋了这么半天，对于一直强势的Charles来说，还是从来没有的事情。
　　“嗯，是啊！这样我们能够随时地沟通，及时地解决问题。”阿捷有点忐忑不安，不知道老板葫芦里面卖的什么药。
　　“这是你自己的感觉呢？还是大家的？”
　　“我们大家都这么认为的！”
　　“你们白板上画的图是作什么用的？”老板指着那个Burndown　Chart问。
　　“这个叫Burndown　Chart，也就是烧制图。是Scrum里面，用来跟踪每个Sprint剩余工作量及趋势的。”
　　“哦？也就是说，你们现在真的在搞Scrum？”老板的话锋突然一转。
　　“是！”看来没有不透风的墙，自己是准备先斩后奏的，这还没奏呢，老板就主动来了。阿捷刚刚放下的心又给提起来了，不知道老板什么意图，没敢接下茬。
　　“尝试新东西，总是好的。但一定要有结果、有效果才行。”老板向来都是以结果为导向的。
　　“嗯”，阿捷唯唯诺诺，刚才开站立会议时，说啥也不搭理老板的那股子劲头早被抛到九霄云外了。
　　“好吧，我今天正好还有点儿时间，你就给我讲讲这个BurnDown　Chart吧！”看来老板没有在责备的味道，还对Scrum饶有兴趣，阿捷顿时又来了精神头儿。
　　“Burndown图（Burn　Down　Chart），用来展示剩余待完成工作与时间关系的图形化表达方式。你看，未完成工作（或称为Backlog）标识在纵坐标轴上，时间标识在横坐标轴上。可用其协助预测项目所有的工作何时完成。”
　　“理想的情况下，抛物线轨道在Sprint　的最后一天应该接触零点。有些时候会是这样，但是大多数情况不是这样。重要的是它体现了团队在相对于他们的目标的实际进展情况——并不是目前花费了的时间的多少，而是仍剩余多少工作量——开发团队仍距离完成任务多远。如果此曲线的轨道在Sprint末期不是趋于结束，那么开发团队应该加快速度，或简化和削减其工作内容。此图表也可以使用Excel　表格管理，我们认为在我们在白板上用图纸标明更为简单和有效，并且可以用笔随时更新；这个技术含量不高的做法比电子表格更快速更简易、更可见。”

第8章　我烧，我烧，我烧烧（2）
“嗯，你怎么知道每天剩余多少工作量？”
　　“每天下班前，要求大家对自己负责的任务，给出一个还需要多长时间才能完成的估算。然后，把所的任务的最新估算值，累加起来，就是每天的剩余多少工作量了。譬如，截至今天，我们还需要170小时，那我们就在这个图上170左右的位置标注了一个点，用直线跟昨天的剩余多少工作量点连起来。时间一久，这个实际烧制曲线就出来了。”
　　“我一开始还以为你在这里记录的是你们实际花了多少时间呢！”Charles自嘲道。
　　“不是，在Scrum中，不关心实际花的时间，不想做Time　Tracker。从另外一个意义上讲，这体现的是一种信任，相信每一个人都会尽心尽力地做好自己的本职工作。如果我们Check到这么细的话，就会引入微观管理，不仅会花费更多的