Какие проекты стоит делать по Scrum | Бизнес-школа Laba (Лаба)
Для отслеживания статуса заказа — авторизируйтесь
Введите код, который был выслан на почту Введите код с SMS, который был выслан на номер
anastasiiasytar@gmail.com
Код действителен в течение 5 минут Код с sms действителен в течение 5 минут
Вы уверены, что хотите выйти?
Сеанс завершен
На главную

Поиск

Содержание

Какие проекты стоит делать по Scrum, а какие — нет

Program Manager в Luxoft — о том, почему фреймворк подходит не для всех.

cover-kravchenko-6113ce7b9f897128513809.jpg

Елена Кравченко работает в сфере управления проектами 14 лет. Она руководила отделом продуктовой разработки в lifecell Ukraine. Управляла проектами полного цикла веб- и мобильной разработки в Peppermint Int и ADV Group, где клиентами были Kyivstar, Unilever, PepsiCo, Ferrero, Mary Kay и Danone.

Сейчас Елена работает Program Manager в DXC Luxoft, и скоро в Laba стартует ее курс о Scrum. Нам она рассказала, в чем специфика работы по Scrum и в каких проектах лучше выбрать другой подход. 

Какие проекты стоит реализовывать по Scrum, а какие — нет

Scrum — фреймворк, который подходит для работы над проектами с высокой степенью неопределенности. 

Scrum будет полезен, когда мы точно не знаем: 

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

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

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

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

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

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

В чем заключается работа по Scrum

Прежде чем проводить первые митинги и наполнять бэклог, убедитесь, что в будущей работе команда будет опираться на «столпы» и принципы Scrum:

  • Прозрачность — работа, которая выполняется, видна всем стейкхолдерам. Процесс тоже должен быть известен и понятен каждому. Прозрачность дает возможность для инспекции.
  • Инспекция — регулярная проверка артефактов, уточнение, в правильном ли направлении мы движемся.
  • Адаптация — изменение курса на основе обратной связи, полученной в процессе инспекции.

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

Scrum Team придерживается таких ценностей:

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

Эти ценности — «протокол» поведения и принятия решений Scrum Team. Без ориентира на них команда не сможет работать с фреймворком эффективно. Это будет набор встреч без ожидаемого результата. 

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

Как планировать спринты

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

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

Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!

Участники обсуждают наиболее важные элементы бэклога и их значение для цели продукта (Product Goal). А именно:

  • Какую ценность принесет этот спринт?
  • Что может быть готово в этом спринте?
  • Как будут выполнены выбранные задачи?

Событие Sprint Planning инициирует спринт, и эта встреча ограничена по времени. Для спринта длительностью 1 месяц планирование занимает до 8 часов, для более коротких обычно нужно меньше времени.

Как измерять результаты работы команды

Основная метрика для измерения скорости работы команды — velocity. Она позволяет строить прогнозы по объему задач в бэклоге и планировать релизы. 

Задачи оцениваются в стори-поинтах — это абстрактная единица измерения количества усилий, которые нужно приложить команде для выполнения задачи из бэклога. Есть разные техники для оценки — например, Planning Poker, и мы научимся использовать их на курсе. 

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

Как распределяются роли в команде

В Scrum Team входят три роли: Product Owner, Scrum Master и Developers. При этом в проекте могут быть менеджеры, архитекторы, аналитики и другие специалисты, которые взаимодействуют co Scrum Team, но не являются ее частью. 

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

Scrum Master — самая многогранная роль. Он отвечает за применение Scrum в команде, а также за эффективность Scrum Team. Scrum Master — фасилитатор, лидер, ментор, коуч. Есть распространенное мнение, что быть скрам-мастером — просто: проводишь «дейли», ретроспективы и заказываешь пиццу для команды. Но это не так: нужно иметь лидерские качества, разбираться в процессе разработки продукта, стать источником знаний об Agile, уметь и хотеть мотивировать, направлять, обучать. 

Developers — люди, которые отвечают за создание части инкремента спринта. Определенный набор навыков зависит от требований продукта. Основная зона ответственности Developers — формирование бэклога для спринта (Sprint Backlog), стремление к качеству, взаимная поддержка, ответственность за общий результат, ежедневная инспекция и адаптация для достижения Sprint Goal.

Рекомендуем почитать:

img.pmscrum-6075a35d7dfb7433135638.jpg

Scrum Master или Project Manager: кто нужен вашей команде

Читать

Работать над проектами внутри компании или на аутсорс — в чем отличие

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

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

Какие ошибки чаще всего совершают в работе по Scrum

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

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

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

#3. Не анализируют и не фиксируют шаги для улучшения на следующих спринтах, которые определили на ретроспективе.

#4. Не заботятся о том, чтобы вся команда разделяла видение продукта — зачем он создается и в чем его суть.

Хотите получать дайджест статей?

Одно письмо с лучшими материалами за неделю. Подписывайтесь, чтобы ничего не упустить.
Спасибо за подписку!
Курс по теме:
«Продакт-менеджмент»
Бизнес и управление
Ведет Александр Емельянов
Александр Емельянов