Как оценивать время на аналитические активности?

[Юрий ВеденинАдмин]

Я думаю, многим приходилось отвечать на вопрос "Сколько у тебя займет … ?" Вариантов "…" много:
- извлечь требования
- написать ТЗ
- провести интервью
- перечитать документ и составить вопросы
- ознакомиться с системой и оценить создание спецификации на неё
- создать макеты будущего сайта
- и т.д.
Какие способы, методы и приёмы вы используете? А если вы готовы поделиться хитростями и примерами подводных камней, то это вообще будет здоровски! (: Будет интересно услышать мнение, как бобров, так и начинающих бобрят (;

Поделиться:

Цитировать

[Sergey.ShimanskyПодписчик]

Отличный вопрос!
Я всегда декомпозирую задачу до того уровня, когда оценить активности не составляет проблем. Т.е. если стоит задача написать докумет, я пытаюсь выделить его секции и оценить трудоемкость разработки каждой из них. Если задача стоит шире, напр. сбор требований к системе, я максимально декомпозирую (исходя из первичного представления) на модули, функции, фичи, и оцениваю каждую в отдельности. Вообще, я заметил, что принцип "разделяй и властвуй" подходит для оценки большинства аналитических активностей.

Поделиться:

Цитировать

[Герман ШестеровАдмин]

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

На самом деле сложно это.. и я дико не люблю давать оценки на высокоуровневые аналитические активности… хотя и часто приходится. Недавно столкнулся с задачей "оценить, сколько времени потребуется на введение нового аналитика в проект". И вариации — jr, staff, senior, знакомый с доменом, не знакомый и т.д. (а "проект" — это сложный с точки зрения бизнеса продукт, разрабатывающийся уже больше года). Вот и крутись .

Что касается подводных камней и трудностей, наиболее очевидное, что мне приходит в голову:
- response time заказчика и его адекватность;
- потенциально упущенные требования (на самом деле, открываем Вигерса, читаем характеристики идеальных требований, и все, что им противоречит, — потенциальный риск, влияющий на эстимации).

Как с этим бороться: опыт + тщательное обдумывание эстимаций + закладка соответствующих рисков.

Поделиться:

Цитировать

[Igor TkachenkoПодписчик]

Может где-то почитать про это есть?
Или у кого-то есть по софтверным оценкам какие-то статистические цифры?
Например: Чтобы сгенерировать разработчикам работы на X часов нужен 1 час работы аналитика при работе с такой-то технологической платформой и в рамках такой-то предметной области?
Понимаю, что статистика вещь каверзная но всё-таки.

Поделиться:

Цитировать

[Юлия ШамрейУчастник]

"phyro" написал(а):

Может где-то почитать про это есть?
Или у кого-то есть по софтверным оценкам какие-то статистические цифры?
Например: Чтобы сгенерировать разработчикам работы на X часов нужен 1 час работы аналитика при работе с такой-то технологической платформой и в рамках такой-то предметной области?
Понимаю, что статистика вещь каверзная но всё-таки.

Эти цифры сугубо индивидуальны и зависят от большого количества факторов:

Чтобы сгенерировать разработчикам работы на X часов нужен 1 час работы аналитика Y квалификации с Z количеством лет работы с технологической платформой и A количеством лет работы с предметной областью при работе с такой-то технологической платформой и в рамках такой-то предметной области, при B количествае параллельных проектов, в которых участвует аналитик, при миллионе других условий, которые специфичны для каждой конкретной ситуации

Поделиться:

Цитировать

[Автор]

Сообщения