One Scrum Process Story (in Russian)
Алекс Атемасов и Макс Колодезный
О чем это все?
Многие, особенно незнакомые со Scrum люди, часто обращают внимание на технические подробности методологии. Возможно, для начинающей команды это и правильно. Но по прошествии полугода работы, Scrum перестает быть в новинку, чем-то особенным, и становится обыденностью. Хорошей, но обыденностью. И тут очень важную, если не главную, роль в успехе команды будет играть ее психология, философия Agile. Это касается как команд, у которых Scrum идет не так как надо (что и так понятно), и как ни странно вполне успешных и процветающих коллективов. В этой статье попробуем изложить некоторые проблемы, с которыми могут столкнуться команды, имеющие подобный опыт. Как можно, и как хотелось бы их решать. А также какую роль в этом должны/могут играть Scrum Master и Product Owner. Будем рассматривать уже словжившиеся команды, которые прошли, так называемую, стадию кристаллизации и представляют из себя сплоченый коллектив. С оглядкой на наш личный опыт.
Кто есть кто?
Product Owner (РО) — полноценный член команды, задачами которого являются разработка бизнес-требований к проекту и распространение этих требований среди всех членов команды. Также, одними из основных задач РО является составление чёткого «How to Demonstrate» на каждом планировании спринта, составление и приоритезация беклога с точки зрения бизнеса. Во время спринта РО должен поддерживать тесную связь с командой для своевременного уточнения реализации стори в соответствии с бизнес-требованиями. Если такая связь отсутствует — команда (ведь она состоит из разработчиков, в широком смысле этого слова — интерфейса, дизайна, кода, вёрстки) может сосредоточить внимание на реализации тех или иных вещей, которые по её мнению являются более приоритетными и важными, нежели это заложено в business-value.
Scrum Master (SM). Трактовка данной роли может быть весьма различной. Некоторые считают его аналогом Project Manager, другие видят в нем того, кто должен пинками собирать команду на Daily Meeting, третьи думают, что он обычный TechLead. Не соглашусь ни с одними. В первую очередь, Scrum Master должен заботиться о том, чтобы команду ничего не отвлекало от непосредственной разработки продукта. Все внешние раздражители, техническая недоукомлектованность, если в офисе нет чая, кофе, туалетной бумаги — это дела Scrum Master'a. Начальник решил вставить свои пять копеек в работу команды — к Scrum Master'у. Product Owner захотел поменять задачи по ходу спринта — SM должен встать поперек и доходчиво объяснить, что так нельзя. И так далее, и тому подобное. Куда сложнее с внутренними проблемами. Проблемами внутри самой команды. Тут уже нужны освершенно другие человеческие качества. Хорошему SM будет в плюс, если он является хорошим психологом, экстравертом. В идеале SM должен не решать проблеемы, а упреждать их.
Scrum Member. Основным свойством Scrum Member'a есть кроссфункциональность. Но… Дизайнер, верстальщик, программист, СЕО-оптимизатор, администратор… Человек-оркестр. Дорогой человек-оркестр… Непродуктивный человек-оркестр. Может быть очень узким местом.Также, каждый отдельно взятый член отдельно взятой команды должен понимать и принимать основные принципы Scrum идеологии, следовать им не по принуждению, а по собственному убеждению. Этот факт является залогом здорового внутреннего командного климата и рабочего процесса. Команда в целом и каждый её участник в частности должны понимать цели продукта и видение этого продукта самим РО, прикладывать все возможные усилия для достижения этих целей.
(По мотивам презентации «One Scrum Process Story» от 12.06.2010)