Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике. Надо различать Agile и Scrum.

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

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

Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса — доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.

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

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

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

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

Scrum Team (скрам тим) – собирательный образ команды, состоящей из Development Team, Scrum Master и Product Owner. Команда полностью самодостаточна и не зависит от внешних специалистов или заказчиков.

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, требования и пожелания.

1. Основные поля в карточке: id, название, важность, оценка, релиз, описание, автор, исполнитель;
2. Дополнительные поля в карточке. Например, поле «Тематика» – рейтинг товара в интернет-магазине сейчас не нужен, а в рейтинг входят пара задач.

   Тогда можно изменить «важность» всех задач с этой тематикой;

3. Задачи лучше разбивать по одинаковым типам.

Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени. 123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач. User Story

1. Получение от заказчика Бизнес-цели. Составляем Impact Map для каждой бизнес-цели: Why?->Who?->How?->What? (Зачем?->Кто?->Как?->Что надо сделать?);
2. Формулировка User Story: Будучи пользователем я хочу сделать , чтобы получить . Как менеджер склада я получаю отчет о товарных остатках, чтобы БЫСТРЕЕ принять решение; Формулировка без ЧТОБЫ (так лучше). Как , я , .

   Как менеджер склада я получаю отчет о товарных остатках БЫСТРЕЕ.

3. Разделение «актеров» на группы: целевая, важная, менее важная и т.д. Присвоение уникальных названий актерам в этих группах, даже если есть одинаковые роли «Пользователи системы»;
4. Написание истории с точки зрения этих актеров с указанием уникальных названий;
5. В результате можно увидеть, какие истории необходимы для актеров целевой группы, важной группы итд. Следовательно можно выстроить приоритет;
6. Действие. Важно описывать историю на уровне «Что?» делает, а не «Как?», описать проблему, а не ее решение. «Как?» находится вместе с командой;
7. Ценность. Отказ от формулировки «Чтобы». Для каких-то историй можно указать ценность истории в формате «Чтобы», но не для большинства;
8. Переход с понятия «ценность» (value) на понятие «влияние» (impact). История не обязательно должна иметь ценность, но обязательно должна оказывать влияние на того актера, который указан в истории. Это влияние в конечном итоге ведет к цели;
9. User Story разбиваются по важности и функциональности и далее разбиваются на задачи в бэклоге.

Уточнение и оценка Product Backlog Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?

Формируется Sprint. Sprint Planning Meeting. Scrum Poker

Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.

1. Первая часть митинга могут участвовать все. Право голоса у Product Owner и Developer Team. Выбор User Story и Задач из Product Backlog в Sprint Backlog;

   Формулировка цели спринта — Sprint Goal. Определение ценности для бизнеса. Краткое описание бизнес-цели, ради которой выполняется данный спринт. Помогает команде принимать бизнес-обоснованные решения, или альтернативные решения.

2. Вторая часть митинга участвуют только Scrum Team. Наполнение Sprint Backlog. Определение, каким образом будет реализован объем работ. Обсуждение технических деталей;

Scrum Poker (Planning Poker). Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок. Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:

1. Scrum Master ведет собрание;
2. Product Owner представляет краткие обзоры каждой задачи;
3. Происходит обсуждение, задаются вопросы;
4. Участники Developer Team выбирают по одной карте, потом переворачивают;

Документы, которые использует команда при работе по Scrum

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

Итак, в Scrum используется всего три документа:

• Журнал продукта (Product backlog)
• Журнал спринта  (Sprint backlog)
• Диаграмма BurnDown

Первый документ – журнал продукта, содержит в себе все требования (пожелания) к тому продукту, над которым ведет работу команда проекта.

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

Пожелания в Scrum называются историями пользователя одной и записываются одной строчкой примерно в таком формате: 

Будучи , я хочу , чтобы

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

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

Владелец продукта должен быть настолько доступным для команды, чтобы  запланировать обсуждение по истории в течение 1-2-х дней после сообщения от команды о желании встретиться.

