Подходы к управлению проектами: границы применимости гибких методологий в проектах внедрения

Введение

Почему я решила выбрать для своего доклада на Infostart Education Event 2024 именно такую тему? Довольно много вопросов на сайте посвящены тому, насколько Agile и 1С вообще совместимы. Очень часто говорят, что Agile в крупных проектах невозможен, часто Agile обвиняют в том, что отсутствие документации списывают на применение гибких методологий.
С другой стороны, многие разработчики вообще не представляют работу без гибких методов, и считают, что Agile — "это такой спасательный круг для проектов, утонувших в водопаде".
Почти все высказывания, которые вы видите на этой картинке — это цитаты практиков, в том числе участников сообщества Инфостарт на сайте, и я решила своим докладом снять противопоставление "Agile vs Водопад" и разобраться, что есть что.

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

Чтобы не быть пустословной, а опираться на какую-то почву, я решила основываться на представления  гибкие методы управления проектами PMI — американский институт управления проектами. PMI давно уже является законодателем вообще в принципе проектного управления, на его основе написан стандарт ISO 21500, который применяется в том числе и в России. На PMBOK — свод знаний по управлению проектами, созданный PMI, ссылается 1С в своих рекомендациях. Кстати, меня очень порадовало, когда я открыла шаблоны Технологии корпоративного внедрения (1С:ТКВ) — небольшие документы, буквально несколько десятков страниц — в начале которых написано, прежде чем их применять — обязательно прочитайте PMBOK — документ на 500 страниц. То есть прежде чем применять документ в 10 страниц, прочитайте документ на 500.
Некоторые, включая моего коллега Ивана Селиховкина, который выступал на конференции с докладом "Черная книга Скрам", даже противопоставляют PMI и Agile — то есть PMI стал именем нарицательным: кто-то работает по PMI, кто-то по Scrum.
Не смотря на восприятие гибких технологий (Agile) как чего-то противоречащего подходу американского института, в последние годы PMI сделал большой шаг навстречу Agile сообществу. Во-первых, 6-ое издание Свода знаний по управлению проектами в конце каждого раздела есть кусочек  Agile. А во-вторых, институтом PMI в конце 2024 года был выпущен Agile Practice Guide, путеводитель по гибким методологиям, и что важно, PMI выпустил его не сам, не в одиночку, а совместно с Agile Alliance. Кто такой Agile Alliance? Это та самая некоммерческая организация, которая, образно выражаясь, заварила всю эту Agile кашу, в 2001 году придумав и написав Agile манифест. Конечно же, нельзя сказать, что они с чистого листа его придумали. Все эти принципы были прекрасно известны еще и до них, и конечно же подобные методы применяли и прогрессивные японские компании. Ну и даже команды разработчиков в советских НИИ тоже гибкие технологии разработки применяли. Вспомните тех же братьев Стругацких, их повесть "Понедельник начинается в субботу". В "НИИЧАВО" мы видим ту самую команду мотивированных профессионалов, которые в условиях бюрократии преодолевают сопротивление и занимаются инновационными разработками. Я думаю, многие из вас не отказались бы иметь в своем распоряжении такую команду! 

Do&Fix или Тяп-ляп

И как раз вот в этом путеводителе по Agile подробно расписываются разные подходы к управлению проектами. И прежде чем пойти дальше, я хочу несколько слов про эти подходы сказать. Ну, первый подход, это очевидно отсутствие всякого подхода. Что видим — видим какую-то проблему, ее исправляем. Встречается на практике очень часто. При применении этого подхода мы можем сравнить управление проектом с управлением машиной, которая двигается хаотически. Как вы думаете, достигнет ли она цели? Ну, если повезет — то достигнет. Но будет ли ее траектория оптимальной? Никоим образом не будет. Точно также — бывают ли проекты внедрения, которые управляются по методологии Do&Fix, или по-русски говоря тяп-ляп, которые успешны? Бывают. Если повезет. Если не повезет — то нет.

Водопад (Каскадная модель, WaterFall)

