Что является хорошим критерием для принятия решения о том, что представляет собой индивидуальная задача?

TL;DR

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

Интеграция документации с задачами

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

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

Анализ сбоя процесса

По моему опыту, если документация является частью определения готовности, но кто-то говорит:

У меня есть масса задач типа «Настроить XYZ», которые просто висят открытыми, потому что у ответственного лица пока нет времени заниматься документацией.

проблемы обычно могут быть связаны с неточной оценкой возможностей команды или неспособностью всей команды соблюдать разумные ограничения незавершенного производства. Некоторые распространенные основные причины могут включать:

• Давление со стороны руководства, чтобы оно выполняло «настоящую работу» вместо документации.
• Команды, которые многозадачны, а не эффективно работают над одной задачей за раз.
• Люди переходят к следующей задаче до того, как предыдущая задача будет полностью завершена в соответствии с согласованным «определением готовности».

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

Ограничения НЗП

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

Определение фактического потенциала вашей команды потребует некоторой работы с вашей стороны и активного сотрудничества вашей команды. Несмотря на то, что ваш пробег будет варьироваться, я рекомендую, чтобы незавершенная работа никогда не превышала:

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

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

Преимущества лимитов незавершенного производства

Даже если вы не используете методологию Канбан, лимиты НЗП помогут вам и вашей команде выполнить ряд задач:

1. Это гарантирует, что работа, брошенная до ее завершения, будет видна команде.
2. Размер очереди предоставит вашей организации ценную информацию о том, достаточно ли ресурсов для обработки объема входящих запросов в течение желаемого времени цикла.
3. Можно измерить среднюю пропускную способность для заданий, поставленных в очередь, и получить обратную связь о возможностях команды.
4. Можно измерить среднее время цикла работ от приемки до завершения и скорректировать процессы (или ресурсы), если время цикла недостаточно.

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

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

Заказ на поставку создает требование, которое необходимо выполнить, это требование требует выполнения работы для выполнения работы. Эта работа выполняется в форме анализа подготовки, кодирования, тестирования, документирования, упаковки развертывания, дизайна пользовательского интерфейса и многих других действий в зависимости от типа продукта.

Каждая из них представляет собой задачу. Таким образом, вы создадите множество задач по уходу, дизайну пользовательского интерфейса, кодированию, тестированию. Затем каждая задача выполняется и выполняется, когда у члена команды есть возможность это сделать. Например, подготовка тестовых данных может быть легко начата до написания кода, или тесты TDD/BDD могут быть созданы с помощью заглушек.

Правило регистрации

Мне нравится создавать задачи на этих границах

1. Что-то, что разработчик может зафиксировать в исходном репозитории. Например, разработчик может создать схему базы данных и зафиксировать ее; идеальная задача.
2. Когда требуется передача между различными навыками.
3. Когда немного работы превышает более 1/2 дня. Нужна видимость того, что делается, а задачи, выполнение которых занимает несколько дней, повышают риск для команды.
4. Задачи должны способствовать определению «Готово».

Баланс размера задачи

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

Задачи по уходу

Часто, когда в команде есть бизнес-аналитик, который занимается очисткой бэклога продукта, я обычно ставлю задачу на Epic , который нуждается в очистке. Задача просто требует очистки PBI, а затем оценивается в часах. Цель состоит в том, чтобы BA/PO и, возможно, команда подготовили PBI и привели его в состояние готовности к следующему спринту. Это помогает команде не забывать ухаживать за собой, а также «учитывает» активность.

Выполнено

Наличие простой стены To Do , In Progress * и Done * позволяет легко увидеть состояние требования. Таким образом, если есть еще задачи, которые нужно выполнить, команде нужно взяться за задачу, чтобы выполнить ее. После того, как все задачи выполнены, требование готово для рассмотрения PO.

Работа с изменениями

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

Тренерское руководство

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

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

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

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

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

Единственный вопрос, на который нужно ответить: знаете ли вы, где вы находитесь, знаете ли вы, в каком состоянии находится ваш проект, знаете ли вы, куда вы идете? Если вы не можете ответить на эти вопросы, значит, ваш нервный срыв сломан.

Избегайте критериев. Существует бесконечное количество сценариев, и не может быть набора критериев, которые будут работать во всех этих ситуациях. Зарегистрированный PM должен иметь право разбивать работу в соответствии с потребностями своего руководства.

Поскольку теперь это выяснено, это документация для конечного пользователя, такая как руководства пользователя и т. Д. Вот мои мысли:

• Руководства пользователя очень важны для конечного пользователя. Необходимо разъяснить вашей команде, насколько это важно для конечного пользователя. Без этого пользователям могут быть неудобны новые разработанные функции.
• Включите эту задачу в свой план, и вы можете сделать это с младшими разработчиками или стажерами колледжа, если они у вас есть. Окончательный обзор документов должен быть сделан с SME (экспертиза предмета) и с старшими членами команды. Отправьте конечному пользователю после реализации комментариев обзора. Качественная документация очень помогает конечному пользователю.
• Другой способ обучения команды — дать членам вашей команды новое программное обеспечение без документации и попросить их выполнить необходимую задачу. Попросите их также записать проблемы, с которыми они сталкиваются.
• Обсудите проблемы по этому поводу и заручитесь поддержкой команды для реализации согласованных улучшений.