Словарь терминов scrum

Scrum на практике

В книге 2004-го года Кен Швабер рассказывает множество реальных кейсов использования Scrum и раскрывает нюансы отдельных его элементов и практик. Книга подробно объясняет, как сделать так, чтобы Scrum работал.

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

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

Книга  богата конкретными примерами, и подробно разъясняет многие аспекты Scrum на практике.

Забавная деталь: в описании Ежедневного Скрама сказано, что “любой опоздавший участник при появлении незамедлительно выплачивает 1 доллар Скрам-мастеру”. Такой вот способ мотивации и дисциплины.

В конце книги есть приложение, с кратким описанием встреч, ролей и артефактов Scrum. Это приложение практически один-в-один совпадает с текстом первой версии Scrum Guide, который появится лишь через 6 лет. Видимо это не случайно.

Инкремент — результат «рывка»

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

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

Это всё, конечно, в идеале. В жизни бывает по-всякому.

Инкрементом первой итерации стали разные формы суперчебурека. Выбираем тот, что покруглее

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

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

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

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

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

Scrum Artifacts

Scrum’s artifacts represent work or value. They are designed to maximize
transparency of key information. Thus, everyone inspecting them has the
same basis for adaptation.

Each artifact contains a commitment to ensure it provides information
that enhances transparency and focus against which progress can be
measured:

• For the Product Backlog it is the Product Goal.

• For the Sprint Backlog it is the Sprint Goal.

• For the Increment it is the Definition of Done.

These commitments exist to reinforce empiricism and the Scrum values for
the Scrum Team and their stakeholders.

Product Backlog

The Product Backlog is an emergent, ordered list of what is needed to
improve the product. It is the single source of work undertaken by the
Scrum Team.

Product Backlog items that can be Done by the Scrum Team within one
Sprint are deemed ready for selection in a Sprint Planning event. They
usually acquire this degree of transparency after refining activities.
Product Backlog refinement is the act of breaking down and further
defining Product Backlog items into smaller more precise items. This is
an ongoing activity to add details, such as a description, order, and
size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the
sizing. The Product Owner may influence the Developers by helping them
understand and select trade-offs.

Commitment: Product Goal

The Product Goal describes a future state of the product which can serve
as a target for the Scrum Team to plan against. The Product Goal is in
the Product Backlog. The rest of the Product Backlog emerges to define
“what” will fulfill the Product Goal.

The Product Goal is the long-term objective for the Scrum Team. They
must fulfill (or abandon) one objective before taking on the next.

Sprint Backlog

The Sprint Backlog is composed of the Sprint Goal (why), the set of
Product Backlog items selected for the Sprint (what), as well as an
actionable plan for delivering the Increment (how).

The Sprint Backlog is a plan by and for the Developers. It is a highly
visible, real-time picture of the work that the Developers plan to
accomplish during the Sprint in order to achieve the Sprint Goal.
Consequently, the Sprint Backlog is updated throughout the Sprint as
more is learned. It should have enough detail that they can inspect
their progress in the Daily Scrum.

Commitment: Sprint Goal

The Sprint Goal is the single objective for the Sprint. Although the
Sprint Goal is a commitment by the Developers, it provides flexibility
in terms of the exact work needed to achieve it. The Sprint Goal also
creates coherence and focus, encouraging the Scrum Team to work together
rather than on separate initiatives.

The Sprint Goal is created during the Sprint Planning event and then
added to the Sprint Backlog. As the Developers work during the Sprint,
they keep the Sprint Goal in mind. If the work turns out to be different
than they expected, they collaborate with the Product Owner to negotiate
the scope of the Sprint Backlog within the Sprint without affecting the
Sprint Goal.

Increment

An Increment is a concrete stepping stone toward the Product Goal. Each
Increment is additive to all prior Increments and thoroughly verified,
ensuring that all Increments work together. In order to provide value,
the Increment must be usable.

Multiple Increments may be created within a Sprint. The sum of the
Increments is presented at the Sprint Review thus supporting empiricism.
However, an Increment may be delivered to stakeholders prior to the end
of the Sprint. The Sprint Review should never be considered a gate to
releasing value.

Work cannot be considered part of an Increment unless it meets the
Definition of Done.

Commitment: Definition of Done

The Definition of Done is a formal description of the state of the
Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an
Increment is born.

The Definition of Done creates transparency by providing everyone a
shared understanding of what work was completed as part of the
Increment. If a Product Backlog item does not meet the Definition of
Done, it cannot be released or even presented at the Sprint Review.
Instead, it returns to the Product Backlog for future consideration.

If the Definition of Done for an increment is part of the standards of
the organization, all Scrum Teams must follow it as a minimum. If it is
not an organizational standard, the Scrum Team must create a Definition
of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If
there are multiple Scrum Teams working together on a product, they must
mutually define and comply with the same Definition of Done.

Первый Scrum Guide. 2010

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

Прямо скажем, если читать его сегодня, то он выглядит очень “сырым” и сильно удивляет рядом анахронизмов

В 2010-м вышел первый Scrum Guide. Прямо скажем, если читать его сегодня, то он выглядит очень “сырым” и сильно удивляет рядом анахронизмов.

Если вы помните конец первой части статьи, то там говорилось, что Майк Кон выпустил в 2009-м году книгу “Succeeding with Agile” в которой ввел понятие Servant Leaderhip как основное свойство и образ действий Scrum Master’а.

Логично было бы ожидать упоминание Servant Leadership в первой версии Scrum Guide 2010.

Но идея Servant Leadership в Scrum Guide 2010 не упомянута вообще. Видимо, авторы Scrum Guide — Кен Швабер и Джефф Сазерленд — черпали материал для Scrum Guide 2010 из своих собственных книг, а не из книг других авторов. Последняя книга, написанная до 2010 года одним из авторов Scrum Guide, была книга “Agile Project Management With Scrum” которая вышла аж в 2004 году, когда идеи Servant Leadership не существовало в принципе.

Косвенным подтверждением моей гипотезы, служит тот факт, что текст Scrum Guide 2010 практически слово в слово повторяет приложение “Apendix A: Rules” к книге “Agile Project Management With Scrum”  2004-го года. В этом приложении содержится краткое описание встреч, ролей и артефактов Scrum, и глядя на это описание невооруженным взглядом видно множество фраз, параграфов и цитат, которые повторяются  в Scrum Guide 2010.

Снова мы видим прямую обязанность Scrum Master’а “железной рукой” внедрять Scrum, как это было в далеком 2001-м году, в книге «Agile Software Development with Scrum» (Scrum Book):

В то же время, Scrum Guide 2010 подтверждает позицию ScrumMaster’а как коуча, поддерживающего команду на пути освоения Scrum:

Анахронизмом, отсылающим нас к Scrum Book 2001-го года выглядит ответственность ScrumMaster за то, чтобы “найти и обучить Владельца Продукта”.

Кроме того, за ScrumMaster была закреплена обязанность “стоять на страже” Sprint Goal, чтобы команда не отклонялась от нее и фокусировала усилия для ее достижения

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

Scrum Guide 2010 как будто отбрасывает наработки авторов книг по Scrum за период 2001-2010 годов, и рисует нам картину все того же «ScrumMaster’а за рулем», который решает как реализовывать Scrum и вести команду. И одновременно с этим, меняется набор инструментов ScrumMaster’а — теперь он много фасилитирует, и делает упор на коучинг команды, а не директивное поведение.

Эдакий «просвещенный правитель», который лучше знает, как надо и полезно для команды и Владельца Продукта.

Пример комплексной проблемы

Давайте представим себе ситуацию: вы литературный менеджер. У вас есть несколько писателей. И заказчик поставил вам задачу — написать роман. Да не просто роман, а такой, какого еще не было! И чтобы обязательно продавался лучше всех. И выпускать этот роман надо по частям, что позволит подогревать интерес к книге. Так многие делали в начале XX века. Конан Дойл печатал свои произведения про Шерлока Холмса таким образом.

Основные требования от заказчика:

• Нужно получить максимально возможную прибыль от этого произведения. В идеале, чтобы этот роман был бесконечен, чтобы выпускать его вечно. Мы, конечно, понимаем, что это невозможно, но хотя бы года на 3-4 надо обеспечить доход.
• Каждую неделю вам надо выпускать главу. И чтоб лучше предыдущей. И чтобы все было связано между собой, над заранее знать что будет дальше.
• Вдобавок, заказчик вдохновился историей коллективного написания книги “The Painted Sky” Сиднейским книжным клубом и требует, чтобы будущая книга была написана коллективом из семи писателей.

Итак, у вас есть группа семи эрудированных, опытных, жаждущих успеха писателей.

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

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

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

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

Что делать? Управлять написанием книги в ручном режиме вы не можете — квалификация не позволяет. Поручить написание книги одному из семи писателей — велики риски сорвать план по выпуску глав книги.

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

Представили? Сложная проблема? А ведь именно с такой проблемой сталкивается большинство Scrum-команд:

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

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

Посмотрим подробнее на эти обязанности скрам-мастера.

Четвертый шаг. Делаем прототип

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

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

Не концентрируемся на дизайне, тут важна структура.

Акцентируем внимание на удобстве интерфейса будущего продукта для пользователя.

Показываем результат клиенту. Он добавляет комментарии.

Так выглядит прототип сайта с комментариями клиента. Источник.

Особенности Скрама

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

В частности, в Скраме отсутствуют конкретные рекомендации по техникам проведения скрам-мероприятий. Например, до 2020 года в Руководстве по Скраму в качестве примера приводился конкретный формат проведения мероприятия «Ежедневный Скрам» (с ответами каждого участника на 3 вопроса). Если команда не понимала ценностей Agile и Scrum, то этот формат зачастую приводил к бессмысленному механическому ритуалу проведения Ежедневного Скрама, поэтому его убрали даже как пример.

Скрам-команда

Вот, пожалуй, главная особенность Скрама в сравнении с другими подходами, следующими ценностям Agile-манифеста:

Именно c самоуправлением и кросс-функциональностью связан тот факт, что Скрам, несмотря на всю его простоту, достаточно сложно применять на практике. Откуда возникает потребность в самоуправлении/кросс-функциональности и как она реализуется в Скраме для IT-команд — рекомендуем посмотреть в 10-минутном видео от Асхата Уразбаева:

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

Скрам – эмпирический подход к управлению

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

Скрам сегодня – это не только про разработку программного обеспечения

• Остатки IT-терминологии из него были удалены в Scrum Guide 2020 (например, тестирование, требования, проектирование, система).
• При этом по факту еще в 2010-х годах Скрам вышел далеко за рамки ИТ-индустрии. Он успешно применяется командах маркетологов, дизайнеров, разработчиков материальной продукции; в розничной торговле, энергетике, промышленном проектировании/производстве и многих других отраслях.
• Подробнее про применение Скрама в не-ИТ отраслях можно прочитать в исследовании Agile в России 2019.

Purpose of the Scrum Guide

We developed Scrum in the early 1990s. We wrote the first version of the
Scrum Guide in 2010 to help people worldwide understand Scrum. We have
evolved the Guide since then through small, functional updates.
Together, we stand behind it.

The Scrum Guide contains the definition of Scrum. Each element of the
framework serves a specific purpose that is essential to the overall
value and results realized with Scrum. Changing the core design or ideas
of Scrum, leaving out elements, or not following the rules of Scrum,
covers up problems and limits the benefits of Scrum, potentially even
rendering it useless.

We follow the growing use of Scrum within an ever-growing complex world.
We are humbled to see Scrum being adopted in many domains holding
essentially complex work, beyond software product development where
Scrum has its roots. As Scrum’s use spreads, developers, researchers,
analysts, scientists, and other specialists do the work. We use the word
“developers” in Scrum not to exclude, but to simplify. If you get value
from Scrum, consider yourself included.

As Scrum is being used, patterns, processes, and insights that fit the
Scrum framework as described in this document, may be found, applied and
devised. Their description is beyond the purpose of the Scrum Guide
because they are context sensitive and differ widely between Scrum uses.
Such tactics for using within the Scrum framework vary widely and are
described elsewhere.