А противоположностью подхода Тяп-ляп является так называемый подход работы по Водопаду, на который ссылалась моя коллега Галина Митричева в своем докладе "Пчелы против меда: когда следование методологиям скорее вредно, чем полезно". Он же каскадная модель, он же WaterFall.
В чем суть подхода? Мы разбиваем нашу работу на четкие этапы, идущие последовательно, и четко прописываем, что мы делаем на каком этапе: собираем требования, проектируем, разрабатываем, интегрируем, внедряем. И порядок действий и сам ход внедрения естественно может быть разным. Примеры, где встречается модель Водопада — это известный многим 34-ый ГОСТ, по разработке Автоматизированных систем, это технология стандартного внедрения от 1С. Сам подход разный, но общая идея — что мы идем по порядку. И в моем опыте, честно скажу, внедрения по водопаду встречаются чаще всего, хотя многие команды пытаются от него идти. Ну если мы говорили, когда рассказывали про тяп-ляп, про хаотически двигающуюся машину, то когда мы говорим про водопад, мы можем представить себе паровоз, двигающийся по рельсам. Но что будет, если за время пути цель немного сместится? То паровоз приедет туда, куда его привели рельсы и не сможет к цели попасть. И для многих — это серьезная проблема. Мы провели небольшой опрос среди руководителей проектов на Инфостарте, и мы выяснили, что практически все РП — более 90% указывают, что к главным проблемам проектов внедрения оказываются изменения требований в процессе. 91% говорит об изменении требований в процессе проекта, 88% про нечеткие требования, 69% про то, что объем работ возрастает.
И другие сложности — про согласование, про взаимопонимание, про несоблюдение сроков — отходят на другой план.

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

Инкрементальный подход

Какие есть альтернативы? Тот же PMBOK — Свод знаний по управлению проектами призывает нас к методу "Дельфины вместо китов". Вместо того, чтобы разрабатывать одного большого кита, давайте разработаем несколько маленьких дельфинчиков, каждый из которых вместе даст кита. Так у нас появляется инкрементальный подход, когда мы выдаем много небольших поставок, или несколько небольших поставок. И выполнив поставку мы можем собрать обратную связь и использовать ее при реализации следующего этапа. Здесь у нас автомобиль, который едет прямо к цели — но периодически останавливается и проверяет, туда ли мы едем. Если цель сдвинулась — то в конце каждого этапа может произойти корректировка. В этом суть инкрементального подхода. Ну, какие у нас ограничения у подхода инкрементального по сравнению с водопадом? Ограничение первое — что он, увы, не всегда возможен. У нас очень часто условия тендера требуют одной поставки, одного контракта. Очень часто технически, особенно, когда мы говорим про строгую отчетность, мы не можем разбить поставку большую на несколько небольших. И это тоже нужно понимать, к этому нужно быть готовым. Другая, оборотная сторона медали, если мы применяем инкрементальный подход, она заметна когда мы говорим про внешнее внедрение. Про внедрение силами франчайзи. Как у нас выглядит этот подход на практике? Вы заключаете с заказчиком несколько небольших контрактов на работы, и ТЗ по каждой следующей работе будете уточнять уже когда подписаны акты по предыдущим. И многие франчайзи жалуются на следующую проблему: вот вы выполнили работы по контракту, заказчик доволен, акты подписаны, все хорошо. Выполнили следующую часть работы, заказчик доволен, акты подписаны. Но: на этом месте заказчик вам говорит: нам все нравится, мы хотим с вами продолжать, но не сейчас, а через некоторое время. Потому что у нас политически изменилась ситуация, нам сейчас неудобно, невозможно. И исполнитель, который уже настроился, рассчитывал на эту работу, были предварительные договоренности, оказывается в неудобном положении, потому что ему зарплату-то людям платить надо. Поэтому, конечно, нужно понимать, что инкрементальная модель содержит риски для исполнителя тоже. Зато позволяет в большей степени получать тот результат, который нам нужен.

Итеративный подход

