软件开发模型与过程改进

always_fly

从过去软件开发模型, 我们有很多的反思与借鉴. 笔者曾看到国内三线城市的一些公司的软件开发过程, 项目的成
功依赖个人能力. 对于每一个软件系统研发过程, 只是拍脑袋定个Dead Line. 规定时间2个月做出来, 临近快要交付
的时间点, 说无论采用什么方式,加班还是其它都要做出来, 最后做出来系统质量差. 然后后面几个月对系统开始打
补丁, 扑火. 实际上就是一个小做坊. 对于研发工程师都是苦不堪言.  想实施敏捷又限于公司文化, 人员的瓶颈, 只
能是不断转化思想与方法. 最后属于哪一类过程也不清楚了. 由于现在还没有任何一种方法能够解决软件危机中的
所有问题，所以在软件开发的各个阶段采用综合治理的方法.  软件开发模型直接影响软件开发的周期和软件质量，
是软件开发的组织管理形式，是软件工程最重要的内容之一。 让我们先回顾一下软件工程中开发模型:

WaterFall模型

缺点
•  Requirements must be known  up  front:  It's difficul t to imagine every detail  in advance. Most projects start o
ut with some uncertainty,  and more  detai ls are  learned as  the  project  progresses.
•  Hard to estimate reliably: To gain conidence  in an  estimate,  there may be the need to design and implement
parts,  especially riskier ones.  Estimates become more  precise as  the project  progresses.
•  No  feedhack of system by  stakeholders until after testing phase: The process does not facilitate  intermediate
versions. Stakeholders  often  need  reassurance  of  progress  and  conirmation  that  what  is  being  developed
meets requirements.
•  Major problems with  system  aren't  discovered  until  late  in  process: The  testing phase  is where  these pro
blems are found,  but  it  leaves very  li ttle  time  for  correction,  resulting  in  potentially disastrous effects  on  p
roject schedule and cost.
•  Lack of  parallelism: Each phase is executed to completion. Disjointed parts of the system could otherwise be c
ompleted  in  parallel.
•  Inefficient  use  of  resources: Team members can be idle while waiting for others to complete their dependent
tasks or  for  phases  to  complete.  Also,  someone  good  at  requirements  analys is  is  not  necessarily  good
at programming.

原型




       在获得用户基本需求说明的基础上，投入少量人力和物力，快速建立一个原始模型，使用户及时运行和看到模
型的概貌和使用效果，并对需求说明进行补充和精化，提出改进意见，开发人员进一步修改完善，如此循环迭代，
直到得到一个用户满意的模型为止。从原型法的基本思想中可以看到，用户能及早看到系统模型，在循环迭代修改
和完善过程中，使用户的需求日益明确，从而消除了用户需求的不确定性，同时从原型到模型的生成，周期短、见
效快，对环境变化的适应能力较强。

优点：

开发者与用户充分交流，可以澄清模糊需求，需求定义比其他模型好得多
为用户需求的改变提供了充分的余地

缺点：

开发者为了使一个原型快速运行起来，往往在实现过程中采用折衷的手段。软件系统的组成部分可能会打折扣；
资源规划和管理较为困难，随时更新文档也带来麻烦。

一般使用场合：

开发者在不了解的应用领域开发
客户不清楚其所开发软件项目的最终目标

增量



系统设计时分片交付，可使用户在使用某些基本功能的同时，开发剩余的功能。这样通常会并行地存在两个系统：
生产系统和开发系统。运行或生产系统是当前被客户或用户所使用的系统。而开发系统是准备用于替代当前生产
系统的下一个版本。

• 增量模型是一种非整体开发的模型。是瀑布模型的顺序特征和快速原型模型的迭代特征相结合的产物。
• 该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。

•特点：
在前面增量的基础上开发后面的增量
每个增量的开发可用瀑布或快速原型模型
迭代的思路

•优点：
如果在项目既定的商业要求期限不可能找到足够的开发人员，这种情况下增量模型显得特别有用。早期的增量可
以有少量的人员实现。同时，增量模型可以规避技术风险。

螺旋



螺旋模型是一种迭代模型，每迭代一次，螺旋线就前进一周。当项目按照顺时针方向沿螺旋移动时，每一个螺旋
周期包含了风险分析，并且按以下4个步骤来进行：

