Scrum: что это и зачем нужно

Содержание

Структура Scrum

Давайте посмотрим из каких элементов состоит Scrum.

Роли

  • Владелец продукта (product owner/manager). Ставит задачу, определяет приоритеты по задачам, взаимодействует с заказчиком.
  • Скрам-мастер – человек, который отвечает за процессы внутри команды, координирует работу, следит за внутренней атмосферой. Планирует спринт, организует скрам митинг, участвует в демонстрации результатов в конце каждого спринта.

Артефакты

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

Процессы

  • Планирование спринта. Команда со скрам-мастером планирует план работ на будущий спринт, то есть составляет беклог спринта (список) задач.
  • Обзор спринта. Демонстрация инкремента продукта после каждого спринта. Команда показывает рабочую функциональность владельцу продукта (и заказчику по запросу), а тот, в свою очередь, вносит изменения в требования, если они необходимы.
  • Ретроспектива. Обзор прошедшего спринта с целью улучшения процессов. Команда, скрам-мастер и владелец продукта обсуждают прошедший спринт, делают выводы, думают над тем, что можно было бы улучшить.
  • Скрам митинг. (см.определение выше в блоке “Роли”)
  • Спринт. Как правило двухнедельный этап времени, в течении которого команда успевает разработать готовый для демонстрации функционал.

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

Ошибка № 5. Фокус 100% на эффективности работы

Повышение эффективности работы, безусловно, является важным условием сокращения затрат и повышения прибыли. Однако не следует забывать, что в некоторых ситуациях бывает полезным пожертвовать эффективностью в пользу гибкости. Давайте разберемся на примере… Вот едите Вы по трассе на машине, и чтобы набрать скорость и маневрировать, Вам нужен простор, не так ли? А если на все 100% загрузить дорогу автомобилями, то сама возможность скорости и маневренности исчезает. То же самое можно наблюдать и в командной работе.

Совет: Помните, что члены команды – живые люди, которым также требуется поле для маневров. Им нужно время и пространство, чтобы думать, учиться, мыслить. Без гибкости в работе показатели эффективности команды вряд ли будет на желаемом уровне.

Скрам Мастер

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

Обязанности Скрам Мастера по отношению к Владельцу Продукта

Скрам Мастер во многом помогает Владельцу Продукта, в частности:

  • Обнаруживает методы эффективного управления Журналом Продукта;
  • Сообщает видение, цели и элементы Журнала Продукта Команде Разработчиков;
  • Учит Команду Разработчиков создавать лаконичные и понятные элементы Журнала Продукта;
  • Осуществляет долгосрочное планирование по продукту в эмпирической среде;
  • Понимает и практикует гибкие методы разработки и управления;
  • По требованию или необходимости может выступить ведущим мероприятий Скрама.

Обязанности Скрам Мастера по отношению к Команде Разработчиков

Скрам Мастер во многом помогает Команде Разработчиков, в частности:

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

Обязанности Скрам Мастера по отношению к Организации

Скрам Мастер во многом помогает организации, в частности:

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

Мероприятия Скрама

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что делает scrum-мастер

Scrum-мастер обеспечивает работу команды в рамках методологии Scrum. Вполне нормально, что в процессе работы команда сталкивается со сложностями, и задача scrum-мастера – помочь справиться с ними.

Самое важное в этой истории: scrum-мастер – не начальник. Это не управленец и не «боевая единица», которая действует с позиции строгости, ограничений и наказаний

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

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

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

Scrum-мастер в команде всегда один. Обычно его выбирает команда.

Манифест Agile и основные принципы

Всё строится на следующих ключевых правилах:

Главное для проекта – удовлетворение заказчика;
Изменение требований в ходе работы – естественное явление;
Работающие версии продукта нужно выпускать как можно чаще;
Специалисты и представители бизнеса должны работать рука об руку;
Мотивация – это критически важно;
Лучший способ обмена информацией – непосредственное общение;
Главный показатель успеха – работающий продукт;
Лишняя работа – плохая работа;
Самоорганизующиеся команды создают лучшие решения.

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

Что дальше

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

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

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

Текст и чебуреки

Александр Бабаскин

Редактор

Максим Ильяхов

Корректура

Ира Михеева

Иллюстратор

Даня Берковский

Вёрстка

Маша Дронова

Соцсети

Олег Вешкурцев

Первая версия Scrum Guide (2010)

Первая версия Scrum Guide  создавалась в 2008-2010 годах. К этому моменту Scrum уже довольно активно использовался в IT-индустрии.

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

Посмотреть на первую версию можно тут: https://res.cloudinary.com/mitchlacey/image/upload/v1589750495/Scrum_Guide_v1_Scrum_Alliance_qe0y2w.pdf

Если посмотреть на частоту запросов по известным подходам к разработке, с которыми конкурировал Scrum (XP, DSDM, RUP), то можно увидеть необычный скачок в 2010-м году, как раз, когда вышла первая версия Scrum Guide

С тех пор было еще 6 ревизий Scrum Guide, каждая из которых старалась адаптировать Scrum к меняющейся реальности и новым потребностям рынка. За период с 2010 по 2020 годы Scrum пришел в большие Enterprise-проекты и вышел за рамки IT, все это не могло не отразиться на Scrum Guide, и создатели честно пытались идти в ногу со временем.

Удалось ли им это — судить тем, кто практикует Scrum и достигает с его помощью результатов.

Нюансы

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

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

Скрам Подход (Scrum Framework)

Скрам состоит из Скрам Команд (Scrum Teams), внутри которых распределены соответствующие роли (roles), а также мероприятий (events), артефактов (artifacts) и правил (rules). Каждый компонент Скрама имеет свое предназначение и является ключевым для успеха и использования Скрама.
Различные стратегии использования Скрама изменяются, и их описание выходит за пределы данного руководства.
Правила Скрама связывают мероприятия, роли и артефакты, регулируя отношения и взаимодействие между ними. Правила Скрама прописаны в данном документе.

Теория Скрама

Скрам основывается на теории управления эмпирическими процессами, или эмпиризме. Эмпиризм утверждает, что знание приходит с опытом и принятием решений на основании того, что является известным. Скрам использует итеративный, инкрементальный подход для оптимизации прогнозируемости и управления рисками.
В основе управления эмпирическими процессами лежат три главных принципа: прозрачность (transparency), проверка (inspection) и адаптация (adaptation).

Базовые принципы Scrum

Базовые принципы Scrum:

  1. Работа короткими циклами (спринтами). Проект делится на части (спринты) и реализуется поэтапно. Спринт длится до момента окончания работы над определенной частью продукта.
  2. Гибкость. После окончания каждого спринта проводится тестирование. При наличии ошибок меняется стратегия реализации или пересматривается список текущих задач (бэклог) по продукту.
  3. Пользователи и заказчик участвуют в разработке. В любой скрам-команде есть «владелец продукта» — заказчик или его представитель. Через него команда взаимодействует с пользователями, которые участвуют в тестировании проекта по окончанию каждого спринта. Владелец продукта собирает фидбэк, передает команде и на основе этих данных принимаются решения по дальнейшему развитию.
  4. Взаимодействие команды. Scrum-team — это несколько человек, которые взаимодействуют друг с другом и стремятся к достижению общей цели.

Кейс компании TOP Games Tech

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

Структура TOP Games Tech до перехода на Скрам

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

Структура TOP Games Tech после перехода на Скрам

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

Первый Scrum Guide. 2010

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

Прямо скажем, если читать его сегодня, то он выглядит очень “сырым” и сильно удивляет рядом анахронизмов

В 2010-м вышел первый Scrum Guide. Прямо скажем, если читать его сегодня, то он выглядит очень “сырым” и сильно удивляет рядом анахронизмов.

Если вы помните конец первой части статьи, то там говорилось, что Майк Кон выпустил в 2009-м году книгу “Succeeding with Agile” в которой ввел понятие Servant Leaderhip как основное свойство и образ действий Scrum Master’а.

Логично было бы ожидать упоминание Servant Leadership в первой версии Scrum Guide 2010.

