Закоулки мозга

Микропроекты в продуктовой разработке

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

Меня заинтересовала эта разница между проектом и продуктом: Продукт vs Проект. Направлений “на подумать” несколько, например, можно ли говорить о том, что завершение проекта - это начало продукта (то есть, закончили работы, вывели в эксплуатацию, теперь нужно поддерживать и развивать).

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

Я уже как-то вскользь упоминал о том, что Agile - это много маленьких “водопадиков”, потому что стадии жизненного цикла разработки местами поменять ну никак не получится - не выйдет же протестировать то, что еще не написано, верно? Ну и реализовать в коде то, что еще не сформулировано в виде описания системы, тоже. В общем, мы все равно выполняем все работы последовательно, просто на более мелком масштабе. Раньше рассматривали всю систему целиком, а сейчас концентрируемся на небольшом кусочке функциональности за раз. Оптимальный размер истории в разработке ПО.

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

И вот тут я вспомнил Райнертсена и его книгу (так и не дочитал, каюсь) Principles of Product Development Flow. Опять же в самом начале там сформулированы критичные проблемы современной разработки продуктов, и среди них есть “Неэкономические способы контроля потока работы”.

В качестве решения этой проблемы Райнертсен предлагает использовать показатель CoD (cost of delay, стоимость задержки) и в первую очередь реализовывать те проекты/действия, у которых стоимость задержки максимальна.

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

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