Инженерное мышление в ИТ

IT Skeptic в перерыве между твитами об инаугурации Трампа нашел время поделиться очередной мудростью. Про инженерное мышление в ИТ – распространенное и не сдающее свои позиции, несмотря на 20 лет Agile и бесчисленные тексты про DevOps, заблуждение о том, что ИТ-системы нужно строить так же, как мосты.

«Строительства моста подразумевает, что:

  • Мы предельно точно определим наши требования до сантиметра
  • Затем начертим подробнейшие чертежи с точностью до каждого винтика
  • Затем построим мост в соответствии с чертежами
  • Затем проведем контрольные замеры, подтвердив, что построенный мост полностью соответствует требованиям

Эта песня всем знакома – называется «водопад» (каскадная модель). И сейчас кажется невероятным, что такой путь считался рациональным для построения чего-то настолько сложного, как ИТ-система.

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

Конечно, как многие из вас знают, Agile учитывает эту особенность и представляет разработку ПО как итеративный процесс непрерывного исследования. DevOps расширяет границы применения Agile на весь жизненный цикл систем и услуг, попутно предлагая соответствующий инструментарий. Но инженерное мышление все еще живет в умах многих в мире ИТ, и особенно тяжелые случаи можно видеть как правило в области программного и проектного управления, стратегического планирования. Сохраняте бдительность,»- наставляет Роб.

В комментариях Скептику возражают, что его представления о строительных проектах немного устарели – мол , и там давно хватает экспериментов и итеративного подхода, особенно когда используются новые методы или материалы. А проблема вовсе не в инженерном мышлении ИТ-специалистов, а значительно шире – в ошибочном применении методов производства к R&D-задачам ради экономической эффективности. В ИТ это становится большой проблемой, так как в ИТ много R&D .

Какие мосты возводили в ИТ вы? 

Напоминаем вам о том, что сразу две книги Роба Ингланда до конца февраля можно приобрести со скидкой 30%.

The Phoenix Project Основы DevOps

Новый учебный курс 2017
 

Проект Феникс — DevOps на практике

Новая деловая игра от GamingWorks
 

Комментарии и мнения

  1. Сергей

    По моему скромному опыту — жадные, недоверчивые, возможно старые, в основном, гос-заказчики, не признают ничего кроме жестких проектов — разработка по каскадной модели — здесь объясняется жесткими планами и отчётностями (жаг влево-вправо для них — это попытка коррупции). Более продвинутые готовы работать как по проектным моделям-каскадной разработке, так и по гибким методологиям. Здесь объясняется просто — проект — это отдельный договор с какой-то ценой. Разработки улучшений идут или скопом (в рамках договора пост-фактум всё аггрегируется в один документ) или в рамках тех поддержки (не в классическом понимании, а именно как доп.разработки по запросам). С первым типом заказчиков — всё ясно, опыт описывать не интересно. А вот со вторыми так: обычно внедряется стандартное решение с небольшими доработками (предварительно может быть пилот), затем, определённое время выполняют мелкие доработки в рамках тех поддержки — т.к. заказчик закупает пул часов (они могут по всякому расходоваться или сгорать). Через определённое время зреет крупная модификация — всё собирается и описывается в рамках тех.поддержки, а уже сама деятельность стартует в виде проекта(отдельного догора). После идёт развитие.

    Вот так и получается сочетание Waterfall и Agile в рамках одного заказчика

  2. Андрей другой

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

    1. Илья Рунов

      Андрей, где найти упоминание, что Agile отрицает нормальную документацию, которая описывает "что надо сделать"? Здесь http://agilemanifesto.org/iso/ru/manifesto.html мне найти не удалось. Я текст прочел так, что при выборе между работающим продуктом с неисчерпывающей документацией и неработающим продуктом с исчерпывающей документацией следует выбирать первый вариант. Может быть я не так понял авторов манифеста.

      1. Олег Скрынник

        Рискую начать очередной холивар (который, сразу хочу оговориться — не поддержу), но считаю важным заметить: то, что сейчас буквально на наших глазах делают Tesla и SpaceX настолько близко к Agile (на мой субъективный взгляд), что космос в пример "сильно-много подумали, затем удачно запустили" приводить как-то не уместно.

  3. Илья Рунов

    Вот я бы сузил задачу с постройки ракеты до создания программно-аппаратного комплекса контроллера управления двигателем луно(марсо)хода. Так интереснее было бы "наблюдать" итеративное развитие продукта уже после запуска ракеты с луноходом.

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

    1. Олег Скрынник

      Некоторое время назад я читал издание о космонавтике. "Российский космос", наверное, не помню уже. Там публиковали журнал, который вели наши космонавты на МКС. Очень любопытно и поучительно.

      Могу сказать одно: большинство из тех, кто рассуждает о космосе, понятия не имеет как там весело всё устроено 🙂

      И с софтом, и с железом, и с доставкой до станции, и с косяками разработчиков.

      Один вопрос у меня остался: как оно вообще летает?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
26