这是一个创建于 906 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天在禅道论坛里看到一篇关于 PDCA 循环的内容： https://www.zentao.net/redirect-index-21470.html
本人是认可 PDCA 循环的，看着也比较简单，无非就是四个步骤执行。不过我们团队在走 scrum ，如果这两者要结合使 用的话应该怎么整呢？
现在团队效率低，领导不愿意，想尝试各种可能。各位兄弟姐妹们，谁能给我理一理，给点建议啊。
 |
1
golangLover 2022-07-06 10:28:39 +08:00 via Android  1
团队效率低是你们管理的问题，管理的要求是无止境的，也不了解自己胡乱给的要求要花多久开发，给钱也不高，自然招的人也水，这不是任何开发方法可以解决的
|
 |
2
shangwuli OP @golangLover 加班已经解决不了问题了，质量质量不好，项目也一直延期
|
 |
3
woodensail 2022-07-06 10:37:05 +08:00
就项目延期这一点，单纯换工作流程是没用的。需要的需求前期严格的需求分析和讨论，在正式动工之前制定完整的技术方案，然后确定各节点流转时间。某个流程超时则对应人员负责，做了一大半发现方案不合理则是产品经理背锅。
按这套做下来，起码 90%以上的需求不延期不返工。 |
 |
4
kop1989smurf 2022-07-06 11:06:23 +08:00
任何软件工程理论都不能解决“团队效率低”。
软件工程理论解决的是工程进度的可控与成功率。 团队效率低是能力的问题。 |
 |
5
bk201 2022-07-06 11:14:19 +08:00
团队效率低我感觉分几种情况，你要分情况去解决。比如团队能力问题的，那么你要评估一下各组员是不是不能用，不能用就慢慢替换。又比如制度流程有问题拖累项目效率的，那么去与领导沟通优化流程制度。只能对症下药，先分析，再去抽丝剥茧，挨个解决。你单纯引入一些新的概念，只会让效率更低下，我是这么觉得的，仅供参考。
|
|
6
kop1989smurf 2022-07-06 11:14:45 +08:00
甚至，软件工程理论从某种意义上讲，是降低团队效率的。
他是用效率的降低换取工程进度的真实有效，以及与需求的连接紧密。 你试图用软件工程流程来控制团队效率，属于缘木求鱼。 |
|
7
woodensail 2022-07-06 11:30:45 +08:00
楼上说得挺对的，软件工程能一定程度上降低意外因素对项目带来的冲击。但是如果你们经常一个评估五天的需求实际动手开干才发现 15 天才能搞完，甚至压根没法实现，这种东西任何流程都救不了你们。
|
 |
8
raptor 2022-07-06 11:47:31 +08:00
管理者能力低下，什么循环也不管用。
PDCA 循环在全面质量管理中的应用都好几十年了，又不是什么新玩意儿。 对于正经读过点管理学的书的人来说，这些都是基本常识。 管理比软件更加没有银弹。因为软件的问题主要是人的问题，管理的问题完全就是人的问题。 |
 |
9
yubohu 2022-07-06 12:32:18 +08:00
非程序员，还是希望我的回答对你有所帮助
其实如果你们每个 sprint 如果都是遵守 scrum 规则执行的话，PDCA 循环已经是走过的了。计划会相当于 P ，评审会相当于 C ，回顾会相当于 C+A 。另外，其实每天的立会也是一次微型的 PDCA 循环，想想你在会上需要回答的问题：1. 完成了什么？（ C ） 2.将要做什么？（ P ） 3.遇到什么阻碍，谁能帮助你？（ A ） 其实不要太拘泥于各种名词、概念，重点是做的事情是不是相同的。同样的事情在不同的方法论里可能有着千奇百怪的概念名词，纠结于这个就没必要了。 你的疑问可能是出在你们的实操过程中并没有遵守 scrum 的这些准则，导致环节缺失，所以可以跟领导聊一聊，或者找机会在内部分享会议上提出自己所看所想，大家集体商议一下是否可以有效的应用到实际的工作中。大部分情况下，方法论的应用是需要进行“本地化”的，毕竟项目环境不太可能是处于理想状况的。 |
|
10
yubohu 2022-07-06 12:34:10 +08:00
团队效率低要去分析原因，再尝试寻找解决方案，不是靠引入新的管理办法就有用的。
|
 |
