QA в SCRUM

Базовые основы и правила SCRUM просты для понимания. Мой опыт показывает, что объяснение сути подхода может быть сведено к пятнадцати минутам, в течение которых сторонний человек поймет все основные роли, артефакты и их связывающие правила. Это также касается людей, совсем не из IT сектора. Последние даже могут быстрее понять о чем идёт речь, так как лишены груза другого опыта.

Но он также и сложен. Его легко понять, однако, его тяжело применить. Вернее будет сказать — тяжело преодолеть те проблемы, которые становятся видимыми в проекте, где применяют SCRUM.

Кен Шуейбер, идеолог SCRUM, говорит, что SCRUM — это всего лишь набор простых правил, благодаря которым основные проблемы проекта становятся очевидными, и далее эффективность его применения зависит только от того, насколько команда и организация в целом захотели и смогли преодолеть эти препятствия. Кен также говорит, что не нужно пытаться изменить SCRUM, он и так состоит из минимального набора правил. Изменение SCRUM всего лишь сделает проблемы снова невидимыми, но не решит их. Это путь в никуда, это путь назад.

Почему же так сложно решить проблемы? Это сложно потому, что очень часто мы сами являемся частью этих проблем; то, как мы привыкли работать и создаёт эти проблемы. Решение же их лежит в изменении наших привычек, что и является большим препятствием. Зачастую бОльшим, чем сами проблемы.

«Вы всегда можете внедрить изменения. Вы всегда можете начать с себя. Вы всегда можете начать прямо сейчас», - так говорит Кент Бек, автор книг про eXtreme Programming.

Часто на тренингах спрашивают о том, что SCRUM думает о QA. Мне нечего сказать, так как SCRUM вообще ничего и ни про что не думает, SCRUM — это набор правил. «А что думают про SCRUM те, кто его формализовал и написал про него книги?» — это обычно второй вопрос из связки. Мой ответ: «В тех книгах нет ни слова про QA».

Но не было такого, чтобы в основах SCRUM не нашёлся искомый ответ на вопросы участников тренинга.

Смотря на схематическое изображение основных артефактов, ролей и правил SCRUM, можно найти как минимум две подсказки про то, как вести QA активности в проекте:

1. «Команда SCRUM должна быть полнофункциональной (cross-functional), то есть должна состоять из всех тех, кто вносит вклад в разработку результата итерации».

В очень маленьких проектах — только разработчики, в проектах побольше — дизайнеры, разработчики и тестировщики, в совсем больших проектах — аналитики, дизайнеры, инженеры баз данных, всякие разные разработчики, тестировщики, технические писатели и др. Только полнофункциональная команда обладает полноценным контролем над ведением проекта и может достичь поставленных на итерацию и проект целей.

2. «По окончанию итерации SCRUM команда должна выпустить срез продукта, потенциально готовый для поставки и использования его конечными пользователями».

Почему «потенциально готовый»? Потому что, не всегда бизнес процесс заказчиков позволяет обновлять продукт для клиентов настолько часто, насколько его может выпускать команда. В этом случае команда всё равно выпускает готовый продукт, и пытается получить выгоду от завершения всех текущих задач.

Для чего нужны такие сложности и связанные с ними накладные расходы? Затем, чтобы в периодические моменты количество незавершенной работы было сведено к нулю, что позволит, во-первых, чётко оценить прогресс всего проекта, а, во-вторых, предотвратит передачу задержек по завершению незаконченной работы из итерации в итерацию. Как известно, годовой проект может быть выпущен на год позже всего лишь, если каждый день будет накапливаться однодневная задержка.

Как же эти базовые принципы поясняют роль и функции QA?

На самом деле довольно просто:

Специалисты по QA должны быть неотъемлемой частью команды. Присутствовать на всех командных встречах, участвовать во всех командных активностях, синхронизировать свою работу со всеми другими членами команды.

Все QA активности, необходимые для выпуска «потенциально готового для поставки среза продукта», должны выполняться внутри каждой итерации.

Легко понять? Да.

Легко воплотить? Нет.

Для пояснения путей решения перечисленных выше задач, сделаем небольшое отступление и рассмотрим типичные проблемы QA в проектах.

На одном из семинаров о SCRUM представители QA довольно много жаловались на возросшее количество работы, которые свалилось на них после того, как проектная команда стала использовать SCRUM. Они говорили: «Теперь нам приходится тестировать и писать тест-кейсы почти одновременно. У нас перестало хватать на всё это времени. Мы не успеваем тестировать, и в конце каждой итерации остаются незакрытые задачи по тестированию». Я сначала не принимал эти высказывания, так как думал, что это всего лишь попытки противостоять необходимости меняться. Но потом я вдруг понял, как объяснить этот факт и добраться до корня проблемы.

На рисунке №1 ниже очень схематически изображена диаграмма Ганта для waterfall проекта (для простоты я отбросил фазы и активности, не связанные с разработкой кода и тестированием):

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

Как видно из рисунка №2 выше, команда, которая привыкла к водопадной модели разработки, при переходе на итеративный подход, всё ещё выполняет активности последовательно. В результате, проект выглядит как набор мини-водопадов, и, как следствие, проблемы урезания качества продукта при затягивании фаз разработки здесь также присутствуют, только в меньшем масштабе. В этом случае качество продукта урезается внутри каждой итераций.

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

