Раз
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». Он не во всём прав, но прав во многом.
Настоящее надёжное управление получается не от того, что выполняются какие-то предписания, а когда люди понимают, что и зачем делают, могут это измерять, предсказывать и контролировать. В том числе, предсказывать и контролировать случайные параметры, недостаток информации и общую неопределённость.
Контроль, естественно, понимается не с точки зрения отчётности, а как способность адоптировать реальные процессы, метрики, способы измерения, цели, задачи и прочее.
На этом всё. Дальше надо книжку писать толстую. Причём, не пересказывающую упомянутые и не упомянутые источники, а только на них базирующуюся.
