можете рассказать о своих историях успеха применения техник оценки трудоемкости разработки ПО на начальных этапах проекта.
Интересует опыт применения таких страшных слов как: COCOMO/COCOMO II, FPA (и его вариаций), (Wideband) Delphi, SLIM, PROBE, T-Shirt.
Заранее спасибо.
success stories — это что?
Типа один раз посидели, сделали оценки на проект длительностью
в 9 месяцев на 40 человеко лет, и так и получилось?
Так практически не бывает.
Оценки — это именно оценки.
Толку от них ноль, если нету постояного отслеживания текущий ситуации на проекте,
с последующей реакцией, которая запросто может включать и перепланирование.
Т.е. рассматривать исключительно формальные методы оценок как раз не интересно.
Если кто-то на проекте использовал COCOMO и проект был успешен, то это точно не из-за полного понимания COCOMO.
А так был у меня опыт использования и COCOMO, и Delphi.
В последнее время вот оценками в стиле SCRUM занимается.
Мое мнение — оценки несомненно нужны, но гораздо важнее именно отслеживание ситуации с последующей реакцией.
Здравствуйте, bkat, Вы писали:
B>success stories — это что?
Это описание успешного опыта в интересующей меня области
B>Типа один раз посидели, сделали оценки на проект длительностью B>в 9 месяцев на 40 человеко лет, и так и получилось?
Ну, если получилось так, то тоже пойдет
B>Оценки — это именно оценки. B>Толку от них ноль, если нету постояного отслеживания текущий ситуации на проекте, B>с последующей реакцией, которая запросто может включать и перепланирование.
Дык, вот это и интересно было бы услышать.
Что-то типа "мы использовали такой-то метод(ы) вот так-то и у нас получилось"
В "так-то" как раз и входит описываемый тобой контекст.
Здравствуйте, 0x7be, Вы писали:
B>>Оценки — это именно оценки. B>>Толку от них ноль, если нету постояного отслеживания текущий ситуации на проекте, B>>с последующей реакцией, которая запросто может включать и перепланирование. 0>Дык, вот это и интересно было бы услышать. 0>Что-то типа "мы использовали такой-то метод(ы) вот так-то и у нас получилось" 0>В "так-то" как раз и входит описываемый тобой контекст.
Да банально все получается.
Вот использовали мы Дельфи.
В самом начале сделали грубые оценки на проект длительностью 1.5 года.
Через пол года заметили, что вылезаем за сроки.
Выкинули пару фич и провели перепланирование.
Еще через пару месяцев заметили что опять не влезаем.
Провели перепланирование и сдвинули сроки на 3 месяца.
Еще через 3 месяца заметили, что опять не влезаем.
Опять выкинули некритичные фичи и в итоге влезли.
Это успешный опыт?
На мой взгляд да, зная насколько сложным был проект и сколько новых людей было.
Формально мы задежались на 3 месяца и многими вещами пожертвовали.
Т.е. формально сфейлили...
Ну а сами методы описаны в разных статьях.
Один черт в новой команде будет все слегка по-другому и немного не так, как пишут в книжках.
В последнее время я вообще склоняюсь к мнению, что если разбить всю работу на небольшие обозримые подзадачи,
то ты вообще можешь использовать генератор случайных чисел для оценки каждой подзадачи.
В целом оценки будут достаточно хорошими
Трюк тут состоит именно в разбивании на понятные, небольшие, обозримые подзадачи.
Оценка каждой конкретной подзадачи почти всегда будет неверна,
но это и не важно на самом деле...
Гораздо важнее уметь определять где ты находишься.
А оценки — они всегда неверны.
Здравствуйте, bkat, Вы писали:
B>...Это успешный опыт? B>На мой взгляд да, зная насколько сложным был проект и сколько новых людей было. B>Формально мы задежались на 3 месяца и многими вещами пожертвовали. B>Т.е. формально сфейлили...
Все относительно
Относительно того состояния дел, с которым приходится иметь дело мне — это ОЧЕНЬ успешный опыт
Здравствуйте, 0x7be, Вы писали:
0>Все относительно 0>Относительно того состояния дел, с которым приходится иметь дело мне — это ОЧЕНЬ успешный опыт
Ну в общем да. Все относительно.
Но относительный успех был достигнут не за счет конкретной методики оценивания, а за счет того, что:
— мы вообще занимались планированием
— ПМ реально отслеживал что сделано и как это соотносится с текущими планами. Ну и плюс он реагировал когда надо.
— у нас были эксперты, которые отлично знали предметную область и были в состоянии разбить все на мелкие подзадачи
— грамотный СМ и bag tracking
— хороший дизайн, который был многократно отревьюен
— юнит тесты
B>Но относительный успех был достигнут не за счет конкретной методики оценивания, а за счет того, что:
Я понимаю, что успех проекта — это синергия сразу многих практик.
Просто сейчас я "захожу" в это хитросплетение со стороны оценки, потому и интересуюсь контекстом применения.
К сожалению, не перечисленные тобой пункты есть у меня в активе
B>Но возвращаясь к твоему прошлому вопросу
, B>влияние той или иной практики на общий результат я лично оценить не смогу. B>Влиянием же именно Делфи вообще можно проигнорировать.
Понятно, спасибо.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, bkat, Вы писали:
B>>...Это успешный опыт? B>>На мой взгляд да, зная насколько сложным был проект и сколько новых людей было. B>>Формально мы задежались на 3 месяца и многими вещами пожертвовали. B>>Т.е. формально сфейлили... 0>Все относительно 0>Относительно того состояния дел, с которым приходится иметь дело мне — это ОЧЕНЬ успешный опыт
В моем случае сильно не успешный. У нас задержка релиза на день уже проблема. Начинают разбираться в чем дело.
В редких исключительных ситуациях могут задержать на неделю но это исключение.
Здравствуйте, hpux100, Вы писали:
H>В моем случае сильно не успешный. У нас задержка релиза на день уже проблема. Начинают разбираться в чем дело. H>В редких исключительных ситуациях могут задержать на неделю но это исключение.
Очень важно КОГДА вы поняли что не успеваете.
В вашем случае, похоже, что знание о том, что будет задержка на 1 день приходит в день релиза, либо за пару дней (в виде девелопера к вам, либо в виде вас к девелоперу: "ты мне обещал что с утра все будет работать, почему не работает?",... продолжить любой из нас сможет, я уверен).
Тогда да, 1-2 дня это много. А неделя дается когда "ну совсем все плохо, а мы не в куГсе".
В данном же случае:
В самом начале сделали грубые оценки на проект длительностью 1.5 года. Через пол года заметили, что вылезаем за сроки.
Выкинули пару фич и провели перепланирование.
Еще через пару месяцев заметили что опять не влезаем.
Провели перепланирование и сдвинули сроки на 3 месяца. Еще через 3 месяца заметили, что опять не влезаем.
Опять выкинули некритичные фичи и в итоге влезли.
Т.е. за ПОЛ ГОДА до релиза были приняты меры чтобы сдать проект в срок. Это УСПЕХ.
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, hpux100, Вы писали:
H>>В моем случае сильно не успешный. У нас задержка релиза на день уже проблема. Начинают разбираться в чем дело. H>>В редких исключительных ситуациях могут задержать на неделю но это исключение. A>Очень важно КОГДА вы поняли что не успеваете. A>В вашем случае, похоже, что знание о том, что будет задержка на 1 день приходит в день релиза, либо за пару дней (в виде девелопера к вам, либо в виде вас к девелоперу: "ты мне обещал что с утра все будет работать, почему не работает?",... продолжить любой из нас сможет, я уверен). A>Тогда да, 1-2 дня это много. А неделя дается когда "ну совсем все плохо, а мы не в куГсе".
A>В данном же случае: A>
В самом начале сделали грубые оценки на проект длительностью 1.5 года.
A>Через пол года заметили, что вылезаем за сроки.
A>Выкинули пару фич и провели перепланирование.
A>Еще через пару месяцев заметили что опять не влезаем.
A>Провели перепланирование и сдвинули сроки на 3 месяца.
A>Еще через 3 месяца заметили, что опять не влезаем.
A>Опять выкинули некритичные фичи и в итоге влезли.
A>Т.е. за ПОЛ ГОДА до релиза были приняты меры чтобы сдать проект в срок. Это УСПЕХ.
A>СУВ, Aikin
тогда да, если заказчика устраивает объем а срок сдачи не сдвигался вообще, то успех.
Здравствуйте, hpux100, Вы писали:
H>В моем случае сильно не успешный. У нас задержка релиза на день уже проблема. Начинают разбираться в чем дело. H>В редких исключительных ситуациях могут задержать на неделю но это исключение.
Для какой отрасли проекты делаете?