Но идея Servant Leadership в Scrum Guide 2010 не упомянута вообще. Видимо, авторы Scrum Guide — Кен Швабер и Джефф Сазерленд — черпали материал для Scrum Guide 2010 из своих собственных книг, а не из книг других авторов. Последняя книга, написанная до 2010 года одним из авторов Scrum Guide, была книга “Agile Project Management With Scrum” которая вышла аж в 2004 году, когда идеи Servant Leadership не существовало в принципе.

Косвенным подтверждением моей гипотезы, служит тот факт, что текст Scrum Guide 2010 практически слово в слово повторяет приложение “Apendix A: Rules” к книге “Agile Project Management With Scrum”  2004-го года. В этом приложении содержится краткое описание встреч, ролей и артефактов Scrum, и глядя на это описание невооруженным взглядом видно множество фраз, параграфов и цитат, которые повторяются  в Scrum Guide 2010.

Снова мы видим прямую обязанность Scrum Master’а “железной рукой” внедрять Scrum, как это было в далеком 2001-м году, в книге «Agile Software Development with Scrum» (Scrum Book):

В то же время, Scrum Guide 2010 подтверждает позицию ScrumMaster’а как коуча, поддерживающего команду на пути освоения Scrum:

Анахронизмом, отсылающим нас к Scrum Book 2001-го года выглядит ответственность ScrumMaster за то, чтобы “найти и обучить Владельца Продукта”.

Кроме того, за ScrumMaster была закреплена обязанность “стоять на страже” Sprint Goal, чтобы команда не отклонялась от нее и фокусировала усилия для ее достижения

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

Scrum Guide 2010 как будто отбрасывает наработки авторов книг по Scrum за период 2001-2010 годов, и рисует нам картину все того же «ScrumMaster’а за рулем», который решает как реализовывать Scrum и вести команду. И одновременно с этим, меняется набор инструментов ScrumMaster’а — теперь он много фасилитирует, и делает упор на коучинг команды, а не директивное поведение.

Эдакий «просвещенный правитель», который лучше знает, как надо и полезно для команды и Владельца Продукта.

Команда как функциональная единица

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

Характеристика

Метод исследования

Метрика

Команда

Наблюдение за принципами организации групп и наличие сущности «команда».

Отсутствует понятие команды — 0 баллов.

Команда образована по функциональному признаку — 1 балл.

Самоорганизация команды по предметному признаку — 3 балла.

Команда образована по предметному признаку (направление) — 5 баллов.

Скрам-мастер

Наблюдение за наличием функций:

— развитие продуктовой команды;— поддержка среды с культурными ценностями;— поддержка среды в рамках фреймворка SCRUM;— мотивация продуктовой команды;— применение модели «менеджер — слуга»;— организация производства;— решение внутренних и внешних конфликтов.

Роль отсутствует, функции роли отсутствуют — 0 баллов.

Роль отсутствует, функции роли присутствуют — 1 балл.

Роль присутствует, функции роли отсутствуют — 3 балла.

Роль присутствует, функции роли присутствуют — 5 баллов.

Владелец продукта

Наблюдение за наличием функций:

— разработка дорожной карты продукта;— управление продуктовым бэклогом;— планирование и развитие продукта;— проведение демонстрации продукта;— проведение ежедневных стендапов;— разработка бизнес-гипотез.

Роль отсутствует, функции роли отсутствуют — 0 баллов.

Роль отсутствует, функции роли присутствуют — 1 балл.

Роль присутствует, функции роли отсутствуют — 3 балла.

Роль присутствует, функции роли присутствуют — 5 баллов.

Разработчик

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

Роль включает в себя только компетенции программирования — 0 баллов.

Роль включает в себя все необходимые компетенции для поставки версии продукта — 5 баллов.

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

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

17–20 баллов — высокий результат, характеризующий наличие самодостаточной организационной единицы производства инкремента продукта, признанной на уровне организации. При данном результате, рекомендуется сделать акцент на мероприятиях направленные на управление продуктом, непрерывное обеспечение качества и CI/CD, как вектор роста команды.

Пример комплексной проблемы

Давайте представим себе ситуацию: вы литературный менеджер. У вас есть несколько писателей. И заказчик поставил вам задачу — написать роман. Да не просто роман, а такой, какого еще не было! И чтобы обязательно продавался лучше всех. И выпускать этот роман надо по частям, что позволит подогревать интерес к книге. Так многие делали в начале XX века. Конан Дойл печатал свои произведения про Шерлока Холмса таким образом.

