敏捷无敌-第8部分

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

　　第二天早上10：00，阿捷站起来催促大家！
　　“走了走了！大家都到‘光明顶’去，咱们讨论第一个Sprint。”
　　阿捷首先发言：“大家好！我们是不是可以为我们的每个Sprint起一个好玩的名字呢？毕竟Scrum就是一个Sprint连着一个Sprint，这样下去就是一个很好的系列了，我建议我们前面几个Sprint采用加里森敢死队的剧名！如何？”
　　“嗯，这样挺好玩儿的！”小宝第一个表示赞成！
　　“加里森敢死队？还真的挺符合我们啊！在咱们部门，还没有人搞过Scrum的，咱们就是第一个吃螃蟹的，我觉得不错！”大民顿时也来了精神。
　　阿捷不免心里有些得意，能得到大家的共鸣是很愉快的事情。
　　阿紫在旁边嘟囔了一句，“加里森敢死队？我都没听说过，讲啥的？”这位80后，跟大家有着明显的代沟。
　　“呵呵，代沟！”阿朱笑道。
　　“嗯，那我简单介绍一下吧。”阿捷说。
　　“电视台播放《加里森敢死队》的时候，我好像才上初中，是在我们本市的电视台看的。”
　　“它讲的是一拨监狱里的囚犯，在一个美军‘干部’的带领下，深入德军敌后搞破坏的故事。”
　　大民还没等阿捷说完，就接过话头，“是啊！当时，我们同学都看得特别High，每天都讨论这个。当时有媒体报道，有少年模仿电视剧里练习飞刀，有盗贼模仿连环盗窃，有学生模仿吸烟，喝酒模仿找帅，都是受了这部电视剧的影响。据说，中央台因为这个还停播了后面的几集。”
　　阿捷继续说：“没错，就那个样子！我所以选择《加里森敢死队》，是因为我觉得这个团队里面有一个很好的Team　Leader——上尉加里森，以及各有所长的成员：小偷、酋长、戏子、强盗，他们各自发挥自己所长，完成了很多难以想象的任务。这样的团队，对于软件开发团队来讲，太需要了！”
　　阿紫一脸的期待，“我建议，我们在每一个Sprint结束的时候，都找一集看看。”
　　“没问题！我家里就有碟！那么还是回到今天的主题，那我们就给第一个Sprint起名字叫兵不厌诈（the　Big　Con！）”。阿捷在白板上写下了“Sprint1——兵不厌诈（the　Big　Con！）”。
　　“其实这个也正好能说明咱们的状况呢！大家第一次采用Scrum，对这个Scrum流程都很期待，同时呢，对于怎么做，如何用，还很模糊，正所谓兵不厌诈。”
　　大家都舒心地笑了，会议的气氛顿时轻松了起来。
　　中午吃饭前，阿捷跟大家一起完成了对第一个Sprint的计划，带领大家开始了他们的第一次快跑！
　　这天，阿捷在自己的Blog上，写下了这样的总结。
　　　电子书　分享网站

