Термин “Agile” используется для обозначения серии подходов, объединенных основными принципами данной методологии и ориентированных на использование итеративной или цикличной разработки. Этот термин официально появился с подписанием Agile Manifesto в 2001 году (рисунок 1). Основной целью манифеста была формулировка общих принципов и терминологии, а также распространение новой концепции на более широкое использование.

Рис. 1 Agile Manifesto 2001г.

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

Итеративный подход подразумевает последовательность циклических итераций из четырех основных фаз: сбор требований, планирование работы на текущую итерацию, разработка функционала и его тестирование (рисунок 2).

Рис. 2 Фрагмент итерации итеративной модели жизненного цикла IT-проекта

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

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

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

Подходы гибкой методологии разработки

В настоящее время существует множество подходов гибкой методологии разработки, но наиболее популярными являются «экстремальное программирование» (XP), «скрам» (Scrum), «шесть сигм» (Six sigma), «бережливая разработка» (Lean), и «канбан» (Kanban). Несмотря на то, что все они объединены общими принципами гибкой методологии, каждая из них является уникальной в своем роде и имеет специфическую среду применения и отличительные особенности. При правильном применении определенный подход способен привести к максимальной эффективности компании за счет оптимального распределения доступных ресурсов и организации рабочего времени каждого сотрудника.

Scrum

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

Основная цель, которую преследует Скрам, - это способность реагировать на изменения как можно быстрее с минимальными потерями времени и денежных средств, что достигается путем контроля и предсказания различных рисков, которые могут появиться на каждом этапе процесса разработки. Следуя принципам Agile, Скрам разбивает весь проект на небольшие независимые части, которые сразу могут использоваться заказчиком для реализации, так называемый задел продукта (product backlog). Затем, составляется последовательность разработки и внедрения частей в том порядке, который важен для заказчика в данный момент времени. Каждая такая часть выполняется в спринте, так называются итерации в подходе Скрам, длящиеся от 2 до 4 недель, и представляется как рабочий инкремент разрабатываемого продукта (рисунок 3).

Рис. 3. Схема процесса Скрам

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

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

В производственном процессе Скрам есть определенные роли (рисунок 4), основными из них являются Скрам-мастер, команда разработки и владелец продукта.

Рис. 4. Роли Скрам

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

· Команда разработки состоит из квалифицированных специалистов разных направлений разработки: тестирование, архитектура, аналитика и дизайн кода. Оптимальный размер команды должен составлять от 3 до 9 человек, чтобы быть достаточно большой для выполнения значительного объема работы в течение спринта и в то же время оставаться гибкой во взаимодействии внутри команды. Основной задачей команды разработки является выполнение необходимых для спринта задач.

· Владелец продукта является представителем Заказчика в проекте, а также всех заинтересованных в результате продукта сторон (будущих или существующих клиентов). Он считается ответственным за беклог продукта и приоритизацию задач внутри него.

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

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

· Планирование спринта происходит после распределения приоритетов задач владельцем продукта и заключается в принятии совместного решения о дальнейшем процессе разработки на грядущий спринт. Производятся необходимые оценки данного этапа и выбираются инструменты.

· Ежедневное совещание является неотъемлемой частью гибкой методологии. Члены команды тратят в среднем по 15 минут в день на то, чтобы обсудить статус задач, состояние проекта и делятся необходимой информацией. В это время также происходит принятие решений и обсуждение актуальных проблем, все вопросы и конфликты решает Скрам-мастер. Главная цель таких собраний - поддержание членов команды в курсе состояния проекта и своевременное решение возникших трудностей и проблем.

· Для наглядной демонстрации процесса работы над спринтом используется Scrum-board - доска (рисунок 5), она может быть как физической так и цифровой, на которой отображаются задачи спринта, разделенные по состояниям готовности («пользовательские истории», «планирование», «разработка», «тестирование», «релиз»). Scrum-master зачитывает приоритетные задачи и обсуждает их процесс выполнения.

Рис. 5. Scrum board

· Обзор итогов Спринта проводится в конце каждого спринта, где команда представляет результат работы владельцу продукта. Успешным завершением спринта считается соответствие реализованного с ожиданиями и целями, поставленными в планировании спринта.

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

Преимущества:

· Высокий уровень взаимодействия членов команды

· Наличие Скрам-мастера

· Ориентация на требования заказчика

· Возможность быстрого исправления ошибок

· Позволяет получить потенциально рабочую версию продукта в конце каждого спринта

· Инкрементальный подход

· Увеличение продуктивности

Недостатки:

· Требовательность к навыкам членов команды

· Ограничение к числу участников

· Необходимые коммуникативные навыки и ответственность со стороны членов команды

· Большое количество проводимых мероприятий

· Спринты должны быть тщательно определены

Применение и внедрение подхода Скрам происходит наиболее успешно в небольших компаниях с квалифицированной и многопрофильной командой разработчиков, тесно работающих с владельцем продукта и нацеленных на быстрый и качественный результат. Скрам широко используется зарубежными компаниями, такими как Google, SAP, PayPal и Yahoo! для управления проектами.

