Правила или общепринятые практики Скрам

Автор: Майк Кон (Mike Cohn)

В одной из мартовских заметок своего блога, я ввел термин, который в то время пробовал ввести в обсуждениях и некоторых классах. Термин был “GASP” и расшифровывался как общепринятая практика Скрам (англ. Generally Accepted Scrum Practice). В чем я сейчас действительно заинтересован и, надеюсь, вы мне в этом сможете помочь, так это создать список всех общепринятых Скрам-практик которые мы знаем.

Но сначала нужно более формально определить, что же такое общепринятая Скрам-практика. Вот мое определение:

Общепринятая Скрам практика (GASP) это активность, осуществляемая многими, но не обязательно всеми Скрам-командами. Команда, которая не придерживается практик, все еще может считать, что она работает по Скраму. То есть, что-то вроде “работа в коротких, ограниченных по времени, не более чем на календарный месяц, итерациях” не есть общепринятая Скрам-практика. Это, скорее, правило Скрама. Чтобы считаться GASP, практика должна быть «общепринятой» – как хорошая идея. В качестве рабочего определения, я использую “каждая Скрам-команда должна быть осведомлена о практике, но некоторые команды могут обоснованно принять решение не следовать этой практике, зачастую предпочитая использовать что-то подобное.”

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

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

Таким образом, чтобы стать общепринятой Скрам-практикой, она должна стать чем-то большим, чем просто хорошей многообещающей идеей. Эта идея должна быть чем-то, что достаточное количество команд практикует, только в таком случае мы можем назвать практику “общепринятой”. Я хочу предложить, считать практику “Использования пользовательской истории как элемент Продакт Беклога” общепринятой. Я думаю, что практика использования историй, безусловно, оправдала свою целесообразность, как практика ведения Беклога Продукта. Но должна ли команда работать с пользовательскими историями, чтобы считалось, что она работает по Скраму? Конечно, нет. Но я уверен, что пользовательские истории настолько широко распространены, что команда должна знать что они из себя представляют, прежде чем отказываться в пользу чего-то лучшего.

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

Итак: как вы думаете, что является общепринятой Скрам-практикой? А что – Скрам правилами?


Залишити коментар
Будь ласка, введіть ваше ім’я
Будь ласка, введіть коментар.
1000 символів

Будь ласка, введіть email
або Відмінити

Інші статті в категорії IT, програмування, розробка Project management, управління проектами Лідерство, тімбілдинг