（1）确定目标，选定方案，设定约束条件，选定完成本周期所定目标的策略。
（2）分析该策略可能存在的风险。必要时通过建立一个原型来确定风险的大小，然后据此决定是按原定目标执行，
还是修改目标或终止项目。
（3）在排除风险之后，实现本螺旋周期的目标，例如，第一圈可能产生产品的规格说明，第二圈可能产生实现产
品设计等。
（4）最后一步是评价前一步的结果，并且计划下一轮的工作。

优点：

结合瀑布模型和原型模型的优点
风险分析可使一些极端困难的问题和可能导致费用过高的问题被更改或取消

缺点：
螺旋模型开发的成败，很大程度上依赖于风险评估的成败。需要开发人员具有相当丰富的风险评估经验和专门
知识
一般使用场合：
需求不能完全确定，同时又存在技术、资金或开发时间等风险因素的大型开发项目。

RUP(Rational Unified Process)


上图示例3个迭代示例, 再来看经典的RUP示例图:

always_fly

来自IBM的海报: RUP 入门最佳导航图：Rational 统一过程，切实可行的流程

原则

只开发需要的东西。
关注有价值的结果，而不是获得结果的过程。
文档最小化。
足够灵活。
从错误中吸取教训。
定期做风险回顾。
为进度设定客观和可度量的条件。
自动化需要大量人力投入且单调易错的工作。
使用小而有自主权的团队。
有计划。
迭代开发是针对问题解决和解决方案开发的基于团队的方法。它要求所有参与的人 —— 包括开发团队、客户团
队，和管理团队 —— 都采用协作的技术。
从开发团队的观点出发，采用迭代和增量开发是需要授权的，并要求团队成员积极进取地用他们认为最适当的
方式处理项目危机和难题。通过设置清晰的目标和客观地度量结果（但不指示活动）来管理迭代可以确保轻松
地找到最佳的方式来交付成果。

从客户和业务团队的观点出发，引入清晰有意义的目标，并结合回顾可论证成果的能力，可以使那些最终使用
新软件的人在项目中发挥积极作用，并与开发团队分享所有权。迭代对所有涉及项目的业务人员产生深远且长
久的影响，并且从根本上改变了他们规定、支付，并实现软件解决方案商业利益的方式。

从管理团队的观点出发，每个项目都被分解为一系列小的项目，称为迭代，每个迭代都建立在前一个迭代的结
果之上，并不断增加地实现项目的总目标。当授权开发团队创造革新的且有效的解决方案时，这种对项目的分
割引入了常规的，可度量的，使项目保持正轨的里程碑，将项目成功的几率最大化。

企业统一过程

企业统一过程, RUP定义了软件开发生命周期，EUP则将它进行了扩展以覆盖整个信息技术（IT）的生命周期。
扩展包括两个新的阶段，产品阶段和衰退阶段，还有一些新的准则：运营和支持以及7个企业准则（企业商业
建模，资产组合管理，企业架构，战略重用，人力管理，企业行政和软件过程改进）

敏捷统一过程

敏捷统一过程，关注的是轻便的方法和一套能够用敏捷原则和价值观驱动的、最小化的实践。AgileUP：

是一个Rational统一软件过程（RUP）的简化版。它描述了一个简单易懂的方法，该方法通过使用敏捷技术和
概念来开发商业程序软件，但它依然忠于RUP。我努力让AgileUP在方法和描述上尽量简单。那些描述单刀直入
，如果你需要更详细的内容，网上都有链接。方法则致力于敏捷技术，包括测试驱动开发（TDD）、敏捷建模
驱动开发（AMDD）、敏捷变更管理以及数据库重构，这些都可以改进生产率。
缺点

•  The UP was  originally conceived of for  large projects : This  is fine, except that many modern approaches
perform work  in  small  self-contained phases .
•  The process may be overkill  for small projects : The  level of complication may not be necessary for smalle
r projects. Practitioners  and  vendors  of  the  uniied  process  have  modified  it  to  be more  like  an  agile  
process.

敏捷

宣言

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

原则与优点

快速、连续的交付
通过快速、连续的有用软件交付来获得客户满意度。这对您的组织是否重要？您的公司是否为希望开始用某个应
用程序的 Beta 版本来吸引客户的新公司？您的应用程序是否将通过取代手动工作来节省内部开支？