Майк Кон в книге «Scrum. Гибкая разработка ПО» описывает, какими важнейшими характеристиками должен обладать  хороший журнал продукта:

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

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

• Изменчивость. Журнал продукта не является чем-то статичным. С течением времени он изменяется. По мере получения дополнительной информации в нем появляются новые пользовательские истории, какие-то из пользовательских историй удаляются, изменяются приоритеты пользовательских историй.

• Приоритезация журнала. Журнал продукта должен быть отсортирован таким образом, чтобы самые важные элементы находились наверху, а наименее важные — внизу. Действуя в строгом соответствии с этими приоритетами, команда может максимизировать ценность разрабатываемого продукта или системы.

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

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

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

Скорость команды обычно измеряет скрам-мастер. Подробнее о ролях в Scrum читайте  здесь.

В The Scrum Guide описана такая метрика измерения скорости работы команды, как velocity, которая по сути отражает скорость работы команды в рамках каждого спринта. Измеряется этот показатель в так называемых story points или идеальных человеко-часах. Мы в команде для измерения скорости нашей работы выбрали идеальные человеко-часы.

Кроме измерения скорости команды, мы измеряли такой показатель, как Focus factor. Он позволяет понять, как команда держит свои обещания относительно выполнения взятого на себя объема  работ на спринт.

Например, на старте спринта мы взяли на команду 10 задач и оценили их в 160 идеальных-человеко-часов. По окончании спринта мы полностью выполнили 7 задач из 10.

По плановым оценкам эти 7 задач оценивались в 96 идеальных человеко-часов, это и есть velocity команды на данный спринт. А focus factor данного спринта составил 96/160 = 0,6.

В следующий раз при планировании спринта команда, фокус-фактор которой оказался равен 0,6, возьмет работы не на все имеющееся у них время в 160 часов (к примеру),  а на 160*0,6 = 96 часов.

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

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

Что нужно знать команде каждый день, чтобы понимать, успеет ли она реализовать взятые на спринт обязательства? Команде нужно понимать, какой объем работ остался до окончания спринта  и какой должен был остаться по плану.

Для этого и используется диаграмма BurnDown,  пример которой представлен ниже:

У команды на спринт было запланировано работы на 162 идеальных человеко-часа. Зеленая линия на диаграмме показывает, какой объем работ в чел-часах должен оставаться у команды в идеальной ситуации на каждый день. Красная линия показывает, какой объем работ реально у команды остался.

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

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

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

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

Удачи Вам в реализации ваших проектов!

Scrum и документация | learnapidoc-ru

Edit me

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

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

В конце раздела есть короткий опрос для сбора фидбека.

Note: Scrum — не единственная методология разработки программного обеспечения. Инженеры могут использовать Kanban, Waterfall, DevOps, Rapid Application или другой подход.

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

Остановимся на Scrum, потому что это самый распространенный подход.

Введение

Если вы не знакомы со Scrum, попробуйте сначала ознакомиться с методологией, прежде чем читать этот раздел. Начните с чтения руководства Scrum. Если вы предпочитаете книжную версию, см. Scrum: The art of doing twice the work in half the time. Это руководство к подходу (небольшая книга).

Подключаемся к Scrum разработки, или создаем свой Scrum

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

Существует несколько преимуществ присоединения к готовому процессу:

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

Помимо преимуществ такого подхода есть и отрицательные моменты:

• еcли тех. писатель является временным ресурсом в проекте, с продолжительностью работы около месяца или около того, то, вероятно, нет смысла присоединяться к инженерному Scrum. Там слишком много адаптации, знакомство с процессом и многое другое;
• если Scrum работает плохо, например, ежедневные встречи длятся более 30 минут, и есть несколько scrum-команд, с которыми нужно работать, все это убивает время, истощает пропускную способность, не давая ничего взамен;
• скорее всего, у тех. писателя будет несколько проектов одновременно. Если нужно изменить свой подход к каждому из них, используя разные варианты Scrum, то собственный рабочий процесс и методология могут почувствовать себя немного разрозненными. Например, если каждый подход рассчитывает все по-разному, имеет разную продолжительность спринта и другие вариации, такое несоответствие своей методологии может быть утомительным;
• команда инженеров хочет, чтобы тех. писатель присутствовал на всех их встречах Scrum, но не станет относиться к нему как к полноправному участнику Scrum (например, без задач, и т.д.), стоит задуматься о создании собственном Scrum-процессе.

