Gaperton's blog

Сделаю таблицу в Excel - выложу.

пришли к выводу, что независимая оценка времени может происходить на основе опыта и статистики по прошлым задачам.
но все равно не понятно, какую метрику взять, чтобы получить адекватную оценку объема работы.

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

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

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


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

> 1. обычно оценка сроков выполняется на основе оценки объема работ. если мы хотим независимые оценки сроков и объема работ, на основании чего нам делать предположения о сроках?

Эксперты часто в состоянии оценить сроки работ, учитывая комбинацию факторов, основываясь на своем опыте похожих проектов. Более того, в большинстве наблюдаемых мной случаев люди изначально делают прогноз именно так - не пользуясь метриками объема.

Это делать гораздо легче, если оценивать не одну дату, а коридор завершения задачи по принципу "раньше точно не справлюсь" - "за такое время гарантировано успею". Практика показывает, что любой человек в состоянии выдать такой коридор. В тяжелых случаях можно задать серию вопросов:
- За день сделаешь?
- Ну нет конечно.
- Хорошо. А за неделю?
- Нет, это невозможно.
- Ладно, три недели.
- Как минимум.
- Ок, за год справишься?
- Разумеется.
- А за полгода?
- Тоже.
...

Принцип должен быть понятен.

> 2. метрики не всегда объективно показывают объем.

Метрики всегда объективно показывают объем. Они не всегда дают корелляцию с трудозатратами и количеством ошибок, но это уже второй вопрос.

> разные строчки кода (в смысле, в разных классах проекта) требуют у разных людей разное время для написания.

Коридоры продуктивности разумеется индивидуальны, и сильно зависят от стиля разработчика. Разные разработчики могут решать одну и ту же задачу в разное количество строк кода, при сравнимом времени. Я наблюдал вариации до двух раз по объему.

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

> также не понятно, как учитывать задачи, на которые уходит время, но при этом пишется мало кода (или не пишется вообще), например, верстка HTML.

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

Пример: средний темп качественного код-ревью в одной из компаний, где я работал, был равен 200 строк кода в час. Пользуясь этим средним, можно было резервировать время на код-ревью.

Еще пример: время на изучение новой темы в целом кореллирует с количеством документации, которую надо изучить.

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

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

Чего угодно перед ничем? Да буквально во всем, что же тут непонятного :).

Нет. В смысле - я никогда не отвечаю серьезно на глупости, и баню за флуд. :)

Вам, собственно, предупреждение. Следующий подобный комментарий будет удален, и вы будете забанены в данном журнале.

> это за хуйня шарлатанская, с этими институтом коучества за дикое бабло.

Это так, и одновременно - это не так. Почему так: я, разумеется, будучи в трезвом уме и сознании, и зная на практике что такое PSP/TSP, не стал бы его внедрять ни в одной организации.

Однако, по чему не так: не смотря на то, что PSP/TSP крайне непрактичен, он основан на значительном количестве фундаментальных посылок, которые верны и работают независимо от того, применяешь ты PSP/TSP или нет. К примеру:
1) PSP/TSP содержит наиболее полный и практичный на текущий
момент фреймворк процессных метрик. Их методику управления через метрики можно применять без их тяжеловесного процесса, если понять принцип - она фундаментальна, и по практической пользе существенно превосходит все, что придумано на тему метрик. То есть, лучше всего тема метрик в разработке ПО раскрыта именно в PSP/TSP. PSP/TSP делают простую и полезную вещь - они превратили теорию в технологию, которая работает, пусть и с большим оверхэдом.
2) В PSP/TSP очень хорошо раскрыта тема взгляда на процесс разработки как на набор фильтров, фильтрующих ошибки. Их методы управления качеством - вообще блеск. Понимание этой философии позволяет сознательно подходить к конструированию процессов. Скажем, я могу проанализировать план работ для каждого конкретного проекта, и оценить его риски качественно, исходя из структуры процедур контроля качества и возможных классов ошибок.

За эти две вещи - подход к построению фреймворка метрик, и взгляд на процесс разработки как на набор процедур контроля качества, а не активностей - им надо ставить памятник. Это - фундаментальные закономерности, понимание которых полезно в любом случае, независимо от того, применяет кто-то PSP/TSP или нет.

При этом, еще раз, внедрять PSP/TSP я категорически не рекомендую. Могу объяснить подробно, что в нем плохого.

Итак, я вижу не только слабые, но и сильные стороны в PSP/TSP. Вопрос - можно применить их фундаментальные закономерности, и получить точные прогнозы сроков для заказных проектов, не сломав себе голову, по простому? Так, чтоб была чистая польза, без геморроя? Ответ. Да. Можно. И я это регулярно делаю. Все, в сущности, очень просто.

Если совсем кратко, вопрос шарлатанства PSP/TSP сводится на самом деле к одному простому вопросу - существуют ли корреляции между метриками сроков и объема.

Значимые корреляции объективно существуют, и это несложно проверить. Вот, собственно, и все.

> Ну вот в том-то и дело, что никаких корреляций нет.

:) Корреляции объективно есть. Количество строк кода за вычетом пустых, комментариев, и автогенеренных, объективно коррелирует со временем их проектирования, написания, и отладки. Корреляция есть статистическая зависимость, а не прямая пропорция. То есть, в среднем чем больше строк кода мы пишем, тем дольше это делаем.

И это легко может быть измерено. И измеряется. На моих задачах в учебных классах PSP/TSP были отличные корреляции. И не только у меня - у всей группы. И в рабочих проектах они есть. И не только в CQG, везде, где я работаю.

> Если помнишь, в PSP всегда открытым оставался вопрос метрик, оценивающих продуктивность. Типа, давайте использовать, а там разберемся. А потом выяснилось, что нет ни одной достоверной метрики, что позволяет оценить продуктивность (по сути вклад в проект).

Если ты помнишь PSP/TSP, то там вообще ничего нет про "оценки продуктивности". Более того, PSP/TSP ПРЯМО И НЕДВУСМЫСЛЕННО ЗАПРЯЩАЕТ доступ менеджмента к любым персональным метрикам, чтобы исключить любое их использование в этом качестве.

Кроме того, вопрос измерения продуктивности не имеет ровным счетом никакого отношения ни к корреляциям время-объем, ни к PSP/TSP.

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

То, что PSP/TSP в изначальном виде мешает работе - это совершено понятно. Процесс тяжеловесен, и его необходимо кастомизировать, с одной стороны (для чего надо иметь мозг), и потратить время на обучение работы с ним (не менее полугода). Все эти вещи, кстати, скорее минусы PSP/TSP. У него, однако, есть более фундаментальные минусы, которые не исправишь никакой кастомизацией.

Но это не отменяет того факта, что PSP/TSP основан на некоторых весьма здравых посылках.

Да, и далеко не все от него добровольно отказывались. Скажем, у нас в Одиссее, он был весьма успешно адаптирован. Мы его довольно сильно облегчили и приспособили под себя. Как и полагается.

Короче, надо просто уметь готовить этих кошек.

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

> Ты прав - в учебных задачах это работало. Но никто почему-то не замечал, что они были так хитро устроены, что каждая следующая задача использовала результаты предыдущей, человек войдя в курс дела, каждую следующую задачу, делал быстрее, чем предыдущую, что разумеется и создавало иллюзию что это работает.

Угу, а в работе над большим проектом это типо совсем не так, ты хочешь сказать, да? Каждая следующая задача вовсе не использует код, сделанный до этого. :)

И кстати, метрики с учебных задач вовсе не показывали, что следующая задача делается быстрее, чем предыдущая. Они показывали, что время связанно с количеством ошибок, которое ты наляпал, и с количеством строк кода. И чем больше кода, тем больше ошибок ты ляпаешь. Просто по невнимательности.

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

Поэтому, на практике устойчивая корреляция будет наблюдаться на более крупных отрезках, только и всего. Не на заданиях по три часа, а на недельных или месячных заданиях. Корреляции на отрезках в год вообще стабильны, как танк.

Что вполне понятно и естественно каждому человеку, знакомому с центральной предельной теоремой. Ты презентацию мою вообще смотрел? Посмотри, там есть слайд, который иллюстрирует одно из свойств центральной предельной теоремы - уменьшение дисперсии в процентном выражении при укрупнении задач.

> В реальной жизни, к сожалению, такого удачного стечения обстоятельств не бывает.

Возьми свои личные данные на крупных задачах, загони в ексель, и убедись сам. Верю/не верю - это не инженерный подход, это детсад. Я вот, например, все свои предположения обязательно подтверждаю и опровергаю экспериментально. И я не стал бы докладывать на крупной отраслевой конференции то, что не проверено многолетней практикой, как врач говорю. :) У меня такого непроверенного дохрена.

> Я это и имел ввиду, они показывали, что со временем, у тебя предсказуемость показателей становилась выше. Но это было очевидно, потому что каждая предыдущая задача сочетала черты предыдущей, и само собой, предсказывать объем становилось на порядок легче.

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

Понимаешь, если ты помнишь матстат, то достоверная корреляция строится не менее чем из 5-7 точек, и невалидные, нетипичные данные надо руками выбрасывать из выборки, чтобы получить хорошую корреляцию. Это матстатистика, а не PSP/TSP.

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

