Почему так сложно оценивать сроки разработки (плюс задача для разработчиков)

в 14:59, , рубрики: gtd, оценка времени, разработка, управление временем, управление проектами

image
Эм, а можно немного подвинуть розовую область?

В повседневной жизни мы постоянно пытаемся всё оценивать: сколько мне нужно времени, чтобы добраться на работу? Сколько денег я трачу в месяц? Достаточно ли у меня еды для предстоящей большой вечеринки? И так далее…

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

Все мы слышали о проектах, выход которых откладывался снова и снова, так? Может быть, это из-за того, что команда не могла правильно оценить сколько времени им нужно?

Позвольте задать вопрос: сколько времени нужно, чтобы попасть из Парижа в Лондон? (Правильный ответ: «Как получится»).

Могут быть варианты от 1 до 10 часов или даже больше, правильно? Заметьте — я только спросил, сколько времени потребуется, но не говорил, как именно это нужно сделать. Это важно, так как оставляет нам на выбор множество способов путешествия. И поскольку ничего явно не указано, каждый может выбрать свой способ. Кто-то решит добираться на самолёте, кто-то — на поезде, некоторые, возможно, на машине или даже на велосипеде.

Обсудив все способы, мы решили, что быстрее всего будет лететь на самолёте. И мы должны быть в Лондоне не позже, чем через два часа, правильно? А теперь угадайте, где из-за плохой погоды отменили авиарейсы. Понимаете, к чему всё идёт?

С оценкой времени на разработку всё ещё хуже…

Для программных проектов сделать точную оценку намного сложнее. Для этого есть даже специальный термин "scope creep" — неконтролируемый рост рамок проекта. Не думайте, что это применимо только к старым, монолитным проектам, которые давно прошли свой пик. Даже в современных приложениях вам нужно знать, сколько времени нужно, чтобы исправить последние ошибки, из-за которых пользователь не хочет покупать продукт. Время — деньги, не так ли?

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

Оценивать тем проще, чем больше у вас информации о задаче, которую вы собираетесь выполнять. Так выглядит идеальный случай, но, как мы знаем, это не всегда так. Что мы делаем, если у нас недостаточно информации? Мы должны сделать Предположение! Поможет ли это улучшить оценку? Вряд ли, но это хотя бы даст какую-то почву, пока вы не узнаете недостающую информацию.

Давайте посмотрим, как это действует на примере задачи...

Задача

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

Посмотрите на код:

interface Bank {
	boolean depositFunds(Funds funds);
}

Всё, что вам нужно сделать, это реализовать интерфейс. Сколько времени вам понадобится? Подсказка: здесь нет правильного или неправильного ответа и вам, вероятно, нужно сделать некоторые предположения.


Перевод статьи Roberto Cortez, оригинал на ZeroTurnAround.

Автор: WarAngel_alk

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js