Ознакомившись с постами, в которых хабрапользователи описывают процессы внедрения и реализации гибких методологий в производство, решил поделиться собственным опытом разработки по методологии Kanban в небольшой продуктовой команде.
К моменту, когда у нас возникло желание попробовать новую систему организации процесса, мы были сработанной командой, ведущей успешную Scrum разработку.
Не буду загружать пост теорией и всяческой водой, на хабре достаточно статей о Kanban и бережливом производстве. Перейду сразу к описанию процесса.
Внедряя Kanban, мы стремились улучшить процесс разработки до максимума и добиться полного отсутствия дефектов в выпускаемом продукте. Поэтому внедрять методологию мы начали с анализа текущего процесса, который на тот момент был построен на Scrum. Анализ заключался в составлении карты ценностей — граф на котором изображались все этапы процесса производства. Рассматривая каждый шаг процесса, мы исключали те этапы, которые задерживали нас или вызывали дискомфорт у участников производства. Замечу, что к анализу процесса мы возвращались постоянно.
Результатом анализа стала карта нашего будущего процесса. Каждый из этапов процесса имеет свой столбец на Kanban доске, причем каждый этап (кроме Pull) имеет два столбца: In Progress и Done.
Для каждого этапа определен список критериев готовности. Если хотя бы одному из критериев фича не соответствует, она не может перейти в следующий столбец.
Остановлюсь подробно на каждом из этапов.
Pull — это буфер, в который Product Owner (PO) добавляет новые задачи из бэклога. Буфер имеет ограничение на количество задач. На доске задачи размещаются в порядке приоритета. PO в любой момент может изменить приоритет задачи или вовсе заменить задачу на другую.
Когда в процессе разработки появляется полностью свободный разработчик, он берет наиболее приоритетную задачу из pull’а и переводит задачу в статус анализ.
Обычно, разработчик, взявший фичу в разработку, становится ответственным за нее. Ответственный на всем этапе разработки следит за состоянием фичи, у него PO в любой момент может узнать текущий статус фичи.
На этапе анализа собирается группа, состоящая из тестировщика(ов) и разработчика(ов). Они всевозможными способами вытягивают из PO подробности задачи, так как описания в бэклоге бывает часто недостаточно. В процессе такого обсуждения PO нередко изменяет некоторые детали фичи, а в некоторых случаях и отказывается от неё. Во время анализа также выписываются тестовые случаи, т.е. всевозможное поведение пользователя и соответствующая реакция системы. Вся полученная информация записывается в спецификации. Если фича предполагала создание интерфейсов, то рисуются прототипы интерфейсов (скетчи), что позволит затем оформить подзадачу для разработчика интерфейсов.
Благодаря фазе анализа функционал точно соответствовал пожеланиям заказчика и мы не тратили время на переделывание.
После окончания анализа, группа разработчиков начинает проектирование технической реализации задачи. Результатом такого проектирования являются технические спецификации архитектуры (диаграммы классов, sequence diagram’ы и т.п.). Разработчики довольно часто проводят презентации архитектуры для всей команды, чтобы выслушать критику или убедиться в совершенстве предложенного решения.
Разобравшись с техническими деталями, можно разбить задачу на более мелкие подзадачи (если это имеет смысл).
Благодаря вдумчивому и детальному проектированию код начал выходить практически без багов.
Итак, фича полностью готова к непосредственной реализации. Свободные разработчики разбирают задачи и перевешивают их в столбец разработка. Разработка каждой фичи ведется в отдельной ветке основного репозитория. При кодировании практически всех задач мы используем TDD и парное программирование. Каждый разработчик проводит функциональное и интеграционное тестирование. О плюсах данных практик написано достаточно много и заострять внимание на них не стоит.
Покончив с кодом, интерфейсами, файлами миграций БД и всем, что включает в себя задача, выставляем ее на ревью.
Любой свободный разработчик, а иногда вся команда разработчиков проводит review задачи. Этому этапу мы уделяем значительное внимание. Кроме беглого просмотра кода на соответствие code convention, ревьювер проверяет работоспособность реализованной фичи и анализирует написанные юнит-тесты.
Данный этап позволяет избежать мелких неточностей в коде и дает возможность всей команде ознакомиться с различными компонентами разрабатываемой системы.
Задача прошедшая ревью попадает в очередь на тестирование. Освободившийся тестировщик берет фичу в оборот. Ее прогоняют по всем кругам тестерского ада, подвергая функциональному, нагрузочному, регрессионному тестированию. Тестирование ведется строго в ветке фичи.
После завершения процесса тестирования, фича деплоится на demo сервер — происходит merge кода и накатываются нужные миграции. На demo сервере PO может смотреть результаты работы.
Успешно задеплоеную фичу подвергают верификации — проводится интеграционое и регрессионное тестирование.
Разобравшись со всеми этапами процесса производства, поговорим об ограничениях. Для чего они нужны? А для того, чтобы все внимание сосредоточить на качестве выпускаемого продукта. Если разработчики начнут бесконтрольно клепать фичи пачками, то отдел тестирования просто не будет успевать тестировать все фичи к сроку. Чтобы избежать подобных ситуаций практическим путем подбираем ограничения на столбец или на группы столбцов. Теперь, например, когда у нас в ревью будет висеть слишком много задач, разработчик не сможет брать в разработку новые фичи, пока не будет проведено ревью уже готовых фич. Тем самым мы лишаем неаккуратных торопливых разработчиков соблазна создавать код с дефектами.
В процессе описания процесса производства, я упоминал только успешные исходы каждого этапа. Так как именно к такому исходу необходимо стремиться. Однако, по ходу становления идеального процесса производства, на свет появляются продукты с дефектами. Мы вынуждены возвращать задачу на шаг (или более) назад. Например, если задача не прошла ревью и тестирование, она снова возвращается в разработку, а иногда и в проектирование (это необходимо обязательно учитывать при расстановке ограничений). Если произошел подобный возврат — это сигнал о том, что в процессе возник дефект (потеря) и необходимо останавливать процесс и проводить анализ этого дефекта. На практике, мы редко делали остановку, чаще потеря фиксируется в журнале возвратов. Когда в журнале накапливается достаточно весомых дефектов, мы собираем митинг, на котором происходит анализ дефектов. По результатам анализа принимаются меры, которые помогут избежать повторения дефекта в процессе производства.
Конечно, не сразу все пошло гладко и красиво. Но постоянное улучшение процесса дало свои результаты. Через пол года нам значительно удалось ускорить процесс разработку (burndown графики указывали ускорение в 2.1 раза), а также намного повысить качество выпускаемого продукта. Тестировщики признавались, что находить баги стало сложнее, а ситуации «тут починили — там сломали» исчезли вообще.
Процессы
Kanban (development)
Kanban Applied to Software Development: from Agile to Lean
Lean Software Engineering
Инструменты
Обзор Kanban досок
К моменту, когда у нас возникло желание попробовать новую систему организации процесса, мы были сработанной командой, ведущей успешную Scrum разработку.
Не буду загружать пост теорией и всяческой водой, на хабре достаточно статей о Kanban и бережливом производстве. Перейду сразу к описанию процесса.
Внедряя Kanban, мы стремились улучшить процесс разработки до максимума и добиться полного отсутствия дефектов в выпускаемом продукте. Поэтому внедрять методологию мы начали с анализа текущего процесса, который на тот момент был построен на Scrum. Анализ заключался в составлении карты ценностей — граф на котором изображались все этапы процесса производства. Рассматривая каждый шаг процесса, мы исключали те этапы, которые задерживали нас или вызывали дискомфорт у участников производства. Замечу, что к анализу процесса мы возвращались постоянно.
Результатом анализа стала карта нашего будущего процесса. Каждый из этапов процесса имеет свой столбец на Kanban доске, причем каждый этап (кроме Pull) имеет два столбца: In Progress и Done.
Для каждого этапа определен список критериев готовности. Если хотя бы одному из критериев фича не соответствует, она не может перейти в следующий столбец.
Остановлюсь подробно на каждом из этапов.
Pull
Pull — это буфер, в который Product Owner (PO) добавляет новые задачи из бэклога. Буфер имеет ограничение на количество задач. На доске задачи размещаются в порядке приоритета. PO в любой момент может изменить приоритет задачи или вовсе заменить задачу на другую.
Анализ
Когда в процессе разработки появляется полностью свободный разработчик, он берет наиболее приоритетную задачу из pull’а и переводит задачу в статус анализ.
Обычно, разработчик, взявший фичу в разработку, становится ответственным за нее. Ответственный на всем этапе разработки следит за состоянием фичи, у него PO в любой момент может узнать текущий статус фичи.
На этапе анализа собирается группа, состоящая из тестировщика(ов) и разработчика(ов). Они всевозможными способами вытягивают из PO подробности задачи, так как описания в бэклоге бывает часто недостаточно. В процессе такого обсуждения PO нередко изменяет некоторые детали фичи, а в некоторых случаях и отказывается от неё. Во время анализа также выписываются тестовые случаи, т.е. всевозможное поведение пользователя и соответствующая реакция системы. Вся полученная информация записывается в спецификации. Если фича предполагала создание интерфейсов, то рисуются прототипы интерфейсов (скетчи), что позволит затем оформить подзадачу для разработчика интерфейсов.
Благодаря фазе анализа функционал точно соответствовал пожеланиям заказчика и мы не тратили время на переделывание.
Проектирование
После окончания анализа, группа разработчиков начинает проектирование технической реализации задачи. Результатом такого проектирования являются технические спецификации архитектуры (диаграммы классов, sequence diagram’ы и т.п.). Разработчики довольно часто проводят презентации архитектуры для всей команды, чтобы выслушать критику или убедиться в совершенстве предложенного решения.
Разобравшись с техническими деталями, можно разбить задачу на более мелкие подзадачи (если это имеет смысл).
Благодаря вдумчивому и детальному проектированию код начал выходить практически без багов.
Разработка
Итак, фича полностью готова к непосредственной реализации. Свободные разработчики разбирают задачи и перевешивают их в столбец разработка. Разработка каждой фичи ведется в отдельной ветке основного репозитория. При кодировании практически всех задач мы используем TDD и парное программирование. Каждый разработчик проводит функциональное и интеграционное тестирование. О плюсах данных практик написано достаточно много и заострять внимание на них не стоит.
Покончив с кодом, интерфейсами, файлами миграций БД и всем, что включает в себя задача, выставляем ее на ревью.
Review
Любой свободный разработчик, а иногда вся команда разработчиков проводит review задачи. Этому этапу мы уделяем значительное внимание. Кроме беглого просмотра кода на соответствие code convention, ревьювер проверяет работоспособность реализованной фичи и анализирует написанные юнит-тесты.
Данный этап позволяет избежать мелких неточностей в коде и дает возможность всей команде ознакомиться с различными компонентами разрабатываемой системы.
Тестирование
Задача прошедшая ревью попадает в очередь на тестирование. Освободившийся тестировщик берет фичу в оборот. Ее прогоняют по всем кругам тестерского ада, подвергая функциональному, нагрузочному, регрессионному тестированию. Тестирование ведется строго в ветке фичи.
Deploy
После завершения процесса тестирования, фича деплоится на demo сервер — происходит merge кода и накатываются нужные миграции. На demo сервере PO может смотреть результаты работы.
Верификация
Успешно задеплоеную фичу подвергают верификации — проводится интеграционое и регрессионное тестирование.
Ограничения
Разобравшись со всеми этапами процесса производства, поговорим об ограничениях. Для чего они нужны? А для того, чтобы все внимание сосредоточить на качестве выпускаемого продукта. Если разработчики начнут бесконтрольно клепать фичи пачками, то отдел тестирования просто не будет успевать тестировать все фичи к сроку. Чтобы избежать подобных ситуаций практическим путем подбираем ограничения на столбец или на группы столбцов. Теперь, например, когда у нас в ревью будет висеть слишком много задач, разработчик не сможет брать в разработку новые фичи, пока не будет проведено ревью уже готовых фич. Тем самым мы лишаем неаккуратных торопливых разработчиков соблазна создавать код с дефектами.
Возвраты
В процессе описания процесса производства, я упоминал только успешные исходы каждого этапа. Так как именно к такому исходу необходимо стремиться. Однако, по ходу становления идеального процесса производства, на свет появляются продукты с дефектами. Мы вынуждены возвращать задачу на шаг (или более) назад. Например, если задача не прошла ревью и тестирование, она снова возвращается в разработку, а иногда и в проектирование (это необходимо обязательно учитывать при расстановке ограничений). Если произошел подобный возврат — это сигнал о том, что в процессе возник дефект (потеря) и необходимо останавливать процесс и проводить анализ этого дефекта. На практике, мы редко делали остановку, чаще потеря фиксируется в журнале возвратов. Когда в журнале накапливается достаточно весомых дефектов, мы собираем митинг, на котором происходит анализ дефектов. По результатам анализа принимаются меры, которые помогут избежать повторения дефекта в процессе производства.
Результат
Конечно, не сразу все пошло гладко и красиво. Но постоянное улучшение процесса дало свои результаты. Через пол года нам значительно удалось ускорить процесс разработку (burndown графики указывали ускорение в 2.1 раза), а также намного повысить качество выпускаемого продукта. Тестировщики признавались, что находить баги стало сложнее, а ситуации «тут починили — там сломали» исчезли вообще.
Полезности
Процессы
Kanban (development)
Kanban Applied to Software Development: from Agile to Lean
Lean Software Engineering
Инструменты
Обзор Kanban досок
