Скрам, что это такое?

Скрам, что это такое?

В начале 2017 года наша команда по созданию контента (в ту пору состоявшая из трех человек) столкнулась с довольно крупной проблемой. Поскольку через наши руки проходят все англоязычные тексты, которые выкладываются в общий доступ, нас несколько ошарашил поток запросов от 400 с лишним сотрудников, которые просили нас написать и отредактировать тексты рассылок для клиентов, советы по инструментарию интерфейсов, содержимое целевых страниц, материалы для поддержки продаж и даже описания вакансий! У нас почти не оставалось времени на создание собственного маркетингового контента, ради которого нас изначально брали на работу. У нас не было возможности нанять дополнительных сотрудников, поэтому единственной возможностью было переосмыслить формат нашей работы, чтобы справиться с неконтролируемым наплывом запросов. Говоря точнее, мы решили использовать скрам.

Как скрам помогает справиться с хаосом

Мы уже писали о скраме. Это методика командной работы, где применяются принципы из «Agile-манифеста разработки программного обеспечения», составленного разработчиками софта в далеком 2001 году.

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

Маркус Миллер, основатель британского агентства цифрового маркетинга Bowler Hat, рассказывает: «Удачно поработав в скрам, я решил применить те же приемы при ремонте купленного нами дома. Я живу в Британии, так что речь идет о викторианском трехэтажном особняке. Его не ремонтировали 30 лет. В нем не было отопления. То есть, делать нужно было все — от проводки до отопления и отделки. Скрам помог нам выполнить этот проект и сохранил мне рассудок. Это очень гибкий инструмент, который прекрасно работает и вне сферы разработки программного обеспечения. Что вообще-то логично, ведь сама идея бережливой разработки изначально строилась на принципах производства».

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

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

Составные элементы скрама

В сухом остатке для использования этого метода требуются три стороны:

  • Владелец продукта, который располагает информацией об объеме работы и очереди задач (бэклоге), а также может ответить на все вопросы
  • Скрам-мастер, который проводит совещания-летучки и ищет самые эффективные способы выполнить работу
  • Участники команды, обычно многопрофильные специалисты, от которых требуется сделать многое за небольшое время

Для скрам-процесса необходимы:

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

Как сделать скрам-процесс успешным?

О чем следует помнить, когда только начинаете использовать эту методику?

Определите приоритеты в очереди задач

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

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

Сет Мессер, старший разработчик компании Vecteezy, объясняет, почему этот процесс так важен для определения пути к поставленной цели: «У разработчиков есть ограничение по времени (то есть мы должны сделать ту или иную задачу в поставленных временных рамках). Это означает, что мы знаем, что нам нужно сделать, и хотим, чтобы это было сделано к определенному моменту. К примеру, к февралю 2018 года нам нужна новая версия сайта. Начать работу — дело несложное, и мы знаем, что должны получить на выходе (например, новый сайт), но все, что лежит между этими двумя точками, покрыто мраком. Какую именно работу нужно выполнить и в какой момент?»

Летучки должны быть краткими и действенными

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

Гэвин Вудс, сертифицированный скрам-мастер из SCRUM Alliance, руководит проектами по цифровой трансформации для клиентов компании PITSS из различных отраслей. Он признает, что проводить летучки придется учиться. «Честно говоря, — говорит, он, — в некоторых компаниях внедрение скрама может очень сильно изменить привычные подходы к работе. Людям приходится больше рассказывать о том, что они делают и с какими трудностями сталкиваются, и решать проблемы сообща. Не каждому это дается легко».

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

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

  • Чего я добился?
  • Чем я занят в настоящий момент?
  • С чем я испытываю затруднения? / В чем мне нужна помощь?

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

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

Записывайте сделанные выводы

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

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

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

«Важно не нарушить баланс между тем, что не удалось, и тем, что прошло гладко, — говорит Вудс. — Позитивный настрой способствует творчеству».

Вы внедрили скрам. Что дальше?

Когда мы внедрили скрам-процесс, наша команда по созданию контента очень быстро сделала три открытия:

  1. Мы быстро справлялись с очередью задач по созданию контента.
  2. Нам стало проще справляться с неожиданными запросами, потому что мы знали, когда и у кого будет время, чтобы ими заняться.
  3. Мы стали намного лучше работать в команде и поддерживать друг друга, так что нам стало проще выполнять задачи.

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

Сотрудники канадского стартапа Procurify, занимающегося закупками программного обеспечения, обнаружили, что им удается сэкономить 70% времени, планируя спринты в Wrike. Теперь участник команды знает, чем заняты остальные, и может сотрудничать с коллегами из других команд. «С помощью единого центрального инструмента для управления всем процессом, — говорит Юджин Донг, сооснователь и технический директор Procurify, — мы можем наблюдать за работой сотрудников и проверять, насколько это совпадает с целями компании».

