敏捷之路

敏捷之路

如何走向敏捷

敏捷开发是当今软件工程和项目管理领域的前沿理论和实践方法。 越来越多的企业和团队在从传统或者无序的开发方法中走向敏捷。有人怀疑敏捷只是一个一时的潮流，但实际上它正在逐渐成为一个最终大多数相关企业都会选择的方向。我们就在这篇文章中从开发团队和项目管理方法两个角度简单探讨一下如何走向敏捷。

团队向敏捷的转变

向敏捷开发转换，首先要取得管理层的支持和团队的认同。管理层的支持是关键，但团队的认同也决定了敏捷执行的程度和结果。这个转换过程可以分几步、有选择性地在一些项目中开始。

许多企业走向敏捷是从组织培训开始的。培训可以是内部的，也可以聘请外部顾问，最重要的是做培训的人要有丰富的敏捷经验。敏捷开发是一种经验科学，书本上的知识只能起到一个了解的作用。真正的掌握需要在实践中训练。

培训第一步一般从公司的管理层开始，尤其是负责开发或工程的副总裁、经理和项目经理等。培训的过程是一个认知的过程，也是一个取得管理层支持的重要的步骤。第二步的培训会集中在开发团队中的带头人身上。有些公司采用的策略是从５０个人中选出１０个有领导潜质的人去培训。这些阶段比较典型的培训是两天的 Scrum 培训。培训以 Scrum 为主，但会涉及敏捷的方方面面。

认识敏捷后开始实施。有些公司选择小型的新项目实践敏捷开发，这样可以减少项目所受的公司其他非敏捷团队的影响，并降低风险。但并不是所有公司都有这种运气，有些公司不得不从已有项目的中间开始，也有很多成功的例子。如果从项目中间开始，或项目比较大，有些团队可能会无所适从或不知所措。但只要有上层的支持和得力的指导，并完成一两个敏捷周期，团队一般会完全转入敏捷开发的模式并不断有所提高。

项目选好后是团队的组建。敏捷的团队有以下两个特点：

·         敏捷的团队是跨领域的平行联合团队，团队中应该有来自所需要的各个平行领域的人员，包括测试人员，甚至客户代表。目的是让这个团队能胜任开发周期中的所有任务。

·         团队的职责和功能除了日常的开发任务外，要完成各种自我管理和组织功能。大多数的管理和决策不再由管理层单独掌握，而是整个团队商议决定。每个成员都要对项目管理中的范围、时间、成本、风险等的概念和管理有一定的掌握。这样每个成员在一定程度上都要成为一个传统意义上的项目经理。

在课堂上的培训对团队来说是个很好的开始，但他们更需要在实践中的指导和训练。不同的团队、不同的公司在不同的项目中会碰到不同的问题。所以敏捷项目的进行中，最好能由经验丰富的敏捷顾问指导。敏捷顾问会带团队走完一个或几个开发周期，帮助团队解决、纠正敏捷实施中的具体问题。这样开发团队会更快的进入敏捷的思维和模式。

项目管理如何过渡到敏捷

当前的开发团队在项目管理上不外乎两大类。 一类是比较正规，有不同程度的过程和方法管理的团队。 由于 PMBOK® 在中国有很多的应用，我们下面会主要谈到怎么从 PMBOK® 的方法过度到敏捷。 另一类团队是无序的或介于有序和无序之间的团队。 他们的开发管理基本基于领队人员的经验，并无成型和稳定的套路。

从 PMBOK® 到敏捷

PMBOK® 定义和描述了一套有关项目管理的知识体系．这套知识体系比较全面，涉及项目计划的集成，项目的范围、时间、质量、成本、信息交流、风险、人力和物流等各个方面。相较与敏捷开发， PMBOK® 的最大不同体现在以下方面：

Ø       PMBOK® 是计划推动的开发，一般来说要求有大量的前期规划和评估。 而敏捷是价值推动，靠经验来优化。

Ø       PMBOK® 重视文档，每个阶段都有正式的文档要求。 敏捷重视结果，文档往往被认为是一种浪费。

Ø       PMBOK® 的项目管理是自上而下的命令式管理。敏捷的管理是团队的自我管理和经理们的服务式管理。

那么 PMBOK® 在敏捷中就必须被完全抛弃吗？在一定意义上讲是这样。因为 PMBOK® 和敏捷有以上原则性的矛盾，敏捷的应用将给用 PMBOK® 管理的团队带来质的变化。但这并不等于 PMBOK® 中所有的东西都没有用处了。 实际上， PMBOK® 中的大多数知识、概念和过程都很有用处，而且在敏捷中都被用到。所以规定要有 PMBOK® 规范的企业并非要否定一切才能过度到敏捷开发的模式。

