Scrum-методология: новый способ поднять эффективность команды

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

Что объединяет методологии Scrum, Kanban и Agile

Сегодня многие авторы статей в Сети используют термины методология Agile, Scrum и Kanban то в качестве синонимов, то как независимые понятия, из-за чего возникает путаница.

«Agile» переводится с английского как «быстрый, гибкий, живой, динамичный, маневренный». Зимой 2001 года в американском штате Юта прошла встреча представителей нескольких альтернативных методологий управления проектами. Сразу оговоримся, что методологии считались альтернативными принятой на тот момент классической каскадной модели управления. Цель встречи состояла в разработке и описании единых принципов нового подхода к управлению проектами. Он должен был отвечать современным требованиям, согласовывая усилия по продвижению гибкой методологии.

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

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

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

Иными словами Agile и Scrum – это не две различные методики. Первая является философской концепцией, а вторая – методологией, следующей данной концепции.

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

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

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

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

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

Достоинства и недостатки Scrum-методологии

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

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

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

Безусловно, как и любой подход, Scrum-методология имеет свои минусы. Ее простота и минималистичность сопряжены с некоторыми довольно жесткими правилами. Это противоречит принципу ориентированности на клиента, поскольку потребителей не интересуют внутренние правила команды, особенно когда они его ограничивают. Так, при необходимости и желании клиента Sprintbacklog может быть изменен, хотя это и противоречит правилам методологии Scrum.

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

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

Распределение ролей в Scrum-методологии

Scrum-методология предполагает три роли:

• Scrum Master;
• Product Owner;
• Team.

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

В обязанности Scrum Мастера входят:

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

Scrum Мастер ведет Daily Scrum Meeting и отслеживает продвижение группы при помощи Sprint Backlog, отмечая статус всех задач в спринте. Также он может помогать собственнику проекта создавать Backlog для команды.

Product Owner отвечает за разработку продукта по Scrum-методологии. Обычно это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Именно Product Owner принимает окончательные решения для команды, поэтому данную роль играет один человек, а не группа или комитет.

В его обязанности, согласно Scrum-методологии, входят:

• формирование product vision;
• контроль ROI;
• управление ожиданиями заказчиков, заинтересованных лиц;
• координация и приоритизирование Product backlog;
• представление понятных и тестируемых требований команде;
• взаимодействие с командой и заказчиком;
• приемка кода по завершении итерации.

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

Повторим, что по условиям методологии разработки Scrum команда (Team) должна быть самоорганизующейся и самоуправляемой. Она отвечает перед Product Owner за выполнение определенного объема работ, выделенного на спринт. Ее работа оценивается как деятельность единой группы, то есть во внимание не принимается вклад отдельных членов. Считается, что подобный подход способен негативно отразиться на самоорганизации команды.

Обязанности команды в Scrum:

• оценка элементов баклога;
• принятие решений по дизайну и его воплощению;
• разработка софта и его предоставление заказчику;
• отслеживание собственного продвижения в проекте (вместе со Scrum Мастером);
• ответственность за результат перед Product Owner.

Размер команды в методологии Scrum зависит от того, сколько людей способно непрерывно эффективно взаимодействовать друг с другом. Обычно в данной методологии речь идет о 7 специалистах +/- 2.

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

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

Scrum-методология на практике

Итак, Product Owner сформулировал цель в виде некого пункта B, его нужно достичь, начав движение из пункта A. Однако, в отличие от математической задачи, пункт B – это не точка, в которую можно попасть, нарисовав прямую между В и А. В случае со Scrum-методологией, пункт B представляет собой окрестность точки, чей радиус может варьироваться.

1. Scrum-спринт.

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

2. Как формируется список задач на спринт.

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

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

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

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




Известна фраза: «Умножьте время, которые назвал вам разработчик, на 2, прибавьте еще немного и получите срок, через который вы получите результат». Причем такая система расчета работает.

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

3. Как убедиться, что выполнено требование Product Owner’а.

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

Scrum-методология требует использования очень подробных тестов.

4. Что происходит во время спринта.

Главная цель спринта состоит в выполнении описанных выше тестов.

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

5. Scrum-митинг.

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

Во время митингов участники проекта не садятся, все действие занимает 15 минут. Многие фирмы проводят митинги в начале рабочего дня – в 9 утра.

6. Что происходит в финале спринта.

Обычно завершение спринта приходится на пятницу в 16:00. В это время команда сдает проделанную работу Product Owner’у и всем заинтересованным лицам. Каждый участник рассказывает, что он сделал и каких успехов достиг, объясняет причины, которые помешали добиться цели. Главное в Scrum-методологии: время сдачи спринта никогда не переносится.

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

Ошибки при переходе на Scrum-методологию и способы их избежать

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

Ошибка № 1. Слишком большое количество незавершенных задач.

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

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

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

Совет: соблюдайте предписание Lean: «Бросьте начинать и начните заканчивать». Занимайтесь единовременно лишь одной задачей, закончите ее и после этого переходите к следующей. Если в процессе работы вы из-за внешних факторов вынуждены ждать, помогите другим членам команды решить их задачи.

Ошибка № 2. Поведенческий менеджмент.

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

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

Ошибка № 3. Движение без цели.

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

Совет: методология требует, чтобы цель отвечала таким характеристикам, как понятность, доступность, обсуждаемость и измеряемость. Откажитесь от выражений, вроде: «Исправить все баги…», «Завершить все истории…». У цели спринта обязательно должны быть бизнес-ценность и различные пути достижения. Далее команда специалистов сама решает, как сделать так, чтобы выбранные на спринте элементы бэклога продукта стали инкрементом.

Ошибка № 4. Не единоличное, а командное решение.

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

Совет: будьте терпеливы, дайте членам рабочей группы возможность брать на себя ответственность, если вы действительно хотите пользоваться Scrum-методологией. И правда, на это может уйти больше времени, чем хотелось бы. Обычно ситуация складывается таким образом, если специалисты никогда раньше не принимали подобных решений. Но работники так и не научатся брать ответственность на себя, если вы не дадите им такой возможности. А значит, нельзя и говорить о должном уровне их мотивации.

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

Ошибка № 5. 100%-ный фокус на эффективность работы.

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

Совет: членам команды тоже не обойтись без поля для маневров – им требуется время, пространство, чтобы думать, учиться, мыслить. Без определенной гибкости в работе вы вряд ли добьетесь желаемого уровня эффективности даже при использовании данной методологии.

Ошибка № 6. Полная централизация.

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

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

Ошибка № 7. Низкая степень визуализации.

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

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

Ошибка № 8. Отсутствие мероприятий в команде.

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

Совет: не отказывайтесь от мероприятий, позволяющих объединить специалистов в настоящую команду.

Ошибка № 9. Страх ошибки.

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

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

Ошибка № 10. Упустили из внимания качество.

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

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