Пятый шаг. Планируем спринт

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

1. Определяем цель спринта. Она должна быть реалистичной. Не ставьте цель, которую не сможете выполнить.
2. Составляем бэклог. Задача Scrum ― создать продукт с минимальной функциональностью для быстрого запуска на рынок. Элементы бэклога спринта нужно сформулировать так, чтобы каждый член команды понимал задачу одинаково. Каждый элемент должен быть осуществимым, чтобы была реальная возможность внедрить его за один спринт.
3. Оцениваем элементы спринта, чтобы понять сложность и трудоемкость, проще расставить приоритеты и прогнозировать ход проекта.
4. Выполняем задачи спринта последовательно, учитывая приоритеты.
5. По итогу каждого спринта оцениваем, что было сделано и достигнута ли цель: сколько задач решено и какие элементы готовы к использованию.
6. Если есть сомнения по поводу какого-то элемента продукта, лучше запустить его как можно скорее и проверить в деле. Пользователи подскажут, как лучше.

Мы рассмотрели основные шаги, которые нужны, чтобы составить план проекта в Scrum. Но после составления плана работа только начинается. Дальше ― больше.

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

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

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

Ретроспектива состоит из четырёх частей и проходит по следующему плану: 

1. Команда обозначает все положительные моменты предыдущей итерации. Например, продукт выпущен вовремя. В статье это может казаться очевидным, но в жизни даже это само по себе может быть предметом для гордости. 
2. Обсуждаем проблемы. В нашем случае хотели предложить заказчику десять вариантов формы чебурека, а успели подготовить только три. 
3. Накидываем идеи по улучшению рабочего процесса. Например, не давать таких оптимистичных обещаний. 
4. В конце составляется план по внедрению принятых идей.

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

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

Ретроспектива происходит после каждой итерации

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

Инкремент второй итерации — цвета суперчебурека. Самым стильным выглядит чёрный цвет

Руководство Scrum

Product BacklogUser Story

Получение от заказчика Бизнес-цели. Составляем Impact Map для каждой бизнес-цели: Why?->Who?->How?->What? (Зачем?->Кто?->Как?->Что надо сделать?);
Формулировка User Story:
Будучи пользователем я хочу сделать , чтобы получить .
Как менеджер склада я получаю отчет о товарных остатках, чтобы БЫСТРЕЕ принять решение;
Формулировка без ЧТОБЫ (так лучше).
Как , я , .
Как менеджер склада я получаю отчет о товарных остатках БЫСТРЕЕ.
Разделение «актеров» на группы: целевая, важная, менее важная и т.д

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

Важно описывать историю на уровне «Что?» делает, а не «Как?», описать проблему, а не ее решение. «Как?» находится вместе с командой;
Ценность. Отказ от формулировки «Чтобы». Для каких-то историй можно указать ценность истории в формате «Чтобы», но не для большинства;
Переход с понятия «ценность» (value) на понятие «влияние» (impact). История не обязательно должна иметь ценность, но обязательно должна оказывать влияние на того актера, который указан в истории. Это влияние в конечном итоге ведет к цели;
User Story разбиваются по важности и функциональности и далее разбиваются на задачи в бэклоге.

Уточнение и оценка Product BacklogФормируется Sprint. Sprint Planning Meeting. Scrum Poker

1. Первая часть митинга могут участвовать все.
   Право голоса у Product Owner и Developer Team. Выбор User Story и Задач из Product Backlog в Sprint Backlog;
   Формулировка цели спринта — Sprint Goal. Определение ценности для бизнеса. Краткое описание бизнес-цели, ради которой выполняется данный спринт. Помогает команде принимать бизнес-обоснованные решения, или альтернативные решения.
2. Вторая часть митинга участвуют только Scrum Team. Наполнение Sprint Backlog.
   Определение, каким образом будет реализован объем работ. Обсуждение технических деталей;

Scrum Poker

