现代项目管理敏捷趋势

敏捷开发（Agile development）已成为在国际上被广泛认可的项目管理框架和方法，近年来在国内软件行业更是发展的如火如荼，在软件行业，如果不知道敏捷就会业内同行被鄙视了。敏捷似乎大有取代传统瀑布模型的趋势，然而是否所有软件项目都适合敏捷开发？敏捷方法可否用于其他领域的项目管理？瀑布的模型真的要扔进垃圾桶么？做了燃尽图，每天开站会真的就是敏捷了么？

敏捷起源于软件开发行业，2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的《敏捷宣言》，传递给世界，宣告了敏捷开发运动的开始。

一、敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

应该说敏捷是吸收了传统精益、看板、现代教练技术的精髓，首先在软件开发行业诞生发展，以可视化管理、项目范围管理、质量管理和团队绩效为着力点，快速响应变化，执行过程中频繁的失败，不断试错、得到反馈后持续校正的一系列简单却互相依赖的最佳实践组成。这些最佳实践不断提炼成为行业标准动作，并结合在一起形成了一个胜于部分结合的整体框架体系、方法论及工具包集合。

目前敏捷开发流派有很多，主要有：SCRUM，Crystal,特征驱动软件开发（Feature Driven Development，简称FDD），自适应软件开发(Adaptive Software Development，简称ASD)，以及最重要的极限编程(eXtreme Programming,简称XP)，其中以SCRUM最为流行，下文也主要以SCRUM框架和实践作为讨论的蓝本。

二、预测性和经验主义螺旋发展

传统项目管理都期望实现两个目标：可控性与可预测性。软件开发中长期实用的瀑布模型就是典范，预测生命周期在早期确定范围及时间和成本，充分了解拟交付的产品，有厚实的行业基础，能整批一次性交付产品。经一系列顺序或交叠阶段，每个阶段都有本质的差别，各个阶段由不同的业务领域的专业人士负责，客户只需要在项目的两端参与，即项目启动时提需求，项目收尾时做验收。

传统的瀑布模型中项目的管理者会花费长达数月的时间去规划所有的细节，确保不会出现任何疏漏，不会超出预算，每件事情都能按照计划完成。但这种美好的设想往往不会变成现实。虽然付出了大量努力去规划细节，限制潜在变化，并预测未知因素，但到最后这些努力大都徒劳无功。在ICT行业实际项目中我们往往发现再完美的计划也不得不面对频繁的变更。而管理者一方面会陷入对完美计划的执着，试图把项目活动限制在充满彩色编码的图形和曲线里，花费大量人力去制作WBS和甘特图会成为行动的负累，任务分解的越具体，活动之间的依赖性和耦合性也就越强。面对新问题的变更处理能力很弱，项目活动之间解耦工作也会异常困难；

而此时很多的项目管理者不愿意承认自己失败，完美的计划则变成了给发起人和客户汇报沟通的利器，而项目的实际控制权完全交到经验主义者的手里。这就是我们在组织中经常看到的两层皮现象：计划和实际项目实际活动的严重的脱离；

经验主义者一方面充满了对教条主义的管理层的鄙视，在实际操刀项目中把自己变成一个救火队员，每天面对各种突发事件，但因为缺乏大局观和标准动作的提炼。同样一个坑，频繁的掉进去不断的交学费。变更的代价随着时间的推移变得越来越大。

在需求不可能一次搞清楚，甚至客户也说不明白自己想要什么的今天。在开发过程中都需要人们不断的去发现新问题，拥抱变更。采用自组织方式，激发每个人的激情和灵感，不断的学习、通过行动快速试错，进而反思校正，再持续迭代；频繁的失败，从而加大成功的概率。这应该是敏捷开发的一个基本思路。可以说敏捷是在项目风险较大，项目范围不明确的情况下，在预测性和经验主义之间选择了一条中庸的道路。

三、敏捷的框架

Scrum是一个过程框架，自上世纪90年代初以来，它就已经被应用于管理复杂产品的开发上。Scrum并不是构建产品的一种过程或一项技术，倒不如说，它是一个框架，在此框架中可以使用各种不同的过程和技术。让您的产品管理和开发实践的相对成效更加清楚地显现出来。

每个Sprint都可以被视为一个项目，为期不超过一个月。就如同项目一样，Sprint被用于完成某些事情。每个Sprint都会定义要开发什么，还有一份设计过和灵活的计划用来指导如何做这些事、工作内容和最终产品。Sprint的长度限制在一个月内。当 Sprint的长度太长的话，复杂性也有可能会增加，同时风险也有可能会增加。Sprint 通过确保至少每月一次对达成目标的进度进行检视和适应，来实现可预测性。Sprint 同时也把风险限制在一个月的成本上。

四、敏捷的标准动作和仪式

敏捷不意味着不再重视计划，而是计划变得更加频繁；仪式感也必不可少；没有这些都会让您的敏捷不复存在。基本流程是：首先负责人（通常称之为产品负责人，PO）从客户和/或组织那里了解到他们的想法，然后创建一个排好优先级的产品待办事项列表。跨职能团队从这份列表中领取任务，频繁定期地交付小的可运行的产品。在某个时间点，团队演示他们的工作并进行总结回顾。

如果您使用迭代，就要制定时间计划，因为迭代是个时间箱。按照定义，团队在时间结束时完成相应的工作。产品负责人决定未完成的工作移至下个迭代还是移到更往后的产品路线图。如果团队使用像Scrum中的迭代，那么就是以有优先级的待办事项为始，以演示和总结回顾为终。如果团队使用工作流，就可以随时演示和回顾。以下是Scrum几个会议：

1、计划会议

要做的工作在计划会议中来做计划。这份工作计划是由整个团队共同协作完成的。计划会议是限时的，以一个月的 Sprint来说最长8小时为上限。对于较短的Sprint，会议时间通常会缩短。每个参会者都理解会议的目的。团队需遵守时间盒的规则。计划会议回答以下问题:接下来的交付的增量中要包含什么内容? 要如何完成交付增量所需的工作?

2、每日站会

每日站会是开发团队的一个以15分钟为限的事件。每日站会在每一天都举行。在站会上，开发团队为接下来的24小时的工作制定计划。通过检视上次站会以来的工作和预测即将到来的工作来优化团队协作和性能。每日Scrum会议不针对某一问题进行深入讨论。站会在同一时间同一地点举行，以便降低复杂性。所有团队成员站在看板前，团队成员按照下面的结构做简单的陈述，
1）昨天，我做了什么？
2）今天，我标准备做什么？
3）是否有任何障碍在阻碍我达成目标？

3、评审会议

评审会议在 Sprint快结束时举行 ，用以检视所交付的产品增量并按需调整产品待办列表。在Sprint评审会议中，Scrum团队和利益攸关者协同讨论在这次Sprint中所完成的工作。根据完成情况和Sprint期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。对于长度为一个月的Sprint来说，评审会议时间最长不超过4小时。对于较短的Sprint来说，会议时间通常会缩短。Scrum Master要确保会议举行，并且每个参会者都明白会议的目的。Scrum Master教导每位参会者遵守时间盒的规则。

4、回顾会议

回顾会议发生在评审会议结束之后，下个Sprint计划会议之前。对于长度为一个月的Sprint来说，回顾会议时间最长不超过3小时。主要用来总结经验教训，提炼最佳实践， 在Sprint回顾会议结束时，Scrum团队应该明确接下来的Sprint中需要实施的改进。

五、敏捷的角色

先讲一则故事：一天，一头猪和一只鸡在路上散步。鸡对猪说：“嗨，我们合伙开一家餐馆怎么样？”猪回头看了一下鸡说：“好主意，那你准备给餐馆起什么名字呢？”鸡想了想说：“叫‘火腿和鸡蛋’怎么样？”“那可不行”，猪说：“我把自己全搭进去了，而你只是参与而已。”

这则故事应用在敏捷开发，用来说明不同角色的职责。“猪”是在Scrum过程中全身投入项目的各种角色，他们在项目中承担实际工作。他们有些像上边那个笑话里的猪，要把自己身上的肉贡献出来。“鸡”并不是实际Scrum过程的一部分，但是必须考虑他们。如公司测试工程师、UI工程师、QA、客户等为鸡类角色。Scrum教练参与会议以控制迭代及其过程。但实际项目中往往是猪类角色没有发言，鸡类角色喋喋不休。

从这个故事引申出来这样的结论：猪类才是团队的核心，拥有较大的话语权；而鸡仅仅为部分参与者或者关联者，拥有较少的话语权，并明确规定在类似于站立会议中鸡类人员不得讲话、评论等，下面介绍在敏捷中的几个关键的“猪”

1、产品负责人

产品负责人负责最大化产品和开发团队工作的价值。客户往往不知道自己需要什么，直到产品经理能把他有体感的产品原型摆在面前，而一个ICT软件产品，我们往往发现有近60%的功能客户从来没有使用过，属于过度开发。负责管理产品待办列表的唯一责任人，通过产品待办列表来解决上述问题包括: 清晰地表述产品待办列表项;对产品待办列表项进行排序，使其最好地实现目标和使命;优化开发团队所执行工作的价值; 产品功能优先级排序，确保产品待办列表对所有人是可见、透明和清晰的，同时显示团队下一步要做的工作; 以及确保开发团队对产品待办列表项有足够深的了解。产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。然而无论何者，产品负责人是负最终责任的人。

2、开发团队

开发团队包含了各种专业人员，负责在冲刺完成时交付潜在可发布并且“完成”的产品增量。只有开发团队成员才能创建增量。开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。由此产生的正面效应，能最大化开发团队的整体效率和效用。他们是自组织的，是跨职能的，团队作为一个整体，拥有创建产品增量所需的全部技能;开发团队最佳规模通常维持在5-9人，过少的开发团队，成员之间没有足够的互动。过大的开发团队会产生太多的复杂性，产生沟通衰减，不便于经验过程管理

3、敏捷教练

敏捷教练对团队而言，他/她是一位服务型领导。帮助团队之外的人了解他/她如何与团队交互是有益的，通过改变他/她们与团队的互动方式来最大化 团队所创造的价值。他要尽可能确保团队中的每个人都能理解目标、范围和产品域； 他作为团队的牧羊犬要移除开发团队工作进展中的障碍;在组织范围内规划敏捷标准动作的实施;维持自组织团队管理高效运作。

六、敏捷不仅适用于软件行业

从上面的介绍我们可以了解，敏捷其实就是一套最佳实践集合框架体系，以可视化、持续试错校正，自组织、始终关注最终可交付成果，不断适应环境拥抱变化为支柱，不断提炼而成的标准动作，流程和价值体系。

近年来敏捷的流行程度很高，但并非所有的软件开发都适合敏捷，如产品范围相对明确、产品路线图比较清晰的移动通信4G的底层协议开发，如果使用敏捷，有可能会产生更多的浪费和沟通中更高的交易成本。一些组织结构相对稳定，文化更强调执行力的企业在推广敏捷时也会有诸多的不适。假设一个水电站项目全盘使用敏捷方法也将无异于一场灾难，因此采用敏捷开发一定要针对自身组织形态和项目特点，不可僵化使用。

随着信息产业的高速发展，在大量的敏捷最佳实践的堆砌下，敏捷的价值体系和方法论日益成熟。适用各种场景的工具箱也很完善。企业敏捷转型中的各种问题也都充分的暴露并提炼。敏捷也可以说是在传统的预测、控制性项目管理方法论和经验主义之间找到了一条新的发展道路。

在一些大型企业的项目部，经常能看到墙上贴着制作精美的WBS，甘特图；但3、5个月不进行更新，工程实际进度和墙上的计划已经完全无法对应。计划文档只是用来给领导汇报或者是装点门面。选择鸵鸟的方式抗拒变化或沉浸在灾难现场充当救火队员，明显都不是现代项目管理者应有的态度。人们再面对变更时大都要经历一个从抗拒到接受的心路历程，

我们尝试在一些传统企业推行一些适应本组织特点的敏捷实践，如看板、站会、用户故事、快速迭代、燃尽图、最小可交付价值（NVP），取得了一定的效果。而这些实践和工件中的相当部分本来就来自传统制造行业。诸行无常，唯有变化是唯一不变的；在应对变化、加速交付上，敏捷的体系有着天然的优势。逐步理解和接受敏捷的价值体系及敏捷道路上不断试错前行。这也许是传统企业不得不面对的挑战。