Руководство по скраму это

Время на прочтение
8 мин

Количество просмотров 103K

Данная статья – это мини-справочник и руководство по методу 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 выбирают по одной карте, потом переворачивают;
5. Если в результате голосования есть большой разброс в очках, то выслушивают двоих, перевернувших карты с минимальным и максимальным значением;
6. Затем голосуют вновь и присваивают задаче Story Points.

Daily Scrum Meeting

Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.

1. Проводится в одно и то же время;
2. Длится строго не более 15 минут. Решение проблем выносится за рамки митинга и в составе лиц, непосредственно затронутых данным препятствием;
3. Все отвечают только на три вопроса, отвечают друг другу, не Scrum Master-у: Что я сделал вчера? Что я буду делать сегодня? Какие проблемы есть у меня и команды на пути к цели?

Sprint Review Meeting

Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.

Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.

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

Проводится в последний день спринта.

Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.

Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?

Руководство по скраму (Scrum) — К.Швабер и Дж.Сазерленд

Цель Руководства по Скраму

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

Общее Описание Скрама

Скрам (Scrum – потасовка, драка за мяч в регби) – это подход, в рамках которого возможно решить сложные адаптивные проблемы, и в то же время продуктивно и с применением творческого подхода разработать продукт наивысшего качества. Скрам является:

• Легким
• Простым в понимании
• Чрезвычайно сложным в овладении

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

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

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

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

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

Прозрачность

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

• Все участники процесса должны пользоваться общей терминологией, относящейся к процессу;
• Исполняющие работу и оценивающие ее результат в виде продукта должны иметь единое определение “Готовности”1.

Проверка

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

Адаптация

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

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

• Планирование Спринта (Sprint Planning Meeting)
• Ежедневный Скрам (Daily Scrum)
• Обзор Спринта (Sprint Review Meeting)
• Ретроспектива Спринта (Sprint Retrospective)

Скрам

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

Скрам Команда

Скрам Команда состоит из

• Владельца Продукта (Product Owner),
• Команды Разработчиков (Development Team) и
• Скрам Мастера (Scrum Master).

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

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

Владелец Продукта ответственен за достижение максимальной ценности продукта и работы, исполняемой Командой Разработчиков. Способы, которыми он этого достигает, могут отличаться и зависят от организаций, Скрам Команд и индивидуумов.
Владелец Продукта является единственным человеком в Команде, отвечающим за Журнал Требований к Продукту (Product Backlog). Управление Журналом Продукта включает в себя:

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

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

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

Команда Разработчиков

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

Командам Разработчиков присущи следующие характеристики:

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

Размер Команды Разработчиков

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

Скрам Мастер

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

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

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

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

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

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

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

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

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

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

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

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

Спринт

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

Во время Спринта:

• Не допускается внесение никаких изменений, которые бы повлияли на Цель Спринта (Sprint Goal);
• Состав Команды Разработчиков и цели по качеству продукта остаются неизменными;
• Границы, в пределах которых ведется разработка в Спринте, могут быть уточнены и повторно обговорены между Владельцем Продукта и Командой Разработчиков по мере большего понимания.

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

Отмена Спринта

Спринт можно остановить перед окончанием его временных рамок. Только у Владельца Продукта есть право на то, чтобы остановить Спринт, хотя он может сделать это и под влиянием заинтересованных лиц, Команды Разработчиков или же Скрам Мастера.
Спринт отменяют в том случае, если его цели перестают быть актуальными. Это может произойти вследствие изменения направления работы компании, изменения технологий или рыночных условий. В общем, Спринт нужно отменить, если в силу некоторых обстоятельств в нем уже нет необходимости. Однако, принимая во внимание его короткую продолжительность, отмена редко имеет смысл.
При отмене Спринта все выполненные и “готовые” элементы из Журнала Продукта пересматриваются. Их принимают при условии, что они представляют потенциально готовый к выпуску Инкремент функциональности. Все остальные требования переоцениваются и возвращаются в Журнал Продукта. Работа, проделанная над ними, обесценивается быстро, и поэтому требует пересмотра.
Отмена Спринта требует дополнительных ресурсов, так как все члены Команды должны перегруппироваться при Планировании Спринта и приступить к новому Спринту. Отмена Спринта является для Команды неприятным процессом, однако на деле это происходит довольно редко.

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

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

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

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

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

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

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

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

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

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

