Как руководитель программы может оценить элементы слишком рано, чтобы их можно было оценить
29 марта 2023 г.Как руководитель программы я должен способствовать оценке товаров, которые слишком рано оценивать, почти во всех компаниях, с которыми я работаю.
Зачем это нужно?
Не будем себя обманывать; оценки необходимы в современном деловом мире, особенно когда вы выпускаете свою первую версию сложного продукта и вовремя находите правильный продукт/рынок. Конечно, вы можете возразить, что современный Agile-метод не работает со сроками, но я хочу остановить вас здесь и сказать, что это неверно.
Вы по-прежнему можете выполнять спринт за спринтом, но для первого выпуска продукта для клиентов в сложной бизнес-ситуации, в которой мы живем и работаем, требуется крайний срок для планирования всех действий, связанных с выпуском продукта.
Установите сцену
Определения проблемы:
* Оценка в очень сложной среде всегда неверна. Чем продолжительнее период, тем значительнее погрешность. * Часто кто-то другой оценивает инженерную работу, основываясь на интуиции и неправильном уровне детализации. * Мы не знаем того, чего не знаем, но когда мы знаем то, чего не знали, мы ничего не делаем со знанием.
Давайте перейдем к практике
Представьте, что у нас есть команда из трех инженерных групп, задача которой состоит в создании полезного веб-сайта по вакцинации против COVID-19, чтобы любой человек в определенной области мог забронировать для него место и дать возможность медицинскому персоналу обслуживать его. быстро.
Этот продукт необходимо создать к 5 ноября, чтобы предотвратить массовое скопление людей, желающих пройти вакцинацию, и снизить риск заражения во время длительного ожидания. .
Ожидаемая дата этого события была получена от национального органа здравоохранения.
Узнав о миссии, команда решила построить свою миссию в соответствии с целью продукта.
Для Team Zebra:
Создайте надежную платформу для непрерывной доставки и интеграции, гарантируя безопасность, соответствие требованиям и качество.
Для Team Lion:
Зарегистрируйте клиента и защитите данные клиента. Соответствовать требованиям HIPAA и GDPR.
Команда Cute Dog:
Непрерывный процесс вакцинации.
Как мы проводим оценку?
Создайте эпики
После того, как каждая команда узнает требования, они вместе с владельцем продукта или лицом, представляющим клиента, в другой конфигурации создают эпики.
Проще говоря, вот как команды решили создавать свои эпики.
Для Team Zebra:
- Создайте конвейер CI/CD
- Добавить в него статическое сканирование безопасности
- Убедитесь, что конвейер поддерживает все тесты, написанные командами.
- Разрешить выпуск программного обеспечения под флагом функции
Для Team Lion:
- Регистрация новых пациентов
- Закрытие учетных записей и всех связанных действий существующих пациентов
- Шифрование данных, обеспечивающее защиту данных в состоянии покоя и в движении.
Команда Cute Dog
- После регистрации гражданина эта команда гарантирует, что он сможет подать заявку на назначение вакцинации.
- Убедитесь, что общение с клиентом происходит.
- И что любые реакции на вакцину или другие жалобы рассматриваются правильно.
Наметанный глаз сразу увидит, что для того, чтобы этот продукт работал, требуется больше деталей, но в большинстве случаев это происходит практически с любым продуктом на этой ранней стадии. Мы поговорим об этом позже.
Эпические очки
На данный момент нам нужно больше данных, чтобы ответить, скорее всего, мы уложимся в срок или мы далеко от графика и должны что-то с этим делать.
Что такое эпическая точка?
Это похоже на точку истории в Agile, но вместо этого на уровне истории, где вы предполагаете иметь всю информацию, необходимую для определения размера, мы применяем ее к эпическому уровню, где у нас нет таких деталей.
Напоминаем, что какую бы систему мы ни использовали, балл учитывает все факторы, которые могут повлиять на завершение:
* Ожидаемые усилия и опыт, необходимые для выполнения работы * Опыт команды в проведении аналогичных эпических проектов в прошлом. * Неопределенности, сомнения и риски на момент оценки * QA (контроль качества) тесты и исправление ошибок, которые могут быть необходимы для завершения эпопеи. * Накладные расходы рабочего процесса в виде общения, совещаний и административной работы, необходимой для завершения
Какой масштаб мы будем использовать?
Последовательность Фибоначчи – это одна из популярных шкал для оценки быстрых эпических очков. Традиционная последовательность Фибоначчи — это 1, 2, 3, 5, 8, 13, 21 и т. д., где каждое число представляет собой сумму предыдущих чисел.
Под agile-оценкой Фибоначчи понимается использование этой последовательности в качестве шкалы оценки при оценке трудоемкости задач гибкой разработки.
Давайте оценим
Для каждой команды коротко обсудите все эпики и попросите группу подумать обо всех факторах эпической точки, которые я перечислил выше. Затем попросите команды расставить былины по шкале Фибоначчи. Чтобы это было удобно для занятий позже, ограничьте числа шкалы только до 8,13,21,34.
Вы можете начать это двумя способами:
* Если у вас есть небольшое количество эпиков, вы можете попросить команду поставить их напрямую, сравнив их. Это то, что сделала команда Lion. * Если у вас их много или вы хотите большей точности, вы можете сказать, что эпик «Выполнение теста» — это 21-указатель, и теперь нам нужно сравнить каждый эпик с ним и решить, больше он или меньше, и поместить его в шкалу. Это то, что сделала Team Zebra.
Идеального подхода не существует, но результатом обсуждения должен быть список эпиков и их сегмент на шкале.
<цитата>Не волнуйтесь, если вы немного нервничаете; помните, что это оценка, и мы будем постоянно уточнять оценки.
Давайте ответим на главный вопрос: успеем ли мы?
Прежде чем мы это сделаем, позвольте мне подытожить наши достижения.
* У нас есть продукт, который нужно создать, и все команды знают, зачем мы его делаем. * Команды определили свою миссию на основе цели продукта * Есть крайний срок, который мы должны успеть из-за предстоящего сезона covid. * Команды с владельцем продукта определили эпики для достижения этой цели. * Все спики были оценены с использованием эпических очков и теперь сгруппированы в ведра на основе этой оценки. * У нас есть хорошая и уютная среда, где все это происходит.
Теперь у нас есть некоторые данные для работы и ответа на вопрос, сможем ли мы уложиться в срок. Мы можем сделать это двумя способами:
Во-первых: у нас есть исторические данные от команд.
Предположим, что Team Zebra может приблизительно сказать, сколько спринтов может занять эпик с 8 очками. Давайте определим это как два спринта.
Затем мы можем выполнить базовую математику, сказав:
- Всего у нас 71 EP.
- Что дает команде примерно 18 спринтов.
- В неделях это будет 36 недель, что равняется восьми месяцам.
Пожалуйста, поместите это на временную шкалу.
Вот как выглядит оценка Team Zebra, основанная на нашем анализе и условии, что наш проект стартует 1 февраля.
Если мы сделаем еще один и предположим, что Team Lion также проделала аналогичную историческую работу и их 34 очка составляют восемь спринтов, что оставляет нам:
- Всего у нас 102 EP
- Что дает нам около 24 спринтов.
- В месяцах это будет 11 месяцев.
Как читать временную шкалу?
Даже неопытный глаз увидит проблему в этом усилии. Поэтому нам нужно что-то делать. Я уверен, что вы лучше меня знаете, что это за предметы, но по моему опыту разговоры идут вокруг нескольких тем:
* Получение большей детализации эпиков — почему все эпики имеют 34 указателя — это потому, что команде нужно чему-то научиться, или у них не было времени провести надлежащее исследование? * Должны ли мы вырезать что-то из первоначального объема, что заставит нас уложиться в срок, но по-прежнему будет ценным для гражданина, и разработать план, чтобы доставить остальное через несколько недель после крайнего срока?
Во-вторых: у нас нет исторических данных от команды.
Давайте представим, что третья команда новая и не может учитывать фактор времени.
Решение здесь простое. Дайте им поработать пару спринтов, а затем проведите оценочное упражнение и посмотрите, сколько Epic Points они сожгли за этот период.
Допустим, они работали над новым процессом вакцинации в течение двух спринтов, потому что это их основной вариант использования, и теперь они считают, что эта эпопея теперь не 34-указательная, а 21-указательная из-за их работы. Итак, теперь мы можем выполнить базовые математические операции и повторить вычисления с нашими данными.
* За два спринта команда сожгла 13 EP. * Значит, они скорее всего закончат свою часть за 9 спринтов, что дает нам 18 недель * это примерно 3,5 месяца.
Некоторые соображения
В результате этого упражнения вы получите набор продолжительностей, который может дать вам начальную оценку того, сможете ли вы достичь цели. Весь процесс, конечно, сложнее.
Было бы полезно, если бы вы также подумали о следующем:
* Зависимости — что произойдет, если команде Cute Dog нужно будет приступить к работе после того, как Team Zebra сдаст? Тогда у вас могут быть проблемы. * Добавление дополнительной работы — команда может обнаружить дополнительную работу во время работы над эпопеей. После того, как это станет фактом, вам нужно назначить EP новому эпику и посмотреть, как это повлияет на временную шкалу, используя тот же подход. * Команды становятся лучше: после каждого или двух спринтов вы должны увидеть, сколько EP сожгли команды, и снова выполнить подсчет.
Команды становятся лучше.
Я хотел выделить для этого отдельный абзац.
Одна ошибка, которую совершают некоторые команды, заключается в том, что они делают оценку один раз, а затем забывают об этом.
В начале проекта мы не знаем, чего мы не знаем, но когда мы знаем, чего мы не знали, мы ничего не делаем со знанием.
Держитесь подальше от этой ловушки; регулярно пересматривайте оценки. Поскольку вы работаете на идеальном уровне детализации — эпике, эти оценки будут с каждым разом все более точными, что дает вашей компании больше шансов на успех с вашим продуктом. Это хорошее вложение вашего времени!
Заключительные примечания
Это упрощенное объяснение того, как оценивать элементы слишком рано, чтобы их можно было оценить, будет полезно вам и вашим командам. Это хорошо структурированный подход, который я использовал много раз. Это обеспечивает прозрачность и согласованность.
:::информация Также опубликовано здесь.
:::
Оригинал