Как заставить Scrum работать на вас, а не вас работать по Scrum? Тонкости организации процесса тестирования или те самые рифы в том самом море

Для начала – пара слов о моем проекте. Проект называется ППО «Территория» и представляет собой комплекс модульных программных продуктов для обеспечения взаимодействия различных государственных организаций и структур, таких как МВД, ФМС, ФСБ, ФТС, Федеральное казначейство и прочее.

Если вы думаете, что можете представить себе объем выполняемых каждый день работ – то вы не можете! Вы не можете представить себе то количество нормативно-правовых актов, законопроектов, шаблонов, спец. бланков и постановлений, в соответствии с которыми должна функционировать наша разрабатываемая система. Вы не сможете представить и то, какую непреступную крепость бюрократии необходимо взять штурмом, для того, чтобы внести в ПО хотя бы незначительные изменения. А уж про предложение изменить какой-то бизнес-процесс, даже если он будет намного приемлемей в текущей ситуации можно даже не заикаться.

Стоит ли говорить, что на таких проектах вопрос контроля качества выпускаемого ПО стоит на первостепенном месте? Стоит ли лишний раз упоминать о том, что при работе с гос. заказчиками, тем более на проекте с таким уровнем интегрированности систем друг в друга, любая, даже самая незначительная ошибка может стоит сотри тысяч, а то и миллионы рублей? Думаю, это очевидно.

Проект начинался достаточно давно, когда о Scrum как о методологии управления проектами было очень мало известно. И весь процесс разработки и тестирования был построен на «крайних» за каждый отдельный модуль. У каждого модуля системы был ответственный бизнес-аналитик, разработчик и тестировщик, которые в совокупности и несли ответственность за качество каждого отдельного модуля. С таким подходом выпускать релизы получалось не чаще, чем раз в несколько месяцев, что по большей части устраивало заказчиков…но на протяжении весьма недолгого промежутка времени. С недавних пор заказчик выдвинул «хотелку» переросшую в требование выпускать релиз не реже 1 раза в 2 недели и выполнять большее количество задач в установленные сроки. С этого момента и началась история Scrum в нашем проекте. Но началась она не с чистого листа, а с анализа ошибок и тонкостей методологии, полученных от наших «коллег по цеху» в самых разных уголках России и мира в целом. И вот к чему мы пришли:

При переходе на Scrum мы первоначально поставили перед собой следующие вопросы:

· Как обеспечить максимально эффективное планирование с минимальным «простоем» тестировщиков?

· Как организовать максимально эффективное и полное тестирование задач, запланированных в рамках спринта и исключить возникновение «технического долга»?

· Как добиться максимального уровня качества выпускаемого релиза и не оставить неразрешенных задач?

Рассмотрим эти вопросы и найденные нами решения более детально.

Как обеспечить максимально эффективное планирование с минимальным «простоем» тестировщиков?

Данный вопрос возник не просто так.

На нашем проекте спринт длится 2 недели. Релиз выпускается в конце каждой второй-третьей итерации. Ориентировочное количество задач, которые планируются каждый спринт – порядка пятидесяти, что занимает очень большой промежуток времени – порядка 3 часов каждое планирование. На проекте 4 Scrum-команды и в каждой в среднем 5 тестировщиков. Нетрудно подсчитать, что при «обычных обстоятельствах» каждый спринт на планирование задач у отдела тестирования может уходить порядка 120(!!!) часов. Почему так много спросите вы? Да потому, что помимо присутствия на планировании разработчиков у нас было и «свое» - планирование тестировщиков, на которое уходило не многим меньше времени.

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

Решением данной проблемы стало разбиение спринтов разработчиков и спринтов тестировщиков и отталкивание точки релиза от спринта тестировщиков. То есть мы преобразовали упомянутый мной ранее «минус» в виде отставания от разработчиков на «плюс». Свое планирование без присутствия на планировании разработчиков – это раз! Результатом работы отдела разработки в конце спринта является конечное и прозрачное количество выполненных задач, которое попадает прямиком в так называемый бэклог тестирования, где они усилиями тестировщиков приоритизируются, эстимируются и на ближайшем планировании включаются в работу – это два! Независимость от количества, потраченного времени на разработку каждой задачи – это три! Больше нет необходимости ждать программиста пока он выполнит задачу, чтобы взять ее в тестирование – он сделал это раньше. Покопавшись еще немного, вполне можно найти и еще преимущества, но даже уже упомянутых вполне достаточно для применения этого метода для организации планирования отдела тестирования!

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

Таким нехитрым способом мы уменьшили время на планирование тестирования задач спринта, доведя его на текущий момент до 10 часов за спринт, что при наших объемах выполняемых работ критично!

Как организовать максимально эффективное и полное тестирование задач, запланированных в рамках спринта?

Автоматизация!!! – скажете вы. И будете абсолютно правы! Однако, это не простой процесс написания автотестов всеми тестировщиками с последующим их запуском, прогоном и прочими аспектами. Как я уже говорил – у нас гигантский проект с невероятным количеством решаемых задач. И если бы каждый тестировщик писал бы автотесты на каждую разрабатываемую фичу – никто ничего бы не успел.

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

И последний, самый очевидный вопрос, который предстояло решить –