Как расчитать время на реализацию task-а?

Я full-stack разработчик.
Почти год тружусь в компании где PHP-программисты это редкость. А точнее я один.
Команда формируется из: 1 ПМ(project manager), 1 QA, 1 Full-stack, ... .
PM в кодинге ноль. Его задача только общение с клиентом и командой. Скорее всего на его плечах и другие важные задачи, но мне не известно.

У меня постоянно возникает проблема с estimate-ами. Так как, для анализа времени выделяется очень мало времени, и приходиться на глаз прикидывать.

Причины просрочки сроков бывают различные. К примеру:
- - Неправильно подобранные плагины. Из-за чего тратится время на поиск подходящих.
- - Клиентские правки, которые присылаются в процессе реализации таск-а.
- - Различные непредвиденные БАГ-ги. на которые приходиться порой затрачивать больше времени.
- ... .

И многое другое, что в итоге влечёт за собой отсрочку срока сдачи проекта.

Пытался уже найти информацию о том как правильно рассчитывается время.
Боб мартин предлагает использовать формулу "PERT". Но с результатами данной формулы не согласно мое начальство и клиенты. Мол, это много.


Собственно у меня вопрос.
Кто как рассчитывает время для реализации task-ов, и в итоге у кого получается уложиться в срок ?
  • Вопрос задан
  • 243 просмотра
Пригласить эксперта
Ответы на вопрос 3
Robur
@Robur
Знаю больше чем это необходимо
Но с результатами данной формулы не согласно мое начальство и клиенты. Мол, это много.

А как с результатами данной формулы согласуется реальность? Если подходит, то "это много" - чисто дипломатическая задача.
Если ситуация такая что вы говорите "4 часа" и всем "это много", а когда говорите "1 час", и потом все равно делаете 4 часа - это ок, то реально оценка 4 часа.
А если от вас в принципе ждут более быстрой работы чем вы выдаете, и из-за этого напряги, то тут два варианта:
- либо вы действительно медленно все делаете
- либо у менеджмента завышенные и неадекватные ожидания.

нужно определить какой вариант - ваш и действовать в соответствии.

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

еще вот такой метод очень популярен:
Собрал с разработчиков оценку, посчитал. Надо заложить риски.
- умножить на два?
- Нет, на два это не научно. Надо умножать на число e или на число пи, в зависимости от сложности проекта.
- А это как определяется? "E..., какой сложный" и "Пи... какой сложный"?
Ответ написан
Комментировать
inoise
@inoise
Solution Architect, AWS Certified, Serverless
На самом деле ничего сложного в этом нет. Надо иметь несколько эталонных задач, которые вы четко понимаете сколько времени делаете, например на 1/4, 1, 5 часов. Сопоставлять новые таски с ними и докидывать сверху относительно области не знания части задачи (а лучше вообще сначала сделать исследование чтобы такого не было) + накинуть на всякие коммуникации (все тоже из опыта берется)
Ответ написан
dimonchik2013
@dimonchik2013
non progredi est regredi
не парься, так у всех
https://www.youtube.com/watch?v=SQ4NAOU5Jso

главное - и это главное что ты должен вынести их этого топика - соскакивай с PHP
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы