Agile и scrum отличия




Agile и Scrum разница

Agile и Scrum разница

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

Хронология

Официально Scrum получил свое название на конференции OOPSLA 95’, подробнее об истории возникновения написано в статье “Scrum History”, а самым первым в мире Скрам-мастером был Джефф МакКенна. В эти годы еще не было ни книг по Скрам ни какого-либо описания. Скрам был похож на набор правил, ограничений к этим правилам и разграничений по бизнес-направлению и процессному направлению. Agile же появился намного позже, а именно в 2001 году.

Определение

Agile это философия, которая была придумана в феврале 2001 года, группой энтузиастов, в количестве 17 человек, на горнолыжном курорте Snowbird. В их числе были, в основном, представители IT-сферы: Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Прагматического программирования и другие.

Snowbird стал отправной точкой появлению термина Agile в мире IT. Этим курорт объединил представителей разных ветвей IT, в результате которого появился манифест гибкой разработки — “Agile Manifesto”.

“Agile Manifesto” представляет собой 4 ценности и 12 принципов. Под этим документом подписался каждый из 17 Аджайлистов:

Как видите, на момент создания Agile речь шла только об IT направлении.
Но на сегодняшний день “Agile Manifesto” является компасом, по которому меряют свой бизнес многие компании, независимо от сферы деятельности.
Итак, давайте рассмотрим “Agile Manifesto”.

Ценности Agile

  1. Люди и взаимодействие важнее процессов и инструментов.
  2. Работающий продукт важнее исчерпывающей документации.
  3. Сотрудничество с заказчиком важнее согласования условий контракта.
  4. Готовность к изменениям важнее следования первоначальному плану.

После выхода этих ценностей в Agile сообществе зародилось много мифов и неправильных трактовок этих ценностей.

    Создатели манифеста ни в коем случае не говорили об:
  1. Отмене процессов;
  2. Отмене документации;
  3. Отмене контракта;
  4. Отмене планирования.

Из-за неправильной трактовки в Agile-сообществе появились люди, называемые ковбой-аджайл девелоперами. Об этом говорит Джефф МакКенна на каждом из своих тренингов и я.

Данные принципы несут лишь один смысл: не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Помимо ценностей “Agile Manifesto” содержит еще 12 принципов, которые более подробно описывают взаимодействие как внутри процесса разработки, так и снаружи.

12 принципов “Agile Manifesto”

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

Исходя из этих принципов можно сказать, что Agile говорит о том, к чему нужно стремиться командам и бизнесу в процессе работы, но не говорит как. В основном, “Agile Manifesto” является философским перевоплощением инструментария Scrum на тот период времени, за исключением 3 принципа. 3 принцип наглядно показывает насколько за 16 лет изменился темп бизнеса. Изменения в мире бизнеса происходят настолько быстро, что новая редакция Scrum Guide 2016 говорит только о верхнем ограничении итерации в 1 месяц и не называет нижнюю границу. (В следующих статьях я планирую сравнить разные версии Scrum Guide для наглядности).

После выхода в свет “Agile Manifesto” в 2001 году появилось много разных его интерпретаций — 1.0, 2.0, 3.0…., но стоит разъяснить, что есть только один официальный документ, который вы сможете найти по этой ссылке. Все остальные документы часто являются взглядами написавших их авторов сквозь призму их восприятия Agile и ограничивают глубину оригинальной философии.

Что же касается Scrum, то он не является философией. Если говорить языком терминов, то Скрам — процессный фреймворк созданный для разработки и поддержки сложных продуктов в сложных условиях. Слово «фреймворк» является понятным для IT. Одним из наиболее удачных терминов, описывающим слово «фреймворк», является «каркас», содержащий набор инструментов, представленных в виде встреч, артефактов, ролей, ценностей и правил взаимодействия.

На тренингах я часто показываю такую картинку, которая, по-моему, мнению наиболее целостно охватывает все составляющие Scrum:

Scrum и Agile

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

Содержание статьи

В классическом понимании, вопрос выбора – Agile или Scrum – не ставится, поскольку Agile – это подход к реализации проектов, для которых ещё нет готовых и ранее проверенных решений, которые не могут быть реализованы в рамках классического проектного подхода, а Scrum – это модель, позволяющая «гибкий» подход осуществить на практике. Точнее, Scrum – одна из нескольких возможных моделей, потому что подход Agile объединяет целое семейство «гибких» методов создания продуктов и моделей управления проектами. Тем более, неверно противопоставлять: Scrum vs Agile.

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

