起点

X公司是一家中规中矩的公司，从事软件开发二十多年，一直使用传统瀑布开发模型，开发流程和相关的制度都已经完善。最近两年因为市场的变化，考虑到公司长远的产品线的竞争力，决策层决定推动新产品领域开发。但是传统的瀑布模型无法满足高层快速进行产品试水的需要，市场部的需求一改再改，并极力打造大而全的产品，虽然他们并不承认。两个项目(A, B)下来开发团队和公司高层都非常不满，团队士气低落，离职频繁。公司高层对项目成果不满，甚至提前中止了第二个项目B的开发，要求公司EPG对两个项目运转进行分析总结，并拿出改进方案，务必使下一个项目成功。经过若干大会小会检讨、分析，EPG指出了公司现有流程无法适应当前开发需求，建议在准备执行下一项目的团队中试行SCRUM+XP。于是我们的故事就从项目经理Watts的上任开始了……

组织结构及主要人物:

Drucker --公司总经理 (原型是现代管理学之父Peter.Drucker)

   Knuth – 公司技术总监兼研发副总 (原型是Donald Ervin Knuth, <<计算程序设计艺术>>的作者)

   Beck --- EPG单位经理 (原型是Kent Beck)

   Sutherland –- 研发团队经理 (原型是SCRUM最初提出者)

   Pressman – 项目管理团队经理 (原型是<<软件工程-实践者的研究方法>>的作者)

Andersen – 市场部经理 (原型是<<长尾理论>>的作者)

   Myers – 测试部门经理 (原型是<<软件测试艺术>>的作者)

   Fowler, Robert – 开发工程师 (原型就不用说了)

   Eric –系统架构师 (原型是<<领域驱动设计>>的作者)

   Watts -- 项目经理 (原型是<<软件管理沉思录>>的作者)

新生计划

大纲: Watts是一位从事严谨、处事果断的项目经理，在公司内部颇受尊重，常常受命处理极为棘手的项目。这次也不例外。

Watts一上任后，马上展开团队面谈，全面了解项目团队目前的状况。同时也和他的老板Pressman以及市场部的Chris了解高层对项目的期望。当然他的最主要挑战是EPG要在他的项目中导入SCRUM，一时还很难预知其中的风险。所以他需要和Beck, Sutherland一起谈谈，SCRUM到底能为团队带来什么?并要求EPG对新的项目团队进行培训。

……

周一一大早，Robert和Eric在公司餐厅边吃早餐边谈论着后面的工作。

Robert：伙计，你要失业了!

Eric: 胡扯什么！这周新项目就要开工了，我应该会忙一阵呢！而你们还可以先休息一会，不过，后面可够你们受的。

Robert：得了吧，兄弟！你不知道Beck那个家伙搞了什么吗?他现在可是准备把设计阶段从项目开发过程抹掉。当然还不止这些。

Eric：怎么可能？不做设计就直接开发？你忘记上个项目怎么失败的吗？Marketing的那个叫Andersen的家伙，三天两头的变更需求，搞得我根本没办法做好系统设计。没有稳定的系统设计就是B项目被Drucker那个老头砍掉的根本原因！

Robert：不要太激动！要生气的应该是我们。设计变来变去，你知道为了配合你那不着调的设计，我们加了多少天的班？真想买本<<人件>>给Sutherland看看！真不知道那家伙看过没有。你说没有充分的设计是前两个项目失败的原因，这个我不同意。Sutherland在项目总结会说过，真正的原因是目前的产品没有清楚的定义，所以需求变来变去。根本原因在这里！

Eric平静下来了，自己刚刚只算是宣泄下情绪。 Robert说得有道理。毕竟他们这些程序员的压力并不比他小。他轻轻地朝Robert点头表示同意。

Robert：我有确切的消息。Watts今天就会来我们的办公区上班了，他是咱们下一个项目的PM。而Beck在我们呆了一个月后，上周给Durcker老头提交了一份关于A、B项目的分析报告，说我们前面运行的流程全错了，要推翻掉改为SCRUM开发模型。这个模型，我查过，确实是针对Andersen那个善变的家伙的，至少我这么认为。整个开发流程和以前不一样了，这可是一个不小的变化。

Eric开始注视着Robert，听他继续讲下去。

Robert: 其中有一项和你老兄就有关系，因为我没看到专门的设计阶段。而且Beck那家伙还一直在EPG内部的评审会议中反复强调说”不要做事先大量设计”，可你不就是干这个的吗?这可是内幕消息，我也是花了不少心思的。哦！你看看Myers?

Myers正低着头从旁边走过，像是在思考什么。

Robert：他肯定也得到消息了。他们测试单位也要面临很大的挑战。

Eric沉思了一会，问道：如果真是这样，影响也太大了。不可能说改就改吧！

