Анализ Agile. Мифы и действительность

I Вступление

Будку надо переносить! Сезона не бывает, чтоб пару-тройку не шандарахнуло.
То с туалетом путают, то с пляжной кабинкой…
(х/ф Особенности национальной рыбалки)

Конец года, подведение итогов, заполнение анкет и прочая предпраздничная мишура ИТ функционеров. Мне уже в который раз попадается на глаза итоговые опросники ИТ фирм, призванные выявить тренды в подходах к разработке продуктов. И каждый раз возникает ощущение какого-то подвоха, когда отвечаешь на вопросы типа: «Вы все еще пользуетесь методом Waterfall (водопадная модель), или Вы все-таки (как и все передовое человечество) практикуете Agile (гибкие методологии)». Когда же начинаешь выяснять у автора сего опроса, а что он понимает под Agile, его разъяснения как-то не сильно ложатся в канву манифеста (Agile Manifesto). О многих принципах он реально задумываются впервые и эти самые принципы прямо-таки ставят его в тупик. Но после небольшого замешательства, в ход идет тяжелая артиллерия с железобетонным обоснованием своей позиции: «Мы же не по Водопаду работаем, значит по Agile».

Сам тезис «Гибкие методологии» настолько гуттаперчевый еще в своем звучании, что многие пытаются втиснуть в него все что угодно, а вернее то, что им наиболее выгодно. Постепенно это стало модной ширмой, которой можно прикрыть всякие свои недостатки и даже разгильдяйство, в процессе производства ИТ продуктов, и при этом, как-бы оставаться на гребне волны, в тренде. Мол не мы такие – а методика такая.

Давайте вместе, еще раз “ударим анализом” по теме Гибких методологий, попытаемся разложить основные артефакты и принципы по полочкам и отделить, тот сакральный смысл, который закладывали в это понятие изначально, от того, во что его превращают отдельные нерадивые популисты. Так же сравним подходы Agile с другими методиками для более точного понимания той грани, что их разделяет или наоборот – объединяет. Заодно попробуем выяснить, где использование принципов Agile наиболее целесообразно, а где не совсем уместно?

II Предыстория возникновения методик разработки программных продуктов

История — как мясной паштет: лучше не вглядываться, как его приготовляют.
Олдос Хаксли

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

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

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

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

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

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

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

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

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

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

Одной из самых известных методик, использующих итеративную модель разработки стала – 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 позволит вполне комфортно справится со всеми возникающими вызовами.

3. Свержение устоев

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

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

Однозначно плохо здесь другое. Молодые и дерзкие, глядя на это со стороны, задаются вопросом: «А что, так можно было?». Они никогда не видели в глаза качественные требования, они не умеют читать диаграммы, но им теперь это и не надо. Все! требования отныне отменили! Диаграммы, процесс моделирования – туда же в топку. Только код, код и общение. Как бонус – они могут оставить свои комментарии в коде, для будущих поколений таких же дерзких.

На этом, исторический экскурс можно закончить и перейти так сказать ближе к телу…

III Анализ явления гибкие методологии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Разберем основные идеи Agile Manifesto

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

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

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

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

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

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

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

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

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

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

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

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

3. Обсудим принципы Agile Manifesto

Раз уж мы хотим непредвзято разобраться в теме, давайте еще хотя бы вкратце коснемся и принципов, которые разъясняет Agile Manifesto:

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

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

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

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

А еще чувствуется диссонанс в утверждение, про «лучшие технические требования, дизайн и архитектуру» при том, что принципы Agile, в принципе не приветствуют документирование и все такое прочее. Если вы “обижаете” формальный подход к документации, то вряд ли она получится лучшей (народная мудрость).

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

IV Применение гибких методологий

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

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

1. Преимущества, предоставляемые использованием Agile

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

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

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

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

2. Небольшие проекты – комфортная среда для Agile

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

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

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

3. Как можно использовать Agile в средних проектах

Использование в средних проектах Agile, тоже может быть весьма эффективным.

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

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

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

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

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

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

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

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

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

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

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

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