Другой способ минимизации рисков водопада, это так называемый итеративный подход. В центре этого подхода, про который начиная с третьего издания тоже говорит PMBOK — на самом деле, PMBOK говорит вовсе не про водопад, а про итеративный подход. В центре итеративного подхода лежит цикл — очень напоминающий цикл Деминга, кто знает — Plan-do-check-act. Планируем-пробуем-проверяем-внедряем изменения, опять планируем-пробуем-проверяем-внедряем… В чем разница между водопадом и итеративным подходом? Мы не делаем планирование вначале, а осуществляем планирование в течение всего проекта методом набегающей волны. И, естественно, когда мы начали что-то делать,  может выясниться, что мы что-то делаем не так, что ситуация изменилась. И мы тогда перепланируем, переделываем какие-то работы. Принципиальное отличие итеративной модели, что мы изначально закладываем возможность что-то переделать, по итогам полученной обратной связи. Ключевое слово, когда мы говорим про итеративную схему — это слово прототип. Мы обязательно прототипируем, мы обязательно пробуем, и смотрим, на что наша финальная система будет похожа. Обратите внимание, здесь мы опять прокладываем рельсы, потому что поставка у нас в конце одна. Мы не можем запустить наш паровоз раньше, по техническим или организационным причинам, релиз у нас в конце. Но по мере того как проект идет, мы все лучше понимаем, куда же нам проложить рельсы. Вот цель сменилась — значит немножко корректируем рельсы. Цель сменилась опять —  прокладываем в нужную сторону.
И действительно, я соглашусь с точкой зрения, которой придерживаются многие эксперты внедренцы, что любой успешный проект внедрения оказывается по объему больше, чем планировался.  Под успешным проектом мы понимаем не просто ситуацию, когда проект сдан согласно букве договоренностей, акты подписаны. Нам все-таки важно, что продукт проекта внедрен и успешно используется.  Таким образом, проект внедрения ждет один из трех финалов: либо ваш проект будет не успешен, либо вам придется делать больше работ за ту же цену, потому что в изначально заложенных работах оказалось не все, что вам нужно сделать, либо вы подписываете доп.соглашения с заказчиком, что вам нужно сделать какие-то дополнительные работы, необходимые для успеха проекта. То есть корректировать придется в любом случае. И результаты исследования среди руководителей проектов Инфостарта показывают, что итеративный подход используется чаще всего. 

 

Мы видим, что больше половины 51% рассказывают, что они используют итеративный подход в управлении проектами. На втором месте (около четверти опрошенных) у нас оказываются подходы Agile и тот самый подход Do&Fix или тяп-ляп. То есть итеративный подход применяется большинством — мы видимо, что он фактически необходим в проектах внедрения.

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

Подход Agile

Мы поговорили с вами про подход Do&Fix, Водопад, итеративный, инкрементальный, и теперь давайте придем к последнему, к подходу. Agile — это когда мы соединяем вместе итеративность и инкрементальность. То есть когда мы с одной стороны делаем маленькие поставки, а с другой стороны мы корректируем работы  по мере появления обратной связи. Если просто в инкрементальном подходе мы сдали один кусочек, сделали первый релиз и все, мы считаем, что он у нас закончен.
То при гибком подходе мы еще больше повторяем и переделываем. Как я уже говорила, сам по себе гибкий, Agile подход основан на Agile манифесте. Я думаю, практически всем он знаком, можно с полным его текстом ознакомиться на сайте http://www.agilemanifesto.org, там же есть русская версия.
Что нам важно понимать про Agile манифест? Мы больше всего ценим ту часть, которая у нас находится слева. Но — мы ни в коем случае не игнорируем, то что справа. Потому что как только мы игнорируем правую колонку, тут же оказывается, что у нас с вами не Agile, а фактически тот же самый Do & Fix. 
 

Зачем вообще Agile нужен, что он дает? Здесь я позволю себе сослаться на опрос, он тоже есть в открытых источниках, с ним можно полностью ознакомиться — VersionOne 12th Annual State of Agile Report. 12-ый ежегодный отчет о ситуации с Agile во всем миром, где компании, использующие Agile, спросили, что им дало применение гибких методологий.

И оказалось, что больше всего набрал вариант ответа "возможность управляться с изменениями требований" — как раз та самая больная тема проектов 1С, про которые мы говорили, "лучшее видение проекта, прозрачность проекта" — "лучшее взаимоотношение бизнеса и АйТи", "более быстрая поставка продукта на рынок", "увеличенная продуктивность команды" и так далее, и так далее. То есть те команды, которым удалось внедрить Agile говорят, что им он помог. Оставим за кадром вопрос, совершаем ли мы систематическую ошибку выжившего — потому что все-таки сюда не вошли варианты ответов тех, кто попробовал Agile, и у них не получилось, но как минимум опыт большого количества успешно Agile внедряющих по крайней мере у нас есть. Сразу хочу оговориться — я ни секунды не агитирую никого за гибкие методы. Я просто рекомендую обращать внимание на то, что подходы бывают разные.

 

 

