Product owner кто это




Обзор методологии Scrum

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

Основа Scrum

Роли
В методологии Scrum всего три роли:

Скрам Мастер (Scrum Master) – самая важная роль в методологии. Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В Agile команда является самоорганизующейся и самоуправлямой. Основные обязанности Скрам Мастера:

  • Создает атмосферу доверия
  • Участвует в митингах в качестве фасилитатора
  • Устраняет препятствия
  • Делает проблемы и открытые вопросы видимыми
  • Отвечает за соблюдение практик и процесса в команде

Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте. ScrumMaster может также помогать Product Owner создавать Backlog для команды.

Product Owner – это человек, отвечающий за разработку продукта. Как правило, это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Product Owner – это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет. Обязанности Product Owner таковы:

  • Отвечает за формирование product vision
  • УправляетROI
  • Управляет ожиданиями заказчиков и всех заинтересованных лиц
  • Координирует и приоритизирует Product backlog
  • Предоставляет понятные и тестируемые требования команде
  • Взаимодействует с командой и заказчиком
  • Отвечает за приемку кода в конце каждой итерации

Product Owner ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта.

  • Отвечает за оценку элементов баклога
  • Принимает решение по дизайну и имплементации
  • Разрабатывает софт и предоставляет его заказчику
  • Отслеживает собственный прогресс (вместе со Скрам Мастером)
  • Отвечает за результат перед Product Owner

Размер команды ограничивается размером группы людей, способных эффективно взаимодействовать лицом к лицу. Типичные размер команды – 7 плюс минус 2.

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

Команда самоорганизуется для выполнения конкретных задач в проекте, что позволяет ей гибко реагировать на любые возможные задачи. Для облегчения коммуникаций команда должна находиться в одном месте (colocated). Предпочтительно размещать команду не в кубиках, а в одной общей комнате для того, чтобы уменьшить препятствия для свободного общения. Команде необходимо предоставить все необходимое для комфортной работы, обеспечить досками и флипчартами, предоставить все необходимые инструменты и среду для работы.

Product Backlog постоянно пересматривается и дополняется – в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За Product Backlog отвечает Product Owner. Он также работает совместно с командой для того, чтобы получить приближенную оценку на выполнение элементов Product Backlog для того, чтобы более точно расставлять приоритеты в соответствии с необходимым временем на выполнение.

Сумма оценок оставшейся работы может быть построена как график зависимости от времени. Такой график называется Sprint Burndown chart. Он демонстрирует прогресс команды по ходу спринта.

Спринт (Sprint)
В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней). Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику). Короткие спринты обеспечивают быстрый feedback проектной команде от заказчика. Заказчик получает возможность гибко управлять scope системы, оценивая результат спринта и предлагая улучшения к созданной функциональности.

Такие улучшения попадают в Product Backlog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий (или на один из следующих) спринтов. Каждый спринт представляет собой маленький «водопад». В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.

  • Жизненный цикл спринта
  • Планирование спринта

В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда. Планирование спринта состоит из двух последовательных митингов.

Планирование спринта, митинг первый. Участники: команда, Product Onwer, Sxrum Master, пользователи, менеджемент Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog –функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта. Артефакт: Sprint Backlog.

Планирование спринта, митинг второй. Участники: Скрам Мастер, команда Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность. Артефакт: в Sprint Backlog появляются задачи Если в ходе спринта выясняется, что команда не может успеть сделать запланированное на спринт, то Скрам Мастер, Product Owner и команда встречаются и выясняют, как можно сократить scope работ и при этом достичь цели спринта.

Остановка спринта (Sprint Abnormal Termination)

Остановка спринта производится в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить Product Owner, если необходимость в достижении цели спринта исчезла. После остановки спринта проводится митинг с командой, где обсуждаются причины остановки спринта. После этого начинается новый спринт: производится его планирование и стартуются работы.

