Как вы управляете ресурсами при гибком подходе с PMI

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

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

Спринт #1

Рассказ № N

  • Дизайн
  • Код
  • Модульный тест

После юнит-тестов один из ваших ресурсов закончил последнюю историю из спринта, а другие нет и почему-то остался 1 день или 2 дня. Этот простаивающий ресурс, что должен делать?

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

Между прочим, большинству людей не нравится, когда их называют ресурсами :)
Вы не назначаете работу в гибких процессах; вы используете очередь вытягивания. Вы также стремитесь к потоку, а не к высокой загрузке. Практики, которые вы описываете, на самом деле не являются «гибкими».
@ Эрик Я отредактировал свой вопрос для тех, кто буквально чувствителен к словам! ;)
@ToddA.Jacobs, спасибо за комментарий. На самом деле, может быть, я смешиваю концепции, потому что я постепенно мигрирую, чтобы понять гибкий подход. Мне нужно больше учиться. Команда, в которой я работаю, быстро развивается и адаптируется к agile. Очень ценю ваш комментарий.
@ToddA.Jacobs, скажем, если члены команды завершают свои задачи и больше не требуется выполнять задачи, они вернутся в эту очередь извлечения? (не говоря уже о том, чтобы поставить их в очередь) доступны для следующего спринта или проекта?

Ответы (3)

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

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

Спасибо за Ваш ответ. Я понимаю, что agile-подход отличается от традиционного PM тем, что agile должен способствовать совместной и самоорганизующейся команде. И как ToddA. Джейкобс говорит, что дело не в оптимизации. Но что я пытаюсь понять, если эти доступные люди не смогут начать следующий спринт, пока все «назначенные» для проекта не будут доступны, верно?
Если вы проводите спринт на основе скрама, то спринт имеет фиксированную продолжительность. Несмотря ни на что, он заканчивается в определенный день, а следующий начинается на следующее утро, и вы знаете эти даты, когда начинаете спринт. Даже если все закончат работу на два дня раньше, спринт не закончится еще на два дня, поэтому людям придется искать дополнительную работу.
+1 за солидный список предложений. Также не забывайте о других командах: можете ли вы помочь обучить первую линию поддержки, продаж, маркетинга или эксплуатации некоторым новым функциям?

@ Ответ Эрика идеален, когда вся команда досрочно выполнила цели спринта.

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

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

В процессе спринта цель спринта является целью команды. В моем случае мы начинаем каждую историю, используя следующую последовательность:

  1. Разработчик, QA и владелец продукта (или BA) проводят быструю встречу, чтобы убедиться, что они находятся на одной странице в отношении истории/критериев приемлемости. (Экономит нам много переделок)
  2. Разработчик начинает кодировать. Специалист по обеспечению качества начинает писать тест-кейсы (автоматизированные и ручные) одновременно. Они держат друг друга в курсе всего спринта.

  3. Если они заканчивают историю, они вместе переходят к другой истории.

  4. Если у кого-то есть время простоя, всегда есть много занятий, таких как проверка кода, проверка тестового сценария, оптимизация процесса сборки, обновление документации и т. д.

  5. Если еще есть свободное время, мы ищем новые истории ИЛИ работаем в парах (Парное программирование)

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

Конечно. Очень интересно. Большое спасибо за ваш ответ.
Как вы управляете ресурсами при гибком подходе с PMI
СпросиСетьПолитика конфиденциальности1y, 0v