Проекты гибкой разработки (agile) – К.Вигерс и Дж.Битти | Бизнес-Анализ в России

Что почитать

Отечественный и зарубежный рынок насыщен книгами по гибкой разработке, поэтому интересующимся не составит труда найти себе подходящее чтиво. Вот мой список ТОП-3:

  1. «Постигая Agile. Ценности, принципы, методологии», Эндрю Стеллман, Дженнифер Грин. Издательство O’Reilly редко разочаровывает, эта книга – определённо не исключение. В ней вы узнаете и про общую концепцию, и подробнее про Scum, Kanban, XP и Lean.
  2. «Гибкая разработка программ на Java и C . Принципы, паттерны и методики», Роберт С. Мартин. Agile в прикладном применении.
  3. «Пользовательские истории. Гибкая разработка программного обеспечения», Майк Кон. Истории правильного и неправильного применения гибкой разработки ПО, советы по внедрению конкретных методологий.

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

Переход к гибкой разработке: что дальше?

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

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

Поощряйте ориентацию членов команды на проект, а не на свои индивидуальные роли или должности (Gorman и Gottesdiener, 2022).• Прочитайте одну из книг о роли владельца продукта в проекте гибкой разработки, чтобы получить хорошее представление о пользовательских историях, приемочных тестах, приоритизации резерва, а также узнать, почему работа бизнес-аналитика продолжается вплоть до конца проекта или выпуска.

Гибкие материалы:  Гибкость организационных структур - Матричная структура

Можно порекомендовать книгу «Agile Product Management with Scrum» («Гибкое управление продуктом в рамках скрама») (Pichler, 2022).• Выбрать из предлагаемых приемов те, что лучше всего подойдут вашей организации. Вспомните, какие приемы разработки уже хорошо себя зарекомендовали в вашей организации, и продолжайте их применять.

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

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

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

4 ключевые идеи Agile сфокусированы на гибкости и адаптивности этого подхода:

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

Эти идеи раскрываются в 12 принципах AgileManifesto[1]:

  1. работающий конкурентоспособный продукт, удовлетворяющий заказчика — лучший показатель прогресса и измеритель эффективности;
  2. оперативная и бесперебойная поставка продукта, удовлетворяющего заказчика;
  3. адаптивность продукта к новым требованиям, которые могут повысить его ценность и конкурентоспособность (возможность внесения изменений на любом этапе разработки);
  4. простота и прозрачность технических решений, документации, процессов и инструментов, чтобы не создавать лишней работы;
  5. частая поставка функционирующего продукта (раз в месяц/неделю или ещё чаще);
  6. постоянный темп работы всех участников проекта на протяжении всего его срока;
  7. минимизация организационных и информационных барьеров, лучший путь передачи информации — это личный разговор лицом к лицу;
  8. тесное и ежедневное общение исполнителей с заказчиком в течении всего проекта;
  9. мотивация участников проекта и обеспечение их всеми необходимыми условиями работы, поддержкой и доверием;
  10. самоорганизация и самоконтроль команды проекта;
  11. непрерывное улучшение профессиональных компетенций команды проекта;
  12. систематический анализ и постоянный поиск возможностей оптимизации командной и индивидуальной работы.
принципы Agile
Главные принципы Agile

Кратко о том, что входит в agile сегодня

К гибким «методам управления» относятся, в частности, фреймворк Scrum и метод Kanban. Согласно исследованию Agile в России, Канбан сейчас занимает прочное второе место по популярности после Скрама (если не считать самопальных гибких подходов, которые любят изобретать в российских компаниях).

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

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

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

Канбан отличается от Скрама по многим параметрам, в частности:

  • имеет более широкую область применения (не только новые продукты, но и поддержка, операционка);
  • в отличие от Scrum, внедряется постепенно (без одномоментного изменения текущих процессов) и более просто (без изменений оргструктуры, например);
  • нацелен не только на ускорение, но и на равномерность процессов;
  • имеет сильно отличающиеся от Скрама метрики, не требующие оценки трудоемкости задач (например, время прохождения задачи в системе);
  • отличается отсутствием фокуса на самоорганизацию команды и отсутствием прямой связи Kanban-практик с Agile-ценностями (у Канбана есть свои ценности, многие из которых вполне согласуются с ценностями Agile, например: клиентоориентированность, сотрудничество, прозрачность).

