Методологии разработки ПО (Scrum, Kanban, RUP, DSDM, MSF, XP)

Методологии разработки — это применение той или иной модели на практике.

SCRUM

Scrum¹ — это методология управления проектами, которая построена на принципах тайм-менеджмета. Основной ее особенностью является вовлеченность в процесс всех участников, причем у каждого участника есть своя определенная роль.

Суть в том, что не только команда работает над решением задачи, но все те, кому интересно решение задачи, не просто поставили ее и расслабились, а постоянно «работают» с командой, и эта работа не означает только постоянный контроль.

Основные термины, которые используются в методологии

Владелец продукта (Product owner) — человек, который имеет непосредственный интерес в качественном конечном продукте, он понимает, как это продукт должен выглядеть/работать. Этот человек не работает в команде, он работает на стороне заказчика/клиента (это может быть как другая компания, так и другой отдел), но этот человек работает с командой. И это тот человек, который расставляет приоритеты для задач.

Scrum-мастер — это человек, которого можно назвать руководителем проекта, хотя это не совсем так. Главное, что это человек, «зараженный Scrum-бациллой» на столько, что несет ее как своей команде, так и заказчику, и соответственно следит за тем, чтобы все принципы Scrum соблюдались. Scrum-команда — это команда, которая принимает все принципы Scrum и готова с ними работать.

Спринт — отрезок времени, который берется для выполнения определенного (ограниченного) списка задач. Рекомендуется брать 2-4 недели (длительность определяется командой один раз).

Бэклог (backlog) — это список всех работ. Можно сказать, что это ежедневник общего пользования.

Различают 2 вида бэклогов: Product-бэклог и спринт-бэклог.
Product-бэклог — это полный список всех работ, при реализации которых мы получим конечный продукт.
Спринт-бэклог — это список работ, который определила команда и согласовала с Владельцем продукта, на ближайший отчетный период (спринт). Задания в спринт-бэклог берутся из product-бэклога.

Планирование спринта — это совещание, на котором присутствуют все (команда, Scrum-мастер, Владелец продукта). В течение этого совещания Владелец продукта определяет приоритеты заданий, которые он хотел бы увидеть выполнеными по истечении спринта. Команда оценивает по времени, сколько из желаемого они могут выполнить. В итоге получается список заданий, который не может меняться в течение спринта и к концу спринта должен быть полностью выполнен.

Пример работы PR-агентства. Как бы это могло выглядеть, если бы они работали по Scrum. Компания клиент «Икс» хочет провести через 2 месяца масштабное мероприятие для своих партнеров и журналистов. Услуги по организации такого мероприятия компания «Икс» заказала у агентства «Зет». Компанию «Икс» представляет PR-менеджер, который отвечает за организацию мероприятия со стороны клиента. В терминологии Scrum — этот человек называется Владелец продукта. Со стороны агентства за организацию мероприятия отвечает account-менеджер (Scrum-мастер), в подчинении которого находится команда (Scrum-команда). На совместном совещании (планировании спринта) компания и агентство решают, что они будут отчитываться-планировать каждые 2 недели (длина спринта). На первые 2 недели они запланировали список задач (спринт-бэклог), однако команда оценила, что не все из этого списка они успеют выполнить. Тогда PR-менеджер (он же Владелец продукта), говорит какие из этого списка задач более приоритетные на ближайшие 2 недели, после чего команда берется за выполнение заданий. Единственное что здесь должно быть учтено, что на момент планирования первого спринта должен быть спланирован весь список заданий на 2 месяца (product-бэклог), чтобы не получилось так, что к моменту проведения мероприятия что-то не выполнено.

Жизненный цикл спринта

1. Планирование спринта В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда. Планирование спринта состоит из двух последовательных митингов.

Планирование спринта, митинг первый Участники: команда, Product Owner, Scrum Master, пользователи, менеджемент Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog -функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта. Артефакт: Sprint Backlog

Планирование спринта, митинг второй Участники: Скрам Мастер, команда Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность. Артефакт: в Sprint Backlog появляются задачи Если в ходе спринта выясняется, что команда не может успеть сделать запланированное на спринт, то Скрам Мастер, Product Owner и команда встречаются и выясняют, как можно сократить scope работ и при этом достичь цели спринта.

2. Остановка спринта (Sprint Abnormal Termination) Остановка спринта производится в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить Product Owner, если необходимость в достижении цели спринта исчезла. После остановки спринта проводится митинг с командой, где обсуждаются причины остановки спринта. После этого начинается новый спринт: производится его планирование и стартуются работы.

3. Daily Scrum Meeting Этот митинг проходит каждое утро в начале дня. Он предназначен для того, чтобы все члены команды знали, кто и чем занимается в проекте. Длительность этого митинга строго ограничена и не должна превышать 15 минут. Цель митинга — поделиться информацией. Он не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы митинга.

