Роли в Скраме
В Скраме всего три роли: Владелец Продукта, Команда и Скрам-мастер. Вместе они известны, как Скрам-команда.
Владелец Продукта (Product Owner, PO) несёт ответственность за максимизацию возврата на инвестиции (ROI) путём определения новой функциональности для продукта, перевода её в приоритизированный список, решая, что должно быть сверху этого списка на следующий Спринт, и непрерывной реприоритизации и прояснения этого списка. Владелец продукта несёт ответственность за доходы и расходы (PNL, profit and loss) продукта, если это коммерческий продукт. В случае внутреннего продукта в компании Владелец продукта не несёт ответственность за ROI в смысле коммерческого продукта (который генерирует доход), но на нём всё же лежит ответственность за максимизацию ROI в смысле выбора - каждый Спринт - самых ценных элементов. На практике, ‘ценность’ является нечётким термином, поэтому на приоритизацию могут влиять: желание удовлетворить ключевых клиентов, соответствие стратегическим целям, снижение рисков, улучшение и ряд других факторов. В некоторых случаях Владелец Продукта и клиент один и тот же человек; это обычная практика для внутренних приложений. В других случаях клиентами могут быть миллионы человек с разными потребностями, поэтому тут роль Владелец Продукта похожа на должность Менеджера Продукта (Product Manager, PM) или Менеджера по Маркетингу (Product Marketing Manager) в разных организациях. Однако Владелец Продукта — это нечто отличное от традиционного Менеджера Продукта, потому что он активно и часто взаимодействует с Командой, приоритизирует, учитывает мнения всех заинтересованных лиц (stakeholders, SH), и делает обзор результатов каждый Спринт, а не делегирует решения по разработке Менеджеру Проекта (Project Manager, PM). Важно отметить, что в Скраме один и только один человек, который играет эту роль - и несёт полную ответственность за продукт - Владелец Продукта, и он(а) ответственны за ценность работы; хотя этому человеку не обязательно работать в одиночку.
Команда (Team), официально называемая Командой Разработки (Development Team, DT), создаёт такой продукт, на какой указывает Владелец Продукта: приложение или веб-сайт, например. Команда в Скраме “кросс-функциональна” - она содержит все виды экспертизы, необходимые для поставки потенциально готового продукта каждый Спринт - она “самоорганизованная” (самоуправляемая), с высокой степенью автономии и ответственности. Команда решает, как много элементов (из предложенного Владельцем Продукта набора) взять в разработку в Спринте, и как лучше всего это сделать.
Каждый член Команды просто член команды. Заметьте, что в группе, которая внедряет Скрам, нет четких должностей; здесь нет бизнес-аналитика, нет администратора баз данных, нет архитектора, нет тимлида, нет UX/UI-дизайнера, нет программиста. Они работают вместе в течение каждого Спринта любым способом, подходящим для достижения цели, которую они поставили перед собой.
Поскольку есть только члены команды, Команда не только является кросс-функциональной, но также демонстрирует множественное обучение (multi-learning): каждый человек, безусловно, имеющий более сильные стороны в определённой области, также продолжает изучать и другие направления. Каждый человек имеет первичные, вторичные, и даже третичные навыки, что означает “следуй туда, где есть работа” (go to where the work is); он берёт на себя задачи в менее знакомых ему областях, чтобы помочь завершить элемент полностью. Например, человек с первичными навыками в дизайне мог бы иметь вторичный навык в автоматизации тестирования; кто-то с первичными навыками в написании технической документации мог бы также помочь с анализом и написанием кода.
Команда в Скраме состоит из 7 плюс/минус 2 людей, и для программного продукта Команда могла бы включать людей с навыками аналитики, разработки, тестирования, проектирования интерфейсов, проектирования баз данных, архитектуры, документации, и так далее. Команда развивает продукт и предоставляет идеи Владельцу Продукта, как сделать продукт лучше. В Скраме, Команды более продуктивны и эффективны, если все её члены на 100 процентов выделены на работу в одном продукте в течение всего Спринта; Команда избегает многозадачности в нескольких продуктах или проектах, чтобы предотвратить увеличение их стоимости из-за рассеянного внимания и переключение контекста. Стабильные команды достигают высокой продуктивности, поэтому избегайте смены членов Команды. Продуктовые группы с большим количеством людей могут организоваться в несколько Команд, каждая из которых может концентрироваться на разной функциональности продукта, с тесной координацией их совместных усилий. Как только одна команда начинает постоянно делать всю работу (планирование, анализ, программирование и тестирование) в задачах, ориентированных на конечного клиента, то такую Команду называют фиче-командой.
Скрам-мастер (Scrum Master, SM) помогает продуктовой группе изучить и внедрить Скрам для получения бизнес ценности. Скрам-мастер делает всё, что в его власти, чтобы помочь Команде, Владельцу Продукта и организации быть успешными. Скрам-мастер не является руководителем членов Команды или менеджером проекта, тимлидом или их представителем. Вместо этого, Скрам-мастер служит Команде; он(а) защищает Команду от внешнего воздействия, помогает устранить препятствия и внедрить современные инженерные практики. Он(а) учит, тренирует и наставляет Владельца Продукта, Команду и всю остальную организацию в правильном использовании Скрама. Скрам-мастер — коуч и учитель. Скрам-мастер удостоверяется, что все (включая Владельца Продукта и менеджмент) понимают принципы и практики Скрама, и он помогает вести организацию через зачастую трудные изменения, необходимые для успеха в гибкой разработке ПО. Поскольку Скрам делает заметными множественные препятствия и угрозы эффективности Команды и Владельца Продукта, то важно иметь вовлечённого Скрам-мастера, энергично работающего над разрешением данных проблем, иначе Команде и Владельцу продукта будет сложно добиться успеха. Скрам-мастер должен быть выделенной ролью на постоянной основе, однако в маленькой Команде член команды может играть его роль (неся при этом меньшую нагрузку из регулярной работы). Великие Скрам-Мастера могут иметь любой опыт или специализацию в прошлом: Инженерия, Дизайн, Тестирование, Продуктовый Менеджмент, Менеджмент Проектов или Менеджмент Качества.
Скрам-мастер и Владелец Продукта не могут быть одним и тем же человеком, потому что их фокусы настолько различны, что часто их совмещение ведёт к путанице и конфликтам. Одни из нежелательных результатов совмещения этих ролей проявляется в микроменеджменте (micro-managing) Владельца Продукта, что противоречит самоуправляемости команд, которую требует Скрам. В отличие от обычного менеджера Скрам-мастер не говорит людям что делать и не назначает им задачи - он фасилитирует [англ. facilitate, помогает чему-то случиться, прим. переводчика] процесс, поддерживают Команду в её самоорганизации и самоуправлении. Если в прошлом Скрам-мастер занимал руководящую должность в Команде, он должен в значительной степени изменить своё мышление и стиль взаимодействия, чтобы Команда была успешна в Скраме.
Замечание: В Скраме в принципе нет роли менеджера проекта. Потому что она не нужна; традиционные обязанности менеджера проекта разделены и распределены между тремя ролями в Скраме, в большей степени Команде и Владельцу Продукта, нежели Скрам-мастеру. Работа по Скраму вместе с менеджером проекта указывает на полное непонимание Скрама, что приводит к конфликту ответственности, неясным полномочиям, и неоптимальным результатам. Иногда (экс-)менеджер проекта может вступить в роль Скрам-мастера, но успех в этом случае сильно зависит от индивидуальных особенностей, и того, насколько хорошо он понимает фундаментальные отличия между двумя ролями, как в повседневных обязанностях, так и в образе мышления, необходимом для успеха. Хороший способ полностью понять роль Скрам-мастера и начать развивать основные навыки, необходимые для успеха - это посетить тренинг Сертифицированный Скрам-мастер (Certified Scrum Master, CSM) от компании Scrum Alliance.
В дополнение к этим трём ролям также существуют заинтересованные лица, которые делают вклад в успех продукта, включая руководителей, клиентов и конечных пользователей. Некоторые заинтересованные лица, такие как функциональные руководители (например, руководители инженеров), могут обнаружить, что их роль, хотя и не перестаёт быть ценной, меняется при переходе на Скрам. Например:
- они поддерживают Команду, уважая правила и дух Скрама
- они помогают убирать препятствия, которые Команда и Владелец Продукта обнаружили
- они предоставляют свой опыт и экспертизу
В Скраме люди, которые раньше тратили время, играя роль “няни” (раздача задач, подготовка статусных отчётов и другие формы микроменеджмента), могут посвятить его тому, чтобы стать “гуру” или “служителями” (servant) для Команды (обеспечивая наставничество, коучинг, помогая в устранении препятствий, в решении проблем, предлагая творческий вклад и направляя развитие навыков членов Команды). При такой перестановке менеджерам необходимо изменить их стиль руководства; например, использовать Сократовские вопросы, чтобы помочь Команде найти решение проблемы, а не решить, что делать, и передать Команде на исполнение.
Перевод статьи осуществлён Кротовым Артёмом и Романом Лапаевым.