第5章　成长的烦恼（1）
Good　honing　gives　a　sharp　edge　to　a　sword　，　Bitter　cold　adds　keen　fragrance　to　plum　blossom
　　宝剑锋从磨砺出，梅花香自苦寒来。
　　——《增广贤文》之勤奋篇
　　时间过得很快，两个礼拜一晃就过去了。阿捷他们的第一次快跑Sprint也结束了，但大家感觉并不怎么好。
　　在Sprint计划会议上，大家按照阿捷准备的一个Product　Backlog，从中选择了一些用户需求，进行开发。虽然阿捷事先对这个Product　Backlog条目做了一定的细化，并设定了一定的优先级，但在选择的时候，大家并没有按照优先级来选，只是找了几个刚好可以在两个礼拜内做完的东西。在会议上，大家大致讨论了一下，阿捷就按照先前的惯例，根据每个人过去的经验，对每个模块的熟悉程度，基本上是直接指定一个人做哪个任务了。对于每个任务，没有做详细的估算和任务划分，因为以前就一直是把任务交给一个人后，由这个人一直负责，自己做估算、做设计、实现，然后交给测试人员测试，测出Bug再返工，直到做完为止。这个过程基本上就是一个黑盒，如果负责这个任务的人不说，别人也不知道具体做得如何，当前是什么状态。
　　Sprint计划会议的第二天上午10：30，阿捷召集所有的人在“光明顶”举行了第一次站立会议，因为这是首次举行站立会议，大家相互看着对方，觉得很好玩，兴致都很高。阿捷首先把自己负责的任务讲了一下。包括自己将会如何设计、对不同的实现方式进行了比较，然后给出估算，觉得应该可以在一周内做完，然后交给测试人员进行测试。大民、小宝基本上都是同样的模式，也把自己的任务讲了一遍。小宝觉得自己那块有些复杂，可能要花上8个工作日才行，估计剩不了多少时间留给测试了。阿朱和阿紫因为要等着开发人员做完后，才能进行测试，所以也没开始具体做什么事情，讲起来自然很简单，两个人总共花的时间还没有大民、阿捷一个人用的时间一半多。但即使如此，不知不觉地时间就到了11：40，大家差不多站了一个多小时，腿都酸了，刚好都到了吃饭时间，大家一哄而散，下楼去吃饭。
　　在接下来的日子里，如果有会议室，大家就到会议室里开站立会议；如果没有，大家就聚到阿捷的格子间凑合一下。有时候是上午10：00开，有时候是10：30，还有一次因为阿捷上午要开部门的Dashboard会议，大家的Daily　Scrum站立会议是在下午3：00开的。有时候大家会对一个技术问题展开激烈的讨论，有时候不知怎么的，大家就会扯到姚明、NBA、奥运会北京限行措施、抢购奥运门票的事情上去，偶尔还会聊聊公司的公积金政策、部门的人事变动等，反正每次的会议都挺长。有时候谁累了，就坐在椅子上或桌子上，听别人讲。当然还少不了阿紫、小宝这样的短信狂人，收到短信时所带来的噪音。有时候，阿捷也觉得这么做真的有点浪费时间，相信其他人也有同感，但即使如此，大家还是把站立会议坚持了下来，毕竟Scrum很重要的一点就是强调Daily　Standup　Meeting的！
　　大民、阿捷所负责的任务基本上都按期完成了，阿朱、阿紫分别进行了测试，虽然发现了一些小问题，但大民、阿捷还是在Sprint结束前就修正完了。但小宝所负责的任务，就像他自己第一天所说的，真的遇到了麻烦。一个模块总是出现Core　Dump，无法运行，小宝换了好几种方法，甚至做了Debug版本，进行单步跟踪，还是找不到问题。甚至在开站立会议时，大家等了他好几次，他才不情愿地从座位上站起来，参加站立会议。在会议中间，还跑回去几次看看运行结果。因为小宝自己没有主动提出需要帮忙，所以阿捷、大民也没好意思帮他看到底问题出在哪里。直到Sprint结束前一天，小宝才兴奋地告诉大家，问题终于解决了。可留给阿朱的测试时间只有一天多，虽然阿朱早已准备好了测试用例，但对于这样一个复杂的特性，这点儿时间还是不够的。于是，在这个Sprint中，小宝负责的模块没有完成最终测试。这让阿朱很沮丧，因为感觉好像是她的工作没有做完。同时阿朱也很委屈，毕竟在这次快跑中，自己的工作前松后紧，自己也想努力完成最初计划的事情，可是小宝的工作一直没完成，自己也只能是干着急，毫无办法。txt电子书分享平台　

第5章　成长的烦恼（2）
对于这种现状，阿捷更着急。不仅仅是因为这个Sprint的原始计划没有完成，更重要的是自己团队的第一次快跑就这么搞砸了。在Sprint结束后，阿捷组织大家进行了一次简单的回顾，谈谈大家对第一次快跑的感受。在会上，阿捷虽然想了点Ice　Breaker，试图活跃一下气氛，但因为第一次快跑的过程与结果都不令人满意，气氛还是很压抑。大家谈得不多，基本上觉得每天的状态报告会花了太多时间，其实应该把这个时间更好地用到项目本身才对；另外，因为Scrum本身只是一个框架，没有定义具体的编程实践，不如一些XP实践更具有可操作性，关键的还是大家基本上都没看到这个Scrum流程的价值，这次快跑让大家感觉有点泄气。小宝和阿朱甚至说，干脆别搞Scrum了，似乎带来的问题更多。阿捷好说歹说，才使大家平静下来，最终达成的一致意见是暂时停下来，重新审视一下，看看是不是可以改善一下，在找到真正可行的办法或者操作实践后，再继续搞Scrum，再试验下一次快跑。
　　阿捷这几天一直很苦恼，再加上7月的北京已经开始变得炎热起来，阿捷就有点着急上火，不仅仅睡觉不踏实，连嘴边都起了大泡。从感觉上讲，Scrum应该是一个很好的项目管理模式，不然敏捷圣贤也不会推荐给自己，而且要不然像Google、Microsoft等大公司也早就放弃了。可能只是自己实践的方式不对吧，但却又不知道到底该怎么去改善，看来只能靠敏捷圣贤的帮助了。阿捷每天都上网，并待到很晚才下去，希望能碰到敏捷圣贤。
　　这天晚上，阿捷跟美国方面开完Conference　Call后，正准备去洗脸刷牙，却意外地发现敏捷圣贤上线了！阿捷高兴得跳了起来！
　　阿捷：你好！
　　敏捷圣贤：你好啊！
　　阿捷：现在有时间吗？我们遇到了麻烦。
　　敏捷圣贤：呵呵，我果然猜对了！我是专门上来找你的！我想你们的第一次快跑结束了吧？
　　阿捷：是的！我们遇到一些问题，大家的意见开始出现分歧了，有人甚至认为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做了个列表，把我们下几周需要做的东西放进去，还按照优先级排了一下序。书　包　网　txt小说上传分享

