敏捷项目管理

与传统项目管理有什么关系？

在理解敏捷项目管理之前，我们先看一下它与传统项目管理之间有什么联系和差异。

传统项目管理模式，一般指瀑布模式。它必须完成上一阶段工作并通过检验才能启动下一阶段工作，将整个项目过程划分为五大过程组。

而敏捷项目管理模式，一般包含迭代和增量。它将整个项目过程拆分为若干个迭代，每个迭代完成一部分用户可感知的完整功能。一般情况下，每个迭代内的项目过程均遵循五大过程组。

传统项目管理模式与敏捷项目管理模式之间存在的差异，可以总结如下：

	瀑布模式	敏捷模式
核心驱动	文档和计划驱动	用户可感知的完整功能驱动
计划	提前对整个项目过程进行详细估算、分析、计划	提前对整个项目做一个粗略的计划。在每个迭代里做每个迭代的详细计划
变更	严密的合同来减少变更风险，如果改变需求需要走CR流程，整个项目过程需要重新估算和规划	基于信任，合约使变更变得简单。鼓励变化，聚焦客户价值，将有益于客户价值实现的变更在后续迭代内进行估算和规划
风险	项目交付晚，意识到风险的时间晚	每次迭代都产生可交付的功能，发现风险的时间早
可视化	项目过程是一个“黑盒子”，对于客户和供应商来说可视化较差	客户、供应商和开发人员之间是紧密连续的合作关系，项目过程可视化较好
应用场景	消耗成本较高的项目过程。如三峡工程、火箭发射	消耗成本较低的项目过程。如软件开发

我从项目团队的视角出发，归纳了在项目管理中我们通常遇到的几大类问题：

1、团队目标不一致
2、团队成员不熟悉
3、信息发布不顺畅
4、项目经常发生变更
5、不清楚，研发团队的工作量，是正常、超负荷、还是有人不饱和
6、需求延期发布成为了家常便饭，不知道什么时候会发布上线

作为项目管理的我们，不断地经历一个又一个的项目，一次次地面对相同的问题。如果我们不从中总结和提炼，我们就会反复地徘徊在丰满的理想和骨感的现实中。
敏捷思想和敏捷实践，为我们提供了一种解决方法，帮助我们解决在项目交付过程中遇到的具体问题

 

1、团队目标不一致

用电子墙和物理墙展示用户故事、需求全景图、项目进度燃尽图；

通过迭代会议和功能演示会议对齐迭代计划，项目进度、识别项目风险。

2、团队成员不熟悉

基于敏捷实践，创造更多的沟通机会，比如回顾会议、代码审查和站立会议。通过不断地创造这样的沟通机会让团队成员更加默契。

3、信息发布不顺畅

共享信息，制定沟通计划；

最大程度的可视化。

4、项目经常发生变更

基于敏捷实践，鼓励变化，聚焦客户价值。

5、不清楚，研发团队的工作量，是正常、超负荷、还是有人不饱和

通过每日站立会议，每周回顾会议，敏捷工具中的任务以及燃尽图判断研发团队的工作量，是否饱和等等

6、需求延期发布成为了家常便饭，不知道什么时候会发布上线

通过每日站立会议，每周回顾会议让团队发言遇到什么困难以及敏捷工具中的任务以及燃尽图判断，会不会导致项目延期发布等问题，提早做相应的补救方案等等。

一、敏捷项目管理定义

敏捷：是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。

敏捷项目管理：指在项目活动中运用敏捷的理念，配合专门的知识、技能、工具和方法 ，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望的过程
 

二、敏捷软件开发宣言：

我们一直在实践中探寻更好的软件开发方法，身体力行，同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

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

 

三、敏捷开发十二原则：

1. 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的行为表现。

 

四、敏捷项目管理（方法）

虽然敏捷项目管理的本质是理念，看起来很玄乎。但是敏捷先驱们基于这种里面已经开发出了非常多的看得见摸得着的敏捷管理框架，日常项目管理工作中常见管理框架有以下几种：

SCRUM

SCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。

Kanban（看板管理）

看板管理在工业企业的工序管理中，以卡片为凭证，定时定点交货的管理制度。

XP（极限编程）

极限编程注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。


敏捷流程图：
 

SCRUM框架

Scrum框架包括3个角色、3个工件、4个事件、5个价值：

3个角色

1. 产品负责人（Product Owner）：俗称PO，主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果
2. Scrum Master：流程管理员，为团队赋能，团队核心，主要负责整个 Scrum 流程在项目中的顺利实施和进行
3. 开发团队：主要负责软件产品在 Scrum 规定流程下进行开发工作，人数控制在 5~10 人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到 Sprint 的目标

3个工件

1. 产品Backlog（Product Backlog）：产品待办列表，这个列表里面包含所有的需求，都是有价值的，有次序的需求池列表。
2. SprintBacklog：俗称冲刺需求列表，也表示本次迭代需要完成的任务列表
3. 燃尽图：查看每日任务，故事燃烧情况

4个事件（Sprint本身是一个事件，包括了如下4个事件）

1. Sprint计划会议（Sprint Planning Meeting）
2. 每日站会（Daily Scrum Meeting）
3. Sprint评审会议（Sprint Review Meeting）
4. Sprint回顾会议（Sprint Retrospective Meeting）

5个价值

1. 承诺 – 愿意对目标做出承诺
2. 专注 – 把你的心思和能力都用到你承诺的工作上去
3. 开放 – Scrum 把项目中的一切开放给每个人看
4. 尊重 – 每个人都有他独特的背景和经验
5. 勇气 – 有勇气做出承诺，履行承诺，接受别人的尊重

敏捷优点和缺点

敏捷是项目管理和软件开发的一种迭代方法，可帮助团队更快地向客户，交付价，减少麻烦。敏捷团队不是把所有事情都押在“大爆炸”的发布上，而是以小的但可消耗的增量交付工作。需求、计划和结果会得到持续评估，因此团队拥有快速响应变化的机制。

1、敏捷的优点：

• 更快交付价值

敏捷是基于价值驱动交付，项目团队要频繁的且尽快的给客户交付可以使用的产品，并尽早的让让产品投入市场可以尽早的验证其商业模式和商业价值，这是敏捷提倡的核心价值之一。

• 更低的风险

敏捷提倡优先交付高价值、高风险的需求，然后交付高价值、低风险的需求、再交付低价值、高风险、最后低价值、低风险的需求。这样的好处是把最高风险的需求在项目的初期就开始做，可以最早发现该产品是否可行（通常只要1~4周）。如果因为市场、技术或者其它原因失败了，可以及时停止该项目，降低项目风险。即使这个项目失败了，这个失败的代价相对来说小一些。

• 拥抱变化

在VUCA 迭代开发的后期也接受变更。因为市场在变化，用户的期望和要求在变化，客户的需求也会随着这些因素的变化而变化，只有及时响应这些变化，并尽快予以实施，才能帮助客户在瞬息万变的市场中保证竞争力和吸引力。而敏捷能够帮助团队在小步快跑的过程中能够快速的响应变化。

• 更好的质量

敏捷提倡高频率的交付有价值的产品。每天的例会、迭代计划会议、迭代评审会、迭代回顾会议都在对可交付成果质量上进行层层把关，因为在这几个会议中会频繁讨论遇到的问题/解决方案，验收标准，DoD等等。同时，也会邀请项目干系人参加迭代评审会并对可交付成果验收和反馈，这样团队可以及时予以调整，以确保质量。

• 持续改进

敏捷提倡不断调整和优化，并在每个迭代的迭代回顾会议进行分析、讨论、总结敏捷当前迭代开发过程中需要改进或者要提升的地方，进而在下个迭代中改进、调整和优化。这是整个团队成员不断学习，不断提升自己经验、技能的一个很好的机会。另外，因为敏捷强调客户参与的重要性，对于客户的反馈意见和建议，开发团队也会及时给与相应以及反馈，让双方可以更好的合作，建立更加信任的合作关系。

