Огромные недостатки разработки программного обеспечения по Agile / Хабр

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

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

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

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

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

А что, если не Waterfall?

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

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

Гибкие материалы:  Гибкие производственные системы - основное направление комплексной автоматизации машиностроительного производства. Реферат. Другое. 2013-03-30

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

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

Одной из самых известных методик, использующих итеративную модель разработки стала – Rational Unified Process (RUP). Она была разработана и внедрена во второй половине 1990-х годов в компании Rational Software.

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

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

  1. Циклический подход производства ПО. Жизненный цикл проекта RUP разбит на 4 фазы и 9 рабочих процессов.
  2. Итеративный процесс разработки. Проект RUP состоит из последовательности итераций с рекомендованной продолжительностью от 2 до 6 недель.
  3. Обязательная разработка требований. Для описания требований в RUP используются прецеденты или варианты использования (use cases). Каждый прецедент использования является описанием сценария взаимодействия пользователя с системой, полностью выполняющего конкретную пользовательскую задачу.
  4. Инкрементный подход, направленный на поэтапное приращение функциональности продукта. Основной единицей планирования итераций является прецедент использования, что позволяет вносить необходимые изменения в требования, проектные решения и реализацию в ходе проекта.

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

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

Кратко о том, что входит в 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 Manifesto


Основные идеи:

  1. Люди и взаимодействие важнее процессов и инструментов;
  2. Работающий продукт важнее исчерпывающей документации;
  3. Сотрудничество с заказчиком важнее согласования условий контракта;
  4. Готовность к изменениям важнее следования первоначальному плану.

Начнем с ложки дегтя. Лично для меня все пункты спорны. Пойдем по порядку:

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

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

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

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

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

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

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

Пункт 3. Ну для начала, в пункте непонятно само противопоставление. А разве согласование условий контракта не является сотрудничеством с заказчиком? Если заказчик, в результате уточнения условий контракта с командой разработчиков, сможет понять объем работ, примерно осознать стоимость их выполнения, а главное представить себе результат, который он сможет получить, в некоторых реально осязаемых показателях (автоматизируемых бизнес функциях, макетах форм и т.п.).

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

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

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

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

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

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

Мифы и реальность про Waterfall

Как уже было упомянуто во вступлении, антагонизмом (жертвенным подношением) для Agile (1) была выбрана Waterfall методика, которая в чистом виде была актуальна в прошлом веке, во времена перфокарт и ленточных накопителей и впервые представлена миру в статье У. У. Ройса (W. W. Royce), опубликованной в 1970 году.

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

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

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

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

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

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

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

Определения Гибких методологий

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

Первое, что отыскалось в поисковике по термину Agile:

Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.

Из данного определения можно выделить следующие важные моменты:

  1. Использование Итеративного подхода. Тут нет ничего нового, о методиках разработки ПО, отрицающих этот принцип, лично я не слышал;
  2. Формирование требований выполняется поэтапно, по ходу разработки продукта. Это пожалую ключевое отличие от многих других методик. В чем-то оно дает преимущество, в чем-то вносит принципиальные ограничения. О том и другом порассуждаем позже;
  3. Использование постоянного тесного взаимодействия всех членов команды, включая заказчика. В большинстве прочих методологий взаимодействию в команде и в том числе с заказчиками конечно же уделяется внимание, но позиционирование этого общения, как дополнительного ресурса проекта, дающего безусловное преимущество, это скорее эксклюзив;
  4. Самоорганизуемость команды. Предполагается, что каждая итерация заканчивается подведением итогов (ретроспективой) и внесением конструктивных изменений в процесс, что способствует постоянному развитию команды. Подобные приемы скорее всего позаимствованы из более ранних методик. Например, это практикует RUP.


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

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

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

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

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

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

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

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

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

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

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

Но поскольку мы тут собрались, чтобы непредвзято проанализировать феномен Agile, то посему продолжим наше исследование. Перейдем к первоисточнику – Манифесту Аджаил:

Как эффективно использовать Agile в больших интеграционных проектах

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

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

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

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

Гибкий унифицированный процесс (AUP, англ. Agile Unified Process) — упрощенная версия унифицированного процесса Unified Process (UP), разработанная Скоттом Эмблером. Данная методология разработки программного обеспечения соединяет в себе элементы гибких методологий и унифицированного процесса. В частности, AUP предполагает разработку через тестирование (TDD), применение гибкого моделирования (англ. Agile modeling) и рефакторинга баз данных, гибкое управление изменениями.

OpenUP — это итеративно-инкрементальный метод разработки программного обеспечения. Позиционируется как лёгкий и гибкий вариант RUP. OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего проекта. Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов. План проекта определяет жизненный цикл, а конечным результатом является окончательное приложение.

