Каждый из программистов и руководителей разработки хоть раз, но попадал на сроки, т.е. нарушал их, сильно или не очень.

Попробуйте открутить назад все Ваши проекты и оцените реальное опоздание по ним.

Может оказаться, что задержки достигают просто гигантских значений.

Автор статьи видел проекты с задержкой сроков в 400% и 700%!

Бытует мнение, что разрабатывать программы без опоздания невозможно в принципе.

Вообще, причина такой точки зрения ясна, ведь люди не провидцы и не могут видеть будущее.

На момент оценки трудоемкости ТЗ есть не всегда. И даже если оно есть, фактор неизвестности всё равно продолжает играть огромную роль – ведь люди, к сожалению, действительно не провидцы, и каким бы подробным не было ТЗ, всё равно остаются моменты, скрытые от глаз.

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

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

Практика показала, что можно достигнуть 20% точности (=%ошибки) при оценке. А ведь опоздание 20% это совсем не 700%, верно?

Как это сделать?

С чего начать

Суть в альтернативах!

Прелесть сценариев использования в том, что они расписывают не только основной ход событий, но и все возможные и невозможные альтернативные ситуации. А альтернативы – это и есть те самые подводные камни, из-за которых и возникают ошибки в оценке трудоемкости.

Как же посчитать трудоёмкость с помощью сценариев?

Представьте, что Вам нужно запрограммировать вот такое небольшое окошко:

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

Вкратце распишем сценарий:

Сценарий использования «Найти документ»

Успешный результат: выбранный документ прописан в свойство какого-то объекта

Основной успешный сценарий

1.Пользователь вводит поисковую фразу.
2.Система выводит список подходящих документов, в названии которых есть искомая фраза. Документы представлены своим названием. Список упорядочен по алфавиту.
3.Пользователь выбирает один из документов.
4.Система прописывает выбранный документ в нужный объект.

Альтернативы

2а.Пользователь хочет найти документы по состоянию на указанную дату
1.Система выводит список подходящих документов, ограниченных по дате создания. Исполнение продолжается согласно п.3.

2б.Пользователь хочет найти документ в архиве
1. 1.Система выводит список подходящих действующих и архивных документов. Исполнение продолжается согласно п.3.

3а.Не найдено ни одного документа
1.Система выводит сообщение: «Не найдено ни одного документа». Исполнение продолжается согласно п.1.

Обратите внимание, что сценарий разделен на две части: «Основной успешный сценарий» и «Альтернативы».

А теперь подумайте, как обычно происходит оценка трудоёмкости? Думаю, Вы согласитесь, что работу обычно оценивают только по успешному сценарию (как самому очевидному, приходящему на ум в первую очередь), а про альтернативы не думают вообще.

В этом и заключается суть проблемы – именно в альтернативах часто зарыта основная трудоёмкость.
Пойдём дальше.

В примере италиком отмечены операции, которые программисту нужно запрограммировать.

В альтернативах можно увидеть две операции, которых нет в основном сценарии. Давайте подумаем, что представляют из себя эти операции? По сути это обычные SQL-запросы к базе, но!

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

Использование сценариев позволяет вытащить на свет все эти альтернативы (или большинство из них), и т.о. в несколько раз точнее оценить итоговую трудоёмкость работы.

Как оценить трудоёмкость

Давайте сведём всю информацию по сценарию в одну таблицу и попробуем посчитать сколько времени у нас займёт реализация:

Создание инфраструктуры классов – 1ч
Формирование окна – 2ч
Вывод списка документов по ключевой фразе – 1ч
Вывод списка документов с учётом даты создания – 1ч
Вывод списка документов с учётом архивных – 1 ч
Прописывание выбранного документа в свойства объекта – 1ч
Тестирование 4 * 0,5ч = 2ч
Итого: 9 ч

Как видите, в оценке учтены дополнительные 2ч на реализацию альтернатив и еще 1ч на их тестирование. А если бы оценка проводилась только по успешному сценарию, то этих 3-х часов мы бы не досчитались.

А это почти 50% времени (6ч на основной сценарий и 3ч на альтернативы)!

Итоги

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

P.S.А как быть, если сценариев ещё нет?

Если на момент оценки Вы ещё не расписали сценарии, попробуйте хотя бы вкратце набросать основные альтернативы. Это уже хорошо улучшит оценку.

P.P.S. Где еще зарыта свинья

Бывает так, что шаги сценария недостаточно мелкие. Представьте, например, что в система должна опубликовать какие-либо данные.

Как Вы понимаете, под «публикацией» может быть скрыт целый ворох действий, которые трудно определить сразу.

Такие ситуации очень легко определяются, когда в оценке трудоемкости ставится время > 3ч. Это однозначно указывает на то, что человек, дающий оценку, не знает, что скрыто внутри. И там 100% сидит БОЛЬШАЯ засада! Проверено многократно.

В таком случае обязательно продумывайте и прописывайте, что скрыто внутри, иначе можно очень сильно попасть на сроки.

Автор: varenich

Источник