下载掌阅APP，畅读海量书库
立即打开
根据敏捷圣贤的建议，如果想真正做好Scrum，就必须有专门的Product Owner负责维护Product Backlog，这事得赶紧解决，否则，以后的Sprint Planning会议不仅开不好，而且每个Sprint肯定又问题多多。阿捷想了想，这事只有李沙最合适。李沙是负责Agile国内OSS产品的Product Manager，阿捷决定请他出山担任Product Owner。
李沙个子有1.85米高，四方脸，稍微有点瘦，是个典型的东北大汉，平时总是西装革履。因为同在公司篮球队里，大家经常一起打球，所以关系一直不错。
阿捷决定找他聊聊。
“Hi，忙着呢？”阿捷走到李沙的格子间，李沙正在看体育新闻，没注意到阿捷过来。
李沙转过身来，笑了笑：“还行，你看这不火箭队又赢了，国内的这帮人把姚明给吹的，不就是一个两双嘛！当家中锋你就得这个数据才行！”
“胜者王侯败者寇！趁着赢球赶紧吹吹，也是有道理的。”
“嗯，对了。这周末的中智杯去不去？听说对手是双鹤药业。”
“去啊！没我哪成啊，你还不全靠我给你喂球呢。”
“好！打完球咱们涮肉去。对了！哥们儿，今天是不是有啥事？”
“有点小事儿。你现在不忙吧？”
“不忙，都周末了。说吧。”
“嗯，是这么回事”，阿捷把自己团队要搞Scrum的事情介绍了一下，然后引到请李沙出任Product Owner的事情上来。
“噢，听起来你们这个流程似乎比原来的要灵活很多。我很愿意做这个事情，这样我们也能更好更及时地合作。可问题是我该做些什么呢？”
“首先，你要帮我们维护一个叫Product Backlog的东西。是我们所需要做的所有事情的高层次的列表，按照优先级排列起来。”
“你的意思是说把用户需求文档中的东西换一个形式？”
“嗯，差不多。原来我们用的需求文档太复杂了，有几百页。我们现在讨论到的Product Backlog是一个需求列表，可以组织得非常简单，既包括已经定下来的需求，也要包括那些还不清晰的需求。具体你可以用Excel，或者Word也行，看你用什么方便了！关键在于要方便修改、增删条目，以便于随时调整优先级。第一次，我可以帮你做一个初始版本。”
“那我们还是用Excel好了！”
“嗯，我也建议这样。我们现在计划每3周为一个Sprint。那么你要根据实际情况随时修改这些内容：如增加新需求，修改已有需求，一定要实时，而且这些修改都要在下一次Sprint计划会议之前完成。这样，才能确保我们团队总是根据你排定的条目优先级，去处理最重要的需求。”
“没问题！”
“我们以后就将以这个文档跟你一起确认详细的需求。如果产生疑问，你得随时解释需求。如果我们做完了，你要帮我们把关，看看是不是你最初所要求的。”
“这些都是我本来就应该做的，除了维护这个Product Backlog外，流程上还需要我做什么？”
“参加两个会议：Sprint计划会议和Sprint评审会议。Sprint计划会议可能会占用很多时间，估计得大半天吧。Sprint评审会议应该比较简单，估计半小时或者一小时就够了。”
李沙皱了皱眉头：“哦？Sprint计划会议要这么久？我可不可以不参加？我保证开会之前把最新的Product Backlog给你。”
“那可不行！这个会议是我们最重要的会议，计划会议开不好，接下来的三周都不会有好日子过的。你要是不能参加，我们这个会议就不能开，也就不能按照这个Scrum流程做事情了！”
“哈哈，这样我不成了你们团队的人了！”
“其实，这是最能展现你的个人魅力的时候了！你看，你说做什么，我们整个团队接下来就得做什么。具体做什么你完全说了算，还不好？外人要是不懂，还以为你是我们组的经理呢。”阿捷尽量把话题搞得轻松些。
李沙笑了笑，拍了拍阿捷的肩膀，“兄弟，你现在行啊！什么事情都能说得这么好听。你们这个Sprint计划会议到底做些什么？我去做什么？”
“简单讲，Sprint计划会议的第一部分，你和我们共同过一遍Product Backlog，陈述Backlog中各条目的目标和背景，并回答开发团队的问题，以便团队成员深入了解你的想法或需求。我们开发团队会从Product Backlog中挑选条目，并承诺在Sprint结束时完成。我们会从你给出的具有最高优先级的条目开始，并按列表顺序依次工作。也就是选择‘What to Do’（做什么），所以你给出的优先级至关重要！在会议的第二部分，我们会针对选择出来的需求项，进行任务拆解及认领，决定如何做、谁去做。也就是How to Do’（如何做）和‘Who to DO’（谁来做）的过程。”
“这样看来，第一部分我参加还有一定的必要性，第二部分似乎意义不大！”
“不，也很重要！我们会详细讨论如何做，做到什么程度，如何演示等，也就是我们给出一个DONE（完成）的标准，这样，在Sprint评审会议上，我们做演示时，你可以根据DONE的定义来评定我们是否真正完成了！而且，我们在细化任务时，还会和你澄清一些问题的！所以你最好要全程参加才行。”
“噢，可我的老板那么久看不到我，没准会有意见的。”
“嘿嘿，兄弟，谁不知道你现在直接汇报给老美呀！咱们上班，人家还没上班呢！再说了，计划会议三周才一次。而且，在会议上，我们没有问题的时候，你也可以上网、发邮件、写文档的！我们需要你一直陪着的目的，就是想一旦有问题，能随时找到你！”
“嗯”，李沙迟疑了一下，“那好吧，看在你的面子上，我克服一下。”
阿捷用力捶了李沙一下，“够哥们儿！不过，得跟你事先声明一下啊，如果我们确定下来一个Sprint中要做的事情后，在此Sprint期间，就不可以添加新的需求或者变更需求。你要想添加新要求，只能等下一个新的Sprint，也就是三周后。”
“这没关系，以前几个月的事也都没变过，不怕！”李沙回答得非常干脆。
“好！那就这么定了！我下周一过来跟你一起搞出来第一版的Product Backlog。”
“好，那周末篮球场见。”
晚上，阿捷登录MSN，准备向敏捷圣贤咨询一下每日Scrum站立会议，因为阿捷他们在这个站立会议上花费了很多时间。不但效率不高，而且大家意见很多。可惜敏捷圣贤并不在线，阿捷只好到抓虾网看看自己订制的博客文章。
不知多久，突然觉得屏幕一震，一个MSN窗口弹了出来，敏捷圣贤上线了。
敏捷圣贤： Hi，阿捷。
阿捷： 你好！圣贤。
敏捷圣贤： 我们继续谈谈你们上一次Sprint的经历吧。我记得你说每日Scrum“立会”平均要花40～50分钟，对吧？
阿捷： 是的。在每日“立会”上，前几天大家还能按时来，注意力集中，并尽量更新足够多的相关内容。但后来说的事情会不着边际，而且时间太长。最后几天，大家因为忙，对这个立会的关注度和重视程度明显下降。
敏捷圣贤： 没准儿你应该换一个思路。
阿捷眼睛一亮，马上回复道：是不是可以通过邮件来代替？
敏捷圣贤： 绝对不可以！邮件不能取代每日Scrum会议。邮件只会增加沟通成本，而且不能提供细节信息或者给他人提问的机会，也不能帮助其他成员解决问题。
阿捷： 可不可以不开立会？我们都觉得每天开会意义不大！
敏捷圣贤： 这个“立会”不仅能要让每个人了解其他人在做什么，当前项目计划进展如何，还可以帮助大家解决那些阻碍，以及共享承诺。其实，这些都是非常有利于提高团队合作精神的。
阿捷： 噢，可我们每天花这么长的时间开会，影响工作效率。有什么可以使会议保持紧凑有效的小窍门吗？
敏捷圣贤： 窍门和经验有很多，我自己总结了8条，想听吗？
阿捷： 好啊，等着你传授给我呢。
敏捷圣贤： 第一指导原则：主题明确，不能掺杂其他无关的话题。要做到这一点很简单，只需要保证每个人只回答3个问题，就行了。
阿捷： 都是什么问题？
敏捷圣贤： “我们上次开会后你都干了什么？”，这可以让整个团队了解该成员在做什么，以及当前进展，但也不要过分详细，否则会使大部分人失去耐心。
阿捷： 嗯，我们的立会上有人说“和上次一样”，也有人说“我正在改一个bug”。看来也是不对的。
敏捷圣贤： 是的，“细节决定成败”，这里一定要关注一下细节才行。有时会让大家更新一下是“你负责的、正在做的任务还剩下多少时间”。
阿捷： 这个我们忽略了。
敏捷圣贤： 有些团队的站立会议并不涉及这个话题，是因为他们用单独的工具软件跟踪剩余工作量。对于你们，如果没有让每个成员在会前主动更新你那个Excel表格的话，就需要在会议上给出最新估算。在Scrum下，每天重新做任务估算是非常重要的。这样，才会知道你们还有多少剩余工作量，在剩余的时间内能否完成。如果你们估计不足，觉得不能完成，那么就要及时调整计划。
阿捷： 看来，如果我们坚持下去的话，也有必要采用一个专门的工具。你说的调整，是什么概念？是把完不成的任务拿出去吗？
敏捷圣贤： 这是一个思路，另外就是坚决地结束当前Sprint，重新开始下一个Sprint。但无论如何，这事都要事先跟Product Owner打招呼，让他知道你们的最新决定。
阿捷： 好的，第二个问题是什么？
敏捷圣贤： “在我们下次开会之前你要做什么？”，当成员间的工作有依赖关系时，这会给其他成员一个很好的提醒。
阿捷： 就是自己给自己设定当天的目标。
敏捷圣贤： 嗯，最后一个问题是“你的开发被阻碍了吗？”这个问题最重要。阻碍一个人继续开发的问题，最终也会阻碍整个开发团队，所以一定要鼓励大家说出自己的问题。一旦有人提出来，作为Scrum Master，你有义务帮助他尽可能地消除这些障碍。
阿捷： 啊？有些技术问题，如果开发人员都解决不了，我更不可能解决的。我可不是什么技术专家。
敏捷圣贤： 对于一个Scrum Master而言，并不一定要自己亲自去解决问题，更关键的是你要去协调、去调度资源。
阿捷： 嗯，这还差不多，吓死我了。对了，如果会议中间讨论起技术问题怎么办？上次我们也发生了这样的情况，大家争论了半天。
敏捷圣贤： 很简单，视情况而定。如果是几句话的讨论，就让它继续下去，不要刻意打断。这样解决问题的速度也快，效果会很好。如果有人说了太多的细节或者离题太远，你作为Scrum Master，有责任打断他们，以保证会议正常进行。需要详细讨论的，记下来，会后单独安排一个会议，专门讨论，我通常把这个环节称为After Meeting（会后环节）。
阿捷： OK。
敏捷圣贤： 还需要提一下，Daily Scrum（每日立会）的主要目的是让每个成员自己去发现进度中的障碍，从而达成自己的承诺。原来我们只是强调了“自己去发现进度中的障碍”，而忽略了“自己承诺要做什么”。之前计划会上，我一直强调要让每个成员自己认领任务。为什么要让每个成员自己认领呢，不是让团队负责人去安排呢？这个道理很简单。每个人对于自己认领的事情，一定会用心去负责完成。如果事情是别人安排的，而不是自愿承诺的，那可能在积极性主动性上会打一些折扣，就会影响事情完成的进度和质量。
阿捷： 绝对赞同！
敏捷圣贤： 第二指导原则：站立会议只允许“猪”说话，“鸡”不能讲话。
阿捷： 猪？鸡？怎么站立会议里还有猪和鸡？什么意思啊？
敏捷圣贤： 在Scrum中，Product Owner，Scrum Master和团队被称为“Pigs，猪”，其他人员被称为“Chickens，鸡”，这些称谓源于这样一个笑话。
鸡说：嗨，猪！你看最近一直提“大众创业、万众创新”，咱们也创业吧！
猪说：好啊！但咱们干点啥呢？
鸡说：我想我们开一家餐厅咋样？
猪说：哦，我不知道我们卖什么？
鸡说：火腿夹鸡蛋……咋样？
猪说：算了，我不这么认为，我全心投入，你却只是参与！
鸡说：为啥呢？这点子是我想的，我咋就不全心投入了呢？
猪说：你看啊！火腿必须要我把自己的腿砍下来，才能做成。而鸡蛋呢，只是你的附属品，你没有任何损失。不是全心投入。
鸡说：……
猪说：……
阿捷： 哈哈！有意思，没想到Scrum中的典故还挺多！
敏捷圣贤： 第三指导原则：所有人站立围成一圈，不能围坐在一个桌子周围。“站立”就暗示大家这个会很短，强迫大家更专注和投入，还可以有效避免有人坐着收发邮件和做其他分心的事情。
阿捷： Got it（收到）。
敏捷圣贤： 第四指导原则：确保整个团队都要参加每日站立会议。每个人，无论是开发、测试，还是文档撰写人员，只要属于“猪”，都要参加并且遵循会议规则。
阿捷： 这个问题不大，我们的人都能保证参加的。
敏捷圣贤： 第五指导原则：每日Scrum站立会议是团队交流会议，不是报告会议。每一与会者应该清楚，开发团队是在互相汇报和交流情况，并不是向ProductOwner或Scrum Master汇报。
阿捷： 虽然这个跟会议效率无关，但的确值得重视。
敏捷圣贤： 第六指导原则：每日Scrum站立会议应该控制在15分钟之内，你们如果可以在8分钟内搞定，那就立刻结束，不一定要用满15分钟，这才叫 Timeboxing（时间盒）。这个不需要多说。
敏捷圣贤： 第七指导原则：不要把每日Scrum站立会议作为一天的开始。
阿捷： 嗯？这是什么意思？
敏捷圣贤： 如果你这么做，有些成员在每日Scrum会议之前，不想做任何事情，这种懒惰实际上是对生产力的破坏。所以不要在上午太早时候开，避免有人从心理上把一天的开始跟这个会议联系在一起。当然，这个会议也不要太晚，一般10：00到10：30是比较适合的。
敏捷圣贤： 第八指导原则：Scrum站立会议要在每日同一时间同一地点举行。这不仅可以给团队一种自己拥有站立会议的感觉，同时，任何对你们站立会议感兴趣的人，譬如其他项目经理或者部门经理、或者上下游团队内的任何人，都可以随时走过来听一听。
阿捷： 这就像宗教仪式一样。还有吗？
敏捷圣贤： 在会议结束后，Scrum Master根据开发团队成员对其负责的Sprint Backlog 中的项目所做剩余时间的更新，记录在燃尽图中。
阿捷： 燃尽图？你之前好像提到过。
敏捷圣贤： 英文是Sprint Burndown Chart（冲刺燃尽图），给你看看我们以前用Excel自动绘制的一个燃尽图。
阿捷： 主要用来做什么？
敏捷圣贤： 用于显示每日直至开发团队完成全部任务的剩余工作量（以小时或天计算）。理想的情况下，该曲线应该在Sprint 的最后一天接触零点，它体现了团队任务目标的实际进展情况。注意，并不是目前已经花费了多少时间，而是仍剩余多少工作量 —— 开发团队距离完成任务还有多远。如果此曲线在Sprint 末期不是趋于零，那么开发团队应该加快速度，或简化和削减其工作内容。
阿捷： 嗯，这个图表确实很管用，非常直观，对项目进展一目了然。你说这个图表也可以使用Excel 表格管理？
敏捷圣贤： 是的，我可以给你提供一个模板，同时管理Product Backlog、Sprint Backlog，并自动生成这个燃尽图。但许多团队认为在墙上用图纸标明更为简单有效，可以用笔随时更新；这个技术含量不高的做法比电子表格更快速、简易，更可见。我建议你们也这样。
阿捷： 好的！我想这次站立会议应该讨论得很充分了吧。那您再给我讲一下产品演示和回顾？我可不想把它们也搞砸了。
敏捷圣贤： 下次再跟你讲吧！这个可比每日“立会”要讲的东西多。
阿捷： 那好吧！什么时候？不要太晚啊，我想把Sprint 2的产品演示和回顾做好！
敏捷圣贤： 肯定是那之前。我也说不太好具体哪天！下个周末吧！我那会儿没那么忙。
阿捷： 好！我随时在线等你！再见！
敏捷圣贤： 再见！
1. 每日立会上，每个人需要回答三个问题：昨天完成什么？今天打算做什么？有什么障碍？如果没有更新剩余工作量，在会上给出最新估算。
2. Scrum团队强调自我管理，自我引导，这其实是管理的最高境界，如果团队里面的每个人都能够时刻关注公司或者部门的业务情况，那么整个公司的利益自然会最大化，但是现实往往不是这样的。那么设立Scrum Master时，是不是可以让每个人在每个Sprint里都有这样的机会来带领团队，并感受这种责任。
3. 让每日站立会议保持紧凑有效的指导原则。
· 第一指导原则：主题明确，不要讨论其他无关的话题。
· 第二指导原则：站立会议只允许“猪”说话，“鸡”不能讲话。
· 第三指导原则：所有人站立围成一圈，不能围坐在一个桌子周围。
· 第四指导原则：确保整个团队成员都要参加每日Scrum会议。
· 第五指导原则：每日Scrum站立会议是团队交流会议，不是报告会议。
· 第六指导原则：每日Scrum站立会议应该控制在15分钟之内。
· 第七指导原则：不要把每日Scrum站立会议作为一天的开始。
· 第八指导原则：Scrum站立会议要在每日同一时间、同一地点举行。
4. Scrum Master要及时解决每日立会上提出的阻碍。这一点非常关键，否则会影响每个成员反应障碍的积极性。
5. 利用Burndown Chart（燃尽图）跟踪细分任务的完成情况，在项目进程的任何时间点都能够看到项目进展状况，而不是每周或者项目完成之后，从而保证了开发进度处于可控制的状态。
仪式感
《小王子》中，狐狸对小王子说：“你每天最好在相同的时间来……我们需要仪式。”
“仪式是什么？”小王子说。
“这也是经常被遗忘的事情，”狐狸说，“它使得某个日子区别于其他日子，某个时刻不同于其他时刻。”
“Scrum站立会议要在每日同一时间同一地点举行”，也是仪式感的体现。心理学家荣格说：正常的身心需要一定的仪式感。仪式感体现的是我们的尊重和热爱，对生活如此，对团队如此，对敏捷也是如此。
在敏捷中，我们有很多表现仪式感的实践，例如庆祝迭代成功发布，给团队成员写感谢卡，团队建设等。
仪式感不仅表现在成功时，也应该表现在失败或出错时。例如即使是迭代失败，集体跑步5公里；站会迟到时，给团队小伙伴发红包；造成持续集成服务器失败时，做俯卧撑等。失败时，我们不是惩罚，而是用游戏的方式来让大家牢记于心。
此外，除了庆祝成功，对于失败，也需要庆祝；如果把成功或失败，看成是反馈与学习的机会，那么，失败时，也许是更好的学习机会。
每日站立会议
每日站立会议是整个Scrum框架里，非常重要的一环，站会的重要性，以及正确方式，却往往容易被忽视；
敏捷宣言强调个体交互重于过程和工具，敏捷原则里也建议面对面的沟通。区别于日报或邮件，每日站立会议是团队面对面沟通和彼此交互的体现。通过保持过程透明性让参与过程的所有人了解真实状况，并且通过燃尽图，随时检查Sprint进展并与干系人沟通，如有必要则及时进行调整。
每日立会是Scrum几个会议中，反馈周期最短的一个，站会是Scrum过程里每人每天为单位的PDCA环，由此形成团队的PDCA环，并最终得到一个Sprint的PDCA环；（考考你，敏捷中，比站会反馈周期更短的，有哪些实践？）
站会不是汇报会，团队是焦点，而不是某一个人。
站会是团队社交的一种方式，当然是针对项目内容，而不是八卦。
举行站会有很多小的技巧，例如为防止大家七嘴八舌影响讨论，可以用一个道具，如一个网球，拿到网球的才能发言；传球最好也不是顺序，而是随机，或者抛球，谁抢到谁发言，更容易活跃气氛而不是僵化的例行公事；例如早期可由Scrum Master适度引导，逐渐转为每个团员轮值，最后变成团队自组织自发进行的活动。
虽然电子看板有诸多优势，举行站会时，围绕着物理看板会更有仪式感，在物理看板上挪动卡片的感觉也会更加直接；如果将电子看板投射到有触摸屏的大电视，可以集电子看板与物理看板的优势与一身。
________________________
________________________
________________________