http://www.citforum.ru/SE/project/psychology/
"Кто виноват в том, что, спустя 30 лет после объявления «кризиса программирования», компания Standish Group, проанализировав работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, в своем докладе с красноречивым названием «Хаос» [1] пришла к следующим неутешительным выводам.
«Только 16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31,1% проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок выполнения — на 122%»?
Что делать, для того, чтобы, все-таки, производить необходимые программные продукты с удовлетворительным качеством и в приемлемые сроки?"

Ваше мнение?

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

G>Не слушайте этого кренделя из CBOSS, а читайте первоисточник. Вот он: Peopleware : Productive Projects and Teams, 2nd Ed. Есть в сети в электронном виде, если поискать.

Угу рекомендую. Вот здесь лежит
http://anatolix.naumen.ru/Books/Peopleware

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>Ваше мнение?
G>Не слушайте этого кренделя из CBOSS, а читайте первоисточник. Вот он: Peopleware : Productive Projects and Teams, 2nd Ed. Есть в сети в электронном виде, если поискать.

G>Эта статья — помесь впечатлений от прочтения Peopleware и авторских мыслей. Какого качества бывают эти мысли, я покажу на примере.
G>

G>Факт 3. Производительность труда программистов с одинаковым уровнем знаний и опытом в обозримом будущем, по-прежнему, будет отличаться на порядок. Более того, производительность одного и того же программиста в течение проекта будет так же отличаться на порядок даже при решении сходных по сложности задач.

G>Хотите, меряйте производительность в строках исходного кода, хотите – в функциональных точках.

G>Вот этот "факт" — совершенно дикий бред.

G>Не будет она отличаться "на порядок" (это минимум в 10 раз) никогда, а уж у одного програмиста тем более.

Дак это вроде не оригинальный факт.
Об этом, если не ошибаюсь, еще Брукс говорил.
Я как раз склонен с этим согласиться.
Если про одного программиста еще можно поспорить, а вот производительность 2 разных
программеров точно может отличаться в 10 раз.


G>И вообще — этот крендель работает в CBOSS. Менеджмент которого не нуждается в представлении.

Ну это вообще смехотворный аргумент

В статье конечно же есть спорные утверждения.
Я, например, вот к этому мог бы придраться

Сегодня мы так же далеки от индустриальной разработки программ, как и 50 лет назад.

Но интересные мысли (хоть и не всегда оригинальные) в ней все же есть.

Здравствуйте, AndreyFedotov, Вы писали:

B>>Я, например, вот к этому мог бы придраться
B>>

B>>Сегодня мы так же далеки от индустриальной разработки программ, как и 50 лет назад.

AF> Увы, это так. Изменился лишь уровень программ, для которых можно или нельзя говорить об их индустриальной разработке. Если бы это не было так, то не было бы и ситуации с провалом проектов, более похожей на ситуацию с проектами с научных разработчках.

Это фигня все. Уровень подготовленности к спроектам возрос на порядок. Просто проекты стали сложнее. Видишь ли сейчас сложность проектов ограничена лишь нашими возможностями их выполнять. Как только ты начинаешь как орехи щелкать сложные проекты тебе сразу дают еще более сложные потому, что в них масштаб денег совершенно иной. Т.е. в не зависимости от наших скиллов все равно будут появляться более сложные проекты и мы будем их лажать с такой же вероятностью как простые раньше.

Для сравнения OS/360 чье создание описано в книге Мифический Человеко Месяц считался сравнимым по масштабу с полетом человека на луну. Сейчас операционные системы на порядок более сложные создаются просто энтузиастами(Linux) или небольшими группами профессиональных программистов(QNX) за в порядки меньшие сроки.

Здравствуйте, bkat, Вы писали:
B>Ну ты спросил... :-)
B>Бери к примеру практики из SW CMM. Или ISO/IEC TR 15504 и вперед
B>Они все об одном и том же.

Я, в общем-то, мнение о статье спрашивал…

Здравствуйте, Аноним, Вы писали:

А>Ваше мнение?
Не слушайте этого кренделя из CBOSS, а читайте первоисточник. Вот он: Peopleware : Productive Projects and Teams, 2nd Ed. Есть в сети в электронном виде, если поискать.

Эта статья — помесь впечатлений от прочтения Peopleware и авторских мыслей. Какого качества бывают эти мысли, я покажу на примере.

Факт 3. Производительность труда программистов с одинаковым уровнем знаний и опытом в обозримом будущем, по-прежнему, будет отличаться на порядок. Более того, производительность одного и того же программиста в течение проекта будет так же отличаться на порядок даже при решении сходных по сложности задач.

Хотите, меряйте производительность в строках исходного кода, хотите – в функциональных точках.

Вот этот "факт" — совершенно дикий бред.

Не будет она отличаться "на порядок" (это минимум в 10 раз) никогда, а уж у одного програмиста тем более.

Если бы этот "факт" имел место быть, то методы типа COCOMO, PSP, и всякие прочие прогнозы сроков через функциональные точки не работали бы в принципе. Я приведу пример. PSP прогнозирует сроки на "сходных по сложности задачах" укладываясь в погрешность 5% на одну задачу сроком порядка 10 часов (!!!). Что достигается благодаря чрезвычайной стабильности метрики продуктивности LOC/hr для одного программиста на задачах одной сложности, и стабильности функциональных точек, через которые делается прогноз объема.

И вообще — этот крендель работает в CBOSS. Менеджмент которого не нуждается в представлении.

А>«Только 16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности...
"
Что характерно, при обсуждении подобных вопросов почему-то предполагается, что бюджет, срок и объем требуемых функций определены менеджерами абсолютно верно, и только криворукость программистов мешает их воплощению в жизнь.
Но ведь есть много случаев, когда срок, объем проекта определялся "от балды", "к началу след. года" и т. д. Я понимаю, когда накладываются жесткие ограничения по сроку в случае критичной важности приложения для бизнеса — но и то не совсем. Представляете, приходит к вам начальник и говорит: "Через месяц напротив нашего офиса должно стоять 50-этажное здание с бассейном на крыше, а не то наши конкуренты построят такое же здание раньше нас." Так ведь в сутках только 24 часа вне зависимости от мнения босса на этот счёт.

Здравствуйте, Anatolix, Вы писали:

A>Ну ты же понимаешь что между новым кодом и legacy разница только во времени его написания. Через год уже твой код станет немножко legacy.
Код станет legacy когда будет переведен в production, и сменится минимум состава команды, работающий над ним, так, что знания о коде будут частично утеряны. Когда придется планировать время на reverse engineering, тогда код и станет legacy. Если такое случилось в процессе разработки одного нового продукта до сдачи его в эксплуатацию , и вы на это закладываетесь как на штатную ситуацию , тогда конечно да. We're writing legacy code. Now.

A>Ну ты же знаешь про систему CoCoMo и надеюсь не будешь отрицать что количество строк от времени зависит не линейно, поэтому можно посчитать количество строк в час, а можно в год и эти 2 значения не будут иметь друг к другу ничего общего.
Они имеют много общего . LOC в час = LOC в год / кол-во рабочих дней в году / кол-во часов в дне.

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

Таки это был раз. Во вторых, при хорошей декомпозиции время разработки одного изолированного модуля не зависит от наличия остальных модулей — они разрабатываются независимо и тестируются unit тестами. Не понимаю, откуда здесь возьмется нелинейность по количеству модулей, которая уменьшит мне продуктивность на одном из них в 10 раз. Причем хаотически и непредсказуемо, о чем шла речь с статье.

А время фазы интеграции, где все это должно взлететь, мы запланируем отдельно, основываясь на предполагаемой плотности дефектов (defect/KLOC) и размере кода в строках (LOC), и измеренном времени на дефект (или возьмем прогноз частично из головы, обработав его PERT-ом — тоже неплохо получится). Продуктивность при планировании этой фазы не очень интересна. И все, нелинейность вас не волнует, проверено при размере команды до 20 чел и сроке проекта до полутора лет. Если добавить, что план постоянно корректируется по ходу получения фактической информации по продуктивности и рискам, так все вообще станет хорошо.

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

