Гибкие методологии и подходы

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

• • приоритет взаимодействия людей над процессами и традиционными инструментами управления;
• • приоритет получения работающего продукта над исчерпывающей всеобъемлющей документацией;
• • приоритет сотрудничества с потребителями (заказчиком) над формальными вопросами контрактов;
• • приоритет быстрого реагирования на изменения над неотступным следованием плану.

Исходя из этих ценностей, у команд, использующих Agile-методологию, почти не встречается одинаковых практик документирования или координации, так как гибкая методология предполагает самоорганизацию, самостоятельное определение объема, содержания и ограничений каждого элемента управления разработкой. Со времени своего появления в 1990;х гг. Agile-практики получили распространение во множестве компаний, в то время как первоначально они позиционировались для управления ИТ-проектами.

В качестве одного из важнейших элементов Agile-нодхода к разработке выступают пользовательские истории (user stories). Это описанные одним или несколькими предложениями основные аспекты функциональности системы, необходимые для выполнения пользователем своей работы. В достаточно сжатом виде они должны отвечать на вопросы: «Кто?», «Что?» и «Почему?» и могут создаваться как менеджером проекта по результатам обследования как один из форматов фиксирования требований, так и разработчиками для выражения нефункциональных требований (например, к безопасности, производительности, качеству решения).

Пример

Отдельные требования, представленные в виде user stories.

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

Итоговая user story на «техническом» языке.

Как ответственному за проведение рассылок пользователю необходимо обеспечить следующую функциональность:

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

В то же время гибкая методология почти не ограничивает команду проекта: так, если необходим больший уровень детализации технического задания, спецификаций или другой документации, то можно его написать. Если необходимы дополнительные приемочные критерии — можно их составить, если нужны прототипы — можно их сформировать в виде макетов (мокапов, mockups), в виде блок-схем или в виде реальной модели прототипа. Уровень детализации и формализации всегда зависит от специфики системы и проектной команды, от их компетенций и опыта реализации подобных проектов.

В 2013 г. было проведено восьмое ежегодное исследование «State of Agile», которое выявило наиболее распространенные гибкие методологии управления проектами, используемые в сфере создания И С и ПО (рис. 6.1).

В 2013 г. методология Scrum оказалась самой популярной, на нее пришлось больше половины проектов. Остальные гибкие методологии используются в 11% случаев и менее. К ним относятся (ХР), Feature Driven Development (FDD), Kanban, Lean, Scrumban (комбинация Kanban и Scrum).

Рис. 6.1. Статистика популярности гибких методологий за 2013 г.¹:

• 1 — Scrum; 2 — Scrum/XP Hybrid; 3 — Custom Hybrid; 4 — Scrumban;
• 5 — Kanban; 6 — Lean; 7 — FDD; 8 — Other; 9 — XP; 10 — AgileUP;
• 11 - Agile Modelling; 12 — DSDM