Фреймворк scrum что это
Что такое Scrum и как правильно использовать его в рабочем процессе
Что такое Scrum
Коротко говоря, Scrum — это способ организации рабочего процесса. Он пришел из мира разработки программного обеспечения и сейчас применяется в разных сферах бизнеса. Метод изобрели программисты Кен Швабер и Джефф Сазерленд. Они наблюдали за тем, как работают американские военные и спецназ и пришли к выводу, что основа успеха состоит в качественной командной работе. Сам же термин пришел из регби и в переводе с английского означает «схватка».
Scrum принадлежит к Аgile — семейству »гибких» подходов к организации процессов. Он состоит из минимального количества элементов, которые помогают успешно организовать работу. При помощи метода Scrum можно быстро и эффективно разработать принципиально новый продукт, аналогов которому нет на рынке.
Особенность Scrum заключается в командном подходе и нестандартном распределении обязанностей внутри коллектива. В процессе участвуют не только сотрудники компании, но и бизнес-заказчики, которые должны включаться в процесс создания продукта чаще, чем при других подходах, и делать это преимущественно в личном общении, а не через документы. Команде приходит постоянная обратная связь от заказчика, что позволяет не сбиться с пути.
Если компания создает новый продукт, но имеет мало представлений о результате, к которому хочет прийти, и не видит перед собой четкий план, — методология Scrum поможет справиться с этой проблемой. Она позволяет постепенно идти к нужному результату и на протяжении всего пути проверять эффективность и ценность проделанной работы. Команда придет к итогу, который полностью устроит заказчика.
Состав scrum-команды
В первую очередь в команду входят разработчики. Так в Scrum называют специалистов, которые вносят вклад в продукт. Все разработчики — часть единой команды. У них нет отдельных заданий или подкоманд. При методе Scrum все работают как единое целое. Состав группы не должен меняться, поэтому важно, чтобы в нее изначально входили все необходимые для проекта профессионалы. Так команда становится независимой от всех внешних воздействий и может функционировать без посторонней помощи.
У сложившейся команды не должно быть лидера. Работа строится на взаимном обмене мнением и знаниями, за счет чего стимулируется кросс-функциональность. Разработчики дополняют друг друга и решают поставленные задачи совместными усилиями. Со временем команда становится все более сплоченной, что положительно влияет на ее продуктивность.
Для успешной работы в команде должно быть от пяти до девяти человек. Если проект большой, набирают несколько команд, которые распределяют между собой задачи.
В работе команды должен участвовать владелец продукта — сам заказчик или его представитель. Он консультирует разработчиков, передает свежие требования компании к будущему продукту и следит за тем, чтобы работа шла в верном направлении.
Третий элемент команды — scrum-мастер. Он выступает в роли куратора и помогает коллективу сплотиться. Мастер проводит ежедневные собрания, помогает найти выход из тупикового этапа разработки и перевести команду на нужное направление. Главный успех scrum-мастера — сделать так, чтобы команда стала самоуправляемой и перестала в нем нуждаться. В идеале должны остаться только разработчики и владелец продукта.
Основные принципы работы по Scrum
После создания команды нужно определить список требований к продукту и составить техническое задание, которое получат разработчики. Далее работу делят на спринты — одинаковые промежутки времени, которые не должны длиться дольше четырех недель. Каждому кругу ставится конкретная цель. Количество таких спринтов неограниченно. В конце спринта команда должна приходить к результату и получать обратную связь от заказчиков о проделанной работе.
Спринт считается завершенным, если команда смогла прийти к цельному итогу и создала продукт, который готов к использованию. К следующему спринту переходят только тогда, когда заказчики и члены команды довольны результатами предыдущего. Если разработчики не успевают уложиться в оговоренные сроки, они сообщают об этом владельцу продукта, и он перераспределяет время. Если команда справляется с задачей быстрей назначенного срока, она может подключить в текущий спринт дополнительные цели.
Чем Scrum отличается от Kanban
Метод управления проектами Kanban также принадлежит семейству Agile. Но Scrum — это структурированный подход с четко прописанными этапами создания продукта, а Kanban — сбалансированный. Его главная задача — сделать так, чтобы у всех членов команды было одинаковое количество работы. В Kanban не должно быть переработок части команды и ситуаций, когда некоторые сотрудники осталась без задач и не знают чем себя занять.
Основное отличие двух методов — это спринты. В Scrum предусмотрены четко организованные периоды работы с конкретными задачами на период, а в Kanban участники команды могут получать новые задачи хоть каждый день. Scrum-команды выполняют работу на время, в Kanban задачи поступают в непрерывном режиме. Для отслеживания достижений и процесса в Kanban используют доски — элемент управления, который наглядно показывает уровень выполнения задач. В Scrum этой задаче служат окончания спринтов.
Преимущества Scrum
Scrum хорошо подходит для быстрого создания новых продуктов. Он помогает объединить сотрудников из разных подразделений и наладить между ними слаженную работу. В результате такой системы увеличивается эффективность рабочей команды.
Вице-президент «Ренессанс страхование» Владимир Тарасов рассказал РБК Трендам, к каким результатам пришла компания после применения метода:
«Мы теряли эффективность при передаче работы из одной функции в другую. Подразделения компании, противодействующие мошенничеству, обладали собственными целями. Каждый сотрудник отвечал за свою работу и выполнял ее хорошо. Но общий результат оставлял желать лучшего.
Мы организовали кросс-функциональные команды, взяв за основу Scrum. Команды, состоящие из инженеров-автотехников, сотрудников службы безопасности, риск-менеджмента и юристов, получили общую цель. Из Scrum мы взяли принцип работы итерациями, а также основные элементы фреймворка. Скорость взаимодействия функций и координация между сотрудниками разных функций увеличилась кратно. С лета прошлого года у нас функционирует уже семь таких команд.
Команды создали скоринги и уникальные критерии выявления мошенничества, снизили уровень латентного мошенничества до минимальных значений. Мы отсекаем мошенников от наших клиентов при первом обращении в компанию. В некоторых ситуациях даже удавалось выявить криминальные случаи еще до подачи заявления о страховой выплате. В итоге уровень страхового мошенничества в самых проблемных регионах снизился без преувеличения в разы и произошло это в течение примерно шести месяцев с момента запуска первой команды. Очень крутой и где-то неожиданный результат!»
Недостатки Scrum
Scrum помогает быстро и эффективно решать задачи, но он подходит не для всех компаний и не для всех ситуаций. Чтобы метод заработал, у компании должно быть поле для экспериментов. Если фирма выполняет задачи по заранее выстроенному алгоритму, знает к чему хочет прийти и как достичь результата, теряется смысл использования такого метода.
Владимир Тарасов:
«Scrum не подходит для текущей операционной деятельности. Он больше ориентирован на проекты. У нас не классический Scrum. Мы объединили текущую работу по конкретным страховым случаям с проектами и задачами на улучшение процесса, разработку и испытание новых инструментов. Scrum не дает ответа, как сочетать операционную работу с проектами. Мы придумали свои собственные инструменты сочетания несочетаемого. Сам фреймворк это допускает».
У компании должны быть ресурсы на запуск такой программы. Scrum предполагает, что команда работает с проектом, аналогов которому нет на рынке. Получается, успех его разработки может не оправдаться или занять слишком много времени. Фирма должна быть финансово готова к такому результату.
Scrum не подходит для слишком сложных и больших проектов. Можно создать несколько команд, которые будут работать над разными деталями идеи, но их будет сложно скоординировать, и работа может зайти в тупик.
После продолжительного времени работы команды Scrum приходят к упадку. Заканчивается творческий потенциал, и падает динамика производительности. Команды приходится разрушать или перестраивать, поэтому Scrum больше подходит для краткосрочных проектов.
Важный критерий успешной работы — заказчик должен быть готов к постоянному общению с командой. Он должен следить за развитием проекта и давать свой фидбек. Без такой обратной связи не получится использовать методику.
Как внедрить Scrum для управления бизнес-процессами
Чтобы внедрить метод в компанию и получить первые результаты, нужно минимум три месяца. Через такой промежуток времени команда начинает работать эффективно и сплоченно. При условии, что выполнены все необходимые условия.
Как внедрить Scrum в компанию
Подробную инструкцию по внедрению Scrum и о его процессах можно посмотреть в гайде или в книге от соавтора методологии Джеффа Сазерленда «Scrum: революционный метод управления проектами». О том, как правильно распоряжаться ресурсами и повышать личную эффективность, читайте в материале РБК Трендов про бережливое производство в жизни.
Мини-справочник и руководство по Scrum
Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.
Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.
Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.
Члены команды должны быть довольны своей деятельностью, быть счастливыми в своей работе. Состояние счастья приводит людей к превосходным результатам.
Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса
— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.
Мини-справочник Scrum
Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.
Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.
Основные обязанности и ответственность Product Owner при управлении Product Backlog:
Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.
Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.
Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
User – пользователь продукта.
Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.
Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.
User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.
Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.
Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.
Sprint Goal (спринт гоол) – цель спринта.
Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.
Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.
Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.
Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?
Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.
Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.
Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.
Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.
Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.
Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.
Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.
Руководство Scrum
Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.
Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.
123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.
User Story
Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?
Формируется Sprint. Sprint Planning Meeting. Scrum Poker
Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.
Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:
Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.
Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.
Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.
Sprint Retrospective Meeting. Ретроспектива.
Проводится в последний день спринта.
Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?
Что такое scrum, как его реализуют и для чего применяют
Создайте рассылку в конструкторе за 15 минут. Отправляйте до 1500 писем в месяц бесплатно.
Отправить рассылку
Scrum — это набор принципов и инструментов, которые чаще всего применяют в IT-разработке. С их помощью разработчик может сделать работоспособный продукт в ограниченные по длительности итерации, именуемые спринтами. Возможности продукта определяют при планировании спринта. Краткосрочность итераций обеспечивает предсказуемость разработки и одновременно гибкость процесса.
Scrum как часть agile
Scrum (скрам) относят к agile-подходам. Такие подходы часто называют фреймворками. Их суть состоит в использовании набора инструментов для ускоренной разработки. Проще говоря, фреймворк — это каркас, состоящий из множества типовых шаблонов (библиотек), которые можно дорабатывать. При создании продукта по принципам scrum разработчик не тратит время на создание элементарных вещей и может сосредоточиться на уникальных задачах.
Представьте, что бригаде рабочих нужно построить дом. Для строительства нужно много разнообразных материалов: кирпич, арматура, балки, кровля и прочее. Если вести все работы с нуля, то рабочим придётся самостоятельно делать кирпичи, отливать арматуру и создавать другие стройматериалы. Это долго и сложно.
Вместо этого строители используют готовые материалы и строят каркас: фундамент, стены, крышу. Получился почти готовый дом. На этапе чистовой отделки рабочие уже могут экспериментировать, чтобы создать готовый уникальный продукт.
Согласно айджал-философии, при реализации проекта не стоит руководствоваться исключительно утверждёнными планами. Необходимо ориентироваться на изменяющиеся условия окружающей среды, учитывать обратную связь от заинтересованных лиц. Такие принципы мотивируют разработчиков к поиску уникальных решений, не ограниченных жёсткими стандартами.
Вместе с тем scrum и agile — не синонимы. Под agile подразумевают образ мышления, когда вся команда меняет своё отношение к созданию итоговой ценности. Достичь подобных изменений в короткие сроки не получится. Однако можно внедрить scrum, использующий основополагающие аджайл-принципы.
В основе scrum-структуры — непрекращающееся обучение и готовность приспосабливаться к изменяющимся факторам: в самом начале команда ничего не знает, но в процессе она развивается и применяет полученный опыт.
Важно понимать, scrum — это не пошаговый метод. Он не описывает, как именно нужно работать и какие решения принимать. Какие-то пошаговые инструкции в скрам отсутствуют. Взамен этого метод дает комплекс базовых рекомендаций по организации процесса.
Scrum — это фреймворк. Он определяет порядок организации процессов, однако предполагает уникальное содержание для всякого отдельного проекта. То есть изначально команда не знает, что будет делать, но знает, как это сделать.
Как работает scrum
Как методология управления проектами, scrum предполагает, что самоорганизованная команда представляет законченный продукт в фиксированный временной отрезок (спринт). Для успешного применения scrum, необходимо разобраться в его структуре. Она включает правила, роли, события и артефакты.
Главное правило: scrum строится по принципу «3-5-3»: 3 роли, 5 событий, 3 артефакта. Если хоть один из этих элементов отсутствует, то технологию нельзя назвать scrum.
Роли scrum
Scrum-команду образуют владелец продукта, команда разработчиков и scrum-мастер. При этом разработчиками выступают маркетологи, программисты, верстальщики и иные специалисты, что зависит от потребностей разработки.
Владелец продукта
Он ответственен за общий список задач (бэклог продукта). Владелец продукта scrum (scrum Product Owner) обязан определить приоритетность задач.
Остальные члены команды высказывают своё мнение. Но именно владелец продукта устанавливает ценность конкретной задачи и принимает решение, которое способны реализовать разработчики.
Владелец обеспечивает согласованность команды. Он постоянно на связи с разработчиками. Он отслеживает процесс, советует и контролирует соответствие решению.
Владелец продукта взаимодействует с заказчиками и заинтересованными лицами, собирает информацию, определяет требования. Он должен обеспечить команде условия, при которых она сможет создать максимальную ценность. Владелец в scrum бывает лишь один, поскольку разносторонние указания вносят хаос в работу.
Команда разработчиков
Команда scrum отвечает за исполнение работ из бэклога спринта. Без согласия скрам-команды никто абсолютно не вправе заносить поправки в бэклог.
Правильная команда в scrum самостоятельно определяет, как именно работать, какие конкретные работы проводить в пределах спринта, как повысить ценность. Любой из участников располагает собственными навыками, при этом все друг друга обучают и делятся рабочими нюансами. Это позволяет не нарушить процесс из-за чьей-то ошибки или несостоятельности.
Scrum-команда общается с владельцем продукта для совместного достижения поставленных целей. Но команда сама разрабатывает план каждой итерации и прогнозирует объём работ, учитывая прошлые спринты.
Scrum-мастер
Scrum-мастер — это наставник, тренер, организатор и дипломат. Он умеет быстро устранять возникающие препятствия, составляет список всех необходимых ресурсов, старается обеспечить максимальную продуктивность команды.
Вернёмся к примеру со строительной бригадой. В роли владельца продукта выступает подрядчик. Он напрямую взаимодействует с заказчиком, формулирует и ставит задачи. Команда — это строители, работающие над проектом. Scrum-мастером будет прораб, который руководит бригадой, обсуждает работы с владельцем продукта и направляет команду в нужном направлении.
События scrum
Основой scrum выступают спринты — чёткий ритм работы команды. Продолжительность спринта варьируется — как правило, от одной до четырёх недель. Любые scrum-события связаны со спринтом.
Организация бэклога
За данное событие в скрам отвечает владелец продукта. Он следит, чтобы продукт соответствовал требованиям, отслеживает рыночную ситуацию, уточняет потребности заказчика.
Владелец ведёт учёт задач, определяет приоритеты, обеспечивает актуальность собранной информации. Это позволяет команде в любое время начать реализацию уточнённых задач.
В процессе организации бэклога владелец фиксирует все сведения, собранные о продукте и требованиях к нему. Затем на основе анализа собранной информации составляют техническое задание. Оно состоит из списка задач, выстроенных по уровню приоритетности.
Совместно с командой и scrum-мастером раз в спринт проходит груминг бэклога. Это встреча, на которой бэклог актуализируют, дополняют новыми вопросами и задачами.
Планирование спринта
Команда разработчиков совместно со scrum-мастером планирует на общем собрании объём работ для предстоящего спринта и устанавливает цели.
Команда решает, какие задачи можно сделать в рамках спринта. По окончанию собрания участники понимают, что можно сделать за одну итерацию и как это реализовать.
Ежедневное совещание (стендап)
Краткосрочное совещание, максимум до 15 минут, проводят ежедневно. Обычно в начале рабочего дня команда подводит итоги выполненных работ, обменивается мнениями, уточняет неясные моменты. Каждый участник получает свой рабочий план на период до очередного стендапа.
Обычно участники стендапа рассказывают:
На ежедневных коротких скрам-совещаниях участники рассказывают, что им мешает в успешном достижении поставленной цели.
Обзор итогов спринта
По окончании спринта вся команда совместно просматривает и изучает результат (инкремент). Разработчики демонстрируют продукт заинтересованным лицам. Владелец продукта определяет, возможно ли запускать созданный продукт.
На основе обзора владелец дорабатывает бэклог продукта и это может стать началом планирования последующего спринта. Без проведения обзоров работа над продуктом будет вестись «вслепую» — без учёта мнения заказчиков.
Ретроспектива спринта
Это scrum-мероприятие предназначено для обзора завершённых этапов. Команда записывает результаты, обсуждает нюансы спринта и сопутствующих процессов.
Задача ретроспективы в scrum — привлечь внимание команды к тому, что получилось и что можно попытаться улучшить в следующий раз. При этом событие не имеет цели акцентировать ошибки.
Все перечисленные события происходят в течение одного спринта. После определения длительности итерации менять сроки разработки нельзя. Такой подход помогает команде использовать ценный опыт из прошлого спринта и учитывать сделанные выводы в будущем.
Посмотрим, как будут выглядеть мероприятия у нашей бригады строителей, которая работает по scrum:
Организация бэклога — подрядчик составляет перечень работ, которые нужно сделать и определяет их приоритетность. Например, в такой очерёдности — строительство фундамента, кладка стен, устройство крыши и прочее.
Планирование спринта — строители вместе с прорабом определяют, за какой срок можно закончить конкретную работу, что должно получится в итоге и как будут вестись работы.
Стендап — ежедневно по утрам строители обсуждают, что уже сделано и что нужно сделать. Прораб выдаёт разнарядку на день каждому рабочему.
Обзор итогов спринта — бригада демонстрирует результат завершённого этапа. К примеру, показывает подрядчику готовый фундамент. Одновременно можно обсудить вопрос о нюансах строительства стен (планирование очередного спринта).
Ретроспектива спринта — строители обсуждают оконченный этап работы: что получилось хорошо, а что плохо, какие ошибки возникали и как их можно было избежать.
Далее бригада переходит к осуществлению следующего этапа работ (последующий спринт) и порядок мероприятий повторяется. И так до полного завершения строительства и передачи готового дома заказчику.
Артефакты scrum
Артефакты scrum — это работы, которые надлежит сделать для завершения спринта. Они обеспечивают прозрачность проекта для всех участников.
Бэклог продукта
Это основной перечень всех запланированных работ. Его ведёт владелец. Список постоянно видоизменяют — меняют требования, добавляют улучшения. Руководствуясь списком, можно определить конкретные задачи.
Владелец продукта всё время работает над бэклогом, пересматривает приоритеты и перепроверяет актуальность. Если этого не делать, то из-за рыночных изменений либо новой информации некоторые задачи могут стать неактуальными.
Бэклог спринта
В состав этого скрам-артефакта включены рабочие задачи, реализуемые в рамках спринта.
Бэклог спринта не обязательно фиксировать, он может меняться в процессе. Но никакие препятствия или изменения не должны помешать достижению поставленной цели — результату, который команда хочет получить в итоге.
Инкремент
Это цель спринта. Часто под инкрементом подразумевают критерии готовности. Причём это может относиться к определённой контрольной точке, цели отдельного спринта либо полноценной версии продукта, готовой к использованию.
Ну и снова наша scrum-бригада строителей. Разберём, как будут выглядеть артефакты в данном случае:
Бэклог продукта — перечень всех работ, которые нужно выполнить для строительства дома.
Бэклог спринта — отдельный этап работ, разбитый на стадии. К примеру, чтобы завершить этап подготовки фундамента нужно выкопать траншею, выложить подушку, установить арматуру, залить бетон. Бригада примерно знает, сколько это займёт времени. Но в случае непредвиденных обстоятельств сроки можно изменить. Главное — достичь цели — сделать фундамент.
Инкремент — цель определённого этапа. Например, на этапе кладки стен инкрементом будут готовые стены. При этом критериями готовности могут служить такие параметры, как соответствие заданным размерам, отсутствие кривизны, наличие необходимых проёмов.
Как применять scrum удалённым командам
Если продукт разрабатывает удалённая команда, то ведение проекта по scrum можно организовать в специальных сервисах. Например, Scrum-доска Jira от Atlassian позволяет объединить все данные по проекту.
Такая доска отображает прогресс во время цикла разработки. Любой участник команды может в любое время получить доступ к доске. Для организации спринта нужно заполнить бэклог проекта.
Например, так может выглядеть скрам-доска в Atlassian — список задач с указанием исполнителя и срока исполнения и несколько столбцов со статусом задач:
Область применения scrum
Изначально scrum был разработан для сферы разработки программного обеспечения. Но постепенно фреймворк распространился и на другие области. Например, скрам используют в исследованиях, бизнесе, образовании, маркетинге. С начала 90-х гг. scrum активно применяют для таких целей, как:
Например, scrum можно применять для создания email-рассылки. Команда разработчиков будет включать маркетолога, копирайтера, редактора, дизайнера, верстальщика. Владельцем продукта может выступить email-маркетолог. При наличии необходимых знаний редактор может представлять scrum-мастера. Процесс создания рассылки можно поделить на несколько этапов (спринтов). Например:
Создание и запуск рассылки.
Доработка писем с учётом реакции аудитории.
Улучшение конверсии рассылки.
В конце каждого спринта будет готов полноценный продукт — рассылка, готовая к запуску. Но при этом письма дорабатывают: улучшают оформление текста, совершенствуют верстку email-письма, меняют содержание, добавляют или убирают различные элементы. И так до достижения конечной цели scrum-проекта — создания эффективной рассылки с высокими показателями конверсии.
Scrum применим в сферах, которые связаны со сложными продуктами, неопределённостью, стабильной изменчивостью.
Преимущественно scrum-фреймворки практикуют в разработке программного обеспечения. Однако принципы использования технологии удобно применять к командной работе любого направления. Это и обуславливает популярность scrum.