Работа по скраму что это
Гибкая методология разработки “Scrum”
Я продолжаю работу над диссертацией по проектному менеджменту. Сегодня мы кратко рассмотрим Scrum, рассмотрим типичные ошибки, приводящие к проблемам. Данный пост не претендует на полноту, он является обзорным и адресуется тем, кто еще не знаком со Scrum, или знаком лишь частично (к примеру, работает в модифицированном Scrum).
В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].
Это говорит о том, что в Scrum невозможно найти ответы на все вопросы и указания к действию во всех ситуациях (к примеру, в официальном описании Scrum лишь указана необходимость оценки времени, необходимой на выполнение работы, но не уточняется вид оценки. Т.е. это может быть и planning poker и другой способ оценки). Таким образом, само наименование топика не верно 🙂
Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии 🙂
Авторами Scrum заявлены следующие особенности:
-Легкий (англ. Lightweight)
-Понятный, доступный
-Сложный в освоении
(практически взаимоисключающие параграфы)
В классическом Scrum существует 3 базовых роли:
—Product owner
—Scrum master
—Команда разработки (Development team)
Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.
Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).
Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO
Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:
-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде, как им преобразовать Product Backlog в работающий продукт
-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды
Рекомендуемый размер команды — 7 (плюс-минус 2) человека. Согласно идеологам Scrum, команды большего размера требуют слишком больших ресурсов на коммуникации, в то время как команды меньшего размера повышают риски (за счет возможного отсутствия требуемых навыков) и уменьшают размер работы, который команда может выполнить в единицу времени. [1]
Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении всей жизни продукта.
Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.
Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint’а.
По окончанию Sprint’а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность (производительность) команды в прошедшем Sprint’е, спрогнозировать ожидаемую эффективность (производительность) в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.
Схематическое изображение процесса приведено на следующем рисунке: 
Важные, часто забываемые особенности
Часто можно услышать, что Scrum не работает, или работает хуже, чем ожидалось. Необходимо заметить, что чаще всего так происходит по одной из следующих причин:
1. Scrum применяется неверно или неполностью.
Согласно авторам Scrum, эмпирический опыт является главным источником достоверной информации. Необходимость полного и точного выполнения Scrum указана в The Scrum Guide и обусловлена нетипичной организацией процесса, отсутствием формального лидера и руководителя.
2. Недооценена важность работы по обеспечению мотивации команды.
Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения [2].
Таким образом, лишь небольшая часть сотрудников способно эффективно работать в Scrum без существенных изменений в ролях Scrum master и Product Owner, что противоречит идеологии Scrum, и потенциально приводит к неверному или неполному использованию Scrum.
3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.
Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла заранее планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. [3] Существуют и иные ограничения.
Достоинства и недостатки
Scrum обладает достаточно привлекательными достоинствами. Scrum ориентирован на клиента, адаптивен. Scrum дает клиенту возможность делать изменения в требованиях в любой момент времени (но не гарантирует того, что эти изменения будут выполнены). Возможность изменения требований привлекательна для многих заказчиков ПО.
Scrum достаточно прост в изучении, позволяет экономить время, за счет исключения не критичных активностей. Scrum позволяет получить потенциально рабочий продукт в конце каждого Sprint’а.
Scrum делает упор на самоорганизующуюся, многофункциональную команду, способную решить необходимые задачи с минимальной координацией. Это особенно привлекательно для малых компаний и стартапов, так как избавляет от необходимости от найма или обучения специализированного персонала руководителей.
Конечно, у Scrum есть и важные недостатки. Ввиду простоты и минималистичности, Scrum задает небольшое количество довольно жестких правил. Однако это вступает в конфликт с идеей клиентоориентированности в принципе, т. к. клиенту не важны внутренние правила команды разработки, особено если они ограничивают клиента. К примеру, в случае необходимости, по решению клиента Sprint backlog может быть изменен, не смотря на явное противоречие с правилами Scrum.
Проблема является большей, чем кажется. Т.к. Scrum относится к семейству Agile, в Scrum не принято, к примеру, создание плана коммуникаций и реагирования на риски. [3] Таким образом, делая сложным или невозможным формальное (юридическое или административное) противодействие нарушениям правил Scrum.
Другой слабой особенностью Scrum является упор на самоорганизующуюся, многофункциональную команду. При кажущемся снижении затрат на координацию команды, это приводит к повышению затрат на отбор персонала, его мотивацию, обучение. При определенных условиях рынка труда, формирование полноценной, эффективной Scrum команды может быть невозможным.
Помимо Scrum, я рекомендую обратить внимание на Канбан. В этом видео я сделал небольшой обзор метода Канбан:
Список использованных источников
[1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
[2] Психология управления, учебное пособие. (А. А. Трусь)
[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)
Заранее благодарю за указанные ошибки и неточности!
Что такое SCRUM
Модное слово в разработке. Нужно ли оно?
Эта заметка об управлении проектами в разработке (и в других областях жизни). Она понадобится тем, кому придётся работать в ИТ-компаниях или кто сам будет управлять командами.
Скрам вкратце
Для этой статьи нам понадобится чебурек:
Дети, это чебурек
Наша задача — вместо обычного чебурека придумать уникальное фирменное блюдо, которое должно понравиться большинству клиентов. Назовём это блюдо суперчебуреком.
Если перевести эту метафору в разработку — у нас есть некая версия нашего приложения и нам нужно сделать более совершенную версию этого же приложения: доработать, добавить, улучшить, прокачать. Как это делать?
Для этой задачи нам не подходит канбан, поскольку мы пока не знаем, каким будет суперчебурек или наше новое приложение. Вместо этого мы можем воспользоваться методом скрама, который как раз и придуман для подобных случаев. Давайте разбираться, что такое скрам и как им пользоваться.
Что есть SCRUM
Скрам, он же SCRUM — это один из способов управления проектом. Помимо скрама проект можно делать в порядке постановки задач, в алфавитном порядке, по степени важности задач, в авральном режиме, хаотично; можно делать проект с восьми утра до пяти вечера или круглосуточно; можно делать проект, пока не сгоришь; можно — по графику «два через два».
Скрам — просто ещё один способ структурировать работу над проектом. Смысл скрама — разбить работу на несколько маленьких кусочков, делать их последовательно и после каждого кусочка получать понятное и видимое улучшение продукта.
Ещё в скрам входят всевозможные ритуалы, артефакты и заклинания, но это лишь подспорье для основной мысли: мы улучшаем проект маленькими рывками.
Теперь посмотрим на основные компоненты скрама.
Бэклог — «что будем делать»
Работа в скраме начинается с формирования бэклога — списка задач, необходимых для разработки продукта. Эти задачи называются пользовательскими историями, и у них две особенности: они должны расставляться по приоритету и находиться на скрам-доске — физическом или виртуальном пространстве с колонками «Что сделать», «В процессе» и «Готово».
Бэклог составляет product owner — человек, который выслушивает пожелания заказчика, передаёт их команде и отвечает за выпуск продукта. Он же занимается оргвопросами и следит за тем, чтобы между сторонами не возникало конфликтов. В метафоре чебурека можно представить, что есть бизнес-заказчик — директор ресторана. И есть оунер — шеф-повар. Директор знает, что ему нужен суперчебурек. Шеф отвечает за то, чтобы этот суперчебурек случился.
Что за сценарий
Хорошая практика — хранить в бэклоге не отдельные кнопки, фишки и возможности продукта, а именно сценарии. Например, если это мобильное приложение, то «пользователь может поделиться фотографией с друзьями» или «пользователь может войти через соцсети».
Когда мы пилим продукт по сценариям, мы можем выпускать их отдельно: например, сделали «пользователь входит через соцсети» и выпустили.
Хуже — когда вместо сценария у нас отдельное свойство или кусочки продукта. Например, не «пользователь может войти через соцсети», а «поддержка плагина авторизации VK». Это как бы часть сценария, но не весь сценарий — нужно ещё доделывать интерфейс, ошибки, подсказки и другие вещи. Если мы мыслим не сценариями, а отдельными кусочками, то у нас продукт всегда «недоготовлен».
Но такое сценарное мышление возможно не во всех продуктах.
Для простоты можно думать о сценарии так: «Можно ли выпустить новую версию продукта для пользователей, если реализовать только этот конкретный набор задач?» Если можно — условно можно назвать это сценарием. Пример с чебуреком: мы можем выкатывать в меню сначала чебурек новой формы, потом чебурек с новым цветом, потом новый размер чебурека и т. д.
Итерации — «рывок» проекта
Когда бэклог сформирован, команда оценивает силы и определяет длительность одной итерации. Итерация — это один рабочий «рывок», обычно в ИТ он занимает 1—3 недели.
Команде нужно посчитать, сколько пользовательских историй войдёт в одну итерацию и какое количество итераций понадобится. Например, если у нас пять историй с недельной итерацией, то на проект уйдёт пять недель.
👉 Итерации в скраме — это то же самое, что и спринты в программировании. Подробно об этом мы рассказывали в отдельной статье.
Перед каждой итерацией команда составляет план работы над выбранными пользовательскими историями. Дополнительно проводятся ежедневные встречи, на которых каждый участник отвечает на три вопроса: что он уже сделал, какие проблемы и чем будет заниматься дальше. На встречи не должно уходить более 15 минут, поэтому численность скрам-команд всегда ограничена 5—9 участниками.
Встречи ведёт скрам-мастер — опытный член команды. Он выступает как менеджер: делает так, чтобы команда могла выполнить поставленную задачу, координирует людей и создаёт условия труда. Сломался ноутбук — скрам-мастер организует ремонт и найдёт новый на замену. Проблемы с дедлайном — скрам-мастер закупит кофе и поставит раскладушку в офис.
Инкремент — результат «рывка»
После каждой итерации команда должна выдать инкремент — промежуточную версию продукта, которая выносится на обсуждение с заказчиком. На встрече каждый участник команды отчитывается о проделанной работе, отвечает на вопросы и предлагает идеи по улучшению. В результате заказчик может принять инкремент, отправить его на доработку или досрочно закрыть проект.
👉 В идеальной ситуации инкремент должен быть стабильной и рабочей версией продукта. Недопустимо, чтобы из-за новых сценариев в продукте начали отваливаться старые возможности (как это часто бывает). Поэтому тестирование и отладка продукта тоже закладывается в итерацию. Лучше сделать меньше, но более стабильно, чем взять много сценариев и получить сырой глючный продукт.
Это всё, конечно, в идеале. В жизни бывает по-всякому.
Инкрементом первой итерации стали разные формы суперчебурека. Выбираем тот, что покруглее
Ретроспектива
После первой итерации появляется обратная связь от заказчика — проще говоря, «правочки». Для её обсуждения предусмотрено отдельное командное собрание — ретроспектива. Для многих разработчиков это самая ненавистная часть скрама, потому что здесь тебе будут что-то говорить про твою работу, не всегда приятное.
Ретроспектива состоит из четырёх частей и проходит по следующему плану:
Можно сказать, что задача ретроспективы — понять, что пошло не так в рабочем процессе, и исправить это. Фокус не на том, что кто-то пропустил баг на тестировании или неправильно обозвал переменную, а именно на том, как ставятся задачи и планируются следующие итерации.
Во время ретроспективы команда не ищет виновных — по умолчанию считается, что каждый участник сделал всё возможное для получения лучшего результата. Если что-то не получилось, то причина в обстоятельствах. Их нужно менять.
Ретроспектива происходит после каждой итерации. При этом важно, чтобы во время каждой следующей ретроспективы учитывались результаты предыдущей — это поможет следить за тем, чтобы продуктивность повышалась не только на бумаге.
Инкремент второй итерации — цвета суперчебурека. Самым стильным выглядит чёрный цвет
Диаграмма сгорания
Для отслеживания прогресса в скраме используется диаграмма сгорания — это график, на котором видно, как быстро мы должны были исполнять задачи и как быстро мы их исполняем на самом деле. Можно было рисовать как угодно, но в скраме — так.
Пример сложной диаграммы сгорания, где команда отстала от дедлайна на одну итерацию. План — зелёное, факт — красное. Чем больше осталось, тем хуже
Критерии готовности
Скрам пытается решить одну из самых горьких проблем разработки: «Заказчик хотел одно, мы это сделали, а оказалось, что он хотел другое». В этот момент у разработчиков, дизайнеров и всех остальных должны наворачиваться слёзы.
Скрам пытается решить эту проблему, прописывая критерии готовности задачи. Заказчик и скрам-мастер должны постараться чётко описать видение результата: на что он должен быть похож, как работать и т. д.
Но это всё в теории и в идеальном мире. В реальности заказчик всё равно скажет: «Да, я написал, но сейчас ситуация изменилась и нужно сделать по-другому».
🔥 Критика SCRUM
Скрам критикуют за излишнюю ритуальность: вместо того чтобы спокойно работать и делать задачки, люди сидят на встречах и занимаются ретроспективным анализом собственной деятельности.
Скрам критикуют за модность: все его пытаются внедрить, не везде уместно и не везде правильно. Результат легко представить.
Скрам критикуют за то, что получается, когда его внедряют неграмотные управленцы. Когда ритуалы замещают полезную работу, это действительно печально.
Но здесь надо понимать, что критика скрама — это в первую очередь критика плохой реализации скрама и людей, которые неуместно его используют. Донт блейм зе гейм, блейм зе плейа.
Что там с чебуреком?
В идеальном мире прошло пять недель, и наши бойцы сделали суперчебурек, который без вопросов был принят руководителем и скрам-мастером. Презентация чебурека разлетелась по всем СМИ, тысячи людей встали в очередь на предзаказ, а чебуречная вышла на IPO.
В реальности фаундер чебуречной купил иномарку, попал на ней в аварию, инвесторы отказались финансировать проект, команда забрала наработки и разбежались кто куда: кто-то в крупные компании, другие — в стартапы, третьи бросили эту айтишную жизнь и переехали в село.
Потому что жизнь сложнее, чем представления скрам-мастера о ней.
Что дальше
Скрам — это гибкая методика, принципы которой подходят под разные проекты, будь это ИТ-компания или чебуречная. В статье мы рассмотрели общие положения, и для погружения в тему рекомендуем следующие ресурсы:
Дополнительно посмотрите интервью Павла Свиридова, который руководит бэкенд-разработкой и обращается с коллегами как настоящий скрам-мастер.
Что такое scrum: преимущества и недостатки
Узнайте больше о том, для чего нужен scrum и как он работает
Scrum (скрам) ― это один из agile-подходов к разработке и управлению проектами. Чаще всего данный метод используют в IT-сфере, однако он применим для разных направлений, включая строительство, образование, производство товаров, ивент-индустрию и другие виды деятельности.
Посмотрите это короткое видео, чтобы лучше понять, что собой представляет методология scrum, как она помогает решать задачи и какие есть основные роли.
Содержание
Зачем нужен scrum?
По словам Джефа Сазерленда, создателя методологии скрам, этот подход является идеальной моделью полного взаимодействия участников команды. Он предполагает регулярное отслеживание процесса работы, что позволяет увидеть результативность прилагаемых усилий, оценить правильность направления движения и решать задачи с меньшими усилиями. При этом, основа планирования по методу scrum — это гибкость. Вы всегда можете внести новые идеи и необходимые изменения.
Скрам нужен для планирования работы, системной организации рабочего процесса, развития ответственности и самоорганизованности в команде. Методология позволяет легко адаптироваться к изменчивым окружающим факторам и постоянно обучаться.
Если говорить о разработке программного обеспечения, то скрам — идеальный подход для реализации идеи, поскольку помогает выстраивать работу без конкретного пошагового плана на начальном этапе. Команда постепенно устраняет неопределенность, выбирает курс дальнейшей работы и анализирует пользу приложенных усилий. В отличие от линейного (каскадного) способа разработки, процесс движется быстрее, требует меньших затрат и легко адаптируется под требования заказчика.
В следующем разделе вы ознакомитесь с преимуществами и главными недостатками методологии scrum.
Преимущества и недостатки scrum
Scrum имеет ряд преимуществ как для команды, так и для компании в целом. Ознакомьтесь с основными сильными сторонами этой методологии:
Скрам — это win-win подход, который обеспечивает такое взаимодействие команды и заказчика, при котором каждая сторона остается в выигрыше и получает желаемое. Однако, несмотря на явные преимущества в планировании, распределение нагрузки внутри команды, прозрачность коммуникации и гибкость работы у этого метода есть и недостатки:
Чтобы лучше понять, что собой представляет методология скрам, ознакомьтесь с правилами организации работы в следующем разделе.
Как работает scrum
Работа по методу скрам предполагает определенный алгоритм действий.
Для визуализации процесса используют scrum-доску, на которой размещают задачи и отслеживают их статус в рамках текущего спринта. Она может быть виртуальной или реальной с использованием канцелярских стикеров. На скриншоте ниже вы видите, как может выглядеть такая доска.
На первый взгляд она схожа с доской, которую используют в методологии канбан. Однако, в них есть отличия. Scrum больше опирается на временные промежутки выполнения работы (длительность спринта), в то время как в канбан более важен сам список задач.
Тем не менее, и в том и в другом инструменте часто используют одинаковое этапы выполнения работы:
Каждой задачи из бэклога присваивают определенный статус путем ее перемещения из одной колонки в другую. Чтобы получить максимальную отдачу от внедрения метода scrum, прежде всего важно его адаптировать под свои рабочие процессы. Помните, любой agile-подход — это метод управления, который еще важно научиться использовать.
Поэтому, не торопитесь сразу использовать подход scrum и кардинально менять рабочий процесс. Сначала проведите предварительную подготовку, изучите кейсы разных компаний и доступную литературу, оцените свою команду, взвесьте все за и против и только после этого приступайте к внедрению.
Мини-справочник и руководство по Scrum
Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.
Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.
Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.
Члены команды должны быть довольны своей деятельностью, быть счастливыми в своей работе. Состояние счастья приводит людей к превосходным результатам.
Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса
— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.
Мини-справочник Scrum
Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.
Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.
Основные обязанности и ответственность Product Owner при управлении Product Backlog:
Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.
Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.
Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
User – пользователь продукта.
Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.
Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.
User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.
Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.
Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.
Sprint Goal (спринт гоол) – цель спринта.
Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.
Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.
Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.
Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?
Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.
Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.
Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.
Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.
Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.
Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.
Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.
Руководство Scrum
Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.
Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.
123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.
User Story
Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?
Формируется Sprint. Sprint Planning Meeting. Scrum Poker
Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.
Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:
Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.
Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.
Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.
Sprint Retrospective Meeting. Ретроспектива.
Проводится в последний день спринта.
Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?