Scrum методология: современные задачи и решения

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

Начнем с терминологии, а далее подробнее обсудим саму суть процессов и особенности их реализации.

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

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

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

Вся суть подхода содержится в «манифесте», но заказчику ее можно озвучить следующим образом:

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

Сегодня десятки тысяч команд со всего мира применяют в своей работе agile-принципы.

Какие проблемы решает методология гибкой разработки Scrum

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

  • Заказчик не может сформировать четкие требования к продукту

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

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

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

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

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

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

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

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

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

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

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

Но важно отметить, что методология разработки Scrum Agile не отказывается от формулирования требований. Заказчик (в Agile он именуется владельцем продукта, Product Owner) выставляет их в упрощенном виде, основываясь на сценариях работы пользователей.

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

  • Развитие бизнеса: 9 оригинальных идей
  • l>

    Чем характеризуется методология Scrum

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

    Scrum методология: современные задачи и решения

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

    Недостатки традиционного подхода к управлению проектами

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

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

    Scrum методология: современные задачи и решения

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

    Планы не работают, работает Scrum

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

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

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

    Философия Scrum

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

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

    Командная работа

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

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

    Помимо этого, автор предлагает вспомнить «закон Брукса»: «Если проект не получается завершить в срок, дополнительная рабочая сила помешает ему еще сильнее».

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

    Scrum методология: современные задачи и решения

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

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

    Минимизация рисков в Scrum

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

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

    Нет мультизадачности

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

    Никаких переработок

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

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

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

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

    Поток

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

    Мнение эксперта

    Необходимо решить, какие совещания, для чего и как часто будут проводиться

    Марина Корсакова,
    руководитель департамента мероприятий в России, «Пять звезд»

    Частота проведения собраний зависит от их типа, целей и сферы, в которой работает организация. Так, ведущим проект разработчикам ПО необходим ежедневный scrum-meeting, тогда как сотрудникам коммерческого отдела будет достаточно встреч по вторникам и четвергам.

    Scrum-meeting — ежедневное жестко структурированное краткое 15-минутное собрание команды, это пульс проекта.

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

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

    Scrum методология: современные задачи и решения

    Как внедряется Scrum методология управления проектами

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

  1. В первую очередь выбираем «Владельца продукта», то есть лицо, у которого есть сложившееся представление относительно того, что вы собираетесь делать.
  2. Теперь собираем «Команду»; сюда будут включены люди, непосредственно выполняющие работу. У них должны быть все навыки и знания, необходимые для воплощения идеи заказчика.
  3. Выбираем «скрам-мастера», то есть человека, который будет отслеживать ход реализации задумки, обеспечивать проведение небольших собраний, содействовать команде при устранении проблем в процессе работы.
  4. Составляем как можно более полный перечень всех требований (или «Бэклог продукта»), предъявляемых к продукту или цели, приступая к работе. Пункты лучше расставить по степени важности. Такой перечень не является окончательным, в соответствии со ей он может расти и претерпевать изменения в течение всего проекта.
  5. Далее участвующие в проекте проводят оценку каждого пункта на предмет сложности и затрат, необходимых при его реализации.
  6. После этого участники, скрам-мастер, заказчик должны провести первое скрам-собрание, чтобы запланировать спринт, иначе говоря, выделить отрезок времени на выполнение блока заданий. Отметим, что он не может продолжаться более месяца. Выполняя каждый спринт, команда получает конкретное количество баллов. Поэтому ей важно непрерывно стараться в новом спринте превзойти результат предыдущего. Получается, ви мы ставим цель — постоянно улучшать свои показатели, «наращивать динамику производительности».
  7. Заводим скрам-доску, чтобы все лица, участвующие в проекте, всегда были в курсе происходящего. На доске выделяем три колонки: «Нужно сделать (Бэклог)»; «В работе»; «Сделано». Сюда группа клеит стикеры с заданиями – в процессе работы они постепенно уходят из «Бэклога» в раздел «В работе» и в итоге остаются в «Сделано».
  8. Каждый день организуем скрам-собрание. Как говорит автор методологии, «это пульс всего процесса Scrum». Смысл этого мероприятия таков: на ходу, в течение 15 минут все должны ответить три вопроса: «Что ты делал вчера, чтобы приблизить команду к концу спринта?», «Что ты будешь для этого делать сегодня?», «С какими проблемами сталкивается команда?»
  9. Как только спринт завершен, команда проводит его обзор. Для этого организуется встреча, где все участники рассказывают, что удалось выполнить за время спринта.
  10. Далее группа проводит ретроспективное собрание, чтобы обсудить, что было сделано хорошо, что стоит в следующий раз улучшить и что можно исправить уже сейчас.