Скрам митинг проводит Скрам Мастер. Он по кругу задает вопросы каждому члену команды:

• Что сделано вчера?
• Что будет сделано сегодня?
• С какими проблемами столкнулся?

Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items в формате что/кто/когда, например

• Обсудить проблему с отрисовкой контрола
• Петя и Вася
• Сразу после скрама

4. Диаграмма сгорания задач (Burndown chart)

Диаграмма, показывающая количество сделанной и оставшейся работы. Обновляется ежедневно с тем, чтобы в простой форме показать подвижки в работе над спринтом. График должен быть общедоступен.

Существуют разные виды диаграммы:

• диаграмма сгорания работ для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте.
• диаграмма сгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).

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

Kanban (Канбан)

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

Особенность Kanban² — задачи должны выполняться точно в срок, нагрузка между командой распределяется равномерно.

На практике это выглядит следующим образом. Каждая задача по проекту описывается в отдельной карточке и добавляется на доску — виртуальную или настоящую. Карточка и доска — неотъемлемые элементы Kanban.

Все задачи, которые необходимо сделать, собраны в специальной колонке, условно, она может называться “сделать”/ “to do”. Исполнитель выбирает задачу и перемещает в колонку “в процессе” / “in progress”. Когда задача сделана, она попадает в соответствующую колонку “готово” / “done”.

На практике колонок может быть гораздо больше, чем три. К примеру, колонки на доске могут выглядеть так: “обсуждается” (backlog), “согласовано” (ready), “кодируется” (coding), “тестируется” (testing), “подтверждается” (approval) и “сделано” (done).

Кейс “Тойота”. Методология Kanban родилась на производстве в компании Toyota. Мастера участков перечисляли выполняемые работы на бумаге и вывешивали их на видном месте — так и родилась доска канбан, один из элементов методологии. В основе производства Toyota — годовой план производства и сбыта авто, на базе которого составляются месячные и оперативные планы среднесуточного выпуска на каждом участке, основывающиеся на прогнозировании покупательского спроса. Методология базируется на принципе “точно в срок”, что, помимо четкого следования таймингу по каждой задаче, позволяет раскрывать дефекты производства вовремя. Например, ежедневные контроль запасов продукции и деталей выявляет неисправности или простои.

Канбан — это даже еще более «гибкая» методология, чем SCRUM и XP. Это значит, что она не подойдет всем командам и для всех проектов. И это также значит, что команда должна быть еще более готовой к гибкой работе, чем даже команды, использующие SCRUM и XP.

Разница между Канбан и SCRUM

• В Канбан нет таймбоксов ни на что (ни на задачи, ни на спринты)
• В Канбан задачи больше и их меньше
• В Канбан оценки сроков на задачу опциональные или вообще их нет
• В Канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи

Канбан разработка отличается от SCRUM в первую очередь ориентацией на задачи. Если в SCRUM основная ориентация команды — это успешное выполнение спринтов (надо признать, что это так), то в Канбан на первом месте задачи. Спринтов никаких нет, команда работает над задачей с самого начала и до завершения. Деплоймент задачи делается тогда, когда она готова. Презентация выполненной работы — тоже. Команда не должна оценивать время на выполнение задачи, ибо это имеет мало смысла и почти всегда ошибочно вначале. Если менеджер верит команде, то зачем иметь оценку времени? Задача менеджера — это создать приоритизированный пул задач, а задача команды — выполнить как можно больше задач из этого пула. Всё. Никакого контроля не нужно. Всё, что нужно от менеджера — это добавлять задачи в этот пул или менять им приоритет. Именно так он управляет проектом.

Экстремальное программирование (XP)

eXtreme Programming, экстремальное программирование, XP — гибкая методология разработки, которая появилась в конце 90-х годов прошлого столетия. Авторы взяли лучшие, на их взгляд, практики гибкой разработки и усилили их до максимума — отсюда и слово “экстремальный” в названии.

В отличие от канбана, скрама, которые можно применять в самых разных стартапах и бизнесах, да и в организации личных дел, XP применяется исключительно в разработке программных продуктов. В рамках экстремального программирования выделяются четыре процесса: кодирование, тестирование, дизайн, слушание. Если описать эту методологию несколькими словами, то ее характеризуют оперативность, высокое качество, командная работа.

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

Другая особенность экстремального программирования заключается в том, что сначала готовятся тесты, и только потом — код. При этом тесты пишут сами программисты. Тестирование позволяет исправить большинство ошибок на стадии создания кода.