1. Лидером в моем антирейтинге является ситуация, когда Agile, а вернее некоторые ее принципы, пытаются использовать не для достижения каких-то конкретных целей, которые они позволяют обеспечить, а просто #ПОТОМУШТО. Потому, что это тренд, это у всех на устах. Например, кто-то поделился на ИТ тусовке положительными отзывами, немного эфемерными и даже заносчивыми, но пошла молва, появился антураж. И вот уже назвавшиеся последователями Agile, ощущают в общении с остальными — принадлежность к некому элитарному клубу. Всему этому способствует кажущаяся простота методологии и туманные очертания ее границ. Внедрения по такому принципу происходит бездумно и формально. Люди, формально и беспринципно внедряют принципы, призванные снизить формализм.
   
   Вот например, один из совсем свежих случаев. В одной фирме проводя Ретроспективы, запретили их посещение тимлидами. Вот такая фишка. Неожиданно. Первая мысль: ну может быть они и правы, чтобы типа не было давления авторитетов на коллектив при обсуждении проблем и т.п. Но тимлиды обижаются, они в недоумении и хотят разобраться. Я попытался переубедить, что мол может так то оно и лучше, главное, чтобы Вам по итогу выдали список пожеланий, с перечнем, что надо менять, что улучшать и т.п. И вот тут-то и открылась страшная тайна. А ни каких итогов и пожеланий к улучшению процессов в результате этих посиделок не возникает. Господа ИТ_шники, а зачем же тогда такая ретроспектива? Просто похвалить друг друга и поднять командный дух? Сказали А, говорите и Б. Ведь основная цель этого процесса методологии и заключается в том, что: «Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы».
2. Вторая в моем рейтинге ситуация, когда команды решают сэкономить на подготовке требований в проектах со сложными поведенческими или логическими алгоритмами. То есть, когда пользовательская история является лишь небольшой вершиной айсберга проблемы, а его основная часть не видна и для реализации требует детального, тщательного анализа и проектирования. Что при этом происходит?
   
   Перед началом работ ни заказчик ни разработчики даже приблизительно не понимаю, тот объем работ, который им необходимо проделать. А соответственно: либо заказчик будет платить, платить и платить, каждый раз, когда ему будут растолковывать, что все оказалось горазда сложнее и теперь еще конца и края работам не видно. И ведь бросить будет жалко и постепенно начнет гложить суровое понимание, что этот «золотой» продукт уже никогда не окупится. Либо разработчики, подрядившись выполнить работы за определенную сумму/время, будут за свой счет (бесплатно) доделывать и переделывать продукт, пока у заказчика не иссякнет фантазия, или он не сжалится над жертвами гибкого подхода.
3. Почетное третье место занимает ситуация, когда в большом многофункциональном проекте (а вдруг еще и интеграционном) команда решает сэкономить на проработке архитектуры решения и начинает короткими итерациями реализовывать отдельные пользовательские истории. С большой долей вероятности случится так, что через 3-5 итераций, при попытке создать новый функционал, окажется, что надо переделывать весь предыдущий, так как не учли фундаментальные принципы, на которых этот функционал должен был базироваться. Еще хуже, если уже после 10_ой итерации обнаружится, что выбранные технологии не позволяют удовлетворить все потребности заказчика и надо начинать все сначала. Возможно, поменяв команду.
4. Не попала в тройку ситуация, в которой резкий и неимоверно гибкий стратап врывается на просторы вялого сегмента рынка. Стартап, он на то и стратап, что в нем нет ни каких устоев, скрепов, привязанностей, а вместе с тем устойчивости и стабильности. А проще говоря, нет почти никакой документации, коллектив не слажен и часто меняется. Рынок буквально рвет команду, требуя все новых и новых решений в застолбленной области, а все последующие проекты просто разваливаются на глазах. Чаще всего, все объясняется тем, что в команде нет понимания процессов промышленного производства ПО, организации поставки и поддержки продукта.

Подведем итоги

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

Надеюсь, что анализ поможет и командам, использующим другие методологии, в случае необходимости применить преимущества подхода Agile.
Смотрите также ролики об Agile на нашем КАНАЛЕ