Основные требования от заказчика:

  • Нужно получить максимально возможную прибыль от этого произведения. В идеале, чтобы этот роман был бесконечен, чтобы выпускать его вечно. Мы, конечно, понимаем, что это невозможно, но хотя бы года на 3-4 надо обеспечить доход.
  • Каждую неделю вам надо выпускать главу. И чтоб лучше предыдущей. И чтобы все было связано между собой, над заранее знать что будет дальше.
  • Вдобавок, заказчик вдохновился историей коллективного написания книги “The Painted Sky” Сиднейским книжным клубом и требует, чтобы будущая книга была написана коллективом из семи писателей.

Итак, у вас есть группа семи эрудированных, опытных, жаждущих успеха писателей.

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

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

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

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

Что делать? Управлять написанием книги в ручном режиме вы не можете — квалификация не позволяет. Поручить написание книги одному из семи писателей — велики риски сорвать план по выпуску глав книги.

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

Представили? Сложная проблема? А ведь именно с такой проблемой сталкивается большинство Scrum-команд:

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

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

Посмотрим подробнее на эти обязанности скрам-мастера.

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

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

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

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

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

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

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

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

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

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

Цель Спринта

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

Что нужно знать прежде, чем начать

Что такое план управления проектом

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

Кто готовит план управления проектом

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

Первый шаг. Выясняем требования

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

  1. Задаем вопросы, чтобы выяснить цели клиента: какие задачи он хочет решить с помощью продукта.
  2. Оцениваем общую ситуацию на рынке и конкурентов клиента.
  3. Выясняем целевую аудиторию и какие ее проблемы может решить продукт.

Второй шаг. Составляем структуру проекта

После первого шага у вас много информации. Ее настолько много, что разобраться в ней пока трудно. Что делать? Структурировать все данные. Так вы поймете, все ли понятно или остались невыясненные части.

  1. Используем mindmap.
  2. Группируем информацию: цели, задачи, ЦА продукта.
  3. Заносим в mindmap все, что узнали.


Пример оформления структуры проекта.

Третий шаг. Пишем техническое задание

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

Пишем бэклог продукта.


1. Создаем Google-таблицу.
2. В столбец заносим базовые требования к продукту. Детали добавим в процессе работы.

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

Например, «1» ― задача с минимальной важностью, «10 000» ― с максимальной. Пределы зависят только от сложности проекта и количества задач, но цифры не должны повторяться в рамках одного бэклога. Приоритеты зависят от важности требования для продукта.


3. Расставляем приоритеты.

В самом начале трудно спланировать, сколько часов займет какая задача, поэтому будем оценивать примерно, в условных единицах. Выбираем самую простую задачу, например, пусть будет «Форма обратной связи». Затраты на ее выполнение минимальны, то есть ставим «1». Остальные задачи оцениваем относительно первой. Сложность растет ― цифра тоже. У нас получилось, что самая сложная задача на данный момент — «Главная страница». Примерные затраты на ее выполнение ― шесть условных единиц.


4. В третьем столбце прописываем примерную оценку затрат команды.

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


5. Добавляем новые задачи. Если требование выполнено ― удаляем его из бэклога.

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

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

Наиболее типичные ошибки при оценке работ в проектах 1С

Для кого эта статья? Если вы руководитель проектов (РП) с опытом «от трех проектов», то можете не читать: скорее всего, ничего нового вы не узнаете. А если вы хотите стать РП в проектах 1С или вы профессионал (разработчик, аналитик, консультант), к которому часто обращаются за оценкой, то вам будет полезно узнать о типичных ошибках при оценке.
Если вам необходимо реализовать задачу, которую не имеет смысла делать по классической проектной технологии, но заказчик требует фиксированной оценки, и задача на 2-5 человеко-месяцев, — то вам будет полезно понять методы оценки работ.
Если читатель часто пользуется услугами удаленных разработчиков/аналитиков, то вам, возможно, станет понятно, почему «человек все сделал, мы ему заплатили, сколько сказал, а он от нас ушел и больше работать не хочет».
Типичные ошибки распределю по классам.