Home

Автор: Ярослав Хорошкин

Оригинальная публикация: http://quality-lab.ru/experience-with-using-scrumban-in-testing/

За последние 20 лет Agile, Lean, Scrum и Kanban неуклонно завоевывают популярность в различных сферах и отраслях экономики. И это правильно, так как именно благодаря гибким технологиям многие компании смогли закончить свои проекты быстрее и\или увеличить прибыль. 

Но что же такое Agile и Lean? Что такое Scrum и Kanban? Чем они хороши, и какая между ними разница? И самое главное: как все это работает в сфере тестирования? В данной статье я постараюсь ответить на эти вопросы.

Что такое Agile и Lean

Agile является время-ориентированной итерационной философией, позволяющей создать продукт, разбивая процесс на отдельные фрагменты. Одно из ее главных преимуществ – способность адаптироваться и меняться на любом шаге (в зависимости от обратной связи, конъюнктуры рынка, корпоративных препятствий и т.д.) и поставлять только соответствующие рынку продукты.

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

Lean (бережливый) подход имеет долгую историю применения в промышленности. В последние годы он завоевал популярность и в области разработки ПО, в которой представлен следующими семью принципами, впервые опубликованными в книге «Lean Software Development: An Agile Toolkit»:

- Исключение потерь. Потерями считается все, что не добавляет ценности для потребителя.
- Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.
- Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а лишь после открытия существенных фактов.
- Предельно быстрая доставка заказчику. Короткие итерации.
- Мотивация команды. Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий.
- Интегрирование. Рефакторинг. Важно передать целостную информацию заказчику и стремиться к целостной архитектуре.
- Целостное видение. «Мыслить широко, делать мало, ошибаться быстро, учиться стремительно».

Чем хороши Scrum и Kanban, и какая между ними разница

Scrum
Scrum – это универсальная система управления проектами, позволяющая получать необходимый эффект при минимальных затратах ресурсов. Основополагающий принцип Scrum гласит: разделение времени, продукта и организации оптимизирует процесс и гарантирует впечатляющие результаты. Методология Scrum помогает универсальным и самоорганизующимся командам, трудящимся на протяжении спринта, сделать работающее и потенциально пригодное к выпуску программное обеспечение.

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

Kanban (в отличие от Scrum) – не итеративный добавочный метод, базирующийся на пяти основных действиях:

- Визуализация рабочего процесса.
- Ограничение Work in Progress (WIP).
- Управление рабочим процессом.
- Прозрачность политики процесса.
- Улучшения совместными усилиями.

Группы, использующие Kanban, часто работают с различными процессами. Метод Kanban – это не более чем набор приемов для управления процессом и последующей целенаправленной его оптимизации. Kanban легко адаптируется к уже существующим системам, в том числе к Scrum. Обе эти методологии придают большое значение непрерывному улучшению, оптимизации работы и процесса. С их помощью объемные и сложные задачи можно раздробить на отдельные фрагменты и выполнить более качественно.

Центральным элементом эффективности этих методологий является Кайдзен – образ мышления, направленный на постоянное совершенствование. И Scrum, и Kanban уделяют много внимания организации рабочего процесса, стремясь удерживать всех членов команды в курсе WIP и перспектив развития. Scrum, как правило, лучше использовать для управления процессом разработки, в котором есть много неопределенностей, тогда как Kanban лучше подходит для долгосрочного поддержания проекта. В ряде случаев наибольшая эффективность достигается при использовании лучших инструментов обеих методологий.

Кликните на картинку, чтобы увеличить изображение

Как все это вместе работает и применяется в области тестирования

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

Преамбула
Первоначально проект работал по Scrum. Использование всех инструментов было верным, однако не давало нужного результата. Очистка доски после каждого спринта и большая нагрузка по задачам приводили к переполнению бэклога. Когда стало понятно, что количество задач не уменьшается, было принято решение о смене методологии. Методологией с нужными инструментами оказался Kanban, но при этом мы не хотели отказываться и от инструментов Scrum-а. Как оказалось, существует методология Scrumban, в которой можно использовать только нужные решения из обеих методологий.

Последовательность наших действий:
1. Формирование бэклога.

