日事清技术总监教你敏捷项目管理（下）
现在的项目管理工作其实分为“项目管理”、“敏捷项目管理”这两种方式，团队的项目适用于哪种方法，这个需要按照项目的特性以及团队的水平来确定。上篇文章中介绍了预测型的项目管理（回顾：预测型项目管理）
与预测型项目管理相比，敏捷有它的优势，确定短期的需求，快速迭代交付、快速验证价值，采用周期性评价代替复杂的绩效管理、让整个团队的目标一致，以价值驱动。
1
“敏捷项目管理”是一种适应型的管理方式，它以价值驱动交付，项目团队需要保证最有价值的功能最先被交付，然后通过用户的反馈得到改进的意见，及时调整适应，整个开发过程遵循计划->执行->调整的环状结构流程。
在敏捷团队中，个体和交互大于流程和工具，这要求每个团队成员都具有良好的沟通能力和专业技能。如果每个成员都是T型人才，能够胜任产品设计、开发、测试中的每个岗位，那敏捷团队将会表现的非常高效。
这样看起来，敏捷团队就像是一个特种部队，每一个成员都拥有广泛的专业技能，随时能够填补团队中的空缺，保证任务的稳定执行。
2
如果想要尝试敏捷项目管理的，可以了解以下敏捷方法：
Scrum
Scrum特指一种敏捷开发的模型。它是一个迭代小、增量性的流程，适用于任何的产品开发以及工作管理。Scrum将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标，明确地推进。
Scrum三大支柱：
1）高透明性：信息的高度透明，任何方面都能被观察到
2）检查：经常性的检查，防止重大偏差
3）适应：当发现可交付成果不合格时，应该及时修正，减少偏差
Scrum 团队：
1）开发团队：是自组织的、跨职能的、他们拥有创造产品增量所需要的全部技能，包括设计，类似特种部队。
2）产品负责人：是管理产品待开发项的唯一负责人，类似军队中的军长。
3）ScrumMaster：确保Scrum被理解并实施，类似军队中的政委。
Scrum 事件：
1）迭代：一个迭代就是一个时间盒（有时间限制），在这个时间盒中至少应该有产品发布，这个时间盒的长度一般为1~6周的时间。
2）迭代计划会议：确定在这个迭代中需要交付哪些产品以及如何达成目标。
3）每日立会：每天15分钟的时间，开发团队需要同步他们的活动，彼此进行沟通以及提出问题。
4）迭代评审：迭代结束时举行的会议，产品负责人决定本次迭代是否完成。
5）迭代回顾：回顾反思整个迭代过程需要改进的地方。
Scrum 工件：
1）产品待开发项：所有需要开发的功能。
2）迭代待开发项：产品待开发项的分解，一次可以交付的最小迭代目标。
3）燃尽图：翻译工作量完成状态的趋势图。
极限编程（XP）
XP是敏捷方法中的一种软件开发方法。如果说Scrum更加关注项目管理工作的话，那么XP更加关注软件开发的良好实践。XP的核心价值是监督、沟通、反馈、勇气、尊重，这些价值体现在XP的整个生命周期中。
极限偏差的核心实践：
特性驱动开发（ FDD）
项目团队使用FDD的方法首先可以为产品开发一个整体的模型，构建特性列表和工作计划，然后对开发的特性进行设计和构建迭代。
FDD推荐了一系列的良好实践，这些都是从软件工程中延伸而来。这些实践包括：
领域对象建模
安装特性开发
类拥有权
特性小组
审查
配置管理
定期构建
可视性进度报告
动态系统开发方法
DSDM
DSDM倡导以业务为核心，快速而有效地进行系统开发。其基本的观点是，任何事情都不可能一次性地圆满完成，应该用20%的时间完成80%的有用功能，以适合商业目的为准。
实施的思路是，在时间进度和可用资源预先固定的情况下，力争最大化地满足业务需求（传统方法一步是需求固定，时间和资源可变），交付所需的系统。
对于交付的系统，必须达到足够的稳定程度以在时间环境中运行；对业务方面的紧急需求，也要求能够在短时间内得到满足，然后在以后迭代阶段中对功能进行进一步完善。
DSDM周期有7个阶段：
1）项目准备阶段
2）可行性检验局阶段
3）业务研究阶段
4）功能建模阶段
5）系统设计编程阶段
6）实施阶段
7）项目后期阶段
精益开发（LEAN）
精益开发不是敏捷的方法，但是精益和敏捷的价值观是紧密相关的，精益的一系列原则是从精益生产中来的，并应用于软件开发。
对于精益来说有7个核心的概念：
其中消除浪费是为了最大化价值。浪费来自一些不必要的功能。为了提升我们在项目中获得的价值，我们必须识别一种方法以消除浪费。
看板方法（Kanban ）
看板开发方法是近年来最热门的敏捷和精益开发方法。越来越多的案例表明，它能够改善协作、优化管理，显著提高交付速度、质量和灵活性。看板开发方法的规则简单，但其有效的实施依赖于对原理的理解、对原则的坚持和实践的应变。
一个看板在敏捷开发中的最佳实践如图：
每个卡片代表开发中的各个流程，图中以规划->开发->测试->发布这样的流程来进行管理，开发任务在这个工作流中扭转执行，最终被发布。整个过程显的十分灵活可控。
“敏捷项目管理”在质量保证的流程中需要借助一些自动化方式，如：
1）持续集成（CI）；
2）持续部署（CD）；
3）测试驱动开发（TDD）；
4）DevOps(开发、运维、质量管理一体化)；
通过自动化的流程，提高交付的效率，减少人为出错的几率，提升质量。
3
敏捷看似简单，但想要达到真正意义上的敏捷是比较困难的。比如敏捷提倡“拥抱变化 高于 遵循计划”这在很多团队执行时往往会陷入两个极端 : 要么根本不做规划，要么就在计划上投入大量的精力直到自己确信计划是正确的。
不做基本规划的小组可能连什么时间交付产品都无法回答，而做了大量计划的小组会自欺欺人地认为某个计划是“正确的”，他们的计划也许更全面，但并不意味更准确或更有用。
这两种极端都是敏捷需要避免的，“我们实施敏捷，不再需要计划和文档了”的论调是极其错误的。
敏捷不是不需要计划，相反它需要更多的规划。不确定性是影响计划正确的主要因素，对大部分不确定而言，获取知识、减少不确定性的唯一办法是开发得到一些原型，收集反馈，然后分析其价值，最后做出调整，这是规划-执行-调整的方式。
一个项目的不确定性越高，敏捷开发方法对取得成功就越至关重要，不断学习和调整是敏捷开发的核心。
（日事情订阅号（rishiqingv）后台回复关键词“敏捷开发”，获取日事清敏捷开发白皮书）