Eric显然已经从自身转移到对整件事情的关注。

Robert：当然。所以Watts来了。他可是以执行力出名的。

Eric：God！

Eric开始担心起来。

上班时间一到，Watts就出现在Sutherland的办公室。两人一见面，相互道了个早安，就直接切入正题。这是Watts的风格，Sutherland也很配合。

Watts：上周在Beck报告会上，R&D这边，主要是Knuth发表了些意见。倒是没听到你讲什么？你是团队的直接主管，我是很想听听你对Beck的报告中关于流程改造有什么看法。

显然， Watts早就看出来Knuth过于偏爱在纯粹的技术领域探讨问题，那是他的专长。特别那三本神一般的著作，公司给每个高管都发了一本。Watts以前就常常拿着它们练练二头肌。现在年龄大了，书也不知道塞哪去了。总之，Watts根本就没兴趣去看那些书，他更关心的是流程。

Sutherland稍稍调整了一下姿势，十指交叉的支住下巴，沉思了一会。

Sutherland：坦白说。Knuth关于技术上的意见是非常正确的。我们的确在一些技术上准备的不充分。而且在开发过程中有一些设计实践和建构方法也不太恰当。特别一些新加入的工程师，在解决问题的能力上常常走弯路，而且得不到有效的支持。所以导致后面Bug一直无法收敛……

Watts打断了Sutherland：老兄，这种的说辞我听得太多了。我们之前已经合作过很多次了，不需要这样避重就轻。我能理解前面两个项目对你造成的压力，而我就是来帮助你解决问题的。所以我们之间需要简洁、高效的沟通。

Sutherland有些尴尬的干笑了一下。曾几何时，自己也是老板指哪就打哪，奋勇向前。但经历越多项目，反而使自己越来越谨慎起来，甚至有些胆小。面对着Watts的洒脱和执着，Sutherland决定找回从前的自己。

Watts继续说:这些问题都只是执行层面中方法论的问题，并不是真正的核心问题。我想听听你对 Beck提出的流程改进计划的看法。

Sutherland：我先说一下先前两个项目的问题。首先，Beck关于前两个项目的分析结论，是正确的。 Beck亲自在这里调研时，我们就已经达成共识了。正如 Beck报告里的那张图，研发团队面临的是两个完全相反的力量。市场端总是责怪我们做得根本无法同其它厂商的产品竞争，同时开发效率低下，开发周期一直拖延。他们根本不理解为什么一处UI上修改会需要不止一天，甚至还引入了一些新的Bug。而另外一边，现有的开发流程要求我们文档一个都不能缺，中间各项制度也不能打破，以免产生破窗效应。

这是研发团队面临的最大的问题。研发团队一般都是指责市场部没搞清楚市场需求，瞎定义，但其中大部分的状况都是针对市场的正常反应，反而是研发团队要学习如何适应。其余的部分就是第二点。

第二，市场部门追求大而全。这里面主要暴露的是产品规格审核的问题，你会发现并没有一个审核机制来约束市场部门对产品的新要求。Knuth没有参与这些细节上的事，所以Andersen总是顶着Drucker的虎皮向研发单位提出新需求。我虽然自行做了一些选择，但却要被指责效率低下。Andersen就说:”连需求的规格都没做完都要让项目延期”。我对这当然是要抱怨的。总之，市场单位和研发单位的配合不起来。研发团队为了在开发周期内完成100多项的功能，我必须承认，我们后面基本失去了协调能力，没有了节奏，只能是将任务分到每个人头上，然后再由个人对照列表逐项完成。中间发生问题了再报出来。所以我不再是Manager,而是救火队长！你知道吗？我们一开始准备的WBS和Schedule到了项目一半时，基本上已经完全被改版了。手上的事情本来就做不完了，而需求的功能还一直在增加，当然也有些是做到一半不要的。这种情况非常打击团队的积极性。代码质量就成了一个很突出的问题。

第三，公司现有制度对团队成员的支持也不够。所有开发人员的绩效考核都是以半年度考评展开的，其中项目的绩效评定以项目周期达成状况决定的。在实际开发中，项目管理团队为了降低风险，在项目规划时故意预留了一段缓冲时间，从而压缩了项目团队的开发时间。面对这个不可能按时完成的项目，其绩效结果基本上定了的。所以团队的动力不足。

这些Beck在报告里都提到了。针对这些问题他们提出了解决方案，坦白说，我并没有多少把握。主要是改动太大，怎么才能顺畅的推行下去？这不简单啊。相信这也是你来这的理由。

