敏捷项目管理——响应变化高于遵循计划（采用敏捷项目管理方法,在控制进度过程中需要）

投稿用户 • 2022年9月19日 am11:03 • 科研百科 • 阅读 184

前言

敏捷项目管理——响应变化高于遵循计划（采用敏捷项目管理方法,在控制进度过程中需要）

响应变化高于遵循计划

“响应变化高于遵循计划”—敏捷宣言。

在当今变化莫测的时代，昨天5G刚刚兴起，今日6G已悄然开始布局。如何抓住时代的红利是每个产品或者项目管理者都要思考的事情。越早响应变化，就越早能够享受变革带来的红利，反之，一味的遵循计划只会被时代抛弃。

接下来老程与大家一起分享敏捷项目管理中的响应变化的知识，旨在让大家了解，敏捷并非是洪水猛兽那么可怕，相反，顺应时代的潮流，引领大家体验敏捷的奥妙！

请各位抓紧时间上车，坐好扶稳，老司机开始飙车了

let’s go

适应学

敏捷项目管理——响应变化高于遵循计划（采用敏捷项目管理方法,在控制进度过程中需要）

世界上最后能生存的生物，不是最强的；也不是智慧最高的，而是适应能力最强的

“世界上最后能生存的生物，不是最强的；也不是智慧最高的，而是适应能力最强的”—英国生物学家达尔文

传统的项目管理者注重按计划行事，尽量做到和计划没有出入；而敏捷项目领导者关注如何成功的去适应不可避免出现的变化《敏捷项目管理第二版》

传统的瀑布式项目管理，往往前期做了大量的计划，制定各项约束，详尽的文档。而敏捷项目管理者则更注重价值。

曾经有段时间，老程接收集团一个LMS（实验室系统）时，先收集需求（各部门及客户）勾画更重流程图，反复的讨论；在调研完毕后，关起门来，奋力书写几天，终于在抽了几包烟以及双眼熬成“国宝”项目需求说明书，项目计划书等等文稿出世了。

接下来信息慢慢，觉得这下子，改兄弟们大展拳脚了。一开始项目进展挺好，中期有一次和市场部门人员闲聊时，对方提了一个随意的问题；听闻他讲完，老程心中不禁大吃一惊。糟糕，这里没有想到，确实是客户需要的功能，但项目已经进行到中期，如果改动，意味着要打破计划，于是，心一横，对市场人员说，你的想法很好，第二个版本我会考虑加上。

就这么团队人员吭叽吭叽码了几个月代码，项目宣告完成，交于市场人员推向市场，获得反馈真是多，比各位粉丝的评论还要热烈，于是团队成员不得不再次修改项目，期间团队的气氛压抑到极点，好在最后经过无数次的抢救，项目被抢救过来了，市场反应相对小一些。

结果这一次项目，反思了一点，为何要制定详尽的计划？详尽的计划一定是对的吗？能不能，划分模块，相互独立的模块，由市场人员来确定优先级，做完一个阶段的功能后，让市场人员进行评审，并收集反馈，进行更高。

于是在第二个项目《XX旅游网》启动时，采用轻计划及规范。由客户参与，罗列出项目的愿景及价值。在一次周日，老程坐上游轮到香港的中环，在总部和客户进行一次交流，虽然那几个美女热情的讲解，但没听懂多少（对方讲英文，连蒙带猜，懂了50%左右）；咳咳，一不小心跑题了。

书归正传

在第二个项目中，我们团队吸取上个项目的教训，决定采用迭代式交付。虽然也属于传统型项目管理，但比瀑布式要好的多。

通过小版本的迭代—评审–修复缺陷–发布，期间用到看板，这种项目管理流程，HK的客户MM们挺满意，期间特意从HK来公司进行深入交流，气氛异常融洽。

直到接触到敏捷后，才知道，原来是有一种项目管理方法是基于变化、实现客户价值为核心的方法，那就是敏捷。

适应性原则声明

《声明》：预测不确定性，并设法通过迭代、预防、适应来应对不确定性；

《声明》：通过使用根据具体情况而定的策略、流程和实践来提高效率和可靠性；

《宣言》：响应变化胜过遵循计划；

《宣言》：即使在产品研发后期，也乐于接受变化的需求，敏捷流程充分利用变化以增加客户竞争优势；

《宣言》：团队定期反省如何做到更有效，然后响应的调整团队的行为。

总结：

以客户价值和质量为目标，计划就是实现这些目标的方式而非目标的本身。计划中的约束依然重要，只是不是重点，重点变成了计划约束是指导项目完成的一种方法，在随着项目的深入，要对计划进行剪裁和更新，使一潭水由死变为活水。

敏捷项目管理——响应变化高于遵循计划（采用敏捷项目管理方法,在控制进度过程中需要）

敏捷项目管理之探索

探索

敏捷是为了在动荡的商业环境中创造利润而制造并响应变化的能力–《敏捷项目管理》

有响应变化的能力固然很好，但是如果能给竞争对手创造变化则更佳。创造变化就是向对手展开竞争攻势。想赢对手的变化，是防守。

变革是困难的，比如，老程一直想戒烟，无奈抽上容易，戒掉很难。要警惕那些固有的习惯，习惯有时会成为惰性，阻止我们作出变化。

尽管敏捷价值观告诉我们，响应变化比执行计划更重要；但往往研发团队习惯固有的计划，而不愿作出大胆的探索，因为探索带来的可能是颠覆性的重构。

探索式困难的，容易引发焦虑、恐惧。这是就需要敏捷项目管理者及时鼓励团队成员，鼓励试错、借鉴成功经验和错误经验，创造安全的环境，让大伙大胆地说出自己的想法。外部的鼓励和内部的鼓励可以帮助团队建立内部激励；

研发产品是需要被引导而不是被管理，我们容许团队成员有好的点子，有变革的激情。每个项目都有一只和未知的条件、有确定因素和不确定的因素，因此，如何在计划和变化中找到平衡点变得尤为重要。这就需要我们用各种方法去探索例如用户故事作坊、用户特性、用户角色、用户画像、用户故事、每日展会、评审会等等方法来帮助我们。

研发人员

在研发团队中，最重要的就是人员。如何点燃人员的激情，很重要。需要各种激励和惩罚手段来调动和约束人员。

人员的意愿也很重要，如果人员对敏捷项目管理或者对公司文化认同，不用打鸡血，人员会释放自己的激情，关于如何做，请参照老程的另一篇《敏捷项目管理-在敏捷环境中交付》一文。

敏捷项目管理——响应变化高于遵循计划（采用敏捷项目管理方法,在控制进度过程中需要）

障碍还是机会

障碍？机会？

老程经常有听到：“敏捷做法太耗时间、敏捷做法太昂贵了、敏捷流于形式”等等对敏捷的抱怨。这种做法往往是针对短期迭代、频繁更新、持续整合、测试等一系列其他的敏捷做法。

大多时候，人们感觉适应变化成本太高，是因为做事相率低下–没有抓住机会简化流程提高组织的适应能力。敏捷研发需要短期迭代，持续集成。很多公司在运用敏捷时，对WIP没有限制，一股脑的把probacklog中的所有事项集中到doit中，高速公路因为在制品的增多，不堵车才怪。可以参照我的另一篇文章《敏捷项目管理-精益产品开发》。

如何看待障碍和机会？我们在遇到困难或作出变革时，要经常问一句“这样做对我们有什么益处？”

结束

开发优质的产品需要探索，而不是遵循计划。探索和适应是创新的两个行为特质–拥有探索未知世界的勇气，拥有承认错误并适应形式的谦逊。

在敏捷中，我们运用一些列的方法“KANBAN、精益软件研发、Scrum、xp、sprint、站会、评审、回顾”等等方法，丰富软件研发的方法，为我们提供有依据的探索工具和方法，让我们在研发的探索之路上不迷路！

敏捷项目管理——响应变化高于遵循计划（采用敏捷项目管理方法,在控制进度过程中需要）

前言

适应学

书归正传

适应性原则声明

探索

研发人员

障碍？机会？

结束

相关推荐