敏捷这个概念来自于2001所发表的一个敏捷软件开发宣言。
其中包括了4个价值观：
- Individuals and interactions over processes and tools
个体和互动高于流程和工具 - Working software over comprehensive documentation
工作的软件高于详尽的文档 - Customer collaboration over contract negotiation
客户合作高于合同谈判 - Responding to change over following a plan
响应变化高于遵循计划
敏捷开始用于软件开发项目，后来这种方法也扩展到各个类型项目，并衍生出ACP(Agile Certified Practitioner)敏捷管理专业人士资格认证。
为何需要敏捷？
敏捷之所以被提出来，就是因为原先线性的项目工作方法，越来越难以满足变化的需求。做软件开发的都知道瀑布开发模型：先需求分析，再系统设计，再系统开发，再系统测试，最后验收上线。
在这种模型中，客户除了最初介绍需求，和最后验收时和开发团队互动较多外，中间开发过程中几乎很少与开发团队互动。如果以时间为横轴，以互动程度为纵轴画一个曲线，那看上去就是一个大大的“坑”。
瀑布开发坑
采用这种模型开发，要求前期需求非常明确，在整个开发过程中都不会变化。可是对于软件开发来讲，要求需求不变，却是一个难以实现的奢望。更多的时候，是客户自己都不知道自己想要什么，或者虽然自己知道但是没有说清楚；或者说清楚了，开发人员没有理解到位；或者理解到位了，但是开发过程中环境发生了变化。假设你按照客户要求做了三个月，最后客户在测试阶段告诉你，之前提的需求全都不对要重新来过，你会不会崩溃？
敏捷项目管理，正式要解决这样的问题。
具体如何做？
如何解决呢，就是将一个较长时间的项目拆解成一个个独立可交付的小项目，每个小项目中有独立的需求、设计、开发、测试、验收上线过程。
具体来说，有如下方法。
- 与客户建立信任
首先要与客户建立信任关系，让客户相信你有能力、有意愿开发出客户想要的系统。因为信任，客户才不会在开始时要求将详细的系统规格写入合同。因为信任，客户才会和开发团队一起探索需求。因为信任，客户才会接受在系统不完备的情况下就开始试用。
- 和客户一起探索需求
客户提出要做什么的需求后（比如A,B,C），先不要想如何去实现，而是先想客户为何提出这个需求，根据自己的对业务、流程、行业的了解，和客户一起可以真正高效解决真实问题的方法（这时需求也许变成了A,B,D）。
要做什么确定下来后，还不要急着想如何实现，再想想这个需求涉及哪些人，哪些是真正使用的人，哪些是受影响的人，哪些是关注此事的人，他们都有什么诉求。
最后将需求写成一个个的用户故事：
某某，。。。作为一个什么角色
想要，。。。实现什么功能
以便，。。。达到什么目的
- 将需求排优先级
每一个需求，根据需求对用户满意度的影响程度，分为必须做、应该做，可以做，不用做四类。优先做必须做的。
- 每两周一个迭代交付
两周之内，用户、分析人员、设计人员、开发人员、测试人员全员参与，一起完成一个可用版本的交付。 开发过程中，可以用燃尽图直观显示开发进度与剩余时间。
- PM充当教练角色
敏捷项目中，PM不是作为沟通的核心，而是充当教练的角色，为每个其他角色成员赋能，让每个成员主动贡献自己力量，对自己的结果负责。
关于敏捷的误解
对于敏捷开发，人们经常有如下几个误解。
- 敏捷不写文档
敏捷虽然主张工作的软件高于详尽的文档，意思是不要过多的文档，但并非不要任何文档。对于必要的文档，如本身就是项目要求的交付物的用户手册，重要沟通结论如接口文档，监管要求文件或者新人培训资料还是需要写的。
- 敏捷开发软件更快
敏捷开发，并不一定比瀑布开发时间更短，实际上，对于需求固定的软件开发，瀑布方式是效率最高的。敏捷开发只是更适合需求变化的软件开发。
网友评论