Software People: вторая презентация

May 23, 2009 22:40

Так получилось, что во второй день конференции один из докладчиков не смог прийти, и меня попросили его заменить ( Read more... )

оценка трудозатрат, планирование, декларативное планирование, управление проектами

Leave a comment

Comments 42

инструменты? maqdev May 24 2009, 07:24:57 UTC
Скажите, а у вас есть какие то готовые инструменты, которые облегчают оценку трудозатрат, с учетом ваших изменений в PERT формуле? Например шаблон простого Excel файла с формулами, я так понимаю был бы уже полезен.

Reply

Re: инструменты? gaperton June 2 2009, 15:35:44 UTC
Сделаю таблицу в Excel - выложу.

Reply


alik_kurdyukov May 25 2009, 09:31:02 UTC
Эээх, жаль что не удалось послушать. Будем ждать видео от CareerLab.

Reply


dima117 June 2 2009, 12:11:46 UTC
добрый день!
рад, что увидел в инете ваш жж.. нашел в нем много интересного.. спасибо!

есть вопросы по второму вашему докладу:

1. обычно оценка сроков выполняется на основе оценки объема работ. если мы хотим независимые оценки сроков и объема работ, на основании чего нам делать предположения о сроках?
2. метрики не всегда объективно показывают объем.
разные строчки кода (в смысле, в разных классах проекта) требуют у разных людей разное время для написания. также не понятно, как учитывать задачи, на которые уходит время, но при этом пишется мало кода (или не пишется вообще), например, верстка HTML.

Reply

dima117 June 2 2009, 13:06:21 UTC
пришли к выводу, что независимая оценка времени может происходить на основе опыта и статистики по прошлым задачам.
но все равно не понятно, какую метрику взять, чтобы получить адекватную оценку объема работы.

Reply

gaperton June 2 2009, 13:15:35 UTC
1. Правильно.
2. ...адекватную оценку объема работы.

Вопрос "адекватности" - это метафизический вопрос. В качестве метрики объема для целей прогноза надо брать не метрику, кажущуюся Вам "адекватной", а ту метрику, которая дает лучшие корреляции со временем работы. Исследования Сarnegie-Mellon SEI показывают, что лучшие корреляции со временем дает метрика SLOC, то есть строки кода, в которых в принципе возможно допустить ошибки.

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

Reply

dima117 June 3 2009, 05:36:17 UTC
>> Помимо лучших корелляций, она обладает также рядом важных преимуществ перед сложными метриками, такими как Cyclomatic Complexity - а именно, она элементарно поддается не только подсчету, но и предсказанию. Это важно.

Подсчитать, действительно, легко. Но на счет предсказания - не могу согласиться.

Пример:
Один программист в нашей компании за день написал 100 строк кода, который генерировал прокси-классы для слоя доступа к данным.
Другой программист за этот же день написал 1000 строк кода - PL/SQL пакет.
Разве это значит, что один программист работает медленнее другого?

При этом каждый из них легко оценил заранее требуемое на задачу время.

Reply


zubian August 25 2009, 15:23:51 UTC
Одного не могу понять, как валью\кост может быть выше чем у PSP, если последний являет собой откровенное шарлатанство, не решающее ни одной реальной проблемы в софтвер девелопменте? :)

Reply

gaperton August 25 2009, 15:34:49 UTC
Если последний являет собой откровенное шарлатанство, то value/cost первого получается по любому выше. :) Не понимаю, что тут может быть непонятного? :)

Reply

zubian August 25 2009, 15:55:36 UTC
Вот и я о том же, что угодно будет лучше чем ничего, в чём же преимущество? :)

Reply

gaperton August 25 2009, 16:22:47 UTC
Чего угодно перед ничем? Да буквально во всем, что же тут непонятного :).

Reply


Leave a comment

Up