Все что нужно знать про scrum

Оценка внутри беклога

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

Допустим, в сервисе есть user story типа «Регистрация пользователя». Возьмём её за образец и дадим ей ценность в 1 бал или один story point. Каждый участник команды напишет собственную оценку к остальным историям пользователя в списке, учитывая задачу, взятую за образец.

Выше мы видим, что «Фотогалерея с довольными клиентами» оценивается 0,5 story point, т. е. она меньше образца в 2 раза. Все эти оценки члены команды проставляют анонимно, например, на стикерах, написав и перевернув.

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

Таким образом, участники команды должны прийти к общему решению, поэтому оценки выравниваются. В результате получается разбивку по всем user stories с учётом эталонной оценки.

Потом задачи набираются в спринты (с учётом приоритетов), и начинается работа. По результатам завершённых спринтов становится ясно, сколько story point-ов может выполнить команда. А по итогам ретроспективы находятся точки роста.

Развитие ответственности в команде

Как Scrum-мастеру нужно организовать работу, чтобы весь коллектив работал на одну цель, и чтобы все между собой общались?

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

Первая встреча, которая приучает к общей ответственности, — это Обзор спринта в конце итерации (итерации работы в Scrum называются спринтами и длятся 1-4 недели). На обзоре вся команда презентует заказчику результат. На этой встрече заказчик впервые увидит, что сделала команда за прошедшую итерацию, и даст обратную связь: что, по его мнению, стоит добавить, усилить или убрать в этой главе книги, а что стоит учесть при написании следующих глав.

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

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

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

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

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

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

Это важно, поскольку результат общий, и на обзоре спринта отмолчаться не удастся — каждый должен будет рассказать о своем вкладе в общий результат

Все это должно быть сделано на планировании спринта. А дальше каждый писатель, имея «канву» будущей главы, должен будет проработать своего персонажа в связке с другими персонажами.

Анализ ситуации

Текущие метрики казались мне слишком “шумными”, а некоторые – скорее даже вредными:

• Focus Factor стимулировал команду либо брать очень много задач рискуя облажаться, либо завышать оценки, если задачи спринта не могли обеспечить полную занятость всех разработчиков команды. Отдельную проблему он создавал для инженерной команды состоящей из «ветеранов компании», которая с одной стороны следит за стабильностью прода, а с другой занимается продуктовыми задачами, которые требуют полного понимания всей системы.

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

• Митапы по факту проходили недостаточно часто, чтобы хоть как-то влиять на турнир. Время между спринтами команды предпочитали тратить на проработку будущих спринтов, внутренние улучшения системы или саморазвитие.

• Оценки демо от stakeholder-ов были просто очень волатильными 🙂

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

Планирование Спринта

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

Планирования Спринта члены Команды ищут ответы на следующие вопросы соответственно:

• Что будет разработано в Инкременте, являющимся результатом работы следующего Спринта?
• Как максимально эффективно выполнить работу по созданию Инкремента?

Часть первая: Что будет сделано в этом Спринте?

В этой части Команда Разработчиков пытается спланировать функциональность, которая будет разработана во время Спринта. Владелец Продукта представляет Команде Разработчиков упорядоченный Журнал Продукта и вся Скрам Команда старается достичь единого понимания работы, которую предстоит проделать на протяжении Спринта.
Входными для этой встречи являются Журнал Продукта, последний разработанный Инкремент продукта, возможности Команды Разработчиков, а также последний показатель ее продуктивности. Количество элементов из Журнала Продукта, которые Команда способна выполнить до окончания Спринта определяется самой Командой. Только Команда Разработчиков может реально оценить объем работы, который она в состоянии завершить до окончания Спринта.
После того, как Команда Разработчиков спрогнозирует элементы Журнала Продукта, которые она выполнит в данном Спринте, Скрам Команда приступает к формированию Цели Спринта. Цель Спринта – это цель, которая будет достигнута в результате Спринта благодаря реализации Журнала Продукта и которая указывает Команде Разработчиков, почему она работает именно над этим Инкрементом функциональности.

Часть вторая: Как выбранная работа будет проделана?

После того, как объем работы Спринта определен, Команда Разработчиков решает каким образом на протяжении Спринта воплотить отдельную функциональность в “готовый” Инкремент продукта. Требования Журнала Продукта, выбранные для выполнения во время ближайшего Спринта вместе с планом их разработки, называют Журналом Задач Спринта (Sprint Backlog).

Как правило, Команда Разработчиков начинает планировать систему и работу, благодаря которой Журнал Продукта можно превратить в работающий Инкремент продукта. Работа может быть разной степени трудоемкости и сложности. Однако обычно во время Планирования Спринта Команда Разработчиков планирует такой объем работы, который она в состоянии выполнить за Спринт. До окончания этой встречи работа, запланированная Командой Разработчиков на первые дни Спринта, разбивается на требования, которые можно выполнить за день или менее. Команда Разработчиков сама организовывает свою работу, планируя поэтапность выполнения требований из Журнала

Спринта как во время встречи по Планированию Спринта, так и, при необходимости, на протяжении всего Спринта.
Владелец Продукта может присутствовать на второй части Планирования Спринта, чтобы иметь возможность объяснить задания из Журнала Продукта и, при необходимости, помочь найти альтернативы. Если же Команда Разработчиков решает, что у нее слишком много, либо слишком мало работы, она может повторно обсудить требования Журнала Спринта с Владельцем Продукта. Команда может пригласить людей со стороны, чтобы они посоветовали что-то с технической или же экспертной точки зрения.
До окончания встречи по Планированию Спринта Команда Разработчиков должна быть в состоянии объяснить Владельцу Продукта и Скрам Мастеру, каким образом она собирается работать в качестве самоуправляемой команды, чтобы достичь Цели Спринта и создать ожидаемый Инкремент продукта.

Цель Спринта

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

Оценка историй пользователей внутри беклога

Мы сформировали беклог, но как оценить истории пользователя с точки зрения сложности? Для этого используется метод эталона. Это относительная оценка, которая позволяет понять потенциал команды и приблизительно оценить ресурсы.

Мы берем одну user story из беклога за образец и присваиваем ей ценность единицу (story point). Дальше оцениваем другие истории пользователя с точки зрения выбранной.

Например, в нашем сервисе есть история пользователя “Регистрация пользователя”. Мы берем ее за образец и даем ценность в один бал или один story point (так его называют в гибких методологиях). Каждый участник команды пишет свою оценку к остальным историям пользователя в списке с учетом задачи, которую взяли за образец и отдает ее скрам-мастеру.

В примере выше “Фото галерея с довольными клиентами”  стоит 0,5 story point, то есть по сложности она в 2 раза меньше нашей эталонной истории “Регистрация пользователя”. Все оценки участники команды ставят анонимно, можно на стикерах писать и переворачивать.

Когда все проставили оценки, результаты открываются. Скрам-мастер организует обсуждение между участниками, которые поставили самые крайние оценки. На рисунке выше, это 2 и 8. Они договариваются между собой и запускается второй раунд голосования.

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

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

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

Нюансы

Если вы решили внедрить Scrum у себя в проектах, то учитываете следующие нюансы:

• Нет ориентации на клиента. Не все заказчики будут готовы к определенным стандартам Scrum.
• Не учитывается система реагирования на риски. Команда может заложить какое-то доп.время на выполнение задач, но при сильных отклонениях от плана, система встанет.
• Команда и человеческие качества. Так как упор сделан на самоорганизующуюся команду, то все участники должны обладать высоким уровнем ответственности и соответствующей мотивацией. Создание такой команды, очень сложная задача.
• Скрам-мастер. Человек отвечающий за процессы и мотивацию команды, должен чувствовать всех участников и связи внутри группы. Это редкий специалист, которого также тяжело найти на рынке.

Мини-справочник Scrum

ScrumProduct Owner

• определение элементов бэклога продукта;
• правильное расположение элементов для оптимизации достижения цели;
• обеспечение понятности и прозрачности Product Backlog;
• обеспечение прозрачности и понятности требований, над которыми предстоит работать всей Scrum Team;
• общая оптимизация для достижения наибольшей ценности работы Development Team;
• ответственность за понимание бэклога командой разработки.

Scrum TeamScrum MasterDevelopment TeamStakeholdersUserProduct BacklogEpicUser StoryTaskSprintSprint GoalSprint Planning MeetingScrum PokerStory PointsDaily Scrum MeetingSprint ReviewSprint Retrospective MeetingDefinition of Done (DoD)VelocityBurndown ChartBurnup ChartAbnormal Termination

6 Month Later…

Проведя сезон турнира по новым правилам были замечены следующие изменения.

Команды стали стабильнее работать

Когда гонка за story points была официально отменена, focus factor и story points превратились из внешнего инструмента мотивации во «внутреннюю красную лампочку команды», которая загоралась каждый раз, когда появлялся риск облажаться. Velocity в спринтах перестало колбасить, и подрос процент успешно вышедших в релиз историй.

Команды стали чаще брать в спринты аналитические истории

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

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

Команды стали поддерживать друг друга

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

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

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

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

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

Так происходит и в бизнесе. Если в период подъема экономики какие-то недостатки конкретного бизнеса сглаживаются, остаются незамеченными и даже не слишком мешают работать, то в периоды экономического спада они становятся теми самыми «тонкими местами», которые приводят к снижению прибыли, к определенным проблемам, а иногда даже к полному краху всего бизнеса.

Что такое Scrum

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

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

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

OOPSLA 95

В октябре 1995 года на конференции OOPSLA (“Object-Oriented Programming, Systems, Languages & Applications”) в Остине, штат Техас, Кен Швабер и Джефф Сазерленд впервые представили Scrum в своем докладе дали первое описание Scrum-процесса.

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

Обратите внимание: речь про “существующие системы” или работающие производственные прототипы. Ни слова ни про продукты, ни про работу в большой зоне неопределенности

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

А вот как выглядел Scrum-процесс на картинке:

Весьма непривычно для современного читателя. Где Ретроспектива? Что за Wrap и Adjust? Процедуры Planning & System Architecture вынесены за пределы рабочего процесса.

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

Книга Agile Software Development with Scrum

В которой ScrumMaster становится владельцем процесса, методологом и менеджером.

В 2001 году Кен Швабер и Майк Бидл опубликовали книгу «Agile Software Development with Scrum», которая оказалась поворотной вехой в истории Scrum. В этой книге детально описан Scrum-процесс, роли, артефакты, встречи, и принципы работы. Это было всеобъемлющее, подробное руководство о том, как правильно делать Scrum. В обиходе многие называли эту книгу “Scrum Book”, что само по себе о многом говорит.
По сравнению с версией 1998 года, роль ScrumMaster сильно меняется, и мера его ответственности значительно возрастает.

Если в 1998 году это был обычный тимлид, которому вменили в обязанность быть еще и секретарем команды, и разрешать Блокеры, то начиная с 2001 года на ScrumMaster возлагается вся ответственность за успех Scrum.

Буквально:

Ответственность ScrumMaster’а была велика:

• Работает с клиентами и руководством, чтобы выбрать и назначить Владельца продукта;
• Управляет формированием состава Скрам-команды (найм, ассессмент);
• Работает с Владельцем Продукта для создания бэклога продукта;
• Работает со Скрам-командой над планированием спринта;
• Проводит Ежедневные Scrum-митинги;
• Отвечает за определение возможных препятствий, будучи активным слушателем Ежедневных Scrum-митингов и анализируя показатели скорости команды (velocity chart);
• Отвечает за устранение препятствий;
• Взаимодействует с руководством для улучшения процессов;
• Принимает решения. Может даже принять решение за всю команду.

По сути, ничто, связанное со Scrum, не могло произойти без согласия ScrumMaster.

ScrumMaster версии 2001 года “сидит на водительском сиденьи”, и управляет Scrum-процессом и Scrum-командой так же как водитель управляет автомобилем.

Причем, на роль ScrumMaster надо было поставить специально выделенного человека с широкими административными полномочиями. Книга явно указывает нам, что на эту роль должен быть назначен кто-то из перечисленных: Team Leader, Project Leader, Project Manager.

Если попытаться подытожить, кем был ScrumMaster в книге 2001 года, то правильно будет сказать, что он был владельцем процесса, методологом, и менеджером.

Интересно, что в  Scrum Guide 2020, спустя 19 лет, тоже появилась похожие формулировки:

Но есть разница. В 1998 году для описания образа действий ScrumMaster используется слово “enforce” — буквально “принуждать”.

А в 2020-м в ход идут слова “coaching”(коучинг) и “helping”(помогать) и другие слова, которые указывают на поддерживающее поведение.

Гуманизация роли за 19 лет налицо

Мне кажется, что такое определение роли ScrumMaster было связано с тем, что в 2001 году мало кто знал что такое Scrum, и это была прям такая экзотика с точки зрения привычного менеджмента, что внедрять его можно было только директивно, имея полномочия и власть. Иначе он просто не “заводился” и его отторгали. И конечно, нужен был какой-то эксперт, который бы наладил все как надо, не допуская отклонений и искажений идеи.

Позже, знания о практике применения Scrum распространились очень широко, и нужда в эдаком “супермене” от Scrum, отпала. Часть инструментов стала обычным делом, и поэтому ответственность постепенно передавалась в команду.

Как работает Scrum

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

Роли

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

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

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

Команда отвечает за реализацию задач из бэклога спринта. Крутая scrum-команда сама определяет, какие задачи как именно нужно делать в рамках спринта, чтобы его ценность была выше. Как водится в Agile, участники команды делятся друг с другом своими знаниями, чтобы можно было снизить вероятность чьих-то ошибок. Совместно с владельцем продукта команда создаёт план работ на каждый спринт.

События

В основе Scrum лежат спринты, но с ними связано ещё несколько важных событий, без которых Scrum не Scrum.

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

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

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

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

При старте команд нужно уделить особое внимание организационной структуре

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

Ниже вы найдете мой обычный чек-лист, который помогает оценить готовность компании к Скраму:

Артефакты

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

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

2. Бэклог спринта — выбранный на спринт набор элементов бэклога продукта для достижения определённой командой цели спринта с учётом имеющихся знаний и приоритетов.

3. Инкремент — протестированная и работоспособная версия с добавочной ценностью для клиента, которая соответствует критериям завершённости.

0–9 баллов — низкий результат, характеризующий сложность существующих подходов в части управления и планирования содержанием работ. Данная сложность может быть причиной увеличения времени ожидания ответа на запрос внутри команды, а также причиной низкой концентрацией на актуальных задачах.

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

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

Новый формат турнира

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

Ведение статистики команд

В каждом спринте для каждой команды считаются следующие метрики:

• Целочисленный процент сданных Product Owner-y историй от числа взятых за каждый спринт с округлением вверх к следующим 25% (назовём это done rate). Подсчитывается на момент отправления «релизного поезда» каждого спринта и далее не изменяется. Коэффициент 25 и округление вверх были выбраны эмпирически, чтобы немного сглаживать разное количество историй, которые бывают у команд (в среднем их около 4) и не сильно наказывать за небольшие провалы.

• Список спринтов с дефектами. Может увеличиваться в пределах текущего сезона.

• Было ли демо команды признано «лучшим демо спринта». Подсчитывается после проведения демо всеми командами спринта и далее не меняется.

Учёт числа спринтов с дефектами

Если на проде находится ошибка, которая была привнесена командой в рамках в текущем сезоне, то руководству отдела разработки (руководители направлений и Product Owner) необходимо принять коллегиальное решение о засчитывания дефекта в статистику одной из команд. Для этого необходимо:

1. Определить спринт, в рамках которого появился дефект.

2. Заслушать мнение самой команды о сложившейся ситуации

3. Коллегиально принять решение и объяснить его команде.

Если дефект засчитывается команде, и ранее этот спринт команды дефектов не содержал, то ей увеличивается метрика «количество спринтов с дефектами».

Подведение итогов турнира

Победившая команда получает:

• Переходящий кубок «Лучшая команда разработки», который размещается рядом с расположением членов этой команды. Выдается на следующий сезон.

• Возможность распорядиться денежным фондом текущего сезона турнира команд.

Похожие записи:

Ищем вдохновение вместе с дизайнерами smmashing media: 5 источников классных референсов Открыть расчетный счет в альфа-банке для ип Хронология в google картах Ребрендинг: что это простыми словами, примеры ребрендинга в россии и в мире Сдача электронной отчётности через интернет для налоговых (уполномоченных) представителей Перечень учредительных документов юридического лица