Scrum методика: SCRUM – эффективный метод управления проектами

SCRUM – эффективный метод управления проектами

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

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

Scrum: определение и краткая история

Понятие «scrum» («скрам») впервые появилось в середине 80-х годов ХХ века в работах японских ученых Икуджиро Нонаки и Хиротаки Такеучи, когда они говорили об успехе проектов, в разработке которых участвовали небольшие команды без жесткой специализации. Эти команды они сравнивали с конструкцией схватки (от англ. «scrum») в регби, назначающейся судьей при остановке игры или при нарушении правил.

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

В 1995 году на конференции «Объектно-ориентированные системы, языки и приложения для программирования» Швабер указал, что основой Scrum-методологии является итеративная разработка, а сама она определяет несколько характеристик при работе с проектами:

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

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

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

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

Концепция Scrum-методологии

В системе Agile Scrum-управление проектами состоит из трех основополагающих частей:

• Роли
• Практики
• Документы (артефакты)

Чтобы уяснить суть, лучше разобрать эти части отдельно.

Роли в Scrum

Всего в Скрам есть три роли:

• Владелец продукта (Product Owner)
• Скрам-мастер (Scrum Master)
• Команда разработчиков (Delivery Team)

О них тоже имеет смысл сказать в отдельности.

Владелец продукта

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

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

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

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

• Формирование видения продукта
• Управление ожиданиями заказчика (и других заинтересованных лиц)
• Координация и приоритизация бэклога (журнала) продукта (см. ниже)
• Предоставление команде понятных и тестируемых требований
• Взаимодействие с командой проекта и заказчиком
• Прием и оценка результата работы в конце каждой итерации

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

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

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

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

Краткий перечень обязанностей скрам-мастера:

• Создание доверительной атмосферы
• Участие в общих встречах и обеспечение успешной коммуникации участников
• Устранение препятствий в работе
• Обозначение проблем и открытых вопросов
• Обеспечение соблюдения практик процесса

Команда разработчиков

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

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

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

Краткий перечень обязанностей команды разработчиков:

• Оценка элементов бэклога продукта (см. ниже)
• Разработка продукта и предоставление его заказчику
• Отслеживание своего прогресса (совместно со скрам-мастером)
• Предоставление результата владельцу продукта

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

Практики в Scrum

Как и ролей, практик в Scrum-управлении проектами существует три:

• Ежедневные Скрам-встречи (Daily Scrum Meeting)
• Встречи по обзору спринта (Sprint Review Meeting)
• Аварийная остановка спринта (Sprint Abnormal Termination)

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

Спринт

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

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

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

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

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

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

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

Ежедневные Скрам-встречи

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

Проводит ежедневные встречи скрам-мастер. Поочередно каждому участнику он задает вопросы:

• Что ты сделал вчера?
• Что ты сделаешь сегодня?
• С какими проблемами ты столкнулся?

Все открытые вопросы скрам-мастер заносит в список «Пункты действий». Здесь очень подходит формат «Что? Кто? Когда?». Вот простой пример такого списка:

• Обсудить детали дизайна бэкграунда
• Толя и Коля
• Сразу после обеда

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

Встречи по обзору спринта

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

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

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

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

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

Аварийная остановка спринта

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

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

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

Артефакты в Scrum

В любом Scrum-проекте есть три основных артефакта (документа):

• Журнал продукта (Product Backlog)
• Журнал спринта (Sprint Backlog)
• График спринта (Burndown Chart)

У каждого из артефактов есть свои особенности.

Журнал продукта

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

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

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

Журнал спринта

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

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

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

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

График спринта

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

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

Таковы общие особенности Scrum-методологии. Если у вас возникло желание разобраться в этом методе более детально, то вам поможет в этом Джеф Сазерленд – познакомьтесь с уже упоминаемой книгой «Scrum – революционный метод управления проектами». А нам остается только подвести итоги этого краткого обзора Скрам.

Выводы о Scrum

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

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

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

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

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

Однако преимущества Скрам-методологии не идут ни в какое сравнение с ее недостатками, и при определенной доле упорства овладеть ей не составит никакого труда. Использование же Scrum помогает компаниям реализовывать самые разные проекты и становиться более конкурентоспособными. Метод ориентирован на изменения и постоянное развитие, а его гибкость достигается посредством непрерывного взаимодействия участников проекта друг с другом.

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

Управления проектами — методология SCRUM

SCRUM — управление проектами

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

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

В чём заключается суть методики Scrum?

Авторы этого революционного направления Джефф Сазерленд и Кен Швабер ввёли понятие Scrum, позаимствовав его из известной командной игры «регби». Выражаясь простым языком, оно означает слаженную и ответственную командную работу коллектива над проектом.

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

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

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

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

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

ЗАКАЗАТЬ ТРЕНИНГ «AGILE MENAGEMENT — ТРАНСФОРМАЦИЯ МЫШЛЕНИЯ» ВЫ МОЖЕТЕ ПОЗВОНИВ ПО ТЕЛЕФОНУ: +7 (495) 394-33-17 ИЛИ ЗАПОЛНИТЬ ФОРМУ НА САЙТЕ. 

