Друзья, всем привет!
Хочу рассказать вам немного о нашем процессе разработки программного обеспечения и методологиях, которые мы применяем. А особенно о том, как у нас организуется тестирование при использовании этих методологий. Для организации процесса разработки мы начинали использовать Scrum, потом перешли на Kanban. Очень подробно и понятно эти методологии описаны в книге Хенрика Книберга и Маттиаса Скарина «SCRUM и Kanban: Выжимаем Максимум». Она небольшая и очень полезная, даже если вы уже работаете по одной из этих методологий, советую прочитать, чтобы упорядочить свои знания.
Kanban - достаточно свободная методология, содержащая не так много правил:
- визуализация потока работ (работа разбивается на части, каждая часть находится на какой-то стадии выполнения - в каком-то столбце)
- ограничение НЗР (незавершенной работы) (определение возможного количества незавершенных пунктов на каждой стадии процесса разработки ПО)
- измерение времени выполнения задачи (нужно свести время выполнения задачи к минимуму и сделать его максимально прогнозируемым).
Как я писала здесь, в качестве доски мы используем Trello. Для визуализации потока работ у нас имеются колонки -
Для определенных нами колонок у нас установлено ограничение НЗР (указано в скобках). Также для этих колонок (стадий выполнения) у нас имеются критерии готовности - в виде обычной карточки в колонке, просто она выделена цветом и размером шрифта для наглядности. В идеале, только при выполнении всех критериев задача может перемещаться из текущей колонки в следующую колонку.
Давайте рассмотрим все колонки по порядку. Самой первой у нас идет колонка "Цель и Улучшения". Вообще в Kanban нет предписания использовать эту колонку, мы сами решили ее завести, чтобы у нас всегда перед глазами была цель работы, которую мы выбрали на последнем планировании, и улучшения, которые мы взяли в работу. Таким образом, на каждом daily-митинге мы стараемся обсуждать, что мы делаем для достижения цели и выполнения улучшений. Поскольку они у нас всегда перед глазами, мы про них не забываем :)
Следующей идет колонка "План". У нас нет ограничения НЗР для этой колонки. В этой колонке у нас находятся юзер-стори, баги, фича реквесты, которые нужно выполнить до следующего релиза, а чаще до следующих двух релизов (потому что добавляются новые задачи и меняются приоритеты). Все элементы этой колонки располагаются в порядке приоритета, выбирается обычно первый элемент для перетаскивания в колонку "Анализ". Также в этой колонке у нас заводится карточка для юзер-стори по подготовке и выпуску релиза. Она помещается под всеми карточками задач, которые должны войти в релиз. Таким образом, мы всегда видим, что у нас находится в плане до следующего релиза. Например, колонка "План" может выглядеть так (здесь в плане находятся еще 2 юзер-стори до выпуска релиза версии 1.1.2):
Рассмотрим колонку "Анализ". Критерии готовности для этой колонки следующие
В этой колонке может находиться только одна юзер-стори. На этой стадии выполнения работы мы составляем макеты (если они нужны), которые затем приаттачиваем к карточке этой юзер-стори. Также мы пишем приемочные тест-кейсы, которые должен посмотреть хотя бы один разработчик, и в идеале составляем сценарии, по которым мы будем показывать реализованный функционал на демо (если вы вообще решите проводить демо, возможно, оно вам и не понадобится).
После анализа задача попадает в стадию "Разработка". Ограничение НЗР для этой колонки составляет 2 юзер-стори + багфикс. Например, эта колонка может выглядеть так:
Мы специально завели карточку "Bugfix" для фикса багов. Те разработчики. которые этим занимаются, отмечают себя на карточке. После реализации юзер-стори и выполнения всех критериев готовности она переходит в колонку тестирование. Эта колонка выглядит примерно так:
Разработка у нас идет следующим образом - каждая новая фича разрабатывается в отдельной ветке. При попадании задачи на стадию тестирования, мы очень тщательно тестируем эту фичу в ветке разработки. После выполнения третьего критерия готовности, мы сливаем фичу из своей ветки в главную ветку. В этой главной ветке мы еще раз тестируем продукт по приемочным тест-кейсам. Наконец, после выполнения всех критериев готовности, мы сливаем изменения в главной ветке в ветку релиз и наша карточка перемещается в следующий столбец. Также в этой колонке у нас находятся карточки каких-то важных багов, которые нужно проверифицировать, и юзер-стори для UI автотестов.
В столбце "Релиз" у нас находятся карточки всех задач (юзер-сторей, багов), реализованных за текущий релиз. Этот список очень помогает при составлении release notes и обновлении документации во время выпуска релиза. После выпуска релиза все карточки из этого столбца переносятся в архив.
И напоследок, еще пару слов о нашем процессе. Каждый день утром мы проводим митинг (это мы взяли из скрама), на котором вначале в порядке приоритета (обычно это разработка - тестирование - анализ - план) мы обсуждаем то, что было сделано по задачам в предыдущий день, затем любой член команды может рассказать что-то о том, что он делал вчера и что не касалось текущих задач на доске, и в конце мы обсуждаем цель и улучшения. Как таковых итераций у нас нет. Демо, ретроспективы и планирования мы проводим по мере необходимости.
Вот вкратце и все. Надеюсь, эта информацию будет для вас полезной. И, конечно, с удовольствием отвечу на ваши вопросы. Всем пока! Пока!
Комментариев нет:
Отправить комментарий