Планирование мощности при использовании Kanban-base/Lean development
В настоящее время мы используем Scrum для разработки набора программных библиотек на C++ и C#. Природа домена такова, что мы должны быть достаточно реагирующими на меняющиеся требования - настолько, что планирование спринтов часто оказывается пустой тратой времени из-за высокого уровня срочной работы. Я думаю, что пришло время переключиться на скудную (канбан) модель разработки вместо Scrum, так как это работало достаточно хорошо для нас в прошлом.
Однако, на мой взгляд, я бы хотел сказать своим менеджерам, что моя команда недоукомплектована. Мне неясно, как это сделать эффективно, так как методологии Lean требуют минимального времени, затрачиваемого на оценку задач. Я должен поощрять наших клиентов (и моих менеджеров) сосредоточиться на приоритете работы, а не на том, сколько времени займет каждая функция. Дело в том, что у нас все еще тяжелый срок, и они хотят знать, что мы можем его выполнить. Для того, чтобы взять на себя обязательства, я чувствую необходимость измерить вещи и рассчитать персонал, который мне нужен!
Проблема в том, что я не знаю, как я могу аргументировать для большего количества сотрудников, если моя команда использует процесс, который фокусируется на расстановке приоритетов - мне нужно оценить всю работу, которую мы должны выполнить, а затем представить цифры, чтобы продемонстрировать "нам нужно Х больше людей".
По сути, я полагаю, что я спрашиваю, есть ли у кого-нибудь хорошие советы по измерению и обоснованию изменений в коллективе, когда вы приняли гибкий и гибкий процесс?
2 ответа
В Kanban вы можете настроить "классы обслуживания" и назначить "соглашение об уровне обслуживания" каждому.
Например, проблемы, которые блокируют клиента, являются приоритетом № 1 и могут даже привести к тому, что мы превысим пределы WIP и переключимся с выполняемой работы на удовлетворение. Такая работа будет выполнена в течение 3 дней 90% времени. (Такие соглашения должны быть получены из реальных данных, которые вы начнете накапливать, если будете ежедневно записывать состояние элемента, например, в виде совокупной блок-схемы.)
Наряду с классами обслуживания и SLA, вы также можете оговорить, что 20% времени команды должно быть потрачено на эти срочные ("ускоренные") проблемы, 60% на нормальную работу (например, разработку функций) и, возможно, 20% на постоянное улучшение, гигиена, технические истории и т. д.
Если вы можете получить согласие руководства по этому вопросу, а затем показать, что вместо этого вы тратите, скажем, 60% своего времени на неотложные проблемы пожаротушения, то вы можете доказать, что вам нужно больше членов команды, чтобы стать "нормальными" (ожидается) все готово.
У вас есть подробный список возможностей? Если это так, вы можете обработать так:
- Перечислите свои функции и для каждой из них перечислите свои истории.
- Затем с вашей командой попытайтесь оценить истории: сравните каждую историю с похожей функциональностью, чтобы оценить ее. Вы также можете использовать некоторые инструменты оценки, такие как планирование покера.
- Рассчитайте задержку и попробуйте выяснить, что необходимо для вашего следующего выпуска с вашим менеджером. Вовлеките его в решение, и он сам увидит, нужно ли вам удалить какую-то функцию или привлечь к процессу больше людей.