Scrum или Kanban

scrum-process-01

Нашел в сети неплохую методичку Хенрика Книберга и Маттиаса Скарина «Scrum или Kanban: выжимаем максимум» про различия и сходства этих двух методов разработки. Вспомнил Саныча. Рассказ не про него, но про него тоже.

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

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

Как и любая методология разработки, scrum, kanban, RUP, XP, хрен-знает-что-еще, это все бизнес-процессы. На входе у них требования, на выходе — работающее ПО. А еще у процессов бывают показатели производительности, которые межарабль и аттейнебля. Например, скорость разработки — сколько фич выпустили за период времени. И если мне кто-то говорит, что «пацаны, давайте заменим ваше говно вашу методологию разработки на нормальный scrum», я всегда задаю вопрос «базара нет, насколько гарантируется увеличение эффективности и по каким показателям»? Но с Санычем я попал впросак. То ли он не понял слова «показатели увеличения эффективности», то ли ему слишком рано пришло на помощь руководство и сказало, что я ничего не понимаю в процессах разработки.

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

И тут вот как раз кроется один нюанс, о котором забывают практически все. Любая методология — это тоже самое, что и рецепт приготовления блюда. Рецепт не может существовать сам по себе, необходимы ингредиенты. И у каждого рецепта они свои, иначе блюдо получится так себе. Нельзя просто так взять и начать применять скрам или канбан. Нужно собрать необходимые ингридиенты. Важным ингридиентом для скрама является осознанность разработчиков. Скрам не дает результатов, если разработчики не обладает достаточным уровнем осознанности с точки зрения достижения целей итераций. Скрам не работает, когда поток задач представляет собой огромное количество микроизменений, которые планировать дольше, чем решать, и которые возникают ситуативно. Методология подбирается под экосистему разработки, а не наоборот. Иначе нужно менять эту экосистему.

Но Саныч вещал об ином. Санычу нужно было продать. Саныч продал.