Scrum time: Система управления проектами на основе Agile / Scrum

Daily Scrum Meeting / Ежедневный скрам

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

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

Разговор тренера при этом может состоять, например, из таких фраз: «главный нападающий практически всегда бежит по данной траектории, ты находишься в этой позиции, тебе для перехвата слишком далеко бежать, смени свою изначальную позицию и держись её до следующего тайм-аута»; «я заметил, что тебе тяжело пройти вот эту дистанцию во время нападения, в чем проблема?» и так далее. Daily Scrum Meeting выглядит примерно так же, хотя, может, и без такого напряжения. Так или иначе, цель такого совещания – скорректировать и понять работу команды, узнать, какие у неё текущие проблемы, и предложить варианты решения. Чтобы иметь структурированную систему в методологии Scrum разработаны три простых вопроса, которые должны звучать на Daily Scrum Meeting.

Три главные фразы Daily Scrum Meeting

1. Что ты делал вчера?
2. Что ты будешь делать сегодня?
3. Какие проблемы есть у тебя на пути?

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

• Мне нужна помощь в отладке программы;
• Техническая поддержка офисного продукта не перезванивает уже второй день;
• Заказанное программное обеспечение так ещё и не пришло;
• Мой стул сломался и мне приходится работать стоя!

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

Кто участвует в Daily Meeting?

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

В Daily Scrum Meeting всё точно так же. Участие в 15-минутной встрече обязательно для всей Development Team, также участвуют Scrum Master и Product Owner. Иные лица, будь то заказчики, маркетологи или кто-то ещё, могут присутствовать, однако без права говорить.

Варианты проведения Daily Scrum Meeting

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

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

Возможные проблемы на Daily Scrum Meeting

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

Диаграмма сгорания задач / Burndown Chart

В большинстве своем мы привыкли к графикам, идущим вверх, что означает положительную динамику. Однако они могут идти и вниз и также показывать положительную динамику. Одним из таких ярких примеров является «Диаграмма сгорания задач» (Burndown Chart). Само сочетание Burn Down дословно переводится как «гореть вниз» и, действительно, это так. Данный график является основным средством для отслеживания выполненных задач в спринте или во всём проекте. Хотя, по сути, он может использоваться как угодно, но мы его рассматриваем внутри методологии Scrum.

Пример Диаграммы сгорания задач:

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

Красным отмечена реальная история выполнения задач.

По шкале Y отмечают количество запланированных баллов (в данном случае), идеальные часы, количество задач и так далее.

По шкале X отмечают количество дней до окончания Sprint.

Как может показаться на первый взгляд, данная «Диаграмма сгорания задач» (Burndown Chart) служит всего лишь для самоконтроля и самоотчета, однако её использование может рассказать об очень многом.

Читаем «Диаграмму сгорания задач» / Burndown Chart

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

1. Burndown Chart: Слишком рано

По «Диаграмме сгорания задач» (Burndown Chart) отчетливо видно, что команда все задачи выполнила раньше срока. Такая ситуация тоже не является позитивной, так как это означает ряд совершенных проблем:

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

В случае такой проблемы чаще всего Scrum Master спрашивает команду о возможности добавления дополнительных задач из Product Backlog.

2. Burndown Chart: Опоздали

Также один из видов негативных диаграмм сгорания задач.

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

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

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

3. Burndown Chart: Без оценок

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

4. Burndown Chart: Конечная оценка

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

5. Burndown Chart: Zero

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

6. Burndown Chart: Релаксирующая команда

Этот пример диаграммы сгорания задач уже значительно лучше, нежели другие, ведь в нём можно увидеть, как усовершенствовать команду. Возможные проблемы здесь такие же, как и в пункте «Слишком рано», но Scrum Team решили не заканчивать Sprint раньше, а более расслаблено продолжить работу, что также является ошибкой.

7. Burndown Chart: Совершенствование

