如何践行敏捷项目管理

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

相信大部分的IT从业者都听说或了解过敏捷项目管理，敏捷不同于传统的瀑布型项目管理方式，敏捷的灵活性、适应性等特点使其更适合软件开发行业。那到底什么是敏捷项目管理，在实际工作中除了喊口号，又该如何实践敏捷管理方式？

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、敏捷开发是什么？

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

二、敏捷开发的优缺点

1、优势：

• 短期目标明确。敏捷的迭代周期短至数天，迭代期间内的目标明确。
• 按照优先级去完成任务，优先做高优先级的。不断适应变化的市场环境，使项目保持最低的风险。
• 产品开发快速且经常交付(数周而非数月)，可以很快的响应客户的需求。
• 自组织的团队有利于团队成员提高沟通能力和凝聚力。
• 更高的团队满意度。敏捷提倡仆人式的领导，SM需要给团队工作上的指导、帮助和支持，扫除团队成员工作上遇到的问题和障碍。重视并尊重团队成员的想法和意见，授权团队并引导团队成员自组织和自管理。

2、劣势

• 难以界定何为必要的文档。敏捷宣言强调能工作的软件胜过面面具到的文档，但这也不要说所有文档都不需要，必要的文档仍然需要保留，不过何为必要，就变的很难界定。
• 很难有效地进行度量。由于敏捷是以增量的方式交付的，所以跟踪进度需要你跨周期地看。而 "边走边看 "的特性意味着你不能在项目开始时设置很多KPI。这种长期的游戏使得衡量进度变得相对困难。
• 很难进行准确的资源规划。由于敏捷团队不是一开始就知道产品“最终的样子”，而是在过程中探索用户的需求逐渐知道产品真正的终局状态，这样一来就给前期的规划（成本，时间，资源）带来了很大的挑战（项目越大越复杂这一点变动更加明细）。

三、敏捷宣言

• 最重要的是通过尽早和不断交付有价值的软件满足客户需要。
• 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
• 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
• 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
• 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
• 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
• 可以工作的软件是进度的主要度量标准。
• 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
• 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
• 简单——尽可能减少工作量的艺术至关重要。
• 最好的架构、需求和设计都源自自我组织的团队。
• 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

三、敏捷实践方式

1. 看板。看板是以待办事项列表形式呈现，它以故事形式呈现给团队。让团队内的每个成员可以透明的了解当前项目的进度以及待办事项，减少沟通的成本，提高消息的一致性。
2. 站立会议。每日站会是整个Scrum框架里非常重要的一环,也是实践次数最多的一种仪式。既然是仪式，那就首先要让所有的团队成员都要感受到仪式感和认同感。要让每位团队成员感受到每日站会是一件很有意义的事情、是一件很有乐趣的事情、是一件很有收获的事情。
3. 回顾会议。回顾是最重要的一个实践,原因是它能让团队学习,改进和调整其过程。 回顾可以帮助团队从之前的产品开发工作及其过程中学习。《敏捷宣言》背后的原则之一是:“团队要定期反省如何能够做到更加有效,并 相应地调整团队的行为。

总结

敏捷不是万金油，并不一定适合所有的项目，只有最合适的管理方式，没有最好的管理方式。