Манифест гибкой методологии, его основные принципы.

Авторы методики Scrum подписали, в числе других 17 участников, знаменитый манифест Agile Manifesto, в основу которого заложен определённый набор принципов, применяемых при разработке цифровых продуктов.

Они включают следующие моменты:

• Главным приоритетом становится удовлетворение всех потребностей клиента.
• Основу проектов составляют самоуправляемые команды профессионалов, без начальников и боссов, где члены коллектива обладают равными правами и все решения принимаются коллегиально, на основе совместного голосования. В этом случае процесс формирования команд отражается более полно, и сразу становится очевидным, кто стремится к достижению результата, а кто просто числится в коллективе и тянет его вниз.
• Работающий продукт, удовлетворяющий все потребности клиента, является основополагающим показателем прогресса.
• Для качественного выполнения работ нужно во всём довериться разработчикам. Именно это позволит создать оптимальные условия для быстрого прорывного решения комплексных задач, на основе полного понимания сути самой идеи всеми участниками процесса.
• Простота и минимум лишней работы является необходимым элементом.
• Команды на систематической основе производят анализ способов улучшения эффективности, качества проектирования, а также выполняют коррекцию стиля своей работы.
• Непрерывный процесс обмена информацией между владельцами продукта, разработчиками и конечными потребителями, поддержание рабочего ритма и ежедневная совместная работа способствуют повышению технического совершенства.
• Рабочий продукт должен выпускается как можно чаще, а изменение требований допускается на всех стадиях разработки.

Ценности методологии SCRUM

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

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

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

Роли в SCRUM

Методика Scrum разбита на определённые ролевые показатели, которые выполняют участники проекта, а именно:

• Владелец продукта, является своеобразным «связующим звеном» между конечными потребителями и разработчиками проекта. Он несёт ответственность за составление концепции, а также общается с командой разработки и клиентами, обсуждает с ними текущие и спорные моменты. Принимает решения и отвечает за ценность продукта. Для получения эффективного результата, способствующего извлечению максимальной прибыли, должен отлично разбираться в рынке и обладать рядом полномочий для принятия решений. Поэтому, при разработке крупных проектов, как правило, задействуют нескольких владельцев продукта.
• Команда разработчиков продукта, т.е. непосредственные исполнители проекта. Отвечают за темпы, сроки и качество выполнения работ.
• Скрам-мастер. Это ответственное лицо, которое следит за ходом выполнения проекта и оказывает помощь команде в решении и устранении разного рода препятствий и проблем. Также, занимается повышением эффективности её работы, выявляет точки роста и способствует мотивации сотрудников. Занимается организацией всех встреч и совещаний.

Планирование в SCRUM

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

Осуществляется планирование, как правило, в несколько этапов:

1. Выбор владельца продукта.
2. Создание профессиональных команд, включающих всех необходимых специалистов для выполнения проекта.
3. Выбор скрам-мастера.
4. Создание списка требований (бэклога) для продукта, расстановка по каждому пункту, в соответствии с приоритетом. По мере выполнения работ этот список может меняться.
5. Оценка бэклога. Уточнение размеров проекта. Члены команд производят оценку всех пунктов списка, учитывают все материальные и временные затраты на создание каждого из них.
6. Планирование спринтов (временных этапов по выполнению отдельных задач). Определение приоритетных целей спринта, объёмов, определение сроков и скорости выполнения работ. Балльная оценка выполнения спринтов.
7. Создание скрам-доски и диаграммы выполнения задач. Все задачи, которые выполняются, уже сделаны или готовятся к выполнению, помечаются стикерами и помещаются в соответствующие столбцы на доске.
8. Ежедневные оперативные собрания (короткие совещания с отчётами, выявление сложностей, запланированные на день задачи).
9. Обзор спринта (демонстрация готовой части проекта, выполненного за данный спринт).
10. Ретроспективный показ (презентация выполненного спринта, обсуждение рабочих моментов по внедрению улучшений).

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

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

Суть работы в команде

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

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

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

Характеристики команд

Лучшие коллективы обладают следующими характеристиками:

• Автономность и способности к самоорганизации, т.е. команда сама решает, как лучше добраться до цели.
• Поиски совершенства рабочего процесса.
• Многофункциональность коллектива и наличие культуры взаимопомощи, взаимозаменяемости. В команду подобраны такие люди, которые могут аккумулировать умения, необходимые для выполнения задач.
• Очерёдность выполнения задач.
• Отсутствие переработок.
• Работа в «потоке» — состоянии наивысшей творческой концентрации.

Размеры команд

Командная работа успешно выполняется только при наличии небольшого слаженного коллектива. Чтобы ваш проект развивался удачно, для работы в нём потребуется 7-8 человек.

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

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

Почему именно SCRUM

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

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

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

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

Автор: Александр Леонов

Гибкая методология разработки “Scrum” / Хабр

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

В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].

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

Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии 🙂

Авторами Scrum заявлены следующие особенности:

-Легкий (англ. Lightweight)

