Скрам по-русски

Иногда интернет представляется чёрной дырой, которая существует лишь для того, чтобы уничтожать отведённое мне время…

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

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

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

Scrum (по-русски Скрам)

Scrum (англ. scrum «толкучка») — методология управления проектами, применяющаяся при необходимости гибкой разработки. Методология делает акцент на качественном контроле процесса разработки. Кроме управления проектами по разработке ПО, Scrum может также использоваться в работе команд поддержки программного обеспечения, или как подход к управлению разработкой и сопровождению программ: Scrum of Scrums.

Скрам по-русски

Автор схемы: Lakeworks, CC BY-SA 3.0

Определения

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

Спринт (Sprint) — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно скрам-стандарту компании Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении.

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

Журнал пожеланий (очередь работ) проекта (англ. Project backlog) — список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются пользовательскими историями (user story) или элементами беклога (backlog items). Журнал пожеланий проекта открыт для редактирования для всех участников скрам-процесса.

Журнал пожеланий (очередь работ) спринта (англ. Sprint backlog) — содержит функциональность, выбранную владельцем проекта из журнала пожеланий проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Каждый день команда оценивает объём работы, который нужно проделать для завершения спринта.

Диаграмма сгорания задач (Burndown chart) — отображает завершенный спринт. Показывает оставшиеся нерешённые задачи и трудозатраты, необходимые для их завершения в расчёте на 21 рабочий день. Диаграмма, демонстрирующая количество сделанной и оставшейся работы относительно времени на разработку проекта.

Скрам по-русски

Автор схемы Pablo Straub, общественное достояние

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

Существуют два вида диаграммы:

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

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

Дополнительные определения

История спринта (Sprint Story) — требуемую функциональность, которую добавляют в бэклог, часто называют историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>». Такая структура удобна тем, что понятна как разработчикам так и заказчикам.

Остановка спринта (Abnormal Termination) — спринта может быть произведена раньше срока его планового окончания в исключительных ситуациях. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведённое время. Спринт может остановить владелец проекта, если исчезает необходимость в реализации цели спринта. После остановки спринта проводится совещание с командой, где обсуждаются причины остановки. После этого начинается новый спринт.

Покер планирования (Planning Poker) — техника оценки, основанная на достижении договорённости, главным образом используемая для оценки сложности предстоящей работы или относительного объёма решаемых задач при разработке программного обеспечения.

Очки за пользовательскую историю (Story Points) — абстрактная метрика оценки сложности истории, которая не учитывает затраты в человекочасах. Обычно используют одну из следующих шкал: ряд Фибоначчи (1,2,3,5,8,13,21,34,55); линейную шкалу (1,2,3,4 … n); степень двойки (1,2,4,8 … 2n); размеры одежды (XS, S, M, L, XL).

Задачи истории спринта (Sprint Story Tasks) — добавляются к историям спринта. Выполнение задачи оценивается в часах. Каждая задача не должна превышать двенадцати часов (зачастую команда настаивает, чтобы максимальная продолжительность задачи равнялась одному рабочему дню).

Критерий готовности (Definition of Done (DoD)) — определяет степень готовности элемента из журнала пожеланий пользователя.

Скорость команды (Velocity) — общее количество очков, набранных командой за предыдущий спринт. Данная метрика помогает команде понять, сколько историй она может сделать за один спринт.


Роли в скрам-процессе

По методике Scrum в производственном процессе есть определённые роли, разбитые на 2 группы «свиней» и «кур». Эти названия были использованы из-за шутки:

Свинья идёт по дороге. Курица смотрит на неё и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать „Яичница с беконом“?». «Так не пойдёт, — отвечает свинья, — ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично».

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

Основные роли (Core roles) в методологии скрам

Полностью включены в проект и в скрам-процесс следующие участники.

  1. Скрам-мастер (Scrum Master) — проводит совещания (Scrum meetings), следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Руководитель проекта скорее относится к владельцу проекта и не должен фигурировать в качестве скрам-мастера.
  2. Владелец продукта (Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
  3. Скрам-команда (Scrum Team) — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет от 3 до 9 человек. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто, кроме команды, не может вмешиваться в процесс разработки на протяжении спринта.

Дополнительные роли (Ancillary roles) в методологии скрам

  1. Пользователи (Users)
  2. Клиенты, Продавцы (Stakeholders) — лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
  3. Управляющие (Managers) — люди, которые управляют персоналом.
  4. Эксперты-консультанты (Consulting Experts)

Пользовательские истории

Обязательные поля

ID — уникальный идентификатор, порядковый номер, применяемый для идентификации историй в случае их переименования.

Название (Name) — краткое описание истории. Оно должно быть однозначным, чтобы и разработчики, и владелец проекта могли понять, о чём идёт речь и отличить одну историю от другой.

Важность (Importance) — степень важности данной истории, по мнению владельца проекта. Обычно представляет собой натуральное число, иногда для этой цели используются числа Фибоначчи. Чем больше значение, тем выше приоритет.

Предварительная оценка (initial estimate) — начальная оценка объёма работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point’ах. Приблизительно соответствует числу «идеальных человеко-часов».

Как продемонстрировать (how to demo) — краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. Данное поле может представлять собой код автоматизированного теста для приёмо-сдаточного испытания.

Критерии приемки (acceptance criteria) — значимые детали реализации истории, уточняющие требования владельца продукта, собранные всеми участниками команды при планировании спринта.

Дополнительные поля

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

Категория (track). Например, «панель управления» или «оптимизация». При помощи этого поля владелец проекта может легко выбрать все пункты категории «оптимизация» и установить им низкий приоритет.

Компоненты (components) — поле указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации истории. Данное поле состоит из группы checkbox’ов, которые отмечаются, если соответствующие компоненты требуют изменений.

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

ID в системе учёта дефектов (bug tracking ID) — если вы используете отдельную систему отслеживания ошибок, тогда в описании истории полезно хранить ссылки на все дефекты, которые к ней относятся.


Собрания

Планирование спринта (Sprint Planning Meeting)

Происходит в начале новой итерации Спринта.

  • Из бэклога проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда;
  • На основе выбранных задач создается бэклог спринта. Каждая задача оценивается в идеальных человеко-часах;
  • Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи;
  • Обсуждается и определяется, каким образом будет реализован этот объём работ;
  • Продолжительность совещания ограничена сверху 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п.
    • (первая часть совещания) Участвует владелец проекта и скрам-команда: выбирают задачи из бэклога продукта;
    • (вторая часть совещания) Участвует только команда: обсуждают технические детали реализации, наполняют бэклог спринта.

Ежедневное совещание (Daily Scrum meeting)

  • начинается вовремя;
  • все могут наблюдать, но только имеющие основные роли (Core roles) говорят;
  • длится не более 15 минут;
  • проводится в одном и том же месте, в течение спринта.

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

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

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

Скрам над скрамом (Scrum of Scrums)

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

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

Обзор итогов спринта (Sprint review meeting)

Проводится в конце спринта.

  • Команда демонстрирует прирост функциональности продукта всем заинтересованным лицам.
  • Привлекается максимальное количество зрителей.
  • Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).
  • Нельзя демонстрировать незавершенную функциональность.
  • Ограничена четырьмя часами в зависимости от продолжительности итерации и прироста функциональности продукта.

Ретроспективное совещание (Retrospective meeting)

Проводится в конце спринта.

  • Члены команды высказывают своё мнение о прошедшем спринте.
  • Отвечают на два основных вопроса:
    • Что было сделано хорошо в прошедшем спринте?
    • Что надо улучшить в следующем?
  • Улучшают процесс разработки (решают вопросы и фиксируют удачные решения).
  • Ограничено одним-тремя часами.

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

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