Давайте более подробно разберем описанную схему и обсудим все элементы Scrum методологии.

Из каких артефактов состоит Scrum методология

В Scrum применяют лишь 4 артефакта.

Product backlog

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

Снимок, приведенный далее, демонстрирует пример Backlog’а. Группа участников поставила себе две задачи на Sprint#3.

Scrum методология: современные задачи и решения

Sprint backlog

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

Просто представьте, что вы готовите пожелание пользователя Amazon.com. Пробный вариант может быть таким: «Мне, потребителю, нужен самый большой в мире магазин, где я в любое время смогу найти любую книгу».

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

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

Это грамотно подготовленные пожелания пользователя, которые нужно учитывать группе.

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

Sprint Backlog — это обязательства группы участников в Scrum методологии – то, что им необходимо сделать за предстоящие 2 недели. Каждое требование включает в себя более конкретные задачи, они выставлены на Kanban-доске.

Sprint Goal

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

Sprint Burndown Chart

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

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

Scrum методология: современные задачи и решения

Как распределяются роли в Scrum методологии

Scrum предполагает только 3 роли.

  • Роль Product Owner

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

Product Owner:

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

Чаще всего Product Owner является представителем компании — владельца разрабатываемого продукта. Так, в банке эту роль играет Департамент карточных продуктов. Правильно подобрать Product Owner’a не так легко, поскольку данная роль требует от человека совмещения в себе некоторых особенностей:

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

Встречаются ситуации, когда Scrum методология допускает назначение более одного человека в качестве Product Owner’а. Правда, тогда требуется выбрать «главного», чтобы он авторизовал требования в Backlog’e и лично расставлял приоритеты.

  • Scrum Master

Это «служащий лидер» (servant-leader). Он должен помочь максимально поднять результативность работы команды, устраняя препятствия, помогая, обучая, мотивируя, оказывая помощь PO. Таким образом, этот человек должен:

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

Такая роль очень сложна. В традиционном project management существует руководитель проекта, тогда как Scrum методология такой роли не предусматривает. Пожалуй, самым подходящим синонимом для Scrum Master’а является «администратор». Этот человек организует работу, но сам в нее не вмешивается:

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

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

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

Команда разработки (Development team, DT) включает в себя людей, непосредственно осуществляющих проект. В соответствии с The Scrum Guide (официальное описание Scrum, предложенное его авторами) DT необходимы такие качества, как:

  • способность самоорганизовываться. Никто (в том числе SM и PO) не имеет права говорить проектной группе, как от Product Backlog перейти к полноценному продукту;
  • многофункциональность, то есть наличие всех навыков, требуемых для создания продукта;
  • неизменный состав на протяжении всего проекта;
  • ответственность всех членов проекта.

Оптимальное число участников для Scrum методологии — 7 (плюс-минус 2). По мнению создателей, чрезмерно большие группы участников затрачивают неоправданно большие ресурсы на коммуникацию, тогда как меньшие группы увеличивают риски (по причине возможного недостаточного количества некоторых умений), снижают объем работы, выполняемой за единицу времени.

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

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

Команда НЕ способна сама решать, какие требования могут относиться к наиболее важным, поскольку эту задачу в Scrum методологии выполняет Product Owner.

Приведенное ниже фото показывает группу разработки на обязательном Daily Meeting.

Scrum методология: современные задачи и решения

Как происходит работа по Scrum методологии

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

В Scrum методологии существуют следующие ритуалы:

  • Sprint Planning Meeting;
  • Daily Meeting;
  • Sprint Review;
  • Retrospective.

Базой для Scrum, как мы уже говорили, является Sprint, в течение которого идет развитие проекта. Как только Sprint завершен, должна быть готова новая версия продукта. Спринт ограничивается временными рамками (1–4 недели), обладая одной фиксированной продолжительностью на всех этапах создания продукта.

Каждый Sprint в соответствии со Scrum методологией начинается со Sprint Planning. Здесь оценивается содержимое Product Backlog, формируется Sprint Backlog, содержащий задачи (Story, Bugs, Tasks) на текущий спринт. У любого спринта должна быть сформулированная цель – она становится мотивацией для участников и достигается посредством выполнения Sprint Backlog.

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

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

Как мы уже говорили, в начале спринта для большей наглядности по Scrum методологии заводят специальную доску с тремя колонками: «Бэклог»; «В работе»; «Сделано». Перед каждым спринтом участники группы заполняют часть «Бэклог» стикерами с задачами, которые, по их мнению, достижимы за этот этап. Пока идет спринт, любой член команды, работающий над задачей, переносит листок из «Бэклога» в раздел «В работе», когда задача выполнена — в блок «Сделано». Благодаря такой схеме работы каждый участник видит, чем в данный момент заняты остальные.

Scrum методология: современные задачи и решения

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

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

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

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

Что делать дальше? Каждый пункт списка необходимо разобрать, чтобы понять, сколько на него уйдет сил, времени, прочих ресурсов. Как вести данную оценку? Scrum методология дает шкалу относительных оценок. Так вы можете сравнивать задачи «в собаках». Какой собакой будет эта проблема: таксой? ретривером? Или даже догом?

Правда, рекомендуем дополнять оценку числовыми показателями. Допустим, такса — единица, дог — тринадцать, лабрадор – пять, бульдог — три.

Помимо этого, Scrum методология предлагает довольно необычную методику покер-планирования. Смысл ее состоит в том, что всем участникам планирования дается по колоде карт с числами Фибоначчи — 1, 3, 5, 8, 13, пр. На стол выкладываются по очереди все пункты списка – это единицы работы, подлежащие оценке. Далее каждый участник группы берет карту с тем числом, которое, как он считает, отображает объем требуемых усилий, и кладет ее рубашкой вверх. После этого все участники разом показывают карты. Когда расхождение составляет не более двух карт (допустим, пятерка, две восьмерки, тринадцать), вычисляется среднее арифметическое (в примере это будет 6,6), и можно переходить к другой задаче. Не забывайте, речь идет об оценках небольших фрагментов проекта, а не о жестких планах. Но если вы видите расхождение более чем в три карты, тогда положившие карты с самыми полярными значениями должны объяснить свою точку зрения, после чего необходим новый раунд такого покера. Иначе произойдет простое усреднение оценок, что превратит результат только в приблизительный.

Sprint Planning Meeting:

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

Структура такой встречи по Scrum методологии состоит из следующих шагов:

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

Суть встречи проста, но очень сложным является ее содержание. На первых этапах проекта на такое общение может уходить по 5–6 часов. И лишь после 3–4-го спринта время на встречу сокращается до 2–3 часов.

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

Само название говорит о том, что встреча должна проходить каждый день. Ключевые особенности:

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

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

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

Встречу рекомендуется вести у Kanban доски, чтобы постоянно видеть все задачи спринта.

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

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

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

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

Ход презентации:

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

Встреча является открытой для всех работников компании и заинтересованных людей. Однако право голоса может принадлежать лишь участникам Scrum процесса (PO, Team, Scrum Master).

Презентаций в PowerPoint здесь не делают.

  • Retrospective

Данный ритуал необходим для обмена опытом внутри команды. Такая встреча проектной группы и Scrum Master’а проводится после Sprint Review. Также может присутствовать Produt Owner, если посчитает необходимым.

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

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

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