Цель Спринта

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

Ежедневные Скрамы

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

• Что было сделано со времени прошлой встречи?
• Что планируется сделать до следующей встречи?
• Что ему мешает в выполнении запланированных заданий?

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

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

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

Обзор Спринта

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

Обзор Спринта включает в себя следующие элементы:

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

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

Ретроспектива Спринта

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

Целью Ретроспективы Спринта является:

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

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

Артефакты Скрама

Артефакты Скрама предоставляются в качестве работы или ценности того, насколько они полезны в обеспечении прозрачности и возможностей для инспекции и адаптации. Определенные Скрамом Артефакты специально спроектированы таким образом, чтобы обеспечить максимальную ясность ключевой информации, необходимой для того, чтобы Скрам Команда достигла успеха в поставке “готового” Инкремента.

Журнал Продукта

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

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

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

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

Отслеживание прогресса на пути к Цели

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

Различные графики типа “сколько осталось ”(burndown) и “сколько сделано ”(burnup), отображающие реальное продвижение, отклонение, и ожидаемое движение, а также другие наглядные практики используются для предсказания прогресса. Эффективность этих практик проверена. Однако их использование не заменяет важности использования принципов эмпиризма. В сложной среде очень трудно предсказать, как будут развиваться события. Единственное на что можно положиться при принятии решений о будущей работе, это опыт прошлого.

Журнал Спринта

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

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

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

Отслеживание прогресса Спринта

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

Инкремент

Инкремент – это сумма всех выполненных требований Журнала Продукта реализованных во время текущего Спринта и всех предыдущих Спринтов. По окончанию Спринта новый Инкремент должен быть «Готовым», то есть он должен быть пригодным к эксплуатации и отвечать определению Скрам Команды понятия “Готовности”. Несмотря на решение Владельца Продукта выпускать ли эту версию Инкремента, он должен быть готовым к использованию.

Scrum доска/Agile Board

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

Пример доски из жизни:

Определение «Готовности»

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

Заключение

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

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

Команда Разработки самостоятельно координирует свою работу для большей степени сотрудничества, роста эффективности и производительности.

Характеристики команд разработки:

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

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

Отсутствие подкоманд
И неважно, какие области работы: тестирование, дизайн или какой-нибудь бизнес-анализ.

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

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

• Планирование Спринта,
• Ежедневный Скрам,
• Разработка Продукта,
• Обзор Спринта,
• Ретроспективы Спринта.

Изменения допустимы на всех этапах, но цель Спринта неприкосновенна, а качество не должно страдать от изменений. Объём работ также можно регулировать и пересматривать по мере приобретения новых знаний, но только совместно — Владельцем Продукта и Командой Разработки.

Цель Спринта — достигнуть цели (масло масляное, но да), поэтому каждый спринт состоит из:

• цели,
• концепции реализации,
• адаптивного плана по её достижению,
• работы по её достижению,
• конечного продукта.

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

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

Отмена Спринта

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

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

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

• какой будет версия продукта в конце спринта?
• как организовать работу, чтобы эту версию получить?

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

Тема первая: что будет сделано?

Владелец Продукта выносит на обсуждение два аспекта:

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

Команда Разработки на этом этапе прогнозирует объём функциональности для разработки в течение Спринта и формирует единое понимание работы в Спринте на основании:

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

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

После прогноза Команды Разработки, Скрам-команда формирует Цель Спринта — она служит ориентиром при реализации элементов из Бэклога и даёт понимание Команде Разработки, зачем создаётся продукт.

Тема вторая: как будет выполнена работа?

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

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

Часто к концу этапа планирования Команда Разработки тщательно детализирует работу, выполняемую в первые дни Спринта: для этого её объём делится на задачи длиною не более 1 дня.

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

Этап планирования завершается, если Команда Разработки может объяснить Владельцу Продукта и Скрам-мастеру, как будет достигнута Цель Спринта и какими способами.

Цель Спринта

Цель Спринта — установленный ориентир, который считается достигнутым, если выполнена нужная часть Бэклога Продукта. Она формулируется во время планирования и объясняет Команде Разработки, для чего создается продукт или его версия. Также Цель связывает элементы Бэклога.

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

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

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

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

Каждый элемент Бэклога должен содержать описание, номер позиции, оценку объема работы и ценность.

Один продукт — один Бэклог, даже если над созданием версии трудится несколько скрам-команд.

Уточнение Бэклога

Непрерывный процесс уточнения, оценки и упорядочивания элементов Владельцем Продукта и Командой Разработки для проверки и пересмотра.

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

Требования к элементам: в начале списка они должны быть более детализированными и понятными по сравнению с расположенными ниже — подробно описанные элементы проще оценивать.

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

Отслеживание прогресса на пути к цели

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

Для прогнозирования скорости движения к цели можно использовать разные практики — например, burn-up и burn-down диаграммы работ или кумулятивные диаграммы. Эти техники полезны, но не могут заменить важность эмпиризма, поскольку неизвестно, что произойдёт, и для принятия решений можно полагаться лишь на то, что уже случилось.

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

Что такое Scrum

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

Основная идея Scrum заключается в том, что проект делится на короткие периоды времени, называемые спринтами (обычно от 1 до 4 недель), каждый из которых заканчивается выпуском работающей модели. В начале каждого спринта команда определяет, что будет сделано в течение этого спринта, и работает над этим до его завершения. Каждый день команда проводит краткий стендап-митинг, чтобы обсудить прогресс и синхронизироваться. Можно делать каждый спринт меньше требуемого времени, например, по готовности каких-то задач (итогов).

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

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

История появления

История появления скрама начинается в 1980-х годах, когда японские ученые Такэучи Нонака (Nonaka Takeuchi) и Хиротака Такэучи (Hirotaka Takeuchi) проводили исследования в области производства автомобилей в Японии. Они обнаружили, что японские автопроизводители, такие как Toyota и Honda, достигают успеха благодаря своей способности быстро адаптироваться к изменениям в рыночных условиях и быстро выпускать новые модели автомобилей.

Они пришли к выводу, что этот успех связан с применением инновационных методологий управления проектами и разработки продуктов, которые позволяют быстро адаптироваться к изменяющимся условиям рынка. Они назвали этот подход «новым знанием производства» и описали его в своей книге «The New New Product Development Game».

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

В 1995 году Кен Швабер встретился с Джеффом Сазерлендом и заинтересовался его методологией. Они продолжили разработку скрама, уточнили и дополнили его принципы и правила, и описали все это в книге «The Scrum Guide», которая была опубликована в 2010 году.

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

Цели и задачи Scrum

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

1. Управление проектом: обеспечивает структурированный подход к управлению проектом, порядок, позволяющий управлять процессом разработки продукта и следить за прогрессом.
2. Коммуникация: поддерживает взаимодействие между всеми сторонами проекта, что способствует быстрому и эффективному решению проблем и достижению общих целей.
3. Прозрачность: обеспечивает прозрачность в процессе разработки, показывает всем участникам проекта, что происходит, и какие задачи выполняются.
4. Улучшение качества: дает команде постоянно совершенствовать качество путем регулярного обмена мнениями и обратной связи, а также постоянного внедрения улучшений и оптимизации процесса.
5. Адаптивность: дает команде быстро реагировать на изменения и адаптироваться к новым условиям, что особенно важно в современном быстро меняющемся бизнес-окружении.
6. Управление рисками: обеспечивает структурированный подход к управлению рисками, позволяя команде рано определить и минимизировать риски, связанные с проектом.

Группа новаторов, когда-то создала «Манифест гибкой разработки программного обеспечения», который лег в основу Agile и Scrum. В него вошли всего четыре пункта:

• Человек важнее инструментов.
• Качество продукта важнее документации.
• Взаимодействие с заказчиком важнее контракта.
• Готовность вносить изменения ранее установленного плана.

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

1. Удовлетворение заказчика через раннюю и непрерывную поставку ценного программного обеспечения
2. Приветствовать изменения требований, даже на поздних стадиях разработки
3. Регулярно поставлять работающее программное обеспечение, отдавая предпочтение коротким срокам
4. Бизнес-люди и разработчики должны ежедневно работать вместе на протяжении всего проекта
5. Создавать проекты вокруг мотивированных людей
6. Самый эффективный способ представить и передать информацию — это личные разговоры
7. Работающее программное обеспечение — основной критерий оценки прогресса
8. Agile-процессы способствуют устойчивому развитию
9. Постоянное внимание к техническому совершенству и хорошему дизайну улучшает гибкость
10. Простота — это искусство максимизации количества работы, которую нужно не делать
11. Самоорганизация команды (каждого человека) и ее способность к адаптации
12. Регулярная оценка и анализ процессов разработки и продукта.

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

