V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
shangwuli
V2EX  ›  程序员

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

  •  
  •   shangwuli · 93 天前 · 2520 次点击
    这是一个创建于 93 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

    25 条回复    2022-07-07 09:24:14 +08:00
    golangLover
        1
    golangLover  
       93 天前 via Android   ❤️ 1
    团队效率低是你们管理的问题,管理的要求是无止境的,也不了解自己胡乱给的要求要花多久开发,给钱也不高,自然招的人也水,这不是任何开发方法可以解决的
    shangwuli
        2
    shangwuli  
    OP
       93 天前
    @golangLover 加班已经解决不了问题了,质量质量不好,项目也一直延期
    woodensail
        3
    woodensail  
       93 天前
    就项目延期这一点,单纯换工作流程是没用的。需要的需求前期严格的需求分析和讨论,在正式动工之前制定完整的技术方案,然后确定各节点流转时间。某个流程超时则对应人员负责,做了一大半发现方案不合理则是产品经理背锅。
    按这套做下来,起码 90%以上的需求不延期不返工。
    kop1989smurf
        4
    kop1989smurf  
       93 天前
    任何软件工程理论都不能解决“团队效率低”。
    软件工程理论解决的是工程进度的可控与成功率。

    团队效率低是能力的问题。
    bk201
        5
    bk201  
       93 天前
    团队效率低我感觉分几种情况,你要分情况去解决。比如团队能力问题的,那么你要评估一下各组员是不是不能用,不能用就慢慢替换。又比如制度流程有问题拖累项目效率的,那么去与领导沟通优化流程制度。只能对症下药,先分析,再去抽丝剥茧,挨个解决。你单纯引入一些新的概念,只会让效率更低下,我是这么觉得的,仅供参考。
    kop1989smurf
        6
    kop1989smurf  
       93 天前
    甚至,软件工程理论从某种意义上讲,是降低团队效率的。
    他是用效率的降低换取工程进度的真实有效,以及与需求的连接紧密。

    你试图用软件工程流程来控制团队效率,属于缘木求鱼。
    woodensail
        7
    woodensail  
       93 天前
    楼上说得挺对的,软件工程能一定程度上降低意外因素对项目带来的冲击。但是如果你们经常一个评估五天的需求实际动手开干才发现 15 天才能搞完,甚至压根没法实现,这种东西任何流程都救不了你们。
    raptor
        8
    raptor  
       93 天前
    管理者能力低下,什么循环也不管用。

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

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

    管理比软件更加没有银弹。因为软件的问题主要是人的问题,管理的问题完全就是人的问题。
    yubohu
        9
    yubohu  
       93 天前
    非程序员,还是希望我的回答对你有所帮助

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

    你的疑问可能是出在你们的实操过程中并没有遵守 scrum 的这些准则,导致环节缺失,所以可以跟领导聊一聊,或者找机会在内部分享会议上提出自己所看所想,大家集体商议一下是否可以有效的应用到实际的工作中。大部分情况下,方法论的应用是需要进行“本地化”的,毕竟项目环境不太可能是处于理想状况的。
    yubohu
        10
    yubohu  
       93 天前
    团队效率低要去分析原因,再尝试寻找解决方案,不是靠引入新的管理办法就有用的。
    nothingistrue
        11
    nothingistrue  
       93 天前
    scrum 天生就是 PDCA 循环,如果你们用 scrum 但是没走出来 PDCA 循环,那说明你们并没有真正的在用 Scrum 。这种情况下给什么方法论都没用。提示一下,PDCA 和 Scrum 的精髓是:每轮只解决最优先的部分问题(通常绝大部分问题都是留给后面);根据以前的效率指定之后的计划(意味绝对不会有效率低下这种说法);没全部成功就是失败(同时做失败了也算做了)。
    yubohu
        12
    yubohu  
       93 天前
    @shangwuli 加班解决不了问题,说明大家还是愿意努力的(至少看在工资的份上)。质量问题基本就是人员能力(单人能力不足或团队配合)问题了,具体排查出问题根源,调整任务分配。另外可以考虑结对编程,这也许是解决你们项目目前遇到问题的一个突破口。从项目计划可能也需要调整,但是不知道详情,实在没办法给出具体方案。

    希望对你有用。
    zhouyg
        13
    zhouyg  
       93 天前
    尝试换个角度,基于你们的管理水平,团队水平推测对比一下。当前这个效率是不是有可能就已经是你们当下的天花板了?
    shangwuli
        14
    shangwuli  
    OP
       93 天前
    @bk201 感谢你的建议,说得有道理,我怎么委婉的和领导说呢?
    fengjianxinghun
        15
    fengjianxinghun  
       93 天前
    @shangwuli 和你老板说,看见 windows 3.1 那个标了没?设计那个标花了 300w$+3 个月时间,你给的钱只值这个质量。
    shinession
        16
    shinession  
       93 天前
    楼上的说法没听过,拿小本本记下了
    1000copy
        17
    1000copy  
       93 天前   ❤️ 1
    你们的问题,是问题本身还没有理清楚。只言片语就是效率低领导不满意质量不好总是延期。

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

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

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

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

    解决你的问题,其实是行业内普遍面临的问题。看起来简单,其实需要一个系统的过程。
    1000copy
        18
    1000copy  
       93 天前
    找到了。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
        19
    shangwuli  
    OP
       93 天前
    @1000copy 感谢感谢
    AllenTsui
        20
    AllenTsui  
       93 天前
    没有任何的方法论,是只要生搬硬套就能解决问题的。要具体分析。
    nothingistrue
        21
    nothingistrue  
       93 天前
    @shangwuli 闲着无事,看了你链接的那篇文章,发现那特么在放屁,你要学他铁定被坑。那个文章,第一章是套话,第二、三章对 PDCA 的解释还不错,但是第四章就是胡扯了。第四章说的实施方法,跟 PDCA 没有任何关系,那压根也不是可以实施的方法,根本就是随便找了些语言组织起来就放那里了,你翻到 20 年前讲解软件工程、CMMI ,甚至瀑布开发的文章,都能找到类似描述。

    PDCA 循环,或者说戴明环,或者说 8D ,在生产制造行业是有完善的实施体系的,如果真要用,要找专业教练培训一下。不是啥大培训,三天就够了,不过培训费用应该不菲。不过软件行业,一般是参照而非使用 PDCA ,最好还是做专门的 SCRUM 培训,哪怕是国内魔改的培训,也有用。
    cowcomic
        22
    cowcomic  
       93 天前
    @shangwuli 整个 scrum 其实就是一个 PDCA 循环,scrum 的复盘阶段总结上一个 scrum 的问题,怎么在后面的 scrum 避免。重点是复盘的时候是不是能分析到真正的原因,比如 BUG 多,不能简单的增加测试,增加单元测试,为什么会测试不好,可能是测试没有参加需求评审,为什么没做单元测试,可能是研发时间不够挤占了单元测试时间,那后面就需要安排全员参加需求评审,研发需要专门留出写单元测试的时间
    SenLief
        23
    SenLief  
       93 天前
    无论是 PDCA 还是 scrum 都是在工作进行时了,他无法解决天生的计划缺陷问题。

    作为管理者最重要的是目标分解能力,而上面最后的复盘可以提供这种能力。
    datocp
        24
    datocp  
       93 天前 via Android
    进了制造业,才发现有 iatf 16949 标准,里面新鲜的东西多了去。这是为了不同公司有统一的行业标准,包括表单模板都是一样的定义,而不是各玩一套。之前在培训业根本没这些东西。
    很多概念没学过觉得眼前一亮,至于会不会用,想不想用完全取决于人。
    shangwuli
        25
    shangwuli  
    OP
       92 天前
    @nothingistrue 专业啊,一伸手就知有没有。我们目前在走 scrum ,其实我们有研发工具,用的就是禅道,也是在这个基础上走的 scrum 。培训的话应该就算了,目前公司层面就是不舍得花钱,禅道有免费的学习视频,我这边在网上扒拉一些资料参考学习。现在是真的难受,没有半点方向。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   938 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 35ms · UTC 22:52 · PVG 06:52 · LAX 15:52 · JFK 18:52
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.