Эволюция идей

Scrum как подход к реализации проектов с помощью небольших эффективных команд, составленных из специалистов различного профиля, впервые был упомянут в 1986 году в статье И. Нонака и Х. Такэути. В 1991 году на подход сослались в своей книге Де Грейс и Шталь, взяв в качестве иллюстративного образа фигуру, которую образуют регбисты во время матча – скрам («схватка»).

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

В отличие от Scrum, «гибкий» маркетинг Agile как начинался в виде идейного-философского новаторства в процессах производства, так до сих пор в качестве философского подхода, в первую очередь, и рассматривается. В своём развитии подход Agile противостоял распространённому прежде каскадному подходу, когда второй этап процесса создания продукта начинался после завершения первого этапа, а третий – после завершения второго и т. д.. Всё это требовало долгосрочного планирования и затягивало реализацию проекта по нескольким причинам:

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

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

Результат эволюции

В основе идеи Agile лежал отказ от долгосрочного планирования в пользу динамичного формирования задач и возможности вносить изменения в любой момент, как только того потребует рынок в лице конечных потребителей или заказчиков продукта. Идея «гибкого» менеджмента на рубеже 20-21 веков стала настолько актуальной и востребованной, что пришло время оформить её в виде свода ценностей и принципов. А поскольку к 2001 году, помимо Scrum, существовало несколько трендовых моделей, у которых базовые установки в подходе совпадали, то представители этих трендов собрались в одном месте (на горнолыжном курорте в Юте) и выпустили Манифест Agile.

Подход Agile был актуален, в первую очередь, для быстро развивающейся IT-индустрии, поэтому для подписания Манифеста собрались именно разработчики ПО (в том числе – Кен Швабер и Джефф Сазерленд). Но и сама идеология Agile, и различные модели управления, которые были выстроены с учётом общих требований рынка, нашли своих последователей в самых разных областях бизнеса и в некоммерческих сферах.

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

Решалась проблема двумя способами:

  1. В качестве основной внедрялась та модель менеджмента из семейства Agile, которая в наибольшей степени соответствовала существующей системе отношений в компании.
  2. Поскольку базовые требования подхода Agile предполагали в принципе похожие решения, типичные для всего семейства Agile, в своих компаниях руководители ориентировались на них, а не на какой-то конкретный фреймворк. Эти типичные практические решения, ставшие логическим следствием «гибкого» подхода, начали называть методологией Agile, хоть сторонников канонической трактовки это и возмущает.

Таким образом, с определёнными оговорками, можно говорить об Agile-модели управления проектами, которая «взяла», в том числе, и некоторые структурные наработки Scrum-модели.

Scrum и Agile: цели и практические решения

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

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

Подобная логика приводит к созданию универсальной Agile-модели со следующими характеристиками:

  1. Вся работа над проектом разделяется на короткие этапы – итерации (в Scrum, например, такие этапы называются «спринтами»). За время одной итерации нужно успеть выпустить продукт, который можно тестировать и получать отклики от потребителей (технический модуль, приложение, локальную услугу – например, востребованность кофемашины в булочной и т. д.).
  2. Любые замечания или требования рынка фиксируются и входят в список требований на следующую итерацию. То есть, план составляется по ходу создания продукта. Подобные этапы цикличны и возобновляются до тех пор, пока не исчерпается список требований.
  3. Чтобы было удобно фиксировать требования рынка они, как правило, приводятся к единому формату (в Scrum – это «пользовательские истории») и размещаются на информационных площадках (досках).
  4. Чем эффективнее и достовернее каналы связи с потребителями, тем выше вероятность получения исчерпывающей информации. Множественные эксперименты дают более злободневные данные о продукте и о клиенте. Причём, каждая значимая поправка добавляет полезность, а, значит, и ценность конечному продукту. (За поддержание такой связи с заказчиком и создание ценности в Scrum отвечает специальный «персонаж» – т. н. «Владелец проекта»). А ориентированность на клиента – это ключевая ценность философии Agile.

Из сказанного следует, что в основе освоения и Agile и Scrum лежит способность коллектива перенять идеи и стиль Agile, а это при внедрении и готового фреймворка, и адаптированной Agile-модели вызывает главные проблемы. В Манифесте – 4 ценности, которые дополняются 12 принципами. Одна из ценностей – готовность к изменениям – допускает и требует в работе пересмотр плана. Но люди, привыкшие долгосрочно планировать свои действия, часто с трудом воспринимают резкие изменения направлений. А в «возрастных» коллективах внедрению «гибкого» управления мешают ещё и сложившиеся привычки.

