Гибкая методология разработки “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 команды может быть невозможным.

Помимо 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: правила, события, команда

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

Фото: Shutterstock

Зачем нужен Scrum

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

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

Три артефакта Scrum

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

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

Agile или Scrum: как подобрать наиболее подходящую методологию

Автор: Max Rehkopf

Просмотр тем

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

Что такое agile?

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

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

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

Преимущества использования Agile

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

Недостатки использования Agile

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

Что такое Scrum?

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

Преимущества использования методологии Scrum

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

Недостатки использования методологии Scrum

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

Другие методологии: Kanban и каскадная модель

Что такое Kanban?

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

Что такое каскадная модель?

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

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

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

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

Сравнение Agile и Scrum

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

Сравнение методики Agile и каскадной модели

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

Управление agile-проектами с помощью Jira Software

Сегодня agile-методики отлично поддерживаются инструментами управления проектами. Решение Jira Software имеет встроенную поддержку Kanban, Scrum и не только. Эксперты регулярно расширяют возможности Jira, чтобы поддерживать даже самые сложные agile-методики. Начните работу со знакомства с руководством по Agile.

Поделитесь этой статьей

Max Rehkopf

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

Рассмотренный продукт
Интеграция Confluence и Jira Software
Подписаться

Подпишитесь и получайте больше статей

Thanks for signing up!

Обучающее руководство

Использование Confluence и Jira Software для планирования и уточнения спринтов в Agile

Сочетание Jira и Confluence — это непреодолимая сила, которая помогает команде воплотить в жизнь концепцию Agile.

Связывание стратегии бизнеса с реальными процессами разработки

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

При подготовке материала использовались источники:
https://habr.com/ru/articles/247319/
https://pro.rbc.ru/demo/6030e6f59a79475afea1892d
https://www.atlassian.com/ru/agile/scrum/agile-vs-scrum