Компания Tactus занимается разработкой инновационных сенсорных экранов с уникальными выпуклыми кнопками, которые могут появляться на экране и исчезать по мере необходимости. Но по мере роста темпов производства сотрудники начали испытывать проблемы с обменом информацией. Применив Wrike для реализации скрам-процессов, они смогли сократить свои спринты на 80% — с целой недели до одного дня. «Теперь не приходится ждать следующего совещания, чтобы оповестить коллег об обновлениях. Так нам намного проще сообща работать в промежутках между плановыми совещаниями», — говорит Кертис Рэй, вице-президент отдела разработки Tactus.

Для всех скрам-мастеров у нас есть отличный доклад Натальи Антиповой, скрам-мастера Wrike. Цель доклада — дать практические инструменты, с помощью которых можно избежать ряда насущных проблем в работе скрам-мастера и команд. Мы разберем на примерах, в каких случаях эти инструменты работают, а в каких — нет, и как они помогают в повседневной жизни скрам команды.

Прощальное напутствие новичкам

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

Вот что сказал нам напоследок Гэвин Вудс: «Скрам нельзя внедрить одномоментно. Если вы прошли курс обучения и стали сертифицированным скрам-мастером, первое, что вы поймете, — это что скрам-процесс невозможно наладить за один день. Любой элемент — от процесса до базовых принципов — может потребовать не только практики, но иногда и полного изменения подходов к работе в вашей компании».

Вам может быть интересно:

Прочитайте еще несколько рекомендаций о том, как использовать Agile-методологии в своей команде:

  • Пошаговое руководство по настройке agile-методологии в Wrike
  • Как Agile-методологии помогают маркетологам решать важнейшие задачи

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

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

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

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

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

Скрам выделяет отдельную роль, которая управляет ценностью, — Product Owner, или владелец продукта. Именно он определяет, какую ценность мы создадим в текущем спринте, а какую отложим на следующий. Таким образом владелец продукта отвечает за максимизацию ценности для заказчика. «Что мы можем сделать в следующем спринте, чтобы это было максимально ценно/полезно?» Над этим вопросом владелец продукта должен думать каждый день, готовясь к следующему спринту.

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

Структура спринта

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

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

Цель встречи — определить цель спринта и составить Sprint Backlog (спринт бэклог). Обязательно присутствие всей скрам-команды и владельца продукта. Владелец продукта рассказывает команде о цели спринта, отвечает на вопросы команды. Команда обсуждает реализацию, выясняет важные детали у владельца продукта, составляет перечень задач, выполнив которые команда достигнет поставленной цели. В конце встречи все одинаково понимают цель спринта, и в команде сформировано общее понимание, как и что нужно сделать для достижения поставленной цели. Рекомендуемая длительность встречи — не более 4 часов для 2-недельного спринта.

Ежедневный скрам-митинг

Ежедневные встречи — это способ координировать усилия членов скрам-команды, оперативно выявлять проблемы, создавать прозрачность текущей ситуации. Команда собирается у доски задач, и каждый участник скрам-команды по очереди отвечает на 3 вопроса: Что я сделал вчера? Что сделаю сегодня? Что меня тормозит и мешает двигаться вперед? Время жестко ограничено — не более 15 минут, поэтому на этой встрече команда только выявляет проблемы. Поиск решения выносится за рамки этой встречи.

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

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

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

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

Целостность Скрам

Скрам — это идеально сбалансированный инструмент. В нем нет ничего лишнего, и каждый элемент имеет свою ценность и предназначение. Именно целостное применение Скрама дает максимальный синергетический эффект. Если убрать какой-либо элемент — баланс нарушится, что негативно скажется на результатах. Однако на практике приходится встречаться с искалеченным Скрамом, когда некоторые элементы не используются. Такой искалеченный Скрам даже получил собственное наименование — ScrumBut, или по-русски СкрамНо. Почему же так происходит? Казалось бы, все очень просто — бери и делай. Да, берут, делают, но потом какие-то элементы отменяют, так как они не приносят пользы. Люди всегда стремятся избавляться от того, что не приносит ценности, и это проявление мудрости. Проблема не в том, что элемент плохой. Проблема в том, что он используется неправильно. И даже эта проблема предусмотрена в Скрам.

Скрам-мастер

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

Обучение скрам-мастеров

На основе многолетнего опыта работы со скрам-командами мы разработали тренинг Advanced Scrum Master. Посещение этого тренинга — это низкий старт для начинающего скрам-мастера и прокачка навыков для практикующего.

Если вы в поисках программы обучения Agile и Scrum для более широкого круга сотрудников, то вам идеально подойдет наш основной курс — Certified Agile Professional. Типичный состав участников этого тренинга: директора, HR, менеджеры проектов, руководители подразделений.

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

Что такое Agile?

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

Agile Manifest

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

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

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

Основополагающие принципы 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
  • Scrum Master
  • Team.

Роль 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 режиме.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *