Как создать план проекта в scrum за 5 шагов

Если душа просит подробностей

Scrum Master – помощник, а не хозяин

Если взять основное назначение такого понятия, как «чиновник», то оно приведёт нас к некоему человеку, который является слугой народа и занимается устранением любых проблем в отведенной ему области. Звучит утопично, не правда ли? Все мы прекрасно знаем, что происходит, когда некий чиновник перестает быть слугой народа, а то и вовсе не понимает главного смысла своей работы и начинает чувствовать себя просто управленцем, верхушкой треугольника, которому должен служить народ и выполнять все его поручения. Ничего хорошего, конечно, из этого не получается.

Scrum Master играет в кёрлинг

В качестве известного примера Scrum-методологии является игра кёрлинг. Нас она сейчас интересует со стороны Scrum Master.

Основные правила кёрлинга:

1. Игра ведется на специальной площадке с дорожкой и «мишенью».
2. Один игрок производит бросок камня, который катится в сторону мишени.
3. Во время движения камня по льду происходит трение об лёд, и, по факту, камень может либо перекатиться через мишень, либо, наоборот, не докатиться. В данном случае в дело вступают игроки, которые занимаются так называемым «свипингом». Свипинг – это процесс натирания льда, который обеспечивает более быстрое скольжение камня по льду благодаря образующейся тонкой прослойке воды. Свипер (натирающий лёд), по сути, выполняет следующие функции:

• не прикасается к движущемуся камню;
• организует именно ту дорожку для камня, которая максимально точно приведет его к цели.

Можно ли сказать, что свипер двигает камень? Физически его толкает другой игрок и фактически свиперы не трогают камень. Однако именно благодаря свиперам камень движется именно так, как надо.

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

На чем стоит Scrum: роли, элементы и другое

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

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

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

Роли в Scrum

В Scrum всего 3 роли:

1. Скрам Мастер. Это бизнес-аналитик, руководитель проекта. Его задача – организовывать и проводить совещания и следить за тем, чтобы соблюдалась технология Scrum. Еще он снимает противоречия и направляет команду. 

1. Product Owner. А это уже владелец проекта, его функциональный заказчик. Он отвечает за разработку продукта и ставит задачи команде. Это всегда один человек, а не группа лиц.
2. Development Team. Команда из профильных специалистов – программистов, дизайнеров, аналитиков и т.д. Работает по принципам самоорганизации и самоуправления. Типичный размер команды – 7 человек (плюс/минус 2). За результат команда отвечает как единое целое. 

Артефакты (элементы) Scrum

В Скрам задействуется всего 4 артефакта.

Product Backlog

Это список требований, которые необходимо выполнить по проекту. Когда в нем не остается требований, проект считается завершенным. Принимать участие в дополнении этого списка могут все участники команды. 

Sprint Backlog

Список требований на ближайший спринт. Все требования обязательно делятся на задачи и получают оценку. Задачи обычно представляются команде на Kanban-доске.

Sprint Goal

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

Sprint Burndown Chart

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

Ритуалы (процессы) в Скрам

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

Sprint Planning Meeting

Это встреча по планированию спринта, на которой команда выбирает требования из Product Backlog и создает Sprint Backlog. На этой встрече Product Owner отвечает на вопросы участников команды.

Daily Meeting

Ежедневная встреча всей команды – она обязательно должна проходить каждый день, причем в одно и то же время. Интересный момент: на встрече все стоят (потому встречи еще зовут стендапами), потому длительность мероприятия не более четверти часа. В таком коротком временном промежутке каждый должен ответить на 3 вопроса:

• Что я делал вчера?
• Чем я занимаюсь сегодня?
• Какие есть проблемы?

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

Sprint Review

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

Retrospective

Это ритуал по обмену опытом в коллективе команды и конструктивное улучшение процесса разработки. На встрече обязательно присутствие всей команды, вместе со Скрам Мастером, а вот Product Owner сам решает – приходить или воздержаться. На встрече озвучивают ответы на ряд вопросов:

• Какие решения нужно принять, чтобы сделать процесс еще более предсказуемым?
• Какие проблемы мешают выполнять обязательства, возложенные на команду?
• Как еще лучше работать и взаимодействовать с Product Owner’ом?
• Какие ошибки допускаются в команде и почему это происходит?

Другие механизмы аутентификации

• DIGEST-MD5 механизм очень сложен в реализации и тестировании, что делает его слабо совместимым. Уровень безопасности в нём часто не реализуется. Вместо этого повсеместно используется TLS.
• CRAM-MD5 SASL механизм, несмотря на свою широкую распространённость, тоже имеет свои проблемы. В частности, в нём отсутствуют некоторые новые SASL возможности, такие как возможность использования международных логинов и паролей. Также отсутствуют возможности аутентификации сервера и привязки канала.
• PLAIN SASL механизм позволяет осуществить атаку перехвата аутентификации и переноса её на другой сервер, где пользователь имеет такой же пароль. Пересылает пароль в открытом виде в случае, если сеть не использует TLS.

Как внедрить scrum-методологию

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

Кажется, что все просто. Нужны несколько последовательных действий.

 1. Собрать команду

Это первый и основной шаг. Именно от слаженной работы команды зависит качество будущего продукта. Но не так легко собрать кросс-функциональную команду.

 2. Назначить владельца продукта

Это может быть заказчик или его представитель. Владелец продукта будет отвечать за взаимодействие с заказчиком и работать с пользователями на всех этапах разработки.

 3. Выбрать scrum-мастера

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

 4. Создать список требований к продукту

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

 5. Спланировать спринт

Разделить всю работу на периоды. Планировать каждый спринт. Не весь процесс разработки сразу, а только ближайший цикл.

 6. Постоянно анализировать и оценивать результат

Подводить итоги после каждого спринта и оценивать результат. Переходить к следующему спринту, только если довольны результатом предыдущего.

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

Сейчас много scrum-теоретиков, которые плохо понимают, как работать с реальным продуктом

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

Курс «Управление Digital-проектами»

Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.

• Живая обратная связь с преподавателями
• Неограниченный доступ к материалам курса
• Стажировка в компаниях-партнёрах
• Дипломный проект от реального заказчика
• Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Недостатки традиционного подхода к управлению проектами

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

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

Почему? Как отмечает Джефф Сазерленд, Генри Гант придумал такие диаграммы еще в 1910 году. Они получили широкое распространение в Первой мировой войне. Однако, каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится-де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее „окопные“ организационные идеи остаются популярными и по сей день.

В современных условиях эта схема неуместна и похожа на модель Политбюро ЦК КПСС, которое верило отчетам, которые оно получало накануне крушения Советского Союза и которые имели мало общего с реальным положением дел.

Команды в Kanban и Scrum

Основа обеих методологий — Agile, поэтому и в Scrum, и в Kanban работают небольшие автономные команды из 5—9 человек. В командах нет формального руководителя, и никто извне не диктует, как организовывать работу над продуктом.

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

Обе методологии подразумевают, что команда располагается в едином пространстве. Лучше, если это не кубиклы, а общая комната. Главный принцип — свободное общение между специалистами и общие обсуждения.

А вот дальше в Kanban и Scrum начинаются различия.

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

При этом универсальные команды не запрещены.

В Kanban внутри команды нет ролей.

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

Поскольку команда самоорганизуется, у специалистов scrum-команды нет формальной компетенции. Когда необходимо, тестировщик помогает дизайнеру, а аналитик — разработчику.

В scrum-команде помимо собственно специалистов есть две роли.

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

• вести собрания;
• устранять препятствия в работе (если команде мешает перфоратор в соседнем офисе, мастер ищет выход);
• замечать и вытаскивать на поверхность скрытые проблемы;
• отвечать за соблюдение методологии;
• следить за статусом задач.

В свободное от этих задач время скрам-мастер работает так же, как другие члены команды.

Владелец продукта — product owner — определяет ход проекта, он может представлять внешнего заказчика. Владелец знает все о рынке и целевой аудитории. Он ставит приоритеты задачам. Результат работы команда представляет владельцу продукта.

Критерии готовности

Скрам пыта­ет­ся решить одну из самых горь­ких про­блем раз­ра­бот­ки: «Заказ­чик хотел одно, мы это сде­ла­ли, а ока­за­лось, что он хотел дру­гое». В этот момент у раз­ра­бот­чи­ков, дизай­не­ров и всех осталь­ных долж­ны наво­ра­чи­вать­ся слё­зы. 

Скрам пыта­ет­ся решить эту про­бле­му, про­пи­сы­вая кри­те­рии готов­но­сти зада­чи. Заказ­чик и скрам-мастер долж­ны поста­рать­ся чёт­ко опи­сать виде­ние резуль­та­та: на что он дол­жен быть похож, как рабо­тать и т. д. 

Но это всё в тео­рии и в иде­аль­ном мире. В реаль­но­сти заказ­чик всё рав­но ска­жет: «Да, я напи­сал, но сей­час ситу­а­ция изме­ни­лась и нуж­но сде­лать по-другому». 

Критика SCRUM

Скрам кри­ти­ку­ют за излиш­нюю риту­аль­ность: вме­сто того что­бы спо­кой­но рабо­тать и делать задач­ки, люди сидят на встре­чах и зани­ма­ют­ся ретро­спек­тив­ным ана­ли­зом соб­ствен­ной дея­тель­но­сти. 

Скрам кри­ти­ку­ют за мод­ность: все его пыта­ют­ся внед­рить, не вез­де умест­но и не вез­де пра­виль­но. Резуль­тат лег­ко пред­ста­вить. 

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

Но здесь надо пони­мать, что кри­ти­ка скра­ма — это в первую оче­редь кри­ти­ка пло­хой реа­ли­за­ции скра­ма и людей, кото­рые неумест­но его исполь­зу­ют. Донт блейм зе гейм, блейм зе плейа.

Что там с чебуреком?

В иде­аль­ном мире про­шло пять недель, и наши бой­цы сде­ла­ли супер­че­бу­рек, кото­рый без вопро­сов был при­нят руко­во­ди­те­лем и скрам-мастером. Пре­зен­та­ция чебу­ре­ка раз­ле­те­лась по всем СМИ, тыся­чи людей вста­ли в оче­редь на пред­за­каз, а чебу­реч­ная вышла на IPO.

В реаль­но­сти фаун­дер чебу­реч­ной купил ино­мар­ку, попал на ней в ава­рию, инве­сто­ры отка­за­лись финан­си­ро­вать про­ект, коман­да забра­ла нара­бот­ки и раз­бе­жа­лись кто куда: кто-то в круп­ные ком­па­нии, дру­гие — в стар­та­пы, тре­тьи бро­си­ли эту айтиш­ную жизнь и пере­еха­ли в село.

Пото­му что жизнь слож­нее, чем пред­став­ле­ния скрам-мастера о ней. 

Что дальше

Скрам — это гиб­кая мето­ди­ка, прин­ци­пы кото­рой под­хо­дят под раз­ные про­ек­ты, будь это ИТ-компания или чебу­реч­ная. В ста­тье мы рас­смот­ре­ли общие поло­же­ния, и для погру­же­ния в тему реко­мен­ду­ем сле­ду­ю­щие ресур­сы:

• Scrum.org — это сооб­ще­ство скрам-тренеров, кото­рые делят­ся кон­тен­том и пред­ла­га­ют кур­сы по скрам-подготовке. 
• Scrumalliance.org — ещё одно круп­ное сооб­ще­ство с бес­плат­ны­ми мате­ри­а­ла­ми, кур­са­ми для сер­ти­фи­ци­ро­ван­ных спе­ци­а­ли­стов и скрам-конференциями по все­му миру. 

Допол­ни­тель­но посмот­ри­те интер­вью Пав­ла Сви­ри­до­ва, кото­рый руко­во­дит бэкенд-разработкой и обра­ща­ет­ся с кол­ле­га­ми как насто­я­щий скрам-мастер.

Текст и чебу­ре­ки:Алек­сандр Бабас­кин
Редак­тор:Мак­сим Илья­хов
Кор­рек­ту­ра:Ира Михе­е­ва
Иллю­стра­тор:Даня Бер­ков­ский
Вёрст­ка:Маша Дро­но­ва
Соц­се­ти:Олег Веш­кур­цев

Итерации — «рывок» проекта

Когда бэк­лог сфор­ми­ро­ван, коман­да оце­ни­ва­ет силы и опре­де­ля­ет дли­тель­ность одной ите­ра­ции. Ите­ра­ция — это один рабо­чий «рывок», обыч­но в ИТ он зани­ма­ет 1—3 неде­ли. 

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

Ите­ра­ции в скра­ме — это то же самое, что и сприн­ты в про­грам­ми­ро­ва­нии. Подроб­но об этом мы рас­ска­зы­ва­ли в отдель­ной ста­тье. 

Перед каж­дой ите­ра­ци­ей коман­да состав­ля­ет план рабо­ты над выбран­ны­ми поль­зо­ва­тель­ски­ми исто­ри­я­ми. Допол­ни­тель­но про­во­дят­ся еже­днев­ные встре­чи, на кото­рых каж­дый участ­ник отве­ча­ет на три вопро­са: что он уже сде­лал, какие про­бле­мы и чем будет зани­мать­ся даль­ше. На встре­чи не долж­но ухо­дить более 15 минут, поэто­му чис­лен­ность скрам-команд все­гда огра­ни­че­на 5—9 участ­ни­ка­ми. 

Встре­чи ведёт скрам-мастер — опыт­ный член коман­ды. Он высту­па­ет как мене­джер: дела­ет так, что­бы коман­да мог­ла выпол­нить постав­лен­ную зада­чу, коор­ди­ни­ру­ет людей и созда­ёт усло­вия тру­да. Сло­мал­ся ноут­бук — скрам-мастер орга­ни­зу­ет ремонт и най­дёт новый на заме­ну. Про­бле­мы с дед­лай­ном — скрам-мастер заку­пит кофе и поста­вит рас­кла­душ­ку в офис.

Телевидение

Планы рассыпаются в прах. Альтернатива — это Scrum

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

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

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

Слово scrum («схватка») автор позаимствовал из игры в регби. Оно «обозначает метод командной игры, позволяющий завладеть мячом и вести его дальше по полю, а для этого нужны слаженность, единство намерений и четкое понимание цели. „Схватка“ представляет собой идеальную модель полного взаимодействия игроков». И это именно то, что требуется для успешной командной работы.

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

«Каждый спринт планируется предварительно на специальных встречах. Участники оценивают, какой объем работ, на их взгляд, они смогут сделать, скажем, в течение следующих двух недель. Из списка задач, расставленных по приоритетам, они выбирают очередные единицы работы, предназначенные для выполнения, записывают их на стикеры, которые приклеивают на стену. Группа решает, сколько единиц работы они в состоянии выполнить за предстоящий спринт».На завершающей стадии спринта участники снова собираются вместе и показывают друг другу, чего удалось достичь за время совместной работы. Они смотрят, сколько единиц работы, занесенных на стикеры, действительно доведены до конца. Не все удается выполнить? Значит, для этого спринта было отобрано слишком много задач. Бывает наоборот — недостаточное количество задач

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

Когда все участники поделятся своими результатами работы, команда начинает разбирать все, что было сделано за спринт, но делая упор не на обсуждение продукта, а на то, каким образом он делался. «Как улучшить сотрудничество в следующем спринте? Что препятствовало в последнем спринте? Из-за чего мы продвигаемся не так быстро, как хотим?» — вот вопросы, которые они ставят перед собой».

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

Как отмечает Джефф Сазерленд, благодаря использованию Scrum, группы учатся добиваться «сверхэффективности», поднимая свою производительность на триста или четыреста процентов.

Как он это делает?

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

1. Планирование. Все собираются, обсуждают и оценивают задачи, которые будут взяты в работу в этот спринт.
2. Стендапы. Эти встречи, конечно, не обходятся без шуток, но речь тут о другом. Каждый день в одно и то же время вся команда собирается, чтобы в течение 15 минут обсудить ход спринта. Делают они это стоя, чтобы не растягивать удовольствие и не затягивать встречу, отсюда и название. Обычно беседа строится таким образом, чтобы каждый член команды ответил на три вопроса: что было сделано в рамках спринта вчера, что планируется сделать сегодня и есть ли какие-то проблемы по ходу итерации, которые необходимо устранить. Это позволяет сразу узнавать, если что-то идет не по плану, а также создает единое информационное поле.
3. Обзор спринта. Проводится в конце спринта и включает в себя скрам-команду и стейкхолдеров (заинтересованных в продукте сторон). На обзоре команда демонстрирует готовый за спринт функционал и получает обратную связь от стейкхолдеров.
4. Ретроспектива. Команда оглядывается назад и рефлексирует на тему того, что в спринте прошло на ура, а что не удалось и почему, придумывает что и как можно улучшить в последующих спринтах.

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

Он может быть сформулирован и помещен в task-трекеры (Jira, trello), размещен в виде стикеров на стене или быть в каком-то другом формате, все зависит от предпочтений владельца продукта и команды. А груминг бэклога – это процесс уточнения деталей по задачам, их формулирование и подготовка к планированию, определение ценности, которую они принесут пользователю. Регулярный груминг – залог здорового бэклога.

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

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

Например, с кем-то лучше вести диалог в игровой форме, кому-то удобнее рисовать на доске, а кому-то лучше работается в строгой деловой обстановке

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

Методы приоритизации задач

Story Mapping

Где и как применятьПлюсы Story Mapping

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

Value & Effort (или Lean Prioritization) для идей

1. Значимость фичи
   Значимость каждой фичи с точки зрения бизнеса — это примерно то же, что и «ценность для бизнеса» в обычном бэклоге. Величина оценивается в условных единицах, лучше всего — в деньгах. В целом, любой параметр, который вы оптимизируете, можно брать за Value. Это может быть количество пользователей, которых вы привлечете в проект, или уменьшение оттока пользователей в проекте.
2. Количество усилий, которое необходимо затратить на каждую из фич
   Тоже можно считать, что это оценка в часах (estimate), как в бэкглоге. Но можно измерять и в Story Point-ах (сравнительная оценка требований относительно друг друга) или в человеко-часах.

Где и как применять

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

MoSCoW

M — Must HaveS — Should HaveC — Could HaveW — Would Have
Пример
Допустим, вы разрабатываете автомобиль. Must Have будут колеса, руль, ходовая часть, двигатель. Should Have — освещение ночью, сидения вместо стульев, двери и всё такое прочее. Could Have — автоматическая коробка передач и так далее. Таким же образом можно разобрать любой проект, где Must Have будет эдаким MVP.

Kano

Пример
Вы планируете делать следующие релизы и опрашиваете группу людей. Кто-то из них может сказать: «А вот вы там платную функцию сделали, из-за неё продукт стал хуже, фи!» Только потому, что она за деньги, эта функция покажется кому-то ненужной. Хотя для бизнеса это может быть ключевая вещь, которая приносит прибыль.

Классический метод приоритизации баг-листов

Критические багиКритичное юзабилити и забытые фичиНекритичные багиНекритичное юзабилитиТекстыХотелки / не будем делать / на усмотрение менеджера