Елена Кравченко работает в сфере управления проектами 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.
Работать над проектами внутри компании или на аутсорс — в чем отличие
Главное отличие — в доступности информации о продукте, планах клиента и в скорости обратной связи. На аутсорсе заказчик часто бывает недоступен, к нему сложно достучаться. Или он не дает команде полной информации о продукте.
Это способно повлиять на мотивацию и эффективность Scrum Team. Но преимущество аутсорса — возможность поработать с разными клиентами и на разных рынках. Это позволяет получить более объемный, разнообразный опыт, прокачать навык инспекции и адаптации до небес.
Какие ошибки чаще всего совершают в работе по Scrum
#1. Не опираются на принципы и ценности Agile, игнорируют принципы Scrum — работают только с процессной частью фреймворка. Например, когда в команде нет открытости и коллеги неохотно делятся информацией — тогда у каждого накапливается свой субъективный опыт.
#2. Не проводят ретроспективы — один из важнейших ивентов по Scrum. Это встреча, на которой команда обсуждает, как прошел спринт. На ретроспективе мы можем отпраздновать успехи, открыто и конструктивно обсудить неудачи, вместе найти решение, обменяться идеями по улучшению чего угодно, обозначить проблемы и определить дальнейшие шаги.
Тут мы можем проверить, какого прогресса достигли с предыдущей ретроспективы, какие из намеченных улучшений удалось реализовать. Если игнорировать эти встречи, мы потеряем возможность планировать повышение качества и эффективности.
#3. Не анализируют и не фиксируют шаги для улучшения на следующих спринтах, которые определили на ретроспективе.
#4. Не заботятся о том, чтобы вся команда разделяла видение продукта — зачем он создается и в чем его суть.
Хотите получать дайджест статей?