频繁的交付
可以按照数周而不是数月的间隔频繁地交付可工作的软件。如果您的应用程序是 Web 应用程序，您可能希望频
繁推出更新以添加新功能，或者在获得客户的反馈时改进该应用程序。您不必担心繁重的版本控制任务，或者维
护文件以跟踪哪个客户端具有哪个版本。如果版本发布涉及到客户端的更改或工作，您可能不希望频繁地做出更
新。此外，频繁的迭代也许是个好主意，因为您知道自己可以在数周而不是数月内实现和发布更改。

工作软件
主要的进度度量标准是工作软件。已编写的文档和幻灯片演示并不足以满足大多数业务需求——您需要相关的工作
软件。如果您从事的是咨询业，也许文档和幻灯片就足够了，但是部署工作软件最终是大多数组织的目标。

适应
在敏捷开发方法中，即使是后期的需求更改也是受欢迎的。很长时期以来，软件专业人员竭尽全力地避免或减少
做出后期更改。然而，由于业务环境可能快速变化，软件需求也应当如此。

亲密无间，日常协作
业务人员和软件开发人员应该每天就解决方案交换意见并展开协作。后期需求更改可能来自于业务人员，并且
开发人员应该实现那些需求。如果流程允许需求变更，则日常协作是必需的。
对于实现接口或规范的应用程序，需求应该与指定的权威机构发布的规范文档相同。对该文档的更改不只是大
事，这种更改根本就不应该出现。

积极主动、熟练人员
项目是围绕积极主动、熟练的受信任个人而构建的。（这确实应该是任何组织的基础。）无疑可以编写另一个专
栏来讨论为什么某些人积极主动，而其他人则不是。您是否拥有用于激励和培训没有动力和不熟练的工作人员
的资源，或者您是否需要确定已经充满动力并且高度熟练的可雇用人员

自组织的团队
自组织的团队在大多数软件开发工作中还不是现实。他们需要大量的开发和管理方面的经验。自组织的团队将决
定他们可以在某个迭代中实现需求的哪个部分，并将决定由谁负责该实现。团队成员的角色基于他们的兴趣和知
识，而不是基于管理层的任命。组织涣散的团队将仅接受少量需求，并且产出成果也不多。为了正确地工作，
团队必须了解他们在做什么，并且管理层必须信任他们。

您的公司准备好了?

协商文化
开放和诚实的讨论在任何组织中都非常重要，但是如果您计划采用敏捷方法，则组织的各个部门必须良好沟通并
且能够在必要时做出妥协。

组织中的工作的人员之间的信任
如果管理层不信任开发人员，或者开发人员不信任销售人员，您就麻烦了。

规模较小、能力级别较高的团队
只需使用少量不必应付额外官僚作风的非常优秀的开发人员即可完成大量的工作。

促进团队成员之间快速沟通的环境。
业务需求需要在眼下而不是在下周得到满足。您的组织文化需要是快速响应的文化，而不是在过程中一筹莫展的文化。

七条原则帮助来判断什么项目是敏捷的项目:

项目中有利益干系人（Stakeholder）的参与
团队拥有并且可随时执行的回归测试
关注产品自身而不是冗余的文档
项目开发拥有严格的源码管理、版本控制
开发能够积极面对和响应项目需求变化
团队作为整体直接担负项目责任
能够自动化重复性的活动
共性

拥抱变化（Embrace the change）
无论是多么明智，多么正确的决定，也有可能在日后发生改变。因此，团队要能够充分理解我们的利益干系人
（Stakeholder）和客户代表为什么经常提出新的需求和设计要求，一句话，就是心中有数“唯一不变的是变化”
。团队更要信任 利益干系人（Stakeholder）做出的每次决定和需求的调整都是将产品开发推向更正确的发展方
向，新变化将进一步降低风险，实现团队最大化利益，理解这是适应市场变化的必然行为。而在接受变化的同时
，我们应该积极的向 利益干系人（Stakeholder）和客户代表反映实现活动中暴露出来的可能的设计缺陷和错误
。在实际工作中，团队成员应该用优先级制度来划分事情和目标先后顺序，在迭代周期内对于还没有最终决定
的设计方案可以予以后来实现、测试，不用急于投入资源展开全面的开发、测试活动。这样一来，开发测试团
队也会人员也将更加适应，真正拥抱变化。