Третья особенность — коллективное владение кодом: каждый программист в команде имеет доступ к коду продукта и может вносить в него изменения. В том случае, если изменения привели к некорректной работе системы, исправить все должен тот программист, который внес эти изменения.

Экстремальное программирование предполагает также работу в рамках небольших релизов — от одного дня до месяца. При этом чем короче релизы, тем лучше качество продукта.

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

Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:

• Короткий цикл обратной связи (Fine-scale feedback)
• Разработка через тестирование (Test-driven development)
• Игра в планирование (Planning game)
• Заказчик всегда рядом (Whole team, Onsite customer)
• Парное программирование (Pair programming)
• Непрерывный, а не пакетный процесс
• Непрерывная интеграция (Continuous integration)
• Рефакторинг (Design improvement, Refactoring)
• Частые небольшие релизы (Small releases)
• Понимание, разделяемое всеми
• Простота (Simple design)
• Метафора системы (System metaphor)
• Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
• Стандарт кодирования (Coding standard or Coding conventions)
• Социальная защищенность программиста (Programmer welfare):
• 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

DSDM (Dynamic Systems Development Model)

Методология, которая демонстрирует набор принципов, предопределенных типов ролей и техник.

Принципы направлены на главную цель - сдать готовый проект вовремя и уложиться в бюджет, с возможностью регулировать требования во время разработки. DSDM входит в семейство гибкой методологии разработки программного обеспечения, а также разработок не входящих в сферу информационных технологий.

RATIONAL UNIFIED PROCESS (RUP)

Это методология разработки программного обеспечения, созданная компанией Rational Software.

Основные принципы

• компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта;
• работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам;
• ранняя идентификация и непрерывное устранение возможных рисков;
• концентрация на выполнении требований заказчиков к исполняемой программе;
• ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки;
• постоянное обеспечение качества на всех этапах разработки проекта.

Разработка продукта при данном методе состоит из четырех фаз (начальная стадия, уточнение, построение, внедрение), каждая из которых включает в себя одну или несколько итераций. RUP огромная методология, которую трудно уложить в абзац текста, но методы, рекомендуемые RUP основаны на статистике коммерчески успешных проектов.

MICROSOFT SOLUTIONS FRAMEWORK

Методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.

Базовые концепции и принципы модели процессов MSF

• единое видение проекта — все заинтересованные лица и просто участники проекта должны чётко представлять конечный результат, всем должна быть понятна цель проекта;
• управление компромиссами — поиск компромиссов между ресурсами проекта, календарным графиком и реализуемыми возможностями;
• гибкость — готовность к изменяющимся проектным условиям;
• концентрация на бизнес-приоритетах — сосредоточенность на той отдаче и выгоде, которую ожидает получить потребитель решения;
• поощрение свободного общения внутри проекта;
• создание базовых версии — фиксация состояния любого проектного артефакта, в том числе программного кода, плана проекта, руководства пользователя, настройки серверов и последующее эффективное управление изменениями, аналитика проекта.

MSF предлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способен удовлетворить нужды организации или проектной группы любого размера. Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов.

Lean, Lean Software Development - бережливая разработка программного обеспечения

Гибкая методология, основанная на концепции бережливого производства. Среди принципов методологии — исключение потерь (к ним относится все, что не добавляет ценности для потребителя — излишняя функциональность, паузы в процессе разработки, нечеткие требования и пр.); акцент на обучении (предполагаются короткие циклы разработки, раннее тестирование), принятие решений на основе фактов, мотивация команды.

Виды методологий разработки ПО: • Каскадная или поэтапная разработка (в некоторых источниках её называют «водопадной моделью») — процесс создания программного обеспечения представляет собой поток, последовательно проходящий фазы анализа, проектирования, реализации, тестирования, интеграции и поддержки. Так обычно строится работа над крупными проектами с длительным сроком внедрения. • Итеративная или инкрементная (эволюционная) модель приращения продукта позволяет параллельно выполнять ряд задач с непрерывным анализом результатов и корректировкой предыдущих этапов работы. Это более «скоростная» разработка для большого штата квалифицированных программистов. • Спиральная методика характеризуется прохождением проектом повторяющегося цикла в каждой фазе развития: планирование — реализация — проверка — оценка (англ. plan-do-check-act cycle). Так обычно создаются проекты, с окончательно не сформированным видением результата, либо требующие ультрасрочного внедрения по этапам. • Гибкая методология Agile-разработки — т.н. быстрая разработка без ущерба качеству, когда во главу угла ставится работающий продукт, а не его документация. Наиболее современный неформализованный подход к созданию ПО, в процессе которого реагирование на изменения ценятся выше строгого следования плану. Для молодых стремительно развивающихся проектов, которые с каждой итерацией программного обеспечения по сути готовы к его релизу.