Одно из обязательных условий при разработке любого ПО — умение своевременно принять правильное решение. Но этот ответственный шаг требует последующей командной синхронизации. Что же нужно предпринять в таком случае? Ответ прост: задействовать в своей работе процессы гибкой разработки методологии типа Agile. Рассмотрим, в чем заключаются их особенности.
Чем хорош и плох фреймворк Scrum?
Многие специалисты считают Scrum синонимом Agile, потому что он используется многими «гибкими» компаниями и поддерживается большинством платформ SaaS. Особенности Scrum:
- процесс управления включает в себя sprints или «спринты» – фиксированные короткие итерации, выполняемые с наибольшей скоростью;
- Product Backlog, когда заказчик сам определяет приоритетность требований к разрабатываемому продукту, которые необходимы, чтобы реализовать рабочее приложение (благодаря установленным приоритетам, для разработчиков определяются конкретные реализационные функции);
- пользовательские истории добавляются в бэклог;
- любая спринт-задача имеет свою определенную оценку (для этого может использоваться шкала на выбор).
Механизм методологии Scrum заключается в том, что полученная командой разработчиков оценка за выполненный успешно спринт служит отправной точкой в планировке последующих этапов разработки.
Активные пользователи Scrum отмечают несколько отрицательных факторов:
- настрой разработчиков на набор большей оценки, что приводит к оптимизации их деятельности под быстрое завершение очередного спринта;
- затяжные митапы-обсуждения одновременно для всех специалистов команды (в том числе и удаленных);
- истории, как функциональный элемент, не должны изменяться на протяжении всего спринта.
Эти моменты не улучшают и не упрощают кодовую базу, не дают возможности перестроить сессию в процессе ее развития. Чтобы больше внимания уделялось практикам разработки, можно Scrum скомбинировать с ХР – экстремальным программированием.
Концепция Extreme Programming
В основе данной методологии лежат 12 приемов, что позволяет акцентировать внимание на модульных тестах. Это отличает ее от Scrum, хотя и здесь заказчик указывает приоритетность задач для разработчиков, которые решаются с помощью быстрых и коротких итераций.
«Минус» ХР все в той же ориентации на тестирование: нужна инфраструктура автоматизированных тестов + непрерывное развертывание программного обеспечения + работа сообща всех специалистов команды и пользователей.
Методология Kanban: возможности и недостатки
К этой технике, предназначенной для управления разработкой, прибегают как к альтернативе Scrum. Ее особенность в возможности:
- исключения излишнего накопления задач для QA-команд;
- перераспределения ресурсов (например, программисты после выполнения своего задания помогают с проведением тестов);
- повышения пропускной способности процесса разработки конвейерного потока с запросами на реализацию функций ПО.
При этом Kanban не подойдет, чтобы планировать долгосрочные задачи и для использования крупными командами (свыше 5 специалистов).
Андерсон пишет в своей книге «канбан. Новой путь в agile», что канбан работает и на долгосрочных проектах. Очень надеюсь, что он прав. На следующей неделе стартуем эксперимент . Да еще с командой в 14 человек 🙂