Scrum Team на текущих показателях выглядит достаточно хорошо. По линиям видно, что в самом начале были трудности, но во время Daily Scrum Meeting все вопросы вскрывались и Scrum Master исправлял работу, ведя команду к цели.

Также, возможно, группа делала принципиальное ускорение для достижения цели.

Ещё одной причиной, к примеру, может быть то, что команда брала дополнительные задачи.

8. Burndown Chart: Опыт

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

9. Burndown Chart: A++

Бесконечно можно смотреть на три вещи: как горит огонь, как течёт вода и как строится идеальный график =).

Испытать как работает Диаграмма сгорания задач
Можно бесплатно в Scrum Time

Product Backlog

Как-то в статье о Sprint мы писали, что это основа методологии Scrum, и всё вокруг него крутится. Сегодня самое время сказать:

«А сам-то Sprint то крутится вокруг Product Backlog и производной – Sprint Backlog!».

На самом деле Product Backlog должен быть понятен абсолютно всем (за что и отвечает Product Owner). Прозрачность Product Backlog помогает разобраться в нём как команде, так и заказчику. Сделать его таким – сродни искусству. Порой заказчики и специалисты говорят совершенно на разных языках, и данный «языковой барьер» главным образом мешает работе, а ещё, более того, таит в себе опасности. Если где-то какое-то недопонимание было изначально, и интерпретация желаний заказчика была не совсем верная, то по прошествии спринта будет готовый продукт, который, представьте себе, сильно ушел в сторону. Малейшее отклонение в ядре продукта может привести к его неисправимой эволюции в другую сторону, так как весь остальной код может базироваться на ошибочном изначальном.

Сам Product Backlog состоит из элементов бэклога или, как модно называть, User Story. По сути, это список желаний, или, на сленге разработчиков – «хотелок». Сами эти «хотелки» должны быть упорядочены по степени важности.

Но довольно слов, давайте посмотрим, как это выглядит:

Расшифровка полей Product Backlog:

ID – всем разработчикам тут всё понятно. Уникальный номер задачи, который идет по порядку.

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

Важность – в каком порядке выполнять задания, чтобы как можно скорее строился готовый продукт, а потом только расширялся и улучшался. Каждая компания делает свои стандарты по шкале оценок. Например, может быть от 10 до 150.

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

Демонстрация – чтобы доказать законченность работы, надо продемонстрировать результат. Что хочет видеть Product Owner и заказчик? Это и необходимо описать в данном поле.

Релиз – по сути, это наглядная демонстрация того, что хотелось бы видеть после первого спринта. По мере роста очков важности бывает тяжело определить, на чем остановиться, если есть какие-то пограничные состояния. Например, Product Owner по Velocity знает, на что способна команда и как идет её работа. Он рассчитывает по Story Points и по «Важности», сколько примерно команда сможет выполнить за одну итерацию. Бывает так, что вроде следующий пункт уже выходит за рамки возможностей команды, согласно Velocity, или, наоборот, можно еще что-то впихнуть, но стоит ли? Product Owner может оценить, что для логичной законченности продукта на эту итерацию, скажем, не надо делать пункт, который ещё можно включить, и ставит на нём «Релиз 2».

Примечания – всегда полезно иметь эту графу. Она может быть пустая, а может расширять понимание задачи.

На самом деле в Product Backlog могут быть и другие поля, расширяющие понимание задач и всего проекта:

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

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

Сначала необходимо попытаться написать это всё по строчкам: 1 I A, 2 II B, 3 III C, 4 IV D, 5 V E – и засечь, сколько времени это займет. Можно представить, что арабские цифры – работа с базой данных, римские – с файловым сервером, буквы – это API. То есть вам нужно сначала сделать что-то по базе, потом по файлам, потом по API. Теперь, по тесту, нужно написать всё тоже самое, только по столбикам: 1 2 3 4 5, I II III IV V, A B C D E. Так, конечно, получится намного быстрее, так как мозгу нет необходимости переключаться с одной системы на другую, и он на автомате работает гораздо лучше в одной системе координат.

Привязываясь к данному примеру с компонентами, представьте, что у команды есть возможность работы не с такими данными: 3 III C, 5 V E, а скажем, с такими: 1 2 3 4, A B C. Такая работа будет намного продуктивней.

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

ID-взаимосвязь – связь с чем угодно. Бывает, что нужно завязать задачи бэклога с какими-то сторонними или внутренними сервисами, например, отдельный баг-трекер.

Возвращаясь к разделению на категории, всегда возникает вопрос: а как поступать, если имеются несколько команд разработки? Сделать для каждой своего Product Owner и свой Product Backlog? Может лучше иметь один Product Backlog и одного Product Owner?

На само деле существуют разные подходы, используемые компаниями.

Подход №1 – один Product Owner и один Product Backlog

Такой подход похож на ситуацию, когда капитаны команд в какой-либо игре отбирают себе игроков. Сначала один капитан выбирает себе самого сильного игрока, потом второй самого сильного из оставшихся и так далее. Здесь происходит похожая ситуация. Product Owner располагает задачи из Product Backlog в порядке важности, и команды начинают разбирать себе задачи также в порядке важности. Деление обычно происходит по тематике (для этого удобно использовать соответствующую графу в Product Backlog).

Команды могут поторговаться за какие-то задачи, сгруппировать их у себя, поменять приоритеты.

Когда распределение закончено, каждая команда занимается только своей стеной задач, то есть своим Sprint Backlog.

Подход №2 – один Product Owner и несколько Product Backlog

Всё, собственно, тоже самое, только задачи на команды раздает Product Owner. Тут, конечно, сразу возникают резонные замечания, одно из которых: «Зачем владельцу продукта распределять задачи по командам? Команды сами лучше решат, кто что сделает, ведь Product Owner может не знать тонкостей реализации» – и это вполне резонно. Однако в некоторых случаях рабочего процесса это может вполне работать. Благодаря такому подходу сама подготовка и формирование Sprint Backlog происходит значительно быстрее. Если на каком-то производстве заранее известно, какой команде какой набор лучше дать – этот способ подойдет как нельзя лучше.

Подход №3 – несколько Product Owner и несколько Product Backlog

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

Тренироваться составлять Product Backlog на бумаге не всегда эффективно. Мы предлагаем Вам попробовать это в боевом режиме в системе Scrum Time, тем более это бесплатно.

Product Owner

Product Owner является неким связующим звеном между заказчиком и командой разработки. Окончательная инстанция по
принятию решений в Scrum Team – это как раз и есть Product Owner.

Самая главная ответственность Product Owner – это создание и контроль Product Backlog.

Основные обязанности и ответственность Product Owner при управлении Product Backlog:

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

Стоит отметить, что Product Owner может сам выполнять все вышеперечисленные обязанности, а может отдать их на
исполнение Development Team, однако всегда остается ответственным.

Решения Product Owner по реализации тех или иных задач должны исполняться. Все свои решения владелец продукта транслирует через тот Product Backlog, который получается. Важно при этом помнить, что влиять на саму работу Development Team он не может и порой даже не присутствует на планированиях, например, на Scrum Planning Meeting,
однако он всегда должен находиться рядом, чтобы в случае возникновения вопросов их можно было оперативно решить.

Жизнь Product Owner внутри Scrum Team

Для Product Owner важно писать задачи не со стороны того же программирования, а со стороны требований заказчика – «хотелок». Например, система выборки журнала работает медленно, хотелось бы быстрее. Если Product Owner напишет: «Произвести оптимизацию базы данных», то это неправильный подход. Проблема ведь может быть и не в базе данных, или не только в ней. Поэтому описание всех задач идет на простом языке, например: «Ускорить выдачу журнала». Для идей решения проблем Product Owner (да и любой другой) есть поле «Примечание» в Product Backlog.

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

Возвращаясь к тому же Planning Meeting, можно часто заметить, что как бы ни старался Product Owner в заполнении Product Backlog, всегда появляются спорные моменты. Самая основная проблема – переоценка Story Points. Product Owner порой не может предусмотреть всех технических аспектов того или иного действия (да и не должен), и, давая задачу, он может не предусмотреть каких-то дальних сложных взаимосвязей, которые увеличивают срок выполнения работы в несколько раз. В таком случае происходит пересмотр оценок этой задачи, а это может повлиять на выход общего количества Story Points за пределы возможностей команды, оцененные по Velocity.

Подробнее о данной проблеме написано в статье про Sprint Backlog.

Product Owner нужен не только на начальном этапе, как может показаться, но и на протяжении всего Sprint.
Взаимосвязь с командой правда проходит только односторонняя – команда, по мере возникновения вопросов, вправе привлекать Product Owner. Чаще происходит так, что время, необходимое для привлечения Product Owner, зависит от общего времени, проведенного с командой. Про такое говорят: «Команда созревает для вопросов к Product Owner».

Также важной обязанностью Product Owner является остановка спринта. В статье Abnormal Termination / Остановка
спринта подробно описано это действие.

Есть желание побыть в роли Product Owner? Scrum Time дает такую возможность совершенно бесплатно

Planning Poker (Scrum Poker)

Planning Poker или Scrum Poker, пожалуй, одно из важнейших мероприятий в методологии Scrum или любой гибкой технологии разработки. Практически всегда перед командой встает вопрос:

Как оценить эту задачу?

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

Что собой представляют карты для Planning Poker / Scrum Poker

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

Есть несколько вариантов карт, которые пользуются большей популярностью.

1 вид популярной колоды для Planning Poker:

Карточки представляют собой последовательность чисел Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89.

2 вид популярной колоды для Planning Poker:

Данный вид имеет следующие значения: 0, ?, 1, 2, 3, 5, 8, 13, 20, 40, 100, «?», «Чашка кофе». Знак вопроса означает, что «игрок» не понял до конца смысл обсуждаемого или не обладает достаточной информацией, чтобы оценить её. Чашка кофе, в свою очередь, означает «Я устал, давайте передохнём».

Как проходит Scrum Poker / Planning Poker

Один человек является ведущим, и он не участвует в «игре». На обсуждение выносятся поочередно пункты, которые необходимо оценить. Каждый пункт позволено обсудить и провести обзор без оценочных данных. После этого каждый член команды выбирает карточку и кладет её рубашкой вверх. После того, как все положили карты – они вскрываются. Идеальным состоянием считается, если разброса в значениях практически нет. Как можно догадаться, такое бывает не всегда. Так или иначе в выброшенных картах будут наименьшие и наибольшие значения. Людям, выбросившим такие карточки, дают слово, и они высказывают своё мнение, почему оценка была именно такой. Это позволяет всей остальной команде получить больше информации и задуматься, услышав доводы, либо объяснить свою точку зрения выбросившим высокие или низкие позиции.

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

Основные проблемы в использовании Planning Poker

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

Эффект привязки в Scrum Poker

Главной проблемой всегда был эффект привязки, который может проявлять себя по-разному. Главной ошибкой, вызывающей этот эффект, является открытое обсуждение оценок. Если тот, кто начинает обсуждение, говорит примерно следующее: «Я считаю, что данное задание займет 18 часов разработки», то так или иначе все будут акцентированы на сроке в 18 часов, и тот, кто считал, что задача будет решена за 2 дня, может подумать, что на самом деле и 18 часов будет достаточно, а тот, кто думал про 5 часов, может подумать, что не учёл все нюансы. С одной стороны, консенсус достигается быстрее, но, с другой стороны, он не будет эффективным, а эффективность – это то, для чего мы всё это делаем. В такой ситуации в результат войдет мнение, скорее, одного человека, а не команды.

Не выделяться из толпы

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

Принципы Scrum: 5 основных и важных

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

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

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

Работа производится небольшими командами (в среднем от 5 до 9 человек). Такое количество людей и вправду оптимально для выстраивания правильного микроклимата во время рабочего процесса. Этот принцип приводит к тому, что небольшие группы удобнее контролировать и совершенствовать. Члены группы обычно всегда многофункциональны. С одной стороны, каждый из них имеет определенную специализацию, а с другой, каждый может подстраховать коллегу или даже взять работу на себя.

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

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

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

Sprint Retrospective Meeting – Ретроспектива в Scrum

Sprint Retrospective Meeting, наравне со Sprint Reviews Meeting,
проводится в последний день спринта. Задачи, в отличие от Sprint Reviews Meeting, ставятся совершенно иные. Если обзорная встреча имеет цель посмотреть на результат продукта, то ретроспектива призвана посмотреть на результат команды.

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

Ретроспектива Scrum – очень полезное мероприятие и не стоит к нему относится посредственно. В качестве примера можно привести автомобиль и замену его масла. Грубым интервалом замены масла считается порядка 15 000 км., то есть через такое число километров необходимо слить старое масло и залить новое, иначе качество работы двигателя может ухудшиться или, более того, это может привести к серьезной поломке автомобиля и даже его выходу из строя. Scrum Team также нуждается в подобной «замене масла», чтобы работа всегда была в наивысшей степени эффективной.

Большинство Scrum Team переходят к ретроспективе (Sprint Retrospective Meeting) сразу после обзора (Sprint
Review Meeting). Вся команда Development
Team, а также Scrum
Master и Product
Owner участвуют в этом процессе. Хотя стоит отметить, что участие Product Owner необходимо не во всех видах Sprint Retrospective Meeting. У ретроспективы нет очень сильных временных ограничений, но есть формула золотой середины: длина Sprint Retrospective Meeting равна 75% часа (45 минут), умноженные на количество недель в Sprint. Если у вас четырехнедельный Спринт, то время на ретроспективу в Scrum следует выделить равное 60 * 0.75 * 4 = 180 минутам. То есть на ретроспективу следует потратить 180 минут, что равняется трем часам. Иногда, правда, некоторые команды не придерживаются этой формулы и просто отводят час для такого анализа, а если происходят горячие споры, то время увеличивается.

На самом деле способов проводить подобные встречи достаточно много. По этому поводу даже написаны целые книги, например «Agile
Retrospectives: Making Good Teams Great» и «Project Retrospectives: A Handbook for Team Reviews».

Самым распространенным и простым способом (что не отменяет его эффективности), является способ Start-Stop-Continue.

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

• Начать делать;
• Прекратить делать;
• Продолжить делать.

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

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

Пример Sprint Retrospective Meeting в разработке интернет-магазина

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

После завершения Sprint и проведения Sprint Reviews Meeting, команда Scrum собралась для обсуждения эффективности её работы, которая была оценена каждым самостоятельно.

Scrum Master решает задать вопрос каждому лично и узнать ответы на все три вопроса.

Участник №1:

1. Я считаю, что команде следует начать использовать более развернутые листы тестирования
2. —-
3. Я считаю, что команда должна продолжить использовать текущий вид Product Backlog, он оптимально подходит.

Участник №2

1. ——
2. Мне кажется, команде надо прекратить использовать текущую IDE, её «неповоротливость» замедляет работу.
3. Команде однозначно следует продолжить использовать текущую систему контроля версий и облачных сохранений, с ней мы менее беспокоимся о потерях и более концентрируемся на работе.

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

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

Что такое Timeboxing? | Scrum Inc

Timeboxing — это фиксированная максимальная единица времени для действия. Эта единица времени называется временной рамкой. Цель тайм-бокса — определить и ограничить количество времени, посвященного деятельности.

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

Timeboxing — общая черта многих методологий управления проектами, потому что timeboxing позволяет командам сосредоточиться на выполнении поставленной задачи, обеспечивая четкое определение «выполнено».

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

Timeboxing — важнейший компонент хорошего Scrum

Все пять событий в Scrum ограничены по времени.

Sprint : Timeboxing используется для определения длины спринта. Спринт — это временной интервал в один месяц или меньше, в течение которого команда схватки реализует цели Спринта. В Scrum Inc. временной график спринта составляет одну неделю, и это то, что мы рекомендуем командам, которые мы тренируем.

Планирование спринта : Когда команда запускается, они устанавливают временной интервал для собрания по планированию спринта. Как указано в руководстве по Scrum, собрание по планированию спринта должно быть рассчитано на 8 часов или меньше для одномесячного спринта.Чем короче спринт, тем короче должен быть временной интервал для планирования спринта. В Scrum Inc. мы рекомендуем однонедельные спринты и двухчасовой временной интервал для планирования спринтов.

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

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

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

.

Что Scrum говорит об оценках

Оценка — это наше лучшее предположение о том, что и когда можно достичь. Бывают ситуации, когда очень важны оценки:

1. Координатные зависимости. Может быть очень полезно знать, когда команда сможет продолжить работу над новым дизайном, если ключевой эксперт временно отсутствует на рабочем месте.
2. Выровняйте приоритеты. В течение дня у нас есть список дел. Часто мы оцениваем усилия по определению приоритетов.
3. Выберите вариант «лучшее соотношение цены и качества».Оценки помогают нам принять решение, когда мы выбираем между различными вариантами, например, когда я выбираю лучший автомобиль с бюджетом
4. Прогноз погоды. Прогноз — отличный способ лучше подготовиться к будущему. Прогнозы часто основываются на эмпирических данных.
5. Общее понимание. Когда супружеская пара не согласна с преимуществами переезда в новый дом, вероятно, им лучше сесть и проверить некоторые предположения, лежащие в основе разногласий.

Когда не проводить оценку

Самая большая проблема оценки заключается в том, что всегда есть кто-то, кто будет на нее полагаться. Я должен постоянно сообщать другому человеку, если я вижу, что моя оценка больше не актуальна. Оценка часто воспринимается как обязательство. Что делать, если я одновременно оценил с десяток разных вещей для разных людей? Это означает, что мне нужно создать идеальный план, чтобы соответствовать оценкам. Любые изменения моих оценок не приветствуются, потому что это повлияет на все другие планы.В конце концов, я чувствую себя подавленным из-за неразберихи с тайм-менеджментом. Я трачу больше времени на обновление планов, чем на выполнение работы. Бывают ситуации, когда оценки не помогают:

1. Прогнозирование результатов комплексной работы. Это закончится беспорядком с тайм-менеджментом
2. Ориентация на кого-то, чтобы работать лучше. Человеку ужасно показывать лучшие результаты в цейтноте. Поэтому профессионалы стремятся повысить смету — облегчить себе жизнь.
3. Повышение эффективности управления временем. Фактически оценивает снижение эффективности из-за закона Паркинсона [1]

Что Scrum говорит об оценках

Scrum Guide упоминает «оценку» как минимум девять раз! Это означает, что оценки по-прежнему являются важным аспектом структуры. Но что интересно,

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

Элементы невыполненной работы продукта должны быть оценены

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

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

Люди, которые будут выполнять работу, сделают окончательную оценку

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

Оценить, сколько работы можно сделать в Sprint

Вы можете быть удивлены, но Scrum не требует от вас оценки единиц работы, которые запланированы и помещены в бэклог спринта для спринта.Многие команды Scrum все еще используют оценки, чтобы выяснить, сколько работы они могут выполнить, в то время как другие команды Scrum просто используют свои наилучшие предположения, основанные на эмпирических данных предыдущих спринтов. Многие команды Scrum могут подготовить бэклог спринта вообще без оценок. Например, когда команда может определить рабочие элементы одинакового размера, используя подход #NoEstimate. Некоторые другие команды Scrum используют подход непрерывной доставки / развертывания с упором на время выполнения заказа и ограничение незавершенной работы.Такой подход помогает быть предсказуемым и прозрачным без каких-либо оценок!

Оценка обновления во время спринта

Для того, чтобы команда разработчиков была прозрачной между собой, очень важно проводить ежедневные собрания Scrum и обновлять прогресс. Любая форма прогресса (числа, статус на доске, контрольный список, диаграмма выгорания) может помочь координировать работу и зависимости внутри команды разработчиков. Графики выгорания — это дополнительная практика в Скраме, но многие Скрам-мастера по-прежнему слишком сильно беспокоятся о своих выгорании и ищут способы быть более предсказуемыми.Расслабьтесь, вы не будете предсказуемы, и использование диаграммы выгорания в качестве индикатора улучшения команды с точки зрения планирования — абсолютная ерунда.

Оценивать или не оценивать

Это вопрос. Как я уже сказал, есть 5 причин, по которым оценки все еще имеют значение:

1. Координатные зависимости
2. Выровнять приоритеты
3. Выберите вариант с оптимальной стоимостью
4. Прогноз погоды
5. Общее понимание

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

Временной интервал и приоритеты вместо оценки

Что делать в ситуации, когда мне нужно увеличить вероятность завершения сложной работы? Есть ли предложения сфокусировать команду? Как улучшить тайм-менеджмент при работе над сложными продуктами? Как объяснялось ранее, прогнозирование с оценками не помогает вам решить эти проблемы, но вместо оценок Scrum предлагает нам использовать временной интервал :

1. Sprint — это итерация с ограничениями по времени.В начале спринта команда может установить цель спринта и достичь наилучших результатов в пределах временного интервала . Эта практика может помочь команде увеличить вероятность достижения целей продукта хотя бы раз в месяц.
2. Размер рабочего элемента бэклога спринта составляет один день или меньше. Я бы порекомендовал вам использовать эту рекомендацию Scrum Guide в качестве шкалы времени , а не оценки . Приятно оставаться сосредоточенным в течение дня, имея подтвержденное достижение в конце.Эта практика может помочь команде каждый день видеть прогресс. Как практика тайм-менеджмента это может помочь найти лучшие способы выполнить сложную задачу, даже более эффективно, борясь со временем.
3. Продолжительность события Scrum ограничена по времени. Это помогает более эффективно использовать время команды на встрече.

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

.

Scrum против традиционного управления проектами

.

Что такое Scrum?

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

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

Scrum — это:

• Облегченный
• Просто понять
• Сложно освоить

Глоссарий Scrum

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

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

Структура Scrum

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

Введение в Scrum Framework

Это короткое видео представляет собой простой обзор Scrum, позволяя зрителям узнать о ролях, артефактах и ​​событиях, а также о том, как они объединяются для вывода продукта на рынок.

Слушайте от создателей

Это видео освещает последнюю версию Руководства по Scrum с Кеном Швабером и Джеффом Сазерлендом, которые знакомятся с последними обновлениями и развенчивают несколько мифов, существующих сегодня.Они дают представление о том, почему они создали Scrum, как они использовали его на протяжении многих лет и в каком направлении движется Scrum.

Ценности Scrum

Несмотря на то, что всегда считался частью Scrum и о котором часто писали, в июле 2016 года Scrum Values ​​были добавлены в The Scrum Guide. Эти ценности включают смелость, сосредоточенность, приверженность, уважение и открытость. Прочтите Руководство по Scrum, чтобы узнать больше об этих ценностях и их применении в Scrum, и загрузите этот плакат.

Роли команды Scrum

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

Где ваша нынешняя роль подходит?

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

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

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

События Scrum

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

Артефакты Scrum

Артефакты

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

Учитесь у сообщества

Сегодня на рынке представлено более 100 книг о Скраме, десятки тысяч статей, статей и презентаций, но все начинается с Руководства по Скраму. Руководство по Scrum было написано и поддерживается создателями Scrum, Кеном Швабером и Джеффом Сазерлендом, и считается Сводом знаний по Scrum.

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

.