-Понятный, доступный

-Сложный в освоении

(практически взаимоисключающие параграфы)

Роли в Scrum

В классическом Scrum существует 3 базовых роли:

—Product owner

—Scrum master

—Команда разработки (Development team)

Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.

Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).

Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO

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

-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде каким преобразовать Product Backlog в работающий продукт

-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта

-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды

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

Процесс Scrum

Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении все жизни продукта.

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

Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint’а.

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

Схематическое изображение процесса приведено на следующем рисунке:

Важные, часто забываемые особенности

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

1. Scrum применяется неверно или неполностью.

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

2. Недооценена важность работы по обеспечению мотивации команды.

Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения [2].

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

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

Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла зарание планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. [3] Существуют и иные ограничения.

Достоинства и недостатки

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

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

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

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

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

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

Список использованных источников

[1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)

[2] Психология управления, учебное пособие. (А. А. Трусь)

[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)

Заранее благодарю за указанные ошибки и неточности!

«Scrum. Революционный метод управления проектами». Книга за 15 минут

Недавно мы в MakeRight.ru с удовольствием прочитали книгу «Scrum. Революционный метод управления проектами» Джеффа Сазерленда. О чем она? В двух словах — о том, как организовать слаженную командную работу.

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

Революционный ли это метод, как указано в названии? Не знаем. Но, возможно, те, кто не читал книгу и не знаком с методикой, почерпнут для себя ряд полезных идей из нашего саммари (краткого изложения). Итак…

Что такое Scrum. Суть методики

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

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

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

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

Scrum не требует внедрения каких-либо дорогостоящих инструментов. Схему методики Scrum вкратце можно описать следующим образом:

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

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

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

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

Изображение с сайта www.quickiwiki.com

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

Почему? Как отмечает Джефф Сазерленд, Генри Гант придумал такие диаграммы еще в 1910 году. Они получили широкое распространение в Первой мировой войне. Однако, «каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится-де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее „окопные“ организационные идеи остаются популярными и по сей день».

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

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

Планы рассыпаются в прах. Альтернатива — это Scrum

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

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

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

Изображение с сайта brendanmarsh.com

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

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

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

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

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

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

Философия scrum

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

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

Суть командной работы в Scrum

Scrum — это, прежде всего, командная работа. Автор выделяет три характеристики лучших коллективов:

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

На многофункциональности стоит заострить внимание особо. Автор приводит пример многофункциональной команды из спецназа — группу «Альфа» (команда «А»). Каждая такая «команда „А“ сформирована таким образом, чтобы все ее члены были разносторонними мастерами боевой подготовки, что позволяет им выполнять операции от начала до конца. Бойцы спецназа постоянно проводят обучение взаимозаменяемости по нескольким специальностям. Команда должна быть уверена, что если убьют обоих медиков, то, скажем, специалист по связи сможет оказать первую медицинскую помощь раненому товарищу. Существенная особенность, отличающая работу спецназа от действий „обычных“ армейских сил, заключается в том, что „зеленые береты“ самостоятельно выполняют и сбор разведывательных данных, и планирование операций. В их практике не допускается передача эстафетной палочки от одного подразделения другому — ведь именно в таких „швах“ таится слабое место, из-за которого возникают ошибки».

Какого размера должна быть команда? Джефф Сазерленд рекомендует малочисленные группы — около семи человек. Он приводит данные, что если группа состоит из более чем девяти человек, то скорость ее работы падает.

Кроме того автор напоминает о «законе Брукса»:

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

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

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

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

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

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

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

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

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

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

Суть работы — поток

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

Как его достичь? За состоянием потока стоит внутренняя дисциплина.

«Не должно быть ни одного движения впустую».

Скрам и счастье

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

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

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

Элементы скрам

Спринты

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

Изображение с сайта nyaski.ru

Однако есть важное замечание — «ничто не переносится в колонку „Сделано“ до тех пор, пока эта часть проекта не будет опробована клиентом».

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

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

Ежедневные собрания

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

Делайте до конца

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

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

Планирование в Scrum

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

Что делать потом? Каждый пункт списка нужно оценить на предмет того, сколько на его выполнение уйдет сил, времени и других ресурсов. Каким образом производить оценку? Автор предлагает шкалу относительных оценок. Например, можно сравнивать задачи «в собаках». Эта проблема — такса или ретривер? А может быть, дог?

Но в любом случае удобнее установить числовые значения. Например, «Такса — единица; дог — тринадцать; лабрадор стал пятеркой, а бульдог — тройкой».

Автор также предлагает использовать интересную методику покер планирования. Ее суть — каждому участнику процесса планирования дается колода карт с числами Фибоначчи — 1, 3, 5, 8, 13 и так далее. Каждый пункт списка, единица работы, которая должна быть оценена, выкладывается на стол. «Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче. Помните, мы говорим об оценках, а не о жестких планах. И оценках небольших фрагментов проекта. Если расхождение получается более чем на три карты, тогда те, кто положил карты с самым большим и самым маленьким значением, объясняют, почему они так считают. Затем проводится еще один раунд покера планирования. В противном случае они лишь усреднят оценки, что сделает результаты слишком приблизительными».