Нет. Это означает, что корреляция на коротких отрезках устойчива для одного программиста и одного применяемого стиля. И ничего страшного, мешающего ее использовать для прогнозов, в этом нет.

> Насчёт остального, зачём загонять что-то в эксел, когда производительность в каждом проекте может меняться в разы, в зависимости от того, какое ключевое решение будет принято на разных этапах проекта.

Затем загонять в эксель, что пока ты этого не сделал, не загнал фактические данные времени и объема, и не посчитал точно производительность, ты не можешь знать, как она меняется. Ты можешь только догадываться. И догадываться неправильно. Я не понимаю, зачем догадываться, когда это считается за полчаса.

> Тут уже никакой статистики нет и быть не может.

Отсутствие корреляции ДОКАЗЫВАЕТСЯ методами той же статистики. А не разрыванием тельняшки на груди.

> Ну что я загоню, если в одном проекте, функционал, равный N строчкам кода в другом проекте равен 100*N строчкам? Лишь за счёт изменения технологии и общего подхода. Что тут можно кореллировать, не пойму.

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

В PSP/TSP люди не языками чешут, а подтверждают свои теории экспериментально. На тех отрезках значений, которые встречаются в отдельной компании, у метрик ЭКСПЕРИМЕНТАЛЬНО обнаруживаются устойчивые линейные корреляции.

> Но проблема в том, что зависимости не то чтобы нелинейные, они даже не экспоненциальные, а скорее гиперболические - как в современной демографии.

Я много подобного слышал. И что удивительно, ни разу, НИ РАЗУ, авторы подобных слов не могли привести в обоснование своих тезисов ровным счетом ничего. Чем обосновывать будешь? :)

Думаешь, я на слово в подобное верить буду, когда без всякого PSP/TSP последние 6-7 лет постоянно вижу линейные корреляции на нужных мне отрезках (меня совершенно не волнует зависимость на больших отрезках, она совершенно бесполезна на практике), и пользуясь ими получаю точные прогнозы? Я систематически в 10% погрешности укладываю планы на заказных проектах по своей методике. Причем - хай-тек, с охрененными рисками, а не типовые вебсайты с базенками данных.

И ты мне говоришь что-то про экспоненциальное и гиперблическое? :) И про то, что не пользуясь корреляциями строки-объем ты прогноз точнее получишь, чем с ней? :) Не делая прогноза объема работ, только время? :) Ну-ну.

> Ну а чем ты обосновывать будешь? Экспериментально?
Зачем мне обосновывать тебе, что я на самом деле укладываю свои проекты в 10% погрешности? У МЕНЯ корреляции есть, и им можно доверять. Для МЕНЯ это достаточное обоснование. Что касательно глобального факта наличия корреляции - Уотс Хамфри ее достаточно хорошо обосновал на гораздо более крупных исследованиях, не вижу причины делать это еще раз.

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

А ты обосновать или опровергнуть все можешь сам. Возьми СВОИ данные с реальных проектов, загони в эксель, и покажи наглядно "гиперболическую зависимость".

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

Меня совершенно не волнуют абстрактные "истины" и "объективность". Понимание требуется для действия. Точка. И я знаю, как мое понимание помогает действовать мне. И мне этого вполне достаточно.

> Насчёт же корелляций строка/объем - приведу лишь простой пример, скажем, за счёт смены технологии или использования какой-то коммерческой библиотеки можно сократить скорость разработки раз в 10...
> Получается, за счёт правильного выбора технологий и балансирования на различных компромисах, можно достигать колоссальных перепадов, так о каких корреляциях идёт вообще речь? Примерно понятно что я имел ввиду?

Нет, не вполне понятно, что ты имел в виду. Я вообще не понимаю, как можно опровергать факт корреляции времени и объема, не приводя никаких данных объема. Вопрос, сколько кода надо было писать до смены библиотек, и сколько - после, ты как-то обошел вниманием. И поверь мне, я сильно удивлюсь, что количество строк кода, которые надо было написать в твоем примере после перехода на новую библиотеку, не уменьшилось пропорционально времени.

Тьфу, написав в десять раз меньше кода (там выше ошибка)

> Да нет, ради бога - просто выразил своё мнение, что на мой взгляд это не работает. Может зайдет кто-то в твой блог и согласится со мной :)

Обязательно найдутся те, кто согласится с тобой. :) И что с того? :) Инженерия это не вопрос веры, а истина - это не то, что может быть установлено большинством голосов. Меня это волнует мало.

> Может какая-то новая истина и зародится.

Сильно в этом сомневаюсь. :)

> По поводу последнего абзаца, после перехода на новую библитеку и новые тулы меняется всё, и объем кода, и все зависимости. А поскольку, в каждом новом проекте, часто меняется много параметров, то считать практически невозможно.