• 更高的客户满意度

敏捷提倡尽早和频繁的为客户交付有价值的产品，以确保更高的质量，更高的成功率，为客户尽早带来商业投资回报率的机会。

• 更高的团队满意度

敏捷提倡仆人式的领导，SM需要给团队工作上的指导、帮助和支持，扫除团队成员工作上遇到的问题和障碍。重视并尊重团队成员的想法和意见，授权团队并引导团队成员自组织和自管理。更重要的是，团队成员可以决定要做什么、怎么做、什么时候做，并自己监控和管理工作进展，对结果负责；团队成员可以一起讨论并确认工作协议，确保考虑并接纳每个人的意见；团队成员可以一起评估故事点；同时，SM要引导团队成员之间相互协作并促进合作。通过这些，团队成员可以更高效的工作，交付的质量也会提高，团队成员的满意度也会大大提高，"A happy employee is a productive employee"，不是吗？

• 更大的灵活性

敏捷基于价值驱动，它的项目范围是可以灵活调整的，这就给项目干系人很多的灵活性来根据市场不断调整需求范围、变更以及优先级等等。另外，敏捷提倡频率与团队和客户沟通交流，并不断根据反馈和意见调整管理方法、需求流程、开发流程以及运维流程等等。还有，验收标准，都可以根据实际情况进行调整。

当然敏捷还有很多其它的优点，比如透明、简洁、高效，更早进入开发等等，在这里就不一一介绍了。

 
 

2、敏捷的缺点和不足：

尽管敏捷带来了很多改善，但是再次重申它并不是适合所有人和所有情况的。因此，了解敏捷的不足显得特别重要。知道这点后，你心理上是准备好的并且会根据具体情况来做裁剪和优化来规避或减少负面影响。

• 很难进行准确的资源规划

由于敏捷团队不是一开始就知道产品“最终的样子”，而是在过程中探索用户的需求逐渐知道产品真正的终局状态，这样一来就给前期的规划（成本，时间，资源）带来了很大的挑战（项目越大越复杂这一点变动更加明细）。

• 很难准确的定义“轻量的“或必要的文档

敏捷倡导的是用工作的软件即文档（核心是代码即文档）。整个项目用于产品开发的文档不是一开始准备好的（甚至都没有RP原型设计），而是在过程中”及时的“ just-in-time准备出来的。因此，我们看到的是非常简单的且常常被放在最后处理的文档（在项目中涉及到移交或问题分析时这一点显得尤其突出）

• 很难把握整体产品的一致性

增量交付可能有助于更快地将产品推向市场，但这也是敏捷方法论的一大缺点。因为当团队在不同的周期内对各个组件进行开发时，整体的输出往往会变得非常零散，而不是一个内部紧密集合的整体。（当项目对UI和UX有更高的要求时，这个挑战就变得更加明显）。

• 很难预测有限的终点

敏捷在一开始要求最低限度的规划，这使得交付新的、意想不到的功能时很容易偏离方向。此外，这意味着项目没有限定的终点，因为从来没有一个明确的 "最终的产品"样子。

 

那为什么互联网项目要用敏捷开发呢？
1、出成果（版本）快，互联网就是以快吃慢，一般都是迭代发布的，追求创新，说明了需要快速响应用户的变化，时间就是一切，需求不确定性高，这个在软件行业也很常见;关注用户行为，倡导以用户为中心的产品设计。很典型的例子微信，腾讯一个月开发出来的产品，根据用户体验和反馈，通过反复的小迭代来优化。

2、互联网项目中市场反响和客户体验尤为重要，需要有一个快速迭代来响应客户的需求，确保客户的满意度。如果是瀑布式开发，迭代慢，更改的成本也比较高。

3、随时应对变化，因为迭代周期的减小，使得项目的弹性更足，可以更好的适应互联网项目上更多的不确定性。
 

敏捷项目管理软件：推荐大家使用腾讯的tapd