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

Agile — гибкий подход к работе. Откуда это взялось?

Многие слышали о «гибком» подходе к управлению проектами. Но все ли осведомлены об истории, лежащей в основе его принципов?

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

Проблему диагностировали как неправильный подход к самому ведению проекта — изменения нужно было начинать «с нуля», то есть уже на этапе планирования работ. До сих пор (то есть до памятной поездки в горы) разработка ПО велась так же, как, например, строительство дома или вывод на рынок нового йогурта. График работы составляли заранее, разделив проект на последовательные этапы — без одного невозможно было перейти к следующему; затраты также оценивались сразу, и был выделен конкретный бюджет. В связи с этим заказчику приходилось сдать все требования, учитывая, что дополнительные изменения внесут хаос и их будет сложно реализовать. Такой подход (называемый каскадным, или «водопадом») в случае проектов с большим количеством трудно предсказуемых переменных просто не работал.

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

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

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

Новое против старого. Agile vs Waterfall

Водопад (каскадный подход)

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

Agile (гибкий подход)

• Нет всеобъемлющего, закрытого плана действий.
• Разбивка работы на короткие циклы (так называемые спринты), которые напрямую не зависят друг от друга.
• Большая гибкость при внесении изменений, бюджетный контроль во время проекта.
• Действия по списку приоритетов, относящиеся к одному циклу (спринт). Список приоритетов растет вместе с проектом.
• Деятельность ведется таким образом, чтобы достичь конкретной цели, но без четких указаний, все составляется в процессе работы.
• Текущая разработка — внедрение — тестирование — улучшение последующих частей программного обеспечения.

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

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

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

12 принципов гибкой методологии

Создатели идеи Agile выделили 12 основных принципов, определяющих положения этого метода работы. Ниже представлены наиболее важные из них вместе с кратким описанием.

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

2. Будьте открытыми для изменений, даже на поздней стадии проекта. Технологическая отрасль меняется динамично, и изменения необходимы, чтобы соответствовать требованиям рынка. Второй момент заключается в том, что клиент часто может прояснить свои ожидания только после того, как увидит первые результаты. Гибкая методология была создана в противовес жестким рамкам «водопадного» подхода.

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

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

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

6. Лучший способ передать информацию — лицом к лицу. Электронная почта и обмен мгновенными сообщениями очень удобны, но личный контакт оставляет наилучшее впечатление и является самым плодотворным.

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

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

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

10. Простота — это искусство сводить работу к минимуму. Принцип заключается в том, чтобы не усложнять решения и не смешивать слишком много там, где это не нужно. Заданная функция должна работать — чем проще ее реализовать, тем лучше (то есть быстрее и эффективнее).

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

12. Благодаря регулярной работе команда постоянно развивается, становится более эффективной и адаптируется к меняющимся требованиям, делает выводы и, соответственно, совершенствует свой подход!

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

Jira Software, или как запускать гибкие проекты

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