第5章　成长的烦恼（3）
敏捷圣贤：等一下！你说，你做了一个Product　Backlog？
　　阿捷：是啊！有什么问题吗？
　　敏捷圣贤：也就是说，你们没有定义一个Product　Owner这个角色？没有让这个人去完成并维持Product　Backlog？
　　阿捷：恩，我们没有。
　　阿捷心想敏捷圣贤的脸色一定很难看，估计这个问题很严重！
　　敏捷圣贤：如果你们真的想实行Scrum，那么就一定要遵循Nokia的敏捷标准，遵循Nokia制定的“Scrum规则”，这是Nokia用了几年时间，对上百个Scrum团队进行了回顾后，才总结出来的很简单的建议，这可以帮助他们判断一个团队是否在真正实施Scrum。
　　阿捷：那Nokia怎么知道一个团队是否真的在实施Scrum呢？
　　敏捷圣贤：首先，他们要看是否采取了迭代开发的方式。多年来，业界一直使用迭代式的、增量式的开发，这似乎已经成为所有敏捷过程的基础元素了。
　　阿捷：这个应该比较好判断。那为什么团队是否“进行迭代开发”这么重要呢？
　　敏捷圣贤：因为如果不这样做，甚至都不能称为敏捷的软件开发过程。这是因为敏捷希望整个软件开发流程中的所有人都可以一起工作，大家都要对产品非常了解：无论是构建产品的人，测试产品的人，还是将会使用产品的用户。
　　阿捷：嗯，大家是应该一起工作。
　　敏捷圣贤：对，如果把过程分隔成“这里的这些人编写需求说明和规范，然后他们把文档交给负责构建软件的人，软件构建者再将软件转给测试人员，最后测试人员把软件提供给客户”，客户就会说那不是他们真正需要的东西。然后就要回到开头，再来一次。如果如此反复三遍的话，客户就会取消这个项目了。这就是为什么世界上有那么多项目被砍掉的原因。
　　阿捷：嗯，那在Nokia，还要接着问什么问题？
　　敏捷圣贤：他们会接着问“你们有固定的迭代周期吗？你们的迭代是否以某个特定的时间开始并以某个固定的时间结束？”
　　阿捷：是不是迭代周期也应该有限制？
　　敏捷圣贤：对！在Nokia，迭代周期必须少于6周。如果不是这样做的，那么就没有进行迭代开发。
　　阿捷：如果人们的回答是肯定的呢？
　　敏捷圣贤：那他们接下来会问“那好，在每个迭代结束的时候，你们有可以工作的软件么？”这个问题会把很多人排除在外，因为如果不能给出可以工作的软件的话，那也就是没有进行迭代式开发。
　　阿捷：嗯，如果回答还是肯定的呢？
　　敏捷圣贤：接下来他们会说“好，你希望在结束时拥有可工作的软件，那么在可以开始迭代之前，你们的团队是不是必须要有一个有完整细节的需求说明？”如果需要的话，那就不是迭代式开发。
　　阿捷：哦，我有些明白你的意思了。接着呢？
　　敏捷圣贤：最后他们会说“要在迭代结束时拥有可以工作的软件，将测试作为迭代增量开发的一部分是非常重要的。你们在开发过程中进行测试吗？”，这个问题有可能将一半左右的Scrum团队排除在外，这时甚至还没有谈到有关Scrum的话题呢。
　　阿捷：是啊！我明白了，那他们的“Scrum规则”是什么？
　　敏捷圣贤：嗯，对于应用Scrum，他们有四个附加的规则。团队被询问的第一个问题是“你们是否有Product　Owner？是不是有人可以代表客户与你们一起工作？”
　　阿捷暗想，自己团队的Scrum还真没有啊，于是问道：Product　Owner的作用是什么？书包　网　。　想看书来

第5章　成长的烦恼（4）
敏捷圣贤：很简单，当团队在决定应该构建什么样的产品时，这个人就是他们要询问的对象，这个人代表着客户的需求与利益。
　　阿捷：如果对这个问题回答“是”呢？
　　敏捷圣贤：Nokia会询问的第二个问题是“如果有Product　Owner的话，他们是否拥有一个待开发功能的Product　Backlog？此Backlog是否根据业务价值排定了优先级？是否已经估算过开发这些功能需要多少时间？”。
　　阿捷：哦。
　　敏捷圣贤：这是一个Product　Owner为一次版本发布构建路线图所需要的依据。如果得到了肯定的回答，他们会继续询问“团队在开发过程中，有没有使用　Burndown图，来展示当前迭代中随着时间的推进，剩余工作量的变化，以跟踪进度？并且能否基于Burndown图来推算团队的速度？”
　　阿捷：这个问题的意义在哪里呢？
　　敏捷圣贤：首先，Product