A>Отдельные сомнения теперь вызывает и оценка оценка 20-60loc/hr очень похожа на оценку в час. Я легко поверю в такой темп в краткосрочной перспективе, но на протяжении года я сильно сомневаюсь, что можно такой темп держать(а ты только что сказал что считается она на протяжении года).
А ты не верь, а проверь. 20 LOC/hr — это нормальный измеренный среднийтемп для практически всех команд у нас в компании за последних два года, который стабилен поквартально. Посчитан на групповых проектах сроком от полугода — понятно, что это не двухчасовая изолированная задачка, которая колбасится на 60 LOC/hr (у меня — 45 LOC/hr).

Сейчас попробую достать наши метрики по закрытым проектам, если получится, пришлю сюда.

Здравствуйте, Аноним, Вы писали:

А>Что делать, для того, чтобы, все-таки, производить необходимые программные продукты с удовлетворительным качеством и в приемлемые сроки?"

А>Ваше мнение?

Ну ты спросил...
Бери к примеру практики из SW CMM. Или ISO/IEC TR 15504 и вперед
Они все об одном и том же.

Обсуждать в целом и в общем будет проблематично.
Лучше все же останавливаться на каких частных проблемах.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bkat, Вы писали:
B>>Ну ты спросил...
B>>Бери к примеру практики из SW CMM. Или ISO/IEC TR 15504 и вперед
B>>Они все об одном и том же.

А>Я, в общем-то, мнение о статье спрашивал…

Статья интересная. Спасибо!!

А то, на что я ссылался, как раз и направлено на то,
чтобы устранить зависимость от личностных качеств программеров.

Я согласен на все 100%, что провал/успех проекта
лежит в области психологии и общения.
Многократно убеждаюсь в этом почти каждый день.

Здравствуйте, bkat, Вы писали:

B>В статье конечно же есть спорные утверждения.
Есть.

B>Я, например, вот к этому мог бы придраться
B>

B>Сегодня мы так же далеки от индустриальной разработки программ, как и 50 лет назад.

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

Здравствуйте, Аноним, Вы писали:

А>Что делать, для того, чтобы, все-таки, производить необходимые программные продукты с удовлетворительным качеством и в приемлемые сроки?"

А>Ваше мнение?

Если это приложение для автоматизации бизнеса, то:

1. Заказчик должен быть заинтересован в данном продукте, и должен точно знать, какое business value он сиожет с этого получить.
2. Заказчик должен понимать, что время, потраченно на пояснение аналитикам разработчика своих потребностей и ожиданий только на пользу делу, и воспринимать разработчика как партнера, а не как потенциального обманщика.
3. Менеджер разработчика должен руководствоваться анализом рисков, и думать о миграции с рисков, обсуждая эти риски с заказчиком (возможно не все ). Отсюда требование к квалификации менеджера. Это не должен быть человек с хорошим багажом знаний и должен иметь како-никаой практический опыт, кроме того он должен обладать некторым кругозором в т.ч. в методологиях разработки ПО. Про управление ожиданиями заказчика тоже упомянем вскользь
4. Разработчик должен понимать таки, для чего нужны аналитики требований/системные аналитики. И что написание ТЗ (причем даже не по ГОСТ, а как бог на душу положит) -- это еще не значит что требования разработаны качественно. И перед требованиями нужно докопаться, каке потребности имеет заказчик.
5. Должна быть разработана базовая линия требований, которые согласовываются с заказчиком.
6. Разработчик должен понимать, для чего нужно проектировать систему (особенно большую). И что проектирование -- это не только схема базы данных, как считают многие. Понимать, что существует понятие бизнес-логики. Кроме этого, нужно понмать бенефиты, которые дает повторное использование кода и как этого добиться в ральности.
7. Разработчик должен согласовывать промежуточные результаты создания ПО, чтобы как можно раньше вносить корректировки (требования могут изменияться, или что-то важное было упущено).
8. Тестирование разработанного ПО должно проводиться не программистами, а тестирощиками -- основываясь на требованиях к ПО.


и т.д.

В более сжатом виде ответ на поставленный вопрос можно получить например в RUP (разрабатывайте итеративно, управляйте требованиями ...). Только нужно очень внимательно прочесть эти рекоммендации и задуматься над прочитанным, а не сразу кричать "про тупых американцев, для которых все эти методологии написаны". И отнестись к этому как к необхомимоу условию (принцип необходимости и достаточности).

Здравствуйте, Anatolix, Вы писали:

A>Это фигня все. Уровень подготовленности к спроектам возрос на порядок. Просто проекты стали сложнее. Видишь ли сейчас сложность проектов ограничена лишь нашими возможностями их выполнять. Как только ты начинаешь как орехи щелкать сложные проекты тебе сразу дают еще более сложные потому, что в них масштаб денег совершенно иной. Т.е. в не зависимости от наших скиллов все равно будут появляться более сложные проекты и мы будем их лажать с такой же вероятностью как простые раньше.

Вот об этом я и говорю Главное — результат. Сравним с инженерными областями — архитектурой, например, или индустрией. Там успешных проектов — свыше 90%. В бюджет и сроки укладываются 80% проектов. Софту до этого, несмотря на несомненный прогрес — очень далеко...

A>Для сравнения OS/360 чье создание описано в книге Мифический Человеко Месяц считался сравнимым по масштабу с полетом человека на луну. Сейчас операционные системы на порядок более сложные создаются просто энтузиастами(Linux) или небольшими группами профессиональных программистов(QNX) за в порядки меньшие сроки.
Вопрос не о сложности проектов, а о потребностях пользователей.

Здравствуйте, AndreyFedotov, Вы писали:

A>>Это фигня все. Уровень подготовленности к спроектам возрос на порядок. Просто проекты стали сложнее. Видишь ли сейчас сложность проектов ограничена лишь нашими возможностями их выполнять. Как только ты начинаешь как орехи щелкать сложные проекты тебе сразу дают еще более сложные потому, что в них масштаб денег совершенно иной. Т.е. в не зависимости от наших скиллов все равно будут появляться более сложные проекты и мы будем их лажать с такой же вероятностью как простые раньше.

AF> Вот об этом я и говорю Главное — результат. Сравним с инженерными областями — архитектурой, например, или индустрией. Там успешных проектов — свыше 90%. В бюджет и сроки укладываются 80% проектов. Софту до этого, несмотря на несомненный прогрес — очень далеко...

Строительству 2000 лет. Небоскребы строились с 30 годов нашего века. С тех пор сложность проектов не росла. Потому что потребности не было. По большому счету современные здания всех устраивают.

A>>Для сравнения OS/360 чье создание описано в книге Мифический Человеко Месяц считался сравнимым по масштабу с полетом человека на луну. Сейчас операционные системы на порядок более сложные создаются просто энтузиастами(Linux) или небольшими группами профессиональных программистов(QNX) за в порядки меньшие сроки.
AF> Вопрос не о сложности проектов, а о потребностях пользователей.

Вот вот в строительстве предел потребностей достигнут. В IT его даже еще представить нельзя, не то что достигнуть.

Здравствуйте, Anatolix, Вы писали:

A>Строительству 2000 лет. Небоскребы строились с 30 годов нашего века. С тех пор сложность проектов не росла. Потому что потребности не было. По большому счету современные здания всех устраивают.

Согласен.

A>Вот вот в строительстве предел потребностей достигнут. В IT его даже еще представить нельзя, не то что достигнуть.
Вот-вот именно об это то я и пишу. И именно потому исходная посылка — что до индустриальной разработки программ (т.е. дающей столь же прогнозируемый и качественный результат как в строительстве или индустрии) — ещё очень далеко. И хотя за полседние 50 лет был достигнут значительный прогресс — сложность программ возросла настолько — что свела все усилия почти к нулю...

Здравствуйте, AndreyFedotov, Вы писали:

A>>Вот вот в строительстве предел потребностей достигнут. В IT его даже еще представить нельзя, не то что достигнуть.
AF> Вот-вот именно об это то я и пишу. И именно потому исходная посылка — что до индустриальной разработки программ (т.е. дающей столь же прогнозируемый и качественный результат как в строительстве или индустрии) — ещё очень далеко. И хотя за полседние 50 лет был достигнут значительный прогресс — сложность программ возросла настолько — что свела все усилия почти к нулю...

Ну и хорошо. Просто отсутствие стагнации в отрасли. Меня подобная ситуация полностью устраивает, потому что даже при том что значительная часть проектов заваливается это происходит из-за того что кто то откусил больше чем смог проглотить. Так что алгоритм простой, хочешь гарантии выполняй проекты которые можешь и тренируйся, хочешь приключений выполняй проекты типа mission impossible. Каждый для себя выбирает. (А не так как некоторые люди считают раз ты в IT каждый третий твой проект должен быть провален)

