Scrum в IT и не только

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

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

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

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

Разработка ведется спринтами. Спринт — это достаточно короткий период времени (обычно длиной от 2 до 4 недель), в течение которого scrum-команда выполняет заданный объем работы.

Материальным представлением работы или ценности в Scrum являются артефакты:

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

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

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

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

Скрам предписывает четыре формальных мероприятия:

• Планирование спринта — собрание проводит и модерирует скрам-мастер при формировании спринта,
  
  
• Ежедневный скрам (стендап) — ежедневный митинг/совещание для скрам-команды, оценка результатов за прошедшие сутки и составление плана на следующий день,
  
  
• Обзор спринта — проводится в конце каждого спринта для того, чтобы все его участники поняли, что было сделано на этом этапе,
  
  
• Ретроспектива спринта — проводится между обзором завершенного спринта и планированием следующего. На ней определяются те задачи, которые нужно будет взять в доработку в следующем спринте.
  
  

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

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

Контракты с фиксированной стоимостью и жесткими требованиями часто встречаются вне IT. Можно, конечно, даже построить дом по Scrum, но мало кому подобный опыт понравится — в здании по факту может оказаться на пару этажей больше, чем по проекту, а Госприемка займет несколько лет.

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

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

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

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

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

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

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

Результаты, которые показывает Scrum в IT-разработке, столь впечатляющи, что порой его воспринимают в качестве «волшебной пилюли», которую стоит применять везде и всегда. Но любой инструмент, если использовать его не по назначению, может оказаться бесполезен, а порой и просто вреден.

• Самый яркий пример относится к отрасли, в которой он и зародился — к IT, а точнее к маркетингу в ней. При разработке MVP продукта Scrum имеет все шансы навредить: можно бесконечно добавлять новые функции, прорабатывать бэклог и… так и не запуститься. Гораздо эффективнее реализовать MVP по водопадной модели, выкатить релиз, а вот дальнейшее развитие проекта вести по Scrum.

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

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

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