上一篇:X公司的流程改造之路 (一)
开端
Beck为团队进行了两天的培训，并逐一解答了大家的问题。在随后的团队的启动会议上，总经理Drucker亲自出席鼓励团队，并对整个管理团队(EPG,PM,R&D,以及行政和人事团队)提出明确的要求，项目的最终目的除了项目成功，也要为公司未来定义出新的软件开发模型。同时在会上要求Knuth、Pressman、Watts和Andersen每周一上午向他报告项目状况。项目小组需公司制度上调整的部分可以整理好报告后直接交给Drucker和另一个行政副总。这一切都为项目团队的提供了强大的支持。
团队培训中的分析诊断
Beck来了。周二上午，Beck带着三位EPG同事走进开发团队的办公区。Sutherland将他们引到团队前的白板位置。然后向大家宣布Beck和他的三位同事将大家一起办公，并从周三开始为项目团队进行两天的敏捷开发方面的培训。在稀落的掌声过后，Beck也说了几句，欢迎仪式就草草收场了。
角落里的Eric看着Beck，越发担心起自己的工作了。他决定趁着第二天培训好好搞清楚。
第二天，整个团队被集中到培训教室，很多人发现Andersen也坐在教室后都感觉有些不太自在。Watts和Sutherland也放下手上的工作全程参与，而Andersen是被邀请来参加第一天的课程的。Beck把课排得很满，他准备把重点放在了SCRUM和XP几个实践的介绍。从公司流程开始，结合着A、B项目总结出项目暴露出来的流程上的问题，然后自然地引出了敏捷宣言。周三下午和周四午则全部用来介绍SCRUM中的角色与责任、主要的框架性活动、冲刺(sprint)的概念等等。但在一开始，他必须引导大家正视问题。
Beck: 伙计们！听说最近你们不少人对未来的项目有些担心，这我理解。前面一个月，大家总结了项目中遇到问题，非常的精准，每个问题都值得我们认真对待。我把他们整理到一起了。
说完Beck在投影仪上打出一张列表，密密麻麻的铺满整页。其中就有沟通不及时、需求不明确、加班严重、没有可供测试执行的规格书、设计变更频繁、项目绩效评估不合理、代码质量不高、工程师的估算不受尊重等等。
没等大家仔细过一遍。Beck便在投影上投出一个大大的红色叉叉，也占满了屏幕。
Beck：Drucker派我来和大家一起消灭它们！
下面有些人鼓起掌来。
Beck：是的，我找到了一个解决方案可以帮我们有效地解决这些问题。虽然不能全部解决，但解决掉多少取决于我们执行得怎么样。我们必须成为一个完整的自组织团队(total self-organized team)。
Beck顿了一下。然后接着说：困挠我们最大的问题是需求不明确。容我替Andersen说句话，换谁在他那个位置，一样事情还会再次发生。这是因为我们的产品面对的市场快速变化。用我们以前的瀑布模型，单单需求和设计就会耗费掉我们两个月的时间，而这个时候市场上可能已经又出现新的产品了，我们的产品很难形成竞争力。所以最根本的一个问题是我们能不能适应快速的市场变化？
Beck环顾一下教室，他想给大家一点思考的时间。
Beck：有一个对策：敏捷开发。具体一点，在流程上，使用SCRUM框架。采用小步快跑的迭代开发，分步聚划出多个Sprint,也就是冲刺阶段。每个Sprint的计划设定好后，直到结束，中间不会再加入新的需求，而是等到第二个sprint启动时再处理。在这个过程中，大家的估算也将受到尊重，但我们也有义务兑现承诺。
教室里的气氛开始活跃起来。
Robert提起嗓子说了一句：听起来，这个主意很不错！可是怎么才能做到呢？
Beck顺着Robert的问题开始谈到团队的组织：关于团队组织上，需要一个完整的自组织的概念。这是结合了SCRUM和XP的概念，一个是谈团队的人员构成，一个是谈人员的主动性。两者的结合就是我们开发团队的发展目标。在这里，我可以告诉大家，Andersen也将是新项目团队中的一员，他将担任Product Owner这一角色，因为他最能代表市场。也就说，Andersen也是我们中的一员，不再是一个外人了。
教室开始有些波动。
Beck补充道：Andersen加入到团队中，将使得我们的需求确认也就是SCRUM中的User Story更为准确，对于每个sprint的开发计划的设定也会更加准确。想想吧，之前Andersen跟各位说过多少次：”这不是我想要的！”，“为什么那个功能还没做好?“
Eric忍不住了:那是因为他没有说清楚！
Andersen坐着前排，他并不感到惊讶，因为他从声音就已经知道是谁。”他不这么说才奇怪呢！”。
Beck：是的，大家都觉得是别人的问题。表面上看这是一个典型的沟通问题，沟而不通，仍然各说各话。我却更相信这是一个运作机制的问题。就是说没有完善的沟通机制可以让Marketing和R&D有效沟通，共同控制好产品计划。而这次安排Andersen做为Product Owner参与我们每次的计划讨论，就是要解决这个问题。在SCRUM里面已经有套运作机制可以运用。在SCRUM框架下，Andersen将帮助我们通过用户故事明确用户的需求，以及每一次sprint的目标。他也能将通过每次sprint产出的程序中发现的问题，放入到产品待定项(product backlog)中，在制订下一个sprint目标时，选择若干优先级高的作为冲刺待定项(sprint backlog) 拿出来讨论。这样也解决了Andersen之前没有任何约束的问题！相信Andersen也理解这一点。
Andersen插话了：我只关心R&D能不能给我有竞争力的产品！
教室里气氛已经轻松许多了。大家开始将焦点集中在如何执行的问题了。
在周三余下的时间和周四上午，Beck依照之前的计划，将SCRUM+XP的概念展开讲述了一遍。大家也渐渐活跃起来。特别是对编写较少的文档、快速的构建、PO的参与及以User Story和Backlog来管理需求等表现出浓厚的兴趣。Eric一直关心设计的问题，当听到Beck讲述只做充份的设计时，也觉得是一个好主意。面对不断变化的需求，谨慎的设计总好过做无用的设计。错的设计做得再多也是错的，这个道理很容易理解。”可是我以后在团队的角色是什么呢？我的价值如何体现呢？” 这个问题一直在Eric脑海无法解开。事实上，多数人都有一样的问题，这也是这个团队最深层次的问题。
Beck显然是有备而来。周四下午，Beck将话题引到团队身上，焦点就是讨论团队成员在敏捷开发过程中价值和绩效。Drucker因为事实了解到培训安排，特别请主管人事的副总裁参与进来。做为一个核心问题，Beck再次从敏捷宣言的第一条说起。
Beck:敏捷宣言的第一条是个体和交互胜过过程和工具。前面我们讲了很多，都是流程和方法，或者说明活动。敏捷宣言强调以人为本。人是活动的执行者，才是整个开发过程的决定因素，而不是传统上所理解的那样:按正确流程就可以做出正确的结果。简而而之就是以人为本。
Beck稍稍又介绍了一个马斯洛需求层次模型。大家也随之思考起个人的职涯发展问题。
Beck: 以前咱们是岗位责任制，每个人的R&R(角色与责任)是很清楚的。这样做是有它的科学道理的。如果依敏捷开发模型，个人职责会被放大。你的职称(title)不能约束你的生产力，虽然一切也要遵循一定的规则。举个例子，做为一名底层模块的工程师，发现了应用层存在的问题并有更好的解决方案，你完全可以去重构它，但一定要请应用层负责的工程Review后才能提交。也就是说如果你能做到更好，那就去做！
Fowler急切的问：如果我的系统设计比较好，我能够争取使用我的设计吗?
Eric瞟了一眼Folwer, 他早知道这家伙想做系统架构师了。可惜之前团队只设一位架构师。这下好了，没有架构师了。他自己苦笑了一下。
Beck笑着回答：Sure! (旁白:这老外好不容易讲了句英文,我的错!) 准确地说应当是更合适的，而不是更好的。
Eric不自觉的嘟囔了句：那我呢？
Beck听到了，他转过脸对着Eric说：我有一个很简单的建议，去做比他的更合适的设计。
Eric听着Beck的回答，他决定索性问个明白：其实我关心的问题是做为一个曾经的系统架构师，我在未来的项目中能担当什么职责呢？毕竟现在没有专职的架构师了。
Beck笑了。他明白这个小伙应该忍了很久了。他停顿了一会，然后说：这个问题其实很好回答。第一，架构师不会取消。我应该没有说过这样的话吧？设计的任务仍然是存在的，只是做法上要求不一样了。以SCRUM而言，设计要能够配合Sprint的规划，在每个Sprint中将核心的骨架定义出来。这个设计工作不仅是没有，反而变得更有技巧了。你可以认为有一个敏捷的设计方法。
第二，我前面说了，大家不要被当前的职称约束了。反而要从团队的需要和项目的需要来思考我能为团队和项目做什么？只要能帮助团队和项目解决问题，那就是你的价值。
Watts也在思考重建团队价值观的问题，于是他也将之前和Beck探讨过的问题再丢出来，主要希望Beck能讲得全面一些。
Watts：这样如何评定绩效呢？没有了明确的岗位职责，就需建立新的衡量标准了。
Beck明白Watts的用意。他开始讲述新的绩效考评计划。
Beck：是的。这将是我们推行敏捷开发必须要面对的难题。说它是难题是因为在现在的绩效考评*下，是没办法支持各位去做职责以外的事的。但是，我必须说，公司对我们这个团队的期望很高。Drucker已经指派人事单位和EPG共同拟定了一个试行的绩效考核制度，只在我们这个团队试行。这个其实是组织层面的敏捷化。如果缺少了组织层面的支持，项目层级或者部门层级的敏捷将很难实实在在的落地。其中一项是同行评价。也就是各位的绩效不再单纯由部门经理和项目经理来评定，同时会收集平级同事的评价，至于具体的指标和实操方式正在拟定中。有些时候主管或许可能看不到你的贡献，只要你的同事认可你的贡献，你的绩效考评就会加分。
Robert很高兴，因为他经常会在工作中提炼出基本组件，为团队成员提高了不少生产力呢。“这应该会让我加分不少吧?”他心里盘算着以后应当多做一些这样提升效率的事情。
Sutherland也在旁边提出了他的问题：这么庞大的系统工程，现在有没有明确的Roadmap来说明我们后面的推行计划？
Beck狡猾的看了看Watts和Sutherland，然后说到：”这就是咱们后面两天要做的。Drucker正等着我们给他呢！但至少一点，我们也会运用小步快跑的原则，一步步”
Watts也笑了。Sutherland在这里问这个问题确实不合适。这只不过是一个培训会。并不是新开发模型的说明会。倒是他的问题确实代表了开发团队绝大部分人的想法。什么时开始？怎么开始呢？
Beck随后按他的培训计划将敏捷开发中的团队与人的课题展开讲述了一遍，算是为大家建立了一些共识。
新项目团队
随后两天，EPG(Beck为首)、开发团队(Sutherland为首)、PM (就是Watts)开始密集地讨论EPG已经准备好的一份Roadmap草稿 (是的，EPG已经准备了一份草案，只是没有定案而已。作为EPG当然要系统地思考问题！)。他们的目标也并不是定下一份决议案，而是讨论以下几点问题：
1. 流程改造的总目标？
2. 将总目标细分出具体的活动和期望的结果，形成一份列表由EPG管理。
3. 选择第一阶段的改造目标。(只做第一阶段应当做的)
4. 估算第一阶段的周期总长。
5. 流程改造的项目结构。
Watts一眼就看出来Beck的组织方式。他从一开始就认为将流程改造以项目的方式运作是必然的。但他没想到Beck运用了SCRUM的规划方式来执行它，或许可以称之为敏捷型项目管理。Watts心里想，幸亏这两天全程参与了培训，不然还真摸不透Beck的做法。
最后，大家达成一致，Beck负责管理各阶段的改造目标,并评估项目改造的效果。也就是Product owner的角色。Watts负责管理改造项目团队，为Sutherland提供支持，保证按阶段目标执行。而Sutherland将主要将焦点集中在项目C的执行。在研发项目团队方面，由Andersen任PO, Watts为SM。团队包括Sutherland的研发团队和Myers的测试团队。考虑到研发团队将近20人，基于系统层次划分，也分出两个团队运作。Beck和三位EPG伙伴被安排到Sutherland和Myers的三个团队中担当教练，协助各个团队主管。一个项目架构明晰起来：
Watts随后召集团队，正式宣布C项目将是开发一款智能手机上使用的电子书阅读软件。各个单位为此展开前期预研工作。
敏捷组织
Drucker拿到Beck送上来的报告后，又召集几位高管讨论布署相关的组织层面的配套制度，包括绩效考核制度、考勤制度，以及奖惩办法等等。两周后，随着相关的准备工作结果，一整套基于”只做到足够好”的原则制订出的制度草案就通过会审。项目启动的日子就来了。
一个风和日丽的下午，透过办公室的窗户可以远远看到蓝蓝的天空上飘着几片薄薄的白云。Watts正在准备项目启动大会上的演讲。虽然时间不长，但是Watts很用心。无论经历了多少项目，他都和以前一样，会为新项目有一个良好的开始而尽百分百的努力，包括每个细节。
在办公区最大的会议室里，所有的团队都被召集进来，等待管理团队的入场。其实已经没有什么悬念了，新的开发流程的培训完成了，相关的新制度在公示一周后，也由人事团队专门开会介绍过了，新的项目组织也经Sutherland公布出来了，而关于任务安排上，仍然是基于先前的分工方式做出一个基本的安排。每个人已经清楚地了解了自己下一步要做什么，虽然也保留了许多的弹性，但那一切都是要在走出第一步之后才能清楚，然后再做决定。这已经足够了，不是吗？所有人表现都很轻松！
没一会，Drucker进来了，紧随其后的是Knuth, Pressman, Watts, Beck, Andersen, Sutherland。公司高层和项目管理团队都到齐后。和其它项目启动会议上一样，Watts作为主持人控制着会议的节奏。各项活动有序进行，一切都很顺利。当Drucker代表公司高层向团队做了简洁的演讲。
Drucker：我很早以前就想来看看大家，看看我这些疲倦的小牛仔们。你们辛苦了！
下面响了一阵掌声。(远比冯巩那句”我想死你们了”，威力要大得多了！)
Drucker：新的C项目要开始了。你们准备好了吗？
人群中给出了一致的回答，虽然不整齐，但对于工程师，这算是很难得的回应了。Watts坐在旁边，不禁感叹Drucker果然实力不凡，自己实在难望其项背啊。短短几句话，已经完全掌握了会场。
Drucker：我和Knuth也认真地检讨了过去的教训，根本原因还是我们对新市场的认识不充分，准备不足，所以才有了比较坎坷的过去。这一次，我们上上下下做了充分的准备，很谨慎评估每个细节，我有信心告诉你们，我也准备好了。而这一切，都是因为你们是它的奠基人。Watts刚刚也为大家介绍了项目的两个目的，我要再强调一次。C项目除了保证最终的产品成功外，还要为公司找出有效的新开发模型。
Drucker：这一次，公司的管理团队会和你们在一起。我已经请Knuth、Pressman、Beck、Watts和Andersen每周一个会，为你们解决困难。任何可以从制度上调整的，都会同步报到我这里，我会亲自推动它的处理。总之，我会尽自己最大的努力给你们做好你们的后盾。而我只希望你们能安心地将项目做成功。你们能做到吗？
在又一次得到一致肯定的回复后，Drucker郑重地说了声谢谢就结束了演讲。Watts和Beck都明白，Drucker正在进行组织的敏捷化，这对未来项目改进的成功与否至关重要。
C项目就这样启程了！
总结
本章节主要通过Beck的培训对团队问题进行分析并提出解决方案。同时为确保流程改进的成功进行公司管理层提供了大量有力的支持。以下是汇总表:
|
问题 |
根本原因 |
对策 |
|
需求不明确且变化快 |
1.涉入新产品领域，追求产品竞争力。 2.尝试适应快速的市场变化。 |
敏捷开发-SCRUM |
|
需求管理不当 |
1. 没有有效的机制让市场单位和R&D进行关于产品计划进行有效的沟通。 |
SCRUM - backlog & sprint |
|
缺少足以支持团队运作的制度 |
当前制度是为原开发流程服务的。 |
由总经理负责为新流程配套相关的制度。比如对于绩效考核将引入同行评价(Peer Review)的方式。 |
进行曲
流程改进的sprint计划会议
由Watts召集Beck, Sutherland, Myers和其它相同的项目管理人员，开会了一个小会，主要是确定一下流程改进项目的第一个发布计划会议。
Watts:先请Beck介绍一下Sprint Backlog中的项目吧，大家可以随时表达你们的意见。
Beck:我之前已经准备好了整个流程改进的product backlog，将近30个项目。我已经为他赋了一个优先级。其中前五项的是基本框架活动: 1.SCRUM - backlog的管理 2.SCRUM – sprint流程：计划会议、评审会议及回顾会议 3. XP –增量设计 4.XP-Small Release 5. XP – 持续集成。我想如果这5项能在第一个Sprint中导入的话就可以帮助团队建立基本的敏捷开发模式。
Myers：这里怎么没有测试相关的项目呢？我建议加上XP-测试驱动开发。由测试人员和开发人员配对编程! ……
没等Myers讲完，Sutherland打断了他。
Sutherland:抱歉，我不同意你的看法。一次性导入太多的实践，只会适得其反。倒是测试单位应当在第5项目持续集成上多想想有什么可做的？要知道持续集成的每一次集成结果都要进行测试的，这就是很好的切入点，也很有价值。
Beck正要表达同意Sutherland的说法。不过, Watts却抢先了。
Watts：其实我们之前讨论过，配合研发的敏捷化，测试也应当敏捷化。Myers，你们不是有推动自动化测试的计划吗?
Myers：是的！问题是我们缺少懂程序开发的测试人员。
Beck：不用一步到位，大家都是一个迭代的过程。还记得婴儿步吧。前期先使用现有的一些自动化测试框架来做吧。
Myers：OK! 刚好我知道有些工具可以做到。
Watts：Perfect!
Sutherland：为什么没有每日站立会议呢？
Beck：我们裁剪掉了。因为这个不是C项目，而是流程改进项目。由Watts每周召集一个短会，大家碰一下就可以了。
流程是为项目服务的，适当的修正会比生搬硬套好的多。Sutherland明白了这一点。
Watts：Beck也会随时观察团队进展，及时给出一些建议的。我想我们还是直接展开五项的具体内容讨论一下，然后做个决定？
随后，大家逐一讨论了五项内容的细节，最终同意了将在第一个Sprint阶段实践Beck提出的五项内容。流程改进项目的第一个Sprint将包含两个C项目的sprint。也就是在C项目第二个sprint的回顾会议举办的时候，也要举行流程改进项目的第一个sprint的回顾会议。
建立初始产品待定项
Andersen在立项之前是忙了很长一段时间收集需求。他按照之前的经验，使用了一些需求获取的方法，其中自然是竞争对手研究是最有效的了。Andersen同样像以前一样准备了一份功能清单向Drucker和Knuth做了报告，经由一些初步预研后，最终被正式立项。
Watts请Andersen尽快先定出产品待订项(product backlog)来，以便进行下一步的sprint计划会议。Andersen虽然了解可以用用户故事来登记待订项，但他对其中的优先级一筹莫展。他找到负责协助他的EPG教练Emma，准备请教一下。
Andersen：Hi, Emma. Watts给我下了死命令了，这周必须要有可用的Product Backlog。
Emma：没问题，我们一起来做。
Andersen：我带来了多之前在项目评审时使用的功能列表。
Emma扫了一眼，功能列表已经根据功能需求及非功能性需求做了分类。看来Andersen已经在努力改进需求管理了。
Emma：挺不错。分类很清楚！那我们就是要为每一项准备一个用例故事(user story)，并且定一个优先级就可以了。首先，产品Backlog中各项都应当是客户价值的体现。我们先看第一条吧。
功能需求: 字体及配色必须适合老年人阅读，以减轻视疲劳，保证连续阅读时间。
看来咱们是主要针对老年用户啊！
Andersen：是的，这个市场会越来越大。我觉得这一条挺直白的。R&D应当根据这一条来设计出来什么样的字体和配色适合老人阅读。
Emma：没错。不过，我们还是要以用户的角度在具体场景下来描述这个问题，这样才是故事嘛。如果R&D问：为什么有特殊的字体和配色的需求？
Andersen：因为老年人眼神不好嘛！应该没人不知道吧。
Emma：呵呵！作为一个backlog有必要去除不必要的困扰，将事情清楚地说出来。特别是抓住核心功能需求。
Andersen：所以，这一条的用户故事要写为:因为老年人多有花眼且易疲劳，所以字体和配色要做相应的调整。字体不能太小，也不能太大。配色应对比度高。
Emma：不错啊。算有一个用户故事的形了。只是还有一些不太明确的部分。比如，这项需求的重点应当是减轻视疲劳。眼神不好是客观前提，改进字体显示和配色是手段，其目的是减轻阅读时的视疲劳。我这样理解对吗？
Andersen：是这样。根据调查，最佳阅读时间是40分钟。因为是掌上阅读的原因，咱们的产品能保证阅读30分钟内无明显疲劳感就可以了。
Emma：所以，想想下面的说法: “因为老年人多有花眼且易疲劳，我们需要保证 40分钟阅读时间内无明显视疲劳。
约束: 1. 字体要易于阅读。2. 配色应对比度高。”
Andersen：原来如此！这就算是第一个User story了，R&D需要请负责用户体验的工程进行设计细节了。我们再往下看吧。
Andersen和Emma随后开始逐项建立产品待定项。前期先将功能需求转换到product backlog中就已经超出第一个sprint的需要了。所以Watts每天都会查看当前product backlog的状态，以决定什么时候开始sprint计划会议。
需求变更
一天早上，Andersen冲进Watts的办公室。
Andersen：Watts！有一个重要的功能，必须马上变更Sprint backlog。
Watts很清楚在sprint开始后是不应当变更sprint backlog的，这样会打乱研发的节奏。但Andersen这么着急提出来，自然有他的道理。他决定先弄清问题。
Watts开玩的说：说说看。是怎样一个伟大的想法让我们的Andersen这么坚持?
边说边请Andersen坐下，自己也往前靠了靠，准备洗耳恭听。
Andersen坐下后，稍稍放松了一下。然后说电子阅读器必须预留一个广告栏。原来在最近一周， Andersen已经和一些潜在客户接触，他们都对新产品很有兴趣，并希望把它同时做为一个广告平台。Andersen最后答应他们尽快给他们一个演示。
Watts明白了，Andersen急于抓住客户，而开了空头支票。这并没有错，商机转瞬即逝。他们需要一起来解决这个问题。
Andersen：多好的机会！我们的产品虽然还没有出来，但已经有了合作客户。这对一个新产品，是多么重要啊！ 你知道，我花了多少心思才打动他们的。
Watts：少来！(直接是Watts的风格) 你老弟在我面前邀功可起不了什么作用啊！不过，你这次做得确实漂亮。
Andersen：那快点把这个需求加进去，让Sutherland他们在这个sprint就赶出来，我就准备去给客人演示一下，然后就可以谈合作的细节了。如果有了这样的样板客户，后面的市场运作就有了非常棒的基础。你知道我提的长尾理论吧？只要我们有了庞大的用户群……
Andersen很沉醉于他的憧憬。可是Watts必须帮他清醒一下。
Watts：打住！回到正题吧！我们流程改造的很重要的一个目的就是要适应变化，但同时要有约束。那就是一个简单的原则:在sprint计划在sprint周期内不做变更。
这是Beck告诉他的。Beck事先预估得一定会有像以前一样不受控制的需求被要求加入现行计划中，为了保护计划的有序进行，便设了这样一个规则。
Andersen：不行。产品做出不就是为了卖出去吗？如果做出来，市场就没有了，那么做出来的产品又有什么意义？
Watts：这样吧，我让你做一个选择题，二选一。第一，如你所愿，将你的这个需求加入到现在sprint，请Sutherland优先实现它。
Andersen连忙点点头，表示这就是他想要的。
Watts：不过，这样的话，以我的粗略估计，这个sprint可能会延期半个月左右。而更严重的是，整个流程改造的节奏会被打乱，很可能违背了改造项目启动的目的。因为又回到有关约束需求管理的问题。研发团队可能因此对刚刚建立起来愿景失去信心。
Andersen愣住了，他开始担心自己是不是被Watts忽悠了。怎么听起来这么复杂呢?
Watts：别慌，还有第二个选择。将这个需求放到下次sprint，也就是大约一个半月后完成。你在第一个sprint完成后，可以拿着软件给客人演示当前的功能和未来的规划。第一个方案和第二个方案，其实没有差多少时间，而且第二个方案却让客户早点看到实实在在的软件，会不会让他们更有信心呢？ 而且，以现在的项目运作方式，他们如果有兴趣，也可以参与进来。
Andersen开始盘算起来。依第二种方案，确实可以让客户更加有信心。增加双方的互动有利于找到更大的合作空间，未尝不是一件好事。
Andersen：好吧！一定要列到下个sprint计划中啊! 我一会去找Emma先加到产品预定项去，然后我再找 Sutherland沟通一下，请他有时间就做些预研的工作。千万别让煮熟的鸭子飞了！
说完，起身离开。一边走还一边嘟囔着：我又要多两根白头发了！
Watts看着Andersen的离去，他看到了Andersen已经开始适应新的开发模式了。
过程改进总结
项目开始两个月后，C项目完成了两个sprint，由于一开始就有效地控制了项目范围和需求蔓延，即便中间也遇到了许多的问题，产出仍基本达到sprint计划的要求。这一点是很重要的，Fowler和Robert也对两个sprint没有出现明显的延期而兴奋不已，他们都已经明显的感受到他们正一步一步的达成项目标。在整个过程中，研发团队像是一个快速反应的机动部队，追求简洁高效，冗长的会议逐渐减少，那些复杂的开发文档也被有效的精简了。总之，团队更加聚焦于要实现的产品上。
对Drucker和管理层而言，并不需要很多的项目报告，更不需要日报，就很清楚C项目的进展，真实的产品很诚实。项目管理的成本和风险都在降低。
敏捷开发模型对于需求不稳定的项目非常有效，小步快走保证了需求变化对团队的影响尽可能的小。而SCRUM限定不在sprint内变更的原则，更是避免了因为团队的灵活而放任了需求变化。简洁的设计、持续构建都有助于团队控制软件的内部质量。而对于各种实践，可以在实践中灵活选择。整个流程改造过程也以敏捷的方式进行，而不是追求一步到位，这样可以使得整个流程改造更加稳定。
在整个流程改造过程中，公司高层的支持必不可少。敏捷开发模型带来不单单是纯粹流程和方法上的变化，也会带来公司制度层面，甚至是文化层面的改变。只将流程改造限制在项目级别，只能产出一个勉强而来的结果，并不是真正的敏捷开发。
总而言之，整个改造过程必须有足够的理性面对复杂的环境变化，以系统地方式统观全局，借签理论和别人的经验，结合本公司实际条件来决定和实践流程改造！
转载请注明出处:http://blog.csdn.net/horkychen
其中有许多不成熟的观点，欢迎指正！谢谢！
参考: