Что делать с нечеткими историями?

TL;DR

Вы не используете Scrum. Возможно, вы делаете что-то похожее на Scrum, но ваш начальник должен прочитать The Scrum Guide , а Scrum Master должен играть активную роль в обучении этого менеджера его роли (если таковая имеется) в проекте.

Анализ

Кто управляет бэклогом продукта

Менеджер [моей] команды настаивает на включении в спринт историй, которые плохо определены. В основном история содержит людей, с которыми можно поговорить, чтобы собрать требования .... [и] мой босс настаивает, чтобы эту историю нужно было начать в этом спринте.

Только Владелец Продукта может управлять приоритезацией историй в Бэклоге Спринта. Если ваш «босс» (который, предположительно, является непосредственным руководителем) также выступает в роли владельца продукта, это конфликт интересов. Если он не является владельцем продукта, то он выходит за рамки своей роли заинтересованного лица в рамках Scrum.

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

Сбор требований в виде историй

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

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

Хотя владелец продукта может работать со скрам-мастером и командой разработчиков во время уточнения невыполненной работы, чтобы прояснить или разложить истории, «сбор требований» не может прагматически быть встроенной частью пользовательской истории; в лучшем случае можно добавить дополнительные пользовательские истории о сборе требований.

В хорошей межфункциональной команде может быть бизнес-аналитик. Даже если нет, как история, которая говорит что-то вроде:

Как член команды разработчиков,
мне нужно обсудить функцию XYZ с отделом маркетинга
, чтобы помочь определить объем работы над функцией для следующего спринта .

Называете ли вы это всплеском истории или просто сбором требований, это приемлемая история, потому что она ясно показывает стоимость проекта (например, сбор требований не бесплатен) и позволяет внести уточненную историю в Бэклог Продукта. во время Уточнения Бэклога, чтобы Владелец Продукта расставил приоритеты и, в конечном итоге, оценил и принял Команду Разработки в течение какого-то будущего Спринта, как только история достигнет вершины Бэклога Продукта.

Скрам-мастер как преподаватель и рефери

Скрам-мастер — судья процесса. Когда вы видите такие «фолы в рамках», вам нужно вытащить красную карточку и дать свой метафорический свисток. Кроме того, вам необходимо предоставить адекватное образование о структуре, ее определенных собраниях и артефактах, а также о ролях и обязанностях в рамках структуры Scrum и организации для всех в организации. Я не могу оценить, действительно ли ваш босс является членом команды (хотя подозреваю, что нет), но ваша роль как скрам-мастера заключается в том, чтобы работать с ним, чтобы определить подходящие для него способы взаимодействия с командой. в рамках рамки.

Если вы не можете этого сделать или если он не желает адаптироваться к требованиям фреймворка, вы можете начать стирать пыль со своего резюме. Неважно, в чем проблема — в неопытном Скрам-мастере или в линейном управляющем; и то, и другое является ключевыми составляющими, которые статистически могут привести к провалу проекта, и если ваша должность не называется «Профессиональный козел отпущения», я бы не стал оставаться в ситуации, которая может привести к краху карьеры.

Как всегда, ваш пробег может отличаться.

CodeGnome хорошо суммирует первопричину. Ваш начальник не понимает или не понимает, как работает Agile. Это довольно большая проблема. Это относится к проблемам внедрения Agile, а это более важный вопрос, который вы задали.

Краткосрочное решение для этого спринта — приемочное тестирование. Поговорите со своим начальником несколько минут и узнайте, какова будет его оценка, если эта функция будет реализована. Примените технику вопросов «5 Почему» и углубитесь в детали. Это можно сделать довольно быстро, чтобы не «тратить» свое время. Имея четкое представление о том, что он считает успехом, ваши разработчики должны быть в состоянии понять, что строить.

Лучший-

Ваш начальник, вероятно, определил техническую неопределенность, с которой вы столкнулись. Для него это риск. Вот почему он хочет, чтобы история началась сейчас; чтобы этот риск можно было конкретизировать.

Вместо того, чтобы что-то делать, примите неопределенность и сделайте что-то, о чем вы сможете получить обратную связь. Разбейте это в шип, а остальная часть истории последует позже.

Жесткое следование принципам Agile/Scrum в таких ситуациях имеет тенденцию продвигать элементы с высоким риском (и, как правило, с высокой ценностью) дальше в список невыполненных работ. Даже попытка получить четкие критерии приемлемости для чего-то, что бизнес никогда раньше не пробовал, может быть сложной задачей. Во что бы то ни стало поговорите со своим боссом, но дайте ему знать, что до того, как вы закончите, пройдет более двух недель, и что вы будете держать его в курсе прогресса.

Если после этого ваш босс по-прежнему настаивает на том, чтобы вы придерживались жестких оценок перед лицом неопределенности, то он идиот, и пора искать новую работу.

Если вы хотите узнать больше о всплесках и анализе и о том, когда их делать, поищите Cynefin или некоторые из недавних статей, которые я написал о BDD и неопределенности .

Это просто.

Будьте суровы и удалите всю историю и заставьте человека, который ее написал, переписать ее правильно + отчитаться перед боссом, техническим директором и генеральным директором. Это единственное, что работает.

Мудрые люди строят и разрушают.

Я думаю, что есть более глубокая проблема, если ваш босс говорит вам сделать что-то, что он не может правильно определить. Но по тому немногому, что вы дали, я не могу судить, что это может быть, а что нет.

При этом я попытаюсь решить вашу текущую проблему:

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

Пока разработчики работают над спринтом, они либо находят решения проблемных историй — тогда «остальное» исчезает — либо, по крайней мере, лучше понимают проблему. Если проблема не была решена, они могут лучше оценить оставшиеся усилия для следующего спринта.

Ключевым моментом сейчас, вероятно, является то, сколько инвестировать в исследовательские истории. Это зависит от важности историй для вашего босса/клиента (кстати, кто из них PO? Должен быть только один...). Оцените больше усилий, если вы не уверены, и часть имеет решающее значение. Меньше, если это необязательно.

Надеюсь это поможет!

Вы слышали о 5 Почему ? Посмотрите, сможете ли вы получить какой-то контекст для историй, которые они хотят добавить.

Это потому, что ваша команда гораздо более последовательна в создании ценности? Покажите, что добавление работы приводит к многозадачности, которая замедляет работу.

Это из-за зависимости от даты? Сделайте эту информацию прозрачной и договоритесь|расставьте приоритеты на основе стоимости задержки

Это потому, что ваш босс просто не умеет писать рассказы? Работайте с ними, чтобы стать лучше и понять, что есть критерии приемки для начала работы, такие же, как и для работы, которая должна быть завершена.

Это потому, что они верят во внешнее давление над внутренней мотивацией? Покажите многочисленные исследования, что это наносит ущерб производительности.

Смените организацию или смените организацию.

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

SCRUM — это отличный набор инструментов, которые помогают повысить продуктивность, но иногда его строгие правила не очень хорошо применимы к реальному миру.

Конечно, босс должен лучше понимать, как работает скрам, и стараться адаптироваться к нему. Это похоже на то, как ваш босс пытается водить машину, но отказывается использовать руль, машина может куда-то попасть, но вряд ли туда, куда он хочет.

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

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

Я бы также записал все и на следующем обзоре спринта обсудил это с командой, попытался получить предложения о том, как справляться с подобными ситуациями в будущем, а затем вам, возможно, придется поговорить с боссом, чтобы объяснить ему последствия его действий. запрос, и вы сможете обсудить эффективные предложения (от команды), а поскольку они будут исходить не от вас одного, а от всей команды, начальник не сможет так просто от них отказаться.

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