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