Метод 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-управления проектами и особенностях его применения. Начать вы можете с этого небольшого видео, а мы желаем удачи вам и успешного осуществления всем вашим проектам!

 

4brain.ru

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

Я продолжаю работу над диссертацией по проектному менеджменту. Сегодня мы кратко рассмотрим 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)

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

habr.com

«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 прямо сейчас

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

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

О нас

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

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

habr.com

как понять 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-проектами»

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

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

skillbox.ru

Почему вам обязательно нужно узнать, что такое Scrum

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

Scrum («скрам») — практическое воплощение Agile-принципов. Это подход, позволяющий, по словам его создателя Джеффа Сазерленда (Jeff Sutherland), делать в два раза больше за вдвое меньшее время.

Вы, вероятно, хотели бы знать больше об Agile и Scrum, чтобы быть в теме. Мир IT уже невозможно представить без Agile, и эта «зараза» стремительно распространяется на традиционные офлайновые бизнесы.

Чтобы быть в курсе, вы можете прочитать новую книгу Джеффа Сазерленда «Scrum. Революционный метод управления проектами». Это займёт несколько дней. Альтернативный способ быстрого чтения умных американских бизнес-книг — прочитать краткую выжимку, пересказ, саммари от нашего партнёра — компании Smart Reading. Это займёт полчаса, и вы обязательно усвоите все ключевые идеи без воды.

Scrum появился около 20 лет назад как эффективный метод увеличения продуктивности при разработке программного обеспечения. Завоевав популярность в Кремниевой долине, Scrum быстро получил признание в других отраслях бизнеса. Его создатели Кен Швабер (Ken Schwaber) и Джефф Сазерленд изучили передовой мировой опыт успешных компаний и пришли к выводу, что «водопадная» модель, по которой прежде строилась работа над IT-проектами, безнадёжно устарела. Она не отвечала ожиданиям клиентов, поскольку работа продвигалась медленно, в строгом соответствии с долгосрочным планом, и часто на выходе получался не тот продукт, который на самом деле был нужен.

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

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

Люди важнее процессов

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

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

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

Продукт важнее документации

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

Scrum — это про смысл, а не про создание максимума бумажек ради создания максимума бумажек.

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

Сотрудничество с клиентом важнее идеально составленного контракта

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

Scrum — это про понимание и сотрудничество, а не про юристов и прикрывание мягкого места.

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

Способность меняться важнее следования планам

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

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

Как же быть? По Scrum, вы должны иметь большую цель, но идти к ней итеративно, не пытаясь предугадать каждый свой шаг в далёком будущем. Небольшими итерациями по 2–4 недели двигайтесь к цели, оборачивайтесь назад, делайте ретроспективу, оценивайте сделанное, отказывайтесь от результата последней итерации, если он не приближает вас к цели. Таким образом можно избежать глупых больших провалов. Итеративность — это научный подход. Надежды на правильность больших планов — это, скорее, похоже на религию.

Должности и титулы не важны — важно то, что вы делаете

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

Scrum — это про доверие, а не про силу и насилие.

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

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

Итак, узнать досконально всё о Scrum можно из книги его создателя Джеффа Сазерленда. В качестве альтернативы можно за 20–30 минут прочитать саммари этой книги в электронной библиотеке Smart Reading.

Читать на Smart Reading

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

lifehacker.ru

Основные заблуждения о SCRUM / Хабр

SCRUM? Какой SCRUM?

Впервые подход SCRUM (англ. scrum «схватка вокруг мяча») описали Хиротака Такэути и Икудзиро Нонака, которые заметили, что небольшие команды (5 — 9 человек), укомплектованные разнопрофильными специалистами, дают лучшие результаты. Наиболее полное описание SCRUM впервые представил в своей книге Джефф Сазерланд. Книга так и называется — SCRUM. Джефф начинал свою карьеру как военный летчик, во время войны во Вьетнаме выполнивший более ста боевых вылетов. Затем Джефф занимался наукой, но мир его запомнит как одного из родоначальников SCRUM. Книга начинается с реальной истории из жизни ФБР, тратившего миллионы долларов на разработку автоматизированной системы, предназначенной для поиска и отслеживания преступников. Проблема заключалась в том, что по истечении сроков проекта подрядчики демонстрировали ФБР абсолютно нерабочий продукт. Это означало лишь одно — американские налогоплательщики потратили миллионы впустую. Ситуация казалась безвыходной до тех пор, пока руководство ФБР не обратилось к тогда еще зарождавшемуся методу управления проектами SCRUM. Этот метод описан доступным языком в вышеупомянутой книге, которая, кстати, переведена на русский язык. Далее в статье рассмотрены основные заблуждения и мифы, которые могут отпугнуть топ менеджеров, задумавших внедрить SCRUM в свои проекты.