Количество добавленных в ходе проекта строк кода посчитать элементарно. И, зависимости, параметры, и библиотеки здесь совершенно не причем.

> Вот скажем, есть у меня проект. Я типа расчитал, что на гуишную часть уйдет год, исходя из того, что прежний, в два раза меньший, шёл за полгода. Сижу такой довольный, а потом вдруг раз, нашёл хороший РАД тул, и сделал этот же гуи за месяц, написав в десять раз больше кода.

Строки кода (SLOC) = все кроме комментариев, пустых строк, и АВТОГЕНЕРИРОВАННОГО КОДА. Это во-первых. НЕ СЧИТАЕТСЯ АВТОГЕНЕРИРОВАННЫЙ КОД, которым ты "написал" в 10 раз больше кода.

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

Второе - "в середине проекта нашел хороший рад-тул" - это само по себе прикольно. :) Но ладно, опустим фееричность ситуации, что ты в середине проекта свободно меняешь тулы и библиотеки. Пусть так. Когда ты нашел этот тул, ты изменил подход к разработке. В этом случае план должен быть переделан заново, ибо любой план отражает твой подход к проблеме. И PSP/TSP с корреляциями тут не причем.

> У меня ж не праздный интерес или желание поспорить, мне реально нужна технология расчёта рисков.

Смотри первую часть презентации. Там нет ничего про корреляции время-объем. Просто - как молоток.

Вторая часть презентации показывает, как применить метрики объема для обнаружения грубых ошибок в оценках сроков, сделанных по первой методике. У меня другой подход, не такой как в PSP/TSP.

PSP дает прогноз объема, и получает из него время. Таким образом почти невозможно учесть риски, и это самое слабое место PSP/TSP, делающее его малопригодным для хайтека.

Я делаю не так. Я делаю прогноз вариации срока из головы, потом, делаю независимо прогноз объема, и вместо того, чтобы пользоваться корреляцией как мультипликатором, применяю широкий коридор колебания "продуктивности" как проверочный коэффициент. При этом:
1) Меня не волнует сила корреляции, пофигу мне. Мне нужен только коридор колебания, и он может быть широким.
2) Я вычисляю запланированную продуктовность по каждой задаче, и смотрю, чтобы она не вылетела за коридор колебания, взятый из истории.
3) Я применяю более сложные правила проверки, см. вторую часть презентации.
4) Мне не требуется для этого долгого сбора статистики. Некоторые правила проверки вообще не требуют сбора никакой статистики, при этом, полагаются на закономерность корреляции время-объем. Чудо? Нет, все очень просто. Читай презентацию.
5) Я не теряю информацию о рисках.
6) Точность 10% в условиях присутствия рисков обеспечивается элементарно и без проблем, никакого PSP/TSP не требуется.

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

Парадигмы и тулы ты раз в проект не меняешь. Их тупо меньше, чем проектов. А менял бы - и безо всяких корелляций сам не мог бы предсказать сроки. Не говоря о том, что не мог бы не только научиться новым тулам и методологиям, но и поиметь от этого обучения бенефит в дальнейшем. Это нонсенс.

> Получается, что твоя схема может считать только то, что делается уже проверенным дедовским способом, а это не всегда верно

Пока не получается. Моя схема дает эффект на таких проектах и тулах, которых команда еще не делала. И это проверено. Пример проекта - вот прессрелизы о его завершении от разных изданий, выбирай любой:
http://www.osp.ru/text/233652/5105400/

http://www.russianelectronics.ru/leader-r/news/company/8672/doc12080.phtml

http://www.astera.ru/pr/28552/

Данный проект запланирован по моей методике. 9 месяцев, два этапа сданы день в день, последний - вылет на две недели. Ничего подобного до этого не делала не только наша команда (которая, кстати, вообще опыта в промыщленной микроэлектронике не имела на момент начала проекта), но и вообще никто в России.

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

Это была заказная разработка по контракту. По ссылкам об этом написано. Контракт оплачен и закрыт, заказчик доволен. Чип с этим контроллером выйдет в следующем году. Еще вопросы будут? Или, наконец, все-таки прочтешь то, о чем выносишь суждения?

Да ладно тебе, все знают, что программеры мозг не юзают :) Просто удивился, что в ты считаешь что PSP - работающая методика. У меня сложилось несколько другое впечатление, то есть я думаю, что решение в другом поле вообще находится. Хотя конечно, если работает, нет проблем. Это знаешь как - у каждого свой бог и у каждого он работает :) По любому - мы сейчас заняты решением одной и той же задачи - как быстро и в срок делать большой и сложный софтвер, только подход разный.

То, что тебя вообще что-то раздражает, уже нехороший симптом. Слишком экспрессивный ответ для профессионала, я бы сказал :)