Здравствуйте, AStarFinder, Вы писали:
ASF>Привет, ASF>В скором времени потребуется эффективно управлять командой из порядка 20-25 программистов. Что хуже, как минимум две трети из них — очень неопытные.
ASF>Соответственно, хочется иметь инструмент для раннего нахождения проблем. Кроме разного рода административных приемов и процедур, очень пригодились бы автоматические утилиты, регулярно "читающие" код и обращающие внимание на сомнительные в том или ином смысле участки.
ASF>На ваш взгляд, может ли вычисление различных формальных метрик кода (lines of code, cyclomatic complexity, lack of cohesion и тп) стать частью подобного инструментария? Используете ли их вы в своей работе, и какие разновидности? Какие утилиты для их вычисления вы могли бы порекомендовать? Как вы интерпретируете и используете полученные результаты?
На основании этих метрик и прочих сделать качественных выводов относительно работы команд нельзя. А если и сделаешь какие-либо выводы — то будет слишком поздно. Я бы рекомендовал в таких условиях применить процесс, ориентированный на качество, с целью предотвратить ситуацию, которой вы опасаетесь, и получить контроль над ситуацией. В следующем варианте:
1) Делишь разработчиков на "опытных" и "неопытных", опытным даешь статус "старших".
2) Бьешь их на группы по 3 человека, за каждым опытным закрепляешь пару неопытных. Каждая такая группа работает над близкими задачами. "Старший" отвечает также и за качество работы "младших".
3) Введи code inspections. Любой код, который идет в репозиторий, должен просматриваться опытным сотрудником, найденные недочеты должны исправляться. Изменений без такой ревизии быть не должно. Код опытного сотрудника, впрочем, тоже должен просматриваться одним из младших. Право решать, что такое недочет всегда остается за "старшим".
4) То же самое касается design inspections. Тока в них всегда обязан принимать участие как минимум один дополнительный "старший".
5) Размер команд не должен превышать 5-6 человек. Назначь из старших 4-5 тимлидов, будешь дрючить их. Они за работу своих команд отличают головой. У каждого тимлида должен быть в команде еще один "старший".
6) Раз в неделю — статус митинги с тимлидами, с разбором полетов и метрик.
Теперь о метриках. Регулярный еженедельный контроль следующих метрик в сравнении с планом. Обсуждается на статус митингах с тимлидами.
1) Процент фактически закрытых задач против запланированного на каждую неделю. EV Plan и контроль его выполнения.
2) Количество написанного кода в lines of code — сравнение с запланированным.
3) График продуктивности LOC/day на закрытых задачах — сравнение с планом.
Для каждой задачи нужно планировать размер в строках кода. Этого должно быть достаточно.
Re[3]: Использование метрик для идентификации горячих точек
Здравствуйте, AStarFinder, Вы писали:
ASF>Так и сделано.
Отлично.
G>>Теперь о метриках. Регулярный еженедельный контроль следующих метрик в сравнении с планом. Обсуждается на статус митингах с тимлидами. G>>1) Процент фактически закрытых задач против запланированного на каждую неделю. EV Plan и контроль его выполнения. G>>2) Количество написанного кода в lines of code — сравнение с запланированным. G>>3) График продуктивности LOC/day на закрытых задачах — сравнение с планом. G>>Для каждой задачи нужно планировать размер в строках кода. Этого должно быть достаточно.
ASF>Поделитесь опытом: как интерпретировать результаты? Скажем, нормальна ли ситуация, и какие в ней меры применять, если число, в полтора раза меньше запланированного? А если вдвое больше?
Метрика нужна только для сравнения с планом. Процент закрытых задач (график количества от времени с нарастающим итогом) при сравнении с плановым значением этого графика позволяет определять отставание от плана. Отклонение в размере Loc против плана означает недооценку/переоценку сложности, т.е. ошибку планирования. Если будет тенденция к превышению loc по всем задачам, то вам станет понятно, что план нереалистичен, и его надо корректировать. Далее. Колебания продуктивности по каждой команда должны быть в районе 3 сигм от среднего. В противном случае разбирайтесь почему. Низкая продуктивность может например означать только то, что человек привык писать компактный качественный код. Кроме варианта, что люди пинают балду (в этом полагайтесь на мнение тим-лида). Слишком высокая продуктивность — хуже, она может означать, что код низкого качества.
ASF>Понятно, что следует разобраться, с чем связано любое расхождение. Но насколько быстро этот процесс выявляет истинную причину той или иной проблемы?
Не любое. Реагировать на колебания метрик в районе 3-х сигм от средних строго не рекомендуется. Метрика нужна только для сравнения с планом — как грубая агрегатная величина. Найти причину проблемы она не поможет, это уже от вас зависит. Насколько быстро? С частотой статус-митингов , т.е. с недельной задержкой.
ASF>Как предотвратить "работу на метрику", когда человек сознательно пишет побольше LOC, чтобы "обмануть" метрику или совпасть с ней?
Есть только один вариант. Сотрудники должны быть уверены, что метрики используются только для планирования, и ни при каких обстоятельствах не будут использованы для оценки их работы. И это должно быть так на самом деле. В этой связи, вы не должны видеть персональных метрик — только средние значения по командам. От греха подальше. Вам это все равно не нужно — метрики продуктивности loc/hr характеризуют только персональный стиль разработчика, а не его профессионализм. То же относится к объему в loc, который колеблется вдвое у разных людей на одной и той же задаче, и это совершенно нормально. Вам важно не это, а чтобы проект завершился в срок, а если он не укладывается в срок — узнать об этом как можно раньше и скорректировать план/порезать функционал. Все.
Метрика "количество дефектов", находимое тестерами — исключение в том смысле, что вам выгодно, чтобы люди сознательно на нее работали .
Re[4]: Использование метрик для идентификации горячих точек
Здравствуйте, Gaperton, Вы писали:
G>>>Теперь о метриках. Регулярный еженедельный контроль следующих метрик в сравнении с планом. Обсуждается на статус митингах с тимлидами. G>>>1) Процент фактически закрытых задач против запланированного на каждую неделю. EV Plan и контроль его выполнения. G>>>2) Количество написанного кода в lines of code — сравнение с запланированным.
Да, люди планируют количество строк кода, круто процесс поставлен.
G>>>3) График продуктивности LOC/day на закрытых задачах — сравнение с планом. G>>>Для каждой задачи нужно планировать размер в строках кода. Этого должно быть достаточно.
Гы...
G>Не любое. Реагировать на колебания метрик в районе 3-х сигм от средних строго не рекомендуется. Метрика нужна только для сравнения с планом — как грубая агрегатная величина. Найти причину проблемы она не поможет, это уже от вас зависит. Насколько быстро? С частотой статус-митингов , т.е. с недельной задержкой.
А почему не 3,5 например или даже 4х? Это мне сильно напоминает кем то предложенную "объективную систему оценки качества труда разработчика на основе коэфициентов", которые оказались, угадайте с трёх раз, какими, правильно субьективными. У парней здесь этот номер не прошёл, знаете анекдот есть — приезжает еврей в Израиль выходит из самолёта и видит плакат: "Уважаемый, помни, здесь все евреи.".
G>Есть только один вариант. Сотрудники должны быть уверены, что метрики используются только для планирования, и ни при каких обстоятельствах не будут использованы для оценки их работы. И это должно быть так на самом деле. В этой связи, вы не должны видеть персональных метрик — только средние значения по командам. От греха подальше. Вам это все равно не нужно — метрики продуктивности loc/hr характеризуют только персональный стиль разработчика, а не его профессионализм. То же относится к объему в loc, который колеблется вдвое у разных людей на одной и той же задаче, и это совершенно нормально. Вам важно не это, а чтобы проект завершился в срок, а если он не укладывается в срок — узнать об этом как можно раньше и скорректировать план/порезать функционал. Все.
Да, согласен, есть только один вариант — не заниматься ерундой, а управлять через цели, выводы делать по результату работы, согласно графика, делать ревью кода и рефакторинг на что выделять время отдельно, по сути это отдельная задача и есть, т.е. сначала делаем чтоб работало, а потом заботимся о возможности будующих модификаций и расширений кода. Не надо модификаций и расширений — отлично, экономим время. Иначе вырабатываем набор шаблонов проектирования подходящих нам в данной проекте, документируем их и делаем рефакторинг. Хотите всё сразу — не получиться, хоть чем себя в грудь стучите не получиться.
Кроме того, если метрики используются для планирования, то отлично, давайте ребята увеличим себя сроки на проект, зачем нам надрываться? Знаете что из такого "грамотного" менеджмента вырастает — нежелание работать и желание уничтожить стремление к работе в своём ближнем, дабы его энтузиазм не вышел боком для всех остальных. По сути мгновенно разрушается коллектив, что в нашем деле смерти подобно.
Не надо давать людям повод и инструмент для обмана, не надо считать людей дураками, которые не знают как обратить чужие ошибки себе во благо, и на собеседованиях не надо смотреть по очереди в один глаз, а потом в другой, нужно не делать управленческих ошибок и не будет проблем.
Насчёт средних значений — средняя температура по больнице из той же песни, работать нужно с людьми, а не запираться у себя в кабинете и выходить оттуда раз в день с важным видом — расступись, начальник идут!
G>Метрика "количество дефектов", находимое тестерами — исключение в том смысле, что вам выгодно, чтобы люди сознательно на нее работали .
Количество дефектов в коде зависит от многих составляющих и в последнюю очередь от старания разработчика. Так что ни в коем случае нельзя использовать такой инструмент унижения в команде как метрика "количество дефектов" и упаси боже делать по этим цифрам выводы о профессионализме разработчика.
Вообще процесс утранения дефектов, отладки необходимый и неизбежный элемент процесса разработки ПО и относиться к нему нужно соответствующим образом без напряжения, спокойно. Для меня вполне приемлемо если первая версия валиться через каждые 10 минут, гораздо важнее чтобы функционал был готов, и я мог показать его заказчику, а ошибки и вылизывание кода это процесс неизбежный и он начинается ближе к финальной версии продукта, для меня важнее быть уверенным что архитектура приложения разработана правильно и все пожелания заказчика включены в продукт.
The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
Bertrand Russell (c)
Re[5]: Использование метрик для идентификации горячих точек
На счет LOC'ов и метрик, на них основанных советую глянуть
на такую вещь, как COCOMO и производные.
Может тогда ехидства немного поубавится.
Метрики надо считать, если у тебя стоит задача
держать проект под контролем. Тогда ты не справишься только
с помочью совместных чаепитий и беседам по душам.
Другое дело что мерить, как мерить и как это все интерпретировать.
Этому надо учиться.
Насчет дефектов...
Дефект — это вообще говоря баг, который нашелся после того,
как баги закончили искать в специально запланированное на это время.
Скажем месяц кодировали (включая Unit тестирование),
затем еще месяц дружно тестировали, а потом полезли баги,
которые во время тестирования не нашли. Это и есть дефекты.
По крайней мере я привык именно к такой терминологии.
Такое определение мне встречалось часто.
Например тут: http://www.softwaredevelopment.ca/bugs.shtml
Метрика "количество дефектов на единицу кода" очень неплохо
характиризует качество процесса разработки в целом.
Если таких дефектов много, то это не говорит отдельно
о плохом тестировании или проектировании или еще чем-то.
Это говорит о плохом процессе в целом.
Если дефектов, грубо говоря, много то это не является
сигналом для начала разборок с тестерами или кодерами.
Это сигнал для менеджмента начать разбирательства и докопаться до истинных причин.
В общем метрики — это неплохой рычаг управления для менеджмента.
Но ими надо уметь умело пользоваться.
Re[7]: Использование метрик для идентификации горячих точек
Здравствуйте, Муравей, Вы писали:
М>Это я о том, что на мой взгляд не стоит сначала усложнять задачу а потом её героически с использованием самых современных методик решать. Это я о важности правильно спроектированной архитектуры приложения.
Попробуй поищи в интернете статистику основных причин,
почему SW проекты проваливаливаются.
Мне, как девелоперу и "практически архитектору",
конечно же хочется быть в центре и думать, что именно из-за
нас земля крутится или не крутится
Но к сожалению (или наоборот к счатью) — это не так
Re[8]: Использование метрик для идентификации горячих точек
Здравствуйте, bkat, Вы писали:
B>Но еще раз повторюсь, что и как мерить — это очень сложная задача.
Ой, да ладно. Ничего сложного в этом нет. Количество дефектов считается по базе данных. Количество измененных + добавленных строк считается скриптами по чекинам. Время сами понимаете как считается. И все, чего сложного-то. B>Не зря в CMM настоящие измерения появляются только на 4-м уровне.
Там вроде как ключевое — не сами измерения, а мониторинг и улучшение процессов разработки софта на основании объективных метрик. Т. е. речь идет о metrics-driven process.
B>А разработка архитектуры — это конечно же важная, но не единственный вид деятельности. B>И вообще, тестеры с тобой не согласятся, B>что "проектирование это половина а иногда и большая часть работы над проектом". B>Статистика показывает, что проектирование занимает довольно мало времени.
Ну, по данным наших метрик это примерно 25-30% времени Если это будет половина или больше — надо разбираться, что-то в процессе разработки не так.
Re[6]: Использование метрик для идентификации горячих точек
Здравствуйте, Aptekar, Вы писали:
A>Здравствуйте, Муравей, Вы писали:
М>>А почему не 3,5 например или даже 4х?
A>Вы когда-нибудь изучали теорию вероятности?
Я изучал теорию относительности, очень полезная вешь, убавляет темперамент.
The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
Bertrand Russell (c)
Использование метрик для идентификации горячих точек
Привет,
В скором времени потребуется эффективно управлять командой из порядка 20-25 программистов. Что хуже, как минимум две трети из них — очень неопытные.
Соответственно, хочется иметь инструмент для раннего нахождения проблем. Кроме разного рода административных приемов и процедур, очень пригодились бы автоматические утилиты, регулярно "читающие" код и обращающие внимание на сомнительные в том или ином смысле участки.
На ваш взгляд, может ли вычисление различных формальных метрик кода (lines of code, cyclomatic complexity, lack of cohesion и тп) стать частью подобного инструментария? Используете ли их вы в своей работе, и какие разновидности? Какие утилиты для их вычисления вы могли бы порекомендовать? Как вы интерпретируете и используете полученные результаты?
Буду признателен за ответы.
Re[2]: Использование метрик для идентификации горячих точек
Вы писали:
G>На основании этих метрик и прочих сделать качественных выводов относительно работы команд нельзя. А если и сделаешь какие-либо выводы — то будет слишком поздно. Я бы рекомендовал в таких условиях применить процесс, ориентированный на качество, с целью предотвратить ситуацию, которой вы опасаетесь, и получить контроль над ситуацией. В следующем варианте: G>1) Делишь разработчиков на "опытных" и "неопытных", опытным даешь статус "старших". G>2) Бьешь их на группы по 3 человека, за каждым опытным закрепляешь пару неопытных. Каждая такая группа работает над близкими задачами. "Старший" отвечает также и за качество работы "младших".
Так и сделано.
G>3) Введи code inspections. Любой код, который идет в репозиторий, должен просматриваться опытным сотрудником, найденные недочеты должны исправляться. Изменений без такой ревизии быть не должно. Код опытного сотрудника, впрочем, тоже должен просматриваться одним из младших. Право решать, что такое недочет всегда остается за "старшим".
Сейчас так и сделано, но не для "любого" кода, а для такого, который желает проинспектировать "старший". Подумав лучше, прихожу к выводу, что это неверно, Вы правы.
G>4) То же самое касается design inspections. Тока в них всегда обязан принимать участие как минимум один дополнительный "старший".
Так и сделано. Более того, расписано по людям, кого из "старших" надо извещать об изменениях/достижениях/предполагаемых архитектурных решениях по каким областях знания.
G>5) Размер команд не должен превышать 5-6 человек. Назначь из старших 4-5 тимлидов, будешь дрючить их. Они за работу своих команд отличают головой. У каждого тимлида должен быть в команде еще один "старший".
Так и сделано.
G>6) Раз в неделю — статус митинги с тимлидами, с разбором полетов и метрик.
Раньше я думал, что раз в месяц хватает. Видимо, Вы правы.
G>Теперь о метриках. Регулярный еженедельный контроль следующих метрик в сравнении с планом. Обсуждается на статус митингах с тимлидами. G>1) Процент фактически закрытых задач против запланированного на каждую неделю. EV Plan и контроль его выполнения. G>2) Количество написанного кода в lines of code — сравнение с запланированным. G>3) График продуктивности LOC/day на закрытых задачах — сравнение с планом. G>Для каждой задачи нужно планировать размер в строках кода. Этого должно быть достаточно.
Поделитесь опытом: как интерпретировать результаты? Скажем, нормальна ли ситуация, и какие в ней меры применять, если число, в полтора раза меньше запланированного? А если вдвое больше?
Понятно, что следует разобраться, с чем связано любое расхождение. Но насколько быстро этот процесс выявляет истинную причину той или иной проблемы?
Как предотвратить "работу на метрику", когда человек сознательно пишет побольше LOC, чтобы "обмануть" метрику или совпасть с ней?
Re[4]: Использование метрик для идентификации горячих точек
B>В общем метрики — это неплохой рычаг управления для менеджмента.
Всё что угодно но только не рычаг, подчёркиваю не рычаг. Отсчёт да, причём один из многих но не рычаг, поймите разницу.
B>Но ими надо уметь умело пользоваться.
Вот именно.
The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
Bertrand Russell (c)
Re[7]: Использование метрик для идентификации горячих точек
Здравствуйте, Муравей, Вы писали:
М>Здравствуйте, bkat, Вы писали:
B>>В общем метрики — это неплохой рычаг управления для менеджмента.
М>Всё что угодно но только не рычаг, подчёркиваю не рычаг. Отсчёт да, причём один из многих но не рычаг, поймите разницу.
Ладно, не рычаг, но индикатор.
Рычаги без индикаторов — вещь бесполезная.
Re[8]: Использование метрик для идентификации горячих точек
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Муравей, Вы писали:
М>>Здравствуйте, bkat, Вы писали:
B>>>В общем метрики — это неплохой рычаг управления для менеджмента.
М>>Всё что угодно но только не рычаг, подчёркиваю не рычаг. Отсчёт да, причём один из многих но не рычаг, поймите разницу.
B>Ладно, не рычаг, но индикатор.
Да, именно и это очень важно понимать, иначе можно всё испортить.
B>Рычаги без индикаторов — вещь бесполезная.
Вот здесь полностью согласен.
The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
Bertrand Russell (c)
Re[6]: Использование метрик для идентификации горячих точек
Здравствуйте, bkat, Вы писали:
B>На счет LOC'ов и метрик, на них основанных советую глянуть B>на такую вещь, как COCOMO и производные. B>Может тогда ехидства немного поубавится.
А связь то какая?
B>Метрики надо считать, если у тебя стоит задача B>держать проект под контролем. Тогда ты не справишься только B>с помочью совместных чаепитий и беседам по душам.
Проект держат под контролем не отслеживанием абстрактных показателей, а
начиная с планирования проекта, разработки архитектуры решения, которая позволит вести разработку помодульно
и тогда не получиться что по цифрам за 2 месяца до сдачи усё должно сойтись, а потом выясняется что части системы не стыкуются — и всё, аврал в лучшем случае. И вообще проектирование это половина а иногда и большая часть работы над проектом.
B>Другое дело что мерить, как мерить и как это все интерпретировать. B>Этому надо учиться.
Учиться можно и нужно до конца своей жизни, только нужно выбрать верное учение, что не просто.
B>Насчет дефектов... B>Дефект — это вообще говоря баг, который нашелся после того, B>как баги закончили искать в специально запланированное на это время. B>Скажем месяц кодировали (включая Unit тестирование), B>затем еще месяц дружно тестировали, а потом полезли баги, B>которые во время тестирования не нашли. Это и есть дефекты. B>По крайней мере я привык именно к такой терминологии. B>Такое определение мне встречалось часто.
Никто не спорит
B>Например тут: http://www.softwaredevelopment.ca/bugs.shtml B>Метрика "количество дефектов на единицу кода" очень неплохо B>характиризует качество процесса разработки в целом.
Заклинание.
B>Если таких дефектов много, то это не говорит отдельно B>о плохом тестировании или проектировании или еще чем-то. B>Это говорит о плохом процессе в целом.
Остерегитесь обобщать, вообще дело неблагодарное.
B>Если дефектов, грубо говоря, много то это не является B>сигналом для начала разборок с тестерами или кодерами. B>Это сигнал для менеджмента начать разбирательства и докопаться до истинных причин.
а кто спорит?
B>В общем метрики — это неплохой рычаг управления для менеджмента. B>Но ими надо уметь умело пользоваться.
ну, да, уметь пользоваться — именно.
The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
Bertrand Russell (c)
Re[6]: Использование метрик для идентификации горячих точек
Здравствуйте, bkat, Вы писали:
B>На счет LOC'ов и метрик, на них основанных советую глянуть B>на такую вещь, как COCOMO и производные. B>Может тогда ехидства немного поубавится.
B>Метрики надо считать, если у тебя стоит задача B>держать проект под контролем. Тогда ты не справишься только B>с помочью совместных чаепитий и беседам по душам.
Не знаю вспомнил тут выдержку из сочинения одной школьницы — "Когда Мересьев дополз до наших, ему сделали гангрену ног, а потом научили летать на костылях"
Устами младенуа, как говориться...
Это я о том, что на мой взгляд не стоит сначала усложнять задачу а потом её героически с использованием самых современных методик решать. Это я о важности правильно спроектированной архитектуры приложения.
The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
Bertrand Russell (c)
Re[7]: Использование метрик для идентификации горячих точек
Здравствуйте, Муравей, Вы писали:
М>Здравствуйте, bkat, Вы писали:
B>>На счет LOC'ов и метрик, на них основанных советую глянуть B>>на такую вещь, как COCOMO и производные. B>>Может тогда ехидства немного поубавится.
М>А связь то какая?
Твоя ехидная фраза?
Да, люди планируют количество строк кода, круто процесс поставлен.
В COCOMO именно LOC'и являются отправной точкой для оценки сроков и трудозатрат.
Я тебе даже больше скажу.
Бывают что даже планируют и меряют размер экзешника в байтах
Угадай зачем это надо.
Впрочем это точно к COCOMO не относится.
B>>Метрики надо считать, если у тебя стоит задача B>>держать проект под контролем. Тогда ты не справишься только B>>с помочью совместных чаепитий и беседам по душам.
М>Проект держат под контролем не отслеживанием абстрактных показателей, а М>начиная с планирования проекта, разработки архитектуры решения, которая позволит вести разработку помодульно М>и тогда не получиться что по цифрам за 2 месяца до сдачи усё должно сойтись, а потом выясняется что части системы не стыкуются — и всё, аврал в лучшем случае. И вообще проектирование это половина а иногда и большая часть работы над проектом.
Хм, а спецификации то ты и упустил, хотя они все и определяют,
включая и окончательные планы.
Проект держат под контролем именно отслеживаением с последующим реагированием.
Сначала планируют, а затем сравнивают текущее положение с тем,
что записано в планах. Как только есть расхождение,
то надо думать что делать. То ли идти на поклон к заказчику
чтобы он денег больше подкинул и сроки увеличил.
Либо идти с повинной к заказчику и резать фичи.
Чем больше контрольных точек, на которых можно заметить расхождение с планом,
тем лучше контролируется проект. Различные метрики — это один из способов
как можно раньше заметить расхождение с планами.
Но еще раз повторюсь, что и как мерить — это очень сложная задача.
Не зря в CMM настоящие измерения появляются только на 4-м уровне.
По мне лучше вообще ничего не мерить, чем делать это бездумно и через ж...
А разработка архитектуры — это конечно же важная, но не единственный вид деятельности.
И вообще, тестеры с тобой не согласятся,
что "проектирование это половина а иногда и большая часть работы над проектом".
Статистика показывает, что проектирование занимает довольно мало времени.
На согласование и утряску требований уходит не меньше времени.
Re[8]: Использование метрик для идентификации горячих точек
Здравствуйте, bkat, Вы писали:
B>А разработка архитектуры — это конечно же важная, но не единственный вид деятельности. B>И вообще, тестеры с тобой не согласятся, B>что "проектирование это половина а иногда и большая часть работы над проектом". B>Статистика показывает, что проектирование занимает довольно мало времени. B>На согласование и утряску требований уходит не меньше времени.
А это и есть проектирование — улучшение в терминах RUP.
The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
Bertrand Russell (c)
Re[8]: Использование метрик для идентификации горячих точек
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Муравей, Вы писали:
М>>Это я о том, что на мой взгляд не стоит сначала усложнять задачу а потом её героически с использованием самых современных методик решать. Это я о важности правильно спроектированной архитектуры приложения.
B>Попробуй поищи в интернете статистику основных причин, B>почему SW проекты проваливаливаются.
Да знаю я, знаю...
B>Мне, как девелоперу и "практически архитектору", B>конечно же хочется быть в центре и думать, что именно из-за B>нас земля крутится или не крутится B>Но к сожалению (или наоборот к счатью) — это не так
Мне как архитектору это объяснять не надо.
The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
Bertrand Russell (c)
Re[9]: Использование метрик для идентификации горячих точек
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, bkat, Вы писали:
B>>Но еще раз повторюсь, что и как мерить — это очень сложная задача. G>Ой, да ладно. Ничего сложного в этом нет. Количество дефектов считается по базе данных. Количество измененных + добавленных строк считается скриптами по чекинам. Время сами понимаете как считается. И все, чего сложного-то.
Что касается дефектов, то — да.
Но это же не единственное, что можно мерить.
B>>Не зря в CMM настоящие измерения появляются только на 4-м уровне. G>Там вроде как ключевое — не сами измерения, а мониторинг и улучшение процессов разработки софта на основании объективных метрик. Т. е. речь идет о metrics-driven process.
Согласен. Метрики для мониторинга собственно и нужны.
Иначе что с ними делать то?
Но 2-м и 3-м уровнях измерения вроде особо и не требуются.
B>>А разработка архитектуры — это конечно же важная, но не единственный вид деятельности. B>>И вообще, тестеры с тобой не согласятся, B>>что "проектирование это половина а иногда и большая часть работы над проектом". B>>Статистика показывает, что проектирование занимает довольно мало времени. G>Ну, по данным наших метрик это примерно 25-30% времени Если это будет половина или больше — надо разбираться, что-то в процессе разработки не так.
Я тоже примерно такие же числа видел.
Меньше — да, больше — нет.
Re[10]: Использование метрик для идентификации горячих точек
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, bkat, Вы писали:
B>>>Но еще раз повторюсь, что и как мерить — это очень сложная задача. G>>Ой, да ладно. Ничего сложного в этом нет. Количество дефектов считается по базе данных. Количество измененных + добавленных строк считается скриптами по чекинам. Время сами понимаете как считается. И все, чего сложного-то.
B>Что касается дефектов, то — да. B>Но это же не единственное, что можно мерить.
Да в общем, кроме дефектов, размера кода, количества задач и времени ничего больше мерить и не обязательно. Хотя и можно.
Re[5]: Использование метрик для идентификации горячих точек
, т.е. с недельной задержкой.
Если нам не помогут, то мы тоже никого не пощадим.