Требования — это истории

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

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

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

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

Вот профессионально сделанные пожелания пользователя, характер которых группа должна принять во внимание».

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

Как планировать спринт

В Scrum процесс планирования происходит в начале каждого нового спринта и так и называется — «планирование спринта».

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

После этого команда дружно произносит: «Вперед!» — и принимается за работу

Но что такое работа? Рутина, обязаловка? С точки зрения скрам, работа — это история. Что это значит? Это означает, что вам следует представить человека, которому нужно то, что вы делаете; потом то, что это такое, и, наконец, зачем людям это нужно.

Командам нужно хорошо узнать свою динамику — сколько работы она может выполнить за один спринт. Это поможет ей работать разумнее и устранять все помехи на своем пути.

«Динамика x время = результат. Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажетесь на финише».

Открытость во всем

Скрам предполагает прозрачность всех действий и процессов.

Это выражается в доске с тремя колонками, к которой имеют доступ все участники команды.

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

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

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

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

Бэклог

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

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

Как правильно расставить приоритеты?

«Для этого нужно выяснить, какие пункты списка:

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

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

Владелец продукта

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

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

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

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

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

«Методология Scrum полезна бизнесу тем, что быстро отвечает на вопрос: сможем ли мы заработать деньги, если сделаем то или иное?»

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

Как внедрить Scrum прямо сейчас

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

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

О нас

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

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

как понять Scrum и создать agile-команду — статьи на Skillbox

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

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

1. Определить требования к продукту.
2. Спланировать весь проект от начала до конца.
3. Написать код.
4. Протестировать продукт.

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

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

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

Манифест гибкой разработки ПО 

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

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

12 принципов Agile

 1. Главное — хорошее ПО и довольный заказчик.
2. Готовность к изменениям в любой момент.
3. Полностью рабочее ПО — как можно чаще.
4. Встреча команды — лучше всего для обмена информацией.
5. Заказчик и команда разработки должны работать вместе.
6. Доверять людям делать свою работу.
7. Есть рабочее ПО — есть прогресс.
8. Гибкие процессы — непрерывное развитие.
9. Внимание к качеству способствует гибкости.
10. Простота процесса позволяет не делать лишней работы.
11. Самоорганизующаяся команда лучше работает.
12. Постоянное стремление к большей эффективности.

Agile и водопад, весы

Одна из методологий гибкого процесса разработки программного обеспечения, которая базируется на agile-принципах, — Scrum.

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

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

Работа короткими циклами (спринтами)

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

Гибкость. «Проверять и адаптироваться»

Участие заказчика и пользователей в создании продукта.

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

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

Взаимодействие команды

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

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

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

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

• Разработчики. В составе scrum-команды всегда есть люди с разным набором навыков. Так, команда из пяти-девяти человек ведет весь проект от начала до конца. Одна команда — один готовый продукт.

Как выглядит scrum-команда

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

Постоянное самосовершенствование

Совершенствование продукта за счет самосовершенствования сотрудника.

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

Кросс-функциональность

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

Процесс работы scrum-команды проходит в несколько обязательных этапов.

• Планирование бэклога спринта

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

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

• Scrum-митинг, или совещание на ходу

Каждый день вся команда проводит короткую встречу, не более15 минут. Scrum-мастер и владелец продукта тоже участвуют. Суть встречи — получить от каждого члена команды ответ на три вопроса:

1. Что я сделал с момента прошлой встречи?
2. Чем я займусь сегодня?
3. Какие есть препятствия?

Задача scrum-мастера — понять, если что-то идет не так, и помочь команде справиться с трудностями.

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

Как выглядит scrum-доска

• Когда что-то идет не так

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

• Обзор результата

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

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

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

 1. Собрать команду

Это первый и основной шаг. Именно от слаженной работы команды зависит качество будущего продукта. Но не так легко собрать кросс-функциональную команду.

 2. Назначить владельца продукта

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

 3. Выбрать scrum-мастера

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

 4. Создать список требований к продукту

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

 5. Спланировать спринт

Разделить всю работу на периоды. Планировать каждый спринт. Не весь процесс разработки сразу, а только ближайший цикл.

 6. Постоянно анализировать и оценивать результат

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

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

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

Курс «Управление Digital-проектами»

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

• Живая обратная связь с преподавателями
• Неограниченный доступ к материалам курса
• Стажировка в компаниях-партнёрах
• Дипломный проект от реального заказчика
• Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

SCRUM: управление проектами (суровая правда)

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

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

И даже самостоятельно устранит все “косяки”, выявленные в ходе действия. А что если такое будет постоянно? Классненько же? Тогда поговорим о Scrum.

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

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

Для примера, вспомните Сбербанк всего 5 лет назад. Хамство, ужас и постоянная ругань с бабушками. И всего 5 лет по прошествию и внедрению Германом Грефом идеологии аджайл. Сейчас Сбербанк не узнать. Конечно, осталось еще это “Где карту получали туда и идите”, но… все совершенно по-другому. Однако вернемся к методологии скрам.

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

