背景
随着项目管理专业的发展，业内越来越多的项目经理开始实践敏捷管理。
图中项目限制
喜欢，
某个功能集的敏捷过程是：
1）首先制作一个产品原型，然后向团队解释
2）让开发者评估工作量
3）任务划分的原则是三天为一个功能开发期，超过三天则进一步细分。
4）然后进入快速开发和测试
5）项目经理通过早会控制进度并沟通协调
6)···
另一个例子，
对于某个产品任务：每月推出一个版本的网页、APP、微信的敏捷流程为：
1）月底安排所需的功能
2）每周举行一次会议，与开发人员讨论时间表和要求
3）对每个功能进行分组规划并进行小迭代和冲刺
敏捷管理可以应对项目的不确定性并满足客户需求。
在TO B领域，做敏捷的目的是快速迭代版本并与客户确认，让客户知道项目组做了某事，并能尽快判断产品是否符合预期，以便修正可以提早做出，并且可以在整个过程中保持工作。 效力。
程序员有画外音，正在吹牛。 敏捷性怎么样？ 每天只是改变需求、挖洞、修复bug……
笔者在观察和参与了很多敏捷项目后发现，目前做敏捷管理的组织存在两个问题：
1）认识到敏捷的重要性，想要敏捷，但不知道如何开始。
2）敏捷组织在交付和需求方面更加敏捷，但在其他方面并不敏捷。
问题导致敏捷执行结果不理想。
笔者认为，通过重新认识敏捷的内涵、实事求是、内化其实施，这些问题都可以得到解决。
01
我们先看一下基本内涵：
敏捷价值观：追求高效、透明、清晰、简单、及时响应变化、专注、试错
敏捷原则：目标是持续尽早地向客户交付满意的结果
常见的敏捷实践方法：频繁的面对面沟通、激励个体积极主动、完成日常任务、设置紧急停车区等。
在这里，我想向做敏捷管理的团队提出几个问题：
缺乏一系列敏捷活动往往会导致个别团队成员只有任务，没有目标，也没有指导。 如何形成自流动的敏捷组织。
有的项目经理可能会说，你说的这些方法我都知道，但是我们项目期限很紧，没有时间去做。 作者想说的是，这完全取决于PM对这些敏捷活动的理解。 只有总理认为重要、有必要，他自然有时间去组织！
02
对于想要进行敏捷变革的组织来说，起点是什么？
作者建议从项目入手，根据项目的重要性、时间和规模选择过程敏捷或迭代敏捷模型。
基于流程的敏捷和基于迭代的敏捷实践说明：
基于流程的敏捷一般用于在项目上线前进行程序演示，以追求每个版本都具有完整的功能。
原则是在每次迭代中完成所有功能。 团队评估工作量并确定工作时间。 注意不要有太多的功能，以免延长迭代时间软件项目管理与敏捷方法，使项目失去灵活性。
基于迭代的敏捷，一般是在软件上线之后，为了最大化软件的价值，保证稳定性，让客户看到我们的更新。
每次迭代的结束都有严格的时间限制。 需求的价值和优先级需要详细列出并得到团队的认可。 如果中间插入新的需求，我们可以剔除低优先级的需求，保证迭代周期。 原则是保证每次迭代都是最有价值的函数。
选择敏捷方法后，与团队成员一起定义敏捷操作流程。例如
Scrum敏捷管理的方法比较多，PM知道如何根据自己组织的特点选择合适的解决方案。
很多PM来自于PMBOK体系，转换成PMBOK指导体系可能会更容易理解，如下：
根据项目管理的五个生命周期整合敏捷：启动、计划、执行、监控和结束
在启动阶段，解释为什么要敏捷以及任务是什么？ 团队构成如何，环境如何？ 沟通机制是什么？ 透明披露使命？ 规划阶段，任务划分，用户故事定义，积压确定，工期评估，承诺执行阶段，快速迭代，聚焦开发，每一项成果都可用于监控阶段，及时响应需求变化，对积压进行价值判断，在插入和需求、评审和评审迭代的最后阶段，可以召开更多的专门会议。
但笔者认为，要想获得高层的认可，敏捷管理更为重要。
尤其是高层管理人员必须给予敏捷团队试错的宽容度，并且必须带领团队看到敏捷的作用。
因为敏捷是一种自上而下的方法，是一个闭环的东西。 敏捷是一个闭环。 从早期的待办事项优先级划分、开发执行、反馈收集到优化阶段，都离不开高层领导的支持。
高层管理人员需要有控制感。 那么他们如何判断组织是否足够敏捷呢？
可以参考的指标包括：可预测的开发速度、单件流程、内置质量、滚动迭代、提前交付等。
最敏捷的项目经理希望拥有自己的自组织团队。 因此，建议PM应赋予团队目标，为团队提供敏捷的规则指导，为团队提供自组织环境，放权，提高团队积极性，从而带来全方位的优化。
如果您对敏捷管理有更有趣的理解，欢迎随时与我交流。
其他敏捷知识参考：
根据时间维度选择敏捷模式：
一周内交付，快速响应，无需文档，面对面沟通，快速开发。
十天交付软件项目管理与敏捷方法，每天一次功能迭代，站立会议跟踪，周报监控。
半个月交付，三天迭代，站立会议跟踪，一周监控和报告。
一个月内交付，三天内迭代，随后召开站立会议，并在每周会议上报告。
按团队区域选择敏捷模式：
在偏远地区工作时，尽早面对面，让团队相互熟悉。 注意使用即时通讯工具进行沟通，例如视频会议和其他可以看到状态的“面对面”会议。
建议召开多次小型专门会议。 可以根据情况决定是否需要召开早会。
采用迭代敏捷，保证开发团队在同一时间线上的节奏。
