Эм, а можно немного подвинуть розовую область?
В повседневной жизни мы постоянно пытаемся всё оценивать: сколько мне нужно времени, чтобы добраться на работу? Сколько денег я трачу в месяц? Достаточно ли у меня еды для предстоящей большой вечеринки? И так далее…
Кажется, постоянная оценка всего вокруг — это часть нашей жизни. Так что не удивительно обнаружить то же самое и в разработке ПО.
Все мы слышали о проектах, выход которых откладывался снова и снова, так? Может быть, это из-за того, что команда не могла правильно оценить сколько времени им нужно?
Позвольте задать вопрос: сколько времени нужно, чтобы попасть из Парижа в Лондон? (Правильный ответ: «Как получится»).
Могут быть варианты от 1 до 10 часов или даже больше, правильно? Заметьте — я только спросил, сколько времени потребуется, но не говорил, как именно это нужно сделать. Это важно, так как оставляет нам на выбор множество способов путешествия. И поскольку ничего явно не указано, каждый может выбрать свой способ. Кто-то решит добираться на самолёте, кто-то — на поезде, некоторые, возможно, на машине или даже на велосипеде.
Обсудив все способы, мы решили, что быстрее всего будет лететь на самолёте. И мы должны быть в Лондоне не позже, чем через два часа, правильно? А теперь угадайте, где из-за плохой погоды отменили авиарейсы. Понимаете, к чему всё идёт?
С оценкой времени на разработку всё ещё хуже…
Для программных проектов сделать точную оценку намного сложнее. Для этого есть даже специальный термин "scope creep" — неконтролируемый рост рамок проекта. Не думайте, что это применимо только к старым, монолитным проектам, которые давно прошли свой пик. Даже в современных приложениях вам нужно знать, сколько времени нужно, чтобы исправить последние ошибки, из-за которых пользователь не хочет покупать продукт. Время — деньги, не так ли?
Как мы можем это исправить? Есть несколько техник, о которых я надеюсь рассказать в ближайших постах. Но давайте начнём сейчас с небольшого примера.
Оценивать тем проще, чем больше у вас информации о задаче, которую вы собираетесь выполнять. Так выглядит идеальный случай, но, как мы знаем, это не всегда так. Что мы делаем, если у нас недостаточно информации? Мы должны сделать Предположение! Поможет ли это улучшить оценку? Вряд ли, но это хотя бы даст какую-то почву, пока вы не узнаете недостающую информацию.
Давайте посмотрим, как это действует на примере задачи...
Задача
Представьте вопрос заказчика: сколько времени понадобится, чтобы реализовать новую деталь, связанную с вкладами?
Посмотрите на код:
interface Bank {
boolean depositFunds(Funds funds);
}
Всё, что вам нужно сделать, это реализовать интерфейс. Сколько времени вам понадобится? Подсказка: здесь нет правильного или неправильного ответа и вам, вероятно, нужно сделать некоторые предположения.
Перевод статьи Roberto Cortez, оригинал на ZeroTurnAround.
Автор: WarAngel_alk