11
nothingistrue 2022-07-06 12:35:01 +08:00
scrum 天生就是 PDCA 循环，如果你们用 scrum 但是没走出来 PDCA 循环，那说明你们并没有真正的在用 Scrum 。这种情况下给什么方法论都没用。提示一下，PDCA 和 Scrum 的精髓是：每轮只解决最优先的部分问题（通常绝大部分问题都是留给后面）；根据以前的效率指定之后的计划（意味绝对不会有效率低下这种说法)；没全部成功就是失败（同时做失败了也算做了）。
|
|
12
yubohu 2022-07-06 12:43:40 +08:00
@shangwuli 加班解决不了问题，说明大家还是愿意努力的(至少看在工资的份上)。质量问题基本就是人员能力(单人能力不足或团队配合）问题了，具体排查出问题根源，调整任务分配。另外可以考虑结对编程，这也许是解决你们项目目前遇到问题的一个突破口。从项目计划可能也需要调整，但是不知道详情，实在没办法给出具体方案。
希望对你有用。 |
 |
13
zhouyg 2022-07-06 12:46:34 +08:00
尝试换个角度，基于你们的管理水平，团队水平推测对比一下。当前这个效率是不是有可能就已经是你们当下的天花板了？
|
 |
15
fengjianxinghun 2022-07-06 13:08:31 +08:00
@shangwuli 和你老板说，看见 windows 3.1 那个标了没？设计那个标花了 300w$+3 个月时间，你给的钱只值这个质量。
|
 |
16
shinession 2022-07-06 13:19:40 +08:00
楼上的说法没听过，拿小本本记下了
|
 |
17
1000copy 2022-07-06 13:49:05 +08:00 1
你们的问题，是问题本身还没有理清楚。只言片语就是效率低领导不满意质量不好总是延期。
大而化之的这些东西，云里雾里的，只能叫做感受，是不够格叫做问题的。因此谈不上为问题找解决方案。 我记得 Joel On Software 上对团队改善提出过问题清单。但是具体内容我记不得了，也懒得搜索了。 就干脆模仿他，我自己炮制 8 个问题，你可以结合你的项目的情况，按图索骥，把你们的乌七八糟的感受变成真正的响当当的有价值的问题。然后寻找改善点。 1. 你们的需求有基线文档和变更版本化吗？ 2. 你们的即将到来的迭代的需求文档，可以在开发前可以冻结吗？ 3. 你们在开发前会做任务功能分解并标记工作时吗？ 4. 你们有专职的测试团队吗？ 5. 你们的有冒烟测试阶段以便明确的开发和测试交接吗？ 6. 你们的开发有自测环节吗？ 7. 你们有 bug 跟踪吗？ 8. 你们的项目线上 bug 修复成本有多高？ 解决你的问题，其实是行业内普遍面临的问题。看起来简单，其实需要一个系统的过程。 |
|
18
1000copy 2022-07-06 14:04:04 +08:00
找到了。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 条我没玩过，不确定价值。 |
 |
20
AllenTsui 2022-07-06 14:38:27 +08:00
没有任何的方法论，是只要生搬硬套就能解决问题的。要具体分析。
|
|
21
nothingistrue 2022-07-06 16:41:58 +08:00
@shangwuli 闲着无事，看了你链接的那篇文章，发现那特么在放屁，你要学他铁定被坑。那个文章，第一章是套话，第二、三章对 PDCA 的解释还不错，但是第四章就是胡扯了。第四章说的实施方法，跟 PDCA 没有任何关系，那压根也不是可以实施的方法，根本就是随便找了些语言组织起来就放那里了，你翻到 20 年前讲解软件工程、CMMI ，甚至瀑布开发的文章，都能找到类似描述。
PDCA 循环，或者说戴明环，或者说 8D ，在生产制造行业是有完善的实施体系的，如果真要用，要找专业教练培训一下。不是啥大培训，三天就够了，不过培训费用应该不菲。不过软件行业，一般是参照而非使用 PDCA ，最好还是做专门的 SCRUM 培训，哪怕是国内魔改的培训，也有用。 |
 |
22
cowcomic 2022-07-06 18:24:33 +08:00
@shangwuli 整个 scrum 其实就是一个 PDCA 循环，scrum 的复盘阶段总结上一个 scrum 的问题，怎么在后面的 scrum 避免。重点是复盘的时候是不是能分析到真正的原因，比如 BUG 多，不能简单的增加测试，增加单元测试，为什么会测试不好，可能是测试没有参加需求评审，为什么没做单元测试，可能是研发时间不够挤占了单元测试时间，那后面就需要安排全员参加需求评审，研发需要专门留出写单元测试的时间
|
 |
23
SenLief 2022-07-06 18:48:05 +08:00
无论是 PDCA 还是 scrum 都是在工作进行时了，他无法解决天生的计划缺陷问题。
作为管理者最重要的是目标分解能力，而上面最后的复盘可以提供这种能力。 |
 |
24
datocp 2022-07-07 02:14:36 +08:00 via Android
进了制造业，才发现有 iatf 16949 标准，里面新鲜的东西多了去。这是为了不同公司有统一的行业标准，包括表单模板都是一样的定义，而不是各玩一套。之前在培训业根本没这些东西。
很多概念没学过觉得眼前一亮，至于会不会用，想不想用完全取决于人。 |
|
25
shangwuli OP @nothingistrue 专业啊，一伸手就知有没有。我们目前在走 scrum ，其实我们有研发工具，用的就是禅道，也是在这个基础上走的 scrum 。培训的话应该就算了，目前公司层面就是不舍得花钱，禅道有免费的学习视频，我这边在网上扒拉一些资料参考学习。现在是真的难受，没有半点方向。
|
Select Language