Говорим о работе, делимся советами, разбираем ошибки

Подводные камни Scrum-проектов



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

Что такое Scrum?

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

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

Как это делается?


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

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

Каждый рабочий день в течение спринта начинается с короткой, в идеале 15-минутной, планерки (ежедневный Scrum). Участники команды рассказывают, что они сделали вчера, что планируют выполнить сегодня, какие сложности встают у них на пути. Таким образом, исполнители постоянно отслеживают и оценивают прогресс реализации задач спринта и попутно решают возникающие проблемы. В этом, если брать классический Scrum, им помогает Sprint Backlog – доска задач, наглядно показывающая процесс выполнения спринта.

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

В чем проблема?

Понятно, что Scrum – не инструкция по работе над тем или иным конкретным проектом. Это только форма, в которую каждая компания и каждая команда вносит своё содержание, сталкиваясь с разными подводными камнями методики по ходу ее внедрения. Очень многое зависит от области применения Scrum: если для ИТ-разработчиков гибкие методологии – это уже что-то хорошо знакомое и привычное, то остальные направления (маркетинг, пиар, консалтинг, производство) только начинают осваивать методику, хотя отдельные ее элементы применяют в своей повседневной деятельности уже очень давно. Итак, рассмотрим основные сложности, возникающие при реализации Scrum-проектов.

Заключение договоров

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

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

«На самом деле в проекте по разработке заказного программного обеспечения не бывает ситуаций с нефиксированным бюджетом, – добавляет генеральный директор First Line Software Александр Поздняков. – Возможно, исполнитель не знает точно, какой бюджет клиент заложил на проект, но заказчик – знает всегда. Что касается договоров, то с моей точки зрения, нет особой сложности в том, чтобы описать юридическим языком работу между контрагентами по Scrum. Компании, работающие в ИТ-сервисной сфере, давно разработали вариант контракта, который это предусматривает».

Scrum не работает

Иногда компании, решившие внедрить у себя Scrum, быстро в нем разочаровываются – эффективность не повышается, сотрудники противятся нововведениям и вообще начинается хаос. Это совсем не тот результат, который ждут от методики. В каких случаях «Scrum не работает», и как этого избежать?

«Действительно, при внедрении новой методологии могут возникнуть сложности. Это нормально, и здесь важно просто продолжать действовать, – считает Александр Поздняков. – Дело в том, что Scrum – это не просто методология. Это ещё и определённый образ мышления, который надо привить команде. Довольно часто происходит путаница: есть компании или группы людей, которые используют только часть практик и называют это Scrum. На самом деле это не Scrum – это просто часть практик. А когда у них не получается достичь ожидаемых результатов, разочарование зачастую "прилипает" к Scrum незаслуженно. Еще раз повторю: нельзя быть "немножко Scrum", нужно использовать эту методологию в целом».

«Первая причина разочарования связана с глобальным заблуждением о "частичном" Scrum, – соглашается Александр Горник. – Нельзя внедрить Scrum только в одной команде или отдельно взятом подразделении. Подход, который пропагандирует эта методика, требует, чтобы вся компания была гибкой, чтобы даже заказчики ставили задачи, формировали собственные ожидания определенным образом. Если компания готова меняться полностью, то Scrum очень эффективен. Возможно, при внедрении вам придется пережить сложный период спада эффективности, но за ним обязательно наступит момент роста. Мы начали внедрять методику еще в 2008 году и до сих пор постоянно что-то меняем, постоянно улучшаем свою работу. В этом, собственно, суть Scrum».

Не получается создать команду


Пожалуй, главное в методике Scrum – создать эффективную команду. Ее участники должны быть квалифицированы, самостоятельны, взаимозаменяемы, иначе проекты будут постоянно буксовать. Считается, что при низком профессионализме или «инфантильности» команды методология не заработает. Как сформировать эффективную Scrum-команду?

«Профессионалов всегда сложно найти, - говорит Александр Горник. – Проблема компетентной Scrum-команды решается только одним образом: необходимо параллельно внедрению современных процессов делать компанию более привлекательной для сотрудников и, соответственно, нанимать более сильный персонал. В методике Scrum для ИТ есть такая роль – scrum-мастер или agile-coach, ведущий разработчик. Хорошо, когда именно этот человек просматривает отклики по вакансии разработчиков и собеседует людей вместе с другими участниками команды. Решение о найме должно принимается коллегиально. Так происходит у нас в Mindbox и это помогает избежать трудностей адаптации к нашей системе работы. Вообще, при работе по Scrum у сотрудников появляется больше ответственности, больше автономии. Весь смысл внедрения таких методов сводится к отказу от начальников. Мы не хотим иметь в компании начальников, которые раздают задачи, решают, кто с кем должен работать и прочее. Мы отдаем полномочия как можно ниже, туда, где людям наиболее видна суть задачи».

«Люди иногда уходят в отпуск, иногда болеют. Команда должна быть готова к таким сложностям, – добавляет Александр Поздняков. – Именно в этом и есть главное отличие Scrum от других методик: команда мобилизуется для решения проблемы как единое целое и как единое целое несет ответственность за результат. К примеру, есть три вопроса, на которые каждый участник команды отвечает на ежедневном стендапе: "Что я сделал?", "Что я сделаю?", "Какие у меня проблемы?" Здесь часто забывают об одной маленькой, но важной детали – эти вопросы должны задаваться с позиции команды: "А что я сделал, чтобы у команды всё получилось?", "Какие, с моей точки зрения, проблемы у команды?", "И как я могу помочь их решить?". Это просто критически всё меняет. В Scrum думать нужно не о себе, а о команде – тогда все пойдет на лад».

***

Кстати, Scrum – это не аббревиатура. Сам термин обозначает горячую схватку вокруг мяча в регби. Более того, технология использует методы из самых разных, порой неожиданных, областей знаний, например, из айкидо или военных интеллектуальных разработок. Почитать об этом подробнее можно в книге создателя методики Джеффа Сазерленда «Scrum. Революционный метод управления проектами». А если вы собираетесь внедрить или повысить эффективность Scrum в своей компании, то рекомендуем своего рода инструкцию по применению «Scrum и XP: заметки с передовой» от шведского agile-консультанта Хенрика Книберга. Удачи!

Заметки с передовой
Революционный метод

Текст: Арина Буковская
Изображение: Jason Carter, Flickr.com, CC BY 2.0

Лучшие статьи по теме

Комментарии