Адаптация Scrum-процессов для создания документации

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

1. Определение предстоящих проектов и других работ (спринт-планирование). Перед каждым спринтом нужно просмотреть предстоящие проекты и другие работы, такие как просмотр календарей запуска, форумы поддержки, роадмапы и многое другое. Стоит получить представление о работе и расставленных приоритетах. Чтобы потом не удивляться работе, которая появляется за две недели до того, как понадобятся результаты.
2. Создание плана документации для более крупных проектов. Вот шаблон плана документации, который адаптирован для данного проекта. Такой план содержит множество деталей, которые нужны, чтобы быть в курсе проекта. Это не каскадный подход или набросок документа, а список заметок о проекте, например, кто есть кто, где сценарии тестирования QA, ожидаемые результаты, когда запланированы даты выпуска, где находятся ключевые документы по продукту и т.д. , Такой план документации функционирует как своего рода контрольная книга для проекта с разделом, в котором перечислены текущие заметки.

3. Разделение работы над документацией на тикеты (задачи). Из плана документа создаются тикеты (например, вопросы JIRA), связанные с работой. Тикеты должны примерно обозначить основные задачи для каждого проекта.

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

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

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

4. Оценка веса пунктов для каждого тикета. Каждый пункт оценки сообщают о сложности проекта. Бывает, что каждая команда немного различается в оценке задач. Можно сделать такую систему баллов: полный рабочий день — 2 балла; полдня или меньше — 1 балл. Можно разбивать свои тикеты не более чем на 5 баллов, чтобы показать прогресс и чувствовать окончание работы. Даже для коротких исправлений, которые занимают 10 минут, равно записываю метку для этого. (Более гибкое взвешивание меток обычно не рекомендуется в гибкой методологии.) Оценка нужна, чтобы понимали все, является ли задача сложной или простой.
5. Разбивка тикетов на двухнедельные спринты. Тикеты должны быть распределены по спринтам. Каждый спринт обычно длится две недели (но может быть разной продолжительности). Для каждого спринта общее усилие каждого писателя должно составлять количество баллов, которые можно выполнить за этот двухнедельный период. Эта скорость прохождения меток называется «скоростью». Это число основано на предыдущих расчетах скорости, поэтому сначала нужно понять свою скорость, что возможно только после нескольких спринтов. Расчет и передача информации о скорости важны для того, чтобы знать, правильно ли тех. писатель укомплектован для выполнения работы с учетом сроков релизов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Процесс проверки может включать шесть контрольных чекпоинтов:

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

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

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

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

   d) Ревью с юр.отделом Если у документации есть какие-либо “флажки”, которые могут вызвать проблемы с юристами, нужно передать документацию группе своих юристов для проверки. e) бета-ревью партнерами Можно сделать бета-ревью документации крупных проектов до ее публикации. Как правило, в этом могут участвовать полевые инженеры и партнер-заказчики.

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

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

   В этом процессе проверки клиенты проверяют вашу работу и по мере необходимости вносят исправления.

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

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

   Техническому писателю стоит знать, есть ли какие-то серьезные проблемы с документами, чтобы их исправить.

Заключение

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

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

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

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

Дополнительные материалы

Небольшой опрос

Для сбора фидбека о данном разделе автор курса создал небольшой опрос. Результаты опроса можно посмотреть по ссылке

SCRUM — Википедия

SCRUM
Официальный сайт
scrum.org
 Медиафайлы на Викискладе

SCRUM (/skrʌm/[1]; англ. scrum «схватка») — программная платформа (framework) для управления проектами.

