浅谈基于 PDCA 原理的软件项目管理

引言

作为一种十分经典的质量管理工具，PDCA 在软件行业逐渐呈现出旺盛的活力，特别是敏捷软件开发方法在软件行业内的普及，持续的迭代与改进已成为软件项目管理的主流。从中国知网的论文数量来看，1980年 PDCA 相关论文仅有7篇而到了2019年已有2751篇相关研究论文，但大部分集中在医疗领域，在软件开发领域相对较少只有2%左右。

定义

PDCA循环又叫“戴明循环”，简称“戴明环”。戴明环是美国质量管理专家戴明博士首先提出，戴明循环研究起源于20世纪20年代，有“统计质量控制之父”之称的著名的统计学家沃特·阿曼德·休哈特（Walter A. Shewhart）在当时引入了“计划-执行-检查（Plan-Do-See）”的概念， 戴明后将休哈特的PDS循环进一步发展成为：计划-执行-检查-处理（Plan(计划)、Do(执行)、Check(检查)和Action(处理))。 

P（Plan - 计划）：评估当前现状，确定目标与方向，明确实施计划、资源与预算。

D（Do - 执行）：项目日常工作的实施

C（Check - 检查）：评估执行结果，分析并找出成功经验与问题

A（Action - 处理）：对检查结果进行处理，对于成功经验加以推广，对于问题进行改进与完善，将本周期内未改进的问题纳入下一个迭代周期内加以完善。

每一件事情先做计划,计划完成后去实施，实施过程中检查记录，之后分析并加以改进。遗留事项纳入下一个循环周期，周而复始，持续完善。

软件研发模式的演进

瀑布开发模式

需求是完整的、清晰的、固定的

敏捷开发模式

需求变化频繁、开发过程需要更新快速高效

DevOps开发模式

需求变化频繁、开发过程需要敏捷、协作需要敏捷

从项目管理的演变我们不难发现，从瀑布式的一个项目一个大周期，到敏捷开发的每一个迭代一个周期，到 DevOps 的循环周期叠加，软件开发模式的循环周期颗粒度越来越小。而 PDCA的持续改进对于软件项目以至整个组织的管理提升都将启动十分重要的作用。

 PDCA敏捷项目管理流程

标准的实施方法与公司实际采用的方法往往存在差异。一般来说，各个公司与组织由于资源、制度、管理方式等自身情况的差异性，对于项目管理流程都会根据自身的实际需要加以定制，已符合自身。包括流程、模板、规范等。

在一个研发团队中，详细定义每一个迭代过程中的PDCA 过程，以保证在整个软件生产中得以持续的改进，使得在持续的交付过程中随着时间的推移，产品功能与质量得以不断完善。

其中每个迭代周期为2~4周，每个迭代都包含了完整的 PDCA 循环。

P - 迭代计划

定义在迭代周期内的工作目标、工作范围，并对工作做 WBS任务分解，最终行程迭代计划。

D - 迭代执行

上一轮遗留：落地上一轮迭代转入本论的改进计划并衡量执行结果

每日站会：团队所有成员固定时间开一个10~15分钟的会议。要求尽量用简短的语言描述实际的个人进展情况，沟通并承诺当天的工作计划，并根据会议结果更新迭代计划与投产计划。不在会议上进行需求、技术与功能上的讨论

常规任务：定义并执行，需求分析、开发、测试任务。

收集执行数据：执行阶段每一个动作与进度均需记录在案，为后续评审与度量提供数据支撑。

目标为输出可工作程序，已达到对业务快速响应提高客户满意度的目的。

C - 迭代检查

检查贯穿整个迭代周期，在执行过程中与执行过程外均需要根据实际情况增加检查动作。

执行过程中：

每日站会——识别风险，沟通问题

单元测试——开发人员执行测试检查

代码走查——测试前对核心代码重点走查，其它代码抽查

进度分析——对剩余时间，工作量，问题，缺陷等综合分析

质量工具——应用代码扫描工具，对代码质量进行分析

执行过程外：需求评审、测试案例评审、技术方案评审、迭代总结会议等。

A - 迭代改进

在每个迭代结束后，项目组成员与干系人对本次迭代已不同的视角进行总结回顾，发现并暴露问题，探讨改进措施并最终形成改进方案。对于成功经验，加以总结抽象，形成通用方法加以推广。所有结论形成文档，并有专人负责跟踪，以确保在后续迭代中得以落实。

结束语

任何一种方法与理论都存在局限性， PDCA 可以很好的持续改进质量，但一定程度上也限制了组织内的创造性，只有灵活的使用工具并不断的自我完善，才能在未来的挑战中保持活力。