Что это такое

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

И эти определения наиболее подходящие для нашего блога (объясняющие сложное простым, человеческим языком). Они же несут в себе основные принципы scrum. Итак:

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

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

Scrum же это именно методология (тоже придуманная программистами, только 2-мя).

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

Почему везде одни программисты? Потому что изначально agile и scrum были придуманы при создании IT-решений (разработка программ). Ведь там процессы сложные и очень долгосрочные, просто так, через “устные приказы” всё не реализовать, и система не будет работать, как часы.

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

Само слово “scrum” было взято из регби. Это когда спортсмены разыгрывают мяч, уперевшись головами друг в друга, направив взгляд вниз. Командная игра, где важен каждый.

Регби

Составляющие скрам

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

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

1. Спринт

Спринт (у программистов это называется итерация) – это срок, в течении которого команда работает над проектом.

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

К примеру, в компании Nokia срок спринтов ставился 6 месяцев. У Apple срок спринта редко превышает 3 недели. Может именно в этом успех этой компании.

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

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

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

1. Что было сделано вчера?
2. Что я должен сделать сегодня?
3. Какие у меня были препятствия в работе надо проектом и как их устранить?

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

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

1. Что мы можем сделать лучше в следующий раз/в следующем “забеге”?
2. Какие были проблемы в этом спринте?

Именно ответы на эти вопросы сильно помогают улучшить эффективность работы над проектом в последующем.

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

2. Команда

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

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

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

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

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

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

2. Мотивация. Работа в команде – это один самых эффективных методов мотивации персонала.

   Она влияет на скорость и эффективность достижения высоких целей. Ведь каждый подтягивает друга друга и в какой-то степени вырастает, хоть и дружественная, но конкуренция.

3. Автономность. У проекта нет формального лидера, который всем руководит. Руководитель лишь ставит задачу, а команда (или команды, если их несколько) уже сама решает, как лучше ее выполнить, чтобы прийти к желаемому результату.

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

Ведь у нас у всех и так всё под завязку, а тут ещё дополнительные встречи. Но об этом чуть позже.

НАС УЖЕ БОЛЕЕ 32 000 чел.
ВКЛЮЧАЙТЕСЬ

3. Роли

А теперь самое необычное, что есть в методологии скрам, что ее отличает от многих. Это роли.

Так как в scrum нет руководителей и явных лидеров (это собственно главный принцип agile-методологии), то кто-то должен модерировать работу команды и работу над проектом в целом. И для этого в методе скрам бывают следующие роли:

• Владелец продукта;
• Скрам-мастер;
• Команда-разработки.

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

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

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

1. Видение со стороны конечного пользователя итогового продукта;
2. Решения о любых изменениях в проекте;
3. Связь команды и заказчика.

3.2 Скрам-мастер. Как и в любом проекте, в скрам есть люди, которые руководят всем проектом. В нашем подходе это скрам-мастер. Его главные задачи в проекте:

1. Контролирование хода всего проекта;
2. Организация спринтов и совещаний;
3. Выявление затыков и их устранение;
4. Доработка продукта до идеального состояния.

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

Плюсы и минусы скрам

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

И скрам не исключение. Есть преимущества scrum перед, например, каскадно-водопадной методологией управления проектами, но есть и свои недостатки.

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

Преимущества

1. Отсутствие бюрократии и довольные сотрудники

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

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

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

2. Готовый идеальный продукт

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

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

Открою Вам секрет, но у первого iPhone, на момент его презентации Стивом Джобсом в 2007 году, не было полной инструкции и готовой технической документации. Зато был телефон, который перевернул мир. А технические инструкции доделывали уже потом в диком темпе. Но об этом никому, я обещал молчать 😉

3. Получение обратной связи и продукта, который купят (вытекает из преимущества “готовый идеальный продукт”).

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

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

4. Внутренняя обстановка

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

А все это время они занимаются тем, что по-настоящему любят. Их главная задача – не работа для галочки, а реализация наилучшим образом задачи.

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

5. Экономия

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

Ведь всё, что Вам нужно, это понимание, как всё устроено и как это реализовать именно у Вас. Дорогостоящее программное обеспечение для этого не обязательно, хотя и желательно.

Недостатки

Звучит это все, конечно, круто и наверное даже фантастически. Столько плюсов! Вы поставили проект и в дальнейшем команда сама работает при минимальном контроле. Но не все так хорошо. Методология скрам имеет и свои минусы.

1. Команда

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

Они должны не только сочетаться между собой как профессионалы, но и как обычные люди. Если нет руководителя, то это не говорит о том, что команда будет работать на 146% своего КПД.

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

2. Планирование

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

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

3. Время

Помните, что в спринтах постоянно проводятся спичи (мини-планерки)? А теперь посчитайте, сколько это времени занимает в целом проекте.

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

4. Жесткость

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

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

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

Первое мнение, которое у меня сложилось: метод скрам – это только для IT-компаний. Частично это верно.