Выбор подхода для управления проектами

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

 

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

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

 

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

То есть мы находим место нашего проекта на этом графике, и смотрим какой именно подход для него применим лучше всего. 

Рекомендации по внедрению Agile

Очень часто коллеги, с которыми я обсуждаю применение гибких методов, жалуются что к их применению не готовы ни заказчики, ни руководство. Действительно, так бывает. Хотя есть плавная тенденция постепенного перехода на гибкие методы, и я верю, что она будет усиливаться и дальше. Какого-то универсального решения я не предложу, но что помогает по моему опыту при взаимодействии с ключевыми участниками. Во-первых, покажите вашим собеседникам, лицам принимающим решения эту схему. Ту табличку, ту схему, которую мы только что разбирали. Это позволит понять, что действительно, когда требования изменяются, их технически невозможно вначале собрать полностью. То что требования вначале нельзя выявить полностью, это не признак непрофессионализма команды, это устройство мира. Я не призываю не собирать требования на старте, я просто предлагаю это понимать и быть к этому готовым. И следующий момент, который помогает — это настрой сторон на долговременное сотрудничество, что когда обе стороны находятся в парадигме win-win, то можно найти решение, даже в условиях жутких контрактов, как применять гибкие методы. А когда одна из сторон хочет максимальной выгоды для себя, возможно в ущерб другой, пытается продавить другую — действительно, не получается. И опять же, моя картинка, мое общее впечатление от российского рынка, что постепенно движение в сторону парадигмы win-win происходит — люди все больше готовы к тому, что , настроены на долговременное сотрудничество, на то, чтобы обе стороны остались в выигрыше. Хотя, конечно, тут осложняет ситуацию, как минимум, когда мы говорим о внешних проектах внедрения, тот факт, что рынок проектов 1С — это в первую очередь рынок покупателей. То есть у нас диктат покупателей. На любой проект, на любую работу, у нас обязательно найдется большее количество компаний, франчайзи, которые с удовольствием за нее возьмутся.  Они будут обладать разной степенью профессионализма, в разной степени к этой работе будут готовы, но, к сожалению, момент, что покупатели очень часто диктуют условия. И здесь, опять же, за счет сотрудничества, профессионализма, можно потихонечку это сдвигать.

 

Гибридные подходы к управлению проектами

По моему опыту именно в таком виде, вышеописанные подходы встречаются не очень часто. Чаще всего мы имеем дело с подходами гибридными. когда мы не применяем Agile целиком на проекте, а применяем его частично. Что имеется в виду? Основных схем четыре.
Первая — когда мы начинаем с разработки, в некотором плане можно сравнить здесь фирму 1С, как делающую первую часть работы, и франчайзи, как делающих вторую часть работы. Потому что компания 1С в процессе разработки применяет гибкие методы, можно послушать того же Олега Фогеля, который рассказывает, как 1С-Бухгалтерия сначала разрабатывалась по Scrum, потом команда перешла на Канбан (и тот и другой фреймворк относятся к гибким методам). В любом случае, когда команда переходит к внедрению особенно по стандартной схеме, по классической — нам уже Agile не нужен, мы идем по водопаду. 
Второй вариант гибридной схемы, в чем-то самый частый, когда у нас идут классические методы управления проектами: сначала планирование, потом исполнение, потом завершение. Но на этом фоне мы используем разнообразные инструменты Agile: пытаемся внедрять самоуправляемые команды, стэндапы, ретроспективы, тесное взаимодействие с заказчиком и так далее. То есть у нас берутся инструменты из метода Agile на фоне стандартной водопадной схемы. Тоже очень часто встречающийся вариант.
Другой вариант, когда у нас идет большая часть внедрения по Agile, но нужно встроить какой-то кусок водопада.
И в чем-то самый распространенный момент, когда весь проект у нас идет по классическому, предиктивному методу — методу водопада, а кусочек его идет посередине по Agile. Типичным примером применения такого подхода является подход WaterScrumFall — вот мы взяли водопад, и посередине впихнули в него Scrum — фреймворк из гибкой методологииAgile. У нас получается на старте мы собираем все требования и проектируем систему целиком, в конце мы внедряем, а посередине процесса, на этапе разработки, мы как раз смотрим, ищем лучшие технические решения, организуем итерации, организуем демонстрации промежуточных результатов заказчику, и так далее. То есть гибридные методы они на практике встречаются очень часто, хотя, конечно, адепты методологии кричат, что нужно применять методологию целиком, но без адаптации все равно не сработает.  Что я, что все мои коллеги, которые занимаются коучингом, внедрением, консалтингом в сфере гибких методов признаются, что в чистом виде разработанные на Западе фреймворки практически никогда не взлетают. А вот в адаптированном виде — запросто.

