Будь гибким: как понять Scrum и создать agile-команду
Scrum — методология гибкого процесса разработки программного обеспечения. Сейчас этот метод управления популярен и активно применяется.
Прежде чем разобраться, что такое Scrum и как внедрить эту методологию, давайте посмотрим на предпосылки её возникновения.
Как и зачем появилась Scrum-методология
До появления Scrum в мире разработки программного обеспечения было принято использовать «водопадный подход». Работа над продуктом велась по следующему плану.
Разработчики согласовывали план работы с заказчиком и чётко следовали техническому заданию. Когда продукт был готов, его тестировали, но уже не было возможности что-то поменять. Поэтому, если выявлялись ошибки, приходилось начинать всё сначала, а сроки работы увеличивались.
Так было, пока группа новаторов не решила изменить ситуацию полностью. Они наблюдали за тем, как работают успешные команды: не срывая сроки и получая именно тот результат, который планировали. Оказалось, что успех обеспечивала гибкость процесса.
Выводы, которые были сделаны, помогли создать «Манифест гибкой разработки программного обеспечения». В него вошли всего четыре пункта, но они полностью изменили процесс.
Манифест гибкой разработки ПО
1. Люди важнее инструментов.
2. Качество продукта важнее документации.
3. Взаимодействие с заказчиком важнее контракта.
4. Готовность к изменениям важнее установленного плана.
Эти четыре пункта стали основой для появления Agile, гибкого процесса разработки программного обеспечения. Позже были созданы 12 принципов, которые и сейчас используются в любой Agile-методологии.
12 принципов Agile
1. Главное — хорошее ПО и довольный заказчик.
2. Готовность к изменениям в любой момент.
3. Полностью рабочее ПО — как можно чаще.
4. Встреча команды — лучше всего для обмена информацией.
5. Заказчик и команда разработки должны работать вместе.
6. Доверять людям делать свою работу.
7. Есть рабочее ПО — есть прогресс.
8. Гибкие процессы — непрерывное развитие.
9. Внимание к качеству способствует гибкости.
10. Простота процесса позволяет не делать лишней работы.
11. Самоорганизующаяся команда лучше работает.
12. Постоянное стремление к большей эффективности.
Одна из методологий гибкого процесса разработки программного обеспечения, которая базируется на agile-принципах, — Scrum.
Создатели Scrum Джефф Сазерленд и Кен Швабер долгие годы наблюдали за работой американских военных, спецназовцев и даже регбистов. И заметили, что их успех основан на взаимодействии и командной работе. Сазерленд и Швабер поняли, что этого как раз и не хватает разработчикам программного обеспечения. Так появилась методология Scrum.
Принципы Scrum
Scrum всегда ориентируется на клиента, который должен получить желаемый продукт вовремя и с минимальными затратами. Этого можно достичь при соблюдении нескольких обязательных принципов.
Работа короткими циклами (спринтами)
Планируйте один спринт, а не весь проект сразу. Каждый спринт — период, в который команда работает над полностью законченной частью продукта.
Гибкость. «Проверять и адаптироваться»
Гибкость процесса и тестирование продукта после каждого спринта. Если что-то идёт не так, команда всегда готова сменить стратегию разработки или пересмотреть бэклог продукта.
Участие заказчика и пользователей в создании продукта
Заказчик не стоит в стороне, а полностью задействован в работе. Для этого существует роль владельца продукта, которую выполняет сам заказчик или его представитель. Именно через него команда взаимодействует с пользователями. Так как разработка ведётся короткими этапами, пользователи подключаются к тестированию почти сразу.
После первичного тестирования им открывают доступ к продукту, а владелец продукта собирает обратную связь. Так команда может совершенствовать результат.
Scrum-команда — это несколько человек, которые работают на один результат и как единое целое. Каждый стремится к общей цели.
О важности scrum-команды
Scrum-команда — это чаще всего группа из пяти-девяти человек. Это оптимальное количество, но иногда встречаются команды и из трёх человек. Если людей больше, то им становится сложнее взаимодействовать между собой, что мешает работе и снижает продуктивность.
Состав команды
Принципы работы scrum-команды
Чтобы работать по методологии Scrum, команда разработчиков должна соблюдать три основных принципа.
Совершенствование продукта за счёт самосовершенствования сотрудника.
Каждый член команды отвечает за свою часть работы и за общий результат.
Каждая команда самодостаточна, так как в ней собраны люди с разными навыками.
Процесс работы scrum-команды
Процесс работы scrum-команды проходит в несколько обязательных этапов.
Каждый спринт начинается с планирования. Scrum-мастер, владелец продукта и остальные члены команды вместе смотрят на бэклог продукта и выбирают направления, по которым будут работать в данном цикле. Так получается бэклог спринта, то есть список задач на этот период.
Дальше команда оценивает объём работ, оговаривает длительность спринта, в конце которого должен появиться результат, то есть готовый продукт.
Каждый день вся команда проводит короткую встречу, не более 15 минут. Scrum-мастер и владелец продукта тоже участвуют. Суть встречи — получить от каждого члена команды ответ на три вопроса:
Задача scrum-мастера — понять, если что-то идёт не так, и помочь команде справиться с трудностями.
Scrum-команда вешает в помещении для совещаний доску с разноцветными стикерами. Она делится на части, где отражается весь процесс работы над проектом. Тут могут быть варианты, но обязательно присутствуют три части. Первая — «Что нужно сделать», вторая — «В работе», третья — «Сделано». Этот простой способ помогает всем членам команды следить за общим ходом работы.
Если кто-то из членов команды понимает, что не укладывается в спринт, он сообщает владельцу продукта, а тот распределяет время иначе. То же самое происходит, если команда понимает, что справится с задачей досрочно, — тогда можно добавить дополнительных задач из бэклога продукта.
Когда задачи спринта выполнены, команда должна продемонстрировать полностью работающую демоверсию той части ПО, над которой велась работа в спринте.
Как внедрить scrum-методологию
Сейчас методология Scrum находится на пике популярности. Вопрос о её пользе уже почти не звучит. Но как внедрить Scrum правильно, чтобы заметно улучшить ситуацию с продуктивностью и качеством итогового продукта?
Кажется, что всё просто. Нужны несколько последовательных действий.
Это первый и основной шаг. Именно от слаженной работы команды зависит качество будущего продукта. Но не так легко собрать кросс-функциональную команду.
2. Назначить владельца продукта
Это может быть заказчик или его представитель. Владелец продукта будет отвечать за взаимодействие с заказчиком и работать с пользователями на всех этапах разработки.
3. Выбрать scrum-мастера
Scrum-мастер — важная часть команды. От него зависит, насколько комфортно всем участникам процесса будет работать. Тут нужен опытный scrum-мастер, который хорошо знаком с методологией не только в теории.
4. Создать список требований к продукту
Прежде чем начать разработку, стоит подумать над списком требований и согласовать их. Получится своего рода техническое задание, которое будет направлять работу.
5. Спланировать спринт
Разделить всю работу на периоды. Планировать каждый спринт. Не весь процесс разработки сразу, а только ближайший цикл.
6. Постоянно анализировать и оценивать результат
Подводить итоги после каждого спринта и оценивать результат. Переходить к следующему спринту, только если довольны результатом предыдущего.
Вот они — шесть шагов, которые ведут к увеличению продуктивности разработчиков, сокращению сроков работы и качественному программному обеспечению. Но так ли это просто, как кажется на первый взгляд? Как понять, успешно ли внедрён Scrum, и сделать так, чтобы не испортить показатели ещё больше?
Сейчас много scrum-теоретиков, которые плохо понимают, как работать с реальным продуктом. Поэтому важно учиться только у тех, кто знает, что такое Scrum, на практике, разбирается во всех тонкостях не только методологии, но и её внедрения в конкретную область. Ведь этот процесс сильно зависит от продукта, который вы собираетесь создавать с помощью Scrum.
Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.
Упорядоченный список задач, над которыми scrum-команда работает при создании продукта.
Спринты
Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы.
Просмотр тем
Что такое спринты?
Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы. Спринты лежат в основе методологий scrum и agile, и правильный выбор спринтов поможет вашей agile‑команде выпускать более качественное программное обеспечение без лишней головной боли.
«При использовании scrum продукт разрабатывается в ходе нескольких итераций с фиксированной продолжительностью, которые называются спринтами и разбивают большие сложные проекты на небольшие задачи», — говорит Меган Кук, менеджер группы товаров для Jira Software в Atlassian.
Многие ассоциируют Scrum-спринты с Agile-разработкой программного обеспечения настолько часто, что Scrum и Agile принимают за синонимы. Однако это не так. Agile — это набор принципов, а Scrum — методика для активного решения задач.
Многочисленные сходства между глобальными задачами agile и процессами scrum вполне справедливо приводят к тому, что эти два понятия ассоциируются друг с другом. Благодаря спринтам команды могут следовать agile‑принципу «частой поставки рабочего программного обеспечения», а также реализовать agile‑задачу «реагирования на изменения в соответствии с планом». Установки scrum — прозрачность, проверка и адаптация — дополняют agile‑методику и играют главную роль в концепции спринтов.
Руководство по Scrum закладывает прочную теоретическую основу для обсуждения спринтов. Мы хотим внести немного красок в эту тему и делимся рекомендациями от людей, которые занимаются этой работой каждый день.
Как планировать и выполнять спринты в scrum
Авторы Scrum действительно все предусмотрели. Чтобы запланировать предстоящий спринт, нужно провести собрание по планированию спринта. Планирование спринта — это мероприятие, на котором команда сообща отвечает на два основных вопроса: какую работу можно выполнить в этом спринте и как она будет выполняться?
Выбором подходящих рабочих задач для спринта занимаются совместно владелец продукта, Scrum-мастер и команда разработчиков. Владелец продукта определяет цель спринта и задачи из бэклога продукта, при выполнении которых она будет достигнута.
Затем команда создает план, согласно которому будут выполняться задачи бэклога, чтобы к окончанию спринта вся работа была завершена. Выбранные рабочие задачи и план по их выполнению называется бэклогом спринта. К концу совещания по планированию спринта команда готова приступить к работе. Для этого необходимо просто выбирать задачи из бэклога спринта и менять их статус с «В работе» на «Готово» по мере завершения работы.
В течение спринта команда собирается на ежедневные Scrum‑совещания (стендапы), чтобы обсудить ход работы. Такие совещания нужны, чтобы выявить блокеры и проблемы, которые могут повлиять на достижение цели спринта.
По окончании спринта команда показывает выполненную работу на обзоре итогов спринта. Здесь можно продемонстрировать итоги работы заинтересованным сторонам и другим участникам команды до того, как они попадут в рабочую среду.
Завершите цикл спринтов на моем любимом собрании — ретроспективе спринта. Здесь команда может определить области, требующие улучшения в следующем спринте. С этими сведениями можно начинать следующий цикл спринта. Вперед!
Что стоит и не стоит делать
Даже если основы уже известны, большинство команд спотыкается в начале работы со спринтами. Меган Кук завершает эту дискуссию списком действий, которые стоит и не стоит делать при использовании спринтов, которые она сформулировала за годы своей работы.
И если уж вы работаете над тем, чтобы стать сильным специалистом по scrum, выполняя рекомендации, ознакомьтесь также с действиями, которые выполнять не следует.
Чего не стоит делать.
Оптимизируйте спринты с помощью автоматизации
Когда вы поймете, как работают спринты, вы сможете оптимизировать процессы, используя автоматизацию. Вот три правила автоматизации, которые часто используются в спринтах Jira.
Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation.
Подробнее о спринтах
Спринты настолько известны (и настолько эффективны), что их часто считают первым шагом на пути к повышению гибкости. Но мы выяснили, что для освоения спринтов необходимо овладеть некоторыми взаимосвязанными понятиями Scrum и Agile. Изучите остальные статьи по Scrum, чтобы расширить знания и стать еще на шаг ближе к счастью от использования Scrum.
Что такое спринты в программировании
Это время, за которое команда успевает решить какую-то часть задач.
Когда вы попадёте на работу в ИТ-компанию, вы обязательно услышите одну из этих фраз:
Разберём, что это за спринты такие и зачем они нужны.
Ситуация
У команды разработчиков есть большой проект, где нужно сделать много разных вещей:
Времени на всё — 6 месяцев, и кажется, что этого достаточно. Но это может быть обманчиво, потому что команда расслабляется, каждый начинает делать что-то своё, а за месяц до финала выясняется, что вместе эти отдельные части работать не будут. Например, сервер не отдаёт данные в нужном формате для веб-страницы, приложения хранят данные только у себя и не умеют отправлять их на сервер, а авторизация в соцсетях работает только на Андроиде.
Чтобы этого не произошло, используют спринты.
Что такое спринт
Спринт — это небольшой фиксированный отрезок времени, в который команда делает какую-то ограниченную часть проекта. Например, команда может двигаться двухнедельными спринтами, с каждым спринтом добавляя в проект новые возможности.
Задача спринта — чтобы по его итогу что-то работало. Например, если мы взяли в спринт единую авторизацию в сервисе, то к концу спринта она должна работать и быть протестированной. Нельзя к концу спринта сказать «Ой, ну ничего, в следующий раз доделаем». К концу спринта должно быть готово.
Что делают в спринте
Цели у спринта могут быть общими для всей команды. Например:
А могут быть для каждого свои:
Кто именно и что делает — это определяет кто-то из руководителей, например, тимлид или менеджер проекта. У него в голове цельная картинка проекта, которую он раскладывает на конкретные маленькие шаги. Менеджер отвечает за корректную постановку задач, а разработчик — за то, чтобы эта задача была выполнена в срок.
Что после спринта
После спринта проводят ретроспективу — это встреча, на которой команда сама оценивает свой результат. Например, они могут обсудить такое:
Цель ретроспективы — подвести итоги спринта и понять, как лучше строить работу в следующем спринте, чтобы всё получалось лучше и интереснее, чем в этом.
После ретроспективы всё по новой.
Где нужны спринты
Спринты применяют для сложных или долгих проектов — там, где на старте непонятно, что конкретно по шагам нужно сделать, чтобы получить результат. Если проект сложный, спринты помогают упростить его, разбивая задачи на более понятные, чтобы каждая задача занимала один спринт.
В долгих проектах спринты держат в тонусе всю команду и не дают расслабляться в самом начале, когда кажется, что времени ещё очень много. Тогда цель каждого спринта — планомерно улучшать то, что есть, и постепенно добавлять новые возможности в сервис или приложение.
Если же задача решается за пару дней или пару недель, то спринты не нужны — нужно просто собраться и сделать.
Все знают, что компьютеры состоят из единиц и нулей. Но что это значит на самом деле?
Если ты можешь сделать страницу о себе, ты можешь сделать всё.
Одно делается для удобства, а другое — для защиты.
Это когда сначала всё делают для смартфона, а потом для всего остального.
Это когда старая игра запускается на новой приставке
Чтобы держать всё перед глазами и не отвлекаться на переключения между окнами.
С чего начать, на что не тратить время, кому уже поздно.
Как перейти от программирования к управлению.
Мини-справочник и руководство по 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-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?