Но сколько таких компаний в числе наших читателей? Наверное 0,001%. Поэтому подведём итог, основываясь на малом бизнесе, а именно на рознице, услугах, опте и производстве.

В каких из вышеперечисленных бизнесов есть сложные и длительные проекты, для которых требуется команда из 7 человек? Скорее всего Вы скажите, что в НИ-КА-КИХ. В этом и весь смысл. Скрам подходит только в тех случаях, когда Вы создаёте что-то неопределённое, что сами до конца не понимаете. А значит и планировать дальше 2-3 месяцев не можете.

В малом бизнесе нужно использовать обычный каскадный подход (последовательный переход от одного этапа к другому).

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

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

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

Scrum — что это такое, как это работает и в чем преимущества

Платформа

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

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

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

Артефакты Scrum

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

• Бэклог продукта — это главный список работ, которые необходимо выполнить. Его ведет владелец продукта или менеджер продукта. Это постоянно меняющийся перечень функций, требований, улучшений и исправлений, из которого составляются задачи для бэклога спринта. В общем и целом, это список задач команды. Владелец продукта постоянно обращается к бэклогу продукта, меняет в нем приоритеты и поддерживает его актуальность, потому что может появиться новая информация или могут произойти изменения на рынке, из-за чего пропадет смысл выполнять имеющиеся задачи или появятся новые способы решения проблем.
• Бэклог спринта — это список рабочих задач, пользовательских историй или исправлений багов, отобранных командой разработчиков для реализации в текущем цикле спринта. Перед каждым спринтом проводится собрание по планированию спринта (о нем читайте далее в статье), на котором команда выбирает, какие задачи из бэклога продукта она выполнит в рамках спринта. Бэклог спринта может не быть фиксированным и может меняться по ходу спринта. Однако ничто не должно мешать достижению основной цели спринта — того, чего команда хочет добиться за текущий спринт.
• Инкремент (или цель спринта) — это готовый к использованию конечный продукт выполнения спринта. В компании Atlassian принято представлять инкремент на демонстрации в конце спринта, на которой команда показывает, что она сделала за спринт. Слово «инкремент» не так уж широко встречается в обычной жизни, но его часто определяют как принятые в команде критерии готовности продукта, контрольную точку, цель спринта или даже полную версию или поставленный эпик. Все зависит от того, какими критериями готовности руководствуется ваша команда и как выбираются цели спринта. Например, некоторые команды предпочитают выпускать что-нибудь для своих клиентов в конце каждого спринта. Для них «готовый» равно «поставленный». Однако для других команд это может быть непрактично. Представьте, что вы работаете над серверным продуктом, который можно поставлять клиентам лишь раз в три месяца. Вы по-прежнему можете разбивать работу на двухнедельные спринты, но для вас продукт будет «готов», когда вы завершите работу над частью большей версии, которую вы планируете поставить целиком. Естественно, что чем больше времени уходит на выпуск ПО, тем меньше шансов у этого ПО снискать успех.

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

Собрания или мероприятия Scrum

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

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

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

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

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

3. Спринт. Спринт — это фактический промежуток времени, в течение которого команда Scrum совместно работает над созданием готового инкремента. Как правило, спринт длится две недели, хотя некоторым командам проще спланировать объем спринта на одну неделю или поставить инкремент, обладающий достаточной ценностью, за месяц. Дейв Уэст из Scrum.org рекомендует выбирать спринт тем короче, чем сложнее работа и чем больше в ней неизвестных. Но последнее слово всегда за командой, и вам не стоит бояться менять продолжительность спринта, если покажется, что она вам не подходит. В течение этого периода владелец продукта и команда разработчиков могут пересмотреть объем спринта, если это необходимо. Это и есть ключ к пониманию эмпирической сути Scrum.

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

4. Ежедневное scrum-совещание, или стендап. Это ежедневное сверхкороткое собрание, которое для простоты проводится в одно и то же время (обычно утром) и в одном и том же месте. Многие команды стараются уложиться в 15 минут, но это не более чем ориентир. Такое собрание еще называется «ежедневным стендапом», что подчеркивает его краткость. Ежедневное scrum-совещание проводится, чтобы каждый участник команды был в курсе происходящего, не отклонялся от пути к цели и получал план работы на ближайшие 24 часа.

   Стендап — самое время сообщить обо всем, что мешает вам достичь цели спринта, в том числе о блокерах.

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

   •      «Что мне удалось сделать вчера?»
   •      «Что я планирую сделать сегодня?»
   •      «Может ли мне что-то помешать?»

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

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

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

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

Три важнейшие роли, от которых зависит успех применения Scrum

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

Владелец продукта Scrum

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

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

• Они решают, когда поставить продукт, стремясь делать это как можно чаще.

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

Scrum-мастер

Scrum-мастера следят за применением принципов Scrum в своих командах. Они обучают команды, владельцев продуктов и остальную компанию тонкостям scrum-процесса и ищут способы оптимизировать применение этой практики.

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

Команда разработчиков Scrum

