Scrum и Agile, как способ избавления от бюрократии и повышения эффективности команды

В чем риски стандартного подхода к разработке продуктов

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

Такой подход разработки продуктов получил название «Стратегия большого взрыва» — обратной связи от заказчика нет до окончания проекта. Вот некоторые риски, которые можно встретить при таком подходе:

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

 Agile, как способ минимизировать бюрократию

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

В 2001 году был выпущен «Манифест гибкой разработки ПО», состоящий из 12 принципов. С этой даты и берет свое начало существование такой методологии (или даже философии) как Agile (дословно – «гибкий»). В её основе лежит метод итераций – повторений определенных элементов работы внутри коллектива. Коллектив оформляется в команду, состоящую из планировщиков, разработчиков, дизайнеров, тестировщиков. Все эти люди на протяжении всего проекта работают вместе, постоянно обсуждают полученный результат и каждый день задают себе два вопроса:

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

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

Agile – это философия, а что же такое Scrum?

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

Все начинается с владельца продукта. Он определяет основных заинтересованных лиц (клиентов, заказчиков), работает с командой, в его задачи также входит определение приоритетов и создание бэклога продукта (списка задач, которые необходимо реализовать). Также в команде присутствует scrum-мастер. Он помогает команде вести работу над проектом, направляет ее, следит за правильным выполнением структуры работы и в целом, его работа похожа на кураторство.

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

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

Секреты эффективного использования

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

1. Усложнение. Бывает так, что Scrum подход не будет самым простым и эффективным из доступных, и в таком случае его применение лишь замедлит разработку.
2. Ежедневный scrum. Благодаря встречам каждый участник может понять, в какую сторону движется команда, какие задачи необходимо решить сегодня, и какие вопросы требуют ответа. Не будет встреч – эффективность метода очень сильно снизится.
3. Ретроспектива. После каждого из спринтов команде необходимо собираться вместе и оценивать успехи за прошлую неделю. В scrum очень важна обратная связь и регулярный мониторинг успехов, именно это и дает методологии такую гибкость. Важно вовремя заметить возможные проблемы, требующие исправления, чтобы следующий спринт прошел гладко.

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

Когда и так все понятно, зачем усложнять?

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

Комментарии 0