Don’t get it, Don’t make it, Don’t send it!

“Don’t get it, don’t make it, don’t send it” is a slogan to emphasize the ‘quality first’ practice in Gemba Kaizen. It was first formulated by Masaaki Imai and you can read about it more in his book, Gemba Kazien.

“Don’t get it, don’t make it, don’t send it“这句标语在Gemba Kaizen这本书中着重强调”质量第一“。这句口号由Masaaki Imai率先提出，你可以在他的书《Gemba Kazien》中看到它。

Though it was first formulated for production/manufacturing focused industries, as were most of the lean principles, it can be easily applied to software engineering using Agile Methodology.

尽管它最初制定用于生产/集中制造行业中，正如大多数倾斜的法则，通过使用敏捷开发同样可以适用于软件工程中。

Having the QA team as a bottleneck is not uncommon in software delivery projects. Although there are various reasons behind it (such as estimating stories without including the testing effort, tech debt, etc.), an important contributor to that situation is the debt that QAs inherit from the upstream. A poor job done with analysis in the upstream process, will definitely impact the downstream processes such as development, testing and UAT. The cost of lack of quality in a story increases as the story is propagated to the downstream, without addressing the quality issues it contains. It is a cascade effect. The failure demand also inflates.

在软件交付项目中缺少质量管理团队并不少见。虽然有各种各样的原因（比如评估测量工作时没有包括测试工作，技术短板等），但一个更重要的因素是质量的缺失来源于”上游“工作。在”上游“需求分析等工作的糟糕表现直接影响”下游“的工作，比如开发、测试和UAT。在一项工作中，随着任务的继续执行，质量缺失的所造成的成本在不断增长。这是级联效应，导致失败像雪球般滚大。

Following the “don’t get it, don’t make it, don’t send it” principle will have a positive effect on the quality of your product, and will decrease your delivery cycle.

遵循“Don’t get it, don’t make it, don’t send it”的原则，你的产品质量会有明显效果，同时能够减少开发周期。

Don’t get it

If you think that the story you are getting from the upstream (upstream is ‘analysis’ for developers and ‘development’ for QAs in a somewhat rigidly defined delivery project) does not have quality built in, do not get it. Do not accept it.

如果你认为你从”上游“（在软件交付项目中，一定程度上可以定义为质量管理者的开发，为软件开发者进行分析的行为过程）获得的需求文档没有质量保证，不要接受它。

If the story does not have clear (or enough) acceptance criteria to start development, do not get it to develop. If the unit tests are not properly implemented, do not get it to do the functional testing. As quality is not just the responsibility of the QA, but is a practice that is nurtured and matured by the whole team, you have all the leverage to not to accept a poorly analyzed story. Story kick-offs are good instruments for quality checks.

如果需求分析没有明显达到可接受的标准去开始程序开发，不要接受它。如果单元测试没有正确地实现，不要拿它做功能性测试。质量不仅仅只是质量保证的责任，更是一种锻炼，培养和推动整个团队的成熟。你有许多方法不去接受一个糟糕的需求分析。分享出需求分析对于质量检查是一个很好的工具。

Don’t make it

Remember, ‘quality first’. Always. Do not sacrifice quality for the sake of cost or delivery. Any product which a customer is not willing to pay for, is a waste. Keep in mind that delivering a product without meeting quality requirements, does not make any sense. Also, remember the cost of lack of quality. If you sacrifice quality and decrease the first short term visible cost, are you really decreasing your cost? Maybe you are increasing your overall costs. There is a brand image angle as well, which cannot be measured by tangible financial figures.

总是记住，”质量第一“，不要牺牲质量来满足成本和交付的目标。任何客户不愿意支付的产品都是浪费。记住，交付一个没有满足质量需求的产品是没有任何意义的。同时，记住缺少质量所造成的花费。如果你牺牲质量，短时间内降低了可见成本，那么是否真的降低了成本呢？或许你增加了总成本了。还有品牌形象，这是不能用有形资产来衡量的。

Don’t send it

Do not send a batch of work to the downstream (i.e. from analysis to development or from development to QA), if you think that you have not built the necessary quality in. If your downstream is starving for work, it is possible that it is a symptom of failed planning and bad process management. You should not rush and send your work to feed the starving downstream. This kind of behavior will cause more issues, rather than solve your starvation problem. Learn from it and focus on solving the root cause of the starvation. Starving downstream processes are not a root cause by itself, but a symptom of the problems that you may have in your overall process management, such as poor planning, over-engineering and sometimes, even your lack of testing coverage.

如果你还没有把必要的质量考虑在内，不要将这堆任务发到下游（比如从分析到开发或者从开发到质量保证）。如何下游急需工作，那这会是一个失败规划的症状或者糟糕的过程管理。你不应该匆忙地把工作交给下游。这样的行为会产生更多的问题，而不是解决饥饿的问题。从中学习，找到解决饥饿问题真正的根源。下游缺少活儿做本身并不是根源，但在项目管理中问题的症状已经发生了，比如糟糕的计划，过度的工程设计以及测试覆盖率的降低。

To follow these practices, you can use tools or create some guidelines. Having hand-overs between processes might help create awareness when you first start doing it. Try not to make these hand-overs too constraining, so as to not alienate people.

你可以创建一些工具或指导方针来实践。在一开始做的过程中，任务的移交会让你对此有一些感悟。不要使移交太过约束，不然会疏远人的。

But also, keep in mind that you need to create some standards. As Taiichi Ohno said once,

同时，记得创造一些标准出来。正如Taiichi Ohno所说，没有标准就没有改善（持续进步）。

You need tangible and measurable standards to compare and find out your progress. No standards means no improvement. Flexible and Agile software delivery needs a lot of planning and standardization, although it might not seem that way if you are new to such a delivery methodology. You should have story kick-offs, have hand-overs, measure your lead time, code coverage tools, measure your velocity, have retrospectives to reflect and talk about how to improve and make showcases to your users with pride.

你需要实实在在和可衡量的标准进行比较，找出你的进步。没有标准意味着没有改善。灵活和便捷的软件交付需要大量的规划和标准化。如果你对这样的交付模式不是很熟悉，看上去很难实现。你应该有案例分析，移交，预算你的交付时间，代码覆盖工具，测量你的开发速度，回顾反思和讨论如何改善以及自豪地展示给客户看。

There are numerous tools that you can use and methods that you can apply. One size does not fit all. It is up to you to get the most efficient set of methods, sometimes even by trial and error.

你有大量的工具可以使用，有大量的方法可以借鉴。一个尺寸并不适用于所有人。这取决于你通过尝试错误后发现最有效的方法。