Какими достоинствами и недостатками обладает Scrum методология

У Scrum есть довольно весомые достоинства. Методология ориентирована на заказчика, адаптивна, позволяет изменять требования (хотя и не обещает, что все это будет реализовано). Такое воздействие на проект интересно многим клиентам.

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

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

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

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

Мнение эксперта

Как привлечь кадровый совет к решению острых кадровых вопросов

Дмитрий Багинский,
бизнес-тренер, экс-заместитель Генерального Директора компании «Сбербанк Страхование», Москва

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

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

Почему Scrum методология управления не всегда работает

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

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

2. Недооценена важность мотивирования группы.

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

Получается, только немногие могут эффективно работать в Scrum без внесения изменений в роли Scrum master, Product Owner. Этот факт противоречит самой идее и способен привести к ошибкам или неполной работе Scrum.

3. Scrum применяется к продукту, требования к которому не подходят под методологию.

Так как Scrum одобряет поправки в требованиях (Product backlog), затрудняется его использование в fixed-cost/fixed-time проектах. По Scrum методологии нельзя заранее предвидеть все изменения, а значит, бессмысленно сразу планировать весь проект. Требуется остановиться на just-in-timе планировании – говорить лишь о работе в текущем Sprint. Есть и другие ограничения в Scrum методологии.

Информация об экспертах

Марина Корсакова более десяти лет работает в управлении услугами, занималась маркетингом, продажами услуг, обучением сервисного персонала, операционным, антикризисным управлением. «Пять Звезд» — организатор деловых мероприятий. Находится на рынке b2b более 15 лет. В копилке «Пяти Звезд» находятся проекты, осуществленные для крупных российских и международных компаний: конференций, выставок, форумов, запусков новой продукции. Официальный сайт — www.5zvezd.ru.

Дмитрий Багинский, бизнес-тренер, экс-заместитель генерального директора компании «Сбербанк Страхование», Москва.

Подпишитесь и получите свежий номер журнала "Коммерческий директор", в котором:
    Подписаться со скидкой 45%>>>


    Ваша персональная подборка

      Подписка на статьи

      Чтобы не пропустить ни одной важной или интересной статьи, подпишитесь на рассылку. Это бесплатно.

      Рекомендации по теме

      Школа руководителя

      Школа руководителя

      Проверьте свои знания и приобретите новые

      Записаться

      Самое выгодное предложение

      Самое выгодное предложение

      Воспользуйтесь самым выгодным предложением на подписку и станьте читателем уже сейчас

      Живое общение с редакцией

      Выбор редактора

      Дайджест самых нужных статей

      Шеф-редактор журнала «Коммерческий директор» Амина Атавова

      Главный редактор журнала «Коммерческий директор»
      Амина Атавова.

      Читать сейчас




      © 2011–2016 ООО «Актион управление и финансы»

      Журнал «Коммерческий директор» –
      профессиональный журнал коммерсанта

      Зарегистрировано Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор) Свидетельство о регистрации ПИ № ФС77-62255 от 03.07.2017

      Политика обработки персональных данных

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

      
      Яндекс.Метрика
      • Мы в соцсетях
      Сайт использует файлы cookie. Они позволяют узнавать вас и получать информацию о вашем пользовательском опыте. Это нужно, чтобы улучшать сайт. Посещая страницы сайта и предоставляя свои данные, вы позволяете нам предоставлять их сторонним партнерам.Если согласны, продолжайте пользоваться сайтом. Если нет – установите специальные настройки в браузере или обратитесь в техподдержку.
      Зарегистрируйтесь на сайте и документ Ваш! Это бесплатно и займет всего минуту!

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

      • методики, проверенные на практике
      • правовая база
      • полезные подборки статей
      • участие и просмотр вебинаров

      У меня есть пароль
      напомнить
      Пароль отправлен на почту
      Ввести
      Я тут впервые
      И получить доступ на сайт Займет минуту!
      Введите эл. почту или логин
      Неверный логин или пароль
      Неверный пароль
      Введите пароль