PI-планирование и основные отличия SAFe от Scrum

Напомним, что SAFe – это фреймворк, который позволяет реализовывать agile-методологии в крупных командах разработки.

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

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

Для этого в SAFe используется инструмент PI-планирование — практика прямого общения команд, представителей бизнеса и других заинтересованных лиц, которые объединяются в одну команду.

Почему PI? Во время планирования команды создают план реализации инкремента продукта, Program Increment.

Как же проходит PI-планирование?

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

Результатом планирования должна стать доска программы (Program Board), на которой указано, какая команда, над какой юзер-стори и в каком спринте будет работать.

Там же указываются взаимосвязи между юзер-стори, чтобы все участники понимали и учитывали риски. Команды в SAFe берут на себя ответственность за реализацию не конкретных фич команды, а фич всего инкремента в целом. То есть если PI провален, то он провален для всех команд.

Длится каждый инкремент два с половиной месяца, или пять спринтов.

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

Организационные отличия SAFe от Scrum

Длительность

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

Участники

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

Этапы

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

PI-планирование включает в себя больше этапов, чем просто оценивание.

Вот расписание PI-планирования, которое проходило у нас. На его примере и расскажем об основных этапах мероприятия.

Начинается планирование с того, что руководство компании доносит бизнес-контекст предстоящего PI всей команде (Business Context).

Затем менеджер по продукту рассказывает, как будет реализовываться бизнес-контекст через функциональность (Product / Solution Vision).

Архитектор рассказывает, как будет развиваться наше приложение технически (Architecture Vision & Development Practices).

После этого владелец продукта (Product Owner) каждой команды в общих чертах презентует свой кусок требований, чтобы все команды имели представление, кто и какие фичи будет разрабатывать (Planning Requirements High Level Feature Overview). Так заканчивается первый день планирования.

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

Далее команды должны подтвердить готовность подписаться под этим планом, т. е. считают его выполнимым. Это процедура называется Confidence Vote. Проголосовать должен каждый участник, оценив план по шкале от 1 до 5.

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

Отличия в коммуникации

  • В SAFe существует понятие Scrum of Scrums — это митинг с участием Scrum-мастеров команд. Такие митинги проходят каждый час, пока команды оценивают свои стори. Задача SoS-митингов – синхронизироваться по статусу и обсудить зависимости между командами.
  • Поскольку команды у нас распределенные, то большая часть обсуждений ведется на английском языке.
  • Новый уровень визуализации. Если при работе по Scrum нам вполне хватало Jira, то в SAFe проблема визуализации общего плана стала остро. Ведь члены команды находятся на разных континентах, и возможности зайти в соседний кабинет и что-то обсудить лично нет. Мы пробовали разные подходы, но остановились на online-сервисе RealTimeBoard – виртуальные доски, на которых можно совместно работать с любым визуальным контентом.

Отличия в методах оценивания

  • Методы оценки также отличаются от методов, принятых в Scrum. Оцениваем мы не в часах, а в стори-поинтах. Это относительная оценка, которая показывает, насколько одна стори больше и сложнее другой.
  • На обдумывание оценки дается всего 2-3 минуты. Нужно это для того, чтобы команды не погружались в длинную дискуссию о деталях разработки, на данном этапе нужна всего лишь высокоуровневая оценка.
  • Если стори оценена больше чем на 8 поинтов, то ее следует разбить на несколько более мелких стори, т.к. команда скорее всего не успеет полностью завершить ее за один спринт, а это противоречит основным правилам SAFe. Ведь к концу спринта мы должны прийти с законченным ПО.
  • Самое интересное: теперь мы оцениваем не только свою работу, но и работу своих коллег. Каждый член команды должен оценить и разработку и тестирование и дать общую оценку. Это сложно, но дает лучшее понимание. Мы реже стали слышать вопрос: «Ну что там столько тестировать-то?»

Преимущества PI-планирования

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

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

Ну и, конечно, планирование стало хорошей возможностью попрактиковать свой английский. Ну чем не бонус?

Kanban vs Scrum vs Agile: сравнение и поиск отличий

Kanban

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

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

