Как жить, если Бэклог Продукта похож на винегрет

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

Бэклог продукта

Со временем отдельные случаи превратились в паттерн и я осознал: Цель Спринта является одним из индикаторов здоровья Бэклога Продукта, потому что именно она объединяет смыслом элементы Бэклога Продукта и служит основанием для командной работы. Сам Бэклог Продукта ультимативно определяет успех продукта, это генеральный план для Скрам-команды.

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

Продолжение этой статьи »


О роли владельца продукта

Перевод статьи Романа Пихлера The Scrum Product Owner Role on one page.

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


Про аджайл в молодых и старых, больших и маленьких компаниях

Влияние размера компании на аджайл мышление

Сергей Русанов спросил нас:

Может ли аджайл внедряться в только что создаваемые компании? Или только в уже действующие с определенным числом персонала?

Отвечаем:

Продолжение этой статьи »


Модель Спотифай не существует

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

Продолжение этой статьи »


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

Иногда участники команды могут чувствовать себя потерянными в потоке задач. ПО нужны деньги, клиентам нужно решение их проблем. Спринт за спринтом, мы решаем возникающие проблемы, думаем о предстоящем релизе, а поток все не заканчивается. Мы забываем, какое отношение всё это имеет лично к нам: почему мы здесь, зачем? Ах, да, ЗП. Ну вот мы и работаем за две смски об авансе и получке. Грустно.

Эта статья для скрам-мастеров и участников команд. Она о том, как увидеть ценность в повседневной работе. Я рекомендую проводить сессию «Ценность для команды» в начале работы над продуктом, если вы начинаете, или в любое другое время, если вам нужно воскресить мотивацию команды.

Итак, пошаговый план организации сессии «Ценность для команды»:

Продолжение этой статьи »


Как начислять зарплату команде разработки, которая работает по Скраму

Артем Игнатенко спросил нас:

Как пересматривать зарплаты в Dev команде? Учитывая Т-образные компетенции, ставить ценник на каждую компетенцию? И как проводить объективную оценку этой компетентности (аналоги оценок 360 и ИПР для Scrum-команд)?

Отвечаем:

Продолжение этой статьи »


30 лучших книг для Скрам Мастера

Всем привет! В этой статье  я хочу поделиться своим списком лучших тридцати книг для Скрам-мастера. Этот список я высылаю всем участникам сертифицированного тренинга Professional Scrum Master (PSM). Настало время открыть его широкой публике 🙂

Все книги я читал и много применял на практике. Они работают 🙂  Книги покрывают все восемь областей модели компетенций Скрам-мастера, которую разработал Agile Coaching Institute:

Продолжение этой статьи »


3 причины, почему Спринты полезны

Перевод статьи Дэвида Старра «3 reasons to sprint«.

Некоторые команды спрашивают, почему так важно заканчивать работу за Спринт. «Это искусственное ограничение моей работы.» — поясняют они. «Почему мы не можем потратить столько времени, сколько необходимо? Почему всё должно быть готово до завершения Спринта?» По моему опыту, эти разочарованные команды, скорее всего, хотят перейти от плохо внедренного Скрама к катастрофически реализованному Канбану и работе по системе “точно вовремя” (just-in-time).
Использование спринтов дает три преимущества, которых нет в системе “точно вовремя”.
Продолжение этой статьи »


Владелец Продукта — предприниматель

Перевод оригинальной статьи Гюнтера Верхеена https://guntherverheyen.com/about/

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

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


Почему Обзор Спринта больше, чем Демо

Многие люди, практикующие Скрам ошибочно называют Обзор Спринта — “Демо”. Казалось бы, какая разница, если это лишь вопрос терминологии? Тем не менее, Обзор Спринта — самое недооцененное событие Скрама, и многим организациям еще только предстоит в полной мере реализовать его потенциал. “Демо” действительно является очень важной и необходимой его частью Обзора Спринта, но не единственной.

Важно — инспектируем Спринт как событие.

Спринт сам по себе — одно из 5-ти официальных событий Скрама. Обзор Спринта — это не просто демонстрация “Готового” Инкремента продукта, а инспекция прошедшего Спринта, исследование его как эксперимента. В Скраме каждый Спринт — это проект, а сама разработка продукта состоит из большого количества подобных мини-проектов. Каждый Спринт может оказаться последним. Владелец Продукта принимает решение о финансировании очередного Спринта исходя из экономической целесообразности (ROI).

Каждый Спринт может стать последним. Владелец Продукта принимает решение о финансировании очередного Спринта исходя из экономической целесообразности (ROI).

К примеру, формально на Обзоре Спринта могут быть приняты следующие решения:

  • Остановить разработку.
  • Финансировать следующий Спринт.
  • Добавить команду(ы) для увеличения скорость разработки.
  • Изменить состав Команды Разработки.

Продолжение этой статьи »