客户的参与（With Customer Representative on site）
首先谁是客户（Customer），客户代表（Customer Representative） 呢？利益干系人（Stakeholder），或者
我们可以理解为我们的客户（Customer），产品的最终使用者（End user），内部使用者（Insider），商业伙
伴（Business Partner）。利益干系人（Stakeholder）作为团队中最了解业务（Business）的人物将帮助开发团
队的快速达到目标和做出适时决策。开发团队拥有很好的技术但在业务（Business）方面他们需要 利益干系人
（Stakeholder）的帮助。而通常在敏捷的开发项目中，团队中的任何一个人若需要帮助时，只要简单的邀请大
家参加一个 15 分钟会议，或一封邮件、一个电话便可以解决。但是，如果利益干系人（Stakeholder）各执一词
怎么办呢？为解决这个问题，将 Product Owner 引入到讨论中来，作为 Product Owner 他可以作为是 利益干系
人（Stakeholder）的代表，能够在分歧中做最后抉择。因此，通过这样的客户代表的参与，团队更好的了解了所
做事情的价值和意义，其工作效率也因而得到很大提高。利益干系人（Stakeholder）能够帮助团队中的每一个人
更好，更快的完成了工作，他们的直接参与成为了敏捷开发、敏捷测试的重要前提。

较少的文档（With less documents）
敏捷开发更重视生产出可用的产品而不是详细文档。而时常有发觉文档又是无论敏捷还是传统开发、测试不可或
缺的一部分。笔者认为，传统开发的文档在敏捷开发里仍有大用，只是原来十来页的内容精炼到现在的一页半页。
敏捷主义者相信文档不是最佳的沟通方式，他们鼓励通畅的交流和沟通，要求避免和减少陈词滥调和空头支票。
尤其是复杂的文档说明只是增加了沟通成本，因而敏捷开发、测试的文档不需要长篇累读，需要的是简洁，清晰。
任何一段清楚的文字，甚至一张图片，照片，一封记录着会议记录的邮件都是我们认可的敏捷文档。因为是无论
是通过文字板书的文件还是其他的沟通方式和载体都是为了帮助团队进行更高效的交流和沟通。只有团队保持着
沟通上、理解上的一致后才能够充分发挥出团队最佳战斗力。但凡这是帮助团队有效沟通的方式，敏捷开发是不
会放弃的。

最大化的生产力（Maximize Productivity）
敏捷开发模式要最大化的提高团队的工作效率。无论是依靠剪除冗余的文档工作，还是提供民主的、通畅的沟通
平台都是为了帮助团队能够集中有限的精力处理有意义的问题。据调查，通常人会在两个、多个任务并行的情况
下产生出出最高工作效率。而敏捷也恰恰使用了各种方法得到团队的最大生产力。敏捷开发的 Scrum 模式，要求
在计划阶段，团队成员主动定制迭代周期的所有工作任务，因此，本身从团队开始迭代活动的那时起，已经在在
多重工作的压力下紧张工作了。而在日常的迭代生产活动里，各个成员需要当众简单汇报当天的工作进度和承诺
下一个 24 小时的工作计划。因此，通过增加敏捷人员的工作的透明度，无形之中，团队成员的生产力进一步得
到提高。

测试驱动开发（Test Driven Development）
测试驱动开发，是让开发人员在编写功能代码之前，根据对需求的理解先设计和编写单元测试代码。先思考如何
对将要实现的功能进行验证，再考虑功能的实现。然后迭代的增加新功能的单元测试和功能代码编写，直到完成
全部功能的开发。

自动化冗余工作（Automate the redundant work）
将团队成员从冗余的劳动中解放出来，无论是自动化的测试还是自动化工具的开发只要能够节约成本都是敏捷
开发、敏捷测试的目标。

民主的团队（Democracy in team）
敏捷团队是一支民主的团队，团队关系是平行的，每个团队成员能够平等的参与讨论，决策。传统开发的垂直的
官僚机构在敏捷开发中已是过时的。

尊重团队（Respect to team）
敏捷团队的决定权交有团队自己，决定是团队统一制定。无论是产品设计方案还是产品的功能实现都是的最佳结
果。团队脱离了任何一个成员的工作都是不完整的，所以我们应当足够尊重其他成员的劳动果实和表达对其他成
员的充分信任。尊重团队，尊重团队中的每一个成员都是敏捷开发的原则之一。