Доска разделена на три логические секции: «ожидание», «работа в процессе» и «завершенная работа». Но Kanban-доска может быть организована несколько иначе, в зависимости от конкретного проекта. Секции доски могут меняться: «ожидание», «работа в процессе», «численность команды», «проверка кода», «тестируется», «результат».

Любой рабочий элемент выглядит как Kanban-карточка (физическая или виртуальная), чтобы было нагляднее отслеживать работу.

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

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

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

Главные элементы помещаются в верхнюю часть списка «ожидание». Приоритет элементов можно изменить.

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

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

Scrum

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

Каждый спринт начинается с планирования, во время которого:

  • Выбирается бэклог продукта для определенного спринта.
  • Определяется масштаб и критерий завершенности элементов.
  • Элементы бэклога по необходимости могут разбиваться на части.
  • Составляется список требований.
  • Требования к функциональности упорядочиваются по степени важности.
  • На совещаниях присутствуют все участники команды.
  • Совещания, как правило, длятся не дольше 15 минут.
  • Участники команды отвечают на два вопроса: что было сделано после прошлой встречи, что будет сделано к следующей?
  • Обсуждаются блокировщики, слабые места и прочее вопросы.
  • В конце спринта проводятся т.н. ретроспективные совещания.
  • Демонстрируется готовая работа.

Анализируются два аспекта: успешные детали спринта и то, что планируется охватить за следующий спринт.

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

В скрам-методике участникам отводятся определенные роли. Их три: владелец продукта, скрам-мастер и команда разработки.

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

Скрам-мастер. Они занимаются планированием спринтов, проверками, ежедневными совещаниями и пр.

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

Kanban Vs Scrum

В описаниях этих методик немало общего. Но на практике отличий предостаточно.

Agile/Scrum для начинающих. Что такое гибкая методология?

Что такое Agile и Scrum?

Что такое Agile?

В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по «гибкой» разработке программного обеспечения.

Суть agile-подхода изложена в «манифесте», но для заказчика ее можно коротко сформулировать так:

  • разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;
  • в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;
  • команда разработки сотрудничает с Заказчиком в ходе всего проекта;
  • изменения в проекте приветствуются и быстро включаются в работу.

В настоящее время agile-принципы используются в работе десятки тысяч команд по всему миру.

Краткое видео о том, что такое Scrum (english).

Что такое Scrum?

Scrum — это одна из нескольких методологий гибкой разработки ПО:

    • Scrum
    • Lean
    • Feature Driving Development
    • Extreme Programming

Scrum процесс на одном листе

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

Артефакты в Scrum

В скрам используется всего четыре артефакта:

  • Product Backlog
  • Sprint Backlog
  • Sprint Goal
  • Sprint Burndown Chart.

Я рекомендую вам посетить наш тренинг «Scrum для проектных команд«. Тренинг помогает изучить Scrum-процесс от начала и до последних нюансов.

Product backlog:

  • Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
  • Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
  • Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
  • Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

На снимке ниже представлен Backlog проекта. Команда проекта выбрала 2 требования в Sprint#3.

Project Backlog (JIRA)

Sprint backlog:

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

Sprint Backlog — это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

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

Sprint Goal

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

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

Sprint Burndown Chart

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

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

Burndown диаграмма в Jira

Если есть время, посмотрите мою запись о книгах, которые можно скачать для изучения Agile/Scrum.

Роли в Scrum

В скрам используется всего три роли:

Роль Product Owner

  • формулирует требования
  • приоритезирует требования
  • корректирует приоритеты на каждом спринте
  • несет персональную ответственность за ценность требований для рынка/пользователей
  • отвечает за взаимодействие с рынком
  • только один человек

Product Owner — это представитель подразделения, которое владеет разрабатываемым продуктом. Например в банке это может быть Департамент карточных продуктов. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

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

В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них «главного», который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

Роль Scrum Master

  • следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
  • организует работу команды и обеспечивает её всем необходимым
  • защищает команду, несёт ответственность за её эффективность
  • только один человек.

Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет «администратор». Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

  • Скрам мастер не назначает людей на задачи — это делает сама команда;
  • Мастер не заставляет людей делать работу — это ответственность команды;
  • Мастер не указывает Product Owner какие требования он должен написать — это работа владельца продукта.

Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

Функции Scrum Master’a существенно шире, но чтобы пояснить их все нужна отдельная статья. Пишите в комментариях, если таковая нужна.

Team (команда проекта)

  • кросс-функциональная
  • взаимозаменяемая
  • самоорганизующаяся
  • с фиксированным составом (в ходе спринта)
  • 4-10 человек.

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

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

Команда НЕ принимает решений:

  • какие требования являются приоритетными — это делает Product Owner.

На снимке ниже команда проекта проводит обязательный «ритуал» — Daily Meeting (см. ниже).

Команда проводит «ритуал» Daily Meeting

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

Ритуалы (процессы в Scrum)

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

Ритуалы в скрам это:

  • Sprint Planning Meeting
  • Daily Meeting
  • Sprint Review
  • Retrospective

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

  • выполняется всей командой перед началом спринта
  • команда выбирает требования из Product Backlog и формирует Sprint Backlog
  • если требуется учесть взаимосвязи между операциями, то это делается здесь
  • команда декомпозирует требования на задачи (tasks)
  • каждая задача проходит оценку в трудозатратах или универсальных единицах
  • во время встречи Product Owner отвечает на вопросы команды.

Встреча, которая проводится перед началом каждого спринта. Структура встречи:

  • представление и пояснение Product Owner’ом списка требований
  • вопросы со стороны команды
  • /рекомендуется перерыв/
  • декомпозиция требований на задачи (tasks)
  • оценка задач по методу Planning Poker.

Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа. Крепитесь.

Daily Meeting (ежедневная встреча команды).

Из названия понятно, что встреча проводится ежедневно. Основные принципы:

  • проходит ежедневно и только в одно и то же время;
  • встреча проходит только стоя;
  • поэтому длительность встречи не более 15 минут;
  • чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

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

Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

Kanban Board во время спринта

Sprint Review — сдача спринта Product Owner

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

Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

  • команда зачитывает требования из Sprint Backlog
  • по каждому критерию приемки происходит демонстрация полученных результатов
  • каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
  • каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

На встрече могут присутствовать любые сотрудники организации или просто заинтересованные лица. Важно, чтобы право голоса имели только участники Scrum процесса (Produt Owner, Team, Scrum Master).

Никаких презентаций в PowerPoint на встрече, если вы правильно меня поняли!

Retrospective

Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

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

  • какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
  • какие проблемы мешают команде выполнять взятые на себя обязательства?
  • как улучшить взаимодействие с Product Owner’ом?
  • какие ошибки совершает команда и почему.

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

Почему появился Agile?

Теперь немного слов о том, как и зачем появился этот подход? История возникновения этого подхода стала ответом на запросы отрасли:

  1. Заказчик не может сформировать четкие требования к ПО;
  2. Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе;
  3. Заказчики и разработчики ПО не удовлетворены процессом взаимодействия.

#1 Заказчик не может сформировать четкие требования к ПО

В начальной фазе проекта заказчик не может сформулировать исчерпывающие требования к продукту. Этому есть несколько причин:

  • у Заказчика существует только идея приложения и он не представляет всю его функциональность;
  • у группы проекта есть разный взгляд на функциональность приложения;
  • команда не может договориться, как же будет удобнее/разумнее реализовать ту или иную часть функциональности приложения.

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

В традиционных «водопадных» моделях руководитель проекта минимизирует изменения в проекте, используя для этого отдельные процессы — управление изменениями. Но если требования будут меняться раз в месяц, то управление изменениями становится трудоемким и замедляет ход проекта.

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

#2 Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе

К середине 90-х разрабатываемое ПО было в основном десктопным и его требовалось устанавливать на каждый отдельный компьютер (например, MS Word). С появлением веб-приложений внедрение новой функциональности стало происходить быстрее: требовалось развернуть приложение только на сервере и все пользователи получали к нему доступ. Эта инновация серьезно усилила конкуренцию между компаниями: тот, кто применил новую технологию раньше других – выигрывает рынок и клиентов.

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

#3 Заказчики и разработчики не удовлетворены процессом взаимодействия

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

Основная идея agile – сотрудничество с заказчиком важнее, чем контрактные обязательства. И поэтому agile-методы стремятся к уменьшению объема документации. Это позволяет Заказчику платить только за результат, имеющий ценность для бизнеса.

При этом agile не отказывается от формулирования требований. Заказчик (в agile — владелец продукта, product owner) предъявляет требования в упрощенном виде и на сценариях работы пользователей.

Резюме

Agile-философия проста. Agile-принципы разумны. Но переход к реальному применению agile — это серьезный вызов для каждой команды. Требуется не только освоить новый подход к управлению проектами, но также подобрать людей, способных работать в agile режиме.