Господа, не подскажете ли какие существуют системы, предназначенные для измерения размера программного продукта. Облазил web, но пока не нашел ):
Хотелось бы чтоб утилитка умела считать кол-во строк для проектов, написанных на разл языках. Умела различать строчки созданные программистом и компиляторомю.
И конечно, умела бы генерировать отчеты.
Здравствуйте, Orin.i9, Вы писали:
OI>Господа, не подскажете ли какие существуют системы, предназначенные для измерения размера программного продукта. Облазил web, но пока не нашел ): OI>Хотелось бы чтоб утилитка умела считать кол-во строк для проектов, написанных на разл языках. Умела различать строчки созданные программистом и компиляторомю. OI>И конечно, умела бы генерировать отчеты.
Глянь по поиску, тему поднимали эту неделю назад
Здравствуйте, slavdon, Вы писали:
SS> Глянь по поиску, тему поднимали эту неделю назад
К сожалению я не смог найти информации именно по тулам обеспечивающим измерение кода Возможно сказался фактор моего первого посещения rsdn.ru
Что странно — думал что проблем с поиском подобной утилиты не возникнет.
Здравствуйте, Orin.i9, Вы писали:
OI>К сожалению я не смог найти информации именно по тулам обеспечивающим измерение кода Возможно сказался фактор моего первого посещения rsdn.ru OI>Что странно — думал что проблем с поиском подобной утилиты не возникнет.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Подсчет "строк кода" — идиотизм. Идет из времен ассемблера и Фортрана эдак на PDP-11.
MSS>Измерение размера кода в килобайтах — намного разумнее.
1) А как же метрики количества дефектов на KSLOC. Пытаться предсказать кол-во дефектов по "весу продукта в километрах" мне не представляется более разумным.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Измерение размера кода в килобайтах — намного разумнее.
А почему бы не в сантиметрах: суммарная длина исходников по вертикали на листах, составленных по короткой стороне? Или в граммах: общий вес бумаги после распечатывания всех исходников?
Здравствуйте, A.Lokotkov, Вы писали:
AL>А почему бы не в сантиметрах: суммарная длина исходников по вертикали на листах, составленных по короткой стороне? Или в граммах: общий вес бумаги после распечатывания всех исходников?
Ага! Дальше предлагаю внедрить метрику успешности проекта:
1) Из базы bug-tracking распечатать общий отчет по дефектам.
2) Посредством новейшей методики "Refiting Fire II" через сожжение привести код проекта и отчет по дефектам к единому состоянию для упрощения дальнейшего анализа.
3) Сравнить количество дефектов и написанного кода взвесив на чашах весов полученный пепел.
4) Интерпретировать полученный результат — качество проекта налицо (в переносном смысле, не стоит сразу кидаться в пепел, еще не все потеряно. ведь можно и тестеров уговорить более кратко излагать свои мысли, для этого предлагаю дефекты описывать исключительно на буркиноафасовском языке).
5) Ввести дополнительные коэффиценты, н/п степень перевешивания
Спасибо за помощь. Продукты посмотрел,
но к сожалению так и нашел программ которые бы работали с различными версионными хранилищами, такими как VSS и ClearCase.
Здравствуйте, Orin.i9, Вы писали:
OI>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>Подсчет "строк кода" — идиотизм. Идет из времен ассемблера и Фортрана эдак на PDP-11.
MSS>>Измерение размера кода в килобайтах — намного разумнее.
OI>1) А как же метрики количества дефектов на KSLOC. Пытаться предсказать кол-во дефектов по "весу продукта в километрах" мне не представляется более разумным.
Значит, дурацкие метрики, опять же тех самых фортрановских времен.
Вот смотрите сами:
if() {
expression
}
и
if()
{
expression
}
— то же самое, а в одном из примеров на 1 строку кода больше, чем во втором.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>Подсчет "строк кода" — идиотизм. Идет из времен ассемблера и Фортрана эдак на PDP-11.
B>Подобные заявления — вот это в самом деле не умно.
Я чуть выше ответил (ответ был адресован Orin.i9) — почему сия метрика есть маразм, и почему покилобайтная метрика лучше.
MSS>>Измерение размера кода в килобайтах — намного разумнее.
AL>А почему бы не в сантиметрах: суммарная длина исходников по вертикали на листах, составленных по короткой стороне? Или в граммах: общий вес бумаги после распечатывания всех исходников?
Потому что метрика в виде "размер исходного кода" — вообще говоря, есть маразм в любом ее виде. непонятно, чему разумному может служить эта метрика. Расчету условных показателей в абстрактно-теоретических книжках?
А уж разновидность этой метрики под названием "строки кода" — есть особо маразматичная ее разновидность. Приведу пример еще раз:
if() {
}
if()
{
}
В современных языках она просто не годится. Зато годится в Фортране и ассемблерах, где строго по одному оператору в строке.
Скажите, где, как, когда и чему полезному может служить метрика "размер исходного кода". Буду очень рад. Сам я этого понять не могу.
Это что — показатель, который предполагается стимулировать? т.е. стимулировать овердизайн и очень длинные комментарии? или — в случае "строк кода" — стимулировать принцип "новая лексема с новой строки"?
Ни качество продукта, ни соблюдение сроков не имеют никакого отношения к этой метрике.
OI>Ага! Дальше предлагаю внедрить метрику успешности проекта: OI>1) Из базы bug-tracking распечатать общий отчет по дефектам.
Аааа!
Так вот зачем в PMных книжках используется метрика "строки кода"!. Для получения показателя под названием "баги на строку кода"!
Умно до блеска. Сторонники такой метрики — скажите, а вы хоть раз реальный bugtracker видели?
Дело в том, что issues там разные. Очень много там, например, неполного взаимопонимания заказчика и постановщика задачи. Очень много там, например, ситуаций, когда продукт должен уметь "еще и вот это", а девелоперы об этом забыли — просто проглядели.
Или возьмем понятие "степень серьезности бага". Это понятие совершенно разное в глазах тестеров/заказчиков/начальства — и в глазах девелоперов.
Например, баг уровня серьезности crash (высший уровень, продукт сам не работает как надо и валит всю ОС) — зачастую правится без исследования и воспроизведения, просто по тестерскому описанию уже ясно, и первый взгляд на реальный код уже дает понять, где и как править. Один час работы.
А баг уровня серьезности minor (interop с другим продуктом, редко наблюдаемый, ничего не валится, просто часть фич не работает) — зачастую требует целых исследований для своего затыкания. Дня три работы.
В свете всего это метрика "количество багов на единицу размера исходника" — выглядит маразмом. Независимо от того, как этот размер мерять.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Здравствуйте, Orin.i9, Вы писали:
OI>>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>>Подсчет "строк кода" — идиотизм. Идет из времен ассемблера и Фортрана эдак на PDP-11.
MSS>>>Измерение размера кода в килобайтах — намного разумнее.
OI>>1) А как же метрики количества дефектов на KSLOC. Пытаться предсказать кол-во дефектов по "весу продукта в километрах" мне не представляется более разумным.
MSS>Значит, дурацкие метрики, опять же тех самых фортрановских времен.
MSS>Вот смотрите сами:
MSS>if() { MSS> expression MSS>}
MSS>и
MSS>if() MSS>{ MSS> expression MSS>}
MSS>- то же самое, а в одном из примеров на 1 строку кода больше, чем во втором.
MSS>Покилобайтный счетчик так не обманешь.
Нормальные тулы это учитывают.
Тупо строки никто и не считает.
Впрочем с идеей покилобайтных счетчиков можешь обраться в какой-нибудь SEI.
Может они тот же COCOMO под него адаптируют
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Скажите, где, как, когда и чему полезному может служить метрика "размер исходного кода". Буду очень рад. Сам я этого понять не могу.
А чем тебе не нравится метрика "количество дефектов на 1000 логических строк кода",
Где дефект — это то, что нашли юзеры после выпуска продукта?
Вполне неплохая метрика, которая характеризует процесс разработки в целом.
Реально применяется в фирмах, которые пытаются управлять своим качеством.
Только прежде чем критиковать, подумай о проблеме в целом.
У нас же форум "управление проектами"...
Здравствуйте, Maxim S. Shatskih, Вы писали:
OI>>Ага! Дальше предлагаю внедрить метрику успешности проекта: OI>>1) Из базы bug-tracking распечатать общий отчет по дефектам.
MSS>Аааа!
MSS>Так вот зачем в PMных книжках используется метрика "строки кода"!. Для получения показателя под названием "баги на строку кода"!
MSS>Умно до блеска. Сторонники такой метрики — скажите, а вы хоть раз реальный bugtracker видели?
Угу... Мы еще ими и пользуемся
MSS>Очень много там, например, ситуаций, когда продукт должен уметь "еще и вот это", а девелоперы об этом забыли — просто проглядели.
"Девелоперы забыли" — это кстати серьезный дефект, который не повышает оценку процесса в целом.
Такие дефекты обязательно надо учитывать.
Метрики, кстати, не должны показывать где зарыта проблема.
По метрикам можно судить о процессе в целом и в случае чего начать разборки.
Уже по результам разборок выясниться что означает "Девелоперы забыли".
Может быть тестры нашли это, а потом девелоперы просто похерили.
Или какой-то аналитик проигнорировал пожелание заказчика и оно в итоге не попало в SRS.
Вот ты большой босс, отвечающий за качество в не маленькой конторе.
Как ты без обобщенных метрик будет оценивать ситуацию в целом?
Будешь код читать и записи в bugtrack системах просматривать?
MSS>Потому что метрика в виде "размер исходного кода" — вообще говоря, есть маразм в любом ее виде. непонятно, чему разумному может служить эта метрика. Расчету условных показателей в абстрактно-теоретических книжках?
MSS>В современных языках она просто не годится. Зато годится в Фортране и ассемблерах, где строго по одному оператору в строке.
Годится, если существует единый стиль кодирования в команде/конторе.
MSS>Скажите, где, как, когда и чему полезному может служить метрика "размер исходного кода". Буду очень рад. Сам я этого понять не могу.
На мой взгляд прежде всего планированию следующих проектов. См. например COCOMO
MSS>Это что — показатель, который предполагается стимулировать? т.е. стимулировать овердизайн и очень длинные комментарии? или — в случае "строк кода" — стимулировать принцип "новая лексема с новой строки"?
Я вас умоляю. В любой книжке/статье в которой встречается слово "SLOC" встречается также предупреждение о том что не стоит оценивать работу девелоперов по этой метрике.
В общем "учите матчасть" (С) фидо.
начать можно с wiki а дальше по ссылкам и книжкам.
MSS>Ни качество продукта, ни соблюдение сроков не имеют никакого отношения к этой метрике.
см. выше.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Вот смотрите сами:
MSS>if() { MSS> expression MSS>}
MSS>и
MSS>if() MSS>{ MSS> expression MSS>}
MSS>- то же самое, а в одном из примеров на 1 строку кода больше, чем во втором.
Автогенеренные строки, операторные скобки ({, }, BEGIN, END, etc), пустые строки, и комментарии в подсчете LOC не учавствуют. Т.е. у тебя в обоих случаях две строки.
MSS>Покилобайтный счетчик так не обманешь.
Обмануть можно любой счетчик. Твой метод является самым "наивным" из всех возможных и даст очень слабые корелляции c временем и с дефектами. Резльтаты будут нестабильны и будут хуже поддаваться сравнению между людьми/командами/проектами. Да его и "обмануть" проще всего (хотя мотивов обманывать метрику объема у програмиста быть не должно — зачем? ). Проcто для иллюстрации, взгляни:
// I know that results of my job are measured with dumb KB coununter. I'm lucky man!
// First of all, let's generate tonns of comments...
// Blah-blah-blah...
// now let's create...
voif myStupidFunctionWithVeryLongName()
{
CertainlyThisFunctionWillDoMuchMoreJobThanSimilarOneWithShorterName();
AndThusItShouldBeMoreReadable_So();
if( SomeoneTellMeImTryingToFakeTheCounter() )
{
IllHaveAGoodReasonToTellHimToFuckOff();
}//ENDIF (Yes, I'm going to garbage my code with useless comments duplicating language constructs!)
}
Дальше и говорить неохота, ей богу. RTFM software metrics.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>>Измерение размера кода в килобайтах — намного разумнее.
AL>>А почему бы не в сантиметрах: суммарная длина исходников по вертикали на листах, составленных по короткой стороне? Или в граммах: общий вес бумаги после распечатывания всех исходников?
MSS>Потому что метрика в виде "размер исходного кода" — вообще говоря, есть маразм в любом ее виде. непонятно, чему разумному может служить эта метрика. Расчету условных показателей в абстрактно-теоретических книжках?
С этого надо начинать. Весьма опрометчиво называть нечто маразмом, не имея представления о предназначении этой вещи (вы заявляете об этом в соседних предложениях).
MSS>Скажите, где, как, когда и чему полезному может служить метрика "размер исходного кода". Буду очень рад. Сам я этого понять не могу.
Я тоже много чего в этой жизни сам понять не могу. И хочу заметить, что
1) Незнание или не понимание чего-либо — это совсем не повод для пафосных заявлений. Это не является ни редким, ни оригинальным, ни удивительным.
2) Что касательно предназначения метрики размера, то как раз это (к счастью) я и несколько других людей здесь понимают. И это совсем не трудно объяснить. Хотя можно было не разводить флейм, а спросить по-простому, в одном посте: мужики, ну зачем нужны эти долбаные метрики размера, черт бы их побрал так и сяк, ума не приложу, растолкуйте!
MSS>Это что — показатель, который предполагается стимулировать? т.е. стимулировать овердизайн и очень длинные комментарии? или — в случае "строк кода" — стимулировать принцип "новая лексема с новой строки"?
MSS>Ни качество продукта, ни соблюдение сроков не имеют никакого отношения к этой метрике.
Гхм.
Метрика объема ("сложности") — основная метрика, через которую расчитывается большинство производных. Она необходима для приемлемого прогнозирования сроков и качества продукта. Она также необходима для контроля выполнения плана. Все это возможно благодаря некоторым статистическим закономерностям.
1) Метрика "продуктивности" (кол-во строк кода)/час имеет обыкновение быть стабильной для одного разработчика и для одного класса задач.
2) Метрика "плотность дефектов" (кл-во дефектов)/(1000 строк кода) имеет обыкновение быть еще стабильнее, и практически не варьироваться.
Стабильность метрик проверяется наличием корелляции между парами величин (а отнють не гениальными прозрениями, спорами, и давлением на авторитеты). Это обычно удивляет неспециалистов и новичков, но у большинства людей эти корелляции близки к 100% (корелляция 95-98% процентов на тестовой выборке более чем достаточна для прогнозов), что позволяет использовать эти метрики при составлении планов и контроле выполнения этих планов. Методы прогнозирования COCOMO и методологии вроде PSP/TSP тому живой пример.
Кстати, использование объективных метрик для контроля и улучшения процессов разработки является одним из необходимых требований CMM Level 5. Также, по правилам проектных тендеров правительства США, в заявке требуется прогнозировать объем в SLOC.
Вот вы говорили что-то про "серьезный багтрекинг"... Могу я поинтересоваться, ваш "серьезный багтрекинг" позволяет точно прогнозировать количество дефектов в продукте? Позволяет оценивать готовность продукта к выходу, делая прогноз количества оставшихся дефектов по их категориям? Может, у вас мониторится и отслеживается эффективность отдельных процедур тестирования? Нет? Какая досада.
А мы делали — год назад наша компания примерно соответствола CMM 5 (профессионально внедренный PSP/TSP), и мы все это без проблем делали, ага. Компания, где работает bkat, тоже имеет высокий уровень CMM (я точно не знаю, но думаю примерно 3-4), и у них тоже есть опыт работы с метриками. Ну давайте, теперь вы поучите нас жизни, расскажите как надо. Мы послушаем.
B>"Девелоперы забыли" — это кстати серьезный дефект, который не повышает оценку процесса в целом.
Тут под словом "девелоперы" имелась в виду вся компания-исполнитель. Т.е. забыли девелоперы, забыли аналитики, забыли тимлиды и забыли PMы.
Что не забыть многие из этих вещей, достаточно одной напоминалки, и неважно, от какой роли она исходит.
B>Метрики, кстати, не должны показывать где зарыта проблема. B>По метрикам можно судить о процессе в целом и в случае чего начать разборки.
Что значит "судить о процессе в целом"? На уровне "позитив/негатив"?
B>Может быть тестры нашли это, а потом девелоперы просто похерили. B>Или какой-то аналитик проигнорировал пожелание заказчика и оно в итоге не попало в SRS.
А! Вот мы и дошли до сути. Все эти метрики с методологиями должны _пресекать вранье сотрудников своему руководству_!.
Вы думаете, сотрудники этого не ощущают? Ощущают. Подсознательно. А вы думаете, приятно быть на положении человека, которого априори подозревают в гадостях? Компания — это что, зона, где PMы — вертухаи, девелоперы — зэки, а директор — "кум"?
Никому такой оттенок не будет приятен. А "методологии" вызовут именно его.
Кроме того — в маленьких командах такое вообще губительно и не нужно. Только в больших.
И мы снова пришли к моей аналогии с дыхательной машиной для бронтозавра
B>Вот ты большой босс, отвечающий за качество в не маленькой конторе. B>Как ты без обобщенных метрик будет оценивать ситуацию в целом? B>Будешь код читать и записи в bugtrack системах просматривать?
Код читать не буду. Не надо мне это. Возможно, почитаю тот код, который считаю особо важным и ключевым (потому как я профессиональный девелопер и смогу там выступить по делу).
Bugtrack просматривать — обязательно.
Оценивать буду так — "атомом" этой работы является issue. По каждому issue должен быть — статус. Качество работы можно оценить по "сходимости" bugtrack к нулю — т.е. число закрытых issues должно превышать число открываемых.
Время от времени — проверки "налетом" на тему "а какой у нас тут статус прямо сегодня".
Следить надо еще и за приоритетами issues, ну и общение с заказчиком — зачастую приоритеты посередине работ расставляются так, чтобы создать у заказчика стойкую картину "продвижения". Лучше закрыть 2 мелких issue, чем проковыряться неделю с крупным и потом не быть способным отчитаться.
Насчет того "что делать, если исполнители не справляются" — отдельная тема, если надо, и это опишу.
Здравствуйте, Maxim S. Shatskih, Вы писали:
>>проще всего (хотя мотивов обманывать метрику объема у програмиста быть не должно — зачем? ).
MSS>Как зачем? Чтобы получить больше бонусов от руководства за ту же работу. Это естественно.
Естественно? А давайте на секунду допустим, что в руководстве сидят не идиоты, и их волнует соблюдение плана реализации по фичам, т.е. точность прогнозирования и выполнения, а не то, насколько много строк кода приходится на отдельную фичу?
B>А чем тебе не нравится метрика "количество дефектов на 1000 логических строк кода", B>Где дефект — это то, что нашли юзеры после выпуска продукта? B>Вполне неплохая метрика, которая характеризует процесс разработки в целом.
Без разбиения понятия "дефект" на несколько суб-понятий — бессмысленно. Красивый чарт в экселе, можно на стенку повесить и радоваться
Дефекты бывают:
а) недопонимание пожеланий заказчика (или своих маркетологов — внутренние заказчики)
б) забывчивость на тему того, что продукт должен работать "еще и вот в такой среде"
в) баг от того, что "проскочило" внимание — т.е. описка или опечатка.
г) серьезная архитектурная проблема, не учтенная при проектировании
д) "сделано наспех". Как правило, кстати, это сочетается с пунктом "б".
е) мало внимания уделено производительности — т.е. написано как проще, а не как быстрее. Часто есть следствие пункта "д".
Это разные категории дефектов. Там зачастую просто ответственные лица разные.
Так что без такой классификации дефектов — делать нечего.
G>Естественно? А давайте на секунду допустим, что в руководстве сидят не идиоты, и их волнует соблюдение плана реализации по фичам, т.е. точность прогнозирования и выполнения, а не то, насколько много строк кода приходится на отдельную фичу?
Голь на выдумки хитра
Как мне кажется, введение бюрократических методов работы — демотивирует сотрудников. Пропадает "порыв", вместо него идет унылое кропание и ковыряние с ленцой. Начинают работать не "для души" (то, что неплохой софт можно писать "для души" — общеизвестно, берется линукс хотя бы) — а для галочки.
В таких условиях неизбежно появится обман работодателя.
Вот мне кажется именно так.
Закручивание гаек вызывает реакцию выскальзывания вбок. Потом — для борьбы с этой реакцией гайки закручиваются еще, в итоге все становится еще хуже.
Да нет, так можно работать, только производительность в пересчете на одного человека будет много ниже — людей больше, дела столько же. А в некоторых видах бизнеса это обнулит прибыль работодателя
В мелком офшоре так и вовсе — сумма контракта как правило в первом грубом приближении есть человеко-часы * некий среднерыночный коэфиициент. Конечно, строго это мало когда считают, но сумма контракта должна быть где-то вокруг, иначе заказчик "не поймет".
Вот. Попробуйте уговорить заказчика включить труд PMов и прочих тимлидов в эти человеко-часы. Ему это нафиг не надо. Он скорее своего PMа назначит "смотрящим" по проекту. А это офшорке невыгодно, ибо увеличивает гимор (а если этот человек окажется пафосный дурак с претензиями? а позиция к тому располагает — он же не отвечает ни за что, случись проблемы — он тут же переведет стрелки на якобы оболтусную офшорку).
А если заказчика таким образом не уговорили — тогда, простите, но труд PMов и прочих аналитиков придется оплачивать из собственного кармана. Что, конечно же, вызывает мотивацию их посокращать и посовмещать.
Падает ли от этого качество? не-а. Оно от девелоперов зависит в основном. Если девелоперы не бестолочи — то не падает.
Вот со сроками да, иногда тяжко становится. Но что делать — в рамках вашего подхода, может, и ниже риск по срокам, зато процедура стоит априори дороже, и намного. Да и сроки подольше — чего стоят хотя бы peer review дизайн-документов.
Все это, конечно же, при проекте средней и высокой технической сложности (типа прибамбаса к ядру) и с коротким описанием требований (на листочек А4 хватит).
Если проект прост технически (сайт на PHP), но сложен по описанию требований (система продажи абонементов в спорткомплекс) — то тут 1 фулл-тайм "аналитик требований" нужен точно. Обычно заказчик не может систематизировать свои пожелания, он может только сказать "а еще хочу вон тот и вот это", бессистемно и "внавал".
Но при чем тут метрики количества багов и тому подобное?
G>1) Метрика "продуктивности" (кол-во строк кода)/час имеет обыкновение быть стабильной для одного разработчика и для одного класса задач. G>2) Метрика "плотность дефектов" (кл-во дефектов)/(1000 строк кода) имеет обыкновение быть еще стабильнее, и практически не варьироваться.
Есть ли метрика "время отработки одного issue"? Это большая часть работ, особенно перед релизом и в промежутке между версиями, например, 1.0 и 1.1
G>Вот вы говорили что-то про "серьезный багтрекинг"... Могу я поинтересоваться, ваш "серьезный багтрекинг" позволяет точно прогнозировать количество дефектов в продукте? Позволяет оценивать готовность продукта к выходу, делая прогноз количества оставшихся дефектов по их категориям? Может, у вас мониторится и отслеживается эффективность отдельных процедур тестирования? Нет? Какая досада.
Скажите, а откуда истории про крупные (десятки и сотни человек) российские офшорки, которые а) таки срывают сроки и б) таки иногда поставляют заказчику отстой, от которого заказчик плюется (знаю представительницу заказчика)? Вроде и метрики есть, и все равно плохо оно. Какая досада.
Есть подозрение, что, не будь у них такой системы, было бы примерно то же самое по качеству и срокам, но при в пару раз меньшем персонале.
G>А мы делали — год назад наша компания примерно соответствола CMM 5 (профессионально внедренный PSP/TSP), и мы все это без проблем делали, ага. Компания, где работает bkat, тоже имеет высокий уровень CMM (я точно не знаю, но думаю примерно 3-4), и у них тоже есть опыт работы с метриками. Ну давайте, теперь вы поучите нас жизни, расскажите как надо. Мы послушаем.
Немного некорректно, но все же: описание бардака у вашего работодателя в вопросе зарплатной политики у вас в ЖЖ — это как, говорит о чем-то или нет?
Мне — так говорит. Большая структура по определению бестолковая. Начиная с какого-то момента ее руководство вырабатывает подсознательный страх утери контроля за тем, что происходит. И вот тогда начинают выдумываться метрики типа "количество багов на килобайт кода".
Оно, скорее всего, неизбежно. Другое дело, что ИМХО российские компании как правило не доросли до этого критического размера. Внедрение метрик в таком количестве зачастую выполняет единственно роль самоутверждения директора "ах какой я крутой, у меня на фирме даже CMM5".
B>>Может быть тестры нашли это, а потом девелоперы просто похерили. B>>Или какой-то аналитик проигнорировал пожелание заказчика и оно в итоге не попало в SRS.
MSS>А! Вот мы и дошли до сути. Все эти метрики с методологиями должны _пресекать вранье сотрудников своему руководству_!.
Параноя какая-то.
позвольте привести два высказывания:
1. Людям свойственно ошибаться
2. Неудача это не трагедия — это бизнесс-процесс.
Иными словами никто не будет наказывать за то что ты допустил ошибку, наказывают если ошибку допустил сознательно (назло/лень/etc) или не хочешь учиться чтобы ошибок больше не совершать (тобишь делаешь из раза в раз одни и теже ошибки).
Все методики направленные на качество призваны снизить число ошибок и тем самым не допустить недовольства заказчика и в конечном итоге краха фирмы.
MSS>Вы думаете, сотрудники этого не ощущают? Ощущают. Подсознательно. А вы думаете, приятно быть на положении человека, которого априори подозревают в гадостях? Компания — это что, зона, где PMы — вертухаи, девелоперы — зэки, а директор — "кум"? MSS>Никому такой оттенок не будет приятен. А "методологии" вызовут именно его.
Хм, у вас на текущем месте работы все в порядке?
MSS>Кроме того — в маленьких командах такое вообще губительно и не нужно. Только в больших.
Необходимость в применении той или иной методике применяется прежде всего исходя из сложности проекта. Размер команды имхо влияет в меньшей степени.
DAN>Все методики направленные на качество призваны снизить число ошибок и тем самым не допустить недовольства заказчика и в конечном итоге краха фирмы.
Во! Методика — как защита от возможных проблем. Напоминает — ходить по городу в бронежилете — а вдруг террористы пристрелят?
А если заказчик _и так доволен_ — зачем все это нужно?
MSS>>Никому такой оттенок не будет приятен. А "методологии" вызовут именно его. DAN>Хм, у вас на текущем месте работы все в порядке?
Вот в этом вопросе — все.
DAN>Необходимость в применении той или иной методике применяется прежде всего исходя из сложности проекта. Размер команды имхо влияет в меньшей степени.
Сложность разная бывает. Некоторые виды сложности тупо требуют увеличения количества людей, которые не обязаны быть серьезными спецами.
А некоторые — требует именно профессионализма каждого.
Вот во втором случае — а команда мелкого размера при сложных задачах — это именно оно — как раз "методики" вредят. Хотя бы пустой тратой времени на них.
MSS>Как мне кажется, введение бюрократических методов работы — демотивирует сотрудников. Пропадает "порыв", вместо него идет унылое кропание и ковыряние с ленцой. Начинают работать не "для души" (то, что неплохой софт можно писать "для души" — общеизвестно, берется линукс хотя бы) — а для галочки.
В бизнесе лучше надеяться на лучшее, а готовиться к худшему. Это я к тому что лучше планировать на разработчиков работающих с ленцой, чем потерять заказ от того что у разработчика пропал порыв от того что у него с девушкой проблемы или "пропала собака, коли, рыжая, возраст 2 года..." (С) анекдот.
MSS>В таких условиях неизбежно появится обман работодателя.
Не стоит переносить эмоции в отношения с работодателем. Вы заключаете с работодателем контракт. вы выполняете одни условия, он в ответ выполняет другие. Обои вправе следить за тем чтобы контракт исполнялся качественно. Обижаться за это на работодателя.. ну-ну..
MSS>Закручивание гаек вызывает реакцию выскальзывания вбок. Потом — для борьбы с этой реакцией гайки закручиваются еще, в итоге все становится еще хуже.
Попытайтесь понять, использование метрик для работника в конечном итоге оказывается благом хотя бы потому что вместо "эй, вася! ну ка быстро сделай мне программу чтобы все было клево.. где-то тут у меня была бумажка с требованиями.. ага, вот она — вот со второй половины страницы читай, а вверху это у меня список покупок на вечер, потом еще листочек принесешь". сроку тебе до вечера.
Чего, ты говоришь что тут на два месяца работы... а я говорю до вечера, понял! Все... иди работай.
Или, Василий! ты чего, охренел чтоли так мало писать? Ты говоришь что на реализацию эта фича весит 5 тыщ. строк? Да фигня! тут на день работы.. остаешься ты Василий без премии в этом месяце.
Ну и т.п.
MSS>В мелком офшоре так и вовсе — сумма контракта как правило в первом грубом приближении есть человеко-часы * некий среднерыночный коэфиициент. Конечно, строго это мало когда считают, но сумма контракта должна быть где-то вокруг, иначе заказчик "не поймет".
Ну и как вы без метрик сможете подсчитать эти самые человеко-часы?
MSS>Вот. Попробуйте уговорить заказчика включить труд PMов и прочих тимлидов в эти человеко-часы. Ему это нафиг не надо. Он скорее своего PMа назначит "смотрящим" по проекту. А это офшорке невыгодно, ибо увеличивает гимор (а если этот человек окажется пафосный дурак с претензиями? а позиция к тому располагает — он же не отвечает ни за что, случись проблемы — он тут же переведет стрелки на якобы оболтусную офшорку).
И что, неужели еще такие заказчики остались где-то? ну ничего.. рынок таких быстро учит
Хотя, если у вас проект "разработать пасьянс косынку", а вы требуете бизнес-аналитика, аналитика-требований, РМ-а по качеству, SCM инженера, РМ-а, техлида и т.п, то наверное заказчик обидится...
В общем тут все по моему много написали сегодня по этому поводу...
Мне остается только позавидовать вашей организации которая может обходится без метрик, и не позавидовать вашим заказчикам т.к. подозреваю вы часто срываете сроки.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Как мне кажется, введение бюрократических методов работы — демотивирует сотрудников.
Это вопрос грамотности менеджмента, как позиционировать те или иные аспекты процесса разработки.
MSS>Пропадает "порыв", вместо него идет унылое кропание и ковыряние с ленцой.
Элементарный контроль версий в такой логике наверняка будет "демотивировать" разработчика — ну не хочет он этим заниматься, у него "полет мысли", а тут с каким-то контролем версий причепились.... А без этого возможна разработка?
MSS> Начинают работать не "для души" (то, что неплохой софт можно писать "для души" — общеизвестно, берется линукс хотя бы) — а для галочки.
Хмм... Проект Eclipse, как пример открытого ПО (как я понимаю, "для души" это то что Open source? , обладает четко описанным процессом: Eclipse Development Process
см. также документы Eclipse Roadmap
Такая "бюрократизация" останавливает "порыв" или помогает ему, направляя усилия в нужное русло?
Очень рекомендую, например, взглянуть на вот этот фрагмент книги Карла Вигерса (один из гуру управления требованиями) "Software Process Improvement Handbook: A Practical Guide": Why Is Process Improvement So Hard? , в чатсности, см. в этом документе "Challenge #3: Wrong Motivations".
MSS>Во! Методика — как защита от возможных проблем. Напоминает — ходить по городу в бронежилете — а вдруг террористы пристрелят?
Если вы не управляете рисками, риски управляют вами.
MSS>А если заказчик _и так доволен_ — зачем все это нужно?
По моему вас никто не пытается убедить в том что вам нужно использовать метрики/методологии.
Это вы пытаетесь всех убедить что их использовать не нужно.
Я вот к сожалению не могу себе позволить сказать заказчику "продукт будет готов через 6 месяцев и будет стоить ХХХ денег" а в результате сорвать сроки в два раза и в два раза увеличить стоимость и при этом еще половину этого срока заставлять разработчиков работать по вечерам и по субботам.
DAN>>Необходимость в применении той или иной методике применяется прежде всего исходя из сложности проекта. Размер команды имхо влияет в меньшей степени.
MSS>Сложность разная бывает. Некоторые виды сложности тупо требуют увеличения количества людей, которые не обязаны быть серьезными спецами.
В этом случае усложняются коммуникации и объемы которые нужно держать в голове — т.е. тоже увеличивается сложность и необходимо применение методик.
MSS>А некоторые — требует именно профессионализма каждого. MSS>Вот во втором случае — а команда мелкого размера при сложных задачах — это именно оно — как раз "методики" вредят. Хотя бы пустой тратой времени на них.
С дуру и ... сломать можно.
Грамотность команды\РМ-а как раз и определяется правильностью применения методик.
Ну и всегда есть такая вещь как бюджет... если у вас бюджет не ограничен — могу только позавидовать.
DAN>В бизнесе лучше надеяться на лучшее, а готовиться к худшему.
Зачастую у нас слишком ограничены ресурсы для такого. И финансовые, и человеческие, и временные.
Вы играли в старых Варлордов? Помните, что если там посадить по 8 армий в каждом городе для обороны на случай прилета дракона, то безопасность повышается, но upkeep превышает income?
>Это я к тому что лучше планировать на разработчиков работающих с ленцой, чем потерять заказ от того что у разработчика пропал порыв от того что у него с девушкой проблемы или "пропала собака, коли, рыжая, возраст 2 года..." (С) анекдот.
Если человек выбивается из колеи на время большее 2 дней из-за личностных проблем (в т.ч. алкогольных) — то там как правило сильно слабые нервишки, что можно и на собеседовании заметить.
Если речь о ремоутере/домашнем работнике — то ремоутеру это на грани профнепригодности для работы в ремоуте, домашнему же — придется пересаживать в офис. Дело в том, что офисная среда мобилизует сама по себе, и давит на психику в правильную сторону.
MSS>>В таких условиях неизбежно появится обман работодателя. DAN>Не стоит переносить эмоции в отношения с работодателем.
Вы знаете, ну это же наивно. Любые межчеловеческие отношения включают в себя эмоции. В том числе отношения с шефом.
От одних лишь эмоций возникали такие, например, вещи, как сдача коммерческих тайн конкурентам, уход к конкуренту вгрязную, уход в могущественную иностранную компанию и использование позиции там для очернения бывшего работодателя. Все это видел лично. Причем люди были совсем не откровенные "замороченные", которых на собеседовании легко отсечь.
А что — вся PMская наука игнорирует этот фактор? Это что, серьезно?
>это на работодателя.. ну-ну..
Давайте говорить о реальных людях, а не об абстракциях.
DAN>Попытайтесь понять, использование метрик для работника в конечном итоге оказывается благом хотя бы потому что вместо "эй, вася! ну ка быстро сделай мне программу чтобы все было клево.. где-то тут у меня была бумажка с требованиями.. ага, вот она — вот со второй половины страницы читай, а вверху это у меня список покупок на вечер, потом еще листочек принесешь". сроку тебе до вечера. DAN>Чего, ты говоришь что тут на два месяца работы... а я говорю до вечера, понял! Все... иди работай.
Метрики для этого зачем? Банальной диаграммы Гантта хватит.
DAN>Или, Василий! ты чего, охренел чтоли так мало писать? Ты говоришь что на реализацию эта фича весит 5 тыщ. строк? Да фигня! тут на день работы.. остаешься ты Василий без премии в этом месяце. DAN>Ну и т.п.
Смысл так поступать? Лояйльность Василия компании подорвана, продукт лучше не стал. Стоит ли это экономии мелкой денежки на его премии?
MSS>>В мелком офшоре так и вовсе — сумма контракта как правило в первом грубом приближении есть человеко-часы * некий среднерыночный коэфиициент. Конечно, строго это мало когда считают, но сумма контракта должна быть где-то вокруг, иначе заказчик "не поймет". DAN>Ну и как вы без метрик сможете подсчитать эти самые человеко-часы?
А как в микрософте считают? Девелопер дает оценку, ее умножают на эмпирически известный по данному девелоперу коэффициент (девелопер всегда занижает, например, потому, что производительность его труда плавает, а оценка им самим дается в расчете на пиковую производительность, которую не получится удерживать долго).
MSS>>Вот. Попробуйте уговорить заказчика включить труд PMов и прочих тимлидов в эти человеко-часы. Ему это нафиг не надо. Он скорее своего PMа назначит "смотрящим" по проекту. А это офшорке невыгодно, ибо увеличивает гимор (а если этот человек окажется пафосный дурак с претензиями? а позиция к тому располагает — он же не отвечает ни за что, случись проблемы — он тут же переведет стрелки на якобы оболтусную офшорку). DAN>И что, неужели еще такие заказчики остались где-то? ну ничего.. рынок таких быстро учит
Wishful thinking. Дела в реале обстоят далеко не так гламурно, как в литературе.
Зачастую американцы — и не очень мелкие — намного расслабленнее относятся к PM, нежели русские PMы из CMM-сертифицированных компаний. Причем это может быть, например, производитель коробочной софтины, которая продается в Москве почти на каждом лотке. И тому подобное. У американцев меньше пафоса и меньше понятий о солидности, у них скорее "делай-делай-делай-делай-делай".
Практика показывает, что практически никто не будет разрывать сложившееся партнерство ради каких-то мифических шансов на более высокую эффективность где-то у других.
К тому же CMM и прочее не подымает эффективности, оно подымает только уверенность в успехе. Если же речь о сложившемся партнерстве — то она и так есть.
CMM годится как козырь, которым можно размахивать при поиске крупных клиентов "там". А потом бывает, например, так — заказчик заказывает просто услуги девелопмент-центра — т.е. полностью свое руководство, от офшорки только выплата компенсаций/офис/безопасность/HR и подобное обеспечение. И офшоркин CMM идет побоку, руководит напрямую заказчик, ему просто полон офис персонала в аренду сдали.
У Luxoft, например, такие случаи бывали. Люди оттуда говорили, что это у них выгодная и зарекомендовавшая себя бизнес-модель.
DAN>В общем тут все по моему много написали сегодня по этому поводу... DAN>Мне остается только позавидовать вашей организации которая может обходится без метрик, и не позавидовать вашим заказчикам т.к. подозреваю вы часто срываете сроки.
MSS>>Во! Методика — как защита от возможных проблем. Напоминает — ходить по городу в бронежилете — а вдруг террористы пристрелят? DAN>Если вы не управляете рисками, риски управляют вами.
Все зависит от ресурсов, которые можно пустить на "подстраховку" от рисков.
DAN>Я вот к сожалению не могу себе позволить сказать заказчику "продукт будет готов через 6 месяцев и будет стоить ХХХ денег" а в результате сорвать сроки в два раза и в два раза увеличить стоимость и при этом еще половину этого срока заставлять разработчиков работать по вечерам и по субботам.
Стоимость увеличивать не принято (если не было сложных фич-реквестов от заказчика по ходу дела). Так делают только отстойные индусы типа RentaCoder. Это худшее, что можно сделать в адрес заказчика. У него возникнет ощущение, что его просто шантажируют — плати еще, а то мы все провалим.
Сроки — другой разговор, только не в два раза обычно они срываются, совсем нет. Другое дело, что это наказывает компанию по деньгам — за время сорванного срока денег не попросишь (см. выше), а зарплату платить каждый месяц.
Как правило, обыкновенной практики "заклада" хватит на предотвращение этого. Например, заклада вдвое от оценки девелопера — обычно хватает.
О бюджете. Такого рода переразвитые структуры, где вокруг девелоперов бегают специальные люди и считают за ними строки кода , уже сразу заранее и априори требуют большего бюджета.
MSS>Как правило, обыкновенной практики "заклада" хватит на предотвращение этого. Например, заклада вдвое от оценки девелопера — обычно хватает.
никто не спорит, только вот появляется на горизонте какая-нить контора, которая посчитала (и процессы поставленные в ней это могут гарантировать), что для этого проекта можно заложиться не 2, а 1.5 — и все... проект ушел... при том что стоимость разработчиков в обоих компаниях одинаковая.
К счастью это пока скорее редкость, чем правило, особенно на российском рынке, но тенденция таки присутствует...
А вообще дискуссия перестала быть конструктивной. дальше не интересно.
Спасибо за диалог.
MSS>О бюджете. Такого рода переразвитые структуры, где вокруг девелоперов бегают специальные люди и считают за ними строки кода , уже сразу заранее и априори требуют большего бюджета.
Ну мы же вроде бы в ИТ работаем.. автоматизируем так сказать. программа считает однако
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>О бюджете. Такого рода переразвитые структуры, где вокруг девелоперов бегают специальные люди и считают за ними строки кода , уже сразу заранее и априори требуют большего бюджета.
Ну и сколько, по твоим оценкам, требуют такие специальные люди?
Мой опыт, на 100 девелоперов 3-4 человека для этих целей (текучка процесс) хватит.
Причем именно подсчет строчек кода времени отнимать практически не будет.
Это много?
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Немного некорректно, но все же: описание бардака у вашего работодателя в вопросе зарплатной политики у вас в ЖЖ — это как, говорит о чем-то или нет?
Это забавный эпизод периода примерно 2000-2001 года, я, знаете-ли, люблю находить вполне обычные эпизоды в жизни и смотреть на них под необычным углом. Так вот, тогда наша зарплатная политика была такой, что специалисты R&D зарабатывали примерно в 1.5-2 раза выше рынка. Такой вот бардак. А вы, я вижу, склонны делать неожиданные выводы из всего подряд — даже из моего забытого покрытого пылью ЖЖ.
MSS>Мне — так говорит. Большая структура по определению бестолковая. Начиная с какого-то момента ее руководство вырабатывает подсознательный страх утери контроля за тем, что происходит. И вот тогда начинают выдумываться метрики типа "количество багов на килобайт кода".
Да, применение метрик дает контроль над разработкой, обходится практически бесплатно (уходит минимум дополнительных затрат), при этом оправдано и работает даже в маленьких проектах на одного человека. PSP расшифровывается как Personal Software Process, и этот курс берет большинство студентов Carnegie-Mellon SEI.
К сожалению, я полный швах, и по понятной причине курсы Пророчеств и Предсказания Будущего в Школе Волшебства Хогвартса прошли мимо меня, так что другими методами предсказаний сроков проекта я не владею. Приходится, сами понимаете, пользоваться мугловыми методами.
MSS>Оно, скорее всего, неизбежно. Другое дело, что ИМХО российские компании как правило не доросли до этого критического размера. Внедрение метрик в таком количестве зачастую выполняет единственно роль самоутверждения директора "ах какой я крутой, у меня на фирме даже CMM5".
Дайте, штоли, я расскажу, где работаю, чтобы снять ваши вопросы. Я работаю вот здесь: www.cqg.com. Небольшая американская компания, всего человек 500. Производит одноименный продукт для трейдеров — 40% рынка в США, компания успешно работает с 80-х годов. R&D в данный момент примерно 150-200 человек.
У нас года 4-5 назад был профессионально внедрен PSP/TSP (который дает CMM5), с привлечением сертифицированных в Carnegie-Mellon консультантов, плюс несколько наших человек прошли обучение на инструктора PSP/TSP в Cаrnegie-Mellon SEI. Официально мы сертификацию не проходили, и, знаете, мысль о том, что кто-то сможет пройти сертификацию на CMM5 просто для самоутверждения, вызывает у меня улыбку — спроcите у bkat как они получали CMM3.
В Москве контор, которые соответствуют CMM3 — по пальцам перечесть, а насчет СММ5 мы, наверное, единственные, да и то — мы сертификацию не проходили (хоть ключевым требованиям и удовлетворяли), нафиг оно нам не надо. Щас, правда, в наших новых проектах, гайки с PSP/TSP раскрутили, а зря.
Здравствуйте, Maxim S. Shatskih, Вы писали:
B>>А чем тебе не нравится метрика "количество дефектов на 1000 логических строк кода", B>>Где дефект — это то, что нашли юзеры после выпуска продукта? B>>Вполне неплохая метрика, которая характеризует процесс разработки в целом.
MSS>Без разбиения понятия "дефект" на несколько суб-понятий — бессмысленно. Красивый чарт в экселе, можно на стенку повесить и радоваться
MSS>Дефекты бывают: MSS>а) недопонимание пожеланий заказчика (или своих маркетологов — внутренние заказчики) MSS>б) забывчивость на тему того, что продукт должен работать "еще и вот в такой среде" MSS>в) баг от того, что "проскочило" внимание — т.е. описка или опечатка. MSS>г) серьезная архитектурная проблема, не учтенная при проектировании MSS>д) "сделано наспех". Как правило, кстати, это сочетается с пунктом "б". MSS>е) мало внимания уделено производительности — т.е. написано как проще, а не как быстрее. Часто есть следствие пункта "д".
MSS>Так что без такой классификации дефектов — делать нечего.
Знаете, как это делается "по-взрослому"? На самом деле делают двухуровневую классификацию — на первом уровне относят каждый дефект к фазе цикла разработки или виду активности, на которой он был внесен, а на втором уровне характеризуют его природу. Далее прогнозируют внесение и вылавливание дефектов на каждой фазе (чего вы, очевидно, делать не умеете, т.к. признаетесь в незнании применений метрики объема). И отслеживают отдельно по каждому типу. Таким образом очень хорошо видна тенденция к переоценке или недооценке, и эффективность разнообразных процессов и процедур, ориентированных на качество.
Здравствуйте, Maxim S. Shatskih, Вы писали:
СО>>Хмм... Проект Eclipse, как пример открытого ПО (как я понимаю, "для души" это то что
MSS>Это коммерческий продукт крупной компании, розданной в open source.
Many subsystems are waiting too long to merge their changes into the mainline, with the result that they miss many weeks of testing time. Getting those changes in sooner could help testers find some of the bugs which have been slipping through into the stable releases.
The kernel developers are simply not fixing bugs, even after they have been found. According to Andrew, we have to try harder, to be more diligent. "
Другой комментарий (можно на него найти ссылку здесь)
"Linux: 2.6.13-rc4, Improved Development Process
Posted by Jeremy on Friday, July 29, 2005 — 06:03
Back from the 2005 Linux Kernel Developers' Summit, Linus Torvalds released the 2.6.13-rc4 kernel. Linus noted that the improved development processdiscussed at the recent summit will begin after the upcoming release of the 2.6.13 kernel, "which is hopefully not too far away." The general idea of the new process, which improves upon last year's development model [story], is to require that all major merges happen within two weeks of a stable kernel release. All the rest of the time between releases should then be spent on fixing bugs. Linus summarized:
"So if you have a favourite kernel developer, please wake him up with a friendly kick to the head and explain this concept to him in small easy-to-understand words, and tell him that we're in the freeze process for 2.6.13 now, and that he should be gathering up the patches, and make sure they get to me _after_ 2.6.13 is out, but at that point do it in a timely manner."
и снова он:
"Torvalds ... is also proud of the formal tracking process he and Morton established to better manage updates and fixes to the kernel. Still, he keeps a healthy distance from the legal and business issues, says Stuart Cohen, CEO of the OSDL. "
С уважением,
Сергей
P.S. а вот если не брать ядро — может быть текущее состояние соотв. процесса разработки остальной функциональности Linux и является причиной столь часто пересекающихся фич в различных утилитах и модулях? Простой пример — почему настройка работы с раскладкой существует и на уровне XFree и на уровне десктопов? (приводящая в определенных случаях к конфликтам — например между xkb и kbd)
G>В Москве контор, которые соответствуют CMM3 — по пальцам перечесть, а насчет СММ5 мы, наверное, единственные, да и то — мы сертификацию не проходили (хоть ключевым требованиям и удовлетворяли),
CMM and PSP
In the late 1980s and early 1990s the SEI developed the Capability Maturity Model (CMM) which captured organizational best practices for software development. SEI Fellow Watts Humphrey decided to apply the underlying principles of the CMM to the software development practices of a single developer. The result of this effort was the Personal Software Process (PSP), designed to be a CMM level 5 process for individual software developers.
CMM and TSP
It soon became obvious that, while excellent results were possible using the PSP, it was almost impossible to maintain the discipline required for PSP practices if the surrounding environment did not encourage and demand them. Humphrey then developed the Team Software Process (TSP) for the smallest operational unit in most organizations, the project team. TSP was designed to be a CMM level 5 process for project teams. Recent results of using the TSP to achieve world-class quality levels while meeting cost and schedule estimates are documented in an SEI technical report.
Возможно сказался фактор моего первого посещения rsdn.ru 
). Проcто для иллюстрации, взгляни:
