Серебряные пули в разработке ПО или как ориентироваться в мире Канбанов, Скрамов и прочих XP

Недавно наткнулся на интересную презентацию на TOCPA про cash-flow driven development http://www.tocpractice.com/page/toc-and-software-development-0#attachments. Презентация содержит много интересного и разбудила во мне мыслительный процесс. Настолько, что я решил вставить свои 5 копеек :-) Просто несколько тезисов - в качестве приглашения к обсуждению - мысли вслух.

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

Про Agile

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

Однако не всегда есть возможность разделить проект на итерации. Представьте себе, что мы строим самолет. Он либо взлетит либо нет. И нет никаких промежуточных результатов.

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

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

Про самоорганизующиеся команды

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

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

Про Канбан

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

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

Разберем о чем я говорю на примере:

Представьте себе, что звено может производить 5  +/-2 детали. То есть в среднем 5. По Канбан мы должны поставить ограничение 5, так как если поставим больше - будет копиться незавершенное производство. Но тогда средняя производительность больше не будет равняться 5. Звено в лучшем случае произведет 5, но произвести 7 уже не сможет.

Почему бы тогда не попробовать вместо Канбан придумать в разработке ПО аналогию с ТОСовским "барабан-буфер-канат"? Он лучше сфокусируется на ограничении.

Про серебряные пули

Так вот мысль в том, что инструмент (или комбинацию инструментов) нужно подбирать под задачу. Любая методика оставляет многие вопросы без ответов. Не стоит относиться к ней, как к священной корове, и молиться на нее, слепо следуя ее предписаниям.

Можно комбинировать Scrum и Канбан. Можно добавлять к ним инженерные техники (например, парное программирование и test driven development) из XP. Для фокусировки на результате проекта использовать CCPM.

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


Замечание:
Для подбора правильных процессов нам нужно понимать свои текущие ограничения. Потому что, как говорит ТОС, действия, не нацеленные на ограничения, не увеличивают результат системы :-)

Пример ограничений в разработке

Ограничения бывают очень нетривиальными и их понимание может привести к неожиданным действиям :-)

Процитирую +Audrius Vasiliauskas

"Я руководил ИТ в 70 программистов, и всегда мы заканчивали 2-3 проекта в месяц. Я долго не мог понять в чем проблема. Оказалось, что deployment это долгое занятия, а у меня не было достаточно хороших программистов-админов. Новых я так и не нашёл - очень дорого. Пришлось менять портфель проектов. Тогда ограничением стали консультанты."