Анализ 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.

    Список литературы
    1. Вольфсон Борис- «Гибкие методологии разработки»
    2. Якобсон А., Буч Г., Рамбо Дж. – «Унифицированный процесс разработки ПО» (2004)
    системы»
    Поделиться публикацией

    Комментарии 38

      0
      Может быть всё-таки Agile?
        0
        Дельное замечание. Спасибо! Не в бровь, а в глаз. Копипаст рулит. Исправил.
        0
        Вот вы написали 4 случая, когда agile не работает. А что сработает?

          0
          Там есть ссылочки в этих пунктах. По ним можно перейти и ознакомиться, с тем, что на мой взгляд в этих случаях сработает.
            0
            Ну вот у вас 2 пункт.
            У заказчика нет ресурсов на сбор требований. Ну скажем, нет ответственного с его стороны. Так что ваша ссылка не релевантна.

            Самый логичный способ запилить, что-то и выкатить, а потом слушать, что не так и как это поправить. Я участвовал в нескольких таких проектах, и когда менеджмент понимал, ситуацию, то мы успешно использовали agile.
            Кстати, переписать всё с нуля не такая уж большая проблема, если понятно, что писать и уже отработана технология.
              +1
              Заказчик не должен собирать требования, поскольку у него нет соответствующих навыков и знаний. Качественно собирать и формализовать требования в больших и сложных проектах должны аналитики. Они обладают навыками и приемами, позволяющими вытянуть из заказчика потребности, даже если тот не очень желает делиться своими знаниями о предметной области.

              Переписать с нуля, к примеру, систему Документооборота гос.струтктуры не очень большая проблема??? (мы же говорим о больших системах).
                0
                должны аналитики

                Которые должны с кем-то общаться. Со стороны заказчика должны быть ответственные лица, которые бы отвечали на вопросы аналитиков и устраивали митинги. Взаимодействие с аналитиками со стороны заказчика — это куча денег.
                  0
                  Я Вам больше скажу, использование программистов для взаимодействия с заказчиком — это еще дороже, поскольку и стоят программисты в среднем дороже и выхлоп будет меньше, потому как аналитики, все таки для это роли более приспособлены.
                    +1
                    Речь не об аналитиках а о людях со стороны заказчика. Вы понимаете, что для того, чтобы аналитик работал его письма не должны сразу оптавляться в спам человеком, у которого и так куча работы, кроме как с подрядчиком общаться.
                    Со стороны заказчика всё это надо организовать — это может быть очень и очень сложно. Аналитику должен отвечать компетентный специалист, который ещё и конкретно отвечать может не хотеть, ибо это ж ответственность. Короче, куча проблем со стороны заказчика, которые подрядчик не может толком решить.

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

                      Для этого есть другие роли в проекте. Это может быть Продакт или Проджект менеджеры. Может быть высшее руководство подрядчика — исполнителя.
                      Задача стоит в другой плоскости — организовать процесс. Не стоит эту проблему решать препирательством исполнителей.

                      Если есть контракт, то в нем обычно прописывают в обязательствах заказчика пункт о своевременном предоставлении необходимой информации. Если контракт не исполняется, то руководство исполнителя направляет руководству заказчика претензию о неисполнении контракта и это в большинстве случаев действенно. Поскольку руководству заказчика нужен продукт и не нужны неустойки.
          +4
          Вся проблема в том, что вы считаете что в манифесте правая часть противопоставляется левой. Это просто проблема перевода / восприятия слова «важнее». Прямо в манифесте, 5-й строчкой написано
          That is, while there is value in the items on the right, we value the items on the left more.

          Вы же восприняли слово over / важнее как «вместо».

          По пунктам примерно так:

          1. Individuals and interactions over processes and tools. Это не «пренебрежение регламентами», это «если команда считает, что будет лучше работать с другим регламентом и инструментами — надо менять регламент и инструменты, а не давить на команду»
          2. Working software over comprehensive documentation. Это просто утверждение, что ситуация «работающий продукт с не совсем полной документацией», лучше чем «неработающий продукт с полной документацией». Там нет утверждения, что документация не нужна.
          3. Customer collaboration over contract negotiation — это не «контракт не нужен». Это «если в процессе разработки оказалось, что в контракте закреплены нереальные, противоречивые или устаревшие требования — то стоит руководствоваться реальными требованиями, поговорить с кастомером, поменять контракт. И менять контракт. И заодно „надо активно пинать кастомера на предмет изменения требований“. А не дописывать без обсуждения промежуточных результатов до самого релиза.
          4. Responding to change over following a plan — это не про техническую возможность внесения изменений. И не про отсутствие плана. А про то, что если ситуация поменялась и идет вразрез с планом — то стоит учесть изменения. А не слепо следовать плану.

          Сам по себе Agile Manifesto — это „манифест здравого смысла“. В нем достаточно очевидные утверждения, которые не накладывают жестких ограничений на процесс. Можно делать водопад, но при этом следовать принципам Agile. Можно делать SCRUM, но при этом не следовать Agile почти никак.
            0
            Эта статья посвящена русскоязычной аудитории. Если посмотреть практически любой перевод на русский язык, то приведенный мной перевод далеко не самый радикальный. Можно найти и такое трактование: «Мы больше не заставляем расписываться заказчика кровью, ограничивая его жесткими и неудобными условиями договоров». Даже в Вашем переводе много личного, разъясняющего, как это надо трактовать (вариант от Вас). Об этом в общем то и речь в статье.
            Можно читать так, а можно и ровно наоборот. Главное, чтобы Вы могли это подкрепить своим взглядом на «здравый смысл».
              +2
              У вас в статье — официальный перевод с agilemanifesto.org/iso/ru/manifesto.html. Agile manifesto — это весь текст манифеста, а только процитированные в статье четыре пункта.

              То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
              это такая же часть манифеста, как и предложения с «важнее». А не какое-то дополнительное «личное толкование». Нужно очень сильно постараться при переводе, чтобы превратить «мы не отрицаем важность согласования условий контракта» в «контракт не нужен».
            0
            Интересная статья, спасибо.
            Планируется добавить часть про SAF (scaled agile framework)?
            Хотелось бы увидеть предложения по использованию agile в крупных интеграционных проектах более детально. Планируете?
            0
            Ну вот не стоило тут про перфокарты-то. Допустим, в 1970 они и имели место, но уже в 1980 в лично моей реальности их не существовало, а лет на 5 позже ими уже пользовались лишь самые закостенелые.

            И что даже еще важнее, так это то, что в 1970-х еще не существовало средств версионирование кода, как таковых (да и в 80-х пожалуй тоже, потому что CVS появилась в 1990-м). А отсутствие в процессе разработки даже CVS влияет на него намного сильнее, чем Waterfall vs Agile.
              +1
              В конце 80-ых, абсолютно точно, и с большой долей вероятности в начале 90-ых большая часть гос.статов. СССР работала на ЕС 1035, 1045. В том числе с перфокартами.
                +1
                Видите ли, я программирую с 1975, поэтому эти все ЕС наблюдал лично. И очень многие, смею вас заверить (включая те 4 своих, которые обслуживал как системщик).

                Я с 1980 года примерно перфокарты почти не трогал. А уже в середине 80-х все машины приходили как минимум оснащенные ЕС-7066, а потом ЕС-7927. Я говорю про свою реальность (в частности это Москва — хотя наблюдал и Миасс, например, и Питер).

                Хотя другую реальность я исключать конечно не могу — в конечном счете, я общался с коллегами, а это был Минобщемаш, и вряд ли он был самый бедный :)
                  0
                  А не слышал ли кто случайно, Миасс мог в своих недрах выпускать/собираться выпускать свой аналог ПВК Электроника МС-0585 (Воронеж) (DEC Professonal 350)?
                    0
                    Я тут говорил не про тот Миасс, который вы видимо имели в виду, так что не знаю.
              0

              Пипец как задолбали эти воинствующие надсмотрщики со своими методиками улучшенной эксплуатации работников!
              Давайте я гипертрофирую немного данные статейки чтобы понять всю хрень всех этих эксплуататорских методик:


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


              Как вам такая интерпритация!? )))
              Сейчас эти воинствующие надсмотрщики накинутся на меня )
              Но давайте их остановим аргументами:


              Давайте сначала вспомним, что мы все еще живем в эпоху эксплуатации — да, да — Карла Маркса еще никто не отменял как и эксплуатацию при капитализме (для молодежи ссылка для почитать http://www.esperanto.mv.ru/wiki/%D0%9C%D0%B0%D1%80%D0%BA%D1%81%D0%B8%D0%B7%D0%BC/%D0%AD%D0%BA%D1%81%D0%BF%D0%BB%D1%83%D0%B0%D1%82%D0%B0%D1%86%D0%B8%D1%8F)


              Почему разработчик (он же ресурс в их терминологии) должен рвать задницу и как-то там само организовываться за ту же зарплату???
              мне начнут лепить тут что дескать он таким образом становится профессионалом!!!
              О как )) а если он и до этого был и является профессионалом но без этой лапши??


              • он что участвует в разделе прибыли предприятия?? — нет
              • он влияет на принятие решений, которые генерируют все вышестоящие и мнящие себя великими всякие топы, овнеры, дезайнеры и так называемые менеджеры?? — нет

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


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


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


              А мелкие компании по-прежнему будут до некоторого времени эксплуатировать сказки про самоорганизацию про то что ресурс должен быть эффективным и произыодительным во имя какого-то владельца конторы!

                0
                Поменяйте галеру (аутсорс, работу на госструктуры) на нормальную продуктовую контору. Будет и нормальная зп, и возможность принимать решения не только в коде, и свобода от корпоративного духа. Аджайл тут как бы вообще ни при чем. При старом добром водопаде гребсти ничуть не легче.
                  0
                  неужели вы думаете, что за такой срок я не побывал во всех типах контор? )
                  Именно в продуктовых этот эджайл цветет и пахнет ))

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

                    1) Люди и взаимодействие важнее процессов и инструментов;
                  0

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

                    0
                    Бизнесу люди в офисах нафиг не нужны. Бизнес организуют, чтобы получать прибыль, а не делать приятно работникам. Если можно автоматизировать всё и выгнать пролетариат на мороз, в 99% случаев это будет сделано, а оставшийся 1% заслуженно сдохнет, не выдержав конкуренции. Считаете это неправильным? Но это то, как устроены жизнь и прогресс, так что тот, кто против — тот, получается, за смерть и регресс.
                    А в прибыли нефиг участвовать тем, кто не участвует в капитале и рисках.
                      0
                      Все не так уж однозначно. С одной стороны, бизнес это детище — почти «живой организм» и отношение к нему у организаторов (не владельцев, а именно организаторов) бизнеса, соответствующее. И команда в нем тоже часть «живого организма» (наиболее живая и интересная), позволяющего ему функционировать и развиваться. Вот если часть этого организма мешает ему развиваться или функционировать, тут может быть включен механизм самосохранения, выбранный организатором (владельцем) бизнеса. Это могут быть репрессии, избавления от балласта, нянченье и заигрывание, замена человеческого труда автоматизацией и т.д.
                        0
                        > А в прибыли нефиг участвовать тем, кто не участвует в капитале и рисках.

                        Возможно и так, но тогда нефиг требовать от сотрудников быть какими-то мотивированными и самововлеченными!
                        Сотрудник пришел и за зарплату делает свою работу!
                        Если хотите от него чего-то большего — вот тут уж будте добры поизголяйтесь — либо улыбайтесь и предоставляйте плюшки либо доплачивайте, а не разводите всякую муру про то что работник что-то еще там должен кроме основной своей работы!
                          0
                          нефиг требовать от сотрудников быть какими-то мотивированными и самововлеченными

                          Абсолютно согласен, нефиг. Бизнес не организуют ради создания рабочих мест, но и наемный работник ходит на работу не ради обогащения своего босса.
                        +1
                        Что значит «за ту же зарплату»? Как правило, людям способным к самоорганизации платят больше там, где эта способность востребована. Собственно как и за любые востребованные способности
                        0
                        AZaz1, А Вы были когда нибудь владельцем конторы, чтобы объективно рассуждать об этом? Я таковым являюсь. Чтобы долго не разглагольствовать приведу в пример анекдот, очень хорошо отражающий суть проблемы: «Надоело работать на дядю, открыл свое дело. Теперь работаю на 10 дядь».
                          0
                          мой пост был немного не про это )
                          +1
                          5. Как не надо использовать Agile

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


                          Много проще.

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

                          Строишь дом? Строительство относительно прогнозируемая деятельность. Никакой agile не нужен.
                          Продаешь свои услуги через свой сайт или свое мобильное приложение? Эта область непрерывных изменений. Без agile твой бизнес весьма вероятно проигрывает конкурентам и умирает.
                            0
                            Agile — не про ИТ. Agile — про бизнес.

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

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

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

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

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

                            Только упомянутый вами аврал и спасает.
                              +1
                              Есть разные взгляды на этот вопрос)
                              И один из них — попробуйте набирать в команду людей со схожими целями и ценностями.

                              Например: наберите семейных мужиков с ипотекой и детьми. По итогам квартала: мы выполнили план и заработали? Вот вам еще 2 оклада.

                              Удивитесь насколько разработчики могут оказаться людьми «про бизнес»)
                              –1
                              Удивлен, что кто-то еще придерживается тех же взглядов на «agile-rup-водопад» что и я.
                              Пожалуй только не соглашусь про
                              «команда решает сэкономить на проработке архитектуры решения и начинает короткими итерациями реализовывать отдельные пользовательские истории. „

                              Иногда так бывает, что даже “проработав архитектуру» (в случаее ее неочевидности) — всё-равно с появлением новых требований может возникнуть неприятная ситуация и что-то придется переделывать, потому что теперь всё по другому — но тут уж никакая методология от неизвестности будущего не застрахует.
                              Субъективно для себя я утвердился во мнении, что если уберечь команду от игр в «я-у-мамы-архитектор» и от того чтобы на ранних этапах слишком всё оптимизировать — потом получается легче принимать изменения т.к. мы не завязали себя в узел + меньше привязанность к прошлым решениям т.к. на них было потрачено меньше ментальных усилий.

                              А в остальном: нас спасет только стремление к осознанности и здравому смыслу + общие цели и ценности.
                                +1
                                Я олдскульщик и вообще старая школа (тот самый RUP когда-то от зубов отскакивал; а уж как я любил автогенерацию Vision на основе заполненных UseCases это вообще не передать), но при этом — я очень гибкий товарищ.
                                Поэтому, когда мне заказчик говорит "… разработку ведем только по гибким методологиям" я ему вот прям сразу и отвечаю «без вопросов, дорогой, за твои деньги, да по T&M, я буду работать хоть вприсядку с подвыпертом, только плати, уважаемый».
                                Приблизительно 99,9 заказчиков после слов о T&M резко перестают хотеть гибкие методологии.

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

                                Самое читаемое