Scrum master это




Содержание страницы

Roman’s knowledgebase

Что такое Scrum

Очередной конспект семинара о методологии управления проектами. На этот раз рассматриваем Scrum – один из, так называемых, гибких (agile) методов.

В отличие от таких всеобъемлющих подходов к управлению проектами, как, например, PRINCE2, Scrum изначально предназначался для разработки IT проектов. При этом Scrum больше ориентирован на сам процесс разработки, чем на процесс управления. С моей точки зрения, эта технология хорошо дополняет любой из процессов управления, и может быть с ним интегрирована при разработке очень больших IT проектов. (В сравнительно небольших IT проектах она самодостаточна)

Конспект семинара предоставлен моим коллегой Антоном Сальником

Оглавление

Введение

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

Термин Scrum был впервые озвучен в работе Хиротаки Такеучи и Икуджиро Нонака, где авторы отметили успешность проектов, использующих небольшие команды без жесткой специализации. Такие команды чем-то напоминают конструкцию схватки (scrum) в регби, которая назначается при нарушении правил или остановке игры. Джеф Сазерленд использовал эту работу при создании методологии для корпорации Easel в 1993 году, которую по аналогии и назвал Scrum, а Кен Швабер формализовал процесс для использования в индустрии разработки программного обеспечения, представив в 1995 году работу на конференции Object-Oriented Programming Systems, Languages & Applications.

Основа Scrum — итеративная разработка. Scrum определяет:

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

Концепция Scrum

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

В методологии Scrum всего три роли.

Product Owner

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

Обязанности владельца продукта таковы:

Scrum Master (Скрам Мастер)

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

Основные обязанности Scrum Master-а таковы:

Scrum Team

Scrum-команда (Scrum Team) — группа, состоящая из пяти–девяти самостоятельных, инициативных программистов. Первая задача этой команды — поставить реально достижимую, прогнозируемую, интересную и значимую цель для итерации. Вторая задача — сделать все для того, чтобы эта цель была достигнута в отведенные сроки и с заявленным качеством. Цель итерации считается достигнутой только в том случае, если все поставленные задачи реализованы, весь код написан по определенным проектом «стандартам кодирования» (coding guidelines), программа протестирована полностью, а все найденные дефекты устранены. Программисты этой команды должны уметь оценивать и планировать свою работу, работать в команде, постоянно анализировать и улучшать качество взаимодействия и работы.

Обязанности команды таковы:

Практики

Sprint

В Scrum итерация называется Sprint . Ее длительность составляет 1 месяц (30 дней).

Результатом Sprint является готовый продукт ( build ), который можно передавать ( deliver ) заказчику (по крайней мере, система должна быть готова к показу заказчику).

Подготовка к первой итерации, называемой спринт (Sprint), начинается после того, как владелец продукта разработал план проекта, определил требования и отсортировал их в количестве, достаточном для наполнения одной итерации. Такой список требований называется журналом продукта (Product Backlog). При планировании итерации происходит детальная разработка сессий планирования спринта (Sprint Planning Meeting), который начинается с того, что владелец продукта, Scrum-команда и Scrum-мастер проверяют план развития продукта, план релизов и список требований. Scrum-команда проверяет оценки требований, убеждается, что они достаточно точны, чтобы начать работать, решает, какой объем работы она может успешно выполнить за спринт, основываясь на размере команды, доступном времени и производительности. Важно, чтобы Scrum-команда выбирала первые по приоритету требования из журнала продукта. После того как Scrum-команда обязуется реализовать выбранные требования, Scrum-мастер начинает планирование спринта. Scrum-команда разбивает выбранные требования на задачи, необходимые для его реализации. Эта активность в идеале не должна занимать больше четырех часов, и ее результатом служит список требований, разбитый на задачи, — журнал спринта (Sprint Backlog). Необходимо, чтобы все участники команды приняли на себя обязательство по реализации выбранной цели.

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

Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.

Daily Scrum Meeting

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

Скрам митинг проводит Скрам Мастер. Он по кругу задает вопросы каждому члену команды

Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items , например в формате что/кто/когда, например

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

Sprint Review Meeting

В конце каждого спринта проводится демонстрационный митинг (Sprint Review Meeting) продолжительностью не более четырех часов. Сначала Scrum-команда демонстрирует владельцу продукта сделанную в течение спринта работу, а тот в свою очередь ведет эту часть митинга и может пригласить к участию всех заинтересованных заказчиков. Владелец продукта определяет, какие требования из журнала спринта были выполнены, и обсуждает с командой и заказчиками, как лучше расставить приоритеты в журнале продукта для следующей итерации. Во второй части митинга производится анализ прошедшего спринта, который ведет Scrum-мастер. Scrum-команда ищет использованные в последнем спринте положительные и отрицательные способы совместной работы, анализирует их, делает выводы и принимает важные для дальнейшей работы решения.

Затем цикл замыкается, и начинается планирование следующего спринта

Sprint Abnormal Termination

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

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

Артефакты

Product Backlog

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

Sprint Backlog

Журнал спринта содержит функциональность, выбранную владельцем продукта из журнала продукта . Все функции разбиты по задачам, каждая из которых оценивается командой. Разбивка на задачи должна быть сделана таким образом, чтобы выполнение одной задачи занимало не больше двух дней (считается, что менее детальная, например, полдня, разбивка приводит к более грубой оценке, чем приемлема в большинстве проектов, использующих методологию Scrum). Разбивка на задачи поможет так спланировать итерацию, чтобы в конце не осталось ни одной невыполненной задачи и, соответственно, достичь ее цели. После завершения детализации оценка журнала спринта сравнивается с первичной оценкой в журнале продукта. Если существует значительное расхождение, команда договаривается с владельцем продукта об объеме работ, который должен быть выполнен в течение итерации, и о том, какой объем будет перенесен на следующую. Менее важные и мало влияющие на цель итерации задачи выносятся из журнала спринта.

Burndown Chart

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

Выводы

Product Backlog

Sprint Backlog

Sprint Burndown chart

Scrum Master: кто он?

В классической модели управления Scrum есть три роли, одна их которых носит название Scrum Master (скрам-мастер). Это роль главного человека в той команде, которая в своей работе исповедует «гибкий» управленческий подход. Но нередко (особенно в бизнес-школах и Scrum-сообществах) Мастером – Professional Scrum Master (PSM) – называют человека, который постиг модель Scrum на фундаментальном уровне, принял философию «гибкого» подхода Agile и теперь не только сам может вести проект любой сложности, но и учит этому других. Такие люди получают сертификат (Scrum Master Certification) разного квалификационного уровня (ступени).

Роль «мастера» в Scrum-модели

В модели Скрам существует три роли:

  • Скрам Мастер.
  • Владелец продукта (Product Owner).
  • Команда (Team).

Каждый «ролевой персонаж» в этом коллективе несёт ответственность за свой «участок работы».

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

Ролевое распределение обязанностей

Команда (Team), которая, как правило, состоит из 6-8 человек, в парадигме Скрам должна самоорганизовываться и самоуправляться, а её работа рассматривается и оценивается как действие единой группы. Внутри команды нет чёткого подразделения на роли с ограничением действий, хотя в команду входят люди с разными профессиональными навыками. Мастер, однако, здесь стоит особняком и не считается членом Team.

Владелец продукта (Product Owner). В широком смысле – это посредник между рынком и бизнесом, который ведёт проект в рамках единого понимания требований. Он отвечает за то, чтобы результат работы был ценным и полезным на рынке. Такой человек руководит развитием продукта, а не деятельностью команды. Но положение посредника обязывает его:

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

В случае с Product Owner речь почти всегда идёт об одном человеке, который несёт персональную ответственность за создание ценности и поэтому сам корректирует приоритеты на каждом рабочем этапе-спринте. Однако иногда одному человеку исполнять эту роль сложно. Тогда функции «Владельца проекта» распределяются между несколькими людьми (например, один формулирует требования, а другой отвечает за взаимодействие с рынком). Но в этом случае всё равно обязательно назначается главный руководитель с правом (и обязанностью) единоличной расстановки приоритетов и авторизации требований в Bcaklog’e.

Скрам-мастер. Если Владелец проекта в модели Scrum не руководит командой, то логично предположить, что работой Team должен руководить Скрам-мастер. Однако и это не так, поскольку команда самоорганизовывается и не требует руководства. В отличие от классического Project Management, здесь такой командир вообще не предусматривается. Мастер помогает организовать работу команды, но в саму работу, как правило, не вмешивается. Он не ставит задачи и не заставляет работать.

Сложная роль Мастера

Аналог деятельности Скрам-мастера – функция администратора. Он должен обеспечить эффективные условия работы по заданной модели. На практике это означает, что:

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

Роль подобного координатора-администратора в коллективе не нова. Идеологически она чем-то похожа на роль комиссара в военном подразделении. (По этой аналогии функции командира отряда соответствуют функциям Product Owner в Scrum-модели).

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

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

Квалификация Скрам-мастера

При освоении модели управления Scrum кандидатам и на роль, и на звание Мастера нужно знать не только формальный алгоритм процесса, но, в первую очередь, исповедовать философию подхода. То есть, во многом менять свои ценностные ориентиры в бизнесе и во взаимоотношениях с коллегами, пересматривать правила своего поведения, а на это готовы пойти не все. По статистике, до 30% персонала, который ранее работал по классическим управленческим моделям, испытывают почти непреодолимые трудности, когда сталкиваются с внедрением гибкого подхода. Адаптироваться к «гибкому» формату самим и помогать в этом другим членам команды учат на специальных курсах, готовящих Скрам-мастеров.

Так, например, в тренинг-школе «Unusual Concepts» проводится двухдневный курс (Certified ScrumMaster), на котором даются базовые знания о модели. Проходящие обучение получают системные рекомендации по тактике внедрения модели в организации и по содержанию Scrum-процессов.

