软件开发模型与过程改进

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

WaterFall模型

缺点
•  Requirements must be known  up  front:  It's difficul t to imagine every detail  in advance. Most projects start out 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 problems are found,  but  it  leaves very  li ttle  time  for  correction,  resulting  in  potentially disastrous effects  on  project schedule and cost.
•  Lack of  parallelism: Each phase is executed to completion. Disjointed parts of the system could otherwise be completed  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示例图:

来自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 smaller 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 应用程序，您可能但愿频繁推出更新以添加新功能，或者在得到客户的反馈时改进该应用程序。您没必要担忧繁重的版本控制任务，或者维护文件以跟踪哪一个客户端具备哪一个版本。若是版本发布涉及到客户端的更改或工做，您可能不但愿频繁地作出更新。此外，频繁的迭代也许是个好主意，由于您知道本身能够在数周而不是数月内实现和发布更改。

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

适应
在敏捷开发方法中，即便是后期的需求更改也是受欢迎的。很长时期以来，软件专业人员不遗余力地避免或减小作出后期更改。然而，因为业务环境可能快速变化，软件需求也应当如此。

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

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

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

您的公司准备好了?

协商文化
开放和诚实的讨论在任何组织中都很是重要，可是若是您计划采用敏捷方法，则组织的各个部门必须良好沟通而且可以在必要时作出妥协。

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

规模较小、能力级别较高的团队
只需使用少许没必要应付额外官僚做风的很是优秀的开发人员便可完成大量的工做。

促进团队成员之间快速沟通的环境。
业务需求须要在眼下而不是在下周获得知足。您的组织文化须要是快速响应的文化，而不是在过程当中束手无策的文化。

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

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

共性

拥抱变化（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

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

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

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

不少小型初创公司其实已演变为 边作边改模型, 对于开发人员来讲是痛苦的, 以下图

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

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

创业公司的软件开发

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

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

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

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

沟通

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

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

 

软件过程改进

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

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

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

1. 为了得到灵活性，软件过程大致是在项目过程当中由从业者和他们的管理者临时准备的。
2. 即便肯定了一个软件过程，它不是严格维护或强制从每一个阶段或迭代中严格执行的。
3. 团队的焦点是解决眼下的危机（救火）。
4. 当强加了严峻的截止时间时，产品的功能和质量不得不对时间表作出妥协。
5. 意图是增强质量的活动，好比结构化的评估和测试，在项目落后于时间表时常常被削减或取消。

CMM的核心思想是: 过程, 要事先定义; 过程的实施效果, 要不断验证(能够持续改进); 过程当中的基本活动形式,要保证.

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

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

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

• 初始级：混乱无序的软件过程，成功与否彻底依赖于我的的努力。
• 可重复级：有基本的项目管理过程去跟踪项目进度、成本等。
• 已定义级：具备过程的文档化、标准化。
• 量化管理级：软件质量和过程有的详细度量数据支持，并有定量的控制。
• 优化管理级：过程量化，并定量反馈信息，可持续改进。

人力资源能力成熟度模型PCMM（People Capability Maturity Model）

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

TMM测试能力成熟度等级

混沌级

一、没有专业测试团队
二、没有创建测试需求和测试用例管理

初始级

一、创建了专业测试团队

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

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

提升级

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

测试需求分析

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

测试用例设计
评审管理

优化级

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

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

测试度量
缺陷分析

 

Final

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

    快速反馈（在全部层面，为了更快速响应、更快速的发现问题和机会）
    权力下放和透明的信息流（为了更快地解决问题）
    学习和知识共享（为了解决复杂问题）

--------------------------------------------------------------------------------------------------------------------------------------------

今天先到这儿,但愿对您在团队管理, 项目管理,产品管理 有参考做用 , 您可能感兴趣的文章:
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与我的目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变

若有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注个人微信订阅号：

做者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面明显位置给出原文链接，不然保留追究法律责任的权利。
该文章也同时发布在个人独立博客中-Petter Liu Blog。