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

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

_>>Ежедневный отчет о проделанной работе. И желательно в письменном (электронном) виде.

SSP>Всегда хотел узнать: почему руководство предпочитает задания раздавать в устной форме,
SSP>а отчёты получать в письменной.
Это способ уйти от ответственности. Наряду с требованиями с разработчикам существуют требования к заказчику — четкие и однозначно трактуемые требования. Начальство, выступая в роли заказчика, этим заниматься не любит . Поэтому процесс разработки должен начанаться с анализа, выполняемого вовсе и не разработчиками, а системными и бизнес-аналитиками.

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

C>Здравствуйте!
C>В конторе складывается такая ситуация.
C>Составляется квартальный план, с учетом мнения разработчика. Т.е., по общему мнению руководителя и разработчика плотный, но выполнимый график.
C>Далее, по прошествии некоторого времени, руководитель выдает разработчику дополнительное срочное, жизненно важное задание. Обычно не надолго, на 2-3 недели. За квартал так может быть 1-2 раза. Такие задания обычно не вносятся в план.
C>По прошествии квартала разработчик отчитывается за свой первоначальный план, а дополнительные задания упускаются из рассмотрения. Чаще всего, естественно, разработчик свой план выполнить неуспевает.
C>Поднимается вопрос о том, что разработчик — разгильдяй.

Часто разработчик внутренне не готов признать необходимость пересмотреть сроки готовности — во многих организациях (особенно не софтверных) это не приветствуется, вследствие чего развивается синдром хронического срыва сроков (хвосты "наезжают" один на другой, задачи откладываются и все это тянется бесконечно). Мне кажется, в поставленном вопросе ключевой фрагмент — "Такие задания обычно не вносятся в план.". Не внося в план и не предостовляя текущей отчетности по продвижению текущей задачи человек часто сам себя загоняет в цейтнот — откладывая реализацию дополнительной задачи на потом и даже приступая к ней время от времени — и внезапно возвращаясь к основной работе. На таких неконтролируемых переходах теряется очень много времени.

Тут кто-то упомянул о числе пи, вспомнилось
Один кадр на проекте писал процедуру инициализации базы в течение года (и сейчас продолжает). То ошибки, то клиент вспомнит какую-нибудь забытую деталь, то полбазы попросит переделать и всё такое, классика. Авангард в том, что на днях его процедура доросла до 314 скриптов . Адская неподъёмная смесь perl, shell, PL/SQL и Java. Единственная и любимая методология — copy-paste. Поэтому когда клиент просит добавить пробел в одно поле, это может потребовать пары дней

Вот это настоящий раздолба-разгильдяй. Причина всех остальных бедствий, описанных Constructor-ом — НУЛЁВЫЙ МЕНЕДЖМЕНТ. Да и авангардиста можно туда же. Не было вовремя подходящих ресурсов, поставили такого, вроде не дебютант. А потом шеф вовремя его не заменил.

Кто становится шефами проектов ? Вчерашние программисты с техническим образованием ? Зачатки менеджмента, преподаваемые в институте, благополучно забИвались. Бывшие студенты-управленцы без представления об ИТ ? Если им не дают нормальных ресурсов — заваленные проекты

Отдельная категория — ставшие умственными инвалидами-параноиками. Дебютанты, решившие, что они способны. И попросившие (или согласившиеся принять) ответственность. А по ним проехались катком их оппоненты-клиенты с 20..30 летним опытом. А собственное начальство сделало их козлами отпущения. Жалкое зрелище

Моё мнение, что человек без 4..6 лет опыта в ИТ, из них 2..3 шефом команды или проекта, мало чего стоит с т.з. менеджмента и не автономен. И неплохо в начале поучаствовать шефом команды в немаленьком проекте (человек 30..50) под управлением реального профессионала. Хороший размер проекта, на котором присутствуют очень много профилей: от дебютантов до профессионалов, от клёвых перцев до полных моральных уродов. И интересоваться не только RUP и CMM, а расширять кругозор психологией, управлением, политикой, ... иначе вас съедят

сколько написал

PreScriptum: всё нижесказанное исключительно для повышения интереса беседы и выяснения истин в части нашего их понимания.


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

S>>Не сильно я, конечно, разбираюсь в проджект менеджменте, однако, не помню, чтобы где-нибудь в COCOMO II или FPA учитывались строки кода без учёта языка, а точнее средств разработки. Не дадите ссылку?
G>Не дам . В СOCOMO II язык учитывается. Я кстати, не говорил, что от языка продуктивность не зависит. Я говорил, что она зависит не сильно. У программиста на ассемблере не будет на порядок выше продуктивность в строках отлаженного кода в час (генеренные строки и комментарии не считать). Хотите — проведите межязыковое сравнение по своей компании — это не сложно. Готов заключить пари, что средняя продуктивность программиста за год по вашей компании уложтся в коридор 20-60 строк строк в час независимо от языка. Мы сравнивали С++ и С#, В Ericsson сравнивали 5 непохожих друг на друга языков.

