Как составить план / график задач по доставке на основе оценки отдельных задач

Question

Мне интересно, как «реальный» рабочий день (7-8 часов) относится к термину «инженерные часы», используемому для оценки времени, необходимого для выполнения какого-либо задания. Я думаю, что оценочное усилие в EH (если оно правильно оценено) не может быть просто переведено в рабочие дни путем деления на 8, и что эффективный рабочий день программиста короче, чем время, которое он проводит в здании, в котором он работает. Это может привести к большим ошибкам в оценках при оценке небольших блоков задач (т. Е. Какова область одной итерации в SCRUM) и когда нет оценок наилучшего / наихудшего вариантов, но планирование выполняется на основе оценок отдельных задач, выполненных программистами. Когда программистам необходимо оценить время, необходимое для выполнения отдельных задач, они обычно оценивают время с момента, когда они начинают работать над ним, до момента, когда они его завершают. Излишне говорить, что безумно ожидать, что кто-то выполнит 4 задания по 2 часа в день.

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

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

Answer 1

При программировании мы делаем две вещи:

• То, что мы сделали, похоже на то, что было раньше, и
• новые вещи, которые мы сделалиникогда не делали раньше.

Когда мы повторяем похожие вещи, оценка - в точках относительного усилия / сложности или в часах - обычно довольно проста.Даже при оценке в баллах их можно легко соотнести с часами после спринта или двух, когда команда наберет скорость.

Проблема, с которой сталкивается большинство команд, заключается в том, что они часто делают новые вещи.Это потому, что:

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

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

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

Я видел несколько стратегий для решения этой проблемы, в зависимости от того, насколько решительно кто-то (заставляет разработчиков) производить надежные оценки, насколько вы доверяете заинтересованным сторонам,и т. д.

1. Ужасно проставьте оценки и затем приведите работу в соответствие с ними (это то, что разработчики в конечном итоге делают, если менеджеры / управляющие компании вынуждают их давать надежные оценкипонимают ли разработчики это или нет).

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

3. Сначала делайте все, что рискованно (особенно если вы не знаете, насколько рискованно)это!).Постепенно поток стабилизируется.Для 9-месячного проекта потребовалось 3 месяца, чтобы начать производить какие-либо полезные оценки, поэтому будьте осторожны с этим.Положительным моментом является то, что ваши заинтересованные стороны увидят, что вы обращаетесь к тем вещам, которые заставляют их спать по ночам рано, поэтому доверие может быть высоким.Ваш PM / SM будет запасным в течение этого времени.Ничего страшного.

4. Примите, что старая метафора "время потрачено = работа выполнена" является мифом в проектах, связанных с большим количеством обучения и знаний.Возможно, это было бы уместно в те дни, когда с разработчиками обращались как с фабрикой - отрабатывая реализацию чужих проектов - но в мире Agile и Scrum это совершенно неуместно.Даже Scrum.org недавно удалили необходимость в оценке и измерении скорости из своего руководства.Найдите другие способы развить доверие, управлять рисками, выиграть бюджет и поговорить о работе - так как это единственные причины, по которым вам нужны оценки в первую очередь.

Answer 2

Кроме мифического человека месяц , который всегда стоит прочитать, Проворные оценки и планирование - одна из лучших книг, которые я нашел по этой теме.

Лучшая цитата:

«Нет смысла быть точным, когда ты даже не знаешь, что Вы говорите. »(Джон фон Нейман)

Также, экспериментальная разработка программного обеспечения пытается сделать статистически значимые выводы из экспериментов в контролируемой среде. Грубо говоря, вы приступаете к разработке экспериментов с применением научного метода, выбора входных переменных (т. Е. Опыта программистов, времени недели, языка / структуры и т. Д.) И измерения результатов.

Из википедии:

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

Хорошая книга, которую я помню из замечательного университетского класса по теме: «Экспериментальная разработка программного обеспечения» . Предполагается, что вы разбираетесь в статистических распределениях и описательной статистике , но это очень приятно читать.

Answer 3

Простой способ достичь запланированного и фактического затраченного времени (которое само по себе всегда изменчиво в определенной степени) - это использовать инструмент гибкого управления. Целевой процесс может работать с большими нагрузками, но вы можете получить полную систему бесплатно, если используете менее 6 лицензий. За последние 5 лет я с большим успехом использовал его у 4 разных клиентов.

У меня нет точного ответа, который вы хотите (т. Е. Часы * 1,75 = рабочее время), но постоянная корректировка оценок TargetProcess в соответствии с затраченным временем очень быстро даст вам соотношение, которое применяется к ВАМ.

PS- я не работаю на них.