Разработка ПО по методикам SCRUM и Критическая цепь: различия и общие черты

Картинки по запросу scrum что этоScrum – методология гибкой разработки ПО. Методология делает акцент на качественном контроле процесса разработки. Кроме управления проектами по разработке ПО, Scrum может также использоваться в работе команд поддержки программного обеспечения, или как подход к управлению разработкой и сопровождению программ: Scrum of Scrums. Долгое время я воспринимал scrum как инструмент для использования в разработке программного обеспечения. Наиболее яркой чертой метода для меня являлось то, что он позволяет выполнять проекты с неопределенным содержанием конечного результата.

Похожее изображение

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

Но все-таки условия использования – это важное, но не главное. К каким главным изменениям в организации труда приходят CCPM (Critical Chain Project Management, метод критической цепи) и scrum? В условиях известного конечного результата (CCPM) гибкость нам нужна только для преодоления неопределенностей в исполнении и в наличие ресурсов, возникающих в ходе выполнения. С ними нам отлично помогает справиться буфер времени (вся подстраховка для критической цепи, агрегированная в одном месте) и система приоритетов на его основе. Задачи известны и определены. Система приоритетов прозрачна. Каждый в любой момент знает, что ему делать. У менеджера задач есть список задач, он уделяет особое внимание задачам в «красном», при необходимости перераспределяет ресурсы и это его ответственность. А еще он выдает инструкции, как именно выполнять ту или иную задачу. Ведь задача в критической цепи – это набор работ. У одной задачи может быть несколько исполнителей. То есть ролью менеджера является координация усилий разных ресурсов.

При определении критической цепи, на этапе планирования, встает вопрос определения длительности задач. Необходимо ее определить, удалив из длительности всю обычную подстраховку, которую привыкли закладывать подчиненные. Считается, что конечная длительность задачи должна составлять половину от обычной длительности. Урезать отведенное на выполнение время наполовину может оказаться трудной задачей с психологической точки зрения. Затем на этапе исполнения менеджеру, с одной стороны, не нужно давить на подчиненного относительно скорости выполнения работы, с другой стороны, каждый день оценивать какое время осталось до завершения задачи. Давит или не давит менеджер на подчиненного – можно узнать только у самого подчиненного. Тут лучше даже задать другой вопрос: ощущает ли подчиненный давление со стороны менеджера? И такое ощущение (со всеми вытекающими последствиями) вполне может быть, даже если давления как такового нет. Получается, что мы являемся заложниками того, как ведет себя менеджер и того, как ощущает поведение менеджера подчиненный. Тонкая материя, однако…

Картинки по запросу scrum ПО РУССКИ

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

Задачи в спринте вообще не оцениваются во времени, они оцениваются в «стори поинтах» (относительных единицах). Команда способна сделать за время спринта определенное количество этих самых поинтов (величина определяется экспериментально). «Вес» задачи в поинтах определяется экспертным голосованием. В этом процессе нет руководителя, который потом будет спрашивать за выполнение обязательств. То есть вопроса закладки в длительность задачи подстраховки по времени не встает вообще. Да, в определении веса каждой задачи возможна ошибка. Но нас интересует не вес одной задачи, а вес всего спринта. Ошибка на одной задаче компенсируется ошибкой в другую сторону на другой задаче. То есть в scrum также заложен эффект агрегации, несмотря на то, что у нас нет буфера!

Что происходит дальше? Команда проекта каждый день проводит scrum митинг в течение 15 минут. Обсуждается три вопроса:

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

Если тебе что-то мешает, тебе тут же помогут или решат, как помочь. За то, чтобы на эти вопросы были получены ответы, отвечает scrum master, который не является формальным руководителем. Он такой же, как все. Иерархии в команде нет. Каждый отвечает перед остальными членами команды. Члены команды – такие же, как и ты. Нет никакой субординации.

Похожее изображение

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

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

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

Картинки по запросу scrum ПО РУССКИ

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

Справка:

В настоящее время, 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’е, спрогнозировать ожидаемую эффективность (производительность) в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.

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

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

Часто можно услышать, что 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)

Автор: Виктор Вальчук

Источник: http://tocpeople.com/

Похожее изображение

Понравилась статья? Тогда поддержите нас, поделитесь с друзьями и заглядывайте по рекламным ссылкам!