Эта статья не рассчитана на бывалых скрам-мастеров, опытных проект-менеджеров… А скорее для начинающих, тех, кто хотят открыть для себя эту нишу в ИТ.

Agile методы - это альтернатива поэтапному управлению проектами. Поэтапная методика управления проектами завязана на менеджерах проектов, предоставляющих артефакты, фиксирующие что задача выполнена. Этот список артефактов, притом для каждого этапа устанавливается, как правило, PMO. Он его(список) создает, просматривает и утверждает, прежде чем будет дана отмашка начать следующий этап жизненного цикла проекта. Чтобы внести любые изменения в проект, приходится отправлять запрос на изменение проекта. Соответственно, внесение изменений настоятельно не рекомендуется, так как их утверждение занимает много времени.

Agile подход разработки программного обеспечения или Скрам-разработка предполагает, что изменения будут происходить прямо во время жизненного цикла продукта и приветствуются, если они улучшают качество продукта и реагирование на требования клиентов. То есть, то, что хочет и в чем нуждается конечный потребитель, со временем будет меняться по мере того, как он будет взаимодействовать с решением поэтапно (или в релизах). Команды разработки, использующие Scrum, начинают работу над проектом, с общения с владельцем продукта или его представителем, чтобы определить, что будет так называемым минимально жизнеспособным продуктом или MVP. MVP — это соглашение с владельцем продукта о минимальной функциональности, необходимой для создания основы проекта, и от которой будет продолжаться постепенное развитие проекта или релизы до тех пор, пока не будут выполнены все требования заказчика. Scrum-команды состоят из пяти-семи человек с учетом гибкости ролей. Работа ведется в «Спринтах» продолжительностью от трех до пяти недель, по окончании которых должен быть полностью протестированный продукт с дополнительным функционалом.

В Scrum-команде есть только три ключевые роли: владелец продукта, разработчик/тестировщик и Scrum-мастер.

Владелец продукта 

Владелец продукта — это представитель пользователей продукта который знает их видение того, какой должна быть функциональность продукта. Один из способов донести это видение до Scrum-команды — это groomings(тренинги) по «обработке» бэклога продукта и выяснение приоритетов фич(features) (также известных как пользовательские истории) для продукта. Владелец продукта обеспечивает четкое понимание пользователей, бизнес-конкуренцию за этих клиентов и дорожную карту продукта с перспективами на будущее. Владельцы продукта должны сотрудничать и идти на компромисс, поскольку именно Скрам-команда выбирает из приоритетов невыполненной работы объем работы, которую они будут выполнять в течение каждого спринта, полагая, что они лучше всех знают, на что они способны. В обмен на это обязательство владелец продукта берет на себя взаимное обязательство не выдвигать новые требования во время спринта. Требования могут изменяться (и изменения поощряются), но только вне Спринта. 

Ожидается, что человек в роли владельца продукта будет активно участвовать в Scrum-команде, иметь деловую смекалку и иметь прокачанные коммуникативные навыки, как для внутренних, так и для внешних связей, со спонсорами и заинтересованными сторонами проекта, притом в любой момент времени.

Разработчик / Тестировщик

В не-Agile разработке программного обеспечения роль программиста резко отделена от роли тестировщика. В Scrum-командах, где участники должны быть гибкими и проявлять интерес к поиску решений многих задач в любой момент времени, и если это необходимо для выполнения задач спринта, все работают вместе над улучшением и повышением качества продукта. Разработчики не просто программируют и скидывают свою работу тистировщикам. Тестировщики не просто запускают тестовые сценарии, выявляют дефекты и регистрируют их для исправления. Они все работают вместе и дополняют друг друга, и роли могут меняться Спринт за Спринтом, в зависимости от сильных и слабых сторон каждого участника и желания изучать новые вещи. Каждому члену команды, по отдельности, будет трудно соответствовать требованиям приемлемости того, что они разрабатывают, и считать историю «готовой» без раннего сотрудничества с тестировщиками, а тестировщики не будут эффективными без погружения и понимания работы разработчика. Нет установленных/быстрых правил; это сводится к тому, что команда находит определенные соглашения для командной работы в своем спринте.

Скрам-мастер

Скрам-мастера служат наставниками и сторонниками метода ведения дел по скраму. Они также организуют встречи, связанные с этим, такие как планирование спринта, обсуждение и подготовка невыполненных работ с владельцем продукта, стендап-встречи, обзоры и ретроспективы. Роль Scrum Master похожа на роль традиционного менеджера проекта, но без сложного процесса и процедур. Скрам-мастера гибки и в идеале могут взять на себя любую роль Скрама для выполнения задачи, необходимой для продвижения Спринта.

Заключение

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

На этом все. Также хочу рассказать о том, что 15 февраля у моих коллег из OTUS пройдет бесплатный вебинар по теме "Планирование и выбор методологии проекта". Подробнее о вебинаре можно узнать по этой ссылке.