需求变化频繁，交付质量不高

关键在于两个模糊的子问题：

抱怨变更，还是抱怨频繁？

质量不高的定义是什么？

抱怨变更，还是抱怨频繁？

第一，我们都知道敏捷开发是拥抱变化，通过短频快交付可用的软件来拉动反馈，影响变更。显然，每个迭代之间去改变需求是允许的。甚至在某些情况是鼓励的，例如获取到好的反馈时。

第二，团队不会反对那些关于优化交付内容的反馈。相反地，如果反复否定团队交付成果的价值，从而要求反工，甚至对于设计的颠覆。那确实会影响士气。试问一个孩子花了一个小时，按照图纸搭出来的乐高积木。你看完之后说不好看，不要。请问是小孩的问题，还是图纸问题，还是你的问题？都有可能，但是我们要识别清楚，要认错，要改！

第三，交付团队不是产品负责人的沙盘！不是一句“我们是Agile模式”，就可以随性修改需求，随意拿团队时间做试验。我们需要坚定地去营造一个有进有出的黑盒交付团队。只有这样，产品负责人才会珍惜每一个和团队计划的时间。

交付质量不高？

需求有明确验收标准（AC）定义，且在交付全过程中考虑完成定义（DoD）的团队，他们已经具备了确保质量的机制，应该不会再抱怨质量不高了。或许他们的问题会变成：需求粒度如何再小一些？构如何重构从而使交付更高效？

我对于这个问题的第一感觉给我提出了另外几个问题：

需求描述和验收标准是否过于简单？不符合INVEST原则，从而交付时无法验收/对峙，造成对质量不高的“错觉”。要知道，对于清晰的需求，团队可能会交付得无比高质量！

团队分工协作之间是否衔接不顺畅？例如，开发修改代码逻辑没通知测试针对性的修改测试脚本？这样的事情多了，从而导致团队感觉效率低下，体现在口头描述：交付质量不高。如果是这样，DoD的贯彻需要重申

总结一下，无论是变更频繁还是交付质量不高，实际发生时都有可能是需求或团队单方面造成的。作为对这个问题做分析一方的你，必须要识别其痛点的真实来源。否则就是一团浆糊，一种感觉，一堆抱怨的躁动