На рисунке №3 ниже схематически показано, как это происходит в течение двух итераций.

Обратите внимание на сокращение фазы тестирования и баг-фиксинга на последующей итерации. Это связано с тем, что часть времени, отведённая для этого, ушла на тестирование и починку результатов предыдущей итерации. При всём этом команды стараются выдерживать темпы разработки кода не ниже от итерации к итерации.

Отсюда и возникает нехватка времени у QA на написание тест-кейсов и тестирование, которая усугубляется от итерации к итерации. И это ещё мы не учитываем необходимость выполнения регрессионного тестирования после каждой итерации, объёмы которого растут по мере роста размера продукта. Кен Шуейбер называет такие проекты «iterative incremental death matches».

Такая ситуация ничуть не лучше и не хуже водопадной разработки, просто нехватка времени на тестирование начинает ощущаться уже на ранних фазах проекта, вместо того, чтобы, при водопаде, быть обнаруженной ближе к концу. Отсюда и растущее давление на выделенных QA инженеров, которые после некоторого количества итераций уже просто физически не поспевают за разработчиками, которые, кстати, после ознакомления с технологиями разработки способны выпускать даже больше кода, чем они писали раньше. Вот и корень конфликта.

Как же с этим бороться? Давайте рассмотрим такой важный момент как критерий готовности среза продукта (критерий «done») и его эволюционирование по мере роста осознанности и зрелости команды.

На рисунке №4 ниже представлена так называемая «луковица критерия готовности» для команды, которая внутри итерации успевает писать юнит-тестированный код.

Для проекта, команда которого приняла для себя такой критерий готовности среза продукта, такие активности как приёмочное и регрессионное тестирование, написание сопроводительной документации и т.п., не «вмещаются» в итерацию.

По мере роста осознанности качества внутри команды, всё больше и больше активностей успевают делаться внутри каждой итерации. За счет чего, собственно, и достигается выпуск потенциального готового к поставке среза продукта после каждой итерации. Что и продемонстрировано на рисунке №5 ниже:

За счет чего же это достигается?

Зачастую на вопрос: «Почему вы не пишите юнит-тесты?» или «Почему вы не пишите документацию, когда сами же утверждаете, что она вам нужна?», — я слышу ответ: «У нас просто не хватает на это времеми!».

Существуют такие параметры, которые формируют рамки проекта:

Для одной итерации существует ряд ограничений на варьирование этими параметрами:

Выходит, цель расширения критерия готовности недостижима?

Нет, это не так. На самом деле мы хотим увеличить общий объём работы, выполняющийся внутри каждой итерации.  Объёмамы же каждой из активностей мы можем изменять.

Посмотрите на рисунки №4 и №5.

.За счёт чего команда вдруг может успевать осуществлять приёмочное тестирование внутри итерации, если размер команды и длину итерации оставить такими же, а производительность труда обычно растёт довольно медленно?

У меня один ответ: за счёт экономии времени на написание кода и использование его на тестирование.

Выходит программисты должны писать меньше кода? Выходит, что так.

Или как минимум, программисты не должны писать код, который не будет протестирован внутри этой же итерации.

SCRUM советует иметь полнофункциональные команды. Это неспроста. Вся команда должна быть ответственна за выпуск качественного среза продукта после каждой итерации. Таким образом, во время митинга по планированию итерации (где присутствуют все члены команды) команда должна определить для себя объём работы, который сможет превратить в часть качественного продукта. Следовательно, каждая часть функциональности, выбранной для реализации в этой итерации, должна быть обеспечена всеми необходимыми ресурсами (людьми и временем) для выполнения оговоренных работ, соответствующих критерию готовности. Обычно это написание кода, юнит-тестов, выполнения приёмочного и прочих видов тестирования.

Если в ходе планирования всё доступное время тестировщиков уже распределено, планирование должно быть остановлено, и выбранная часть работы, поддержанная необходимыми ресурсами, считается планом на итерацию.

Что же тогда должны делать программисты, чьё время на итерацию распределено не полностью? Они, как члены команды, должны выполнять ту работу, которая поможет команде достичь целей на итерацию. Если команде не хватает рук для выполнения тестирования, то они, соответственно, должны использовать свои знания и навыки для облегчения выполнения этих задач. Чаще всего это написание или интеграция инструментов автоматического тестирования.

Этого тяжело добиться. Поэтому хорошие команды и продукты встречаются не так часто. Но всё же они есть.

Скорее всего у вас не выйдет реализовать все идеи с первой итерации. Но этого от вас никто и не требует. Понимание проблем — это уже половина успеха. Используйте итеративность, заложенную в ваш процесс, как возможность абстрагироваться от повседневной рутины и подумать об их решении как цельная команда.

Ставьте реальные цели (к примеру, расширить критерий готовности на ещё одну активность внутри итерации), когда все члены команды будут чувствовать себя комфортно.

Пробуйте, анализируйте, обсуждайте, и делайте коррективы с учётом полученных знаний.

Из всего этого можно сделать, как минимум, следующие выводы:

Статья от 10/2007