Здравствуйте, Anatolix, Вы писали:

A>Для сравнения OS/360 чье создание описано в книге Мифический Человеко Месяц считался сравнимым по масштабу с полетом человека на луну. Сейчас операционные системы на порядок более сложные создаются просто энтузиастами(Linux) или небольшими группами профессиональных программистов(QNX) за в порядки меньшие сроки.
А вот это как раз фигня... Вы, наверное, на OS/360 не работали...
Прогресс ИТ еще и в том, что некоторые вещи, которые в OS/360 были сделаны ОЧЕНЬ СЛОЖНО, в QNX и LINUX реализованы не в пример проще...

Здравствуйте, bkat, Вы писали:

B>Дак это вроде не оригинальный факт.
Факт тут только один. Автор статьи никогда не видел метрик продуктивности, посчитанных на своих программистах.

B>Об этом, если не ошибаюсь, еще Брукс говорил.
Г-н Брукс после двукратного срыва сроков и бюджета в своем проекте (OS/360) был снят с должности, и остаток жизни посвятил преподавательской деятельности, а его книга является отчасти оправданием его провала. По метрикам продуктивности и "человеко-месяцам" накоплена индустриальная статистика, и она не подтверждает мысли господина Брукса. Которые, кстати, вообще не подкреплены никакой статистикой.

B>Я как раз склонен с этим согласиться.
B>Если про одного программиста еще можно поспорить, а вот производительность 2 разных
B>программеров точно может отличаться в 10 раз.
Если речь идет о проектах без рефакторинга и о технически грамотных программистах (которые знакомы с языком и платформой) — не может. Ни один программист не в состоянии делать код продакшн качества со средней продуктивностью 100 LOC/hr. На самом деле я бы сильно удивился, если бы увидел значение этой метрики выше 60 LOC/hr. Средняя продуктивность программиста (не студента, который не знает языка и платформы) также не может падать ниже 10 LOC/hr, если он откровенно не пинает балду. Реальный коридор, в котором работает большинство программистов на групповых проектах — это 20-40 LOC/hr.

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

G>>И вообще — этот крендель работает в CBOSS. Менеджмент которого не нуждается в представлении.
B>Ну это вообще смехотворный аргумент
Да ради бога. Вот мне, в свою очередь, смешно, когда менеджер из CBOSS цитирует Peopleware, в то время как весь город знает про их реальное отношение к программистам.

B>В статье конечно же есть спорные утверждения.
B>Я, например, вот к этому мог бы придраться
B>

B>Сегодня мы так же далеки от индустриальной разработки программ, как и 50 лет назад.

Там ко много чему можно придраться, потому что человек очевидно просто не понимает о чем пишет.

B>Но интересные мысли (хоть и не всегда оригинальные) в ней все же есть.
Все интересные мысли, которые там есть — это коктейль из Peopleware. Прочтите его, у найдете там гораздо больше интересных мыслей в их первозданном виде.

Здравствуйте, LaptevVV, Вы писали:

LVV>некоторые вещи, которые в OS/360 были сделаны ОЧЕНЬ СЛОЖНО, в QNX и LINUX реализованы не в пример проще...

сделать проще гораздо сложнее и дольше, чем сделать сложнее, сложно — оно само-собой получается

Здравствуйте, Gaperton, Вы писали:

>бы увидел значение этой метрики выше 60 LOC/hr. Средняя продуктивность программиста (не студента, который не знает языка и платформы) также не может падать ниже 10 LOC/hr, если он откровенно не пинает балду. Реальный коридор, в котором работает большинство программистов на групповых проектах — это 20-40 LOC/hr.

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

Так вот в десятки раз отличается как раз продуктивность в долгосрочной перспективе. Т.к. некоторые пишут сразу как надо, есть которые пишут эти самые 100 loc/hr за 2 первый день а потом 2 недели это рефакторят и т.п.

Здравствуйте, Anatolix, Вы писали:

A>Здравствуйте, Gaperton, Вы писали:

>>бы увидел значение этой метрики выше 60 LOC/hr. Средняя продуктивность программиста (не студента, который не знает языка и платформы) также не может падать ниже 10 LOC/hr, если он откровенно не пинает балду. Реальный коридор, в котором работает большинство программистов на групповых проектах — это 20-40 LOC/hr.

A>Да но это в краткосрочной перспективе. Но в долгосрочной это не применимо, поэтому если ты тупо помножишь эту цифру на 200 рабочих днйе в году на 8 часов то цифра не будет совпадать с реальностью даже близко.
Во первых не на 8, а максимум на четыре. Эти цифры, которые я привел, рассчитаны за вычетом совещаний и прочей лабуды — это чистая работа.

Во вторых, сойдется. И именно в долгосрочной перспективе сойдется близко, если взята реально средняя продуктивность для конкретного разработчика. Как раз в краткосрочной перспективе на отдельных задачах могут быть отклонения, а на проекте целиком — их будет тем меньше, чем больше единиц планирования и чем длиннее проект. Потому что отклонения сроков в обе стороны (ошибки прогнозирования) — независимые случайные величины по каждой задаче, и когда их много, погрешность планирования уменьшается, а не увеличивается. Об этом говорит теория вероятностей, и практические наблюдения — видел это много раз лично.

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

A>Ты же сам недавно писал что в фирме где ты работаешь по началу в legacy team крутые программеры правят один простой баг в 2 недели. Только не говори что потом они выходят на продуктивность команды которая пишет новый проект.

Ты аккуратно вырезал из начала моей цитаты важную фразу: "Если речь идет о проектах без рефакторинга и о технически грамотных программистах (которые знакомы с языком и платформой) — не может." Как ты считаешь, какие проекты я имею в виду, когда говорю, что они без рефакторинга (добавлю: и без reverse engineering)? Не похоже на возню с легаси системами, не находишь?

Чтобы снять вопросы, скажу еще раз, прямо, что я говорю только о написании нового кода.

A>Так вот в десятки раз отличается как раз продуктивность в долгосрочной перспективе. Т.к. некоторые пишут сразу как надо, есть которые пишут эти самые 100 loc/hr за 2 первый день а потом 2 недели это рефакторят и т.п.
Средняя продуктивность считается на единице планирования, куда включен дизайн, кодирование, отладка. Задача считается закрытой, когда она отдается в интеграционный тест, и программерская активность по ней в рамках разработки прекращена. Это и есть продуктивность в долгосрочной перспективе, и она стабильна. Понимаешь, что это значит? Если ты не включил в расчет продуктивности упомянутый рефакторинг, ты ее просто неправильно считаешь. Другую "продуктивность" считать совершенно бессмысленно, она никакого практического смысла не несет, в планировании ее использовать нельзя.

Здравствуйте, Gaperton, Вы писали:

G>Ты аккуратно вырезал из начала моей цитаты важную фразу: "Если речь идет о проектах без рефакторинга и о технически грамотных программистах (которые знакомы с языком и платформой) — не может." Как ты считаешь, какие проекты я имею в виду, когда говорю, что они без рефакторинга (добавлю: и без reverse engineering)? Не похоже на возню с легаси системами, не находишь?

G>Чтобы снять вопросы, скажу еще раз, прямо, что я говорю только о написании нового кода.

Ну ты же понимаешь что между новым кодом и legacy разница только во времени его написания. Через год уже твой код станет немножко legacy.
Ну ты же знаешь про систему CoCoMo и надеюсь не будешь отрицать что количество строк от времени зависит не линейно, поэтому можно посчитать количество строк в час, а можно в год и эти 2 значения не будут иметь друг к другу ничего общего.

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

Отдельные сомнения теперь вызывает и оценка оценка 20-60loc/hr очень похожа на оценку в час. Я легко поверю в такой темп в краткосрочной перспективе, но на протяжении года я сильно сомневаюсь, что можно такой темп держать(а ты только что сказал что считается она на протяжении года).

Здравствуйте, AndreyFedotov, Вы писали:
AF> Вот об этом я и говорю Главное — результат. Сравним с инженерными областями — архитектурой, например, или индустрией.

Вы читали Дика Гэбриела? Если да, то это редкий случай... Просто цитата фактически прямая.

Здравствуйте, Gaperton, Вы писали:

> Код станет legacy когда будет переведен в production, и сменится минимум состава команды, работающий над ним, так, что знания о коде будут частично утеряны.