Daily Scrum Meeting

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

  • Что сделано вчера?
  • Что будет сделано сегодня?
  • С какими проблемами столкнулся?

Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items, например в формате что/кто/когда:

  • Обсудить проблему с отрисовкой контрола
  • Петя и Вася
  • Сразу после скрама

Демо и ревью спринта
Рекомендованная длительность: 4 часа Команда демонстрирует инкремент продукта, созданный за последний спринт. Product Owner, менеджмент, заказчики, пользователи в свою очередь его оценивают. Команда рассказывает о поставленных задачах, о том как они были решены, какие препятвия были у них на пути, какие были приняты решения, какие проблемы остались нерешенными.

На основании ревью принимающая сторона может сделать выводы о том, как должна дальше развиваться система. Участники миитинга делают выводы о том, как шел процесс в команде и предлагает решения по его улучшению. Скрам Мастер отвечает за организацию и проведение этого митинга. Команда помогает ему составить адженду и распланировать кто и в какой последовательности что представляет. Подготовка к митингу не должна занимать у команды много времени (правило – не более двух часов).

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

Product owner кто это

Директор по продукту в Kaiten

  • Основатель компании Sputnyx
  • Организатор митапов Product Tank Moscow
  • Professional Scrum Master / Scrum Product Owner
  • Управлял более 20 проектами разработки Web и Mobile приложений
  • Имеет успешный опыт повышения производительности отдела разработки на 20% за счет внедрения Agile-практик
  • Professional Scrum Master / Scrum Product Owner

Agile Coach в Сбербанке

  • Более 12 лет в разработке коммерческого программного обеспечения в должностях от разработчика до руководителя проектов
  • Как Agile-коуч и тренер работал с Альфа-Банк, М.Видео, ZeptoLab
  • Сертифицированный Agile-практик

Инструктор в течение всего тренинга терпеливо и подробно объяснял непонятные моменты на наглядных и жизненных примерах, обращал внимание участников на важные моменты при разработке user story.

С помощью этого курса я наконец поняла, как я могу начать применять их на практике, а также помогать своим коллегам при их разработке.

После выбора билета вы сможете оплатить картой как частное лицо или получить счёт для компании

Онлайн-тренинг пройдёт
15 и 16 декабря 2018, в выходные,
с 10 до 14 часов по московскому времени

  • Обучение в выходные
    в группе до 14 человек
  • Свидетельство
    об окончании тренинга
  • Оплата картой
  • Обучение в выходные
    в группе до 14 человек
  • Свидетельство
    об окончании тренинга
  • Закрывающие документы

После выбора билета вы сможете оплатить картой как частное лицо или получить счёт для компании

Онлайн-тренинг пройдёт
15 и 16 декабря 2018, в выходные,
с 10 до 14 часов по московскому времени

  • Обучение в выходные
    в группе до 14 человек
  • Свидетельство
    об окончании тренинга
  • Оплата картой
  • Обучение в выходные
    в группе до 14 человек
  • Свидетельство
    об окончании тренинга
  • Закрывающие документы

После регистрации и оплаты вы получите приглашение в календарь и письмо со ссылкой на подключение к видеотрансляции.

Инструктор будет вести занятие в Zoom, вы сможете говорить голосом и писать вопросы, в ходе занятия вы будете делать задания в Google Docs.

На тренинге вам потребуются: компьютер с надёжным интернетом и современным браузером (Explorer, Chrome, Firefox, Safari), микрофон и наушники.

Нет, запись трансляции купить нельзя, мы продаём обучение, а не записи.

Просмотр записей наблюдений за тем, как пловцы под руководством тренера плывут по дорожкам 4 часа подряд учебного эффекта для зрителя не создаёт 🙁

Для обучения, помимо инструктажа по записи, необходимо:

  • выполнить ту деятельность, по которой вы получили инструктаж
  • получить обратную связь на результаты вашей деятельности

Поэтому наш курс состоит из практических занятий, а не вебинаров.

Product owner кто это

04:57 pm — Кто такой Product Owner
Готовился к тренингу для Product Owners и набросал заметки на тему кто такой Product Owner и зачем он нужен.

Был бы рад услышать комментарии и/или возражения

Под катом много буков.

В методологии Scrum есть роль ProductOwner. Зачем он нужени и какие проблемы он решает?
Давайте рассмотрим вполне типичный случай разработки продукта или сервиса. Предположим, что у вас есть множество заказчиков/стейкхолдеров и команда. Кроме того, есть цель (или цели) разработки. Какие? Не знаю. Но уверен, что цель у быть должна. Вы же зачем-то пишете код? Если у вас цели нет, самое время задуматься и ее сформулировать.
Предположим, вам удалось сформулировать цель. Например, «мы хотим к концу года заработать 10млн долларов» или «мы хотим занять 51% рынка к такому-то году».
Осталось выяснить, как этой цели добиться максимально оптимальным образом. Я попробую сформулировать некоторые проблемы, которые могут тут вам встретится.

Проблемы

  • Проблема концепции. У каждого заказчика есть свои собственные интересы в системе — каждый хочет, чтобы продукт решал именно его задачи. Все заказчики говорят команде, что нужно делать. В итоге команда решает задачи того, кто более настойчив. Насколько это правильный и оптимальный выбор с точки зрения достижения цели?
  • Проблема приоритетов. Заказчик знает, что единственный способ добиться, чтобы его работу все-таки сделали — объявить ее самой важной. В противном случае за нее никто никогда не возмется. В итоге у команда вся текущая работа идет с самым высоким приоритетом.
  • Проблема контекста. В итоге команда бросается делать то одно, то другое. Помимо того, что это всех нервирует и демотивирует, существует проблема переключения контекста: переход от задачи к задаче занимает много времени. Это просто медленнее.
  • Проблема прозрачности. Заказчики расстроены. Команда работает медленно (они не делают мои задачи!) и плохо (они делают мои задачи совсем не так, как я хочу!). Это действует в обе стороны. Заказчики иногда представляются команде неадекватными людьми, которые хотят странного.
  • Проблема скорости разработки. Иногда ответы на вопросы заказчик не может ответить днями или даже неделями. Пока заказчик «думает», команда занимается низкоприоритетными, ненужными задачами, а иногда и вовсе бездельничает

Ну отлично, давайте думать как это поправить. Не мудрствуя лукаво воспользуемся «менеджерским» методом решения проблем: введем роль и распишем отвественности и полномочия. (а как, вы думали, в RUP появилось 33 роли?)

Новая роль ProductOwner

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

  • Проблема концепции. Сделаем так, чтобы только один человек отвечал за концепцию продукта/сервиса. В своей голове он должен утрясти мнения многих заказчиков и исходя из сформулированной цели и интересов всех участников определить Концепцию (Vision) продукта/сервиса.
  • Проблема приоритетов. Этот же человек определит приоритеты — что в каком порядке делать, чтобы достигать цели оптимальным, то есть максимально эффективным образом. В случае постоянно меняющегося окружения это просто означает, что важнейший приоритет получает самая важная с точки зрения бизнеса задача.
  • Проблема контекста. Этот человек будет работать с командой так, чтобы ее производительность была максимальной в долгосрочной перспективе. В частности, это означает, что он будет заботится о стабильности объема работ в итерации (команда сосредотачивается на четком списке фич на итерацию) и берет на себя все заботы о заказчиках, которым вдруг нужен этот чертов функционал прямо сейчас!
  • Проблема прозрачности. ProductOwner отвечает за обеспечение полной прозрачности всей разработки. Все должны иметь нужную им информацию — начиная от спонсора проекта/продукта/сервиса и заканчивая студентами-стажерами.
  • Скорость разработки. ProductOwner отвечает за то, чтобы требования были готовы к началу итерации.ProductOwner может принять временное решение, если правильного ответа все-таки нет.

Итак, у нас появился человек, который отвечает за продукт/сервис. Это один человек, а не группа — иначе мы опять получим проблему множественности заказчиков. У него в голове сформулирован эффективный путь достижения целей, который он доносит до каждого, кто в том нуждается и, как говорят американцы, «he gets the job done».

Теперь мы готовы расписать его ответственность и полномочия (они будут у нас совпадать)

Ответственность и полномочия ProductOwner

Концепция

  • Концепция продукта/сервиса
  • ROI (возврат вложенных средств) по фичам (features)
  • Координация и приоритезация списка фич [Backlog]
  • Планирование фич на итерацию (кроме оценки!)

Общение с командой

  • Отвечает за предоставление понятных и тестируемых требований
  • Принимает результат в конце итерации. Команде нужна обратная связь.

Общение со стейкхолдерами и заказчиками

  • Отвечает за сбор требований к продукту/сервису
  • Разруливает конфликты
  • Управляет ожиданиями стейкхолдеров и заказчиков

Пытливый ум некоторых читателей наверное заметил несколько «такнебывает». Они и правда есть. Сформулируем.

Такнебывает №1. Где гарантия, что узурпация власти ProductOwner решит проблему?

ProductOwner не занимается принятием решений вместо стейкхолдеров. Он должен понимать, что его основная задача — общение со всеми заинтересованными сторонами. Он не в коем случае не узурпирует власть. ProductOwner является представителем заказчика для команды и представителем команды для заказчиков.
Например, он может проводить регулярные встречи заказчиков для выработки совместных решений по приоритетам разработки.

Такнебывает №2. ProductOwner у вас быстро станет узким местом!

Отличный довод. Если бы ProductOwner определял приоритеты разработки, общался с заказчиками, разрабатывал требования и т.д. то очень скоро скорость разработки продукта определялась скоростью, с которой ProductOwner отвечает на запросы.
Однако, это не так. Как только план сформирован и цели итерации определены, команда сама может контактировать с заказчиками по поводу реализации конкретного плана. В частности, ProductOwner может работать с аналитиками в команде для определения требований.

Такнебывает №3. Бизнес-человек быстро завалит разработку нашего высоко-технологического продукта
Действительно, при разработке продуктов со сложной архитектурой приоритеты часто определяются не интересами бизнеса, а технологическими рисками. Кроме того, иногда архитекторы (особенно неопытные) заигрываются и планируют создание большого фреймворка в стиле лучше день потерять, а потом за пять минут долететь. Тем важнее иметь правильного ProductOwner, который сможет выслушать обе стороны и согласовать план, который удовлетворит обе стороны.

Карьера в IT: должность Software Product Manager

Статья продолжает цикл «Карьера в IT» — обзоры должностей в IT.

Если вы уже задействованы в IT проекте в качестве дизайнера, разработчика, тестировщика или другого специалиста и хотите получить большую свободу действий и влиять на продуктовую стратегию компании, то позиция Software Product Manager может оказаться именно для вас.

Software product manager — это человек, который:
— Выступает СЕО продукта;
— Отвечает за продуктовую стратегию компании;
— Имеет глубокое понимание своего сегмента рынка, потребителей и портфолио;
— Периодически тестирует бизнес-кейсы;
— Принимает на себя риски и управление ими;
— Энтузиаст своего продукта;
— Профессионал в коммуникациях и анализе поведения людей.

Наглядно продемонстрировать место SPM в команде можно так:

Задачи и обязанности

Основная задача менеджера по продукту — делать все возможное для постоянного совершенствования продукта на каждой стадии его жизненного цикла.

Выполняя свою работу, Software Product Manager коммуницирует как с командой проекта — CEO, разработчиками, визуальными дизайнерами, UX/UI специалистами, QA, так и с конечными пользователями. На определенном этапе именно взаимодействие с пользователями продукта может составлять более 70% ежедневной работы.

В круг обязанностей менеджера по продукту может входить следующее:
— Общение с заказчиком и его командой, сбор требований, выявление ожиданий и пожеланий;
— Создание user stories, приоритизация беклога продукта, распределение задач;
— Создание feature спецификаций (цели, аналитика, wireframes);
— Взаимодействие с дизайнерами (фидбек по выполненным задачам);
— Создание, обновление и мониторинг дешбордов продукта;
— A/B-тестирование;
— Координация взаимодействия с компаниями, которые исследуют поведение потребителей (UserTesting, Validately, Ask your Target Market и т.д.), затем анализ полученной информации;
— Принятие решений по продукту, основываясь на количественных данных.

Самым сложным часто оказывается именно первый пункт — коммуницирование с заказчиком. Очень важен поиск баланса между возможностью и реальностью, так как заказчик хочет многого, а его пользователи, зачастую, хотят несколько другого. И ваша задача — донести до заказчика мнение и нужды именно его целевой аудитории/пользователей и получить одобрение на внесение модификаций в реализацию его «возможностей».

Типичный рабочий день описать сложно — задачи зависят от этапа, на котором находится разработка. К повторяющимся изо дня в день задачам можно отнести следующие:
— Общение с заказчиком, демонстрация последнего мокапа/прототипа, обсуждение деталей, согласование;
— Проведение стендапа с командой, распределение задач;
— Работа с пользователями: тестирование новых фич, A/B-тестирование, сбор фидбеков. По необходимости внесение данных в беклог по результатам;
— Работа с дизайнерами: разработка-доработка мокапов, фидбек по проделанной работе, согласование полученного результата с заказчиком;
— Исследование рынка: аналитика, новости, мониторинг конкурентов.
— Обязательная часть рабочего дня — хотя бы час в день тратить на обучение: онлайн курс, книжка, общение с ментором.

В зависимости от проекта могут меняться как задачи, так и схема взаимодействия участников проекта. Более того, может быть и так, что роли менеджера по продукту нет совсем, и его функции распределяются между CEO, CTO, менеджером проекта и дизайнером.

Многие спрашивают, чем роль менеджера по продукту отличается от менеджера проекта. Product Manager — это Product Owner, он принимает бизнес-решения, вовлекается в маркетинг и в то, что мы называем Product Shaping. Таким образом, Product Manager влияет на сам продукт. Project Manager занимается не продуктом напрямую, управляет тем или иным проектом (отвечает за то, чтобы проект достиг своей цели).

Иногда эти роли бывают перемешаны, и один человек может совмещать в себе обе функции. Опять же, все зависит от проекта и компании. Например, у меня в компании проектного менеджера нет. Его функции разделены между CEO, CTO и Product Manager.

Как стать менеджером по продукту

Если говорить о наборе знаний/качеств, которые могут пригодиться, я бы обратила внимание на следующее:
— Технические знания процесса веб-разработки;
— Понимание индустрии;
— Коммуникационные способности, стрессоустойчивость, способности быстро найти эффективное компромиссное решение.

В зависимости от вашего бекграунда набор знаний будет меняться. Хочу предложить перечень источников-ресурсов, который очень помог лично мне:

1. The Lean Product Playbook by Dan Olsen — одна и моих настольных книг. Автор — талантливый предприниматель, консультант и Lean product эксперт. Благодаря его инициативе в Сан-Франциско существует сообщество людей, влюбленных в Product Management — Lean Product and Lean UX Silicon Valley. Они организуют на регулярной основе встречи для проведения тренингов, обмена информацией и лучшими практиками, нетворкинга. Некоторые видео можно найти на Youtube.

2. Intercom on Product Management by Des Traynor и John Collins — не настолько интересная, как первая, но служит прекрасным к ней дополнением.

3. Курс «Software Product Management» на Coursera. Стартовал в октябре, поэтому можете успеть пройти его с общей группой. Чтобы пройти курс бесплатно, необходимо регистрироваться на отдельные части курса (без сертификата).

4. Если у вас нет технического бекграунда, необходимо задаться вопросом изучения цикла разработки веб- или мобильного приложения. Помочь могут курсы, на Coursera большой их выбор.

5. Касательно используемых тулов, могу выделить следующие:
— UX Design: Balsamiq Mockups, Proto.io, Axure, Uxpin, Bootstrap;
— Agile Development: Trello, Pivotal Tracker, JIRA Agile;
— Исследование потребителей (американских): UserTesting, Validately, Ask your Target Market;
— Аналитика и A/B Testing: Google Analytics, KISSmetrics, Mixpanel, Flurry.

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

Куда двигаться дальше

Что касается перспектив роста в Product Management:
— Развиваться горизонтально — каждый новый проект будет приносить новые знания, возможности, а также понимание, что еще следует доучить и в чем разобраться;
— Создать собственный продукт;
— Стать консультантом (Advisor). Это сейчас крайне актуально — хорошие специалисты помогают растить продукт, получая за это equity или почасовую оплату.

Roman’s knowledgebase

Что такое Scrum

Очередной конспект семинара о методологии управления проектами. На этот раз рассматриваем Scrum – один из, так называемых, гибких (agile) методов.

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

Конспект семинара предоставлен моим коллегой Антоном Сальником

Оглавление

Введение

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

Термин Scrum был впервые озвучен в работе Хиротаки Такеучи и Икуджиро Нонака, где авторы отметили успешность проектов, использующих небольшие команды без жесткой специализации. Такие команды чем-то напоминают конструкцию схватки (scrum) в регби, которая назначается при нарушении правил или остановке игры. Джеф Сазерленд использовал эту работу при создании методологии для корпорации Easel в 1993 году, которую по аналогии и назвал Scrum, а Кен Швабер формализовал процесс для использования в индустрии разработки программного обеспечения, представив в 1995 году работу на конференции Object-Oriented Programming Systems, Languages & Applications.

Основа Scrum — итеративная разработка. Scrum определяет:

Каждую итерацию можно описать так: планируем — фиксируем — реализуем — анализируем. За счет фиксирования требований на время одной итерации и изменения длины итерации можно управлять балансом между гибкостью и планируемостью разработки.

Концепция Scrum

Формальная часть Scrum состоит из трех ролей, трех практик и трех основных документов.

В методологии Scrum всего три роли.

Product Owner

Product Owner ( владелец продукта ) – это человек, отвечающий за разработку продукта. Обычно владелец продукта является представителем или доверенным лицом заказчика, а для компаний, выпускающих коробочные продукты, он представляет рынок, на котором реализуется продукт. Владелец продукта должен составить бизнес план, показывающий ожидаемую доходность и план развития с требованиями, отсортированными по коэффициенту окупаемости инвестиций. Исходя из имеющейся информации, владелец продукта подготавливает список требований, отсортированный по значимости. Владелец продукта – это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет.

Обязанности владельца продукта таковы:

Scrum Master (Скрам Мастер)

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

Основные обязанности Scrum Master-а таковы:

Scrum Team

Scrum-команда (Scrum Team) — группа, состоящая из пяти–девяти самостоятельных, инициативных программистов. Первая задача этой команды — поставить реально достижимую, прогнозируемую, интересную и значимую цель для итерации. Вторая задача — сделать все для того, чтобы эта цель была достигнута в отведенные сроки и с заявленным качеством. Цель итерации считается достигнутой только в том случае, если все поставленные задачи реализованы, весь код написан по определенным проектом «стандартам кодирования» (coding guidelines), программа протестирована полностью, а все найденные дефекты устранены. Программисты этой команды должны уметь оценивать и планировать свою работу, работать в команде, постоянно анализировать и улучшать качество взаимодействия и работы.

Обязанности команды таковы:

Практики

Sprint

В Scrum итерация называется Sprint . Ее длительность составляет 1 месяц (30 дней).

Результатом Sprint является готовый продукт ( build ), который можно передавать ( deliver ) заказчику (по крайней мере, система должна быть готова к показу заказчику).

