关键在于两个模糊的子问题:
抱怨变更,还是抱怨频繁?
质量不高的定义是什么?
抱怨变更,还是抱怨频繁?
第一,我们都知道敏捷开发是拥抱变化,通过短频快交付可用的软件来拉动反馈,影响变更。显然,每个迭代之间去改变需求是允许的。甚至在某些情况是鼓励的,例如获取到好的反馈时。
第二,团队不会反对那些关于优化交付内容的反馈。相反地,如果反复否定团队交付成果的价值,从而要求反工,甚至对于设计的颠覆。那确实会影响士气。试问一个孩子花了一个小时,按照图纸搭出来的乐高积木。你看完之后说不好看,不要。请问是小孩的问题,还是图纸问题,还是你的问题?都有可能,但是我们要识别清楚,要认错,要改!
第三,交付团队不是产品负责人的沙盘!不是一句“我们是Agile模式”,就可以随性修改需求,随意拿团队时间做试验。我们需要坚定地去营造一个有进有出的黑盒交付团队。只有这样,产品负责人才会珍惜每一个和团队计划的时间。
交付质量不高?
需求有明确验收标准(AC)定义,且在交付全过程中考虑完成定义(DoD)的团队,他们已经具备了确保质量的机制,应该不会再抱怨质量不高了。或许他们的问题会变成:需求粒度如何再小一些?构如何重构从而使交付更高效?
我对于这个问题的第一感觉给我提出了另外几个问题:
需求描述和验收标准是否过于简单?不符合INVEST原则,从而交付时无法验收/对峙,造成对质量不高的“错觉”。要知道,对于清晰的需求,团队可能会交付得无比高质量!
团队分工协作之间是否衔接不顺畅?例如,开发修改代码逻辑没通知测试针对性的修改测试脚本?这样的事情多了,从而导致团队感觉效率低下,体现在口头描述:交付质量不高。如果是这样,DoD的贯彻需要重申
总结一下,无论是变更频繁还是交付质量不高,实际发生时都有可能是需求或团队单方面造成的。作为对这个问题做分析一方的你,必须要识别其痛点的真实来源。否则就是一团浆糊,一种感觉,一堆抱怨的躁动
领取专属 10元无门槛券
私享最新 技术干货