Одного не могу понять, как валью\кост может быть выше чем у PSP, если последний являет собой откровенное шарлатанство, не решающее ни одной реальной проблемы в софтвер девелопменте? :)
Если последний являет собой откровенное шарлатанство, то value/cost первого получается по любому выше. :) Не понимаю, что тут может быть непонятного? :)
Да ладно тебе Влад, это я, Давид из Еревана, работали вместе в сикьюдже. Неужели ты серьезно PSP считаешь за серьёзную технологию? Не ожидал, не ожидал, вот честно скажу. Я думал, ты понимаешь что это за хуйня шарлатанская, с этими институтом коучества за дикое бабло.
Если совсем кратко, вопрос шарлатанства PSP/TSP сводится на самом деле к одному простому вопросу - существуют ли корреляции между метриками сроков и объема.
Значимые корреляции объективно существуют, и это несложно проверить. Вот, собственно, и все.
Ну вот в том-то и дело, что никаких корреляций нет. Если помнишь, в PSP всегда открытым оставался вопрос метрик, оценивающих продуктивность. Типа, давайте использовать, а там разберемся. А потом выяснилось, что нет ни одной достоверной метрики, что позволяет оценить продуктивность (по сути вклад в проект). Строки? Сам помнишь к чему это приводило. Плотность багов? Опять таки бред. Выполняемость сроков? Опять сбой. Если процессы разработки софта имели простые линейные зависимости, то всё конечно было бы хорошо. Но проблема в том, что зависимости не то чтобы нелинейные, они даже не экспоненциальные, а скорее гиперболические - как в современной демографии
( ... )
Ты прав - в учебных задачах это работало. Но никто почему-то не замечал, что они были так хитро устроены, что каждая следующая задача использовала результаты предыдущей, человек войдя в курс дела, каждую следующую задачу, делал быстрее, чем предыдущую, что разумеется и создавало иллюзию что это работает. Ещё бы, на то это и учебный курс, чтобы на нём работало, иначе б его никто не покупал :) В реальной жизни, к сожалению, такого удачного стечения обстоятельств не бывает.
Насчёт же измерения продуктивности, да, ты предъявляешь стандартный аргумент PSP разработчика, мол, мы не ставим оценки. Но ведь CQG это делала, поскольку, если мы признаем действенность PSP и получается, что один человек делает свой проект с расчётным количеством метрик, то он молодец, а если другой, делает с другими метриками, значит он очевидно, прохлаждается на работе. А дело могло быть всего лишь навсего в том, что один быстро-быстро, чтобы попасть в метрики, наляпал работающий проект с часовой бомбой внутри, а другой - просёк все проблемы, и решил их предотвратить заранее, в результате, получилось, он плохой разработчик.
> Ты прав - в учебных задачах это работало. Но никто почему-то не замечал, что они были так хитро устроены, что каждая следующая задача использовала результаты предыдущей, человек войдя в курс дела, каждую следующую задачу, делал быстрее, чем предыдущую, что разумеется и создавало иллюзию что это работает
( ... )
Я это и имел ввиду, они показывали, что со временем, у тебя предсказуемость показателей становилась выше. Но это было очевидно, потому что каждая предыдущая задача сочетала черты предыдущей, и само собой, предсказывать объем становилось на порядок легче. К примеру, когда я проходил этот курс, я сделал все на темлитных функторах, практически методами функционального программирования, так у меня вообще сходимость была идеальная, но она лишь означала, что задачи хорошо подобраны.
Насчёт остального, зачём загонять что-то в эксел, когда производительность в каждом проекте может меняться в разы, в зависимости от того, какое ключевое решение будет принято на разных этапах проекта. Тут уже никакой статистики нет и быть не может. Ну что я загоню, если в одном проекте, функционал, равный N строчкам кода в другом проекте равен 100*N строчкам? Лишь за счёт изменения технологии и общего подхода. Что тут можно кореллировать, не пойму.
Reply
Reply
Reply
Reply
Reply
Вам, собственно, предупреждение. Следующий подобный комментарий будет удален, и вы будете забанены в данном журнале.
Reply
Reply
Reply
Значимые корреляции объективно существуют, и это несложно проверить. Вот, собственно, и все.
Reply
Reply
Reply
Насч
Reply
Reply
Reply
Reply
Насчёт остального, зачём загонять что-то в эксел, когда производительность в каждом проекте может меняться в разы, в зависимости от того, какое ключевое решение будет принято на разных этапах проекта. Тут уже никакой статистики нет и быть не может. Ну что я загоню, если в одном проекте, функционал, равный N строчкам кода в другом проекте равен 100*N строчкам? Лишь за счёт изменения технологии и общего подхода. Что тут можно кореллировать, не пойму.
Reply
Leave a comment