Существует еще одна гибкая методология, которая на данный момент менее распространена чем Scrum, но пи этом не менее эффективна. Имя этой методологии – Kanban. Основной идеей данной методологии является ограничение количества незавершенной работы в каждый момент времени. Также важным атрибутом этой методологии является приоритезированный бэклог, т.к. в каждый момент времени надо понимать какую задачу брать следующей.
Kanban не подразумевает обязательного наличная спринтов и всего того количества ролей которые есть в Scrum. И это делает методологию более простой для внедрения, т.к. не надо обучать людей играть роли, которые они до этого не играли. Также очень большим плюсом с точки зрения внедрения является отсутствие в Kanban предписания иметь кроссфункциональную команду не очень большого размера.
В силу того, что Kanban имеет гораздо меньше предписаний чем любая другая Agile методология, она по праву считается самой гибкой.
Если попробовать построить шкалу адаптивности популярных Agile методологий, то получится примерна такая картина как на рис. 7:
Рисунок 7 – Адаптивность Agile методологий
Когда речь заходит о внедрении Agile-методологий, то всегда встает извечная проблема выбора, а какую именно методологию внедрять. Давайте сравним Scrum и Kanban.[13]
Сходства:
Обе являются Agile методологиями
Обе ограничивают незавершенную работу
Обе полагаются на самоорганизующиеся команды разработки
Обе нацелены на частые поставки продуктов
Обе предполагают наличие приоритезированного бэклога
Отличия:
Scrum Kanban
Обязательное наличие итераций Наличие итераций не обязательно
Команда должна быть обязательно кросс-функциональной Кросс-функциональность команды не обязательна
Задачи обязательно должны биться на более мелкие Обязательных правил по величине задач нет
Обязательной метрикой являются Burn-down диаграммы Обязательных метрик нет.
Обязательно надо оценивать задачи для формирования бэклога на спринт Оценивать задачи не обязательно.
Добавление задач в текущую итерацию запрещено Можно добавлять задачи в любое время.
Есть обязательные роли (Product Owner/Scrum Master) Нет обязательных ролей.
Скрам-доску надо отчищать после каждого спринта Kanban доска постоянна на протяжении всего проекта.
Ежедневные митинги и ретроспективы обязательны Нет никакого регламента по проведению митингов
Когда речь идет о внедрении Agile методология, то наиболее правильным путем будет движение от простого к сложному. Т.е. начинать надо с Kanban (возможно сразу дополненным какими-то легко внедряемыми практиками из других методологий). А когда команда сформируется и начнет работать слаженно и думать об улучшение процесса разработки, чтобы более эффективно справляться с поставленными задачами, то можно внедрять другие практики.
Выводы
Таким образом, в отличии от других итеративных методологий, Agile делает упор на коммуникации, выводит на первый план команду разработки, а также задает структуру итерации.
Основной метрикой Agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, Agile-методы уменьшают объем письменной документации по сравнению с другими методами.
Методология базируется на следующих принципах, зафиксированных в Agile Manifest:
Люди и их взаимодействие важнее, чем процессы и инструменты; Работоспособное ПО важнее, чем обширная и детальная документация;Сотрудничество с заказчиком важнее, чем переговоры по условиям контракта;Реагировать на изменения важнее, чем следовать плану.
Agile-методология более других позволяют вносить изменения с гораздо меньшими усилиями и уровнем затрат.
Таким образом, Agile-разработка хорошо подходит как для проектов, требования к которым эволюционируют в процессе разработки, так и когда заказчику бывает трудно полностью сформулировать требования с самого начала.