Kanban

Как и описанный выше Скрам, Канбан является одним из подходов гибкой методологии разработки. “Kanban” является японским термином, и обозначает «рекламный щит» или «вывеска». Его использовали в компании Toyota на производстве, когда перечисляли выполняемые работы на листках бумаги и вывешивали их в специально отведенном месте рядом с другими такими же листками. Позже в 1959 году, система Канбан была сформирована и в 1962 году реализована в производственной системе Тойоты, вследствие чего, все производство было переведено на этот принцип.

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

Канбан основан на трех основных принципах:

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

· Минимизация процесса производства. Данный принцип помогает сбалансировать подход, основанный на потоках, чтобы команды не начинали и не делали слишком много работы одновременно.

· Оптимизация жизненного цикла разработки. Возможность вносить своевременные изменения в процесс разработки является неотъемлемой частью Канбан и одним из важных компонентов гибкой методологии в целом.

Канбан помогает улучшить рабочий процесс. С визуальным представлением процесса разработки, скорость перехода от одной задачи к другой уменьшается. Это достигается путем эффективного использования Канбан-доски (рисунок 6), на которой каждая задача отображена в виде отдельной карточки, которая перемещается по столбцам, указывающим, в каком состоянии рабочего процесса находится данная задача («Запланировано», «В процессе выполнения», «Сделано»). Карточка перемещается по столбцам и на каждом этапе процент завершения задачи становится выше. Сама доска со столбцами может быть как физической, так и электронной.

Рис. 6. Kanban board

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

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

Эффективность внедрение подхода Канбан наиболее высока для команд поддержки продукта, такие как:

o группы поддержки ПО, где важна скорость реагирования на изменения

o группы тестирования, работающие отдельно от групп разработки

o службы поддержки

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

Преимущества:

а Высокий уровень взаимодействия членов команды

а Отсутствие ролей

а Нет четких дедлайнов

а Быстрая доставка продукта

а Высокий уровень визуализации

а Непрерывный поток задач

а Изменения допустимы в любое время

а Сокращение потерь

а Постоянное увеличение эффективности и продуктивности

Недостатки:

а Ограничение к числу участников и диапазону их деятельности

а Недостаток дисциплины

а Требуется высокая оптимизация работы во избежание простоев в работе

а Не подходит для объемных проектов, требующих поэтапного планирования

а Участники команды должны быть самостоятельными и самоорганизованными

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

Scrumban

Scrumban = Scrum + Kanban

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

Гибрид Скрам и Канбан дает команде гибкость в адаптации и изменении потребностей владельца продукта и заинтересованных сторон, без риска перегруженности методологией. Скрамбан объединяет гибкость Скрам и визуализацию Канбан, Что делает подход очень универсальным к управлению рабочим процессом.

Его также можно использовать, чтобы помочь команде осуществить плавный переход от Скрам к Канбан. Для многих групп разработчиков программного обеспечения немедленный переход к Канбан был бы слишком резким. Таким образом, Скрамбан предлагает командам удобный способ научиться практиковать постоянное совершенствование в Канбан, не отказываясь при этом от привычной структуры Скрам.

Можно выделить основные характеристики гибридного подхода:

· Командная работа организована в небольших итерациях и контролируется с помощью визуальной доски, аналогичной доскам Скрам и Канбан

· Длина итерации измеряется количеством поставленных задач и командной скорости выполнения.

· Идеальная длина итерации зависит от рабочего процесса каждой команды и не должна превышать двух недель

· Применение минимизации процесса производства для беклога

· Ограничение на количество задач в любой этап разработки

· Определена роль команды, остальные роли добавляются в случае необходимости

· Кратковременные сроки выполнения за счет своевременного анализа и планирования

· Проводятся только ежедневные собрания, на которых происходит планирование, обзор и ретроспектива, если это необходимо

· Команда работает с как можно меньшим количеством задач одновременно

· Задачи, запланированные для следующей итерации, добавляются в раздел «To Do»

· Приоритет задачам задается во время проведения планирования. Задачи добавляются на доску с пометкой приоритета

Так как в основе данного подхода лежит требование Канбан к визуализации и прозрачности процесса разработки, доска является неотъемлемым рабочим элементом. Доска Скрамбан (рисунок 7) объединяет поточность доски Канбан и разбиение на стадии и приоритизацию задач Скрам. В первую очередь выполняются задачи из столбца приоритетов. Новые задачи появляются на доске в столбце «Сделать» и не назначаются определенному члену команды. Так, члены команды выбирают себе задачи для выполнения самостоятельно.

Рис. 7. Scrumban board

Преимущества:

а Более гибкое формирование беклога по сравнению с классическим Скрам

а Срок завершения спринта может быть уменьшен или увеличен в зависимости от нужд команды

а Возможность добавления задач в процессе выполнения Спринта

а Прозрачность организационных процессов

