Как составить план / график заданий по доставке на основе оценок отдельных заданий
Мне интересно, как "реальный" рабочий день (7-8 часов) относится к термину "инженерные часы", используемому для оценки времени, необходимого для выполнения какого-либо задания. Я думаю, что расчетное усилие в EH (если оно правильно оценено) не может быть просто переведено в рабочие дни путем деления на 8, и что эффективный рабочий день программиста короче, чем время, которое он проводит в здании, в котором он работает. Это может привести к большим ошибкам в оценках при оценке небольших блоков задач (т. Е. Какова область одной итерации в SCRUM) и когда нет оценок наилучшего / наихудшего вариантов, но планирование выполняется на основе оценок отдельных задач, выполненных программистами. Когда программистам необходимо оценить время, необходимое для выполнения отдельных задач, они обычно оценивают время с момента, когда они начинают работать над ним, до момента, когда они его завершают. Излишне говорить, что безумно ожидать, что кто-то будет выполнять 4 задания по 2 часа каждый в течение одного дня.
Я хотел бы знать, каковы лучшие практики в успешных компаниях для соотношения эффективного времени и времени, потраченного "на работе", и есть ли какие-то книги или исследования, в которых оценивается, сколько среднего времени тратит программист на работу (сосредоточенный на поставленных задачах), а не выполнение других действий, не включенных в оценку, таких как чтение / запись писем (кроме включенных в оценку, если это задача поддержки или аналогичная), мозговой штурм, встреча, пить кофе, оценка задач и обновление статуса в инструменте отслеживания ошибок / задач.
Если нет книг или исследований, любые ссылки на статьи по этой проблеме уважаемых членов сообщества также будут полезны, так как я не смог найти ни одной, эти ключевые слова являются слишком общими.
3 ответа
Есть две вещи, которые мы делаем, когда программируем:
- То, что мы сделали, похоже на то, что было раньше, и
- новые вещи, которые мы никогда не делали раньше.
Когда мы повторяем похожие вещи, оценка - будь то в относительных усилиях / сложности или в часах - обычно довольно проста. Даже при оценке в баллах их можно легко соотнести с часами после спринта или двух, как только команда наберет скорость.
Проблема, с которой сталкиваются большинство команд, заключается в том, что они часто делают что-то новое. Это потому что:
- делать проект, где все это было сделано раньше, бессмысленно (см. "Вальс с медведями")
- если все это было сделано раньше, возможно, есть Open Source или готовые продукты, которые сделают это для вас, поэтому изучение того, как их использовать, может быть новым
- разработчики ненавидят делать одно и то же снова и снова и предпочитают изучать что-то новое, автоматизируя это или создавая повторно используемую библиотеку.
Таким образом, многое из того, что мы делаем в программных проектах, имеет тенденцию быть новым. Обычный-тот же-старый-тот же самый часто заканчивает тем, что был дан младшим разработчикам, для которых это ново.
Проблема с новыми вещами в том, что вы понятия не имеете, сколько времени они собираются занять. Вы никогда не делали их раньше!
Я видел несколько стратегий для решения этой проблемы, в зависимости от того, насколько решительно кто-то (заставляет разработчиков) производить надежные оценки, насколько вы доверяете заинтересованным сторонам и т. Д.
Ужасно дополняйте оценки, а затем делайте работу подходящей для них (именно это в итоге и делают разработчики, если менеджеры / управляющие вынуждают их давать надежные оценки, независимо от того, осознают это разработчики или нет).
"Классы обслуживания" Канбана позволяют смешивать некоторые новые вещи с некоторыми знакомыми вещами. Это, как правило, позволяет менее переменному потоку проходить через конвейер разработки, поэтому вы можете основывать свои оценки на этом.
Сначала делайте все, что рискованно (особенно если вы не знаете, насколько это рискованно!). Постепенно поток стабилизируется. Для 9-месячного проекта потребовалось 3 месяца, чтобы начать производить какие-либо полезные оценки, поэтому будьте осторожны с этим. Положительным моментом является то, что ваши заинтересованные стороны увидят, что вы обращаетесь к тем вещам, которые заставляют их спать по ночам рано, поэтому доверие может быть высоким. Ваш PM / SM будет запасным в течение этого времени. Все нормально.
Примите тот факт, что старая метафора "потраченное время = проделанная работа" является мифом в проектах, связанных с большим объемом обучения и знаний. Возможно, это было бы уместно в те дни, когда с разработчиками обращались как с фабрикой - отрабатывая реализацию чужих проектов - но в мире Agile и Scrum это совершенно неуместно. Даже Scrum.org недавно убрал необходимость в оценке и измерении скорости из своего руководства. Найдите другие способы развивать доверие, управлять рисками, выигрывать бюджеты и вести переговоры вокруг работы - поскольку это единственные причины, по которым вам нужны оценки в первую очередь.
Помимо мифического мужского месяца, который всегда стоит прочитать, гибкая оценка и планирование - одна из лучших книг, которые я нашел по этой теме.
Лучшая цитата:
"Нет смысла быть точным, когда ты даже не знаешь, о чем говоришь". (Джон фон Нейман)
Кроме того, экспериментальная разработка программного обеспечения пытается сделать статистически значимые выводы из экспериментов в контролируемой среде. Грубо говоря, вы разрабатываете эксперименты, применяя научный метод, выбирая входные переменные (например, опыт программистов, время недели, язык / рамки и т. Д.) И измеряя результаты.
Из википедии:
Научный метод предлагает цикл наблюдений, законов и теорий для развития науки. Экспериментальная разработка программного обеспечения применяет этот метод к программному обеспечению.
Хорошая книга, которую я помню из замечательного университетского класса по этой теме, - "Экспериментальная разработка программного обеспечения". Предполагается, что вы разбираетесь в статистических распределениях и описательной статистике, но это очень приятно читать.
Простой способ достичь запланированного и фактического затраченного времени (которое само по себе всегда изменчиво в определенной степени) состоит в использовании гибкого инструмента управления. Целевой процесс может выполняться с большими нагрузками, но вы можете получить полную систему бесплатно, если используете менее 6 лицензий. За последние 5 лет я пользовался им у 4 разных клиентов с большим успехом каждый раз.
У меня нет точного ответа, который вы хотите (например, часы * 1,75 = рабочее время), но постоянная корректировка оценок TargetProcess в соответствии с затраченным временем очень быстро даст вам соотношение, которое применимо к ВАМ.
PS- я на них не работаю.