Этапы работы по методу Scrum

Scrum включает следующие этапы работы:

1. Планирование: В начале каждого спринта команда и владелец продукта (или человек, его представляющий) проводят планирование, определяя цели, время, объем работы и ожидаемые результаты спринта.
2. Итерация (Спринт): Работа в Scrum основана на итерациях, называемых спринтами, которые обычно длительностью от 1 до 4 недель. Команда разработчиков работает на протяжении всего спринта, совершенствуя скрам-проект и выполняя задачи.
3. Постоянное обновление: Команда регулярно обновляет продукт, предоставляя новую функциональность, исправления ошибок и т.д.
4. Проверка (Review): в конце каждого спринта команда проводит проверку продукта, демонстрируя свои достижения заказчику или владельцу.
5. Ретроспектива (Retrospective): Команда проводит ретроспективу для анализа работы, выявления проблем и поиска способов улучшения процесса работы.
6. Планирование следующего спринта: В конце каждого спринта команда проводит моделирование следующего спринта, определяя новые цели и объем работы.

Планирование спринта в Scrum происходит в несколько этапов:

1. Предварительная оценка объема работы: команда разработчиков вместе с владельцем продукта определяет, что необходимо выполнить в следующем спринте, а также оценивает их объем и сложность.
2. Определение целей: команда разработчиков и владелец продукта (или человек представитель) определяют, какие цели, время и ожидаемые результаты должны быть достигнуты в рамках спринта.
3. Создание плана спринта: команда разработчиков определяет, какие задачи будут выполнены в рамках спринта, как они будут выполнены, кто будет ответственен за выполнение каждого пункта и какие зависимости между задачами существуют.
4. Оценка рисков: команда разработчиков и владелец продукта проводят анализ рисков и определяют, какие меры будут предприняты для минимизации рисков и обеспечения успешного завершения спринта.
5. Создание бэклога спринта: команда разработчиков создает список задач (бэклог) для выполнения в рамках спринта.
6. Определение продолжительности спринта: команда разработчиков определяет, какой будет продолжительность спринта.
7. Завершение планирования спринта: команда разработчиков и владелец продукта проводят окончательное согласование плана спринта и договариваются о дальнейших шагах.

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

Составляющие Scrum

Разберем 10 главных элементов Scrum. Основные элементы:

1. Команда разработчиков (Development Team): группа специалистов, которые работают вместе для достижения результата.
2. Владелец продукта (Product Owner): представитель заказчика, ответственный за определение требований, приоритезацию задач и принятие решений моментом.
3. Скрам-мастер (Scrum Master): человек, ответственный за поддержание процесса работы команды в соответствии с принципами Scrum, устранение препятствий и обеспечение эффективного взаимодействия между участниками.
4. Бэклог или журнал продукта (Product Backlog): список задач и требований к продукту, который поддерживается и управляется владельцем.
5. Бэклог спринта (Sprint Backlog): список задач, выбранных командой разработчиков для выполнения в рамках текущего спринта. Спринты и итерации могут повторятся.
6. Спринт (Sprint): период времени, обычно от 1 (реже — двух) до 4 недель, в течение которого команда разработчиков работает над единой задачей.
7. Планирование спринта (Sprint Planning): встреча, на которой команда разработчиков и владелец продукта определяют цели и объем работы на следующий спринт.
8. Ретроспектива спринта: встреча, где анализируются результаты последнего спринта и ищет способы улучшения процесса работы в будущем.
9. Обзор спринта: встреча, которая демонстрирует результаты последнего спринта заказчику или владельцу.
10. Инкремент продукта (Product Increment): новая функциональность, которая добавлена в продукт в результате работы команды разработчиков в течение спринта.

Состав Scrum-команды

Scrum-команда состоит из трех ролей: команда разработчиков (Development Team), владелец продукта (Product Owner) и скрам-мастер (Professional Scrum Master).

Рассмотрим подробнее каждую из ролей:

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

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

Принципы работы Scrum-команды

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