Подготовка к первой итерации, называемой спринт (Sprint), начинается после того, как владелец продукта разработал план проекта, определил требования и отсортировал их в количестве, достаточном для наполнения одной итерации. Такой список требований называется журналом продукта (Product Backlog). При планировании итерации происходит детальная разработка сессий планирования спринта (Sprint Planning Meeting), который начинается с того, что владелец продукта, Scrum-команда и Scrum-мастер проверяют план развития продукта, план релизов и список требований. Scrum-команда проверяет оценки требований, убеждается, что они достаточно точны, чтобы начать работать, решает, какой объем работы она может успешно выполнить за спринт, основываясь на размере команды, доступном времени и производительности. Важно, чтобы Scrum-команда выбирала первые по приоритету требования из журнала продукта. После того как Scrum-команда обязуется реализовать выбранные требования, Scrum-мастер начинает планирование спринта. Scrum-команда разбивает выбранные требования на задачи, необходимые для его реализации. Эта активность в идеале не должна занимать больше четырех часов, и ее результатом служит список требований, разбитый на задачи, — журнал спринта (Sprint Backlog). Необходимо, чтобы все участники команды приняли на себя обязательство по реализации выбранной цели.

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

Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.

Daily Scrum Meeting

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

Скрам митинг проводит Скрам Мастер. Он по кругу задает вопросы каждому члену команды

Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items , например в формате что/кто/когда, например

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

Sprint Review Meeting

В конце каждого спринта проводится демонстрационный митинг (Sprint Review Meeting) продолжительностью не более четырех часов. Сначала Scrum-команда демонстрирует владельцу продукта сделанную в течение спринта работу, а тот в свою очередь ведет эту часть митинга и может пригласить к участию всех заинтересованных заказчиков. Владелец продукта определяет, какие требования из журнала спринта были выполнены, и обсуждает с командой и заказчиками, как лучше расставить приоритеты в журнале продукта для следующей итерации. Во второй части митинга производится анализ прошедшего спринта, который ведет Scrum-мастер. Scrum-команда ищет использованные в последнем спринте положительные и отрицательные способы совместной работы, анализирует их, делает выводы и принимает важные для дальнейшей работы решения.

Затем цикл замыкается, и начинается планирование следующего спринта

Sprint Abnormal Termination

Остановка спринта производится в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить Product Owner , если необходимость в достижении цели спринта исчезла.

После остановки спринта проводится митинг с командой, где обсуждаются причины остановки спринта. После этого начинается новый спринт: производится его планирование и стартуются работы.

Артефакты

Product Backlog

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

Sprint Backlog

Журнал спринта содержит функциональность, выбранную владельцем продукта из журнала продукта . Все функции разбиты по задачам, каждая из которых оценивается командой. Разбивка на задачи должна быть сделана таким образом, чтобы выполнение одной задачи занимало не больше двух дней (считается, что менее детальная, например, полдня, разбивка приводит к более грубой оценке, чем приемлема в большинстве проектов, использующих методологию Scrum). Разбивка на задачи поможет так спланировать итерацию, чтобы в конце не осталось ни одной невыполненной задачи и, соответственно, достичь ее цели. После завершения детализации оценка журнала спринта сравнивается с первичной оценкой в журнале продукта. Если существует значительное расхождение, команда договаривается с владельцем продукта об объеме работ, который должен быть выполнен в течение итерации, и о том, какой объем будет перенесен на следующую. Менее важные и мало влияющие на цель итерации задачи выносятся из журнала спринта.

Burndown Chart

График спринта показывает ежедневное изменение общего объема работ, оставшегося до окончания итерации. Это график позволяет команде разработчиков делать анализ текущей ситуации и своевременно реагировать на отклонения. График спринта позволяет также владельцу продукта наблюдать за ходом итерации — если общий объем работ не уменьшается каждый день, значит, что-то идет не так.

Выводы

Product Backlog

Sprint Backlog

Sprint Burndown chart