Продолжаем цикл постов про Story Points (SP). Сегодня разберем более подробно, что это такое SP и какие преимущества получает команда, когда их использует.
Представим, что нам необходимо выкопать яму размером 3 кубических метра. Если у нас есть детская лопатка, то эту яму один человек выкопает за 7 дней. Однако, если у него есть качественные штыковая и совковая лопаты, то это можно сделать за 3 дня. Если над задачей будет работать параллельно 3 человека, то яму удастся выкопать менее, чем за день. В случае, если будет привлечен экскаватор, то потребуется около часа, чтобы выполнить задачу. Как вы видите, время выполнения задачи варьируется в зависимости от имеющихся инструментов, количества людей, их физической подготовки и многих других факторов. Однако размер ямы не зависит от всех этих параметров.
Story Points позволяют установить размер самой задачи (так же, как кубические метры используются для определения размера ямы). Ее размер не зависит от того, сколько человек будет работать над ней, и какой у них опыт.
SP - относительная оценка. Само числовое значение не столь важно - важен относительный размер задачи в сравнении с другими. Каждый раз, когда необходимо дать оценку той или иной задачи, необходимо сравнить ее с остальными: больше или меньше она относительно похожих задач? Сложнее или легче? Выше или ниже неопределенность по задаче?
В чем преимущества использования SP?
1. В силу абстрактности оценки появляется буфер времени внутри спринта, что позволяет команде быть более гибкой. 2. Команда избегает локальной оптимизации каждого отдельного сотрудника, что также повышает гибкость команды в целом. 3. В оценке задачу принимает участие вся команда, что позволяет выявить большее число кейсов и рисков, тем самым снижается вариативность задачи. 4. В процессе оценки задачи члены команды общаются друг с другом, что позитивно влияет на кросс-функциональность.
В ближайшее время поделюсь алгоритмом, который поможет команде перейти к оценке в SP.
P.S. - Story Points не являются обязательным инструментом для оценки элементов бэклога продукта в Scrum. Если команде удобно оценивать в часах и это успешно работает - не стоит навязывать данный способ команде.
Майкл Кон опубликовал отличное видео по одной из самых холиварных тем - оценка задач в story points. В нем он системно рассказывает: как их использовать, что они в себя включают, и какие преимущества дают.
В общем случае SP включает сложность, объем и риски. Другими словами, SP = f(объем, сложность, риски).
Более того, само числовое значение вообще не важно - важен относительный размер историй. Каждый раз при определении размера истории, команде необходимо сравнить ее с другими историями, которые она уже делала и определить ее размер.
В следующем посте я расскажу о преимуществах оценки в SP, а также о том, как помочь команде понять и принять их.
Очень большая проблема в области гибких подходов к разработке - неверное толкование представителями бизнеса agile манифеста.
Довольно часто происходит ситуация, когда в силу несовершенства процессов со стороны бизнеса, команда вынуждена регулярно брать в спринт срочные задачи, что разрушает фокус на бэклоге спринта.
Далее при разборе данных кейсов бизнес начинает манипулировать одним из принципов Agile: "Изменение требований приветствуется, даже на поздних стадиях разработки." "Вы же гибкие" - говорят они команде - "Вы должны адаптироваться. Это жизнь."
К сожалению при таких утверждениях они не только упускают из вида 11 других принципов, но также зачастую не осознают реальную стоимость таких срочных задач.
Для объяснения последствий подобного паттерна я использую CLD (см. ниже).
Напомню легенду: 1. Прямая стрелка - прямая зависимость (т.е. чем выше мотивация команды, тем выше скорость команды). 2. Обратная зависимость (стрелка с кругом) означает обратную зависимость переменных, т.е. чем выше скорость команды (team velocity) тем ниже time to market (T2M) или чем выше стресс команды разработки тем ниже мотивация команды. 3. Стрелка с подписью QF - сиюминутное решение, quick fix.
Если кратко: любое пропихивание дополнительных задач в спринт приводит к разрушению фокуса и системному снижению скорости работы команды, а также ее мотивации.
Команда сказала, что ее получилось качественно релизовать потому что: 1. Было интересно 2. Не было людей вокруг (был фокус) 3. Были понятны перспективы развития продукта 4. Выделиться на фоне других команд
Хочу поделиться с вами отличным форматом ретро, который позволяет команде самой проанализировать качество реализуемого функционала и найти пути улучшения ситуации.
Особенно интересно узнать факторы, которые позволили реализовать историю максимально качественно.
Если вы хотите повысить производительность команды, то прежде всего стоит обратить внимание на пять основных препятствий на пути доставки ценности (автор - Márcio Sete):
1. Зависимости 2. Слишком высокий WIP 3. Низкий уровень профессионализма команды и кросс-функциональности (team liquidity) 4. Ручная и рутинная работа 5. Блокеры
Исходя из этого, советы достаточно очевидны: устраняйте зависимости, сокращайте количество задач над которыми команда работает параллельно, повышайте профессионализм и взаимозаменяемость членов команды, автоматизируйте рутину и боритесь с блокерами.
Лично я являюсь сторонником открытых зарплат, поскольку, на мой взгляд, это важный инструмент саморегуляции команды и крайне необходимый компонент радикальной прозрачности.
Однако, открытие зарплат должно быть совмещено с перемещением ответственности за бюджет продукта на уровень команды. Иначе существует риск перейти к необоснованно завышенным зарплатам.
К сожалению, пока это только мысли, без реальной практики. Но направление движение кажется правильным...
Предлагаю послушать Александра Горника (генеральный директор Mindbox) о том, как они пришли к открытым зарплатам, и как устроена вся эта система у них.
Рассказ о том, к чему мы пришли за десять лет развития Agile культуры, пока росли с 5-ти человек до 70. Акцент на практике и ответе на вопрос «как»: -живем с...
Отличный материал о том, почему на встречах важно разговаривать, а не пялиться в экран и слушать докладчика (PO). Крупные и передовые корпорации это прекрасно понимают.
Вот почему привычный формат презентаций не эффективен:
1. Наш мозг в процессе эволюции приспособился эффективно воспринимать истории: наши предки на протяжении нескольких тысяч лет ежедневно собирались вокруг костра, чтобы согреться и дабы не скучать обменивались новостями и рассказами.
2. Аристотель утверждал, что убедительный рассказ включает три важных компонента: авторитет рассказчика, логичность и эмоциональность. Часто презентации - это скучное зачитывание текста со слайда (задачки из Jira). Исследователи мозга уверены, что эмоции - самый быстрый способ "достучаться" до мозга. Рассказ наполненный эмоциями быстрее запомнится и дольше будет оставаться в памяти.
В этом контексте пользовательские истории становятся еще более эффективным форматом записи требований. Они не просто постулируют, что нужно делать - они задают реальную ситуацию, кейс, они передают эмоции, боль пользователя или бизнес заказчика. Все это формирует объемное представление о задаче и стимулирует наш мозг к работе.
Илья Павличенко (первый PST в России) составил список мастридов для Скрам-Мастеров:
1. Agile Project Management With Scrum 2. The Professional ScrumMaster’s Handbook 3. The Scrum Field Guide 4. The Great ScrumMaster 5. Coaching Agile Teams 6. Scrum Mastery
Лично для меня наиболее интересными и полезными показались Коучинг Agile команд и Scrum Mastery.
Многие руководители, Скрам Мастера, Владельцы Продуктов да и сами команды часто задаются вопросом, как можно измерить эффективность работы команды в Scrum.
Согласитесь, что оценивать производительность команды в Story Points - не самая лучшая идея, в силу абстрактности данного показателя. Да и команда может делать очень много и быть максимально производительной, но не поставлять реальной ценности пользователю.
Лучший набор метрик, который я видел, предлагает Evidence-Based Management. Он фокусируется на трех основных областях:
- Current Value - Time to Market - Ability to Innovate
Предлагаемые метрики (см. фото) предоставляют полноценную информацию относительно гибкости команды, ее инновационного потенциала и успехов в донесении ценности в текущий момент. Данные компоненты наиболее точным образом характеризуют эффективность работы команды в запутанной среде (по модели Cynefin).
В книге "Командный подход" нашел очень крутое определение команды:
"Команда - это малочисленная группа людей со взаимодополняемыми навыками, приверженных общим миссии, целям и подходу к делу, за реализацию которых они несут коллективную ответственность"
Оно включает все ключевые элементы, необходимые для построения высокоэффективной команды.
Исходя из этого формулируется алгоритм быстрого аудита команды:
1. Действительно ли численность группы небольшая? 2. Адекватен ли уровень взаимодополняемых навыков (профессиональные, навыки решения проблем и принятия решений, навыки межличностного взаимодействия)? 3. Есть ли у группы значимая цель, к которой стремятся все сотрудники? 4. Определен ли ряд конечных результатов, согласованный со всеми члена группы? 5. Все ли сотрудники хорошо понимают общий подход к делу и согласны с ним? 6. Существует ли в группе индивидуальная и коллективная ответственность за результаты?
Очень часто команды, владелец продукта и руководство не видят всей системной картины и не всегда понимают, к чему могут привести их сиюминутные решения.
Очень эффективный инструмент для демонстрации взаимосвязей - CLD подробнее. Диаграмма показывает, как разные переменные связаны друг с другом.
Рассмотрим на примере скорости команды (team velocity).
Как читать диаграмму:
1. Прямая стрелка - прямая зависимость (т.е. чем выше профессиональный уровень команды, тем выше скорость команды).
2. Обратная зависимость (стрелка с кругом) означает обратную зависимость переменных, т.е. чем выше скорость команды (team velocity) тем ниже time to market (T2M) или чем меньше количество препятствий - тем выше скорость команды.
3. Стрелка с подписью QF - сиюминутное решение, quick fix.
Используя приведенную ниже диаграмму можно показать руководству или владельцу продукта, какие побочные эффекты несет за собой давление на команду и как это в итоге негативно влияет на ее скорость (увеличение объема техдолга, снижение мотивации профессионалов и др.). Также здесь видно, что нужно делать, чтобы скорость команды системно росла: инвестировать в инфраструктуру, уделять внимание постановке амбиционных и мотивирующих целей, создавать комфортные условия труда, повышать качество отбора персонала.
CLD - отличный фасилитационный инструмент. Он позволяет не только пояснить вашу модель мышления, но и понять, как мыслит ваш собеседник и видит ли он взаимосвязь между разными параметрами системы. Будьте готовы, что ваша модель мышления не совсем верна и вам благодаря этому инструменту покажут, в чем вы не правы.