а Использование доски для визуализации

а Совещания происходят по необходимости

а Минимизация потерь и простоев

Недостатки:

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

а Требуются опытные и самоорганизованные участники команды

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

Экстремальное программирование (XP, eXtreme Programming) - это гибкий подход разработки, который в значительной степени фокусируется на обеспечении качества поставляемого программного обеспечения и оперативность реагирования на изменяющиеся требования клиентов. Экстремальное программирование было разработано Кентом Бек нацеленным на удовлетворения специфических потребностей разработки программного обеспечения небольшими командами.

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

XP - это подход, который состоит из ценностей и практик

Экстремальное программирование базируется на пяти ценностях:

· Простота. Простые решения дешевле и быстрее реализуются, чем сложные. XP всегда пытается найти простейшие решения

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

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

· Смелость. Некоторые методики экстремального программирования требуют храбрости использовать непривычные методики подхода и не бояться: сосредоточиться только на том, что требуется, общаться и принимать критику, реорганизовывать код, честно говорить о прогрессе и оценках, приспосабливаться к постоянным изменениям.

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

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

Рис. 8. Практики экстремального программирования

Всего можно выделить 13 практик экстремального программирования (рисунок 8):

1. Вся команда.

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

2. Игра в планирование

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

3. Частые релизы версий

В экстремальном программировании происходит частый выпуск версий с небольшим функционалом. Объясняется это легкостью в тестировании небольших частей, сохранении устойчивости системы в целом и своевременном выявлении проблем нового функционала.

4. Пользовательские тесты

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

5. Коллективное владение кодом

В XP разработанный код не закреплен за конкретным участником команды и может быть исправлен и дополнен любым разработчиком проекта.

6. Непрерывная интеграция кода

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

7. Стандарты кодирования

Необходимо соблюдать стандарты написания кода для его легкой читаемости другими участниками команды.

8. Метафора системы

Метафора системы - так называемая архитектура, представление о взаимосвязях компонентов системы между собой. Она дает команде понимание о принципе работе разрабатываемой системы, её актуальном функционале, и какой она должна быть.

9. Устойчивый темп

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

10. Разработка, основанная на тестировании

В XP тесты пишутся программистами до написания основного кода, который требуется тестировать. Это обеспечивает полное тестовое покрытие. Успешным написанием кода считается срабатывание всех написанных модульных тестов.

11. Парное программирование

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

12. Простой дизайн

Система должна быть спроектирована максимально просто в любой момент и содержать только то, что нужно именно сейчас. Простой код легче оптимизировать и переписать.

13. Рефакторинг

Код постоянно пересматривается и переписывается с целью его упрощения и оптимизации. Улучшается сам код без изменения его функциональности.

Преимущества:

а Соответствие продукта требованиям заказчика

а Своевременное внесение изменений в систему

а Всегда стабильно работающий код

а Легкость в поддержании системы за счет простоты и стандартизации кода

а Быстрые темпы разработки

а Высокое качество написанного кода

а Снижение затрат на разработку за счет отсутствия избыточной документации и многочисленных мероприятий

Недостатки:

а Минимум документации

а Не подходит для крупных проектов из-за недостатка структуры и документации

а Успех проекта зависит от степени участия в нем владельца продукта

а Подходит только для опытных и сильных разработчиков

а Трудно спланировать бюджет и количество затраченного времени в начале разработки

Использование и внедрение подхода экстремального программирования наиболее эффективно для таких проектов, в которых требования не являются четкими или вовсе недоступны, которые сразу требуют минимальную рабочую версию продукта.

Популярность методов, практик и инструментов гибкой разработки

Согласно двенадцатому ежегодному государственному исследованию гибкой методологии разработки и управления проектами интернет-ресурса Version One за 2017 год, подход Скрам, его модификации и комбинации с другими подходами гибкой методологии являются самыми используемыми в мире и применяются гораздо чаще, чем остальные подходы и практики гибкой разработки (рисунок 9).

Рис. 9. Популярность подходов Agile методологии

По данным исследования, всего 1% agile компаний используют подход экстремального программирования в классическом виде. Еще 6% команд работают по гибридной методологии XP +Scrum. Несмотря на то, что использование XP как независимой методологии составляет небольшой процент во всей индустрии разработки ПО, техники, связанные с этим подходом, тем не менее, являются популярными и имеют широкое применение на практике (рисунок 10).

Рис. 10. Использование инженерных практик в 2017г.

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

Снова обращаясь к исследованиям VersionOne, можно выявить, какие инструменты являются наиболее востребованными среди компаний, использующих гибкие методологии разработки (рисунок 11). Несмотря на небольшую популярность подхода Канбан (5% - рисунок 9), Канбан доски широко распространены среди команд разработки, и согласно результатам исследования, 74% команд выбирают этот инструмент для отслеживания задач рабочего процесса и еще 7% планируют его использовать в будущем.

Рис. 11. Использование инструментов

Разработка модификации гибкого подхода