说完，Sutherland冲着Watts点点了头。 Watts认真地听着Sutherland的说明，虽然Beck对这些问题都提到了。但今天听到Sutherland的再次说明，Watts对Beck提出的解决方案也更加有了信心。Watts来之前，Pressman让他和Beck仔细地讨论过一次，但以Watts的观察，Beck虽然将新SCRUM+XP说得像是就为了解决现在的问题而生的，但Beck并没有深厚的项目经验，所以Watts对新方案的态度也很谨慎。

Watts准备鼓励Sutherland说下去：你说得很好，让我有了更清晰的认识。那么关于Beck的解决方案呢？真得可以完全解决现在的问题吗?

Sutherland随后表达了自己对Beck所提方案的支持，但重点还是对如何执行，心里没有底。Watts清楚下面需要请Beck亲自出场了。

在Beck来之前，Watts必须花些时间了解一下团队。先是请Sutherland介绍了每一位组员，然后Watts下午约每位工程师做了半小时的面谈。在交谈中，Watts已经能够深深感受到团队中充斥着不安的气氛。

“看来只有Beck将方案说透，团队才能回到正常的状态了！”Watts想到了Tuckman关于团队发展的四个阶段，还真是需要一段时间。

在整个流程改造过程中，公司高层的支持必不可少。敏捷开发模型带来不单单是纯粹流程和方法上的变化，也会带来公司制度层面，甚至是文化层面的改变。只将流程改造限制在项目级别，只能产出一个勉强而来的结果，并不是真正的敏捷开发。

开端

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内变更的原则，更是避免了因为团队的灵活而放任了需求变化。简洁的设计、持续构建都有助于团队控制软件的内部质量。而对于各种实践，可以在实践中灵活选择。整个流程改造过程也以敏捷的方式进行，而不是追求一步到位，这样可以使得整个流程改造更加稳定。

总而言之，整个改造过程必须有足够的理性面对复杂的环境变化，以系统地方式统观全局，借签理论和别人的经验，结合本公司实际条件来决定和实践流程改造！

X公司的流程改造之路相关推荐

X公司的流程改造之路 (二) [课程报告]
在整个流程改造过程中,公司高层的支持必不可少.敏捷开发模型带来不单单是纯粹流程和方法上的变化,也会带来公司制度层面,甚至是文化层面的改变.只将流程改造限制在项目级别,只能产出一个勉强而来的结果,并不是 ...
SCPPO（二十一）:系统统一身份认证的改造之路（续）
强烈推荐一个大神的人工智能的教程:http://www.captainbed.net/zhanghan [前言] 在上篇博文中小编为大家分享了<SCPPO:系统统一身份认证的改造之路>,由 ...
创业必看——开公司的流程
创业必看--开公司的流程原文http://www.cnblogs.com/lexloo/archive/2011/01/21/1941601.html 创业在即,一切从零开始.我必需知道要做什么,该 ...
巨头都在争抢无人驾驶这家智慧停车公司却先上了路科技事务百家号 08-14 15:55 今年来，互联网巨头在智慧交通领域动作频频，4月初，百度提出雄心勃勃的“阿波罗计划”，宣布开放自动驾驶平台以
巨头都在争抢无人驾驶这家智慧停车公司却先上了路科技事务百家号 08-14 15:55 今年来,互联网巨头在智慧交通领域动作频频,4月初,百度提出雄心勃勃的"阿波罗计划",宣布 ...
【转】STO跨公司转储流程
一．流程说明跨公司转储流程,是在不同公司代码下的两个工厂之间进行物料转移,涉及交货出库和收货,需要进行结算. 一般由收货工厂做转储单,也可能需要经过审批等环节,发货工厂根据转储单做交货单,并完成拣配 ...
农产品进出口成都代办公司注册流程
在成都怎么注册进出口农产品公司呢,该如何去办理相关的注册流程?农产品公司在成都我们应该如何去做呢?企博士财务就为各位老板整理了关于进出口农产品公司注册流程以及相关需要资料,看完本文你就一目了然了! 一 ...
深圳市注册新公司的流程
深圳市注册新公司的流程七木网络-East胡杨 xd54622@qq.com 在深圳市注册新公司,流程还是比较简单的,整个过程只需要在工商局网站填写资料就可以了,目前连公司注册资本都不需要认证.另外需 ...
企业研发流程演进之路
前言无论是半路转行的准程序员,还是正在读书的大学生,大家都比较关心一个问题:「企业中真实的研发流程是怎样的」.有一些在小公司的程序员,也会好奇大厂的研发流程. 为什么这么多人关心研发流程呢,因为一个 ...
电子商务公司运营流程是什么怎样绘制
移动互联网的发展,带动了很多新兴产业的发展,电子商户算是里面独占鳌头的从在,很多人纷纷加电子商务这个大队中并在里面发光发热,那电子商务公司运营流程是怎样绘制的呢?下面看一下在迅捷画图中绘制该电子商务运 ...

X公司的流程改造之路

开端