Скрам игнорирует качество?

Проблема отношения к качеству в гибких управленческих практиках существует давно. Миф о том, что в Agile некогда делать хорошо потому, что нужно делать быстро, оказался на удивление живучим. Адепты этой точки зрения последовательно игнорируют весь содержащийся в гибких практиках инструментарий по управлению качеством и сложившуюся инженерную культуру. Донесение до команд правильной концепции управления качеством приводит к диалогам наподобие описанного в статье Уильяма-Яна Агелинга

Карла – разработчик в скрам-команде, испытывающей определенные затруднения. Наши сыновья играют в одной футбольной команде и когда мы смотрели их игру, она решила обсудить эти проблемы со мной. Карле известно про мою увлеченность скрамом, поэтому она использует подходящий момент. Ей нравится очень многое в скраме, но у нее сложилось впечатление, что скрам игнорирует качество. Это ощущение явилось причиной интересного диалога.

Я ответил:
«Что же вы упускаете, что вызывает у вас такие ощущения?»

Карла: «Ну, у нас нет гайдлайнов, которые бы помогали нам определить, достаточно ли хорош наш код. Мы просто-напросто ничего не знаем об этом».

Я: «Вы что же, не знаете, в какой момент элемент оказывается в статусе «Сделано»?»

Карла: «Конечно, мы знаем, кода у нас все готово. Это тот момент, когда наш код прошел приемочное тестирование и готов к предварительному развертыванию. Но этого недостаточно. Меня огорчает, что мы не проводим перекрестного ревью кода или — в качестве альтернативы — не занимаемся парным программированием»

Я: «Вы работаете с критерием готовности?»

Карла: «Что вы понимаете под критерием готовности?»

Я: «Критерий готовности, или DoD – это общее понимание момента, когда работа завершена. Похоже, что у вас определен DoD. Ваша команда считает, что работа завершена, когда тестирование пройдено и код готов к предварительному развертыванию. Это ваш DoD»

Карла: «Это просто то, о чем мы никогда не договаривались, но именно так мы и делаем. Но я чувствую, что нужно добавить еще кое-что. Во-первых, конечно, ревью кода, но мне также хотелось бы, чтобы наш владелец продукта одобрял результаты тестирования».

Я: «Хорошо, что команда разработчиков определяет DoD. Это не разовое усилие. DoD развивается вместе с командой. Если вы хотите расширить DoD — в вашем случае добавить ревью кода и одобрение от PO — обсудите это с командой и сделайте так!»

Карла: «Мне это нравится. Тем не менее ... Есть некоторое непонимание с моей стороны. Я рассчитываю на то, что у компании есть указания в этом отношении».

Я: «Что ж, довольно часто у компании есть правила и рекомендации, которые должны соблюдаться всеми командами. DoD для  всех команд должны, как минимум, соответствовать этим правилам. Но команды могут решить расширить их».

Карла: «Получается, требования внутреннего аудита нашей компании тоже должны быть включены в DoD?»

Я: «Да, конечно! Это примеры указаний, которые следует добавить в DoD каждой  из ваших команд.»

Карла: «Большое спасибо за то, что обсудили это со мной. Я передам этот разговор своей команде, чтобы мы смогли создать критерий готовности, который поможет нам поставлять качественный код. Кроме этого, я поговорю с коллегами из других команд и выясню, есть ли у нас общие принципы или подходы, или мы могли бы создать принципы, которых мы сможем придерживаться в качестве DoD, на уровне компании. Я и не знала раньше, что это в руках команды разработчиков, что у нас есть эта важная возможность для обеспечения качества».

Я: «Это звучит как отличный подход. Действительно, скрам расширяет возможности команды разработчиков. Разработчики определяют, сколько работы они могут выполнить в спринте, а также определяют, как они выполняют свою работу, включая определение момента, когда работа завершена.»

Kanban Kanban-метод

Практика построения быстрого потока. Новый мастер-класс!
 

Узнайте больше!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний: