Что ответить когда вас просят дать оценку сроков?

Нас, как программистов постоянно спрашивают «как много займёт времени эта задача?»

И ситуация, как вы знаете, почти всегда одна и та же:

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

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

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

Что же можно сделать в этой ситуации? Какой может быть способ определить и донести реальную оценку сроков? Какие техники могут оказаться полезными?

Ответ 1:

Как было сказано в книге «Программист-прагматик: от подмастерья к мастеру»

Ответьте «Я вернусь к вам с этим позже»

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

В этой секции авторы рекомендуют следующий процесс:

  • Определите требуемую точность оценки. Основываясь на продолжительности, вы можете давать оценки с разной точностью. Сказать «от 5 до 6 месяцев» не тоже самое, что сказать «150 дней». Если вы немного проскользнёте в 7 месяц, вы всё равно будете довольно точны. Но если это будет 180-ый или 210 день — уже не так точны.
  • Убедитесь, что вы точно понимаете, о чём вас спрашивают. Определите область проблемы.
  • Смоделируйте систему. Это может быть набросок от руки, диаграммы или существующие записи данных. Разбейте систему на компоненты/подзадачи и постойте оценки этим компонентам. Дайте значения времени и возможные отклонения для каждого компонента.
  • Посчитайте оценку, основанную на вашей модели.
  • Следите за оценками. Записывайте информацию о проблеме, которую вы оцениваете, данных вами оценках и реальных показателях.
  • Другие вещи, которые могут быть включены в оценку времени — это создание и документирование требований, или изменений которые необходимо сделать в спецификации требований, создание и изменение дизайна документов и спецификаций, тестирование (юнит-тестирование, интеграционные и приёмочные тесты), создание и изменение пользовательских документаций, файлов README. Если вместе работают 2 и более человек, существует оверхед на общение и взаимодействие (телефонные звонки, е-мэйлы, встречи) , слияние кода. Если это реально долгая задача, нужно учитывать такие вещи, как другая работа, отсутствие возможности работать (праздники, больничные, отпуска), и другие накладные расходы времени, которые могут увеличить время, необходимое на решение проблемы.

Ответ №2:

Оценка программного обеспечения — это наиболее сложная задача в программной инженерии. Вторая близкая по сложности — определение требований.

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

  • Хорошо взгляните на требования, которые у вас есть.
  • Сделайте допущения, чтобы заполнить дыры в требованиях, основываясь на ваших лучших догадках относительно того, что от вас хотят.
  • Запишите все ваши допущения.
  • Заставьте их сесть и согласиться со всеми вашими допущениями (или, если вам повезёт, составить настоящие требования на основе ваших допущений)
  • Теперь у вас есть требования, на основе которых можно строить оценки.

Моя мама говорила «Торопись и одень какую-нибудь одежду, иначе я приду и сделаю это сама!»

Ответ 3:

Один программист работал на очень непреклонного заказчика, который требовал очень точных оценок сроков. Его рассказ о том, как они урегулировали это, и этот приём работал очень хорошо:

  • Я брал плату за время, которое я проводил, оценивая задачи. Выходило около 20-25% от того, за что я получал деньги.
  • Я делал крайне детальные исследования задач. Никакой съёмки от бедра. Я лез в код, определял, какие строки нужно изменить, какие другие части программы это затронет, сколько тестов надо написать, чтобы убедиться, что всё работает также хорошо, как и раньше. Я оценивал каждый кусочек по 0,1 часа (то есть по 6 минут).
  • Я отправлял оценки на каждую задачу отдельно с детальной разбивкой.

20-25% звучит как «очень много».

Но он хотел попросить меня сделать изменение XYZ, думая, что это займёт 2 часа. За один час детальной оценки я понял, что это займёт 8,5 часов. После чего он решал, стоит ли стоит ли это изменение оплаты за 8, 5 часов. Если нет, он экономил 7,5 часов оплаты, которых бы стоили эти изменения, если бы я приступил к ним без предварительной оценки.

И если он хотел вложить 8,5 часов, чтобы задание было выполнено, детализация работы, которую я сделал, была бы сделана в любом случае.

Я заметил, что с таким подходом я мог выполнять задачи за время равное или меньшее чем то, которое я озвучивал без переоценок (имеется в виду озвучивание большего времени, чем кажется). Из-за того, что время было детализировано почти поминутно, я мог на раннем этапе сказать, что не укладываюсь во время, которое я озвучил изначально. Если я затормозил так, что после 3 часов работы понял, что задача, оценённая в 8,5 часов будет занимать 12, я мог сказать об этом прежде чем время пройдёт, так что он мог пересмотреть и прекратить разработку фичи, если он сомневался в цене.

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

Контрольные списки Стива Макконела

Контрольный список: требования

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

Специфические функциональные требования

— Определены ли все способы ввода данных в систему с указанием источника, точности, диапазона значений и частоты ввода?
— Определены ли все способы вывода данных системой с указанием назначения, точности, диапазона значений, частоты и формата?
— Определены ли все форматы вывода для Web-страниц, отчетов и т.д.?
— Определены ли все внешние аппаратные и программные интерфейсы?
— Определены ли все внешние коммуникационные интерфейсы с указанием протоколов установления соединения, проверки ошибок и коммуникации?
— Определены ли все задачи, в выполнении которых нуждается пользователь?
— Определены ли данные, используемые в каждой задаче, и данные, являющиеся результатом выполнения каждой задачи?

Специфические нефункциональные требования (требования к качеству)

— Определено ли ожидаемое пользователем время реакции для всех необходимых операций?
— Определены ли другие временные параметры, такие как время обработки данных, скорость их передачи и пропускная способность системы?
— Определен ли уровень защищенности системы?
— Определена ли надежность системы, в том числе такие аспекты, как следствия сбоев в ее работе, информация, которая должна быть защищена от сбоев, и стратегия обнаружения и исправления ошибок?
— Определены ли минимальные требования программы к объему памяти и свободного дискового пространства?
— Определены ли аспекты удобства сопровождения системы, в том числе способность системы адаптироваться к изменениям специфических функций, ОС и интерфейсов с другими приложениями?
— Включено ли в требования определение успеха? Или неудачи?

Качество требований

— Написаны ли требования на языке, понятном пользователям? Согласны ли с этим пользователи?
— Нет ли конфликтов между требованиями?
— Определено ли приемлемое равновесие между параметрами-антагонистами, такими как устойчивость к нарушению исходных предпосылок и корректность?
— Не присутствуют ли в требованиях элементы проектирования?
— Согласован ли уровень детальности требований? Следует ли какое-нибудь требование определить подробнее? Менее подробно?
— Достаточно ли ясны и понятны требования, чтобы их можно было передать независимой группе конструирования? Согласны ли с этим разработчики?
— Каждое ли требование релевантно для проблемы и ее решения? Можно ли проследить каждое требование до его источника в проблемной среде? Можно ли протестировать каждое требование? Можно ли будет провести независимое тестирование, которое позволит сказать, выполнены ли все требования?
— Определены ли все возможные изменения требований и вероятность каждого изменения?

Полнота требований

— Указаны ли недостающие требования, которые невозможно определить до начала разработки?
— Полны ли требования в том смысле, что если приложение будет удовлетворять всем требованиям, то оно будет приемлемо?
— Не вызывают ли какие-нибудь требования у вас дискомфорта? Исключили ли вы требования, которые не поддаются реализации и были включены лишь для успокоения клиента или начальника?

Контрольный список: архитектура

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

Специфические аспекты архитектуры

— Ясно ли описана общая организация программы? Включает ли спецификация грамотный обзор архитектуры и ее обоснование?
— Адекватно ли определены основные компоненты программы, их области ответственности и взаимодействие с другими компонентами?
— Все ли функции, указанные в спецификации требований, реализуются разумным, не слишком большим и не слишком малым, числом компонентов?
— Приведено ли описание самых важных классов и их обоснование?
— Приведено ли описание организации данных и ее обоснование?
— Приведено ли описание организации и содержания БД?
— Определены ли все важные бизнес-правила? Описано ли их влияние на систему?
— Описана ли стратегия проектирования GUI?
— Сделан ли GUI модульным, чтобы его изменения не влияли на оставшуюся часть программы?
— Приведено ли описание стратегии ввода-вывода данных и ее обоснование?

Основы разработки ПО

— Указаны ли оценки степени использования ограниченных ресурсов, таких как потоки, соединения с БД, дескрипторы, пропускная способность сети? Приведено ли описание стратегии управления такими ресурсами и ее обоснование?
— Описаны ли требования к защищенности архитектуры?
— Определяет ли архитектура требования к объему и быстродействию всех классов, подсистем и функциональных областей?
— Описывает ли архитектура способ достижения масштабируемости системы?
— Рассмотрены ли вопросы взаимодействия системы с другими системами?
— Описана ли стратегия интернационализации/локализации?
— Определена ли согласованная стратегия обработки ошибок?
— Определен ли подход к отказоустойчивости системы (если это требуется)?
— Подтверждена ли возможность технической реализации всех частей системы?
— Определен ли подход к реализации избыточной функциональности?
— Приняты ли необходимые решения относительно «покупки или создания» компонентов системы?
— Описано ли в спецификации, как повторно используемый код будет адаптирован к другим аспектам архитектуры?
— Сможет ли архитектура адаптироваться к вероятным изменениям?

Общее качество архитектуры

— Все ли требования отражены в архитектуре?
— Является ли какая-нибудь часть системы чрезмерно или недостаточно проработанной? Заданы ли явные ожидания по этому поводу?
— Является ли вся архитектура концептуально целостной?
— Независим ли высокоуровневый проект системы от платформы и языка, который будет использован для его реализации?
— Указаны ли мотивы принятия всех основных решений?
— Удовлетворяет ли вас — программиста, который будет реализовывать систему, — разработанная архитектура?

Контрольный список: предварительные условия

— Установили ли вы тип проекта, над которым работаете, и адаптировали ли вы к нему свой подход?
— Достаточно ли хорошо определены и достаточно ли стабильны требования для начала конструирования? (См. контрольный список вопросов о требованиях).
— Достаточно ли хорошо определена архитектура для начала конструирования? (См. контрольный список вопросов об архитектуре).
— Рассмотрели ли вы другие, уникальные для конкретного проекта факторы риска, чтобы они не снижали эффективность конструирования?

Контрольный список: основные методики конструирования

Кодирование

— Решили ли вы, какая часть проекта приложения будет разработана предварительно, а какая во время написания кода?
— Выбрали ли вы конвенции именования программных элементов, оформления комментариев и форматирования кода?
— Выбрали ли вы специфические методики кодирования, определяемые архитектурой приложения? Определили ли вы, как будут обрабатываться ошибки, как будут решаться проблемы, связанные с безопасностью, какие конвенции
будут использоваться при разработке интерфейсов классов, каким стандартам должен будет отвечать повторно используемый код, сколько внимания нужно будет уделять быстродействию приложения при к одировании и т. д.?
— Определили ли вы стадию развития используемой технологии и адаптировали ли к ней свой подход? Если это необходимо, определились ли вы с
тем, как будете программировать с использованием языка, вместо того чтобы ограничиваться программированием на нем?

Работа в группе

— Определили ли вы процедуру интеграции? Иначе говоря, какие специфические действия программист должен будет выполнить перед включением своего кода в исходный код всего проекта?
— Будут ли программисты программировать парами, индивидуально или эти подходы будут скомбинированы?

Гарантия качества

— Должны ли будут программисты разработать тесты для своего кода до написания самого кода?
— Должны ли будут программисты разработать блочные тесты для своего кода?
— Должны ли будут программисты перед включением своего кода в исходный код всего проекта проанализировать его в отладчике?
— Должны ли будут программисты выполнить интеграционное тестирование своего кода до его включения в исходный код проекта?
— Будут ли программисты выполнять взаимные обзоры или инспекцию кода?

Инструменты

— Выбрали ли вы инструмент управления версиями?
— Выбрали ли вы язык, версию языка и версию компилятора?
— Выбрали ли вы платформу программирования (такую как J2EE или Microsoft .NET) или явно решили не использовать ее?
— Приняли ли вы решение о том, можно ли будет использовать нестандартные возможности языка?
— Определили ли вы другие средства, которые будете применять: редактор, инструмент рефакторинга, платформу для тестирования, модуль проверки синтаксиса и т. д.? Приобрели ли вы их?