Подробнее об этом см. в статье про отличия Kanban и Scrum.

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

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

Речь про проблемы крупных организаций, которые вынуждены конкурировать со стартапами как по скорости вывода новых продуктов на рынок, так и по скорости принятия решений. Таким организациям помогают, в частности, подходы SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum), а также нехитрая практика Scrum of Scrums. Это — тройка наиболее популярных подходов к масштабированию Agile, как показывает то же исследование Agile в России.

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

Agile — философия, scrum — ее реализация

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

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

Ценности эти настолько общие и даже абстрактные, что Agile часто называют философией.

Также встречается термин «гибкий образ мышления» (от английского Agile Mindset), который означает понимание человеком ценностей Agile.

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

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

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

Поэтому Agile и Scrum обычно изучают совместно. На нашем сайте десятки статей по гибкому управлению собраны в рубрику Аджайл и Скрам.

Исторически к Agile относится также и метод Kanban. Поэтому самый универсальный международный сертификат по Agile — ICAgile Certified Professional — включает не только Scrum, но и Kanban.

Agile сложнее, чем 4 ценности

Во-первых, помимо ценностей, в Agile-манифесте есть также 12 принципов, которые уточняют и дополняют ценности.

Во-вторых, в статье «Что такое Agile-подход и зачем он нужен бизнесу» вы найдете подробное изложение 6 признаков работы по Agile, которые намного более конкретны, чем ценности и даже принципы. Приведу их здесь кратко:

  1. Потребности клиента понятны всем. Важно, что при Agile-подходе на нуждах клиента фокусируется не только бизнес и менеджер продукта, но и вся команда. То есть, каждый из разработчиков понимает: кто клиенты, что им нужно и какие их проблемы решает новый продукт. Это помогает находить более адекватные решения.
  2. Процессы и оргструктуры максимально упрощены. Правила и процессы, по которым работают Agile-команды, должны быть простыми, чтобы люди смогли сфокусироваться на клиентах и на создаваемом продукте.
  3. Работа короткими циклами (итерациями). Продолжительность цикла — порядка недели или месяца, за это время разработчики выдают какой-либо полезный для клиента результат.
  4. Системное получение и использование обратной связи. Разработчики демонстрируют продукт заказчику, получают обратную связь на продукт и сведения об изменениях планов заказчика, затем дорабатывают, добавляют что-то полезное и так далее по циклу. Но также цикл обратной связи работает и для совершенствования самого процесса разработки: для избавления от потерь, задержек и иных препятствий, мешающих повышению производительности.
  5. Максимум полномочий у исполнителей. В идеале, люди самостоятельно принимают решения и несут за них ответственность. Когда команда или даже отдельный сотрудник сам(а) может, хочет и имеет право решить какую-то проблему без ожидания действий извне, это значительно ускоряет работу.
  6. Внутренняя мотивация вместо «кнута и пряника». Agile-методы помогают настроить процессы таким образом, что сотрудники становятся более свободны и счастливы на работе, видят востребованность своего труда клиентами, ценят доверие и предоставленные им возможности для саморазвития. Люди с такой внутренней мотивацией эффективнее справляются с работой, особенно если это сложная творческая работа.

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

Вовлечение клиентов

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

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

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

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

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

Где, как и кем используется agile

Сегодня эджайл применяется не только в управлении ИТ-проектами, а используется как эффективная практика организации труда небольших групп и творческих команд вместе с либеральными и демократическими методами менеджмента [1]. В частности, одной крупной телеком-компании благодаря внедрению Agile-практик в процессы кросс-функциональное взаимодействия всего за 3 месяца удалось достичь следующих результатов [6]:

  • рост от продажи устройств на 45%;
  • сокращение сроков запуска рекламных кампаний в 2 раза;
  • рост плановой ежемесячной выручки от разработки продуктов на 20%;
  • в 1,5 раза больше запущено рекламных кампаний по направлению В2В.

