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

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

— Нет, однако должен выполняться ряд пререквизитов. Для удобства можно пользоваться Методикой Ситуационного Контекста.

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

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

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


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

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

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

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

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

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

— Можно и нужно. Опытные руководители проектов применяют практики постоянных улучшений в своей деятельности, извлекают уроки из проектов: завершённых или текущих, своих или чужих.

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

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

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

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

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

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

— Нет. Это прекрасная альтернатива, более эффективная в рамках своих границ применимости. На момент написания в 2022 году этой статьи по итогам опросов института PMI "Pulse of the Profession®" оказалось, что огромное количество организаций продолжает успешно реализовывать инициативы традиционным проектным подходом и даже не собирается переходить на иные подходы рождения ценности или реализовывать "agile-трансформацию" своих компаний. В ряде индустрий гибкое производство вовсе невозможно, не добавляет стоимости или добавленная стоимость "не стоит свеч".

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