Основные компетенции практика Agile

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

• Развитие команды

Нам важна та самая команда, про которую говорили мои коллеги в блоке про Agile.

• Адаптивное планирование.

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

• Выявление и разрешение проблем
• Постоянное совершенствование

Как раз то, что отличает Agile от Do&Fix — это постоянная готовность к изменениям.

• Фокус внимания на поставку ценностей 

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

Виды контрактов в Agile

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

Рамочные договора

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

Перевернутый треугольник

И другой вариант контакта — это, так называемый, перевернутый треугольник. Можно посмотреть слева у нас классический проектный треугольник, где у нас функционал, сроки и стоимость. И поставленный функционал, который нужен, у нас жестко зафиксирован, никуда не может деться, ни за что не может измениться. А сроки и стоимость у нас, конечно же, тоже зафиксированы, но могут уплыть. Если стоимость уплыть не может, то может уплыть по крайней мере себестоимость. А Agile у нас переворачивает все с ног на голову, то есть мы с вами жестко фиксируем сроки и стоимость, и при этом не уверены в том, какой функционал у нас будет на выходе. Но уверены в том, что это будет функционал, представляющий максимульную ценность для клиента из того, что можно было за это время и деньги получить. Давайте я попробую на примере объяснить, как это работает — возьму конкретный кейс. Имеем инновационный банк — банк, который использующий инновационные технологии. Имеем опыт провала нескольких проектов по водопаду — что важно. Что проект запущен, проект проведен, сдан — результат оказывается никому не нужен. То есть заказчик уже оказывается потенциально готов к тому, что как-то по-другому нужно работать. Дальше — имеем подрядчика, который замотивирован на долговременное сотрудничество. Который выполняет поставки железа и в связи с этим разнообразное программное обеспечение тоже хочет сделать на высшем уровне. И имеем работу подрядчика на стороне заказчика. И действительно, при этих условиях оказывается, что контракт, в котором мы фиксируем сроки, стоимость, а функционал просто по ходу ситуации дорабатываем с заказчиком, он работает, оказывается эффективно.

Ваши изменения бесплатно

И еще один принцип контрактования Agile, который озвучил Джеф Сазерленд, автор метода Scrum, в своей книге про Scrum, это принцип "Ваши изменения бесплатно" Вот у нас есть объем работ, который есть в бэклоге, и заказчик понимает в процессе проекта, что нам надо обязательно добавить какую-то функцию, вот без нее никак. Что происходит? Пожалуйста, любую функцию можно добавить, убрав вместо нее любую аналогичную по трудоемкости. При этом приоритеты расставляет заказчик, а трудоемкость определяет исполнитель. И тоже в этой ситуации все оказываются довольны, потому что наверняка есть какая-то функция, которую можно убрать достаточно безболезненно для проекта в целом. И опять же, опрос, проведенный среди практиков, в сообществе Agile Russia, показывает, что большая часть практиков Agile как-то проблему с Agile решает. Почти 40% ответивших показывают, что используют контракты "Время и материалы", когда в ходе внедрения смотрят, сколько наработали, сколько функций сделали, и это оплачивается. Порядка четверти используют контракт Fix Price и не как используют гибкие методы контрактования, и 13% и 11%, итого 24% — используют контракты Fix Price с доп. соглашениями, предполагающими возможности внесения изменений. 

 

 

 

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 EDUCATION. Больше статей можно прочитать здесь.

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

Выбрать мероприятие.