Гибкие практики управления также активно применяются и в банковском секторе. Например, за год в проектном офисе ЦентроБанка в 2 раза увеличилась скорость достижения результатов, повысилась вовлеченность сотрудников, улучшилась прозрачность и управляемость изменений [7].

Подобным опытом делится Райффайзен-Банк [8] и Сбербанк [9]. Предприятия нефтегазовой промышленности также активно используют Agile для повышения эффективности своих бизнес-процессов, открывая новые офисы и выстраивая работу филиалов по адаптивным принципам [10].

Кроме того, в рамках государственных проектов цифровизации, идеи и принципы эджайл используются в бюджетных и правительственных организациях [11]. В частности, правительство Новой Зеландии, Норвегии и США изучали методы Scrum для внедрения в своих министерствах [12].

Источники

Гибкость против жесткости: agilevswaterfall

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

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

Waterfall, водопад, водопадная каскадная модель разработки ПО
Waterfall – водопадная (каскадная) модель разработки ПО

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

гибкая итерационная разработка ПО, спринт
Гибкая разработка ПО серией итераций

История зарождения agile

Изначально термин Agile относился к ИТ-индустрии и употреблялся в контексте гибких методологий разработки программного обеспечения: экстремального программирования (XP), Crystal Clear, DSDM, Feature driven development (FDD), Scrum, Adaptive software development, Pragmatic Programming, быстрая разработка приложений (RAD) и других адаптивных методов, суть которых состоит в ускорении процессов создания продукта путем микропланирования, коротких производственных циклов и оперативного реагирования на изменения.

Ключевой смысл этих Agile-практик отражен в манифесте гибкой разработки программного обеспечения (Agile Manifesto), который был выпущен инициативной группой программистов в феврале 2001 года в американском штате Юта [1]. Эта дата считается началом повсеместного распространения эджайл как практики управления проектами и организации бизнес-процессов не только в ИТ-отрасли, но и в других прикладных областях.

Дополнительным драйвером развития Agile-подходов является микросервисная архитектура приложений, когда весь проект состоит из набора независимых слабосвязанных модулей, которые взаимодействуют друг с другом через открытые API-интерфейсы [2].

Область применения agile

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

Судя по числу участников исследования Agile в России 2022, IT-отрасль теряет свою монополию на Agile, имея долю менее 50% от общего числа людей, вовлеченных в Agile-трансформации.

Agile — это уже давно не только про разработку программного обеспечения.

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

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

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

Про область применимости Agile и про основные проблемы, которые влечет за собой Agile, смотрите в 5-минутном видео Алексея Пименова:

Подробнее о том, зачем и когда нужны гибкие подходы, вы узнаете из бесплатных видеоуроков про Agile (11 видео, 65 минут).

Ограничения водопадной модели

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

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

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

Даже в прогнозируемых проектах ожидается определенный объем изменений, и нужны механизмы для работы с ними. Всегда есть некоторое перекрытие и обратная связь между стадиями. Но в целом, в проектах водопадной разработки команда прикладывает значительные усилия к тому, чтобы как можно раньше «как положено» создать все требования.

Помимо водопадной модели и модели гибкой разработки существует много других жизненных циклов разработки ПО. В них по-разному относятся к разработке полного набора требований на ранних этапах проекта (McConnell, 1996; Boehm и Turner, 2004). Основной отличительный признак всего спектра проектов — от фиксированных, прогнозируемых проектов и полностью неопределенных, адаптивных проектов — заключается во времени, которое проходит от создания требования до поставки основанного на этом требовании ПО клиенту.

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

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