1. Scrum Master ведет собрание;
2. Product Owner представляет краткие обзоры каждой задачи;
3. Происходит обсуждение, задаются вопросы;
4. Участники Developer Team выбирают по одной карте, потом переворачивают;
5. Если в результате голосования есть большой разброс в очках, то выслушивают двоих, перевернувших карты с минимальным и максимальным значением;
6. Затем голосуют вновь и присваивают задаче Story Points.

Daily Scrum Meeting

1. Проводится в одно и то же время;
2. Длится строго не более 15 минут. Решение проблем выносится за рамки митинга и в составе лиц, непосредственно затронутых данным препятствием;
3. Все отвечают только на три вопроса, отвечают друг другу, не Scrum Master-у: Что я сделал вчера? Что я буду делать сегодня? Какие проблемы есть у меня и команды на пути к цели?

Sprint Review MeetingSprint Retrospective Meeting. Ретроспектива.

Scrum и Канбан на масштабе крупной компании

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

Однако есть и разница. 

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

Приходится применять фасилитацию на большом масштабе, проводить громоздкие и дорогостоящие встречи (например, Big Room Planning), чтобы все вовлеченные Scrum-команды успели поговорить, договориться и двигаться дальше с общим пониманием целей, задач и контекста.

Так как у каждой Scrum-команды своя собственная Scrum-доска и свой пул задач, то в процессе движения нужны синхронизирующие встречи (например, Scrum of Scrums или PO Sync), на которые будут приходить представители от команд (Scrum-мастера или Владельцы продуктов), чтобы сделать прозрачным для всех текущий статус движения к общей цели, проблемы и необходимость разрешать зависимости. 

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

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

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

Некоторые из них — тактические, и проводятся часто (например, ежедневный Канбан-митинг).

Другие носят стратегический характер (ревью рисков, ревью сервиса поставки) и проводятся раз в несколько месяцев

С другой стороны, на разных уровнях иерархии надо собирать разные данные.

На уровне топ-менеджмента нужны данные о портфолио проектов и о статистике реализации проектов.

На уровне среднего менеджмента нужно собирать данные о работе крупного подразделения (например, департамента) над разными проектами.

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

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

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

Ценность продукта

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

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

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

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

Итерации — «рывок» проекта

Когда бэклог сформирован, команда оценивает силы и определяет длительность одной итерации. Итерация — это один рабочий «рывок», обычно в ИТ он занимает 1—3 недели. 

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

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

Перед каждой итерацией команда составляет план работы над выбранными пользовательскими историями. Дополнительно проводятся ежедневные встречи, на которых каждый участник отвечает на три вопроса: что он уже сделал, какие проблемы и чем будет заниматься дальше. На встречи не должно уходить более 15 минут, поэтому численность скрам-команд всегда ограничена 5—9 участниками. 

Встречи ведёт скрам-мастер — опытный член команды. Он выступает как менеджер: делает так, чтобы команда могла выполнить поставленную задачу, координирует людей и создаёт условия труда. Сломался ноутбук — скрам-мастер организует ремонт и найдёт новый на замену. Проблемы с дедлайном — скрам-мастер закупит кофе и поставит раскладушку в офис.

Что есть SCRUM

Скрам, он же SCRUM — это один из способов управления проектом

Помимо скрама проект можно делать в порядке постановки задач, в алфавитном порядке, по степени важности задач, в авральном режиме, хаотично; можно делать проект с восьми утра до пяти вечера или круглосуточно; можно делать проект, пока не сгоришь; можно — по графику «два через два»

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

Ещё в скрам входят всевозможные ритуалы, артефакты и заклинания, но это лишь подспорье для основной мысли: мы улучшаем проект маленькими рывками.

Теперь посмотрим на основные компоненты скрама. 

Похожие записи:

Как открыть пункт выдачи заказов wildberries по франшизе Средняя зарплата по странам мира. рейтинг 2020 Как придумать надежный пароль для ваших аккаунтов, который не смогут взломать Правила размещения рекламной вывески на фасаде частного и общественного здания 8346298 ##-## — какой оператор и регион? Заместитель генерального директора: должностная инструкция, обязанности и компетенция