vlambda博客
学习文章列表

随着软件行业规范化，其成本也逐渐降低，加之需求方对软件行业了解日趋深入供需双方矛盾日益凸显，导致敏捷开发模式在软件行业愈加流行。当下很多团队的现状是仍是瀑布式开发模式，又或者是有敏捷的形无敏捷的神，对于团队过去的痛点毫无益处，甚至存在一定拖累。摆在这些团队面前的问题是：如何推广和应用敏捷开发管理模式帮助团队解决供需双方的矛盾？

此前我曾主导和参与过多个团队敏捷开发转型，有成功亦有失败，在这里我将自己的经验总结为三大部分：准备、实施、优化。

图1：推广和应用敏捷开发管理模式

在敏捷实施之前，我们一定要正视敏捷转型这件事，把它当作一个独立的项目来看待。

敏捷转型切忌为了转型而转型。公司当下项目管理体系运作良好，没有需要解决的痛点，那么是没有必要搞敏捷转型。敏捷转型一定是为了解决当下某些痛点的，比如质量提升、效率提升、成本降低等等。敏捷转型之前一定将目标铆钉，目标需要符合SMART原则：(Specific)具体的、(Measurable)可衡量的、(Attainable)可达到的、(Relevant)存在相关性、(Time-bound)有明确截止日期。

目标的制定切忌拍脑袋，它是一个过程，需要详尽的调研和收集当下项目管理体系的现状，对比同业团队的平均指标，分析具体现状痛点。必要时可以考虑引入行业内较活跃的敏捷教练，将敏捷教练的经验带入目标制定过程，制定出合理的改进目标。

完成目标制定后，就可以根据目标进行拆解，制定出初步的里程碑计划，并推演制定各里程碑达成方案，形成目标达成的可行性分析。可行性分析是说服发起人的关键步骤，过程中需要考虑内部组织环境、企业战略、企业文化、团队能力成熟度、外部商业环境等等（例如2020年因疫情导致外部商业环境对于大多数公司来说相对较差，不太适合做较大规模的组织转型）。

将转型目标以及可行性方案向发起人汇报，争取发起人的支持。这里提到的发起人可能是自己，也可能是上级领导。如果是自己，也需要和上级领导进行沟通汇报，因为转型过程中可能会存在短期的效能下降、组织混乱等问题，为避免引起恐慌，还是需要取得上级领导的认可和支持。

把敏捷转型这件事当作一个独立项目，可以参考本文前的图1：推广和应用敏捷开发管理模式，进行详细的任务拆解，制定详细项目计划。一般需要进行半年时间的敏捷实践，才能顺利固化环境和知识，完成转型。

这里提到的团队，并不是特指敏捷团队，而是参与此次转型的成员，通常会包括发起人、项目经理、PO、Scrum Master、敏捷团队、PMO成员等（部分角色可能是同一人）。

团队组建过后，需要项目经理动员团队。在动员团队之前，需要评估各利益相关方，分析相关方对此次转型的支持度以及相关知识储备度。在动员团队过程中，项目经理需要制定有说服力的愿景，点燃斗志和希望。愿景需包含四部分：

①简洁有力的口号：核心关键的一句话，能够鼓舞人心，且能够表达出变革精神；

②令人心动的故事：详实的此次转型背景原因，转型后的公司、部门、团队是什么样的，与当下有哪些不一样；

③效益明确的成果：转型后明确的效益有哪些，对公司/部门/团队/个人的战略和财务面有什么改变；

④长远正面的影响：对于公司/部门/团队/个人在行业内的价值和地位存在哪些影响。

附：以下风险点需要尽早关注：

①发起人支持：发起人无法亲身参与支持，无法展现足够的言语行动支持项目，无法充分有效的向团队沟通转型缘由，或者任意将发起人角色授权给他人等；

②公开频繁沟通：转型过程中问题追踪未透明化，里程碑进展和激励未透明化；

③使用科学管理方法：凭感觉和经验做转型，没有按照独立项目进行科学管理；

④充裕的资源：领导的支持度，员工的投入度，短期效能下降等容忍度；

⑤员工积极参与：员工未全职100%投入参与；

⑥中层领导的支持和参与：中层领导不认可不支持等。

（1）、选择敏捷方法

现行的敏捷方法有很多种，每一种都有其适用场景。关于敏捷方法的简介可以参考我的上一篇文章《【敏捷管理】什么是敏捷项目管理》的第三章节：敏捷项目管理框架（方法），详尽的敏捷方法介绍请关注我的后续文章，也可以在网络上检索相关资料。在这里，我个人比较提倡选择Scrum敏捷方法，该方法使用者相对较多，更容易进行行业基准比较。以下内容均以Scrum方法为基础进行介绍。

（2）、创建敏捷团队

Scrum建议敏捷团队规模为3-9人，如果超出9人，建议拆分建立多个Scrum敏捷团队。Scrum敏捷团队应包含Product Owner（PO）、Scrum Master（SM）、开发团队（Team）三个角色。关于每个角色的职责和说明，请参考Scrum中文网介绍：Scrum团队的三个角色(https://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-5)

（3）、导入敏捷思维

导入敏捷思维是创建敏捷环境较为重要的步骤。在此过程，需要根据敏捷团队成熟度制定培训计划，将敏捷基础理念以及Scrum方法运作模式向敏捷团队介绍清楚。

（1）、制定敏捷团队章程

敏捷团队章程不建议由项目经理、PO或SM单独制定，而是建议带领团队一起制定。在制定过程中，需要引导团队一起思考以下四个问题：

①、我们为什么要做这个项目？

②、谁会从中受益？如何收益？

③、对此项目而言，达到哪些条件才意味着项目完成？

④、我们将怎样合作？

基于以上讨论和思考，PO、SM和团队基本可以达成以下约定：

①、团队价值观：价值观必须以互相信任为基础，在此基础上约定持续工作时间，和一些核心冲突的解决方案；

②、工作协议：例如时间盒定义、就绪定义、完成定义、缺陷定义等等；

③、基本规则：例如站会时间不准带手机、会议发言规定等等；

④、团队规范：例如团队如何对待会议时间等等。

敏捷团队章程制定完成后，建议将其提炼，张贴在每个人都能看到的位置，作为大家的共同约定。

（2）、敏捷实践（在敏捷转型项目中，敏捷实践是一个循环过程）

Scrum敏捷实践已经非常成熟，在此仅列举关键实践不作详细赘述，如需了解详情可以参考Scrum中文网介绍：Scrum的三个工件(https://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-6)和Scrum的四大支柱(https://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-9)，或者关注我的后续文章。

①基于迭代和增量的敏捷

②关注交付价值的执行

③待办事项列表

④每日站会

⑤展示/评审会

⑥回顾会

在敏捷环境中，倡导仆人式领导。所以SM需要清除在敏捷项目过程中不断出现的障碍。比如业务方与敏捷团队没有在一起办公、敏捷团队成员因职能领导安排无法100%投入、敏捷团队能力成熟度较低、产品复杂度过高、需求不明确、估算不准确等等。

在敏捷环境中，更多关注量化指标。例如故事点/功能点完成速率（匀速/匀加速至匀速）、时间盒遵守率、缺陷增速等等。

在敏捷实践中不断总结固化知识和制度，作为资产存储。例如故事点/功能点完成速率、故事点/功能点与缺陷比率、故事点/功能点评估基准和方法、敏捷团队跨职能协作方式等等。

当完成某个转型里程碑，需要进行有仪式感的奖励激励。例如奖金激励、组织认可等等.

针对阶段性目标，复盘敏捷转型过程，总结经验教训，形成下一个阶段改进措施。