Первую публикацию формальной водопадной модели (хотя и под другим именем) приписывают Уинстону Ройсу (Royce, 1970), но он представил ее в контексте описания подхода, который «рискован и чреват неудачами». Он точно определил проблему, с которой сегодня сталкиваются при реализации проектов: ошибки требований не обнаруживаются до начала тестирования, то есть до поздних стадий проекта.

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

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

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

Планирование времени

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

Подробнее о документации

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

Бизнес-аналитики и другие ответственные за требования люди могут добиваться необходимой точности в процессе общения и документирования по мере необходимости (IIBA, 2022).Некоторые считают, что в командах гибкой разработки не нужно писать требования.

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

Преимущества и недостатки

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

Недостатки Agile являются прямым следствием его достоинств:

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

Преимущества и недостатки

Начнём с плюсов:

  1. Максимальная удовлетворённость клиента. У него есть постоянный контакт с разработчиками, его пожелания быстро находят отклик в проекте.
  2. Благоприятная атмосфера в коллективе. Даже в случае разногласий эффективнее все решать словами.
  3. Высокие цели. Постоянный фидбек предполагает внимание к мелочам, эргономике, соответствию трендам.
  4. Безопасность. Множество итераций исключает существование ошибок, допущенных в самом начале.

Но есть и минусы:

  1. Слабое внимание к документации. В случае возникновения претензий и конфликтных ситуаций аргументов в свою защиту у исполнителя просто не будет.
  2. Проблемы с реализацией комплексных продуктов. Если в самом начале разработки были заложены ограничения — на поздних этапах исправлять их будет сложно.
  3. Вероятность отказа клиентов в процессе разработки. Если у заказчика нет четкого понимания, что он хочет видеть на выходе — выполнять его требования очень сложно.
  4. Влияние иерархии. Руководители принимают все решения, так как все процессы цикла реализуются параллельно. Важность рядовых программистов минимальна.

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

Проекты гибкой разработки (agile) — карл вигерс и джой битти

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

— Scrum— Extreme Programming— Lean Software Development— Feature-Driven Development— KanbanТермин «гибкая разработка» приобрел популярность с момента публикации «Manifesto for Agile Software Development» («Манифест гибкой разработки ПО»).

Методы гибкой разработки основаны на интерактивных и инкрементальных подходах к разработке ПО, которые существуют уже много лет.Методики гибкой разработки обладают разными характеристиками, но в основном в них предпочтение отдается адаптивному (иногда он называется «управляемым изменениями»), а не прогнозному (иногда он называется «плановым»)

подходу (Boehm и Turner, 2004; IIBA, 2009). В прогнозном подходе, таком как водопадная методика, пытаются минимизировать риски в проекте, выполняя значительный объем планирования и документирования до начала создания ПО. Менеджеры проектов и бизнес-аналитики обеспечивают, чтобы все заинтересованные лица четко понимали, что планируется выпустить, до начала разработки.

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

Гибкие требования?Термин «гибкие требования» не используется, потому что это подразумевало бы, что требования в проекте гибкой разработки чем-то отличаются от проектов других жизненных циклов. Разработчикам нужен одинаковый объем информации, чтобы правильно реализовывать нужную функциональность во всех проектах. Однако в обычных проектах и проектах гибкой разработки с требованиями работают по-разному, особенно в том, что касается глубины проработки, места требований в графике проекта, а также объема письменной документации требований. Используется термин «требования в проекте гибкой разработки».

Расчет на неизбежные изменения

В организациях знают, что в проектах будут изменения. Даже бизнес-цели могут меняться. Самое важное для бизнес-аналитика — перестроиться и при возникновении изменений требования в проекте гибкой разработки говорить не что-то типа: «Минуточку, это выходит за рамки проекта» или «Для внедрения этого изменения нам нужно пройти определенный формальный процесс», а «Хорошо, давайте обсудим изменение».

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

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

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

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

Резерв проекта и расстановка приоритетов

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

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

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

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

Резюме. место agile среди родственных управленческих подходов

Итак, Agile — это не методология, не свод рецептов, не доски со стикерами и не стандартизованный набор встреч команды, предписанный в Scrum.

