В связи с повышенным интересом в мире к гибким методологиям разработки программного обеспечения, мы решили опробовать их на нашем рабочем процессе. В качестве внедряемых методологий были приняты Scrum и Kanban. Что из себя представляют гибкие методологии мы описывали в предыдущей статье — “Гибкие методологии разработки. Agile”.
Коротко о Scrum
Scrum — это методология управления проектом, основные особенности которой:
- над проектами работают небольшие кроссфункциональные команды, которые в идеале являются самоорганизующимися;
- работа разбивается на маленькие компоненты, которые отсортированы по приоритетам и оценены по времени;
- время разработки делится на итерации фиксированной длины, которые называют спринтами;
- в начале каждого спринта определяют минимальный функционал продукта, который будет выпущен в конце этой итерации;
- проводятся ежедневные короткие митинги для всей команды;
- постоянно анализируется и оптимизируется процесс разработки на ретроспективах.
Что такое Kanban
Kanban — это система организации производства, которая пришла к нам с фирмы “Тойота”, и характеризуется тремя принципами:
- визуализация процесса работы — работу необходимо выписать на карточки и прикрепить их на стене, подписав столбцы, чтобы видеть этапы работы;
- ограничение количества незавершенной работы (НЗР) — необходимо определить максимальное кол-во работы на каждом этапе;
- измерение времени выполнения задачи.
Процесс внедрения
1. Обучение и мотивация команды
Первым шагом стала обучающая лекция для всех наших сотрудников, на которой было рассказано о гибких методологиях, их принципах и преимуществах, которые они могут дать в нашей работе. Целью лекции было не только обучение, а и попытка мотивировать сотрудников помогать во внедрении новых методологий. Команда приняла предложение с интересом, и мы решили попробовать Scrum и Kanban в работе.
Результат: поддержка и помощь во внедрении гибких методологий со стороны команды.
2. Внедрение ежедневных митингов
Вторым шагом стало внедрение в наш рабочий процесс ежедневных митингов. Их особенность в том, что они довольно короткие (10-15 мин) по сравнению с совещаниями и каждый член команды ведет общение с командой, а не с менеджером. На митинге каждый отвечает на три вопроса:
- Что было сделано вчера?
- Что будет сделано сегодня?
- Что мешает реализации запланированных на сегодня задач?
Главная цель этих вопросов вовсе не сравнивать кто больше сделал, а кто меньше. Цель в том, чтобы распланировать работу на текущий день, скоординировать действия каждого члена команды с общими задачами, выявить все проблемы которые мешают дальнейшей разработке и устранить их в ближайшие сроки.
Митинги мы проводим в начале рабочего дня, закрыв ноутбуки и стоя — это позволяет задать определенную динамику и информативность собранию.
Результат: менеджер в курсе всех прошедших событий и планов на ближайшее время, повысилась коммуникация внутри команды, митинги задают отличный рабочий ритм на весь день.
3. Централизованное хранение задач
Scrum подразумевает существование Product backlog — список того, что должно быть реализовано. Для хранения этого списка мы используем Redmine — веб-приложение для управление проектами. Существующие задачи мы разбили на более мелкие подзадачи, которым расставили приоритеты, назначили исполнителей и оценили примерное время разработки.
Результат: Снизили риск, что задача “потеряется”, наиболее важные задачи выполняются в первую очередь, т.к. находятся выше всех в общей таблице. В любое время есть доступ к описанию задачи и текущего статуса по ней. Так же стало легко вести учет затраченного времени на задачи и анализировать затраченное время за период.
4. Создание Kanban доски
Последним этапом стало создание Kanban доски, при помощи которой мы визуализировали рабочий процесс и движение всех задач. Kanban доска представляет из себя пробковую доску объявлений, на которой нанесена разметка в виде столбцов. Каждый столбец — это стадия, которую проходит любая задача:
- планирование;
- проектирование;
- разработка;
- тестирование;
- релиз.
На отдельных картонках (стикерах) пишется суть задачи, ее номер на redmine и приоритет. Эти картонки крепятся на доску и перемещаются между этапами своего существования.
Ограничение незавершенной работы.
Под каждым заголовком столбца написана цифра, которая указывает, сколько карточек с задачами может находится одновременно в разработке на этой стадии. Нельзя добавить в разработку 4-ю задачу, при ограничении в 3 задачи. В таком случае необходимо устранить проблемы которые мешают завершить этап разработки для этих задач.
Результат: Визуализация процесса помогла отслеживать наглядно движение задач и выявлять узкие места в работе команды на разных этапах. Например, если возникают проблемы с тестовым сервером, то количество задач в разделе тестирования достигает ограничения НЗР. В этом случае разработчики не могут передавать новые задачи тестерам, и все направляют усилия чтобы исправить возникшую проблему, тем самым избегаются “пробки” в рабочем процессе.
Вывод
Благодаря поддержке со стороны наших клиентов, мы решили внедрить еще некоторые идеи Scrum и Kanban в текущих проектах. Со временем опубликуем результаты применения гибких методологий в нашей работе.
Не забывайте, что Scrum и Agile всего лишь инструмент, каждый из нас решает где и как им пользоваться, и не стоит становиться их заложником. В своей работе применяйте те составляющие этих инструментов, которые смогут решить ваши проблемы и повысить эффективность работы.