Как же обмануть Железный Треугольник?

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

Вот три устоявшихся стереотипа, которые я стараюсь изменить:

Cначала нужно получить требования, а потом уже проектировать; сначала проектировать, а уже потом писать код.

Лучше описывать все подробно, чем делать приблизительные наброски и обсуждать их.

Людям лучше работается в изолированных рабочих помещениях.

Давайте заменим эти правила на другие:

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

Кратко и быстро отражать основные моменты разработки в документации и не забывать сопровождать документацию живым общением.

Дать всем возможность работать в одном помещении.

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

Моя статья слишком мала, чтобы описать все стратегические и тактические приемы, которые они используют. К тому же, об этом можно прочесть в нескольких книгах: "Managing the Design Factory", "Skunk Works", "Theory of Constraints", "Lean Software Development", "Agile Software Development", и "Agile Management for Software Engineering.

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

Содержание раздела