Бэклог – это проявление видения и бизнес-плана продукта. Бэклог состоит из Product Backlog Items (PBI’s). PBI может быть что угодно: от требований рынка до юзер-кейсов и спецификаций. Для начала мы полностью переработали бэклог. Все задачи были поделены на классы (Bug verification, Regression testing or Testing, Planning, etc). Sprint был сделан годичным, что помогло более точно отбирать задачи, решение которых необходимо на данный момент. Если в рамках текущего релиза возникало какое-либо уточнение (например, появлялись новые исправленные баги, входящие в текущий релиз), то на каждое такое изменение создавалась задача, которая включалась в спринт для немедленного выполнения.

Кликните на картинку, чтобы увеличить изображение

2. Заполнение доски.
Команда участвовала в планировании и корректировке спринта (добавление задач из бэклога или создание новых при необходимости). Все задачи из спринта переносились на доску, где и находились до их закрытия. При этом доска могла быть как цифровой (Trello, Jira и т.п.), так и аналоговой (белая доска, маркеры, стикеры).

Наша доска состояла из 4 колонок: To do (задачи, которые еще не начинали делать), In progress (задачи, над которыми работают в данный момент), Wait for info (задачи, ожидающие уточнения или любой другой информации, без которой невозможна дальнейшая работа) и Done (завершенные задачи).

Формирование колонки To do происходило согласно приоритетам, формирующимся в соответствии с релизами. В течение дня член команды выбирал задачу, висящую на доске в статусе To do, и перемещал ее в колонку In progress, начиная работу над ней. После завершения задачи ее карточка перемещалась в колонку Done. Таким образом, вся команда видела, кто над какой задачей работает, и какие задачи еще необходимо сделать.

Колонок на доске может быть больше. Главное, чтобы вся команда понимала, в каком статусе сейчас находится задача, кто ответственен за ее выполнение, и что нужно сделать для того, чтобы она была завершена. В целом, работа с доской и работа по методологии для команд тестирования практически не отличаются от работы команд разработчиков. Главное отличие от Scrum заключается в том, что каждая колонка лимитирована (то есть, в колонке не может быть больше определенного количества задач). Лимит устанавливается на совместном обсуждении при создании доски.

Кликните на картинку, чтобы увеличить изображение

3. Проведение митингов.
Для корректировки и правильного планирования проводится ежедневный митинг (у нас данное мероприятие проходило в начале дня). Есть одно обязательное условие: каждый новый митинг ведет новый ведущий. Соответственно, каждый член команды в порядке очередности должен побывать в роли ведущего. Во время митинга происходит корректировка приоритетов выполнения задач.

Также ведущий уточняет прогресс и задает интересующие его вопросы по каждой задаче в колонке In Progress, например:

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

и т.д.

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

4. Демонстрация.
Демо – самая захватывающая часть Scrum, во время которой команда показывает все то, что она сделала за прошедшее время, озвучивает цель спринта и демонстрирует готовый инкрементный продукт (при этом не показываются неготовые фичи). Каждый присутствующий на демонстрации может высказать свое мнение о продукте: что ему нравится, что бы он изменил, какие идеи по улучшению продукта у него есть.

Демонстрация в тестировании не проводится, и это является единственным отличием от использования методологии Scrumban в разработке. Во-первых, у нас нет спринтов как таковых. Во-вторых, тестировщики могут выдать только готовый результат (если тестирование закончено); в противном случае показывать просто нечего. Единственная информация, характеризующая ход тестирования, – это прогресс тестирования продукта в процентах.

5. Проведение ретроспективы.
Ретроспектива – это встреча, на которой команда обсуждает только что завершившийся спринт или период времени. Проведение ретроспективы – неотъемлемая часть процесса. При ретроспективе присутствует вся команда тестирования.

Происходит оценка результативности команды, исходя из трех основных вопросов:

- Что прошло хорошо?
- Что пошло не так?
- Что необходимо улучшить?

В начале стоит кратко напомнить про цели ретроспективы, процедуру и ожидаемые результаты. Важно настроить людей на конструктивное взаимодействие; они должны быть готовы давать обратную связь, анализировать ситуацию и предлагать решения. Например, можно сделать так, чтобы каждый сказал хотя бы несколько слов, – ведь первый шаг всегда наиболее труден.

Примеры вопросов для оценки:

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

и т.д.

По итогам ретроспективы составляется план улучшений, который поможет команде повысить скорость тестирования.

Кликните на картинку, чтобы увеличить изображение

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

Вывод

Конечно, предложенная схема действий совсем не обязательно подойдет вашему проекту. Но среди огромного разнообразия инструментов вы можете подобрать именно те, которые будут полезны для вашей работы. В конце концов, соберите свой инструмент, как это сделали мы!

Обсудить в форуме