День 1125. #Estimates
5 Законов Оценки Сроков Разработки
Оценки обычно являются необходимым злом в разработке ПО. Люди склонны считать, что написание ПО похоже на строительство дома, поэтому подрядчик должен предоставить оценку работы до того, как заказчик одобрит её. Однако в мире ПО большая часть системы создается с нуля, и обычно то, как она создаётся, что и как должна делать, когда она будет готова, — всё это туманные цели. Далее описаны некоторые аспекты оценок, которые являются (почти) универсальными.
1. Оценки — пустая трата времени
Время, потраченное на оценку, — это время, которое не тратится на создание ценности. Оценка бессмысленна, когда время на выполнение работы ограничено, и ещё хуже, если оценки запрашиваются срочно и мешают разработчикам выполнять работу.
2. Оценки не подлежат передаче
Оценки ПО не взаимозаменяемы, как и члены команды. То есть оценку одного человека нельзя использовать для предсказания того, сколько времени потратит другой на выполнение задачи. Ещё хуже, когда сроки основаны на оценке, сделанной продажниками, чья мотивация – продать продукт клиенту, а не предоставить реалистичную оценку.
Переносимость оценок лучше, когда оценщик и исполнитель имеют одинаковый уровень опыта или даже работают в одной команде. Некоторые методы оценки ориентированы на опыт всей команды, гарантируя, что не будут упущены ключевые моменты, известные только некоторым членам.
3. Оценки неверны
Оценки - это догадки, и, как правило, чем больше масштаб и чем дальше в будущем оценивается активность, тем больше потенциальная ошибка. Поскольку более мелкие и неотложные задачи могут быть оценены более точно, чем более крупные, имеет смысл разбивать задачи на мелкие части. В идеале единицей измерения прогресса должны быть отдельные подфункции, с которыми пользователь может взаимодействовать и тестировать. Теория очередей также предполагает, что пропускная способность увеличивается, когда работа в системе невелика и однородна по размеру.
Оценки отдельных элементов, как правило, становятся более точными, чем ближе работа к завершению. Самая точная оценка, как и самый точный прогноз погоды, говорит вам о том, что произошло вчера, а не о том, что произойдёт в будущем.
4. Оценки временны
Можно изначально предположить, что разработка функции займёт неделю. По мере работы над проектом многое изучается и решается, и эта же функция теперь может занять несколько часов или месяц, либо может быть полностью исключена из проекта из-за изменения требований. В любом случае, оценка имеет небольшую или, возможно, даже отрицательную ценность, поскольку с момента её создания потенциально многое изменилось.
Некоторые методологии разработки рекомендуют регулярно переоценивать все элементы в бэклоге продукта. Но это, как правило, усугубляет потери, определённые 1-м законом. Оценки должны выполняться в последний момент, чтобы обеспечить наибольшую точность и наименьшую необходимость их повторного проведения.
5. Оценки необходимы
Компании не могут принимать решения о создании ПО, не имея представления о затратах и времени. Часто они должны предоставлять оценку сроков как часть любого предложения продукта. То, что приведённые выше законы верны, не означает, что оценки должны исчезнуть волшебным образом. Но можно лучше управлять ожиданиями и временем, затрачиваемым на оценку, если все участники проекта понимают эти истины.
По закону Гудхарта, когда мера становится целью, она перестаёт быть хорошей мерой. Если желательны точные оценки, их не следует использовать в качестве обязательств или сроков.
Итого
С оценками связаны реальные затраты, которые следует учитывать, прежде чем делать их слишком важными для процесса разработки. После того как для утверждения проекта проведена достаточная высокоуровневая оценка и анализ рентабельности инвестиций, дополнительная оценка работы может оказаться не столь полезной, как более быстрое выполнение фактической работы.
Источник: https://ardalis.com/the-5-laws-of-software-estimates/
5 Законов Оценки Сроков Разработки
Оценки обычно являются необходимым злом в разработке ПО. Люди склонны считать, что написание ПО похоже на строительство дома, поэтому подрядчик должен предоставить оценку работы до того, как заказчик одобрит её. Однако в мире ПО большая часть системы создается с нуля, и обычно то, как она создаётся, что и как должна делать, когда она будет готова, — всё это туманные цели. Далее описаны некоторые аспекты оценок, которые являются (почти) универсальными.
1. Оценки — пустая трата времени
Время, потраченное на оценку, — это время, которое не тратится на создание ценности. Оценка бессмысленна, когда время на выполнение работы ограничено, и ещё хуже, если оценки запрашиваются срочно и мешают разработчикам выполнять работу.
2. Оценки не подлежат передаче
Оценки ПО не взаимозаменяемы, как и члены команды. То есть оценку одного человека нельзя использовать для предсказания того, сколько времени потратит другой на выполнение задачи. Ещё хуже, когда сроки основаны на оценке, сделанной продажниками, чья мотивация – продать продукт клиенту, а не предоставить реалистичную оценку.
Переносимость оценок лучше, когда оценщик и исполнитель имеют одинаковый уровень опыта или даже работают в одной команде. Некоторые методы оценки ориентированы на опыт всей команды, гарантируя, что не будут упущены ключевые моменты, известные только некоторым членам.
3. Оценки неверны
Оценки - это догадки, и, как правило, чем больше масштаб и чем дальше в будущем оценивается активность, тем больше потенциальная ошибка. Поскольку более мелкие и неотложные задачи могут быть оценены более точно, чем более крупные, имеет смысл разбивать задачи на мелкие части. В идеале единицей измерения прогресса должны быть отдельные подфункции, с которыми пользователь может взаимодействовать и тестировать. Теория очередей также предполагает, что пропускная способность увеличивается, когда работа в системе невелика и однородна по размеру.
Оценки отдельных элементов, как правило, становятся более точными, чем ближе работа к завершению. Самая точная оценка, как и самый точный прогноз погоды, говорит вам о том, что произошло вчера, а не о том, что произойдёт в будущем.
4. Оценки временны
Можно изначально предположить, что разработка функции займёт неделю. По мере работы над проектом многое изучается и решается, и эта же функция теперь может занять несколько часов или месяц, либо может быть полностью исключена из проекта из-за изменения требований. В любом случае, оценка имеет небольшую или, возможно, даже отрицательную ценность, поскольку с момента её создания потенциально многое изменилось.
Некоторые методологии разработки рекомендуют регулярно переоценивать все элементы в бэклоге продукта. Но это, как правило, усугубляет потери, определённые 1-м законом. Оценки должны выполняться в последний момент, чтобы обеспечить наибольшую точность и наименьшую необходимость их повторного проведения.
5. Оценки необходимы
Компании не могут принимать решения о создании ПО, не имея представления о затратах и времени. Часто они должны предоставлять оценку сроков как часть любого предложения продукта. То, что приведённые выше законы верны, не означает, что оценки должны исчезнуть волшебным образом. Но можно лучше управлять ожиданиями и временем, затрачиваемым на оценку, если все участники проекта понимают эти истины.
По закону Гудхарта, когда мера становится целью, она перестаёт быть хорошей мерой. Если желательны точные оценки, их не следует использовать в качестве обязательств или сроков.
Итого
С оценками связаны реальные затраты, которые следует учитывать, прежде чем делать их слишком важными для процесса разработки. После того как для утверждения проекта проведена достаточная высокоуровневая оценка и анализ рентабельности инвестиций, дополнительная оценка работы может оказаться не столь полезной, как более быстрое выполнение фактической работы.
Источник: https://ardalis.com/the-5-laws-of-software-estimates/
👍8