Коротко о Scrum, Kanban, XP

Разработка программного обесечения требует своевременного принятия правильных решений. Но все принимаемые решения нужно синхронизировать. Один из резидентов Hacker News написал о том, как наблюдал за экспериментом, когда в одной крупной компании пяти сотням разработчиков разрешили принимать решения в “отрыве” от команды. Он пишет, что был хаос. Хотя команды начали работать быстрее, они двигались в никуда из-за задержек на этапе поддержки ПО.

Чтобы избегать таких ситуаций приходится использовать процессы гибкой разработки. Их внедрение позволяет компании повысить заинтересованность и мотивацию сотрудников, а также ускорить получение заказчиком продукта. В этой статье будут рассмотрены методологии Scrum, Kanban и экстремальное программирование.

[sendpulse-form id=”278″]

Scrum

Scrum является методологией “по умолчанию” и является синонимом Agile. В 2017 году компания VersionOne опубликовала статистику использования гибких методологий за 2016 год, согласно которой Scrum использует 58% компаний работающих по “гибким” методологиям.

Методология был создана в конце 80-х начала 90-х годов и в ее основе лежит использование фиксированных итераций – спринтов. Используя методологию Scrum, представитель заказчика плотно работает с командой разработки, составляя требования и расставляя их приоритеты (Product Backlog). В этом списке может быть все – функциональные и нефункциональные требования, баг-фиксы, все что необходимо для создания рабочего приложения. Элементы добавляемые в бэклог называются историями. Каждая задача оценивается определенным количеством очков, абстрактной метрикой для которой могут быть использованы различные шкалы (ряд Фибоначчи, степени двойки, породы собак).

На основании созданного и оцененного списка требований истории разбиваются на спринты. Длительность каждого спринта определяется до начала работы и может быть от 7 до 30 дней. В конце каждого спринта считается количество очков набранных командой. Это позволяет лучше планировать следующий спринт.

За время своего существования Scrum приобрел огромную популярность и используется командами разработчиков как в малых так и в крупных компаниях.

Одной из популярных проблем за которую многие не любят Scrum является митапы – 15-минутные обсуждения в начале и конце дня. Проблемой является то, что на практике митап не должен превышатьь 15 минут для любого количества участвующих людей, но всем ведь известна любовь представителей постсоветского пространства к бесполезным и бессмысленным часовым совещаниям. Еще одна проблема использования Scrum на постсоветском пространстве это неизменность истории во время выполнения спринта. В Scrum нельзя перестраивать корабль во время плавания. Для того чтобы внести изменение необходимо дождаться окончания спринта, только тогда новые требования к истории могут быть рассмотрены и приняты.

Kanban

Канбан пришел в мир IT с заводов компании Toyota и многие его принципы легли в основу методологии Scrum и других Agile-методологий. Канбан представляет процесс разработки как конвейер с запросами на реализацию функций, с которого сходит улучшенное программное обеспечение.

Поскольку в основу легла часть производственной системы завода по производству автомобилей, которая называется “точно вовремя” в Канбан исключает излишнее накопление задач. Если, например отдел тестирования проверяет 5 функций в неделю, а команда разработчиков и аналитиков выпускает 10, то “пропускная способность конвейера” ограничивается 5 функциями. Это необходимо сделать, чтобы у отдела тестирования не было накопления работы и они не начали “срезать углы” обеспечивая тем самым выпуск некачественного продукта.

В своей простейшей реализации Канбан это доска с расчерченными столбцами в которой размещаются карточки. Столбцы это этапы процесса разработка, а карточки – рабочие задачи. Цифры возле названия столбца означают сколько задач в может одновременно находиться в нем.

Extreme Programming

Экстремальное программирование привлекло внимание в конце 90-х годов. Концепция этой методологии строится на 12 основных приемах:

  1. Разработка через тестирование
  2. Игра в планирование
  3. Заказчик всегда рядом
  4. Парное программирование
  5. Непрерывная интеграция
  6. Рефакторинг
  7. Частые небольшие релизы
  8. Простота проектирования
  9. Метафора системы
  10. Коллективное владение кодом
  11. Стандарт оформления кода
  12. 40-часовая рабочая неделя

XP сильно напоминает Scrum в части взаимодействия заказчика с командой разработки, расставления приоритетов и короткими итерациями. Поэтому некоторые компании выбирают гибрид методологий XP и Scrum. Однако эта методология делает основной упор на тестировании. Согласно методологии код не может считаться правильно написан пока он не прошел все тесты, и зачастую сначала пишутся тесты, а потом уже сам код. Это является основным недостатком данной методологии. Согласно Scrum и Канбан есть отдельная категория людей отвечающих за тестирование, а в случае использования XP разработчик тоже должен уметь разбираться в тестах.

Заключение

Использование методологий Agile накладывает требования на опыт команды и способность ее членов взаимодействовать как между собой, так и с членами других команд. Каждая из методологий имеет свои сильные и слабые стороны, а иногда и области применения.