程序员们，你们有走 PDCA 循环吗？帮忙给个建议

[shangwuli]

今天在禅道论坛里看到一篇关于 PDCA 循环的内容： https://www.zentao.net/redirect-index-21470.html

本人是认可 PDCA 循环的，看着也比较简单，无非就是四个步骤执行。不过我们团队在走 scrum ，如果这两者要结合使 用的话应该怎么整呢？

现在团队效率低，领导不愿意，想尝试各种可能。各位兄弟姐妹们，谁能给我理一理，给点建议啊。

[golangLover]

团队效率低是你们管理的问题，管理的要求是无止境的，也不了解自己胡乱给的要求要花多久开发，给钱也不高，自然招的人也水，这不是任何开发方法可以解决的

[shangwuli]

@golangLover 加班已经解决不了问题了，质量质量不好，项目也一直延期

[woodensail]

就项目延期这一点，单纯换工作流程是没用的。需要的需求前期严格的需求分析和讨论，在正式动工之前制定完整的技术方案，然后确定各节点流转时间。某个流程超时则对应人员负责，做了一大半发现方案不合理则是产品经理背锅。
按这套做下来，起码 90%以上的需求不延期不返工。

[kop1989smurf]

任何软件工程理论都不能解决“团队效率低”。
软件工程理论解决的是工程进度的可控与成功率。

团队效率低是能力的问题。

[bk201]

团队效率低我感觉分几种情况，你要分情况去解决。比如团队能力问题的，那么你要评估一下各组员是不是不能用，不能用就慢慢替换。又比如制度流程有问题拖累项目效率的，那么去与领导沟通优化流程制度。只能对症下药，先分析，再去抽丝剥茧，挨个解决。你单纯引入一些新的概念，只会让效率更低下，我是这么觉得的，仅供参考。

[kop1989smurf]

甚至，软件工程理论从某种意义上讲，是降低团队效率的。
他是用效率的降低换取工程进度的真实有效，以及与需求的连接紧密。

你试图用软件工程流程来控制团队效率，属于缘木求鱼。

[woodensail]

楼上说得挺对的，软件工程能一定程度上降低意外因素对项目带来的冲击。但是如果你们经常一个评估五天的需求实际动手开干才发现 15 天才能搞完，甚至压根没法实现，这种东西任何流程都救不了你们。

[raptor]

管理者能力低下，什么循环也不管用。

PDCA 循环在全面质量管理中的应用都好几十年了，又不是什么新玩意儿。

对于正经读过点管理学的书的人来说，这些都是基本常识。

管理比软件更加没有银弹。因为软件的问题主要是人的问题，管理的问题完全就是人的问题。

[yubohu]

非程序员，还是希望我的回答对你有所帮助

其实如果你们每个 sprint 如果都是遵守 scrum 规则执行的话，PDCA 循环已经是走过的了。计划会相当于 P ，评审会相当于 C ，回顾会相当于 C+A 。另外，其实每天的立会也是一次微型的 PDCA 循环，想想你在会上需要回答的问题：1. 完成了什么？（ C ） 2.将要做什么？（ P ） 3.遇到什么阻碍，谁能帮助你？（ A ）
其实不要太拘泥于各种名词、概念，重点是做的事情是不是相同的。同样的事情在不同的方法论里可能有着千奇百怪的概念名词，纠结于这个就没必要了。

你的疑问可能是出在你们的实操过程中并没有遵守 scrum 的这些准则，导致环节缺失，所以可以跟领导聊一聊，或者找机会在内部分享会议上提出自己所看所想，大家集体商议一下是否可以有效的应用到实际的工作中。大部分情况下，方法论的应用是需要进行“本地化”的，毕竟项目环境不太可能是处于理想状况的。

[yubohu]

团队效率低要去分析原因，再尝试寻找解决方案，不是靠引入新的管理办法就有用的。

[nothingistrue]

scrum 天生就是 PDCA 循环，如果你们用 scrum 但是没走出来 PDCA 循环，那说明你们并没有真正的在用 Scrum 。这种情况下给什么方法论都没用。提示一下，PDCA 和 Scrum 的精髓是：每轮只解决最优先的部分问题（通常绝大部分问题都是留给后面）；根据以前的效率指定之后的计划（意味绝对不会有效率低下这种说法)；没全部成功就是失败（同时做失败了也算做了）。

[yubohu]

@shangwuli 加班解决不了问题，说明大家还是愿意努力的(至少看在工资的份上)。质量问题基本就是人员能力(单人能力不足或团队配合）问题了，具体排查出问题根源，调整任务分配。另外可以考虑结对编程，这也许是解决你们项目目前遇到问题的一个突破口。从项目计划可能也需要调整，但是不知道详情，实在没办法给出具体方案。

希望对你有用。

[zhouyg]

尝试换个角度，基于你们的管理水平，团队水平推测对比一下。当前这个效率是不是有可能就已经是你们当下的天花板了？

[shangwuli]

@bk201 感谢你的建议，说得有道理，我怎么委婉的和领导说呢？

[fengjianxinghun]

@shangwuli 和你老板说，看见 windows 3.1 那个标了没？设计那个标花了 300w$+3 个月时间，你给的钱只值这个质量。

[shinession]

楼上的说法没听过，拿小本本记下了

[1000copy]

你们的问题，是问题本身还没有理清楚。只言片语就是效率低领导不满意质量不好总是延期。

大而化之的这些东西，云里雾里的，只能叫做感受，是不够格叫做问题的。因此谈不上为问题找解决方案。

我记得 Joel On Software 上对团队改善提出过问题清单。但是具体内容我记不得了，也懒得搜索了。

就干脆模仿他，我自己炮制 8 个问题，你可以结合你的项目的情况，按图索骥，把你们的乌七八糟的感受变成真正的响当当的有价值的问题。然后寻找改善点。

1. 你们的需求有基线文档和变更版本化吗？
2. 你们的即将到来的迭代的需求文档，可以在开发前可以冻结吗？
3. 你们在开发前会做任务功能分解并标记工作时吗？
4. 你们有专职的测试团队吗？
5. 你们的有冒烟测试阶段以便明确的开发和测试交接吗？
6. 你们的开发有自测环节吗？
7. 你们有 bug 跟踪吗？
8. 你们的项目线上 bug 修复成本有多高？

解决你的问题，其实是行业内普遍面临的问题。看起来简单，其实需要一个系统的过程。

[1000copy]

找到了。The Joel Test: 12 Steps to Better Code

1 你使用源代码控制吗？
2 你能在一个步骤中完成构建吗？
3 你每天都进行构建吗？
4 你有一个 bug 数据库吗？
5 你在写新的代码之前会修复错误吗？
6 你有一个最新的时间表吗？
7 你有一个 Spec 吗？
8 程序员有安静的工作环境吗？
9 你使用金钱可以买到的最好的工具吗？
10 你有测试人员吗？
11 新的候选人在面试时写代码吗？
12 你会做走廊的可用性测试吗？

这些条目提出很多年了，前面的 5 条当年不是那么显然，现在则是共识吧。如果都是常识，就不必再提了。

第 6 ，7 ，10 ，11 条非常有意义。特别是第 6 条，可以倒逼需求编写的质量。

第 8 ，9 ，12 条我没玩过，不确定价值。

[shangwuli]

@1000copy 感谢感谢

[AllenTsui]

没有任何的方法论，是只要生搬硬套就能解决问题的。要具体分析。