Он тогда совсем Legacy станет, немножко Legacy т.е. требующий дополнительное время он становится достаточно быстро. Т.е. я вот например месяц назад нашел багу в коде который писал 2 года назад. Поправил. Но времени это у меня заняло не 5 минут, а час. Даже об одном и том же коде знания оказываются утерянными, даже если есть документы по design их нужно читать.

A>>Ну ты же знаешь про систему CoCoMo и надеюсь не будешь отрицать что количество строк от времени зависит не линейно, поэтому можно посчитать количество строк в час, а можно в год и эти 2 значения не будут иметь друг к другу ничего общего.
G>Они имеют много общего . LOC в час = LOC в год / кол-во рабочих дней в году / кол-во часов в дне.

А почему не LOC в час = LOC в месяц / количество рабочих дней в месяце / количество часво в году? Другая характеристика будет.

G>Ты, видимо, до сих пор не догнал, что "строки в час" считаются на статистике по закрытой задаче, которая делается, например, неделю (а не замеряется скорость печати программера за отдельный час). И эти строки в час не будут "средними", средние — это посчитанные но большом количестве задач.

Среднее можно посчитать по любому параметру. Так вот среднее KLOC среди проектов в месяц и среднее KLOC среди проектов в 3 года совсем разное.

G>Таки это был раз. Во вторых, при хорошей декомпозиции время разработки одного изолированного модуля не зависит от наличия остальных модулей — они разрабатываются независимо и тестируются unit тестами. Не понимаю, откуда здесь возьмется нелинейность по количеству модулей, которая уменьшит мне продуктивность на одном из них в 10 раз. Причем хаотически и непредсказуемо, о чем шла речь с статье.

Да забей ты на статью. Просто если у тебя есть N модулей то между ними есть 2 крайних варианта
1) N-1 связей между ними (идеальный дизайн)
2) N*N связей (наихудший дизайн)

Это экстремальные значения, в реальной жизни получается где то наверное N*LnN — но все равно не линейно.

G>А время фазы интеграции, где все это должно взлететь, мы запланируем отдельно, основываясь на предполагаемой плотности дефектов (defect/KLOC) и размере кода в строках (LOC), и измеренном времени на дефект (или возьмем прогноз частично из головы, обработав его PERT-ом — тоже неплохо получится). Продуктивность при планировании этой фазы не очень интересна. И все, нелинейность вас не волнует, проверено при размере команды до 20 чел и сроке проекта до полутора лет. Если добавить, что план постоянно корректируется по ходу получения фактической информации по продуктивности и рискам, так все вообще станет хорошо.

Полтора года это очень короткий проект, есть такие решения типа сделать сдать и забыть. Здесь действительно legacy это не так страшно. Но все равно есть. Кроме того ты для чего сроки измеряешь для программы или для продукта? Я так понимаю что обсуждать имеет смысл продукт, во всяком случае CoCoMo коэффичиенты для них посчитаны. Я не вижу смысл считать продуктивность в KLoc для кода который еще нужно дорабатывать в двое большее времени чем потратили на написание.

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

A>>Отдельные сомнения теперь вызывает и оценка оценка 20-60loc/hr очень похожа на оценку в час. Я легко поверю в такой темп в краткосрочной перспективе, но на протяжении года я сильно сомневаюсь, что можно такой темп держать(а ты только что сказал что считается она на протяжении года).
G>А ты не верь, а проверь. 20 LOC/hr — это нормальный измеренный среднийтемп для практически всех команд у нас в компании за последних два года, который стабилен поквартально. Посчитан на групповых проектах сроком от полугода — понятно, что это не двухчасовая изолированная задачка, которая колбасится на 60 LOC/hr (у меня — 45 LOC/hr).

G>Сейчас попробую достать наши метрики по закрытым проектам, если получится, пришлю сюда.

Давай. С интересом посмотрю.

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

Золотые слова. Просто золотые и все.
Часто руководитель девелопмента нахватает проектов — а потом у него элементарно некому их делать. Развитие компании в персонале отстает от развития в заказчиках.

А проекты хватаются с надеждой на авось.

OE>сделать проще гораздо сложнее и дольше, чем сделать сложнее, сложно — оно само-собой
получается

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

Сделать сложнее — оно тупее в плане требований к архитекторам, но всегда хуже по общим срокам проекта.