1. Постоянное самосовершенствование. Опытные разработчики рассказывают, что совершенствование продукта, доведение до идеального состояние невозможно без самосовершенствования каждого члена команды.
2. Автономность. Все сотрудники должны отвечать не только за общий результат и уметь работать в коллективе, но и выполнять многие обязанности индивидуально.
3. Кросс-функциональность. Любая команда самодостаточна, так как в нее входят специалисты с разными навыками.

Остальные принципы работы Scrum-команды включают в себя:

• Работа в итерациях (спринтах)
• Коллективная ответственность за результат
• Прозрачность и открытость
• Адаптивность и гибкость
• Постоянное улучшение процесса
• Регулярные обзоры и ретроспективы
• Стремление к высокому качеству
• Самоорганизация и автономность команды
• Непрерывный процесс обратной связи
• Обеспечение приоритетности
• Распределение ролей и обязанностей
• Ориентация на потребности заказчика

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

Плюсы и минусы Scrum

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

Плюсы

Минусы

Гибкость и адаптивность. Scrum помогает командам быстро реагировать на изменения в проекте и быстро адаптироваться к новым требованиям заказчика, учитывая при этом предыдущие. Улучшение качества продукта. Команда может сосредоточиться на создании высококачественного продукта, благодаря регулярным обзорам и ретроспективам. Улучшение коммуникации. Стимулирует команду к постоянной коммуникации и обратной связи, что способствует более эффективному решению проблем и улучшению процесса. Развитие команды. Стимулирует развитие команды, поскольку каждый участник команды имеет возможность выражать свои идеи и мнения. Быстрый запуск продукта на рынок. Быстро разрабатывать и выпускать товары на рынок.

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

Как и зачем проводятся совещания в Scrum

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

Ниже описаны мероприятия, проводимые в Scrum, и их цели:

1. Разработка бэклога продукта. Владелец разрабатывает концепцию продукта с учетом ситуации на рынке, потребностей пользователей. На основании этого составляется перечень требований к проекту, которые распределяются по приоритетности. Готовый бэклог — это техническое задание для команды.
2. Сбор команды. Scrum-команда — единое целое. В проекте участвует небольшая группа специалистов разного профиля (6–10 человек). Они работают на общий результат и стремятся к одной цели.
3. Sprint Planning (Планирование спринта) — это совещание, с которого начинается в каждый спринт, и предназначено для определения плана работы команды на протяжении спринта. Целью является определение того, что команда должна достигнуть в следующем спринте, и какие задачи будут выполнены в этот период.
4. Daily Scrum (Ежедневное совещание, стендап) — это совещание ежедневное, и длится обычно не более 15 минут. Целью Daily Scrum является обмен командой информацией о прогрессе работы, проблемах, возникших при выполнении задач и планах на ближайший период.
5. Scrum-доска. Команда использует физические либо программные доски, пространство которых разделяется на части, отражающие стадии работы над продуктом. Их количество может варьировать, но обязательно включает в себя три пункта (слева направо):
   • запланированные задачи;
   • задачи в активной работе;
   • выполненные задачи.

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

6. Sprint Review (Обзор спринта) — это совещание в конце каждого спринта и предназначено для презентации продукта, разработанного командой в течение спринта. Целью является демонстрация продукта заинтересованным сторонам и сбор обратной связи.
7. Sprint Retrospective (Ретроспектива спринта) — проводится после обзора спринта и предназначено для обсуждения работы команды, выявления проблем и поиска способов их решения. Целью этого совещания является улучшение процесса разработки продукта и устранение препятствий, которые могут повлиять на результаты команды в будущем.

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

Пошаговое внедрение Scrum

Принципы Scrum — это итеративность, инкрементальность, прозрачность и коллективная ответственность. Вот пошаговое внедрение Scrum:

1. Выберите владельца продукта, который четко определит, что должно быть сделано.
2. Сформируйте скрам-команду.
3. Назначьте скрам-мастера.
4. Создайте бэклог проекта в виде списка пользовательских историй. Включите в него все задачи, которые команда могла бы сделать для глобальной цели, и расставьте их по приоритету. Вперед вынесите задачи, в которых заключена основная функциональность и которые принесут доход заказчику.
5. Оцените задачи из бэклога, используя относительные величины, например, размеры футболок или числа из последовательности Фибоначчи. Оценивайте задачи всей командой с помощью покера планирования (planning poker): используйте колоду карт или приложение на смартфон.
6. Проведите планирование спринта: выберите задачи и распределите их между исполнителями.
7. Заведите скрам-доску, поделите ее на три части: нужно сделать, в работе, сделано. Перемещайте стикеры с задачами, чтобы видеть динамику работы. Используйте реальную или виртуальную доску.
8. Не забывайте о ежедневных собраниях.
9. В конце спринта проведите демонстрацию.
10. Соберитесь на ретроспективу, обсудите, как улучшить работу, какие препятствия устранить. Это может быть неработающая кофемашина, тормозящий компьютер, некомфортная температура воздуха, вспыльчивость коллеги, недобросовестный подрядчик. Когда команда начинает работать по scrum, решаются проблемы, которые месяцами откладывались в долгий ящик.
11. Начинайте следующий спринт с планирования.

Отличия Scrum от Kanban и Agile

Scrum, Kanban и Agile — это три подхода к управлению проектами. Ниже разберем отличия между ними.

Scrum:

• Это гибкая методология управления проектами, разработанная для разработки ПО и других продуктов.
• Имеет явную структуру, включая роли (Scrum Master, Product Owner, команда разработчиков), практики и артефакты.
• Работа происходит в рамках спринтов (обычно 2-4 недели), в которых команда выполняет задачи из Sprint Backlog.
• Подчеркивает коллективную ответственность и доверие между членами команды.

Kanban:

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

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

Agile:

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

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

Ошибки работы по Scrum

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

1. Недостаточное понимание ролей и ответственностей внутри команды Scrum. Каждая роль имеет свои обязанности, и непонимание этого может повлечь путаницу и конфликты.
2. Отсутствие ясного и общего понимания того, что нужно достичь в рамках спринта. Это может убрать фокус и ускорить работу, что не всегда полезно для достижения результата.
3. Перегрузка спринтом. Это может произойти, когда команда берет на себя слишком много для выполнения в рамках одного спринта. Так команда не успеет завершить все задачи, и это может повлиять на общий результат проекта.
4. Неправильное планирование спринта. Некоторые команды могут просто вынимать задачи из Product Backlog и пытаться выполнить их в рамках спринта без достаточного планирования. В итоге — проблемы в процессе выполнения задач и снижение производительности.
5. Недостаточная коммуникация между членами команды. Руководство основано на коллективной работе, и взаимодействие является ключевым элементом этой методологии. Ее недостаток — потенциальная неопределенность и дополнительные недопонимания.
6. Неверная оценка задач. Команда Scrum может неправильно оценить задачи, следствие — срыв сроков или команда не будет работать с максимальной эффективностью.
7. Отсутствие непрерывного улучшения. Scrum предполагает, что команда будет постоянно анализировать свою работу и совершенствоваться. Несоблюдение этого принципа — затягивание и снижение эффективности команды.

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

Рассмотрим примеры ошибок:

• Иногда проблемы возникают и с разработчиками. По сути, если в команде уже есть владелец продукта и Scrum-мастер, все остальные члены группы – это равноправные разработчики, от чьей слаженной работы зависит результат проекта. Еще разработчика можно назвать developer, что в более распространенном вольном переводе означает: «тот, чьей работой является создание новых идей и продуктов». Так вот, если разработчики теряют равноправие, разбиваясь на меньшие команды в составе группы, то команда перестает быть эффективной и функциональной. Такая ошибка так же понимается, как неверное распределение ролей в Scrum-группе.
• Бывает, что разработку продукта (например, сайта) команде заказал не один заказчик, а несколько. Представления о конечном результате в процессе разработки могут не совпадать и группа «единомышленников» превращается в несогласованную хаотичную силу, которая выбирает разные стороны. Они начинают по очереди высказывать каждый свои требования и мешают команде сосредоточиться на результате. О чем свидетельствует такая картина? Можно с уверенностью сказать, что в данном случае в команде некомпетентный владелец продукта, который не способен скоординировать действия заказчиков, приведя их к единому знаменателю, и довести до команды Scrum четко сформулированные условия, основанные на общих пожеланиях клиентов.
• Другой пример относится к ошибкам Scrum-мастера. Этот специалист должен быть ответственным за медиацию команды, призван налаживать внутреннюю связь в группе разработчиков, грамотно направляя каждого к созидательной миссии. А он всего лишь сосредотачивается на формальном выполнении своих обязанностей: ведет собрания и контролирует действия разработчиков. Иногда, не умея смотивировать членов команды, сам выполняет их функции, идя по пути наименьшего сопротивления. Ни о каком эффективном построении процесса в данном случае речь не идет.