Как не надо использовать Agile

Не менее важный раздел, возможно ради которого и затевался весь анализ.

  1. Лидером в моем антирейтинге является ситуация, когда Agile, а вернее некоторые ее принципы, пытаются использовать не для достижения каких-то конкретных целей, которые они позволяют обеспечить, а просто #ПОТОМУШТО. Потому, что это тренд, это у всех на устах. Например, кто-то поделился на ИТ тусовке положительными отзывами, немного эфемерными и даже заносчивыми, но пошла молва, появился антураж. И вот уже назвавшиеся последователями Agile, ощущают в общении с остальными — принадлежность к некому элитарному клубу. Всему этому способствует кажущаяся простота методологии и туманные очертания ее границ. Внедрения по такому принципу происходит бездумно и формально. Люди, формально и беспринципно внедряют принципы, призванные снизить формализм.

    Вот например, один из совсем свежих случаев. В одной фирме проводя Ретроспективы, запретили их посещение тимлидами. Вот такая фишка. Неожиданно. Первая мысль: ну может быть они и правы, чтобы типа не было давления авторитетов на коллектив при обсуждении проблем и т.п. Но тимлиды обижаются, они в недоумении и хотят разобраться. Я попытался переубедить, что мол может так то оно и лучше, главное, чтобы Вам по итогу выдали список пожеланий, с перечнем, что надо менять, что улучшать и т.п. И вот тут-то и открылась страшная тайна. А ни каких итогов и пожеланий к улучшению процессов в результате этих посиделок не возникает. Господа ИТ_шники, а зачем же тогда такая ретроспектива? Просто похвалить друг друга и поднять командный дух? Сказали А, говорите и Б. Ведь основная цель этого процесса методологии и заключается в том, что: «Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы».

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

    Перед началом работ ни заказчик ни разработчики даже приблизительно не понимаю, тот объем работ, который им необходимо проделать. А соответственно: либо заказчик будет платить, платить и платить, каждый раз, когда ему будут растолковывать, что все оказалось горазда сложнее и теперь еще конца и края работам не видно. И ведь бросить будет жалко и постепенно начнет гложить суровое понимание, что этот «золотой» продукт уже никогда не окупится. Либо разработчики, подрядившись выполнить работы за определенную сумму/время, будут за свой счет (бесплатно) доделывать и переделывать продукт, пока у заказчика не иссякнет фантазия, или он не сжалится над жертвами гибкого подхода.

  3. Почетное третье место занимает ситуация, когда в большом многофункциональном проекте (а вдруг еще и интеграционном) команда решает сэкономить на проработке архитектуры решения и начинает короткими итерациями реализовывать отдельные пользовательские истории. С большой долей вероятности случится так, что через 3-5 итераций, при попытке создать новый функционал, окажется, что надо переделывать весь предыдущий, так как не учли фундаментальные принципы, на которых этот функционал должен был базироваться. Еще хуже, если уже после 10_ой итерации обнаружится, что выбранные технологии не позволяют удовлетворить все потребности заказчика и надо начинать все сначала. Возможно, поменяв команду.
  4. Не попала в тройку ситуация, в которой резкий и неимоверно гибкий стратап врывается на просторы вялого сегмента рынка. Стартап, он на то и стратап, что в нем нет ни каких устоев, скрепов, привязанностей, а вместе с тем устойчивости и стабильности. А проще говоря, нет почти никакой документации, коллектив не слажен и часто меняется. Рынок буквально рвет команду, требуя все новых и новых решений в застолбленной области, а все последующие проекты просто разваливаются на глазах. Чаще всего, все объясняется тем, что в команде нет понимания процессов промышленного производства ПО, организации поставки и поддержки продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме. место 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, после каждого спринта продукт должен быть:

  • работоспособным;

  • полезным для пользователя;

  • более совершенным, чем до спринта.

Agile-подход к разработке продукта.

Результатом первых недель работы должен стать продукт, готовый к выходу на рынок. Такой продукт называют минимально работоспособным (Minimum Viable Product, MVP).

Запуск MVP — важная точка проекта. Удачный MVP либо сразу привлекает пользователей, либо сразу проваливается и показывает нежизнеспособность идеи.

Допустим, мы делаем интернет-магазин. Магазину нужны карточки товаров, поиск, корзина, профили пользователей, бонусная система, рассылки и все такое. Если делать это по каскадной методологии, до запуска пройдут месяцы. Мы идем по Agile, поэтому ищем MVP.

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

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

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

Пары «план — спринт» идут одна за другой, пока живет проект.

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

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