Agile-методологии разработки отличаются от “водопада” объемом того, что находится в работе в каждый конкретный момент времени. Для водопада - это вся разрабатываемая система в целом, каждый этап работ осуществляется для всей системы. Поэтому работа в водопаде - это разовая активность, это разовый проект с четкими этапами, началом и концом. Agile же взял на вооружение принцип уменьшения размера “партии” и применил все этапы работы к небольшой части функциональности, а не ко всей системе в целом.
Собственно, операционные менеджеры автомобильных производств заметили это еще в 1970-х годах, ЕМНИП. “Цель” Голдратта хорошо иллюстрирует результаты уменьшения размера партии, переход от мышления в рамках большого заказа целиком к мышлению в рамках небольшой партии заказанных деталей. В физическом производстве этот переход позволил уменьшить запасы, высвободить денежные средства из оборота и в целом повысить эффективность работы.
Говоря об Agile, сложно не вспомнить XP - экстремальное программирование. Напомню главный принцип: если какая-то практика хороша и полезна, то нужно использовать ее на 100%. Например, если код-ревью - это хорошо, то нужно проводить его в каждый момент работы над кодом, например, с помощью парного программирования. Так вот, если этот принцип применить и к определению размера “единицы работы” команды разработки, то что получится? Если маленький объем партии (читай, истории или реализуемой функциональности) - это хорошо, то нужно предельно минимизировать скоуп каждой “единицы работы”.
И вот тут возникает серьезный вопрос. Каков этот предельно минимальный размер “единицы работы”? Он явно должен быть чем-то ограничен снизу, а к этой самой “единице работы” явно должны выдвигаться какие-то требования. Иначе можно минимальной “единицей работы” считать изменение одного символа в исходном тексте программы, но мы же понимаем, что это не то, по крайней мере, это не общий случай (некоторые глупые баги требуют изменения именно одного символа).
Я пока не могу найти ответа на этот вопрос. Подумал о том, что для историй предлагаются критерии INVEST1, но вскоре понял, что это скорее “проверочные вопросы” к формулировке истории в целом, а не эвристика для направленного движения к минимальному размеру истории. Еще есть разной степени подробности инструкции по уменьшению размера истории, но они не предлагают никаких критериев, в основном говорят, что если вы прошлись по всем шагам инструкции, то дальше уменьшить историю нельзя (а так ли это на самом деле?).
В целом, вопрос можно сформулировать так: На основании каких принципов или правил можно гарантированно определить минимальный размер единицы работы для команды разработки? Если у вас есть какие-то идеи по этому поводу - давайте обсудим.