Из-за множества подходов, существующих в Agile, далее мы сосредоточимся на SCRUM, совместимом с SCRUM Guide (https://www.scrumguides.org/). Мы также будем ссылаться на SAF (Scaled Agile Framework — https://www.scaledagileframework.com/), который был создан для решения некоторых проблем SCRUM (в основном проблемы масштабируемости для крупных организаций).

Наиболее важные функции Jira Software в контексте гибких методологий

Спринты

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

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

Задачи

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

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

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

Каждая задача может иметь определенное количество времени для ее выполнения (в форме времени или Story Points), и пользователи могут записывать, сколько времени они тратят на работу.

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

В этом случае метки OPEN, DONE и блоки между ними указывают на статус задания. Стрелки представляют собой возможные переходы от одного статуса к другому. Рабочие процессы варьируются от очень простых до очень сложных — с условиями, триггерами, валидаторами и функциями публикации. Это позволяет не только адаптировать каждый из потоков к индивидуальным потребностям, но и автоматизировать большую часть повторяющихся действий. Таким образом устраняются обязанности по управлению долгими задачами, от которых не слишком большой «сбыт».

Таблицы задач

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

Просмотр задач

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

Бэклог

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

База знаний и документация

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

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

Отчеты и поиск

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

• Поиск задач. В больших проектах количество созданных задач так велико, что один человек не может отслеживать их все и теряет контроль над происходящим. Atlassianа решила эту проблему с помощью расширенной системы поиска, позволяющей фильтровать задачи по каждому доступному полю, связанным задачам, проектам, в которых они расположены, и т. д. Поиск может выполняться как с упрощенным интерфейсом, так и в расширенной поисковой системе с использованием запросов, написанных на языке JQL.
• Отчеты. Графическое представление выбранных показателей обеспечивается отчетами, посвященными гибким методологиям, таким как Velocity chart, Sprint chart, Release Burndown или Burndown chart.

Дополнительные возможности

В дополнение к стандартным функциям Jira, предназначенным для гибких методологий, среда Atlassian предлагает возможность дальнейшей адаптации Jira к потребностям организации, как в контексте Agile, так и в более широком смысле разработки продуктов. Это делается благодаря возможности установки других систем, интегрируемых с Jira, а также дополнений к самой Jira из Atlassian Marketplace. Некоторые из наиболее интересных вариантов описаны ниже.

Bitbucket

Инструмент на основе Git, т. е. репозиторий кода, который интегрируется с Jira. Облегчает совместную работу над кодом, более эффективную сборку, тестирование и развертывание (выпуск).

BigPicture

Надстройка, развивающая функциональные возможности Jira управлением портфелем проектов, управлением проектами в каскадных методологиях, а также более продвинутым планированием для гибких методологий. BigPicture добавляет в Jira модули, которые позволяют планировать работу в соответствии с SAF. В двух словах — с точки зрения планирования — это означает, что мы можем планировать не только спринты, но и инкременты программы (PI — Program Increment), которые могут состоять из нескольких спринтов с более низким уровнем детализации. Запланированные задачи могут быть назначены данной команде в зависимости от доступности ресурсов в данном спринте или PI. Также можно планировать и назначать задачи на основе набора навыков, необходимых для их выполнения.

Гибкость (не) всегда работает?

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

Так что же, Agile лучше других способов ведения проектов? Не всегда и не для всех.

Agile-команды часто недовольны формой своей работы, поэтому было бы неправильно писать похвалы, зная, что у методологии есть недостатки. Ниже представлены самые важные преимущества и проблемы, характерные для Agile — подчеркиваем, что они связаны с работой фреймворка SCRUM (хотя Agile принимает множество форм, включая гибридные подходы).

Преимущества гибкой методологии

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

• Акцент на общении. Элемент, уже упомянутый в предыдущем пункте, но настолько важный, что его стоит выделить и развить. Гибкие методологии сосредоточены на «коммуникации, а не на документации». Это не означает отказ от документирования продукта, но упор делается на понимание потребностей, требований и подходов к их реализации (а не бездумный переход от точки к точке). Так проблемы выявляются прежде, чем их станет трудно исправить. А частота спринтов, после которых решение представляется и обсуждается, позволяет команде быстрее получать обратную связь, и риск возникновения критических проблем снижается.

• Непрерывное улучшение. SCRUM имеет встроенные механизмы для выхода из завершенных спринтов и внесения изменений с целью повышения эффективности работы (ретроспектива). Учитывая, что во многих каскадных подходах документы lessons learned («усвоенные уроки») создаются только в конце проекта (если вообще делаются), а позже их «откладывают на полку» вместо использования в других проектах, это значительно повышает эффективность работы.

• Гибкость (собственно). Планирование в SCRUM осуществляется от спринта к спринту. Конечно, у владельца продукта есть видение развития продукта в долгосрочной перспективе, но решение о том, какие задачи выполнять дальше, принимается в ходе последующих спринтов на основе предпринятых действий и сделанных выводов. А значит, на каждом спринте можно менять «направление» развития. Сравнивая его с каскадными методологиями, где многие изменения требуют перепланирования дальнейшей работы (а часто и серии согласований), показательно, что в SCRUM реакция на изменения происходит быстрее.

• Участие. В команде SCRUM нет руководителя, ответственного за предоставляемые функции — ответственность несет вся команда. Ее участники вовлекаются более активно, поскольку они являются не только исполнителями воли «тех, кто над ними», но и людьми, имеющими реальное влияние на решения и их реализацию (вместе с ответственностью за последствия).

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

Недостатки гибкой методологии

Неспособность адаптироваться к некоторым типам проектов. Сторонники Agile могут не согласиться, но SCRUM не всегда хороший выбор. Он может оказаться непригодным в таких случаях:

• Проекты с четко определенными требованиями и сроками завершения. Например, проекты, связанные с выполнением требований законодательства — и объем, и сроки строго определены регулирующим органом. SCRUM здесь не работает, ведь теряется одно из больших преимуществ — гибкость и возможность менять «направление» разработки продукта. Второй момент: имея объем и дату завершения, нам нужно определить, какие ресурсы требуются для завершения проекта. Это требует планирования с самого начала всей работы (по крайней мере, на высоком уровне), потому что планирование от спринта к спринту не гарантирует, что мы завершим проект в соответствии с требованиями. Конечно, вы можете сначала провести весь анализ, на его основе создать команды и определить количество спринтов, но это не чистый SCRUM.

• Разработка продукта, который во многом зависит от сторонних продуктов или частей организации. Командная работа, когда приходится ждать релиза для выполнения множества задач (например, раз в 3 месяца) в другом приложении, начинает напоминать работу по каскадной методологии. В таких ситуациях SCRUM теряет многие из своих преимуществ, и это часто разочаровывает членов команды.

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

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

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