На команды Scrum ложится вся основная работа. Они специалисты по принципам сбалансированной разработки. Самые успешные команды сплочены, находятся в одном месте и обычно состоят из 5–7 участников. Чтобы определить размер команды, можно обратиться к известному «правилу двух пицц», которое сформулировал глава Amazon Джефф Безос (в команде должно быть столько участников, чтобы им хватало двух пицц).

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

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

Scrum, Kanban и agile

Scrum — настолько популярная agile-методология, что слова Scrum и agile многие ошибочно используют как синонимы. Но есть и другие методологии, например Kanban, которая тоже пользуется популярностью. Некоторые компании даже предпочитают гибридную модель, сочетающую в себе элементы Scrum и Kanban. Ее называют Scrumban или Kanplan — по сути, Kanban с бэклогом.

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

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

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

За что мы любим Scrum?

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

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

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

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

Что такое Scrum?

Перейти к основному содержанию

Домой

Икс

• авторизоваться
• регистр
• партнеры
• служба поддержки
• Поиск

• Домой
• Насчет нас
  
  • Назад
  • Насчет нас
  • Обзор
  • Почему Scrum.орг
  • Новости
  • Карьера
  • Познакомьтесь с нашими сотрудниками
  • Познакомьтесь с нашими тренерами и тренерами
  • Разнообразие и инклюзивность
  • Связаться с нами
• Повышение квалификации
  
  • Назад
  • Повышение квалификации
  • Обзор курсов
  • Посмотреть расписание занятий
  • Запросить частный класс
  • Найдите тренера или тренера
  • Станьте профессиональным тренером по Scrum
  • Отзывы студентов
  • Профессиональные компетенции Scrum
• Сертификация
  
  • Назад
  • Сертификация
  • Обзор
  • Профессиональный Скрам Мастер
  • Профессиональный владелец продукта Scrum
  • Профессиональный разработчик Scrum
  • Масштабируемый профессиональный Scrum
  • Профессиональный Scrum с Канбан
  • Профессиональное гибкое лидерство
  • Профессиональный Scrum с пользовательским опытом
  • Поиск профессиональных держателей сертификатов Scrum
• Открытые оценки
  
  • Назад

.

Что такое Scrum of Scrums [с целью, повесткой дня и результатом]

Scrum of Scrums Origins

Scrum of Scrums был впервые разработан IDX Systems, теперь GE Healthcare. Джефф Сазерленд (разработка SVP) и Кен Швабер (консультант) реализовали его как метод масштабирования отдельных scrum-команд до уровня предприятия. В восьми бизнес-подразделениях, каждое с несколькими линейками продуктов. Каждая линейка продуктов имеет свой собственный Scrum of Scrums , некоторые продукты имеют несколько Scrum of Scrums с более высоким уровнем Scrum of Scrums , весь продукт должен быть доставлен на рынок, с циклом выпуска три месяца или меньше, и все продукты необходимо полностью интегрировать, обновлять и развертывать каждые шесть месяцев для поддержки региональных поставщиков медицинских услуг, таких как Стэнфордская система здравоохранения.

Scrum of Scrums использовался в дальнейшем в ведении пациентов, пока Сазерленд был техническим директором (2000-2008), для поддержки нескольких корпоративных выпусков как для больничных систем, так и для партнеров (GE и Cerner) в каждом спринте. Встреча Scrum of Scrums длилась около 15 минут каждый день:

1. Чтобы уменьшить препятствия для любого выпуска во время спринта
2. Слушайте отчет на уровне команды, отвечая на вопросы ежедневного Scrum

Диаграмма, показывающая Scrum of Scrums

Что такое Scrum of Scrums

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

Scrum of Scrums определение

По словам Джеффа Сазерленда, определение Scrum of Scrums следующее:

Подход для координации между несколькими командами в Scrum — это Scrum of Scrums или также называемый SOS . Это включает в себя различные команды для координации своей межгрупповой работы.Команда, работающая с SOS, состоит из отдельных членов различных команд разработчиков. Команда разработчиков решает, какого члена команды следует отправить в Scrum of Scrums , исходя из того, кто может лучше выступить, чтобы решить проблемы межгрупповой зависимости. Человек, представляющий команду во время экстренного вызова, может со временем измениться и может быть заменен другим человеком, который лучше всего может представлять команду и решить проблему в этот момент.

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

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

1. Что моя команда сделала с момента нашей последней встречи, что могло повлиять на другие команды?
2. Что будет делать моя команда перед новой встречей, что может повлиять на другие команды?
3. С какой проблемой сталкивается моя команда, для решения которой может помочь другая команда?

У Команды будет 15 минут времени на Scrum of Scrums , так же, как и на индивидуальную ежедневную встречу Scrum

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

Какова цель Scrum of Scrums?

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

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

Общая цель — обеспечить непрерывность работы команд и выполнение общих результатов.

Повестка дня схваток

• Что вы делали вчера?
• Что ты будешь делать сегодня?
• Какие препятствия стоят на вашем пути или замедляют вас

Какой должна быть частота?

