September 25th, 2014

vit_r

Про мангу и мангу

Панель читается по-японски справа налево.
Eroge no Taiyou Ch 04 P 007_crop_small

Обнаружена производственная драма про ИТ.

Eroge no Taiyou

Да, про игры. Да, про эти самые. Скопирачено пять первых глав. Процесс передан прекрасно.

Но специфика.

Не скажешь «Дети, вот это то, чем папа занимается». Хотя, в метафорическом смысле действительность описывается и наглядно, и поразительно точно.
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». Он не во всём прав, но прав во многом.

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

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

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