Tips: 敏捷关注人与实践,  通常需要成功实施敏捷团队需要半年融合期.

XP极限编程


Scrum

always_fly

目前很多公司在广泛使用的, Scrum是一个包括了一系列的实践和预定义角色的过程骨架（是一种流程、计划、模
式，用于有效率地开发软件）。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，
产品负责人代表利益所有者，开发团队包括了所有开发人员。在每一次冲刺（一个15到30 天周期 ，长度由开发团
队决定），开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品订单（pr
oduct backlog，我觉得翻译成“产品目标”更恰当）， 产品订单（产品目标）是指按照优先级排列的需要完成的工作
的概要的需求（目标）。哪些订单项（目标项目）会被加入一次冲刺，由冲刺计划会议决定。 在会议中，产品负责
人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。
在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。

篇幅有限, 其它有关水晶等敏捷方法在这儿不展开了

边做边改模型（Build and Fix Model）

很多小型初创公司其实已演变为 边做边改模型, 对于开发人员来说是痛苦的, 如下图



当一个软件产品在没有规格说明或主要设计的情况下被开发时，开发者往往不得不重新对产品编码多次直到他们
得到正确稳定的产品。这种开发模型就是边做边改模型。
边做边改模型的最重要缺点是存在于需求。设计和实现中的错误要到整个产品被构建出来后才能被发现。
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能
令人满意的，其主要问题在于：
1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
2） 忽略需求环节，给软件开发带来很大的风险；
3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

其它模型还有 快速应用开发(Rapid Application Development), 喷泉, 变换模型,智能模型,WINWIN,并发开发模型,基
于构件的开发模型, 基于体系结构的开发模型, Adaptive Software Development

创业公司的软件开发
“完成比完美重要”以及“快速移动且要突破一些事情”，当你进入到创业公司的工作区域时会看到这样的箴言。

流程管理是敏捷的、进化的、机会主义的

在创业公司中流程管理代表了用于管理产品开发的所有工程活动。因为灵活性对于创业公司来说能够使用频繁的
变化至关重要，敏捷方法论被认为是最可行的流程－他们鼓励变化、允许开发去适应业务的策略。以增量和迭代
的方式快速发布可以缩短从创意构思到生产部署的时间。其中一个敏捷的变体就是精益方法，此方法倡导识别软
件业务中风险最大的部分，且据系统的测试提供最小化的可行办法，以及在下一代产品迭代时的修改计划。在此方
面，原型是缩短上市时间必不可少的。为了能够更好的设计原型，在第一阶段需要实现“软编码”的进化工作流程，
直到找到最优解为止。尽管在开发中用来鼓励快速的开发原型使用了多种方法论，但是创业公司没有一个是按照某
种方法论严格执行的。然而创业公司的不确定和快速变化的性质驱使他们寻找最小化的流程管理来实现短期的目标
，以快节奏的学习过程来适应用户，从而解决市场的不确定性。创业公司急于寻找利益增长点和获得投资，从而得
到进一步的发展。这也就意味着软件质量并非是他们主要关心的。为了能够快速的验证产品，他们倾向于利用特定
的敏捷或精益方法。

根据市场需求使用众所周知的框架来快速的适应产品的变更；
通过已有的组件来使用进化的原型和实验；
持久的客户承认成立专门的团队来作早期的采用者；
持续的价值交付，专注于从事那些为付费用户服务的核心功能;
团队的授权会影响到最终到结果；
使用量化来快速的学习用户的反馈和需求；
使用容易实现的工具来促进产品的开发，且要掌控快节奏的、不断变化的信息。
沟通

沟通包括三个部分：视觉、口头和笔头。去掉视觉和口头元素，沟通只能保留原本7%的信息。跟旁边隔间的程序
员在网络上沟通，实际上跟阅读笔头文字没有区别。您可以用文字发送问题（写邮件等于另一堆笔头文字），得到
回应（也是邮件）。如果不能提供程序员可以面对面沟通的区域，我们就进一步限制了沟通。隔离也会降低士气。

第一条：组织不应做任何事情限制沟通。典型的、也是很常见的障碍，就是格子间。在行动相对不受限的开放空间
中，团队工作更有成效。
第二条：不要将两个甚至更多团队放在同一个项目区域中。与手上任务无关的人也是障碍，这些外人的出现会造成
噪音，降低士气。
第三条：为开发团队提供白板、会议桌、马克笔。
第四条：不要试图在项目之间分享团队成员。