Книги по Scrum

Чтобы понять как это работает в реальности, нужно лучше углубиться в тему. Лучшие книги про Scrum:

1. Скрам Гайд. Исчерпывающее руководство: Правила Игры / Кен Швабер, Джефф Сазерленд. Руководство по применению скрама: описывает роли, мероприятия, артефакты скрама, и правила их использования. Гайд составлен и поддерживается соавторами методологии, осталось только разобраться в терминологии.
2. Скрам. Революционный метод управления проектами / Джефф Сазерленд. Бестселлер соавтора scrum раскрывает историю создания и основные принципы методики. Автор приводит потрясающие примеры скрама в действии. Читать обязательно, чтобы загореться тут же внедрить в работу и жизнь.
3. Скрам Джефф Сазерленд Роман Пихлер. Управление продуктом в Scrum. Agile-методы для вашего бизнеса / Роман Пихлер. Существенная часть книги посвящена владельцу продукта: его функциям, качествам, ошибкам. Автор подробно рассматривает процесс создания продукта по скрам методологии, начиная продумыванием концепции будущего продукта и заканчивая созданием отчетов.
4. Agile-манифест разработки ПО. Состоит из нескольких строк, в которых заложены основные принципы разработки по гибким методологиям.
5. Кеннет С. Рубин. «Основы Scrum». Эта книга даст более углубленное понимание технологии Scrum применительно к данной сфере разработок. Автор собрал словарь терминов, а для лучшего понимания материала текст издания подкреплен примерами и иллюстрациями.
6. Кен Швабер. «Скрам». Еще один из основателей поделился своим практическим и теоретическим видением плюсов и минусов работы технологии.
7. Хенрик Книберг. «Scrum и XP: заметки с передовой». Автор имел возможность экспериментировать с различными Agile-практиками, о чем и рассказывает в своей книге, используя понятные наглядные примеры.
8. Майк Кон. «Scrum: гибкая разработка ПО». Авторское понимание процессов Scrum подкреплено результатами собственных экспериментов. Знания и опыт, описанные автором книги, можно также применить для внедрения гибкого метода Scrum в работу любой организации.

Часто задаваемые вопросы

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

Сегодня scrum-методологию используют как крупные компании, такие как Google, Amazon, Microsoft, Adobe, так и стартапы. Но подход не универсален: если команда работает по заданному алгоритму, выполняет повторяющиеся задачи, скрам только усложнит процесс. Сейчас фреймворк успешно используется во многих других индустриях: в материальном производстве (например, Северсталь, SOKOLOV), в маркетинговых агентствах и дизайнерских студиях, в телеком-компаниях (Tele2, МТТ), в фармакологии (BIOCAD), в розничных сетях (X5 Retail Group, МВидео) и др.

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

Если продукт разрабатывает удаленная команда, то ведение по scrum можно организовать в специальных сервисах. Например, Scrum-доска в Jira от Atlassian позволяет объединить все данные по проекту. Такая доска отображает прогресс во время цикла разработки. Любой участник команды может в любое время получить доступ к доске, написать об окончании или сообщить сколько осталось времени по прошлой задаче. Для организации спринта нужно заполнить бэклог проекта.

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

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

Работа над скрам-проектами ведется в специальных приложениях и программах. Многофункциональный интерфейс дает возможность следить за ходом работы с разных ракурсов. Есть три популярных приложения для скрам:

1. Worksection. Простой интуитивно понятный сервис для работы над проектами и решения задач бизнеса.
2. Scrumdo. Чисто скрамовский сервис с планированием итераций, покером, карточками-задач. В остальном стандартный пакет функций с отчетами, диаграммами и гистограммами.
3. Jira. Программный инструмент для управления проектами, разработанный компанией Atlassian. Jira часто используется в IT-компаниях для формирования списка задач, отслеживания общего прогресса команды и решения возникающих по ходу разработки продукта проблем.

Заключение

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

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

Нашли ошибку в тексте? Выделите нужный фрагмент и нажмите
ctrl
+
enter