В частности, «студентов» знакомят со всеми этапами системы и её преимуществами:

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

Помимо этого есть 3-дневные курсы по подготовке руководителей проекта – «владельцев продукта» (Product Owner) и тренинг для Мастеров, по итогам которого выдаётся сертификат Скрам-мастера (PSM I). Это официальный курс от Scrum.org, сертификаты которого признаны во всём мире.

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

  • PSM I. Прошедшие обучение на этом уровне демонстрируют фундаментальное понимание формы и содержания Scrum, овладевают концептуальными знаниями.
  • PSM II. Люди на этой ступене знаний демонстрируют продвинутый уровень мастерства и могут эффективно применить его на практике даже в сложных ситуациях.
  • PSM III. Овладевшие этим уровнем отличаются всеобъемлющими теоретическими и практическими знаниями о Scrum и о ценностях идеологии.

«Дом Scrum.org» основал один из авторов модели, Кен Швабер (Ken Schwaber), который вместе со своим соавтором Джеффом Сазерлендом (Jeff Sutherland) в 2001 году вошёл в число 17 подписантов знаменитого манифеста Agile.

The Improved Methods

Обучение Agile методам, Agile трансформация компаний, консультации

Scrum на простом языке

Scrum (Скрам) — это не аббревиатура, этот термин взят из регби, который обозначает схватку вокруг мяча.

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

Основные термины, которые используются в методологии:

Владелец продукта (Product owner) — человек, который имеет непосредственный интерес в качественном конечном продукте, он понимает, как это продукт должен выглядеть/работать. Этот человек не работает в команде, он работает на стороне заказчика/клиента (это может быть как другая компания, так и другой отдел), но этот человек работает с командой. И это тот человек, который расставляет приоритеты для задач.

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

Scrum-команда — это команда, которая принимает все принципы Scrum и готова с ними работать.

Спринт — отрезок времени, который берется для выполнения определенного (ограниченного) списка задач. Рекомендуется брать 2-4 недели (длительность определяется командой один раз).

Бэклог (backlog) — это список всех работ. Можно сказать, что это ежедневник общего пользования 🙂

Различают 2 вида бэклогов: Product-бэклог и спринт-бэклог.

Product-бэклог — это полный список всех работ, при реализации которых мы получим конечный продукт.

Спринт-бэклог — это список работ, который определила команда и согласовала с Владельцем продукта, на ближайший отчетный период (спринт). Задания в спринт-бэклог берутся из product-бэклога.

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

Попробую объяснить все это на примере работы PR-агентства, как бы это могло выглядеть, если бы они работали по Scrum.

Компания клиент «Икс» хочет провести через 2 месяца масштабное мероприятие для своих партнеров и журналистов. Услуги по организации такого мероприятия компания «Икс» заказала у агентства «Зет». Компанию «Икс» представляет PR-менеджер, который отвечает за организацию мероприятия со стороны клиента. В терминологии Scrum — этот человек называется Владелец продукта. Со стороны агентства за организацию мероприятия отвечает account-менеджер (Scrum-мастер), в подчинении которого находится команда (Scrum-команда). На совместном совещании (планировании спринта) компания и агентство решают, что они будут отчитываться-планировать каждые 2 недели (длина спринта). На первые 2 недели они запланировали список задач (спринт-бэклог), однако команда оценила, что не все из этого списка они успеют выполнить. Тогда PR-менеджер (он же Владелец продукта), говорит какие из этого списка задач более приоритетные на ближайшие 2 недели, после чего команда берется за выполнение заданий. Единственное что здесь должно быть учтено, что на момент планирования первого спринта должен быть спланирован весь список заданий на 2 месяца (product-бэклог), чтобы не получилось так, что к моменту проведения мероприятия что-то не выполнено.

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

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 режиме.

Professional Scrum Master II Moscow, Mar 11-12, 2019

Course Overview

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

Price: RUB 55000

Course Details

Taught By

Location

More Information

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

Для кого
Тренинг будет полезен Скрам-мастерам с опытом работы от одного года.

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

Учебная программа

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

Основные темы курса:

  1. как успешный Скрам-мастер влияет на организацию;
  2. борьба со сложностью. Концепция «лидер-слуга»
  3. борьба с конфликтами в команде;
  4. устранение препятствий;
  5. техники фасилитации;
  6. важность готового Инкремента ;
  7. Цель Спринта;
  8. цель событий Скрама;
  9. роль менеджмента в Скраме;
  10. успешная доставка Продукта;
  11. метрики в Скраме;
  12. поддержка Владельца Продукта;
  13. проблемы миддл-менеджмента;
  14. Скрам-мастер как агент изменений.

Международный сертификат
После сдачи экзамена в Scrum.org все слушатели получают международный сертификат PSM II.

Группа до 24 человек
Вместо лекций и готовых презентаций вас ждут практические упражнения и бизнес-игры. Все важное вы нарисуете на флипчартах вместе с тренером.

55 000 рублей
В стоимость входят обед и кофе-брейки, раздаточные материалы и оплата экзамена.

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