Проблема отношения к качеству в гибких управленческих практиках существует давно. Миф о том, что в Agile некогда делать хорошо потому, что нужно делать быстро, оказался на удивление живучим. Адепты этой точки зрения последовательно игнорируют весь содержащийся в гибких практиках инструментарий по управлению качеством и сложившуюся инженерную культуру. Донесение до команд правильной концепции управления качеством приводит к диалогам наподобие описанного в статье Уильяма-Яна Агелинга
Карла – разработчик в скрам-команде, испытывающей определенные затруднения. Наши сыновья играют в одной футбольной команде и когда мы смотрели их игру, она решила обсудить эти проблемы со мной. Карле известно про мою увлеченность скрамом, поэтому она использует подходящий момент. Ей нравится очень многое в скраме, но у нее сложилось впечатление, что скрам игнорирует качество. Это ощущение явилось причиной интересного диалога.
Я ответил: «Что же вы упускаете, что вызывает у вас такие ощущения?»
Карла: «Ну, у нас нет гайдлайнов, которые бы помогали нам определить, достаточно ли хорош наш код. Мы просто-напросто ничего не знаем об этом».
Я: «Вы что же, не знаете, в какой момент элемент оказывается в статусе «Сделано»?»
Карла: «Конечно, мы знаем, кода у нас все готово. Это тот момент, когда наш код прошел приемочное тестирование и готов к предварительному развертыванию. Но этого недостаточно. Меня огорчает, что мы не проводим перекрестного ревью кода или – в качестве альтернативы – не занимаемся парным программированием»
Я: «Вы работаете с критерием готовности?»
Карла: «Что вы понимаете под критерием готовности?»
Я: «Критерий готовности, или DoD – это общее понимание момента, когда работа завершена. Похоже, что у вас определен DoD. Ваша команда считает, что работа завершена, когда тестирование пройдено и код готов к предварительному развертыванию. Это ваш DoD»
Карла: «Это просто то, о чем мы никогда не договаривались, но именно так мы и делаем. Но я чувствую, что нужно добавить еще кое-что. Во-первых, конечно, ревью кода, но мне также хотелось бы, чтобы наш владелец продукта одобрял результаты тестирования».
Я: «Хорошо, что команда разработчиков определяет DoD. Это не разовое усилие. DoD развивается вместе с командой. Если вы хотите расширить DoD – в вашем случае добавить ревью кода и одобрение от PO – обсудите это с командой и сделайте так!»
Карла: «Мне это нравится. Тем не менее … Есть некоторое непонимание с моей стороны. Я рассчитываю на то, что у компании есть указания в этом отношении».
Я: «Что ж, довольно часто у компании есть правила и рекомендации, которые должны соблюдаться всеми командами. DoD для всех команд должны, как минимум, соответствовать этим правилам. Но команды могут решить расширить их».
Карла: «Получается, требования внутреннего аудита нашей компании тоже должны быть включены в DoD?»
Я: «Да, конечно! Это примеры указаний, которые следует добавить в DoD каждой из ваших команд.»
Карла: «Большое спасибо за то, что обсудили это со мной. Я передам этот разговор своей команде, чтобы мы смогли создать критерий готовности, который поможет нам поставлять качественный код. Кроме этого, я поговорю с коллегами из других команд и выясню, есть ли у нас общие принципы или подходы, или мы могли бы создать принципы, которых мы сможем придерживаться в качестве DoD, на уровне компании. Я и не знала раньше, что это в руках команды разработчиков, что у нас есть эта важная возможность для обеспечения качества».
Я: «Это звучит как отличный подход. Действительно, скрам расширяет возможности команды разработчиков. Разработчики определяют, сколько работы они могут выполнить в спринте, а также определяют, как они выполняют свою работу, включая определение момента, когда работа завершена.»
