IT Skeptic в перерыве между 
твитами об инаугурации Трампа нашел время поделиться очередной мудростью. Про инженерное мышление в ИТ – распространенное и не сдающее свои позиции, несмотря на 20 лет Agile и бесчисленные тексты про DevOps, заблуждение о том, что ИТ-системы нужно строить так же, как мосты.
«Строительства моста подразумевает, что:
- Мы предельно точно определим наши требования до сантиметра
- Затем начертим подробнейшие чертежи с точностью до каждого винтика
- Затем построим мост в соответствии с чертежами
- Затем проведем контрольные замеры, подтвердив, что построенный мост полностью соответствует требованиям
Эта песня всем знакома – называется «водопад» (каскадная модель). И сейчас кажется невероятным, что такой путь считался рациональным для построения чего-то настолько сложного, как ИТ-система.
В ИТ мы всегда затрудняемся точно определить, что именно строим, сколько средств для этого потребуется и сколько времени займет. Реальность такова, что каждый ИТ-проект – это упражнение в экспериментировании и усваивании уроков из ошибок: так уж работают сложные системы. В результате, каждому успешно реализованному ИТ-проекту неизбежно предшествует череда неудач. Мы никогда не строим ровно то, что спроектировали, и мы редко сохраняем определенный первоначально охват проекта.
Конечно, как многие из вас знают, Agile учитывает эту особенность и представляет разработку ПО как итеративный процесс непрерывного исследования. DevOps расширяет границы применения Agile на весь жизненный цикл систем и услуг, попутно предлагая соответствующий инструментарий. Но инженерное мышление все еще живет в умах многих в мире ИТ, и особенно тяжелые случаи можно видеть как правило в области программного и проектного управления, стратегического планирования. Сохраняте бдительность,»- наставляет Роб.
В комментариях Скептику возражают, что его представления о строительных проектах немного устарели – мол , и там давно хватает экспериментов и итеративного подхода, особенно когда используются новые методы или материалы. А проблема вовсе не в инженерном мышлении ИТ-специалистов, а значительно шире – в ошибочном применении методов производства к R&D-задачам ради экономической эффективности. В ИТ это становится большой проблемой, так как в ИТ много R&D .
Какие мосты возводили в ИТ вы?
По моему скромному опыту – жадные, недоверчивые, возможно старые, в основном, гос-заказчики, не признают ничего кроме жестких проектов – разработка по каскадной модели – здесь объясняется жесткими планами и отчётностями (жаг влево-вправо для них – это попытка коррупции). Более продвинутые готовы работать как по проектным моделям-каскадной разработке, так и по гибким методологиям. Здесь объясняется просто – проект – это отдельный договор с какой-то ценой. Разработки улучшений идут или скопом (в рамках договора пост-фактум всё аггрегируется в один документ) или в рамках тех поддержки (не в классическом понимании, а именно как доп.разработки по запросам). С первым типом заказчиков – всё ясно, опыт описывать не интересно. А вот со вторыми так: обычно внедряется стандартное решение с небольшими доработками (предварительно может быть пилот), затем, определённое время выполняют мелкие доработки в рамках тех поддержки – т.к. заказчик закупает пул часов (они могут по всякому расходоваться или сгорать). Через определённое время зреет крупная модификация – всё собирается и описывается в рамках тех.поддержки, а уже сама деятельность стартует в виде проекта(отдельного догора). После идёт развитие.
Вот так и получается сочетание Waterfall и Agile в рамках одного заказчика