Во-первых разброс продуктивности по вашему коридору как минимум в три раза, что нехило (как при таком разбросе планировать, не очень понятно). Во-вторых, сравниваемые вами языки достаточно близки (если бы вы сравнили хотя бы классический C++ и VB, у вас бы была разница где-то раза в 2. Не знаю, что там сравнивали в Ericsson, но я видел описанные в методиках conversion ratio для различных языков, предназначенные для анализа объёма кода, решающего одинаковые задачи, где даже C++ и Visual C++ отличаются в 1,5 раза.

S>>По существу: когда вы говорите про "прогноз объёма" в строках кода — вы говорите серьёзно? И про то, что без этого прогноза ни один серьёзный заказчик не будет разговаривать и тем более тендер заключать?
G>Да, я говорю серьезно. Почитайте Хамфри, автора модели CMM, он тоже говорит серьезно.

Вы имеете ввиду того Хамфри, который Уотс? К сожалению, пока не нашёл материалов с его авторством по поводу объёма в строках (может ссылочку какую подкините?), хотя человек, безусловно, незаурядный, хотя ИМХО слегка консервативный.

S>>И вы действительно считаете указанную вами метрику "основной"?
G>Я дал повод в этом сомневаться? По-моему, я объяснил почему я считаю ее основной и в чем конкретно ее преимущества перед остальными метриками.

В общем дали повод.

Объяснения по поводу простоты метрики не совсем меня убедили, а вот стабильность — это уже лучше. Когда посмотрю индустриальную статистику — может быть мнение опять таки изменится. Кстати, если уж зашла речь о данной статистике, то откуда вы её брали? Что-нибудь вроде документов Gartner Group или ещё где-то? Или основываетесь на EFP методе и подсчёте SLOC? Если последнее, то учёт SLOC требует глубокой проработки проекта на стадии проектирования, что не всегда возможно. Мне больше импонирует, например, оценка по метрикам, основанным на анализе компонентов и их применимости. Потому что такие оценки дают достаточное понимание общего объёма работы, а дальнейшие уточнения можно проводить в рамках итерационного процесса параллельно с изменением и коррекцией требований. Я уж не говорю о том, что SLOC даёт объективную оценку, а некоторые методы разработки (например XP) подразумевают исключительно субъективную оценку теми, кто, собственно и будет разрабатывать ту или иную часть системы.

Кстати, начинаю понимать, откуда растут примеры про минобороны США. Вы, наверное, имели ввиду заключение контрактов данного министерства на разработку ПО с компаниями, имеющими CMM не ниже третьего уровня...

Здесь, кстати, вижу в нашей дискуссии уход в разные плоскости. Когда я говорил о неприменимости отдельных метрик (в том числе и метрики по строкам кода), то не имел ввиду компании, которые могут себе позволить хотя бы приблизиться к возможности сертификации по CMM, по крайней мере по финансовым возможностям. Да и необходимости в этом нет, поскольку далеко не все компании работают на поле заказчиков, выдвигающих столь серьёзные требования к качеству процесса и, что немаловажно, готовых за это платить. А отслеживание любых метрик требует существенных ресурсов. Т.е. есть некоторый почти замкнутый круг.

В одной полупетле компании, которые развиваются по CMM (условно говоря), которых стимулирует бизнес-модель выхода на заказчиков, это требующих. В другой полупетле компании, которые не развиваются по CMM (это не означает, что они гонят некачественный продукт, однако) и которых не стимулируют на данное развитие заказчики, не готовые платить за повышенное качество.

Ко второй "полупетле" относятся большинство мелких и средних компаний. Вот в них то применение всех метрик нецелесообразно, поскольку дорого эти метрики отслеживать. Здесь выбираются метрики, которые в каждой конкретной ситуации наиболее эффективно позволяют осуществлять планирование и выдерживать сроки. И в данном контексте объём задачи "в строках кода" не так уж и часто применяется как метрика.

Предполагаю, что если вы посмотрите, например, на компании, работающие на рынке недорогих систем и разовых заказов (коим по моему текущему убеждения является, к примеру, Rentacoder), то вряд ли вы найдёте там компании, использующие метрику "объём в строках кода". Поскольку там больше используется не расчёты SLOC, а расчёт возможности применения повторно используемого кода. Если есть люди с RAC — прошу подтвердить или опровергнуть моё предположение — было бы интересено узнать.

S>>Надеюсь про тендеры — это шутка?.. Про минобороны США не знаю — не участвовал в тендерах. Американцы — они вообще народ интересный... Про минобороны наше (да и про наши центральные органы власти) — уж поверьте — там никого не интересует "объём кода" при анализе тендерных предложений.
G>Конечно. Там их интересует объем откатов. Как и в большинстве тендеров в России. Я надеюсь, вы привели этот пример в шутку?

Нет, не в шутку. Объём откатов уже мало кого интересует, поскольку люди поумнели. Это лет 10 назат откаты решали всё... Сейчас уже людям нужен результат (что радует — за державу приятно). Скорее не откаты, а надёжность исполнителя (подтверждённая успешными проектами в конкретных бизнес-областях, а не по каким-нибудь CMM) + контакты исполнителя с представителями силовых структур (имеется ввиду их инженерная часть) и других аналогичных ведомств...

G>Тест брейна на PM (я говорю только о нем, и не хочу обсуждать brainbench) проверяет знакомство со специализированной литературой по PM и элементарное понимание базовый понятий PM. Менеджер, который не может его пройти — профнепригоден. Так же как и программист на С++, который ни разу за не читал книг по своей специальности.

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

S>>Не понял. Как их можно учитывать не считая??? В процентах? Т.е. время на набор 20 программистов в Москве и в Усть-Урюпинске одинаково? И не зависит от среды разработки и платформы?
G> Вы вот тут COCOMO упоминали. Неужели вы не знаете две элементарных формулы PERT, и не понимаете, как именно он помогает количественно учесть риски?

2 формулы PERT действительно не знаю... было бы интересно узнать, что вы имеете ввиду.

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

ГВ>Вопрос, который я люблю задавать любителям отчётности (простите за ёрничающий тон): как нужно отображать в отчёте процесс размышлений над некоторой задачей? А спонтанные микросовещания, которые могут длиться по полтора-два часа?

1. почитай вот эту статью
http://www.joelonsoftware.com/global/Russian/Articles/PainlessSoftwareSchedules.html
2. любая мало-мальски серьёзная система стоит денег. чтоб инвестор или клиент дал денег, ему нужен план: что, когда и сколько будет стоить. все серьёзные системы написаны по планам. отчётность служит для оценки и корректировки планов.

если хочешь, можешь "всё" умножить на 0,999. всегда бывают исключения

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

S>>Ладно, согласен, передёргиваю слегка... Разговор шёл про разработчиков... С разработчиками самые богатые будут те, кто на Ассемблере пишут — у них строк больше
G>Да не слегка. Кстати, сразу видно, что вы не считаете строки кода. Сколько именно строк кода конкретный программист колбасит в день — совершенно пофигу, лишь бы сильно не выбивалось за коридор средних (в обе стороны), это говорит о проблемах. Кстати, продуктивность в строках не так сильно зависит от языка. Речь идет о строках отлаженного кода без комментариев.

Кстати, подтверждаю. Когда-то занимался анализом продуктивности по этой метрике. Действительно, всё так и есть. Во всяком случае, если речь идёт об одной и той же команде. Структурные метрики плавают в десятки раз (в особенности — Effort по Холстеду). Видимо, это как-то связано с манерой мышления и интуитивным выбором баланса между мышлением и воплощением.

G>Нельзя позволять машине раскидывать задачи на разработчиков, если вы, конечно, хоть как-то озабочены управлением рисками. Почему? Программисты не взаимозаменяемы, учитывать их индивидуальность необходимо для успеха проекта. В этом ключ к успешной командной работе.
Ну хоть кто-то думающий есть!

Здравствуйте, Бусел,

В целом согласен. Понятно, что менеджеру нужно знать о происходящем в команде — кто над чем работает и т.п. Пусть даже это и каждодневная отчётность. Лишь бы только форма не начинала превалировать над содержанием.

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

[..]

Б>2. Дать ему почувствовать, что его контролируют (Ежедневная отчетность, именно ежедневная).
Б> Над какими работами из плана работал, сколько часов в день, каков результат (кратенько).
Б> Занимает это не более 15 мин/день, вырабатывает чувство самоконтроля и ответственности.
...
Вот все-таки если текущие работа достаточно объемные.. несовсем понятен смысл ежедневной отчетности. Ну занимаюсь я дизайном нового модуля. Или реализую сложный гуй. Что писать — задизайнил 2 класса? Добавил 2 вкладки с четырьмя сплиттерами и датагрид? :)) В таких случаях разработчик тупо поднимает процент готовности для текущей работы и все. Совершенно неинформативно и напряжно для разработчика. Мы давно перешли к понедельной отчетности и вполне довольны.
PS. Возможно для больших команд ежедневная отчетность и необходима, не знаю.

Вот об этом и речь. Тут поминаются методы — которые применяются методы, используемые компаниями где сотрудников более 1000 (или нескольких сотен), причём для проектов стоимостями в сотни мегабаксов — причём над постановкой и контролем за выполнением процессов там работают целые команды.
В такой орде сотрудников индивидуальные особенности разработчиков частенько просто не заметны на общем уровне. И там легко вести расчёты на основе статистики...
А потом местные мудрецы с умным видом советуют применять те же методы в командах из 3-10 человек, да ещё над проектами, где заказчик с трудом готов оплачивать зарплату девелоперам... Сама мысль о дополнительных тратах приведёт заказчика в ярость — ему не нужен "процесс" — ему нужен результат. И если вы попросите денег на процесс — он уйдёт в другую фирму. И это реальность с которой приходится считаться...

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

[...]
Во:!

ему не нужен "процесс" — ему нужен результат.

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

Вот-вот. А понять Шефу, что результат — следствие правильно организованного процесса (не важно откуда он взялся — из собственной интуиции или мудрх книг) — кажется что может помочь только лоботомия...
Тут может помочь статистика — т.е. аккуратный и пунктуальный подстчёт времени, потраченного каждым разработчиком на те или иные задачи — представленный шефу в таком виде — что бы хорошо была видна цена тех срочных задач, которые ставятся перед разработчиками. Голословно утверждать можно что угодно. С фактами спорить сложнее. Если же он и это не воспримет — то, наверное, стоит задуматься о смене работы.

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

AF> Вот-вот. А понять Шефу, что результат — следствие правильно организованного процесса (не важно откуда он взялся — из собственной интуиции или мудрх книг) — кажется что может помочь только лоботомия...
AF> Тут может помочь статистика — т.е. аккуратный и пунктуальный подстчёт времени, потраченного каждым разработчиком на те или иные задачи — представленный шефу в таком виде — что бы хорошо была видна цена тех срочных задач, которые ставятся перед разработчиками. Голословно утверждать можно что угодно. С фактами спорить сложнее. Если же он и это не воспримет — то, наверное, стоит задуматься о смене работы.

Вообще-то в своё время в одной из компаний помогло следующее...
Ситуация была примерно такая, как здесь описывается ("Надо деньги зарабатывать, продукт продавать, а не всякие картинки рисовать!"), с попыткой силового давления на сроки Через некоторое время шефу попалась на глаза (а точнее была подсунута) парочка популярных книг типа "Как заработать деньги в ИТ" или "Правильная организация ИТ бизнеса" (сейчас уже не помню точно). Причём в контексте, мол, кто эту книжку не читал, тот лох позорный и всё такое...
Шеф почитал, понял мало чего (поскольку в ИТ специалистом никогда не был), но, будучи человеком прогрессивным и науки не чуждым (Оксфорд, всё таки) понял, что и ИТ бизнес имеет свои законы и правила. Поэтому на последующие замечания со стороны ИТ менеджмента о необходимости проектирования, прототипирования и прочих "ненужных" действиях уже реагировал вполне адекватно и специалистам начал доверять.

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

S>Вообще-то в своё время в одной из компаний помогло следующее...
S>Ситуация была примерно такая, как здесь описывается ("Надо деньги зарабатывать, продукт продавать, а не всякие картинки рисовать!"), с попыткой силового давления на сроки Через некоторое время шефу попалась на глаза (а точнее была подсунута) парочка популярных книг типа "Как заработать деньги в ИТ" или "Правильная организация ИТ бизнеса" (сейчас уже не помню точно). Причём в контексте, мол, кто эту книжку не читал, тот лох позорный и всё такое...
Хороший, умный и ловкий ход.
S>Шеф почитал, понял мало чего (поскольку в ИТ специалистом никогда не был), но, будучи человеком прогрессивным и науки не чуждым (Оксфорд, всё таки) понял, что и ИТ бизнес имеет свои законы и правила. Поэтому на последующие замечания со стороны ИТ менеджмента о необходимости проектирования, прототипирования и прочих "ненужных" действиях уже реагировал вполне адекватно и специалистам начал доверять.
Хорошо, что удачно сложилось. Чаще увы бывает, что пока речь идёт в общем — шеф доверяет, а когда дело доходит до реального проекта и сроков — 1-2-3-4-5 начинаем всё опять...

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

G>>Сколько именно строк кода конкретный программист колбасит в день — совершенно пофигу, лишь бы сильно не выбивалось за коридор средних (в обе стороны), это говорит о проблемах. Кстати, продуктивность в строках не так сильно зависит от языка. Речь идет о строках отлаженного кода без комментариев.

ГВ>Кстати, подтверждаю. Когда-то занимался анализом продуктивности по этой метрике. Действительно, всё так и есть. Во всяком случае, если речь идёт об одной и той же команде. Структурные метрики плавают в десятки раз (в особенности — Effort по Холстеду). Видимо, это как-то связано с манерой мышления и интуитивным выбором баланса между мышлением и воплощением.

Кстати, а по каким метрикам осуществлялось планирование объёма проектирования, тестирования и т.п. составляющих проекта в вашей конкретной ситуации? Вопрос навеян воспоминанием о схеме из RUP-а, где утверждалось, что непосредственно кодирование — это только около 30% проекта...

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

ГВ>>Кстати, подтверждаю. Когда-то занимался анализом продуктивности по этой метрике. Действительно, всё так и есть. Во всяком случае, если речь идёт об одной и той же команде. Структурные метрики плавают в десятки раз (в особенности — Effort по Холстеду). Видимо, это как-то связано с манерой мышления и интуитивным выбором баланса между мышлением и воплощением.
S>Кстати, а по каким метрикам осуществлялось планирование объёма проектирования, тестирования и т.п. составляющих проекта в вашей конкретной ситуации? Вопрос навеян воспоминанием о схеме из RUP-а, где утверждалось, что непосредственно кодирование — это только около 30% проекта...

Это были усреднённые показатели: берём общее количество строк кода (Logical Lines Of Code, не просто по счётчику), вычитаем сгенерированные и делим на продолжительность разработки — от постановки задачи до момента сдачи модуля. Разбор сделал где-то за полгода нашей деятельности, язык — C++. Производительность колебалась в пределах 70-180 строк/день по команде, по одному человеку разброс был где-то в пределах 10%, если приводить к месяцу.

S>а по каким метрикам осуществлялось планирование объёма проектирования

Ты неправильно понял. Метрики снимаются с готового проекта. До проведения некоторой фазы метрики её результата можно назвать только приблизительно. Хотя, можно набросать некоторые ожидаемые значения метрик после первоначального проектирования. В конце концов, взять число классов, число методов и помножить на некоторый коэффициент, вычисляемый в зависимости от языка програмимрования и дисциплины реализаторов. Но вот предсказать, сколько именно будет классов, каков коэффициент повторного использования... Мне тогда (1999-2000 гг.) это не удалось.

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

S>Во-первых разброс продуктивности по вашему коридору как минимум в три раза, что нехило (как при таком разбросе планировать, не очень понятно).
Это примерный коридор средних по индустрии. В рамках одной команды и одного языка разброс будет меньше (примерно десятка). У одного человека на одном языке средняя метрика на большом объеме кода вообще стабильна, и индивидуальна для человека. Поэтому я и говорю, что ее надо брать из завершенных проектов. Она в большей степени определяется стилем этого человека, нельзя судить о его профессионализме программеров сравнивая их продуктивность. Подробнее об этом здесь

Автор: Gaperton
Дата: 10.08.04

.

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

S>Во-вторых, сравниваемые вами языки достаточно близки (если бы вы сравнили хотя бы классический C++ и VB, у вас бы была разница где-то раза в 2. Не знаю, что там сравнивали в Ericsson, но я видел описанные в методиках conversion ratio для различных языков, предназначенные для анализа объёма кода, решающего одинаковые задачи, где даже C++ и Visual C++ отличаются в 1,5 раза.
Это мне, с моим основным средством Visual C++ непонятно. Скорее всего это потому, что в этих методиках прогноз делается через функциональные точки. В Visual C++ часть кода, относящегося к GUI, генерируется визардами. Автогенеренный код не должен участвовать в рассчете продуктивности, и этот коэффициент вычитает автогенеренный код. Время разработки также будет отличаться, а вот продуктивность в LOC в вашем примере не должна отличаться вовсе. Не с чего. Кстати замечу, что по приведенным вами данным ее вообще посчитать нельзя, я уж за вас додумываю, на что вы намекаете.

S>Вы имеете ввиду того Хамфри, который Уотс? К сожалению, пока не нашёл материалов с его авторством по поводу объёма в строках (может ссылочку какую подкините?), хотя человек, безусловно, незаурядный, хотя ИМХО слегка консервативный.
Он автор PSP, там все планирование делается формально через SLOC.


S>Объяснения по поводу простоты метрики не совсем меня убедили, а вот стабильность — это уже лучше.
LOC интуитивно понятна, ее легко прогнозировать. Спросите программера о длине функции. Он скажет — да фигня — пол экрана кода. Или, например, — "да он вообще офигел, у него один метод десять экранов кода занимает! Ужас". Хотите перевести это в строки кода? Умножте на размер "экрана". Об этом и речь.

А вы пробовали научится прогнозировать метрику Cyclomatic Complexity? Это не так просто (на самом деле — no way), плюс ко всему она скачет как черт знает что. Например, вы сделали небольшой рефакторинг, и видите, что кол. строк кода уменьшилось на 20%. Что это означает — ну можно предположить, что мы убрали копипейст и выделили общий функционал, правильно? А вот метрика cyclomatic complexity при этом скакнула на 15% вверх (из примера с сайта Carnegie-Mellon SEI, привожу по памяти). Сюрприз. Нового функционала вы не добавили — попробуйте как-нибудь это объяснить, и главное, спрогнозировать. Подобного рода сюрпризы вас будут ждать со всеми метриками, которые не вычисляются простым суммированием видимых глазом объектов.

Кстати еще насчет стабильности. Еще одна чрезвычайно стабильная метрика, основанная на LOC — это плотность дефектов штук/1000 строк. Вот она — нереально стабильна для одного человека — проверяли. Удивительно, но факт.

S>Когда посмотрю индустриальную статистику — может быть мнение опять таки изменится. Кстати, если уж зашла речь о данной статистике, то откуда вы её брали? Что-нибудь вроде документов Gartner Group или ещё где-то?
Я взял ее из статистики, собранной в рамках работ по PSP. Эта статистика собирается и обрабатывается Carnegie-Mellon SEI. Она сильно зависит от методики замера, естественно. Плюс, за последние несколько лет у нас накопилась статистика по нашей компании, которая укладывается в индустриальную. Имейте в виду, что продуктивность основанная на LOC зависит от методики измерения этих самых LOC, так что сравнивать замеры в разных компаниях надо осторожно. В общем, сходите на их сайт, там очень много есть про метрики.

S>Или основываетесь на EFP методе и подсчёте SLOC? Если последнее, то учёт SLOC требует глубокой проработки проекта на стадии проектирования, что не всегда возможно.
Примерно прикидывается через функциональные точки, например. Или просто "из головы", но через PERT. Это можно сделать довольно рано. При большом количестве единиц планирования погрешность должна уйти до разумных пределов, и будет вполне адекватно. Точные значения на начальной фазе планирования все равно никого не интересуют, очевидно, что это невозможно в принципе.

S>Мне больше импонирует, например, оценка по метрикам, основанным на анализе компонентов и их применимости. Потому что такие оценки дают достаточное понимание общего объёма работы, а дальнейшие уточнения можно проводить в рамках итерационного процесса параллельно с изменением и коррекцией требований. Я уж не говорю о том, что SLOC даёт объективную оценку, а некоторые методы разработки (например XP) подразумевают исключительно субъективную оценку теми, кто, собственно и будет разрабатывать ту или иную часть системы.
Так ваш прогноз SLOC и будет субъективен, и, кстати, не очень точен. В принципе, его можно сделать и точным до процентов, как это сделано в PSP (основываясь на данных по закрытым задачам + спец. схема обработки экспертных оценок), но не думаю, что это целесообразно. Геморроя много, а польза не очевидна.

S>Здесь, кстати, вижу в нашей дискуссии уход в разные плоскости. Когда я говорил о неприменимости отдельных метрик (в том числе и метрики по строкам кода), то не имел ввиду компании, которые могут себе позволить хотя бы приблизиться к возможности сертификации по CMM, по крайней мере по финансовым возможностям. Да и необходимости в этом нет, поскольку далеко не все компании работают на поле заказчиков, выдвигающих столь серьёзные требования к качеству процесса и, что немаловажно, готовых за это платить. А отслеживание любых метрик требует существенных ресурсов. Т.е. есть некоторый почти замкнутый круг.
В принципе, высокие уровни СММ не является необъходимостью для использования метрик при планировании и контроле. Это гораздо проще и дешевле, чем многие думают (и чем я думал раньше), к этому надо просто привыкнуть, и потом будешь удивляться, как обходился без метрик раньше. Надо всего-то вести статистику по чекинам — сколько строк кода удалено/изменено/добавлено (может считаться автомат. скриптом), да (если хочется) сделать привязку модулей и чекинов к базе данным по дефектам. И вы всю статистику получите почти автоматически. Чтобы потом поюзать несколько средних величин и коридоры значений в Excel, где будете делать прогноз.

S>>>Не понял. Как их можно учитывать не считая??? В процентах? Т.е. время на набор 20 программистов в Москве и в Усть-Урюпинске одинаково? И не зависит от среды разработки и платформы?
G>> Вы вот тут COCOMO упоминали. Неужели вы не знаете две элементарных формулы PERT, и не понимаете, как именно он помогает количественно учесть риски?
S>2 формулы PERT действительно не знаю... было бы интересно узнать, что вы имеете ввиду.
Освой PERT за 5 минут! Мастер-класс от Гапертона на rsdn.ru

Автор: Gaperton
Дата: 17.07.03

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

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

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

S>>Во-первых разброс продуктивности по вашему коридору как минимум в три раза, что нехило (как при таком разбросе планировать, не очень понятно).
G>Это примерный коридор средних по индустрии. В рамках одной команды и одного языка разброс будет меньше (примерно десятка). У одного человека на одном языке средняя метрика на большом объеме кода вообще стабильна, и индивидуальна для человека. Поэтому я и говорю, что ее надо брать из завершенных проектов. Она в большей степени определяется стилем этого человека, нельзя судить о его профессионализме программеров сравнивая их продуктивность. Подробнее об этом здесь

Автор: Gaperton
Дата: 10.08.04

.
G>Но эта метрика отличается от задачи к задаче, даже у одного человека в рамках одного языка. Почему так? Потому, что колебания продуктивности отражают риски, учтенные в плане и фактически "сыгравшие" при решении задачи. Или степень компетентности конкретного программера в предметной области — да много чего. При планировании времени/объема вы фактически планируете продуктивность, и ее колебания вокруг среднего отражают ваше представление о рисках и прочих факторах, влияющих на продуктивность. Но вы делаете это опосредованно, прогнозируя объем и время.

С этим согласен. Неясно только следующее... Если на коридор так существенно влияют дополнительные факторы предметной области, среды разработки и т.п., то в чём смысл наличия индустриальных средних? Т.е. я ещё могу доверительно относиться к исследованиям, утверждающим, что на один примитивный вывод информации в диалоговое окно уходит в среднем какое-то количество строк кода в зависимости от языка и среды разработки. Это звучит правдоподобно, потому что понятен базис расчёта — задача исключительно типовая (GUI). Что же касается, например, запросов к базе данных (так называемых Request-ов), то здесь совершенно неясно, как считается средний по индустрии LOC для SQL, поскольку запросы ОЧЕНЬ сильно отличаются в зависимости от структуры БД, СУБД, необходимости оптимизации и кучи дополнительных условий. Думаю, что похожая ситуация и с написанием классов предметной области.

Есть, конечно, разные корректирующие коэффициенты... Может в них дело?
Кстати, лучший коэффициент в планировании, который я встречал в своей жизни, был произнесён 15 лет назад моим первым шефом. Звучал примерно так: "хорошая система получается только с третьего раза". Очень стабильный коэффициент оказался.

G>При этом, чрезмерное колебание продуктивности, выходящее за коридор разумного для конкретного программера/команды и/или не соответствующее вашему представлению о риске, сразу укажет вам на ошибку планирования. Вот вам и все "пи".

Говоря проще, если вы сделали план, который не выполняется, то это означает, что вы ошиблись в планировании. Ну да, факт. Согласен.

S>>Во-вторых, сравниваемые вами языки достаточно близки (если бы вы сравнили хотя бы классический C++ и VB, у вас бы была разница где-то раза в 2. Не знаю, что там сравнивали в Ericsson, но я видел описанные в методиках conversion ratio для различных языков, предназначенные для анализа объёма кода, решающего одинаковые задачи, где даже C++ и Visual C++ отличаются в 1,5 раза.
G>Это мне, с моим основным средством Visual C++ непонятно. Скорее всего это потому, что в этих методиках прогноз делается через функциональные точки.

Да, совершенно верно. Это взято из описания метода Early Function Points.

G>В Visual C++ часть кода, относящегося к GUI, генерируется визардами. Автогенеренный код не должен участвовать в рассчете продуктивности, и этот коэффициент вычитает автогенеренный код. Время разработки также будет отличаться, а вот продуктивность в LOC в вашем примере не должна отличаться вовсе. Не с чего. Кстати замечу, что по приведенным вами данным ее вообще посчитать нельзя, я уж за вас додумываю, на что вы намекаете.

А что всё-таки понимается под "продуктивностью"?

G>Кстати еще насчет стабильности. Еще одна чрезвычайно стабильная метрика, основанная на LOC — это плотность дефектов штук/1000 строк. Вот она — нереально стабильна для одного человека — проверяли. Удивительно, но факт.

Попробую оценить. А как проверяли, если не секрет?

S>>Когда посмотрю индустриальную статистику — может быть мнение опять таки изменится. Кстати, если уж зашла речь о данной статистике, то откуда вы её брали? Что-нибудь вроде документов Gartner Group или ещё где-то?
G>Я взял ее из статистики, собранной в рамках работ по PSP. Эта статистика собирается и обрабатывается Carnegie-Mellon SEI. Она сильно зависит от методики замера, естественно. Плюс, за последние несколько лет у нас накопилась статистика по нашей компании, которая укладывается в индустриальную. Имейте в виду, что продуктивность основанная на LOC зависит от методики измерения этих самых LOC, так что сравнивать замеры в разных компаниях надо осторожно. В общем, сходите на их сайт, там очень много есть про метрики.

Уже там пасусь вовсю Правда объём информации великоват и есть предположение, что работает принцип 20/80 (т.е. 20% информации может действительно понадобиться), но, возможно, основные теоретические моменты удастся выцепить за достаточно разумное время.

S>>Или основываетесь на EFP методе и подсчёте SLOC? Если последнее, то учёт SLOC требует глубокой проработки проекта на стадии проектирования, что не всегда возможно.
G>Примерно прикидывается через функциональные точки, например. Или просто "из головы", но через PERT. Это можно сделать довольно рано. При большом количестве единиц планирования погрешность должна уйти до разумных пределов, и будет вполне адекватно. Точные значения на начальной фазе планирования все равно никого не интересуют, очевидно, что это невозможно в принципе.
Попробую проверить на следующем проекте. Посмотрим. Здесь же как — пока сам не убедишься — можно и теории верить, но осадочек остаётся...

S>>>>Не понял. Как их можно учитывать не считая??? В процентах? Т.е. время на набор 20 программистов в Москве и в Усть-Урюпинске одинаково? И не зависит от среды разработки и платформы?
G>>> Вы вот тут COCOMO упоминали. Неужели вы не знаете две элементарных формулы PERT, и не понимаете, как именно он помогает количественно учесть риски?
S>>2 формулы PERT действительно не знаю... было бы интересно узнать, что вы имеете ввиду.
G>Освой PERT за 5 минут! Мастер-класс от Гапертона на rsdn.ru

Автор: Gaperton
Дата: 17.07.03

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

Сенкс. Формулы простые и понятные. Непонятно только, как расчитывать переменные в этих формулах с наименьшей погрешностью.

P.S. Думаю, нужно будет вернуться к данной беседе где-то после нового года, поскольку в текущий момент чувствую некоторую нехватку информации, которая не даёт в некоторых случаях аргументировать интуитивные догадки. Интуиция — она вещь хорошая (мне за неё как раз деньги и платят ), но в контексте данной беседы всё же хочется аргументировать собственные мысли на том же языке, которым вы привыкли оперировать.

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

AF> Вот об этом и речь. Тут поминаются методы — которые применяются методы, используемые компаниями где сотрудников более 1000 (или нескольких сотен), причём для проектов стоимостями в сотни мегабаксов — причём над постановкой и контролем за выполнением процессов там работают целые команды.
Чепуха. Не знаю кто поминает такие методы, но мне кажется, вы на меня намекаете, да?

Вы хоть знаете, как расшифровывается PSP, помянутый здесь? Personal Software Process. Я надеюсь, вы знаете, что означает слово "personal"? Что касательно сотен мегабаксов и тысяч сотрудников... Ну в самом деле, ну должна же быть объективная причина, что вы этими методами не пользуетесь, а то ведь получится, что вы не разбираетесь в PM, так?

AF> А потом местные мудрецы с умным видом советуют применять те же методы в командах из 3-10 человек, да ещё над проектами, где заказчик с трудом готов оплачивать зарплату девелоперам...
Да где уж нам, мудрецам, до гуру, умножающих свои пророчества сроков на пи.

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

M>Тут кто-то упомянул о числе пи, вспомнилось
M>Один кадр на проекте писал процедуру инициализации базы в течение года (и сейчас продолжает). То ошибки, то клиент вспомнит какую-нибудь забытую деталь, то полбазы попросит переделать и всё такое, классика. Авангард в том, что на днях его процедура доросла до 314 скриптов . Адская неподъёмная смесь perl, shell, PL/SQL и Java. Единственная и любимая методология — copy-paste. Поэтому когда клиент просит добавить пробел в одно поле, это может потребовать пары дней
Так это-же не столько проблемы управления, сколько оценка способностей человека ...

M>Вот это настоящий раздолба-разгильдяй. Причина всех остальных бедствий, описанных Constructor-ом — НУЛЁВЫЙ МЕНЕДЖМЕНТ. Да и авангардиста можно туда же. Не было вовремя подходящих ресурсов, поставили такого, вроде не дебютант. А потом шеф вовремя его не заменил.
Не совсем согласен что это менеджмент, это как раз проектирование ...

M>Кто становится шефами проектов ? Вчерашние программисты с техническим образованием ? Зачатки менеджмента, преподаваемые в институте, благополучно забИвались. Бывшие студенты-управленцы без представления об ИТ ? Если им не дают нормальных ресурсов — заваленные проекты
Кстати, интересное наблюдение, по окружающей обстановке. Заметил тенденцию что менеджерский состав в больше половины проектов компании (обращаю внимание что это imho) описать так, женщина, желательно за 40 и желательно без сильных семейных привязаностей. И что самое интересное это эффект — менеджмент превращается в ежечастное — "ну как у нас дела?", "успеваем ли в сроки?" и т.д. и т.п., причём ставка явно сделана именно на женский пол Мы с нетерпением ожидаем окончания эксперимента ....


M>Отдельная категория — ставшие умственными инвалидами-параноиками. Дебютанты, решившие, что они способны. И попросившие (или согласившиеся принять) ответственность. А по ним проехались катком их оппоненты-клиенты с 20..30 летним опытом. А собственное начальство сделало их козлами отпущения. Жалкое зрелище
Ну это уже клиника, подобные вещи можно сразу определить на глаз

M>Моё мнение, что человек без 4..6 лет опыта в ИТ, из них 2..3 шефом команды или проекта, мало чего стоит с т.з. менеджмента и не автономен. И неплохо в начале поучаствовать шефом команды в немаленьком проекте (человек 30..50) под управлением реального профессионала. Хороший размер проекта, на котором присутствуют очень много профилей: от дебютантов до профессионалов, от клёвых перцев до полных моральных уродов. И интересоваться не только RUP и CMM, а расширять кругозор психологией, управлением, политикой, ... иначе вас съедят
Как таковой (imho), методология это не закон, это рекомендация, а уж как ты работаешь и тем более как управляешь проектом, это твой личный опыт, который ты применяешь и развиваешь соответсвенно.
Никакая методология не научит человека, правильно вести себя в стресовой ситуации, например когда понимаешь что была допушена ошибка в планировании, а сроки уже поджимают. Каждый будет вести себя так, как умеет, может где-то видел, но всё равно это будет индивидуально.
И (imho) управление как таковое представляется именно твоим взглядом на ситуацию (проект, сроки, планы и т.п.) и то как ты будешь решать проблемы. А научиться видить, умеет ли человек решать проблему и доводить задачу до конца, с приемлемым или хорошим качеством, это уже дело опыта.

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

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

AF>> Вот об этом и речь. Тут поминаются методы — которые применяются методы, используемые компаниями где сотрудников более 1000 (или нескольких сотен), причём для проектов стоимостями в сотни мегабаксов — причём над постановкой и контролем за выполнением процессов там работают целые команды.
G>Чепуха. Не знаю кто поминает такие методы, но мне кажется, вы на меня намекаете, да?
Мания величия в активной фазе...

G>Вы хоть знаете, как расшифровывается PSP, помянутый здесь? Personal Software Process. Я надеюсь, вы знаете, что означает слово "personal"? Что касательно сотен мегабаксов и тысяч сотрудников... Ну в самом деле, ну должна же быть объективная причина, что вы этими методами не пользуетесь, а то ведь получится, что вы не разбираетесь в PM, так?
Personal Computer применяется отдельными персонами — как в компании из 1-2-3 человек так и в мегакорпорациях с сотнями тысяч сотрудников. Вот и PSP применяется каждым персонально но в рамках компании практически любого масштаба. А вот позволить себе нанять людей которые будут толком ставить процесс — на практике как правило могут себе позволить лишь достаточно большие компании.

AF>> А потом местные мудрецы с умным видом советуют применять те же методы в командах из 3-10 человек, да ещё над проектами, где заказчик с трудом готов оплачивать зарплату девелоперам...
G>Да где уж нам, мудрецам, до гуру, умножающих свои пророчества сроков на пи.
Естественно — вы же и до ПИ пока не доросли...