Блог

Scrum-разработка и ее роль в управлении проектами

17.06.2019

Вопросы, рассмотренные в материале:

  • Почему Scrum-разработка получила такое название
  • За счет чего гибкой Scrum-разработке удается повысить эффективность
  • Как осуществляется управление проектом в Scrum-разработке
  • Каковы достоинства гибкой Scrum-разработки

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

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

Об истории разработки Scrum

Scrum-разработка

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

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

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

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

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

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

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

Плюсы и минусы методологии разработки Agile Scrum

Scrum-разработка

Scrum имеет немало плюсов:

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

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

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

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

Роль команды в Scrum-разработке

Scrum-разработка

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

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

  • роли;
  • практики;
  • документы (артефакты).

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

1. Роли в Scrum.

Существует три роли:

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

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

Вот его основные обязанности:

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

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

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

Среди обязанностей скрам-мастера необходимо выделить:

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

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

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

Команда, участвующая в Scrum-разработке, обязана:

  • оценивать элементы бэклога продукта;
  • разработать продукт и предоставить его заказчику;
  • отслеживать собственное продвижение – этот этап выполняется вместе со scrum-мастером;
  • предоставить результат разработки владельцу продукта.

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

Обычно рабочая группа состоит из 7 (плюс/минус 2) человек. Считается, что более объемные команды требуют слишком много ресурсов на коммуникацию. Тогда как работа в маленьких командах чревата рисками из-за отсутствия необходимых навыков, снижением продуктивности на единицу времени.

3. Артефакты. Это набор требований к функциональности продукта, помогающий организовать деятельность входящих в команду специалистов. Данные требования описаны в двух журналах: журнале пожеланий проекта (project backlog) и журнале пожеланий спринта (sprin tbacklog).

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

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

Концепция методологии гибкой разработки Scrum

Scrum-разработка

Scrum-разработка предполагает три вида практик:

  • встречи на ежедневной основе (Daily Scrum Meeting);
  • встречи по обзору итерации (Sprint Review Meeting);
  • аварийная остановка спринта (Sprint Abnormal Termination).

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

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

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

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

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

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

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

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

Scrum-разработка

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

Встречи проводит скрам-мастер и задает всем специалистам стандартные вопросы:

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

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

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

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

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

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

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

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

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

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

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

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

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

3 ошибки Scrum-разработки, которые лучше не допускать

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

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

  3. Проведена недостаточная работа по мотивации команды.
  4. Напомним, что разработка продукта при помощи данного подхода базируется на самоорганизующейся, многофункциональной команде. Исследования социологов показали, что только 15 % всего работоспособного населения являются самомотивированными сотрудниками, способными самостоятельно распределять свое время при выполнении задачи. Иными словами, лишь немногие могут эффективно работать со Scrum, не требуя серьезных изменений в ролях Scrum-master и Product Owner. Кстати, любые подобные изменения не вписываются в идеологию Scrum, приводя к первой проблеме.

  5. Scrum пытаются использовать для продукта, который не может быть создан при помощи данной идеологии.
  6. Scrum является частью семейства Agile, допускает изменения в требованиях в любой момент, то есть Product backlog может претерпеть корректировки на любом этапе разработки продукта. Данная особенность делает Scrum непригодным для fixed-cost/fixed-time проектов. В нашем случае нельзя заранее предусмотреть изменения, поэтому не нужно заранее планировать все этапы работы. Поэтому используется планирование just-in-timе, при котором определяются действия лишь на ближайший спринт.

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