阿捷：好的！这次我不会冒进的。？
敏捷圣贤：那就好！凡事预则立，不预则废。对形势做出良好的判断并提前做好准备还是非常有必要的。我要下了，有事咱们再联系吧。
阿捷：多谢。886。
敏捷圣贤：886。
今天的收获太大了，阿捷重拾起了Scrum的信心，准备带领TD团队再次快跑。
。 最好的txt下载网
第6章 不仅仅是站立（1）
The way ahead is long； I see no ending； yet high and low I’ll search with my will unbending。
路漫漫其修远兮，吾将上下而求索。
——屈原《离骚》
根据敏捷圣贤的建议，如果想真正搞好Scrum，就必须有专门的Product Owner负责维护Product Backlog才行，这事得赶紧解决，否则，以后的Sprint Planning会议不仅开不好，而且每个Sprint肯定又问题多多。阿捷想了想，这事只有李沙最合适。李沙是负责Agile国内OSS产品的Product Manager，阿捷决定请他出山担任Product Owner。
李沙个子有米高，四方脸，稍微有点瘦，是个典型的东北大汉，平时总是西装革履。因为同是公司篮球队里面的，大家经常一起打球，所以关系一直很不错。
周五下午，阿捷决定找他聊聊。
“嗨，忙着呢啊？”阿捷走到李沙格子间时，李沙正在看Sohu体育新闻，没注意到阿捷过来。
李沙转过身来，笑了笑：“还行，你看这不火箭又赢了，国内的这帮人把姚明给吹的，不就是一个两双嘛！当家中锋你就得这个数据才行！”
“呵呵，胜者王侯败者寇！趁着赢球赶紧吹吹，也是有道理的。”
“嗯，对了。这周末的中智杯去不去？听说对手是双鹤药业。”
“去啊！没我哪成啊，你还不全靠我给你喂球呢。”
“好！打完球咱们涮肉去。对了！哥们儿，今天是不是有啥事？”
“有点小事儿。你现在不忙吧？”
“不忙，都周末了。说吧。”
“嗯，是这么回事”，阿捷先把自己团队要搞Scrum的事情介绍了一下，然后引到请李沙出任Product Owner的事情上来。
“噢，听起来你们这个流程似乎比原来的要灵活很多。我很愿意做这个事情，这样我们也能更好更及时地合作。可问题是我具体该做些什么呢？”
“首先，你要帮我们维护一个叫Product Backlog的东西。是我们所需要做的所有事情的高层次的列表，按照优先级排列起来。”
“你的意思是说把用户需求文档中的东西换一个形式？”
“嗯，差不多。原来我们用的需求文档太复杂了，有几百页。我们现在讨论到的Product Backlog是一个功能列表，可以组织得非常简单，既包括已经定下来的需求，也要包括那些还不清晰的需求。具体你可以用Excel，或者Word也行，看你用什么方便了！关键在于要方便修改、增删条目，以便于随时调整优先级。第一次，我可以帮你一起做一个初始版本。”
“那我们还是用Excel好了！”
“嗯，我也建议这样。我们现在计划每三个礼拜一个Sprint。那么你要根据根据实际情况随时修改这些内容：如增加新需求，修改已有需求，一定要实时，而且这些修改都要在下一次Sprint计划会议之前完成。这样，才能确保我们团队总是根据你排定的条目优先级，在处理最重要的需求。”
“没问题！”
“我们以后就将以这个文档跟你一起确认详细的需求。如果产生疑问，你得随时解释需求。如果我们做完了，你要帮我们把关，看看是不是你最初所要求的。”
“这些都是我本来就应该做的，除了维护这个Product Backlog外，流程上还需要我做什么？”
“参加两个会议：Sprint计划会议和Sprint评审会议。Sprint计划会议可能会占用很多时间，估计得大半天吧。Sprint评审会议应该比较简单，估计半小时或者一小时就够了。”
第6章 不仅仅是站立（2）
李沙皱了皱眉头：“哦？Sprint计划会议要这么久？我可不可以不参加？我保证开会之前把最新的Product Backlog给你。”
“那可不行！这个会议是我们最重要的会议，计划会议开不好，我们接下来的三个礼拜都不会有好日子过的。你要是不能参加，我们这个会议就不能开，也就不能按照这个Scrum流程做事情了！”
“哈哈，这样我不成了你们团队的人了！”
“其实，这是最能展现你的个人影响力的时候了！你看，你说做什么，我们整个一个团队接下来就得做什么。具体做什么你完全说了算，还不好？外人要是不懂，还以为你是我们组的经理呢。”阿捷尽量把话题搞得轻松些。
李沙笑了笑，拍了拍阿捷的肩膀，“兄弟，你现在行啊！什么事情都能说得这么好听。你们这个Sprint计划会议到底做些什么？我去做什么？”
“简单讲，Sprint计划会议的第一部分，你和我们共同过一遍Product Backlog，讨论Backlog 中各条目的目标和背景，并回答我们开发团队的问题，以深入了解你的想法或需求。在会议的第二部分，我们开发团队从Product Backlog 中挑选条目，并承诺在Sprint结束时完成任务。我们会从你给出的具有最高优先权的条目开始，并按列表顺序依次工作。所以你给出的优先级至关重要！”
“这样看来，第一部分我参加还有一定的必要性，第二部分似乎意义不大！”
“不，也很重要！我们会详细讨论如何做，做到什么程度，如何演示等，也就是我们给出一个DONE的标准，这样，在Sprint评审会议上，我们做演示时，你可以根据‘DONE’的定义来评定我们是否真正完成了！而且，我们在细化任务时，还会跟你澄清一些问题的！所以你一定要全程参加才行。”
“噢，可我的老板那么久看不到我，没准会有意见的。”
“呵呵，没事，谁不知道你现在直接Report给老美呢。咱们上班，人家还没上班呢！再说了，计划会议三个礼拜才一次。而且，在会议上，我们没有问题的时候，你也可以上网、发邮件、写文档的！我们需要你一直陪着的目的，就是想一旦有问题，好能随时找到你！”
“嗯”，李沙迟疑了一下，“那好吧，看在你的面子上，我克服一下。”
阿捷用力捶了李沙一下，“够哥们儿！不过，得跟你事先声明一下啊，如果我们一起确定下来一个Sprint中要做的事情后，在此Sprint 期间，就不可以添加新的需求或者变更需求。你要想添加新要求，只能等下一个新的Sprint ，也就是三个礼拜后。”
“这没关系，咱们以前几个月都没变过，也等过，不怕！”李沙回答得非常干脆。
“好！那就这么定了！我下周一过来跟你一起搞出来第一版的Product Backlog。”
“好，那周末篮球场见。”
晚上，阿捷登录MSN，准备和敏捷圣贤继续讨论每日Scrum站立会议，因为阿捷他们在这个站立会议上花费了很多时间。不但效率不高，而且大家意见很多。可惜敏捷圣贤并不在线，阿捷只好到抓虾网看看自己订制的博客文章。
阿捷正看得来瘾，突然觉得屏幕一震，然后一个MSN窗口弹了出来，阿捷用鼠标切过去一看，原来是敏捷圣贤上线了。
敏捷圣贤：Hi； 阿捷。
阿捷：你好！圣贤。
敏捷圣贤：我们继续谈谈你们上一次Sprint的经历吧。我记得你说每日Scrum“立会”平均要花40~50分钟，对吧？ 。。
第6章 不仅仅是站立（3）
阿捷：是的。在每日“立会”上，前几天大家还能按时来，注意力集中，并尽量更新足够多的相关内容。但后来说的事情会不着边际，而且时间太长。最后几天，大家因为忙，对这个例会的关注度和重视程度明显下降。
敏捷圣贤：没准儿你应该换一个思路。
阿捷眼睛一亮，马上回复道：是不是可以通过E…mail来代替？
敏捷圣贤：绝对不可以！E…mail不能取代每日Scrum会议。E…mail只会增加沟通成本，而且不能提供细节信息或者给他人问问题的机会，也不能帮助其他成员解决问题。
阿捷：可不可以不开？我们都觉得每天开会意义不大！
敏捷圣贤：这个“立会”不仅能要让所有人了解其他人在做什么，当前项目计划进展如何，还可以帮助大家解决那些阻碍做事情的问题，以及共享承诺。其实，这些都是非常有利于提高团队合作精神的。
阿捷：噢，可我们每天花这么长的时间开会，影响工作效率。有什么可以使会议保持紧凑有效的小窍门吗？
敏捷圣贤：窍门和经验有很多，我自己总结了8条，想听吗？
阿捷：好啊，等着你传授给我呢。
敏捷圣贤：第一指导原则：主题明确，不能掺杂其他无关的话题。要做到这一点很简单，只需要保证每个人只回答4个问题，就行了。
阿捷：都是什么问题？
敏捷圣贤：“我们上次开会后你都干了什么？”，这需要让整个团队很好地了解该成员在做什么，以及当前进展，但也不要过分详细，否则会使大部分人失去耐心。
阿捷：嗯，我们上次有人说“和上次一样”，也有人说“我正在改一个bug”。看来也是不对的。
敏捷圣贤：是的，“细节决定成败”，这里一定要关注一下细节才行。下一个问题是“每个你负责的、正在做的任务还剩下多少时间”。
阿捷：这个我们忽略了。
敏捷圣贤：有些团队的站立会议也不涉及这个话题，是因为他们用单独的工具软件跟踪剩余工作量。对于你们，如果没有让每个成员在会前主动更新你那个Excel表格的话，就需要在会议上给出最新估算。在Scrum下，每天重新做任务估算是非常重要的。这样，才会知道你们还有多少工作量，在剩余的时间内能否完成。如果你们估计不足，觉得不能完成，那么就要及时调整计划。
阿捷：看来，如果我们坚持下去的话，也有必要采用一个专门的工具。你说的调整，是什么概念？是把完不成的任务拿出去吗？
敏捷圣贤：这是一个思路，另外就是坚决地结束当前Sprint，重新开始下一个Sprint。但无论如何，这事都要事先跟Product Owner打招呼，让他知道你们的最新决定。
阿捷：好的，第三个问题是什么？
敏捷圣贤：“在我们下次开会之前你要做什么？”，当成员间的工作有依赖关系时，这会给其他成员一个很好的提醒。
阿捷：就是自己给自己设定当天的目标。
敏捷圣贤：嗯，最后一个问题是“你的开发被阻碍了吗？”这个问题最重要。阻碍一个人继续开发的问题，最终也会阻碍整个开发团队，所以一定要鼓励大家说出自己的问题。一旦有人提出来，你作为Scrum Master，就有义务帮助他尽可能地消除这些障碍。
阿捷：啊？有些技术问题，如果我们的开发人员都解决不了，我更不可能解决的。我可不是什么技术专家。
敏捷圣贤：对于一个Scrum Master而言，并不一定就要自己亲自去解决问题，更关键的是你要去协调、去调度资源。
第6章 不仅仅是站