theWay2Agile

敏捷之路如何走向敏捷敏捷开发是当今软件工程和项目管理领域的前沿理论和实践方法。越来越多的企业和团队在从传统或者无序的开发方法中走向敏捷。敏捷不是一个一时的潮流，它在逐渐成为一个最终大多数相关企业都会选择的方向。那么我们为什么要走向敏捷呢？敏捷开发能在现实中给我们的企业和个人带来什么呢?敏捷带来的变化对于企业来说，敏捷的优势是显而易见的。第一，敏捷开发相对于传统的瀑布或迭代开发来说更能适应需求的变化，而且在开发过程中用户和开发团队的反馈会给产品的开发带来极大的价值，最终的产品或软件服务将更能满足市场和用户的需求。第二，敏捷开发过程更精炼、高效、高质，能给企业带来更大、更快的投资回报率。第三，如果你要走敏捷之路，你就要首先建立一个敏捷的团队，一个稳定、高效、自我管理的的开发团队。人才是一个企业竞争的核心，但人才不仅仅是选出来的，人才更是培养出来的。敏捷的推广和应用能给企业带来更强的来自人才的核心竞争力。敏捷开发对开发人员有很高的要求。每一个敏捷团队成员都应成为一个自觉、自知、自信的团队合作者。一个可以和大多数人合作的成员要具备诚信的工作态度，和一定的社交和沟通能力。他或她每天都有可能是一个领导者，同时又是一个被领导者。在每个开发周期中，设计要团队自己完成，所有细化的任务要成员们主动承担，成员之间每天都要自由精确的交流各种信息，团队要自己安排进度保证每个周期的任务和质量。在这样一个频繁、自由地交流，紧张有序地工作的团队，每个人的技术能力、评估能力、组织能力、表达演讲能力、和社交能力都会得到高强度的训练和提高。还有，敏捷团队要真的实现自我管理，每个成员都要对项目管理中的范围、时间、成本、风险等的概念和管理有一定的掌握。这样每个成员都要在一定程度上成为一个传统意义上的项目经理，从而在项目进程中共同管理和执行。如果有人跟不上这种团队的发展，就会感觉很不舒服。不适应成员自动退出或被团队请退的例子是时有发生的。所以一个稳定后的敏捷团队一般来说都会是一个出色的高效的团队。如何走向敏捷当前的开发团队在开发的理念和方法上不外乎两大类。一类是比较正规，有不同程度的过程和方法管理的团队。PMBOK®在中国有很多的应用，我们下面会谈到怎么从PMBOK®的方法过度到敏捷。另一类团队是无序的或介于有序和无序之间的团队。他们的开发方式基本基于领队人员的经验，并无成型和稳定的套路。这种团队一旦认识到敏捷可以带来的收益，应该比较容易采纳敏捷开发。从PMBOK®到敏捷PMBOK®定义和描述了一套有关项目管理的知识体系．这套知识体系比较全面，涉及项目计划的集成，项目的范围、时间、质量、成本、信息交流、风险、人力和物流等各个方面。相较与敏捷开发，PMBOK®的最大不同体现在以下方面：PMBOK®是计划推动的开发，一般来说要求有大量的前期规划和评估。而敏捷是价值推动，靠经验来优化。PMBOK®重视文档，每个阶段都有正式的文档要求。敏捷重视结果，文档往往被认为是一种浪费。PMBOK®的项目管理是自上而下的命令式管理。敏捷的管理是团队的自我管理和经理们的服务式管理。那么PMBOK®在敏捷中就必须被完全抛弃吗？在一定意义上讲是这样。因为PMBOK®和敏捷有以上原则性的矛盾，敏捷的应用将给用PMBOK®管理的团队带来质的变化。但这并不等于PMBOK®中所有的东西都没有用处了。实际上，PMBOK®中的大多数知识、概念和过程都很有用处，而且在敏捷中都被用到。所以规定要有PMBOK®规范的企业并非要否定一切才能过度到敏捷开发的模式。从大量的前期计划到阶段性分批计划在PMBOK®中，项目开始前要在范围、执行、成本等方面制定出详细的计划。在转向敏捷的过程中，这些计划并不是完全没有了，而是被分散到各个短小的开发周期中了。例如，PMBOK®要求项目开始前有尽可能详细的需求，并制定正规的需求更改规范和过程。而在敏捷开发中，项目开始前有的只是一个有关要开发的产品的高层次的远景规划，产品的功能需求是在开发过程中由用户的反馈和开发团队反馈一起来推动并逐步明确和细化的。正式的需求文档变成了分散的产品的多个需求条目、功能或用户使用案例等。至于需求变动规程，大多数敏捷方法都积极预期这种变化并把对变化的管理嵌入到每个周期甚至每天的开发过程中了。还有一点经常被用来当作敏捷的不足。那就是敏捷开发不能在一开始给出项目的成本计划。所以看起来敏捷项目似乎无法进行成本的控制和管理，让许多外包性的项目无法采用敏捷。如果说要有一个大概准确的项目成本评估，PMBOK®也无法做到。PMBOK®的做法是把所有的需求细化，然后把对每个最小单位的估计总和起来。这样看似合理，但由于要对很久以后的开发作出估计，往往有很大的偏差。许多项目的失败就起因于开始时的一个不实际的成本预算。敏捷项目中的成本预算和管理可以用由上而下的方法。项目开始前，由总体的规划出发，把他交给整个团队，讨论评估出一个大概的范围。在每个周期开始前，团队和用户可以再对周期的成本进行比较准确的预估和管理，这时PMBOK®中的由下而上的方法就完全适用了。然后，在每个周期结束后都再次根据当时的状况来调整对整个项目的成本估计。这样的成本控制和管理往往更准确、实用。在其他PMBOK®中涉及的对时间、质量、风险等的计划和管理可以遵循同样的原则转化为敏捷中的阶段性计划和管理来实施。从由上至下命令式管理到面向团队的服务式管理管理方式的转变是比较难的一方面。PMBOK®中的项目管理风格是由上而下的计划、分配、指定、跟踪、评估和管理。在敏捷开发中，团队要自我管理。计划的制定，任务的分配，质量的管理，项目的执行等都由整个团队协作进行。项目经理的职责是协调团队完成这些自我管理任务，并帮助团队排除遇到的障碍。项目经理要从命令式的管理思维转换成服务式的思维和行为。用另一句话说就是，原来PMBOK®的项目经理是靠自己指挥一些人完成一项任务。而在敏捷中，项目经理可能更需要做的是建立一种机制使所有的人能在其中自我协调完成某种任务。而项目经理的日常职责是维护这种机制的正常运作和不断改进。从‘实用主义’走向敏捷实用主义有时会被某些自由无序的开发团队用来标识自己。如果真的是实用主义的话，敏捷最实用，应该是这种团队适合的开发模式。这些团队也并非都没有实施任何有序的方法，他们的领导者或技术带头人会凭经验或一定的自学掌握一些方法，然后他们会摸索着运用这些方法，有的甚至是在采用敏捷中的一些方法。这种团队如果能和经验丰富的顾问或其他运用敏捷比较成功的团队交流，往往会认识到自己摸索的局限性和离高层次敏捷开发的差距。一旦决定采用敏捷开发，由于这些团队通常比较小而且没有任何包袱，他们没有摆脱固有过程的困难，可能会更容易地过度到敏捷开发。而他们的关键在于放开视野，看到自己和高效的敏捷开发的差距。常见障碍及对策敏捷开发的概念和原则简单易懂。但这些简单易懂的概念在实际的应用中并不那么简单，也容易造成一些理解上的偏差。有些团队从对一些敏捷书籍的阅读和几个关键成员之间的讨论开始运用敏捷，经常会遇到很多问题或障碍。在面对敏捷开发的时候，有些团队的经理会告诉我们他们现在的开发方法就很好，不用改为敏捷，或者他们现在的方法就“很象”敏捷。如果这是真的，并且你们的客户很满意，市场很成功，也许你们的确不用改变。但是想一想IBM或者微软，他们的产品应该说是成功，他们的客户也许比你们的更满意，但他们都在走向敏捷。我们的经验告诉我们，这种拒绝的说法往往会另有隐情。走向敏捷往往意味着改变，改变意味着加倍的努力和可能的对成员效绩评估的方法的改变，这些都有可能威胁某些团队成员的发展道路和现有利益。如果要走向敏捷，不仅要让团队认识到敏捷给企业带来的好处，还要把每个人的利益和向敏捷的过度关连起来，争取让敏捷给每个人都带来多方面的提高。在走向敏捷的过程中，一定要选择一位合适的带头人来领导和推动。敏捷的模式强调协作和沟通，如果这位负责人习惯于命令和指挥，那他很可能会打消团队内想协作和互助的积极性。如果他更注重的是项目的数字和报表而不是最终结果，那走向敏捷的努力自然会前功尽弃。如果一位经理更关心的是自己的权力和权威，那就不可能有一个自我管理的团队。敏捷方法强调的是团队每个成员间的协调和合作，而不时某一个人的功劳。尾声敏捷模式继承和发展了以往的软件工程理论和实践，并熔入了人们对于软件开发的新的理解和理念。我们相信敏捷是为我国的软件企业带来效率、质量并促使开发团队职业化，推动我们赶超世界软件先锋的一个很好的机会。我们希望能尽我们一份力，使我国企业走向敏捷之路更平坦、更高速。