Scrum революционный метод управления проектами: как это работает

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

В связи с этим возникает необходимость в пояснении значения этого термина.

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

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

Историческая справка

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

Компьютеризация производств позволила автоматизировать и упростить ведение бизнеса.

Однако внедрение техники в бизнес требовало специализированного программного обеспечения.

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

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

После образовался основанный на принципах Agile Scrum – его понимали все, кто пользовался, потому как всё просто.

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

• базовых идей Agile;
• подробностей текущего проекта.

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

Что это такое

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

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

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

И это касается любого из этапов проекта.

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

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

Строитель может быстро заложить фундамент и, получив оплату, исчезнуть. А гарантирует ли он, что дом на этом фундаменте будет стоять как надо и вообще будет возведён?

В Scrum, ради повышения управляемости, контроля и предсказуемости выполнения проекта тратится от четверти до половины потенциала команды.

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

Кто есть кто

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

• Product Owner;
• Development Team или Scrum Team;
• Scrum Master.

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

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

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

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

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

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

Development Team – разработчики, специалисты каждый в своей области, умеющие работать в коллективе.

Именно они трудятся над получением результата.

Согласно официальной документации (документу, где описана методология его непосредственными авторами), группа исполнителей обязана выполнять следующие требования или максимально стремиться к этому:

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

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

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

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

Как выглядит рабочий процесс

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

Начнём из спринта (Sprint) – это временной интервал, данный команде для внедрения в жизнь указанного перечня заданий.

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

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

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

Backlog – список всех работ, общий ежедневник и отчёт. Их может быть несколько для разных этапов разработки.

Бэклогов различают пару типов:

• Product Backlog – полный перечень заданий с их приоритетностью, выполнение которых позволит получить необходимый результат по окончании работы;
• Sprint Backlog – перечень заданий, определённый командой и согласованный с заказчиком (владельцем) или же предложенный им в одностороннем порядке, которые следует реализовать в ближайшее время (спринт). Они берутся из Product B

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

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

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

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

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

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

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

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

На них каждый из работников отчитывается перед сотрудниками и/или руководителем проекта о:

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

Цель ежедневных собраний (летучек):

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

В завершение спринта проводятся так называемые Sprint Retrospective и Sprint Review .

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