Содержание
Роль владельца продукта не всегда совмещена с ролью менеджера продукта. Владельцы стремятся создать все условия, чтобы команда разработчиков создавала максимальную ценность для бизнеса. Важно, чтобы владельцем продукта был один человек. Вряд ли команда разработчиков захочет получать разные указания от разных владельцев одновременно. Такие улучшения попадают в Product Backlog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий (или на один из следующих) спринтов. Каждый спринт представляет собой маленький «водопад».
Таким образом, идет естественная эволюция процессов, так как с каждой новой итерацией учитывается и разбирается предыдущий опыт. На практике, историй пользователя (типа https://deveducation.com/ “Регистрация пользователя”) гораздо больше. Сервис/продукт может включать множество таких историй, поэтому приоритезация строится сверху вниз, слева направо.
В верхней левой части располагаются самые важные user story (Активность) и самые важные задачи. В digital проектах, это может быть функциональность. К примеру, рабочая форма регистрации на сайте, которую можно показать. Scrum – гибкая методология разработки или гибкий управленческий фреймворк (т.е. структура) с акцентом на качество процессов.
Продукт разрабатывает самоуправляемая команда
Scrum Master гарантирует проведение таких встреч, но отвечает за проведение Daily Scrum команда разработчиков. Также Scrum Master обучает команду разработчиков удерживать проведение Daily Scrum в 15 минутных рамках и должен следить, чтобы встреча не была нарушена. Владелец продукта может захотеть хранить информацию о всех заказчиках, заинтересованных в данной бизнес-задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ в ходе спринта. Важность — степень важности данной истории, по мнению владельца продукта, полученная в результате переговоров с заказчиком.
Встреча обязательна для разработчиков в полном составе. Скрам-мастер может, но не должен на ней присутствовать. Если же вы понимаете, что самостоятельное знакомство со скрамом заберет слишком много вашего времени, советуем посетить наш тренинг по скраму для начинающих Scrum Core 2.0. На нем вы за два дня получите исчерпывающие знания основ скрама, включая роли, события и артефакты, а также собственными глазами увидите, как его применяют в командах на практике. Любой разговор об успешном управлении проектами с помощью скрама стоит начинать с определения скрама. Он не фильтрует те хотелки заказчика, которые ничего не дадут или даже принесут вред продукту и бизнесу в целом.
Совещание планирования спринта (Sprint Planning Meeting)[править | править код]
Для расширения Scrum предложена методика Scrum of Scrums. Анализ последнего завершенного спринта в части задействованных людей, процессов и инструментов. Цель таких встреч — улучшение коммуникаций в команде, сокращение количества дополнительных встреч, выявление будущих рисков и трудностей, способствование быстрому принятию решений. Стейкхолдеры — лица, которые инициируют проект (бизнес-заказчики) и для кого проект Scrum будет приносить выгоду. Они вовлечены в схватку только во время обзорного совещания по спринту .
Product Owner обсуждает цели, которые должны быть выполнены за спринт, учитывая бэклог продукта, предыдущий инкремент продукта и т. Д., добавляет новые User Story в бэклог и убирает выполненные. Команда разработчиков пытается спрогнозировать функциональность, которую смогут разработать за время спринта. Также, все члены Scrum Team должны совместно осознать и оценить всю работу грядущего спринта.
Это очень короткое ежедневное собрание, которое для удобства проводится в одно и то же время (обычно утром) и в одном и том же месте. Многие команды стараются уложиться в 15 минут, однако это лишь рекомендация. Такое собрание также термины agile называется «ежедневным стендапом», что подчеркивает его краткость. Ежедневное Scrum-совещание проводится, чтобы каждый участник команды был в курсе происходящего, не отклонялся от цели и получал план работы на ближайшие 24 часа.
🔥 Критика SCRUM
С одной стороны, владелец продукта — это человек, который общается с клиентами и другими заинтересованными в продукте лицами (нередко их называют заказчиками). Scrum устроен так, чтобы стимулировать разработчиков работать совместно и помогать друг другу закончить каждый взятый в спринт элемент бэклога. Scrum не подходит для слишком больших и сложных проектов, так как могут возникнуть проблемы с координацией команд. Команда работает небольшими этапами, на каждом из которых определяются цели и способы их достижения, что повышает скорость работы. Scrum изобрели программисты Джефф Сазерленд и Кен Швабер. Они наблюдали за работой американских военных и спецназа и пришли к выводу, что в основе успеха лежит качественная командная работа.
- Например, он не подходит для проектов, где требуются фиксированные сроки вплоть до часов, бюджеты и точное видение результатов, как в случае с конвейерной работой.
- Бэклог продукта — это упорядоченный перечень всех пожеланий и идей, над которыми будет работать скрам-команда.
- Должно быть поле для экспериментов и исследований.
- В digital проектах, это может быть функциональность.
- Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.
Производительность вычисляется в конце Спринта как сумма Стори Поинтов по всем полностью завершенным Элементам Бэклога Спринта. Все эти практики имеют самое прямое отношение к спринтам, поэтому сначала скажем несколько слов о том, что вообще такое спринт. В 1995 году Джефф Сазерленд и Кен Швабер привели скрам в систему в статье «Разработка программного обеспечения по скраму» . По скраму, продукт разрабатывают не сразу полностью, а небольшими готовыми к релизу частями, каждую из которых завершают за короткую итерацию, или спринт. Скрам — не линейный метод разработки; это не каскадная модель. Каскадная модель (англ. waterfall) — линейная последовательность событий, когда продукт планируют, разрабатывают, тестируют и так далее.
Ретроспектива: анализ спринта
Доска должна помогать сплочению команды и взаимопомощи. Вообще говоря, выделение столбцов для каждой из стадий работы над задачей вполне возможно, но команда должна учитывать эти риски. Скрам-команда, владелец продукта и заинтересованные лица собираются в одной комнате. Команда и владелец продукта демонстрируют заинтересованным лицам результаты спринта, рассказывают, как прошел спринт, отвечают на вопросы.
SCRUM – эффективный метод управления проектами
Когда члены команды разбросаны по разным комнатам, местам или часовым поясам, люди обычно откладывают свое взаимодействие, из–за этого продуктивность и качество продукта снижается. В идеале вся команда должна сидеть в одной комнате, чтобы не было никаких препятствий (независимо от того, насколько они малы) для общения. Это не означает, что каждый член команды должен быть идеальным разработчиком и обладать всеми этими знаниями, но эти знания должны быть распределены по команде члены. Скрам Мастер — это защитник Скрам–команды, который устраняет препятствия и контролирует рабочие процессы. В этом тексте мы опишем содержание и функционал каждой роли в Scrum и общие характристики Scrum команды.
Работа с командой и анализ проделанной работы, да. Управление задачами, в удобных программах, тоже да. Далее с учетом приоритетов задачи набираются в спринты и начинается работа. По итогам завершенных спринтов становится понятно, сколько story point-ов приблизительно может выполнить команда. А в процессе разбора (ретроспективы) после могут найтись точки роста.
В идеальном мире прошло пять недель, и наши бойцы сделали суперчебурек, который без вопросов был принят руководителем и скрам-мастером. Презентация чебурека разлетелась по всем СМИ, тысячи людей встали в очередь на предзаказ, а чебуречная вышла на IPO. Команда обозначает все положительные моменты предыдущей итерации. В статье это может казаться очевидным, но в жизни даже это само по себе может быть предметом для гордости. 👉 Итерации в скраме — это то же самое, что и спринты в программировании.
Все участники команды разработчиков в обязательном порядке должны взять на себя ответственность по достижению поставленной цели. На этом собрании команда разработчиков под руководством scrum-мастера планирует работу (объем спринта), которую необходимо выполнить в течение текущего спринта. Затем в спринт добавляются конкретные пользовательские истории из бэклога продукта. При этом команда Scrum согласовывает такие истории, которые можно будет реализовать на практике в ходе спринта. Сегодня скрам является одной из самых популярных методологий управления проектами в мире и используется не только в области разработки программного обеспечения, но и в других отраслях. Он позволяет командам быстро адаптироваться к изменениям в условиях рынка и достигать большей эффективности и производительности.
Тогда вы говорите, что ужин будет готов в 8 вечера. Кстати, я уже давно веду авторские семинары по управлению IT продуктами, если интересно, посмотреть их можно тут. Несмотря на нюансы и особенности методов Scrum, хочется отметить, что он все еще остается самым популярным среди всех гибких методологий. Отдельные его части можно применять в других сферах бизнеса, а принципы могут лечь в основу вашей собственной стратегии развития. Хорошо, что мы применяем Scrum управление, но как расставить приоритеты в огромном списке историй пользователя?
Владелец продукта также отвечает за пользовательские истории и определяет их приоритетность. Название «скрам» происходит из исследования Такеучи и Нонаки 1986 года «Новые правила разработки новых продуктов» . В этой работе говорится, что лучший способ достичь цели — предоставить точные планы небольшой команде. В середине 1990-х годов Кен Швабер и Джефф Сазерленд создали фреймворк Scrum, который помогает разрабатывать новые продукты быстрее и с постоянной обратной связью от клиента. В его основе – эмпирический подход к управлению. Это означает, что видение продукта и даже процесс его разработки не детерминированы заранее, а адаптируются к данным, поступающим в ходе разработки.