软件过程改进
      过程改进（Software Process improvement，SPI）帮助软件企业对其软件（制作）过程的改变（进）进行计划、
（措施）制定以及实施。 他的实施对象就是软件企业的软件过程，也就是软件产品的生产过程，当然也包括软件维
护之类的维护过程，而对于其他的过程并不关注. 五个原则:

·注重问题
·强调知识创新
·鼓励参与
·领导层的统一
·计划不断地改进 　　

为了决定你的组织是否处于CMM第一级，判断你的软件和测试团队实践是否符合以下的任何一个描述：

为了获得灵活性，软件过程大体是在项目过程中由从业者和他们的管理者临时准备的。
即使确定了一个软件过程，它不是严格维护或强制从每个阶段或迭代中严格执行的。
团队的焦点是解决眼下的危机（救火）。
当强加了严峻的截止时间时，产品的功能和质量不得不对时间表做出妥协。
意图是加强质量的活动，比如结构化的评估和测试，在项目落后于时间表时经常被削减或取消。
CMM的核心思想是: 过程, 要事先定义; 过程的实施效果, 要不断验证(可以持续改进); 过程中的基本活动形式,要保证.

软件能力成熟度模型集成(CMMI)

将现有的实施以及未来的各种能力成熟度模型进行了集成，目的就是增强并改进软件过程，以最低的成本最高的效
率，开发出最符合客户需求的高质量软件。

目前通用的成熟度模型有五级：

初始级：混乱无序的软件过程，成功与否完全依赖于个人的努力。
可重复级：有基本的项目管理过程去跟踪项目进度、成本等。
已定义级：具有过程的文档化、标准化。
量化管理级：软件质量和过程有的详细度量数据支持，并有定量的控制。
优化管理级：过程量化，并定量反馈信息，可持续改进。
人力资源能力成熟度模型PCMM（People Capability Maturity Model）

是美国卡耐基.梅隆大学的软件工程研究院（SEI）开发的一个管理架构，于1995 年推出第1版标准,随即在世界范围
内被各种商业组织、政府组织以及其他类型的组织广泛运用。后来又推出第2版标准，促使PCMM更为科学化、更具
有适用性和广泛性，同时进行了PCMM评估方法的拓展和完善，使PCMM更具实用性。

TMM测试能力成熟度等级

混沌级

1、没有专业测试团队
2、没有建立测试需求和测试用例管理

初始级

1、建立了专业测试团队

测试团队
2、实现了需求、测试用例和测试执行的管理

需求管理
测试用例管理
测试执行管理
缺陷跟踪

提高级

1、划分了测试分析、测试设计和测试执行阶段

测试需求分析

2、引入了测试分析和测试设计方法，保障了测试覆盖度

测试用例设计
评审管理

优化级

1、引入缺陷分析，发现软件开发和测试过程中质量改进点，不断优化流程
测试计划

2、引入测试度量，使得测试过程可视化，达到量化管理目标

测试度量
缺陷分析




Final
    组建敏捷团队, 需要优秀的工程师, 持续长期招聘, 创造公司的影响力, 招聘优秀与合适的人容入团队.  层级组织不
能快速应对新的市场机遇和变化，这会妨碍公司的长期生存。组织应该在跨职能团队和董事会之间分配管理职责，
从而实现扁平化并提高整体敏捷. 每一个理智的人都想在一个开放、透明、诚实、民主的环境中工作，在那里他们
的知识和诉求能够得到响应。拥有中层管理的传统的层级结构往往不能做到这一点。它仍然能够非常有效地解决问
题，但是它往往是一个冰冷的环境。敏捷团队是自组织的团队,拥有制定计划和做技术决定的自主权.如果项目成员
足够优秀,那么他们几乎可以采用任何一种过程来完成任务. 如果项目成员不够优秀,那么没有任何一种过程可以弥补
这个不足.
    团队持续进化, 淘汰白食者与未被进化者, 成员必须在环境中自我学习与进化. 凡事需要度量, 有度量才有管理.
    对于短期缺乏优秀工程师组织, 还是先成功实践CMMI过程半年以后, 再逐步尝试转化于敏捷开发. 从其中需要经
过组织与企业文化变革