В дебрях водопада

[vit_r]

Раз cross_join выпытывает про три уровня, напишу немного подробнее.

Agile в изначальной концепции - это просто возможность адаптации процессов к команде, задачам и условиям.

Cockburn в «Agile Software Development» называет это третьим уровнем. (Насколько хороша книжка по Use Cases, настолько тупа книжка про Agile. Но иногда встречаются просветы вроде этих трёх уровней.)

Первый - это просто карго-культы.

Второй - это, когда приходит понимание, что карго-культы не работают и надо подстраивать их под реальность.

Естественно, у него это сформулировано по-другому, потому что он гуру и продаёт консультации. А про уровни, скорее всего, добавил для отмазки, на случай если серебряные пули не сотворят чуда. Точнее, если отсутствпие волшебного действия поймут осчастливленные новой мудростью.

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

Но в ИТ психологию никто не знает, все рассказывают, что мозги похожи на компьютер, токарный станок или сборочный конвейер. (При этом гуры плохо понимают, как это всё на самом деле внутри работает. Включая и компьютер.)

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

Любой процесс в какой-то мере водопад. По крайней мере, когда деньги кончаются, игра завершается.

Любой процесс в какой-то мере спираль. Потому что никогда ничего не бывает готовым абсолютно полностью и совершенно без ошибок. Даже межпланетным аппаратам, летящим в космическом пространстве, дописывают софт.

Любой процесс в какой то мере agile (в изначальном понимании). Потому что делать всё формально и с полной документацией - это никаких ресурсов не хватит. Да и просто делать в объёмах, прописанных профессорами от софтостроения, занятие недешёвое и не очень осмысленное. Судьба Мотороллы тому наглядный пример.

Любой «agile process» на самом деле не очень agile, а часто и совсем не agile. Просто по определению.

По сути дела, стремиться надо не туда, а к пятому уровню по Crosby’s Quality Management Maturity Grid. Как туда идти в ИТ можно почитать у Gerald M. Weinberg в «Quality Software Management». Он не во всём прав, но прав во многом.

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

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

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

Comments

[yajohn.livejournal.com]

> Дальше надо книжку писать толстую.
Напиши-напиши. Будет еще одна серебряная пуля. Даже если книга будет называться "почему не бывает серебряных пуль".

[esc.livejournal.com]

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

[vit-r.livejournal.com]

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

А модные технологии создаются в основном переписыванием старых книжек. Причём, то, что писали профессионалы, переписывают профессора, никогда в жизни не державшие в руках живого кода. Тем более, не опускающиеся то того, чтобы поговорить с практиками по душам.

Те же пять уровней CMMI выросли из пяти уровней Crosby. Только люди уже не понимали, как это работает в реале, зато добавили много наукообразных слов.

[cross-join.livejournal.com]

Три круга ада :)
В итоге все-таки нормальная адаптированная спиральная метода.

[vit-r.livejournal.com]

Нету "спиральной методы". Есть спиральная модель.

Модель - это просто способ предсказания и ничего больше.

[cross-join.livejournal.com]

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

[vit-r.livejournal.com]

Адаптивная методика - это любая методика, которая оценивает изменение обстановки и подстраивается под неё. Спираль - это просто свёрнутые в трубочку интервалы между измерениями.

Смысла в этом названии нет, просто картинки красивые.

[vit-r.livejournal.com]

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

[cross-join.livejournal.com]

В спиральной модели на каждом витке прототип выбрасывают (целиком или частями) и делают новый.

[vit-r.livejournal.com]

Слово "частями" может иметь очень разные значения.

По сути дела спираль - это свёрнутые в трубочку маленькие водопады. То есть, опять не учтены короткие циклы.

[cross-join.livejournal.com]

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

[vit-r.livejournal.com]

Тут такое дело, что в адаптивной модели в любой момент можно "маленький водопад" прервать и сесть думать, что делать дальше, или растянуть, или перекроить.

Модель спиральная этого не учитывает, потому что этапы завязаны не на качество, а на время.

[cross-join.livejournal.com]

А смысл прерывать не закончив витка? Тогда не всем будут ясны причины, включая ощупывающего прототип заказчика.

[vit-r.livejournal.com]

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

Ладно, я на этом останавливаюсь, а то уже начался слив секретной информации.

(Естественно, модель называется не адаптивной, потому что это просто прилагательное.)

[cross-join.livejournal.com]

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

[vit-r.livejournal.com]

Если в кастрюле обнаружена крыса, нужно выливать всё на помойку, брать другую кастрюлю и готовить по-новой, а не доваривать суп, чтобы отправить его на дегустацию.

[cross-join.livejournal.com]

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

[vit-r.livejournal.com]

Если это на самом деле крыса и она обнаружена без функциональных тестов, проблем никаких нет.

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

[cross-join.livejournal.com]

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

[vit-r.livejournal.com]

Новые требования могут вылезти только в начале витка.

Нет, конечно. Иначе это не требования, а бесполезные бумажки.

[cross-join.livejournal.com]

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

[vit-r.livejournal.com]

Не надо подстраивать жизнь под модель. Ни к чему хорошему это не приводит.

[cross-join.livejournal.com]

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

[vit-r.livejournal.com]

Модель - это модель. Если она не подходит к реальности, её надо отбрасывать.

[cross-join.livejournal.com]

Отбрасывая, переходят к другой модели. Пока что все крутятся вокруг трёх названных выше (каскадная, циклическая и спиральная).

[vit-r.livejournal.com]

Не надо зацикливаться на моделях. Если никакая модель не подходит, планирование и управление производят по интуиции. Это лучше, чем залипать на неработающую модель.

[cross-join.livejournal.com]

Работать, не зная моделей - это называется кейс. Можно и по кейсам, своим или чужим.

[vit-r.livejournal.com]

Модель всегда есть. Просто не всегда есть название. Даже не всегда осознаётся.