Честно скажу, название статьи навеяно старым анекдотом…
Как заставить себя вставать пораньше? Как просыпаться выспавшимся? Как приходить на работу радостным? Как уехать из Крайнего Севера и жить в Сочи? Как есть всё подряд и не толстеть? Обо всем этом читайте в новой книге "Никак, б*”%#*!" "Никак, б*”%#*!" — теперь и в твердом переплете.
Дисклеймер. Я ни секунды не утверждаю, что именно вам нужно срочно переходить с Водопада на Agile. Универсальной и идеальной методологии вообще не существует. Я ни секунды не утверждаю, что в вашем случае возможен переход на Agile, а мешающие этому проблемы преодолимы. Я просто констатирую, что у многих компаний есть успешный опыт руководства ИТ-проектами при помощи гибких методологий, и этот опыт может оказаться полезным.
Управление требованиями: больная тема
Начну, с вашего позволения, с небольшого списка литературы.
Я уже рассказывала, какие бывают подходы в управлении проектами. Чтобы у нас была возможность говорить на одном языке, рекомендую перед прочтением этой статьи ознакомиться с моими материалами на эту же тему Можно ли объять необъятное или чем Agile отличается от водопада? и Почему Agile превращается в Тяп-ляп. Кто виноват и что делать? Тема написания ТЗ и уточнения требований была в свое время частично раскрыта в статье Александра Чавалаха Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть? Классические подходы (водопад/итеративный подход) разбирает в своих статьях Иван Селиховкин, так что не буду его дублировать, и поговорю подробнее про применение гибких методов в управлении.
Опрос среди руководителей проектов внедрения 1С, проведенный на сайте Инфостарт, показал, что из всех проблем лидируют “Изменение требований в ходе проекта” (около 25% опрошенных) и “Нечеткие требования заказчика” (около 24% опрошенных).
Итак, в чем ключевая особенность управления по Agile в вопросах создания ТЗ и управления требованиями?.. Очень просто — ограничения не фиксируются в начале проекта. То есть у нас нет той самой “скорлупы яйца” — жестких сроков-бюджета-содержания, о которых говорится в статье Ивана Селиховкина Три фундаментальных принципа проектного управления.
Мы понимаем окончательную цель проекта — допустим, переход от зоопарка разных программ и приложений ("лоскутная автоматизация") на 1С: Комплексную автоматизацию. Но не знаем подробности: сроки, стоимость, и даже подробное содержание (бизнес-функциональные требования, а тем более технические задачи для выполнения этих требований).
Если и заказчик и исполнитель привыкли работать по водопаду, то на этой точке (неопределенность общих сроков, содержания и бюджета) дальнейшее сотрудничество может быть признано невозможным.
Но в Agile — все так и работают, и считают, что так и надо )))… Давайте попробуем разобраться, за счет чего это может получиться.
Водопад: его недостатки и ограничения
Водопад, несомненно, большой шаг вперед по сравнению с технологией “тяп-ляп” — здесь четко структурирован порядок деятельности.
Скажем, вот так выглядит технология корпоративного внедрения (ТКВ) от 1С, предполагающая последовательное внедрение по водопаду.
Весь проект разделен на четкие последовательные фазы, каждая из фаз регламентирована.
В чем же основные недостатки водопадного подхода?
- В начале проекта Заказчик не может написать хорошие требования
Чем серьезнее и комплекснее проект внедрения, чем большие изменения бизнес-процессов компании предполагаются, тем сложнее Заказчику сформулировать, что именно ему требуется. Скажем, в ходе внедрения Документооборота в Почте России, эта проблема возникла в полный рост — будущие пользователи смутно понимали, что от них требуется.
- Список требований пополняется до самого конца проекта
Очень часто, знакомясь с документами по тому или иному проекту, я встречаю упоминание пополнения списка требований в графе “Риски проекта”. Увы, по моему опыту, это скорее не риски, а ограничения проекта — я пока не видела ни одного проекта внедрения, где новые требования бы не появлялись в процессе. Может различаться только отношение к этим требованиям. Исполнитель может делать лицо кирпичом и отказываться их учитывать, ссылаясь на подписанный контракт. Но новые требования будут появляться обязательно (если заказчик хоть сколько-то вовлечен в процесс разработки и тестирования).
- Самые точные и полные требования Заказчик сформулирует на стадии внедрения
Одна из типичных проблем при сборе требований, сформулированная Дмитрием Безуглым в его онлайн-курсе “Постановка задачи на разработку ПО” — “Заинтересованный стороны и пользователи думают, что знают, чего именно они хотят, до тех пор, пока им не дали именно то, что они попросили”.
Опять же, можно обвинять в этой проблеме аналитиков и пользователей, но по мне, это примерно как обвинять небо, что идет дождь…
- Аналитиков не волнуют трудности будущей разработки
В моей практике в больших командах внедрения часто возникают конфликты внутри команды между разными “лагерями”:
Аналитики обвиняют продажников, в том, что они обещали реализацию функционала, который с их точки зрения, мало возможен при помощи предложенного продукта.
Разработчики обвиняют архитекторов, что они призывают реализовать громоздкое и неработоспособное решение.
Тестировщики обвиняют разработчиков, что они пишут кривой код…
Ну, и так далее (кстати, как у вас? поделитесь в комментариях)…
- Заказчики не знают возможностей и ограничений технологии
Любое внедрение, предполагающее смену инструментов с разной бизнес-логикой (переход с 7 на 8 бухгалтерию, переход с УПП на ERP и т. п.) обычно сопровождается довольно болезненными запросами “сделайте мне также как было” и объяснениями консультантов, почему именно это невозможно.
С другой стороны, если заказчикам не приходит в голову, что приложение может решать какую-либо задачу, они и не включат запрос об этом в бизнес-функциональные требования.
- Существуют проблемы (ошибки), о которых можно узнать только завершив работу в этой фазе и начав работу в следующей
Кривые и непродуманные аспекты архитектуры очень часто становятся заметны только на этапе внедрения. Если в вашем проекте по занесению пианино на 17-ый этаж вы совершили ошибку на этапе планирования — неправильно выбрали подъезд — то вы ее заметите только перейдя к этапу внедрения в квартиру…
Agile: подход к сбору требований и написанию ТЗ
Итак, мы поговорили о проблемах и ограничениях водопадного подхода. Как же можно минимизировать эти проблемы?
При помощи итеративности и инкрементальности. То есть выдавать конечный результат маленькими порциями (инкрементами), и осуществлять планирование на протяжении всего проекта (итеративно). Детализация требований при этом тоже осуществляется на каждом этапе отдельно. См, например, схему работы предлагаемую компанией 1С в технологии быстрого результата (ТБР), относящейся к гибким методологиям:
Детализация требований и планирование осуществляется на каждой фазе отдельно, то есть непонимание заказчиком своих запросов на старте уже не является проблемой.
Работает ли Agile в ИТ-проектах и проектах внедрения 1С в частности?
В ходе вебинара для руководителей проектов мы провели опрос более чем 100 руководителей проектов внедрения 1С. И результаты опроса показали, что около 22% РП применяют гибкие методы в управлении проектами.
Мировой опыт тоже явно указывает на тенденцию перехода в Agile.
Скажем, очередной Chaos Report от Standish Group International показал, что шансы на успех ИТ проекта (то есть полное выполнение целей и удовлетворение заказчика) по Agile более чем в полтора раза выше, чем управляемого по водопаду.
Итак. Мы выяснили, что Agile возможен, что уход от водопадной модели обладает некоторым количеством преимуществ. Теперь прикладной вопрос — как это может выглядеть на практике, при внедрении 1С-продукта?
Вариант первый. Внедрение внутри предприятия своими специалистами.
Здесь, как мне кажется, Agile просто напрашивается. Большинство известных мне крупных успешных компаний, где ИТ-решения предлагают внутренние подразделения, постепенно уходят от крупных комплексных проектов, с тщательным продумыванием деталей на старте. Потому что к концу долгого водопадного проекта чаще всего выясняется, что проект успешно реализован согласно ТЗ, но… в таком виде уже давно никому не нужен.
Как выглядит управление проектом по Agile в этом случае?
На старте четко понимается целевой результат. На старте максимально четко понимается архитектура решения в целом. На старте формулируются наиболее важные бизнес-функциональные требования. На старте определяется функционал первого релиза. На старте мы не пытаемся понимать весь бюджет, сроки внедрения в целом, полный объем содержания. Дальше проект запускается, и обеспечивается взаимодействие между ключевыми заинтересованными сторонами.
Вариант второй. Внедрение во внешней организации. Серия небольших договоров.
Как уже описывалось выше, в начале проекта заказчик и исполнитель не пытаются понять общую стоимость, продолжительность и содержание проекта. В начале — оформляется рамочное соглашение, договор о намерениях, включающий общую цель. Дальше заключается серия небольших контрактов, каждый из которых предполагает законченный результат, подлежащий использованию. Неоднократно наблюдала компании франчайзи, которые успешно выполняли многомиллионные контракты на крупные компании/холдинги “по кусочкам” — каждый конкретный контракт заключался на небольшую сумму.
Вариант третий. Внедрение во внешней организации. Один большой контракт.
Вариант, описанный выше, хорош, но не всегда возможен. Скажем, когда у вас идет речь о госконтракте, объявляется тендер, подписывается договор на старте — и в нем должны быть жестко зафиксированы сроки, бюджет и содержание ТЗ. Как можно действовать в такой ситуации? Мы же помним все те недостатки водопадного метода, про которые мы говорили в начале статьи — заказчик физически не способен на старте четко сформулировать исчерпывающие требования, появление новых требований и уточнение старых в ходе проекта неизбежно.
Чтобы иметь возможность применять гибкие подходы Agile, вам нужно суметь реализовать две лазейки.
Во-первых, не пытаться четко прописывать подробные требования на старте. На старте в ТЗ указываются высокоуровневые требования, а дальше они, по методу набегающей волны, детализируются уже в ходе проекта.
Во-вторых, заложить в контракт опцию замены требований на аналогичные по трудоемкости. Знакомая, думаю, всем ситуация — в ходе проекта заказчику становится понятно, что ему крайне необходим дополнительный функционал. При этом контракт подписан и утвержден на старте, и исполнитель не жаждет делать дополнительные работы за бесплатно. В такой ситуации можно предложить заменить часть функционала из контракта, которую заказчик на настоящий момент оценивает как менее ценную, на новые функции. Причем приоритетность функций (что важнее всего) оценивает заказчик, а трудоемкость работ (что значит “заменяем работу на аналогичную”) — исполнитель.
Важно, чтобы договор предполагал выполнение работ по этапам, и была возможность при помощи дополнительных соглашений менять состав работ на каждом этапе.
Скажем честно, на практике так очень часто в водопадных проектах и делают “мимо договора”, просто “договариваясь по понятиям”… Но в этой ситуации мы имеем расхождение между документом и действительностью, что осложняет дальнейшее сопровождение и вообще усложняет коммуникацию. Оптимальное решение, повторюсь, указано выше — заложить в условия договора возможность замены одного функционала на другой.
Ограничения Agile
Гибкие методы управления проектами — не панацея.
В рамках вебинара для руководителей проектов 1С, который мы провели некоторое время назад на Инфостарте, руководители проектов, успешно применяющие Agile, поделились за счет чего им это удается, а что — мешает. Ниже рекомендации по моему опыту и опыту моих коллег:
Что мешает внедрять Agile?
- Как я писала в предыдущей статье — гибкие методы подходят для проектов с высокой степенью неопределенности требований, высокой степенью технической неопределенности и возможностями частых поставок.
- Agile ограниченно подходит для решений со сложной архитектурой. Компания 1С, разработавшая Технологию быстрого результата (ТБР), по сути, являющуюся фреймворком в рамках гибких методологий, не рекомендует применять ее для сложных архитектурных решений. Потому что частыми маленькими релизами как раз легко сломать типовую архитектуру и нагородить решений, которые сложно будет использовать для других задач.
- Гибкие методы подразумевают очень сильное вовлечение специалистов заказчика (вплоть до участия в определении фич в начале каждой итерации) — а это время заказчика и немалое. Не все заказчики к этому готовы.
- Неопределенность бюджета и сроков проекта усложняет коммуникацию с руководством заказчика
- При работе по небольшим кусочкам заказчик всегда может разорвать контракт с исполнителем посередине, или отложить реализацию следующего фрагмента. Это удобно заказчику, но уменьшает уверенность исполнителя в завтрашнем дне. Разрывы между итерациями увеличивают себестоимость проекта.
Что помогает внедрять Agile на практике?
- Отношения, основанные на доверии, и готовность обеих сторон к сотрудничеству.
- Приемка каждую итерацию. Или хотя бы демонстрация заказчику.
- Документальная фиксация согласия заказчика с промежуточным результатом — актировать этапы.
- Вовлечение в тестирование на промежуточных стадиях широкого круга пользователей от заказчика (зачастую против воли основного представителя заказчика)
- Практически любой заказчик хочет быстрый результат. Поэтому обещанием работающего инкремента с урезанным функционалом по итогам первой итерации — позволяет уговорить заказчика на применение гибких методологий.
- Обжегшись на молоке заказчики начинают дуть на воду. Если у заказчика был опыт неудачных ИТ-проектов по водопаду — уговорить его на Agile будет несколько проще ))).
Резюме данной статьи хорошо сформулировал мой коллега, Дмитрий Кузнецов:
Использование гибких методов не гарантирует успех проекта. Но в некоторых ситуациях (например, высокой неопределенности требований) не применение Agile предопределяет его провал…
В следующей статье я расскажу про то, какие техники и инструменты по сбору и приоритизации требований предлагают гибкие методологии. Следите за обновлениями.
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Вы часто встречаете подобные отношения в проектах по внедрению? Да вообще в бизнесе.
Многих проблем можно было бы избежать, много подходов поменять, много работы не делать, если бы отношения, основанные на доверии встречались бы чаще.
Я бы сказал «нередко делает невозможной.»
Тот же дефицит доверия.
Agile неплох для внедрения силами «внутренних» программистов, хотя и там водопад применяют просто потому что не доверяют своим сотрудникам. Для более или менее крупного внедрения сторонней организацией… очень хотелось бы узнать как РП сумел договориться с руководством организации на внедрение «с неопределенным сроками и бюджетом».
(2) Steelvan — радует, что название книжки, упомянутое в начале статьи, выше слова «Дисклеймер», не затруднило чтения.
(1)
Подстава заключается в том, что Водопад дает скорее иллюзию внедрения с определенным сроком и бюджетом… Потому что на практике результат очень часто оказывается неработоспособным. И организации (в том числе крупные) скрепя сердце соглашаются на Agile.
(Ну, или не соглашаются. Но статья про тех, кто соглашается — и их с каждым годом все больше).
(4)
Во-первых, вы явно недооцениваете иллюзии… на них в нашем мире делают огромные деньги. Более того, они очень нужны многим людям.
Во-вторых, суть в том, что водопад вместе с иллюзией даёт хоть какую-то определенность. Четкие сроки и сумму. Да, потом это поменяется десять раз, но все же есть хоть какая-то база. А что пишут в договоре на внедрение по agile? Клиент обязуется исправно платить за некие работы не имея реальной возможности потребовать результата, т.к. появление этого результата не обусловлено ни наступлением какой-либо даты, ни выплатой определенной суммы?
Прочитав заголовок, хотел зайти и написать: «Никак».
А у вас это в начале написано)
Информация, основанная на полученном опыте: на начальном этапе всего 20-30% процентов могут сформулировать требования, остальные выражают абстрактные мысли. И даже та часть клиентов с вероятностью в 50 процентов все переиначивают на этапе разработки, внедрения и знакомства с продуктом. Назвать первоначальные общения с клиентом «постановкой задач» не поворачивается язык. Я называю этот этап «Предварительная ласка»))
(6) beefit — похоже мыслим!
(7) d.zhukov — точная характеристика процесса, что-то есть )))
(5)
— несомненно. Иллюзии вообще очень ценная вещь, факт!.. Мы говорим про ту ситуацию, когда участники хотят результат, имеющий бизнес-ценность, и дозрели ради этого до отказа от иллюзий.
Вот здесь-то собака и порылась! Что у них должен быть промежуточный результат, пригодный или потенциально пригодный к внедрению. И на промежуточном этапе в принципе можно заплатить деньги за то, что уже готово, и отправить Agile-исполнителя гулять восвояси…
Если нормальный человек, который пишет для взрослых людей, напишет «Отступление» или «Отказ от ответственности», то
автор, который держит читателей за толпу уровня школоты, пишет «Дисклеймер».
Сугубо мое персональное мнение.
На начальном этапе 5% специалистов обладают достаточной квалификацией для того чтобы выполнить даже достаточно четкие и адекватно сформулированные требования 20-30% заказчиков.
(10)
А у кого «у них»? У клиента? У внедренца?
Этот промежуточный результат и сроки его наступления закрепляются в договоре или нет? Он имеет предварительно установленную стоимость? Что помешает внедренцу кормить клиента завтраками и получать деньги за этот будущий промежуточный результат, если всего этого нет?
Кто определяет потенциальную пригодность результата к внедрению другим внедренцем? Кто оценивает шансы на то, что другой внедренец не скажет «да тут всю систему менять надо, нагородили тут ерунды всякой, архитектура ни к черту»?
1.Пришел новый дворник. Получил старую метлу в целости и сохранности. Новый дворник «даже крыльцо нормально подмести не может».
Старый дворник не может получить денег на новую метлу потому что старую метлу еще можно подремонтировать, можно собрать хворост на улице и перетянуть шнурками от ботинок или леской от удочки (ну, ты же рыбак..).
2. За что Герасим утопил свое Му-му..
Ситуация такова, что заказчики сейчас требуют аванс/залог от исполнителей. Но поскольку у исполнителей единственный источник дохода — разработка конфигураций, денег нет, то аванс называется функциональная модель или рабочий прототип (опытный образец). Как можно оформить что такая работа это именно аванс разработчика заказчику? Каковы методы оценки ее стоимости в случае передачи функциональной модели третьим лицам? По себестоимости / по стоимости повторной разработки функциональной модели?
(14) Образы красивые, но, если совсем честно, я не совсем поняла, какие именно тезисы статьи они призваны проиллюстрировать..
Например точки зрения «абстрактной бухгалтерии» клиента разработку конфигурации можно определить как нематериальный актив, с достаточно частой модернизацией в момент получения результатов очередного спринта и установленным сроком амортизации.
Амортизация такого актива начинается в момент его промышленной эксплуатации и можно дальше развивать тему различного определения остаточной стоимости разработки на стороне разработчика и заказчика, на случай передачи/продажи разработки третьим лицам и получением дохода третьими лицами от четвертых, пятых, шестых..
Функциональная модель же предполагает что она «как есть» никогда не будет передана в промышленную эксплуатацию. Ее незавершенность есть неотъемлемое и обязательное качество. Так же как и эксклюзивный продуктив в промышленной эксплуатации не может быть «как есть» передан/установлен третьим лицам физически. Если таковое возможно — это не эксклюзивный продуктив, а коммерческая разработка.
Таким образом коммерческую ценность разработки имеют только тогда, когда за них можно и не платить, как это ни парадоксально.
Для меня agile это покупка джинсов на вырост, которые сначала подрезали и подшили, а затем надставляем/расшиваем/ушиваем по мере необходимости. Результат маловероятно будет удовлетворять понятию «бесшовная интеграция». Agile предполагает кроме неопределенности требований еще и экономию на квалификации внедренцев за счет полной смены команды внедренцев на каждом спринте/блоке спринтов и постоянный поиск лучших участников проекта по соотношению цена/качество. Любые технологии к сожалению описывают поведение одной проектной команды. Проблема в том, что количество команд, которые можно привлечь к проекту на каждом конкретном этапе к спринту не бесконечно.
И отношение при каждом обращении клиента к команде разработчиков будет менятся с учетом опыта, полученного в других проектах.
Следует учитывать тот нюанс, что клиент, обратившийся к разработчику в третий раз дважды отказался от его услуг.
(0) сажаете разработчика в отдел — пусть работает на ряду с пользователями — оформляет заявки, отгружает товары, обслуживает клиента, формирует отчетность и т.д. Я только так понимал, что нужно заказчику от системы. При этом большая часть айсберга дорабатывалась уже чисто для удобства работы (в том числе проверки, подсказки, раскраски).
(18)
как жеж так , это ведь подход тупого кодера. А где собственные компетенции в предметной области? Где передовой опыт отрасли? С таким взглядом клиент получить только три мешка говнокода и автоматизацию собственного кондового уклада жизни.
(19) 99% работ делаются без выезда по удаленке — тут и компетенция, и передовой опыт отрасли. про остальное — не могу судить.
(20)
-как Карл ! если
Даже поработав в системе несколько лет Заказчик может не знать чего хочет от системы. Но после запуска нескольких оперативных контуров он может это и узнать.
Опасность в том, что вместо запуска всей новой системы эти части могут быть перенесены в старую и заказчик будет удовлетворен, а проект в целом вернется от внедренцев к поддержке. На agile эта вероятность еще выше.
В качестве страховки можно предложить единовременный запуск оперативных контуров на новой системе и обратную синхронизацию данных с существующей, а для этого потребуется знать существующую систему достаточно хорошо и их поддержка должна будет обеспечить эту синхронизацию со своей стороны.
Кроме того, что список первоочередных задач/багтрек и требования к новой системе опять таки будет составлять и предоставлять поддержка существующей системы. Готовы ли 1с ники взять на себя поддержку например Аксапты полностью на время предпроектного обследования? И если да, то готовы ли они при этом внедрять 1с какую нибудь?
(23)
В Agile вообще по определению выше вероятность того, что проект пойдет не так, как планировалось изначально. Если у нас есть высокая уверенность в том, как делать проект, нам Agile в принципе обычно не нужен, достаточно водопада (ну, или итеративной модели).
(22) Спасибо за столь развернутый и конструктивный комментарий!
Я генерально согласна с вами по существу, только немножко предлагаю уточнить терминологию
Совсем нет! Почитайте идеологов. Скажем, того же Джеффа Сазерленда, автора Скрама. Он вполне себе описывал проект, управляемый по Скрам с единой поставкой в конце. А в конце каждой итерации — те же самые прототипы, про которые вы рассказываете. Это, конечно, хуже, чем много маленьких поставок. Но лучше, чем обсуждение на словах.
Метод водопад + прототипы на разных стадиях проекта совершенно не панацея и не самое лучшее решение.
Мне кажется, что то, что вы описываете как «водопад + прототипы» — это как раз и есть то, что называется итеративный метод — когда мы не пытаемся планировать всю систему на старте целиком, а по итогам изучения прототипов изучаем требования.
См. мою статью
(22)
Мы практически открыто говорим, как бы ни старались, мы промахнемся с реализацией требований, все равно после старта промышленной эксплуатации будут доработки, объективно будут.
Да, и эта схема тоже вполне укладывается в подход Agile. Когда мы на первом этапе выделяем тот функционал, без которого система работать не будет. Налепляем на него минимально осмысленный функционал («walking skeleton») — и это и входит в первую поставку. А дальше у нас много итераций (например, как вы и описываете, в ходе промышленной эксплуатации), когда мы допиливаем уже не критичный функционал.
(23)
Если Заказчик поработал несколько лет и не знает, что хочет от системы, любая методика бессильна.
Разве что концепция «второго» внедрения …
(25)
Марина, то что я называю прототипами как-то многократно пересекается с тем, что Вы описываете, представляя agile.
И хотя все-таки это разные термины, да и инструменты, тем не менее, или при их использовании много общего, или я слишком обширно и нечетко использую понятие прототип.
Наверно возможно прописать некую модель интеграции водопад + прототипы в понимании PMBOK + agile, в ней описать роль и место прототипов, роль и место agile, сделать это отдельно для на стадии сбор требований, затем для стадии разработка.
И вряд ли понятия прототип и agile окажутся смешанными или одной и той же сущностью, например как бэклог окажется сущностью, которой прототип не является.
Может быть agile на этапе сбора требований окажется применимым в качестве инструментария менеджмента, организации групп, а областью бэклог окажется список требований с высокой степенью неопределенности.
А прототип это в данном контексте это некая форсированная разработка (в классическом водопаде преждевременная), но тем не менее уместная в силу низких затрат на голый и полусырой функционал прототипа. И с помощью прототипов будет таять список бэклогов.
Опять же манифесты agile в том месте, где речь о взаимодействии, жизненно необходимы для успешности прототипов в снятии неопределенности требований.
На стадии разработки прототипы и agile могут взаимодействовать уже как-то иначе.
Например все требования могли оказаться собранными очень четко и тогда почти вуаля (для несложных доработок).
С другой стороны, для сложных доработок, а может даже для типового функционала может оказаться важной «преждевременная» (до наступления сроков опытной или промышленной эксплуатации всей системы) «боевая» эксплуатация на примере реального периода работы с реальными данными (1 или несколько дней работы в 2-х системах).
Это важно для фиксации успешности реализации требованиях путем получения достоверной обратной связи от ключевых пользователей поработавших не на бумаге в новой системе.
И для этой стадии вероятно можно расписать менеджмент в духе agile и порядок и процедуры работы с прототипами.
А может быть все проще и в силу того, что среда обитания прототипов и agile оказалась близкой (пи сборе требований), когда Вы Марина описываете agile, я заблуждаюсь, читая слово «прототип» вместо «agile».