Это слово сейчас имеет два основных значения:

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

Agile фокусируется именно на разработке — точнее, на реализации и поставке готовых продуктов. Тогда как для генерации и проверки идей новых продуктов Agile следует дополнить различными продуктовыми подходами: Customer Development, Design Thinking и т.п.

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

Agile помогает решить две основные задачи, типичные для современного бизнеса:

  1. сократить время вывода продуктов на рынок / время их поставки потребителю;
  2. ускорить принятие решений на уровне команд и выше.

Для подходов к ускорению на уровне программ и портфелей проектов (в крупных организациях) грамотнее применять термин Enterprise Agility, хотя во многих контекстах их тоже относят к Agile.

Что же касается подходов к повышению гибкости/скорости принятия решений на уровне всего бизнеса, то это намного шире Agile. Так что для обозначения таких подходов следует использовать термин Business Agility, получивший распространение в конце 2022-х годов.

Среди 12 доменов бизнес-гибкости, показанных на рисунке, Agile полностью покрывает домен «Гибкость процессов», но также связан в той или иной степени с 5-ю другими доменами, по меньшей мере.

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

Спецификация требований в проектах гибкой разработки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чем agile отличается от методологий

Термин «методология» применяется к Agile по аналогии с предшествующими подходами к организации разработки программного обеспечения: RAD, RUP, XP и другими.

Однако те, кто сталкивался с Аджайлом, понимают: он не похож на предшествующие подходы, которые описывали процесс разработки в деталях. Agile краток: состоит из 4-х ценностей и 12-ти принципов. А описание методологии RUP, например, занимает десятки страниц, — это много приемов и алгоритмов действий.

RUP (Rational Unified Process) включает разбиение жизненного цикла разработки на 4 фазы, рекомендованные соотношения объемов работы по 9-ти потокам (workflows) на каждой фазе, а также конкретные инструменты для каждого потока. OpenUP — последняя методология-наследница RUP — короче и гибче, но все равно до краткости Agile ей далеко.

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

Метод — это способ достижения какой-либо цели.

Agile сам по себе не дает алгоритмов, способов и приемов. При этом входящие в Agile «гибкие» подходы нередко предписывают конкретные приемы:

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

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

Показанная выше условная схема гибких подходов взята из книги Бориса Вольфсона «Гибкие методологии разработки». Этот краткий справочник по огромному числу гибких управленческих инструментов весьма неплох для своего времени (2022), когда Agile применялся лишь в той индустрии, где он появился — в разработке программного обеспечения. Если же вы не связаны с этой индустрией, для углубления читайте более современные книги без IT-специфики.

Эпики, пользовательские истории и функции

Пользовательская история — это краткое утверждение, которое выражает потребность пользователя и служит исходной точной для общения с целью выяснения деталей. Пользовательские истории специально созданы для обслуживания потребностей «гибких» разработчиков. При изучении пользовательских требований вы вправе задействовать названия вариантов использования, функций или потоков процессов. Выбор формы для описания всех этих требований не важна — в этой главе мы в основном называем их пользовательскими историями, потому что именно они чаще всего используются в проектах гибкой разработки.
Объем пользовательской истории определяют так, чтобы ее реализация могла уложиться в одну итерацию. Майк Кон (Cohn, 2022) определяет эпику (epic) как пользовательскую историю, которая слишком велика для реализации в одной итерации. По этой причине эпики нужно разбивать на наборы более мелких историй. Иногда эпики такие большие, что их приходится разбивать на ряд более мелких эпик, каждая их которых в свою очередь разбивается на истории, пока не будут получены истории, которые можно с уверенностью оценить, реализовать и протестировать в одной итерации. Разбиение больших эпик сначала на более мелкие эпики, а затем на пользовательские истории часто называют декомпозицией истории (story decomposition) (IIBA, 2022).
Рисунок «Эпики могут разбиваться на более мелкие эпики, а затем — на пользовательские истории»:Эпики могут разбиваться на более мелкие эпики, а затем — на пользовательские истории

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

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *