Моя научно-исследовательская организация следует методологии разработки Agile (Scrum). Одна из команд разработчиков работает в основном над элементами, которые действительно проблематичны с точки зрения определенности при планировании спринта. Это означает, что они в основном связаны с проблемами производительности, которые необходимо изучить и решить.
Ожидается, что эта команда будет работать в сотрудничестве с другими командами, следуя методологии Agile. Менеджеру команды трудно, так как во время планирования спринта очень мало определенности в отношении задач его команды. Более того, во время спринта возникают горячие вопросы, требующие оперативного реагирования команды.
Каким будет правильный способ работы этой команды в этом контексте? Как они должны планировать свою работу? Должны ли они выделять ведра времени для непредвиденных проблем? Должны ли они разделить свою работу на исследовательскую и резолютивную части и планировать их отдельно? Любые другие идеи?
Во-первых, Agile хорошо подходит для исследовательских проектов из-за неопределенности и возможности изменения требований.
Agile больше похож на набор руководств, чем на строгую методологию, полную правил. Настройте его под свой проект и технологический допуск. Я бы посоветовал вам принять следующие методы (некоторые из которых вы уже упоминали):
Опять же, agile — это расплывчатые оценки работы по сравнению с прошлыми выполненными работами. Дело не в том, чтобы зафиксировать количество часов, минут или секунд, которые что-то займет. До тех пор, пока вы можете сказать: «Эта предыдущая задача X была похожа и была оценена в Y баллов, значит, эта задача также оценивается в Y баллов», ваша скорость будет неизменной, независимо от точных чисел, с которыми вы оцениваете задачи.
Однако разделенная работа кажется естественной и лучше всего подходит для команд.
Работаем недельными итерациями. Всякий раз, когда есть задача, которая требует некоторого исследования (это означает, что команда не имеет представления о том, как решить проблему, а уровень неопределенности высок), мы решаем, сколько часов мы хотим потратить на задачу в итерации, т.е. . 4ч. Это значит, что во время итерации кто-то берет такое задание и тратит на исследование не более 4 часов. После завершения, какими бы ни были результаты, они представляются на демонстрационном собрании, и результаты используются на следующем сеансе планирования.
Конечно, иногда первые пару часов, потраченных на исследование, приносят слишком мало знаний, поэтому исследование продолжается в последующих итерациях. Тоже с ограничением по времени. Однако в нашей команде такая ситуация встречается редко. Обычно достаточно первых пары часов, чтобы понять, в чем заключается задача и как с ней справиться.
Конечно, количество часов, необходимых для исследования первого шага, зависит от сферы деятельности. Может быть, это будет день или дольше. Или, может быть, час. Однако имейте в виду, что достаточно хорошие результаты видны довольно быстро.
Одна идея состоит в том, чтобы использовать исторические данные и попытаться спланировать такие вещи, например, у нас есть такое количество проблем с обслуживанием, такое количество пожаров, которые нужно потушить, и некоторые «нормальные» работы, которые нужно выполнить. Вы также можете планировать такие вещи, поэтому, что бы ни случилось, мы не работаем над обслуживанием более 50% времени, так как мы также хотим, чтобы новые функции были реализованы.
Другая идея состоит в том, чтобы использовать Канбан , который действительно очень хорошо подходит для таких ситуаций. В этом случае вы даже не пытаетесь запланировать какую-то итерацию или как вы это называете период в пару недель. Вы просто реагируете на то, что является главным приоритетом в данный момент.
На самом деле такой подход очень хорошо работает для ремонтных бригад. Вы также можете настроить свое собственное решение, чтобы у вас были вещи в приоритетной полосе, где решаются супер-пупер-высокоприоритетные задачи и тому подобное. Так что довольно легко реагировать на изменение окружающей среды.
рвонг
Брюс Зепплин