1. Тотальный контроль, который убивает творческий подход

В SCRUM как достичь бизнес-цели, решает проектная команда, а не руководство. Такой метод мотивирует и стимулирует творческий подход, в отличие от классического менеджмента, где сотрудникам делегируют выполнение конкретных низкоуровневых действий, а те, в cвою очередь, часто даже не понимают, для чего это и как это повлияет на проект в целом. Таким образом, в SCRUM руководство не контролирует действия проектной команды, а та, в свою очередь, отчитывается только о результатах в конце каждого спринта (установленного заранее промежутка времени, например, 2 недели). Прозрачность существует только среди членов проектной команды. В чем она она проявляется? В первую очередь, ежедневные stand-up митинги, на которых каждый участник проектной команды рассказывает, что он сделал вчера, что сделает сегодня, какие проблемы у него возникли. Такая практика не преследует цели проконтролировать объем работ, выполненный каждым сотрудником. Stand-up митинги предназначены для того, чтобы помочь каждому члену команды устранить препятствия в работе и посвятить коллег в свои планы, чтобы каждый понимал куда движется проект сегодня и осознавал свою роль в развитии продукта. Для этих же целей, кстати, служит общая SCRUM доска со стикерами, которую может посмотреть каждый, и опенспейсы, которые уничтожают препятствия для свободного общения членов команды.

2. SCRUM лишает прав самых опытных инженеров, потому что они подчиняются решению команды

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

3. SCRUM нацелен на краткосрочные ценности бизнеса, а не на долгосрочное развитие проекта

Данная проблема, действительно, актуальна. К счастью, на вопрос «Что же делать?» есть ответы. Следует начать с того, что если проект не долгоиграющий, с продолжительностью не более полугода, то данная проблема скорее всего не всплывет. Другое дело, когда софт развивается 2-3 и более лет. Существует множество статей, в которых авторы изливают свою боль касаемо таких проектов. Армия джунов и мидлов (синеры, как известно, стоят дорого и их мало) уверенно коммитит в master своё творчество, а заказчик спринт за спринтом пожинает блестящие результаты SCRUM. Но вот незадача, через 5-10 спринтов добавлять новые фичи становится проблематично, и чем дальше, тем сложнее. Следовательно, SCRUM — это хорошо, но о стратегии и об архитектуре задумываться надо. Предотвратить подобную ситуацию можно. Во-первых, на проекте должны работать как минимум 1-2 как можно больше опытных инженеров, которые будут пропускать через себя все коммиты в репозиторий во время code review. Во-вторых, уделять много времени обучению (не менее 3 часов в неделю) младших и средних инженеров архитектуре ПО, паттернам проектирования и тому, как это накладывается на существующий проект. Такие занятия должны сопровождаться практикой и минимальным домашним заданием для лучшего усвоения. Выполнение практических заданий можно встраивать в backlog проектных спринтов. Это не сильно ударит по рентабельности проекта, зато ускорит процесс роста сотрудников и предотвратит потенциальные проблемы с архитектурой ПО. Проведение периодических meetup-ов позволит проектным командам перенимать опыт друг у друга, что не навредит качеству выпускаемого софта.

4. SCRUM не дает развиваться инженерам

SCRUM предполагает, что все решения, касаемые способа достижения бизнес-целей делегируются команде. Владелец продукта решает, что нужно сделать, а команда решает — как. Из этого вытекает, что команда должна быть достаточно компетентной, чтобы принимать эффективные решения. Таким образом, краеугольным камнем методологии SCRUM является обучение. Вот почему во всех крупнейших банках и IT аутсорсерах так много внимания уделяется развитию: тренингам, семинарам, курсам. Профессиональный рост сотрудников — это неотъемлемая составная часть SCRUM. За счет того, что SCRUM команды относительно маленькие, членам команды приходится осваивать весь стек технологий в рамках проекта, над которым они работают. По окончании проекта инженер получает новые навыки, что увеличивает его стоимость на рынке труда.

Промежуточный итог

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

1. Джефф Сазерленд // SCRUM 2017.

habr.com

Все что нужно знать про Scrum. Гибкие методологии.

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

Учеба продолжается, три раза в неделю я знакомлюсь с новыми знаниями из области разработки и понимания digital продуктов изнутри. Для маркетолога, это новый мир. Ты слышишь про какой-то там Agile, понимаешь, что связано это с разработкой и вполне можешь поддержать беседу в общих красках. Но как только дело доходит до деталей, “поплыл”.

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

Что такое Scrum

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

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

Как работает Scrum

Как Scrum устроен на самом деле смотрите ниже.

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

Структура Scrum

Давайте посмотрим из каких элементов состоит Scrum.

 

Роли

  • Владелец продукта (product owner/manager). Ставит задачу, определяет приоритеты по задачам, взаимодействует с заказчиком.
  • Скрам-мастер – человек, который отвечает за процессы внутри команды, координирует работу, следит за внутренней атмосферой. Планирует спринт, организует скрам митинг, участвует в демонстрации результатов в конце каждого спринта.

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

  • Команда – 7±2 человек, которые реализуют требования владельца продукта.

Артефакты

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

Процессы

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

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

Пример Scrum

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

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

Выбираем, для примера, важную задачу или историю пользователя (user story) в рамках создания сайта: “Регистрация клиента/пользователя”. И раскладываем ее на более мелкие части. Формируем беклог продукта.

 

 

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

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

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

Понятно, что управлять такой “махиной” в реальном времени просто невозможно, поэтому для удобства работы, вся эта стена переезжает в специальный софт/программу (Jira, Trello, Redmine и прочие трекеры управления проектами). Там вы можете назначать ответственных за задачи и исполнителей, изменять статусы задач и прочее.

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

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

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

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

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

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

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

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

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

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

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

Оценка историй пользователей внутри беклога

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

Мы берем одну user story из беклога за образец и присваиваем ей ценность единицу (story point). Дальше оцениваем другие истории пользователя с точки зрения выбранной.

Например, в нашем сервисе есть история пользователя “Регистрация пользователя”. Мы берем ее за образец и даем ценность в один бал или один story point (так его называют в гибких методологиях). Каждый участник команды пишет свою оценку к остальным историям пользователя в списке с учетом задачи, которую взяли за образец и отдает ее скрам-мастеру.

В примере выше “Фото галерея с довольными клиентами”  стоит 0,5 story point, то есть по сложности она в 2 раза меньше нашей эталонной истории “Регистрация пользователя”. Все оценки участники команды ставят анонимно, можно на стикерах писать и переворачивать.

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

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

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

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

Можно ли применять Scrum не только в разработке

И да и нет. До того, как я начал понимать, что означают эти 5 букв (Scrum), часть принципов уже использовал в работе. Планирование, с помощью различных инструментов и выстраивание своего так называемого “спринта задач” уже было.

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

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

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

Когда применять Scrum

В основном в небольших проектах и старт-апах. Можно и в больших, типа Mail.ru, но там должна быть определенная свобода действий и отдельные функциональные команды со своим владельцем продукта. Не забывайте, что Scrum про гибкость и изменения. Команды не должны быть больше 7±2 человек, иначе невозможно будет эффективно организовать коммуникации.

Нюансы

Если вы решили внедрить Scrum у себя в проектах, то учитываете следующие нюансы:

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

Завершим

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


Читайте также:


Великолепный ролик от Николая Дроздова и Huawei. Обязательно смотреть!

Вконтакте

Facebook

Twitter

Google+

Загрузка…

www.alexcouncil.com

Отправить ответ

avatar
  Подписаться  
Уведомление о