Частота Scrum of Scrums в основном определяется командой.Кен Швабер предлагает проводить встречи ежедневно, как и ежедневный стендап или ежедневный скрам. Также он предлагает ограничить время встреч не более 15 минут. Он предпочитает проводить потенциально более длительные встречи реже. Кен Швабер обнаружил, что часто бывает достаточно двух или трех раз в неделю. Это делает расписание вторник-четверг или понедельник-среда-пятница подходящим.

Кто все принимает участие?

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

• Scrum Master принимает участие в Scrum of Scrums, иногда Agile-коуч
• Владелец продукта представляет работу всей команды, обычные представители каждой команды
• Команда или группа, которые отвечают за Результат в рамках плана выпуска должен присутствовать на Scrum of Scrums
• Другие часто посещают Scrum of Scrums как средство обмена информацией с другими командами, эти люди просто слушают и собирают информацию

Когда мы проводим Scrum of Scrums?

Встречи Scrum of Scrums в основном проводятся для поддержки гибких команд, сотрудничества и координации их работы с другими командами.

Каков результат Scrum of Scrums?

Встреча Scrum of Scrum дает ясную картину и путь, по которому команда движется к конечной цели, команда может определить четкий план на день.

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

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

.

Схватка схваток | Atlassian

«Рост» — это не то же самое, что «масштабирование»

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

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

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

История Scrum of Scrums

Методология Scrum of Scrums была впервые внедрена в 1996 году Джеффом Сазерлендом и Кеном Швабером, двумя пионерами структуры Scrum. И Сазерленду, и Шваберу нужен был способ координировать восемь бизнес-единиц с несколькими линейками продуктов на бизнес-единицу и синхронизировать отдельные команды друг с другом.Поэтому они попробовали новый способ масштабирования Scrum-команд для достижения этой цели. Этот опыт вдохновил Сазерленда на публикацию в 2001 году статьи под названием «Agile Can Scale: изобретение и переосмысление SCRUM в пяти компаниях», в которой Scrum of Scrums впервые упоминался публично.

С тех пор популярность Scrum of Scrums возросла как практика, тесно связанная с гибким масштабированием. Он встроен в Scrum @ Scale Guide и упоминается в других масштабируемых гибких фреймворках, он обеспечивает структуру, помогающую группам масштабироваться.

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

Что такое Scrum of Scrums?

Scrum of Scrums — это масштабируемая гибкая техника, которая предлагает способ объединить несколько команд, которым необходимо работать вместе для предоставления комплексных решений.

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

Чтобы поддержать это, размер команды имеет решающее значение. Исследования Хакмана и Видмара показывают, что 4,6 человека — это теоретически «идеальный размер команды». Слишком маленькие или большие команды могут столкнуться с трудностями при доставке сложных продуктов.

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

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

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

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

Когда несколько команд создаются для достижения общей цели, необходима координация. Это породило потребность в Scrum of Scrums.

Цель Scrum of Scrums

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

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

Scrum of Scrums — масштабируемая структура

Вновь сформированная команда Scrum of Scrums применяет почти те же методы, участвует в тех же мероприятиях и выполняет те же роли, что и команда Scrum.Чтобы предоставить интегрированный, потенциально готовый к поставке продукт в конце каждого спринта, могут потребоваться дополнительные роли, например архитекторы или руководители отдела контроля качества.

Например, есть роль главного владельца продукта. Главный владелец продукта отвечает за надзор за командой владельцев продукта и помогает формировать общее видение продукта.

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

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

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

Заключение и соображения

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

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

• Сохраните масштабируемую ежедневную схватку до 15 минут, отражая ежедневную схватку вашей команды
• Проведите масштабную ежедневную схватку в течение 15 минут после последней ежедневной схватки команды
• Установите рабочее соглашение для Scrum of Scrums
• Согласуйте коллективное и индивидуальное определение завершенного и, конечно же, поделитесь им!
• Установите распорядок дня или повестку дня, чтобы сфокусировать масштабируемую ежедневную схватку
• Начните отслеживать количество дней, в течение которых вы заблокированы препятствиями
• Отслеживайте, сколько масштабных ежедневных схваток было начато и завершено вовремя
• Сосредоточьтесь на доставке историй, у которых есть зависимости первый, чтобы снизить риск и дать возможность другим командам
• Отслеживайте и визуализируйте дни до демонстрационной встречи

По правде говоря, нет правильного способа масштабирования Agile.Но многие организации добились большого успеха, развивая свои процессы, команды и культуру, используя фреймворки для гибкого масштабирования. Узнайте больше о самых масштабируемых Agile-фреймворках, используемых сегодня, и больше в разделе Agile at Scale Agile Coach.

Крис Спаннер

Крис Спаннер — консультант по Agile @ Scale, увлеченный преобразованиями, которые устанавливают новые методы работы. В настоящее время Крис связывает бизнес-стратегию организации с техническим выполнением для различных клиентов и помогает управлять трансформацией в качестве архитектора решений Jira Align.Вне офиса вы наверняка встретите его летом на мотоцикле, а зимой — на лыжах.

.

Этапы и процессы в Scrum-проекте | SCRUMstudy

.