Моя команда работает в трехнедельном спринте, и, соответственно, мы рассчитываем возможности члена команды на основе его или ее запланированных отпусков и отпусков компании.
Но мы не можем отрицать любые незапланированные/больничные, незапланированные встречи и обучение. Различные межкомандные и внутрикомандные связи, которые могут быть важны для моего собственного проекта или других команд. Обмен знаниями — важная основная ценность растущей организации, которая поощряет открытое взаимодействие между командами.
Различные церемонии спринта также занимают некоторое время членов команды в течение этих 3 недель. Какие моменты важно учитывать при расчете Вместимости членов Команды, учитывая, что они проводят 8 часов в офисе.
Я делаю вывод, что ваша команда использует баллы для первоначальной оценки, а затем на совещании по планированию разбивает истории на задачи и оценивает их на уровне часов.
Сначала несколько общих рекомендаций:
Никогда не планируйте 8 часов в день. Перебои случаются. Запланируйте только около 6 часов в день для задач разработки.
Убедитесь, что вы убрали эти запланированные выходные из возможностей команды. Точно так же обязательно удалите известное время собраний из емкости.
Но вы, кажется, уже знаете это. Вы хотите знать, как справиться с неожиданным отсутствием.
Оставьте некоторую слабину в вашем планировании.
Мы, люди, очень плохо умеем оценивать. Дела обычно занимают больше времени, чем мы предполагаем. Оставив небольшой резерв в своем расписании, вы сможете смириться как с плохими оценками, так и с некоторыми пропусками. Если команда достигает цели итерации досрочно, у нее есть время, чтобы погасить часть технического долга.
Смиритесь с тем, что любая данная оценка, скорее всего, будет ошибочной, и вы не всегда сможете написать все истории, даже если каждая из них будет появляться каждый день.
В принципе, не беспокойтесь об этом. Найдите время, чтобы вспомнить, что разработчики — это люди, что вы человек, а не машины, генерирующие код. Примите неопределенность разработки программного обеспечения и найдите способы быть гибкими. Можем ли мы отказаться от истории из этой итерации? Джо сделал свои дела раньше, может ли он забрать Сьюзи, пока ее нет? Можем ли мы продлить эту итерацию еще на неделю? Научитесь быть гибким (осмелюсь сказать, проворным ) и реагировать на неизвестное с изяществом.
Значит, вам не удалось представить каждую историю в итерации? Большое дело. Такое случается. Расскажите об этом в ретроспективе, пусть команда расскажет, почему и как они могут уменьшить влияние незапланированных выходных. У них будут лучшие идеи, чем у незнакомцев в Интернете.
Перестаньте делать оценку часового уровня.
По моему личному опыту, это в значительной степени пустая трата времени, которая порождает ложное ощущение знания. Вместо этого используйте историческое количество завершенных сюжетных очков в качестве возможностей вашей команды. В любом конкретном случае это будет неправильно, но так же будет и планирование мощности на уровне часов. Иногда они делают больше, иногда меньше, однако в среднем это довольно хороший показатель того, сколько команда может сделать за одну итерацию.
Цель — не чистая пропускная способность задач. Цель — итерация работающей и ценной части программного обеспечения. Сначала делайте самое важное, и оно будет у вас независимо от того, заболеет ли кто-нибудь из команды на несколько дней.
В Scrum Guide говорится о том, что следует учитывать при определении обязательств на следующий спринт.
Входными данными для этой встречи являются Бэклог Продукта, последний Инкремент продукта, прогнозируемые мощности Команды Разработки во время Спринта и прошлые результаты Команды Разработок. Количество элементов, выбранных из Бэклога Продукта для Спринта, зависит исключительно от Команды Разработки. Только Команда Разработки может оценить, чего она может достичь в предстоящем Спринте.
Самое важное, что нужно учитывать, — это фактические доказательства работы, которую вы проделали в прошлом . Мера того, сколько ваша команда может сделать за одну итерацию, обычно называется скоростью .
Неважно, будут ли члены команды там 8 часов. Неважно, что иногда бывают встречи. Мы не заинтересованы в этих вещах по отдельности, и гораздо лучше напрямую измерять то, что нас волнует, а именно нашу скорость.
Обратите внимание, что за принятие обязательств отвечает команда разработчиков (а не скрам-мастер), и что производительность измеряется как команда, а не как отдельные лица .
В то время как руководство по Scrum оставляет вопрос «Как» команда разработчиков оценивает истории в качестве упражнения для читателя, наиболее успешные команды используют что-то вроде Story points .
Например, предположим, что у моей команды есть несколько историй размера (в баллах, левый имеет наивысший приоритет) { 1, 5, 8, 3 }. Если в прошлом спринте нам удалось набрать 6 очков, команда умеет брать дальше 1и 5только. Если нам удалось набрать 9 очков, мы знаем, что я могу взять 1, 5и 3. Вещь, определяющая решения команды, — это данные предыдущих итераций. «Точка» не связана с каким-либо количеством времени, кроме как через наше основанное на доказательствах измерение скорости.
Команды, которые на практике используют часовые оценки, плохо используют скорость и поэтому плохо планируют.
Итак, подводя итог,
Оценивайте возможности вашей команды как совокупный диапазон, основанный на исторической производительности, а не как сумму идеальных часов, доступных каждому человеку. Кроме того, вы должны тщательно обдумать, чего вы надеетесь достичь с помощью таких расчетов, и определить, не лучше ли подходит более гибкий подход к производительности и статистической оценке.
Моя команда работает в трехнедельном спринте, и, соответственно, мы рассчитываем возможности члена команды на основе его или ее запланированных отпусков и отпусков компании.
В Scrum никогда не рассчитываются скорость или возможности отдельного человека . Вместо этого вы рассчитываете прогнозируемую мощность всей команды на основе эмпирических показателей прошлой производительности и ожидаете, что незначительные различия в индивидуальной или итерационной мощности со временем выровняются.
Что еще более важно, хотя вы можете использовать различные методы для оценки идеальных часов, доступных команде, это не даст вам хорошей предсказуемости в отношении объема работы , которую вы можете выполнить в спринте. Если это не ваш самый первый спринт, гораздо лучше использовать относительные размеры (например, баллы за историю) и оценивать объем работы, которую вы сможете выполнить в любой конкретной итерации, на основе эмпирических данных о том, какой объем работы выполнила команда. совершить в прошлом.
Даже если вы решите использовать идеальные часы, а не очки истории, вы все равно рассчитаете вместимость команды. Например:
Итак, у команды из пяти человек есть 60-90 идеальных человеко-часов, доступных за трехнедельный спринт. Вы можете просто остановиться на этом и позволить статистической вариации сгладить себя.
В качестве альтернативы вы можете применить фактор выдумки, чтобы скорректировать известные проблемы в предстоящем спринте. Например, вы можете:
Из прагматических соображений я склонен применять ложные коэффициенты для больших потенциальных торможений скорости, но обычно игнорирую их для незначительных отклонений, таких как запланированные визиты к стоматологу.
Кажется вероятным, что ваша реальная проблема заключается не в отсутствии точной оценки, а в том, что вы относитесь к членам команды как к отдельным ресурсам и стремитесь оптимизировать использование, а не пропускную способность. Хотя вы прямо не сказали об этом, формулировка вашего вопроса, по крайней мере, подразумевает, что задачи назначаются отдельным лицам, а не коллективно принадлежат команде, и поэтому отсутствие или снижение возможностей любого члена команды может создать узкие места. или раскрывайте зависимости в вашем конвейере доставки.
Не делай этого.
Вместо этого убедитесь, что элементы невыполненной работы принадлежат всей команде и что команда работает над завершением историй совместно, а не последовательно или параллельно. Кроме того, элементы невыполненной работы должны быть как можно более независимыми друг от друга, чтобы невозможность завершить одну из них из-за нехватки ресурсов или времени не «останавливала очередь» и для других элементов невыполненной работы.
Даже если вы не совершаете ошибок, которые я только что описал, подумайте , почему вы пытаетесь отслеживать показатели производительности на индивидуальном уровне, а не используете командный подход, лежащий в основе большинства гибких методологий. Вы можете быть удивлены, обнаружив, что во многих случаях это необязательно и даже контрпродуктивно.
Попробуйте принять идею LEAN о «отходах».
Попросите команду записывать свои часы по задачам, встречам, администрированию и т. д., чтобы вы могли точно определить, сколько времени вы тратите на «нерабочие» задачи каждую неделю.
Это даст вам как средний процент «пустого» времени, который вы можете учесть в индивидуальных возможностях, так и позволит вам определить то, что вы можете сократить, чтобы увеличить производительность.
Вместо того, чтобы пытаться планировать незапланированные встречи, тренировки или больничные, запланируйте набор часов каждый день для групповых мероприятий, таких как:
Кроме того, создайте резервную историю, которая фиксирует процентную долю возможностей каждого члена команды в каждом спринте для обработки предсказуемых действий, таких как:
использованная литература
Ануруд Сингх
Натан Купер
Натан Купер