• SCRUM обычно используется в сфере разработки ПО, но может использоваться и в других производственных отраслях[2].
• Кроме управления проектами по разработке ПО, SCRUM может также использоваться в работе команд поддержки программного обеспечения, как подход к управлению разработкой и сопровождению программ.
• Следует различать SCRUM[3] и Agile[4].

История

Термин «scrum» пришёл из регби, где он означает схватку. Здесь запечатлена схватка в регбийном матче клубов «Ньюпорт» и «Лондон Уэлш» 1904 года

Первоисточниками методологии Scrum послужили: производственная система компании Toyota и цикл OODA (OODA loop, или петля OODA, или петля Бойда) концепции применения боевой авиации, включающий в себя четыре составляющих: observe («наблюдать»), orient («ориентироваться»), decide («решать»), act («действовать»).[5]

Джефф Сазерленд

Сам подход впервые описали Хиротака Такэути[en] и Икудзиро Нонака[en] в статье The New Product Development Game (Harvard Business Review, январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «подход регби».

В 1991 году ДеГрейс и Шталь в книге «Нечестивые проблемы, праведные решения»[6] называли подобный подход словом «scrum» (буквальный перевод — «толкотня», в регбийной терминологии — схватка), спортивный термин, приведенный в статье Такэути и Нонакой. Кен Швабер[en] в начале 1990-х использовал подход, который привел SCRUM в его компанию.

Впервые методология SCRUM была представлена на общее обозрение задокументированной, четко сформированной и описанной совместно Швабером и Джефом Сазерлендом[5] на OOPSLA’95[7] в Остине.
К. Швабер и Д.

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

Кен Швабер

Швабер объединил усилия с Майком Бидлом[en] в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM»[8].

В 2002 году Швабер вместе с другими основал Альянс Scrum[9] и создал серию сертифицированных аккредитаций Scrum. Швабер покинул Scrum Alliance в конце 2009 года и основал Scrum.org, который курирует параллельную серию аккредитаций Professional Scrum[10].

С 2009 года публичный документ под названием The Scrum Guide[11] официально определяет Scrum. Он был пересмотрен более 5 раз. В 2018 году Швабер и сообщество Scrum.org вместе с лидерами сообщества Kanban опубликовали Руководство по Kanban для групп Scrum[12].

Определения

Процессы методологии SCRUM

SCRUM

SCRUM (англ.

«схватка» — термин из регби, обозначает стартовое состояние команд перед вбросом мяча) — минимально необходимый набор мероприятий, артефактов, ролей, на которых строится процесс SCRUM-разработки, позволяющий за фиксированные небольшие промежутки времени, называемые спринтами (sprints), предоставлять конечному пользователю работающий продукт с новыми бизнес-возможностями, для которых определён наибольший приоритет. Методология базируется на идеях, озвученных в статье Таекучи и Нонака «The New New Product development Game», и базируется на командной работе, по аналогии с тем, как в регби команда действует сообща, ради достижения общей цели. Возможности к реализации в очередном спринте определяются командой в начале спринта на совещании по планированию спринта Sprint Planning Meeting. Для оценки предстоящего объёма работ на спринте чаще всего используются относительные оценки, и практика покера планирования (Planning Poker).

В конце спринта Scrum-команда встречается на обзорном совещании результатов спринта (Sprint Review — старое название Demonstration) с заказчиком, и представляет ему инкремент бизнес-продукта (версия продукта с законченным набором функциональности, который уже можно отдавать заказчику и пользователю для использования), который она успела сделать за спринт. Цель Sprint Review — получение обратной связи от заказчика, чтобы понять, на чем нужно делать акцент в дальнейшем, и какой должен быть следующий инкремент бизнес-продукта.

Строго фиксированная небольшая длительность спринта (от 1 до 4 недель) снижает риски, и дает возможность быстро получить обратную связь от заказчика, чтобы скорректировать видение продукта.

Спринт

Спринт[13] — промежуток времени, достаточный для выполнения запланированной совокупности операций SCRUM, целью которой является создание инкремент бизнес-продукта. Жестко фиксирован по времени. Длительность одного спринта от 1 до 4 недель.

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

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

Для оценки объёма работ в спринте можно использовать предварительную оценку, измеряемую в баллах истории. Предварительная оценка длины спринта фиксируется в бэклоге проекта (product backlog; см. далее).

Артефакты SCRUM

Диаграмма сгорания задач (Burndown chart)

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

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

Журнал пожеланий проекта (Project backlog)

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

Элементы этого журнала называются пользовательскими историями (user story) или элементами бэклога (backlog items). Бэклог проекта открыт для редактирования для всех участников процесса SCRUM.

Ответственный за ведение бэклога проекта — владелец продукта SCRUM.

Журнал пожеланий спринта (Sprint backlog)

Журнал пожеланий спринта (бэклог спринта) — содержит функциональность, выбранную владельцем продукта из бэклога проекта. Все функции разбиты по задачам, каждая из которых оценивается командой SCRUM. На Sprint Planning Meeting методом покера планирования команда оценивает объём работы, который нужно выполнить для завершения спринта[14].

Scrum-доска

Скрам-доска

Scrum-доска — это инструмент открытой демонстрации состояния текущей работы Scrum-команды. Scrum-доска состоит из трех колонок: «сделать» (to-do), «в процессе» (in progress), «сделано» (done).

На Scrum-доске размещается весь объём Sprint Backlog, который команда выбрала на Sprint Planning для реализации в текущем спринте.

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

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

Бизнес-задачи, и карточки конкретных работ, передвигаются по доске из колонки в колонку, в соответствии с тем, как команда берет их на исполнение (In Progress), и завершает (Done). Для обеспечения видимости прогресса работы команды «убывание работы» по дням, отображается на Burndown Chart’е.

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

Так же часто используются электронные доски, с реализованными в них похожими механизмами. Например, Atlassian Jira, Trello или kaiten[15].

Цель спринта (Sprint Goal)

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

Инкремент продукта

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

Команда на Sprint Review (Demonstration) демонстрирует инкремент продукта скрам мастеру, владельцу продукта, заказчикам и другим заинтересованным лицам[3], для получения обратной связи от них и принятия решения по дальнейшему направлению развития продукта[16].

История пользователя (User Story)

Истории пользователя

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

• _
• _
• _

Оценка трудоемкости выполнения пользовательской истории (задачи спринта)

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

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

Колода карт Planning Poker

Каждый разработчик должен дать свою независимую от других оценку трудоемкости задачи, при этом должны использоваться числа из ряда Фибоначчи (1, 2, 3, 5, 8, 13, 20, 40, 100). Вместо чисел 21, 34, 55 используются числа 20, 40, 100.

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

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

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

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

Хотя изначально задачи, и, соответственно, истории и проект в целом, оцениваются в какой-то определённой единице трудоемкости, эти оценки в дальнейшем используются как относительные величины трудоемкости в качестве очков (баллов) для определения скорости (производительности) работы команды SCRUM (Velocity).

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

Критерий готовности (Definition of Done, DoD)

Критерии, определяющие степень готовности элемента из бэклога пользователя.

Скорость команды SCRUM (Velocity)

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

Роли в процессе SCRUM

По методике Scrum в производственном процессе можно определить роли, разбитые на две группы «свиней» и «кур». С 2011 метафоры «свиней» и «кур» отсутствуют в руководстве Scrum, так как никаких специальных ритуалов для кур не предусмотрено см. Chickens and Pigs > (неопр.).. Руководство по SCRUM полностью относится к свиньям. Эти названия были использованы из-за шутки[5]

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

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

Основные роли (Core roles) в методологии SCRUM («Свиньи»)

«Свиньи» полностью включены в проект и в процесс SCRUM.

SCRUM-мастер (SCRUM Master) — проводит совещания (Scrum meetings) следит за соблюдением всех принципов SCRUM, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учёт, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения процесса SCRUM. Таким образом скрам мастер SCRUM есть сервант-лидер (Servant Leader) команды.