从大量的前期计划到阶段性分批计划

在 PMBOK® 中，项目开始前要在范围、执行、成本等方面制定出详细的计划。在转向敏捷的过程中，这些计划并不是完全没有了，而是被分散到各个短小的开发周期中了。例如， PMBOK® 要求项目开始前有尽可能详细的需求，并制定正规的需求更改规范和过程。 而在敏捷开发中，项目开始前有的只是一个有关要开发的产品的高层次的远景规划，产品的功能需求是在开发过程中由用户的反馈和开发团队反馈一起来推动并逐步明确和细化的。正式的需求文档变成了分散的产品的多个需求条目、功能或用户使用案例等。至于需求变动规程，大多数敏捷方法都积极预期这种变化并把对变化的管理嵌入到每个周期甚至每天的开发过程中了。

还有一点经常被用来当作敏捷的不足。那就是敏捷开发不能在一开始给出项目的成本计划。 所以看起来敏捷项目似乎无法进行成本的控制和管理，让许多外包性的项目无法采用敏捷。 如果说要有一个大概准确的项目成本评估， PMBOK® 也无法做到。 PMBOK® 的做法是把所有的需求细化，然后把对每个最小单位的估计总和起来。这样看似合理，但由于要对很久以后的开发作出估计，往往有很大的偏差。许多项目的失败就起因于开始时的一个不实际的成本预算。敏捷项目中的成本预算和管理可以用由上而下的方法。项目开始前，由总体的规划出发，把他交给整个团队，讨论评估出一个大概的范围。 在每个周期开始前，团队和用户可以再对周期的成本进行比较准确的预估和管理，这时 PMBOK® 中的由下而上的方法就完全适用了。然后，在每个周期结束后都再次根据当时的状况来调整对整个项目的成本估计。这样的成本控制和管理往往更准确、实用。

在其他 PMBOK® 中涉及的对时间、质量、风险等的计划和管理可以遵循同样的原则转化为敏捷中的阶段性计划和管理来实施。　

从由上至下命令式管理到面向团队的服务式管理

管理方式的转变是比较难的一方面。 这点在上面讨论敏捷给企业带来的变化时有所触及 。 PMBOK® 中的项目管理风格是由上而下的计划、分配、指定、跟踪、评估和管理。在敏捷开发中，团队要自我管理。计划的制定，任务的分配，质量的管理，项目的执行等都由整个团队协作进行。项目经理的职责是协调团队完成这些自我管理任务，并帮助团队排除遇到的障碍。项目经理要从命令式的管理思维转换成服务式的思维和行为。 用另一句话说就是，原来 PMBOK® 的项目经理是靠自己指挥一些人完成一项任务。而在敏捷中，项目经理可能更需要做的是建立一种机制使所有的人能在其中自我协调完成某种任务。而项目经理的日常职责是维护这种机制的正常运作和不断改进。

从‘实用主义’走向敏捷

‘实用主义’经常被处于无序或半无序状态的团队拿来标识自己。这些团队应该最容易走向敏捷。因为如果真的是实用主义的话，敏捷最实用，自然应该是必由之路。这些团队也并非都没有实施任何有序的方法，他们的领导者或技术带头人会凭经验或一定的自学掌握一些方法，然后他们会摸索着运用这些方法，有的甚至是在采用敏捷中的一些方法。这些团队如果能和经验丰富的顾问或其他运用敏捷比较成功的团队交流，往往会认识到自己摸索的局限性和离高层次敏捷开发的差距。这些差距往往不在于敏捷的形式，例如故事或需求条目墙，站立会议等，而是在于团队的开发和应变的速度、效率和自我管理能力。一旦决定采用敏捷开发，由于这些‘实用主义’的团队通常比较小而且没有任何成型的包袱，他们没有摆脱固有过程的障碍，可能会更容易地过度到敏捷开发。

 

尾声

敏捷模式继承和发展了以往的软件工程理论和实践，并熔入了人们对于软件开发的新的理解和理念。我们相信敏捷是为我国的软件企业带来效率、质量并促使开发团队职业化，推动我们赶超世界软件先锋的一个很好的机会。我们在这篇文章中从团队和项目管理两方面简单探讨了企业和团队如何走向敏捷的问题，希望能对大家有所帮助。