Коллеги, поделитесь опытом кто проходили подготовку по PSP\TSP и\или используете в работе.
Интересует следующее:
1) Насколько реально собирать все метрики, если разработчики не проходили курсы по PSP?
2) Насколько совместимо использование PSP\TSP и систем управления разработкой (в частности меня интересует TFS)? А то делать все на бумаге или в стороннем софте (сильно платном и сложном) как-то не улыбается. Может есть простые программы для этого?
3) Как производится оценка? Ведь статистика на основе LOC в современных языках слишком неточна.
Здравствуйте, gandjustas, Вы писали:
G>Интересует следующее: G>1) Насколько реально собирать все метрики, если разработчики не проходили курсы по PSP?
Собирать метрики — вполне реально. Для сбора цифр никакого PSP не нужно.
G>2) Насколько совместимо использование PSP\TSP и систем управления разработкой (в частности меня интересует TFS)? А то делать все на бумаге или в стороннем софте (сильно платном и сложном) как-то не улыбается. Может есть простые программы для этого?
Без использования специального PSP/TSP тула ему практически невозможно следовать. Без прохождения обучения — невозможно пользоваться тулом. PSP/TSP слишком сложный матан для этого, и здесь не должно быть никаких иллюзий.
Больше половины так толком ничего и не понимают, даже пройдя курс обучения, и не смогут провести реальный проект без помощи коуча. А после того, как коуч "поставит им руки", все равно не поймут, что произошло.
G>3) Как производится оценка? Ведь статистика на основе LOC в современных языках слишком неточна.
Оценка производится в результате статистического анализа, основанного на поиске корреляций метрик процесса разработки. PSP тул в состоянии выдать не только оценки, но и оценить их достоверность. Кроме того, он постоянно калибруется на свежепоступающих данных. В основе всего — статистическая модель процесса разработки, понимать которую необходимо, чтобы оптимизировать процесс.
Скажем так. Я понимаю PSP/TSP очень хорошо, практически на уровне хорошего коуча. Но при этом, не возьмусь его внедрять на команде, наверное, ни при каких обстоятельствах.
Это, в целом, слишком затратно, для того эффекта, который получается в результате. Понимая модель PSP/TSP, понимаешь также, что можно добиться близкого эффекта куда как более дешевыми способами. По этому поводу можно дискутировать, но что ясно 100% — тот результат, который PSP/TSP дает, такой ценой однозначно не нужен.
Здравствуйте, Gaperton, Вы писали:
G>Это, в целом, слишком затратно, для того эффекта, который получается в результате. Понимая модель PSP/TSP, понимаешь также, что можно добиться близкого эффекта куда как более дешевыми способами. По этому поводу можно дискутировать, но что ясно 100% — тот результат, который PSP/TSP дает, такой ценой однозначно не нужен.
Ну и кроме того, в типовом PSP/TSP есть объективные слабости. Пожалуй, главная — невозможность учета рисков в прогнозах и завязанность на "большие числа", и, как следствие, фактическая беспомощность процесса на "исследовательских" этапах. Это свойство его математики, и попытки заставить его работать выглядят скорее искусственно, хотя, разумеется, это возможно.
Эта слабость становится главной, и начинает играть тогда, когда PSP/TSP попадает в руки безмозглого менеджера. Учитывая матанистость методики, и, по видимости, высочайший порог вхождения из известных, это произойдет с вероятностью близкой к 100% — процесс слишком легко неправильно использовать.
Это все не отменяет фундаментальной ценности PSP/TSP для понимания процесса разработки и его анализа.
Здравствуйте, Gaperton, Вы писали:
G>Это все не отменяет фундаментальной ценности PSP/TSP для понимания процесса разработки и его анализа.
Потому что ценность огромная. Изучение PSP/TSP и опыт работы под ним должен быть обязателен в программе профильного высшего образования. Как это происходит, скажем, в Carnegie-Mellon SEI. Я лично очень ценю, что прошел этот курс.
Здравствуйте, Gaperton, Вы писали:
G>Скажем так. Я понимаю PSP/TSP очень хорошо, практически на уровне хорошего коуча. Но при этом, не возьмусь его внедрять на команде, наверное, ни при каких обстоятельствах.
G>Это, в целом, слишком затратно, для того эффекта, который получается в результате. Понимая модель PSP/TSP, понимаешь также, что можно добиться близкого эффекта куда как более дешевыми способами. По этому поводу можно дискутировать, но что ясно 100% — тот результат, который PSP/TSP дает, такой ценой однозначно не нужен.
Это я уже понял.
Какими способами можно добиться близкого эффекта? Всех программистов обучать в C-M SEI не получится, да и своими силами обеспечить подобное обучение нереально.
On 09.02.2013 15:22, Gaperton wrote:
> Оценка производится в результате статистического анализа, основанного на > поиске корреляций метрик процесса разработки. PSP тул в состоянии выдать > не только оценки, но и оценить их достоверность. Кроме того, он > постоянно калибруется на свежепоступающих данных. В основе всего — > статистическая модель процесса разработки, понимать которую необходимо, > чтобы оптимизировать процесс.
Добавил бы еще пунктик, что нужна достаточно большая выборка объектов с
которых снимаются метрики в течение достаточно длитеьного времени иначе
достоверность (так понимаю доверительные интервалы имеются в виду) будет
очень низкой.
Тул сами сделали? Молодцы, под таким соусом продавать то, что считает
основные статистики и доверительные интервалы. Честно, завидую таким людям.
Ну ладно без ерничания, факторный хоть есть?
On 09.02.2013 15:38, Gaperton wrote:
> Пожалуй, > главная — невозможность учета рисков в прогнозах и завязанность на > "большие числа",
Это как бы основная теорема ТВ.
Здравствуйте, Vzhyk, Вы писали:
>> Пожалуй, >> главная — невозможность учета рисков в прогнозах и завязанность на >> "большие числа", V>Это как бы основная теорема ТВ.
Иррелевантно. Методы, лишенные этих недостатков, существуют. Полагаются на экспертные оценки свойств распределения трудозатрат отдельных задач. На вскидку — моделирование Монте-Карло, и, попроще — PERT-подобные методы.
Здравствуйте, gandjustas, Вы писали:
G>Какими способами можно добиться близкого эффекта? Всех программистов обучать в C-M SEI не получится, да и своими силами обеспечить подобное обучение нереально.
Ну например, в одном из своих докладов я рассказывал про более простой подход для прогнозов сроков. Вторая половина презентации, идея в использовании коэффициентов продуктивности как проверочного коэффициента для прогнозов, и сознательном упрощении — отказе контролировать time-on-task, что снимает необходимость поминутно снимать время, и кучу ассоциированного с этим геморроя.
Только это далеко не все, что дает PSP. Сильная сторона PSP/TSP — их работа с метриками плотностей ошибок, и использование системы метрик для оптимизации процесса разработки. Можно было бы заняться и этим, но я не занимался. Но, думаю, должно быть много работ на эту тему.
Здравствуйте, Vzhyk, Вы писали:
V>Добавил бы еще пунктик, что нужна достаточно большая выборка объектов с V>которых снимаются метрики в течение достаточно длитеьного времени иначе V>достоверность (так понимаю доверительные интервалы имеются в виду) будет V>очень низкой.
В ходе двухнедельного тренинга ты каждый день решаешь по задачке, работая с тулом. Он неплохо калибруется к середине второй недели, и укладывает погрешность процентов в 5-10.
V>Тул сами сделали? Молодцы, под таким соусом продавать то, что считает V>основные статистики и доверительные интервалы. Честно, завидую таким людям.
Хорошего коммерчески доступного тула 10 лет назад не было. В CQG, например, тул писали сами. Суть тула не в основах статистики, это по сути хитрый трекер задач с особыми возможностями.
V>Ну ладно без ерничания, факторный хоть есть?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>Какими способами можно добиться близкого эффекта? Всех программистов обучать в C-M SEI не получится, да и своими силами обеспечить подобное обучение нереально.
G>Ну например, в одном из своих докладов я рассказывал про более простой подход для прогнозов сроков. Вторая половина презентации, идея в использовании коэффициентов продуктивности как проверочного коэффициента для прогнозов, и сознательном упрощении — отказе контролировать time-on-task, что снимает необходимость поминутно снимать время, и кучу ассоциированного с этим геморроя.
G>http://files.rsdn.ru/20496/ISV%20Oracle%20final.pdf
Это уже читал. У нас есть проблема, что продуктивность сильно скачет от разработчика к разработчику. Даже усредняя между участниками одного проекта может отличаться в разы.
G>Только это далеко не все, что дает PSP. Сильная сторона PSP/TSP — их работа с метриками плотностей ошибок, и использование системы метрик для оптимизации процесса разработки. Можно было бы заняться и этим, но я не занимался. Но, думаю, должно быть много работ на эту тему.
Вот это было бы интереснее всего. Проблемы у нас начинаются на этапе проектирования, потому что многие аспекты выпадают из внимания "не очень продуктивных" разработчиков и в итоге большой объем переделок и низкая продуктивность. Но, как я уже говорил, устроить обучение, аналогичное PSP нереально.
On 11.02.2013 15:41, Gaperton wrote:
> Иррелевантно. Методы, лишенные этих недостатков, существуют. Полагаются > на экспертные оценки свойств распределения трудозатрат отдельных задач.
Понятно. Проблема в экспертах.
> На вскидку — моделирование Монте-Карло,
Неа. Монте-Карло на законе больших чисел — он ни на грамм не выходит за
рамки классической ТВ.
и, попроще — PERT-подобные методы.
Это не знаю, возможно.
Есть и хорошая русская литература, статьи. Смешно, но когда-то
разбирался в нем по статье, в которой применили факторный анализ к
размножению кроликов и поиску скрытых факторов, влияющих на это.
On 11.02.2013 16:38, gandjustas wrote:
> Это уже читал. У нас есть проблема, что продуктивность сильно скачет от > разработчика к разработчику. Даже усредняя между участниками одного > проекта может отличаться в разы.
Мне тоже интересно, что Гапертон ответит. По идее вы попали в ситуацию,
что либо данных мало, либо закон больших чисел в вашем случае не
действует либо разработчики у вас настлько различны.
> Вот это было бы интереснее всего. Проблемы у нас начинаются на этапе > проектирования, потому что многие аспекты выпадают из внимания "не очень > продуктивных" разработчиков и в итоге большой объем переделок и низкая > продуктивность. Но, как я уже говорил, устроить обучение, аналогичное > PSP нереально.
И что PSP может помочь в этом?
У вас скорее всего элементарная ошибка: вы проектируете в очень
маленьких частях и пытаетесь предсказать будущее.
Начнине проектировать от большого к малому. Не делайте слишком маленькую
детализацию в проекте. По обпыту максимальный горизонт на одного
программиста 2 недели. На группу из 4-5 человек на 2 месяца. А дальше,
планы полгода-год, но уже не сильно четкие. Ну и гибкость начальстве в
выделении главных направлений работы и второстепенных и смена при
необходимости приоритетов.
Здравствуйте, Vzhyk, Вы писали:
>> Иррелевантно. Методы, лишенные этих недостатков, существуют. Полагаются >> на экспертные оценки свойств распределения трудозатрат отдельных задач. V>Понятно. Проблема в экспертах.
Непонятно. В каких экспертах и какая проблема?
>> На вскидку — моделирование Монте-Карло, V>Неа. Монте-Карло на законе больших чисел — он ни на грамм не выходит за V>рамки классической ТВ.
Да-да. Большие числа большим числам рознь. Применение монтекарло для анализа плана проекта не требует "больших чисел" в плане большого количества задач. Там штука в чем — экспертно оценивается плотность вероятности задач в плане, и рисков. После чего, берется план со связями задач и рисками, и плотность вероятности случайной величины "срок окончания проекта" моделируется численно. При помощи Монте-Карло. Есть соответствующие плагины для Прожекта.
Разумеется, ни это, ни PSP/TSP не выходит за рамки классичесвой теории вероятностей. Разница в ее приложении — PSP/TSP плотностями вероятностей рисков и отдельных задач не оперирует.
V>и, попроще — PERT-подобные методы. V>Это не знаю, возможно.
По сути близкая хрень, тока плотность вероятности задачи оценивается упрощенно, через пару (иногда — тройку) оценок "оптимистическая-пессимистическая". Монте-Карло не требуется, если предположить нормальное распределение для трудозатрат задач, то прикидка может быть сделана на коленке.
Здравствуйте, gandjustas, Вы писали:
G>>>Какими способами можно добиться близкого эффекта? Всех программистов обучать в C-M SEI не получится, да и своими силами обеспечить подобное обучение нереально.
G>>Ну например, в одном из своих докладов я рассказывал про более простой подход для прогнозов сроков. Вторая половина презентации, идея в использовании коэффициентов продуктивности как проверочного коэффициента для прогнозов, и сознательном упрощении — отказе контролировать time-on-task, что снимает необходимость поминутно снимать время, и кучу ассоциированного с этим геморроя.
G>>http://files.rsdn.ru/20496/ISV%20Oracle%20final.pdf
G>Это уже читал. У нас есть проблема, что продуктивность сильно скачет от разработчика к разработчику. Даже усредняя между участниками одного проекта может отличаться в разы.
"Сильно скачет" — это бесполезная лирика. Вы линейную регрессию время-объем по задачам в экселе постройте. И посмотрите на коэффициент корреляции. Это будет уже ближе к истине. А если вы перед этим подготовите данные, как положено при статистическом исследовании, выкинув выпадающие точки (поищите в сети мануалы), то будет еще ближе.
Для того, чтобы эти методы работали, достаточно корреляций метрик по отдельным разработчикам. Сделайте, сделайте. Вы удивитесь результату. Не выйдет в лоб — можно отклассифицировать задачи по разным признакам, и поискать корреляции раздельно по классам. Да, и по команде в среднем тоже посмотрите, за какой-нибудь внятный интервал, от 3-х месяцев до полугода.
Ну, а еще можно взять фактическую продуктивность, посчитать ее матожидание с дисперсией, посмотреть на фактическое распределение, и взять интервал. И внимательно перечитать презентацию — там сказано, как интервалом обращаться.
G>>Только это далеко не все, что дает PSP. Сильная сторона PSP/TSP — их работа с метриками плотностей ошибок, и использование системы метрик для оптимизации процесса разработки. Можно было бы заняться и этим, но я не занимался. Но, думаю, должно быть много работ на эту тему.
G>Вот это было бы интереснее всего. Проблемы у нас начинаются на этапе проектирования, потому что многие аспекты выпадают из внимания "не очень продуктивных" разработчиков и в итоге большой объем переделок и низкая продуктивность. Но, как я уже говорил, устроить обучение, аналогичное PSP нереально.
Все, что вам бы дало PSP, свелось к введению в процесс дизайн- и код-инспекций. И ревью. С контролем их эффективности через Yield — оценку процента ошибок, которые ваша инспекция ловит.
Введите инспекции отдельно, для этого PSP/TSP не нужен. Следите, чтобы на них реальные ошибки ловились, а не косметика. Поможет.
Я знаю, что такое факторный анализ. Каждый, кто финансовый менеджмент советско-российской школы изучал (напичканный математикой сверх разумного) — знает.
On 11.02.2013 17:58, Gaperton wrote:
> Непонятно. В каких экспертах и какая проблема?
В живых, причем экспертах.
> Да-да. Большие числа большим числам рознь. Применение монтекарло для > анализа плана проекта не требует "больших чисел" в плане большого > количества задач. Там штука в чем — экспертно оценивается плотность > вероятности задач в плане, и рисков.
Что? Гапертон не порти восприятие себя. Иногда лучше молчать, чем...
> По сути близкая хрень, тока плотность вероятности задачи оценивается > упрощенно, через пару (иногда — тройку) оценок > "оптимистическая-пессимистическая".
Нечетко сформулировано, но приближительно понятно о чем ты.ч
> Монте-Карло не требуется, если > предположить нормальное распределение для трудозатрат задач, то прикидка > может быть сделана на коленке.
Очень часто на таких предположениях приходиться жестко обламываться.
On 11.02.2013 18:20, Gaperton wrote:
> Я спрашивал, зачем он нужен в PSP/TSP тулзе.
Фактически поиск скрытых переменных влияющих на тестируемый (целевой)
параметр. СЧасто позволяет понять, что сделать, чтоб ыцелевую величину
увеличить, уменьшить. Кроликов, я не просто так вспомнил.
