Особенности Разработки программного обеспечения (ПО) в том, что это чистая "Визуализации Идеи". А значит 5% изменений могут полностью изменить логику системы. И любые изменения системы меняют архитектуру системы.

Ниже я прокомментирую некоторые принципы Agile-манифеста (agile-manifesto.org) и как их следует адаптировать к своей среде.

Принцип отсутствия архитектуры

Если нет описанной архитектуры программной системы и описанной стратегии её изменения, архитектура будет меняться чаще, чем хотелось бы. А если она меняется, то затраты на её изменения будут расти.

О принципах Agile-манифеста

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

Тут необходимо адаптировать к своей среде.

Относительно принципа:

Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев

Следует учитывать что:

1. Это применимо ТОЛЬКО в программному обеспечению.
2. Это возможно ТОЛЬКО при продуманной и адаптивной архитектуре со стратегией развития "что если".
3. Если не будет продуманной архитектуры, стоимость изменений будет возрастать и постоянный темп поставки будет недостижим.

Это означает что:

1. Для производства Аппаратного обеспечения темп поставки 1-2 месяца НЕВОЗМОЖЕН в силу длинного цикла проектирования, моделирования, производства.
2. Проектирование нужно ВСЕГДА, каждый день нужно уделять время проектированию БУДУЩЕЙ архитектуры и обработке изменений, и приводить текущий код в рамках текущих задач к новой архитектуре не забывая о решении текущих задач Клиента.

Относительно принципа:

- Работающий продукт - главный показатель прогресса

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

Какие же проблемы у них есть:

1. Одна из проблем крутых разработчиков софта - "сейчас все-всё спроектируем, потом всё-всё сделаем", то есть любят уходить в долгое проектирование, при том что сама архитектура без кода это только "наверное сработает", а как только начинается реализация, то архитектура меняется и её нужно адаптировать. Редко кто может удержать всю систему в голове, какие детали забываются и теряются, а они могут оказать влияние
2. Вторая проблема: "Нужно все переписать это займет 3 месяца" - тут бизнес тоже не понимает "нафига это нужно".

А следуя принципу "работающий продукт" можно обеспечить постоянный темп и "небольшие и приемлемые изменения"

Итого

Поэтому вышеприведенные принципы для "Аппаратного обеспечения" и "Конструкторских изделий" ( "ЖЕЛЕЗА" ) не применимы в чистом виде. Для "ЖЕЛЕЗА" - это НЕ значит обязательность поставки в формате полуфабриката. Это значит, что результат работы должен быть ВИДЕН и его можно измерить. И Заказчик понимает "этот самый прогресс" создания Продукта.

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