Здравствуйте, playnext, Вы писали:
ГВ>>Неправильно ставишь вопрос. Допустимое количество багов определяется условиями эксплуатации — может быть, проект вообще никто не запускает, а может быть, требуется "пять девяток" и простой не более 16 часов в год. P>Продукт работает круглосуточно и достаточно нагруженно
Ясно. Цену простоя и выявленных ошибок, я так понимаю, не считали. То есть она варьирует в диапазоне от "ужас-ужас-ужас" до "и фиг с ним".
P>>>У нас например при количестве разработчиков 8, багов бывает от 100 до 400 количественно при продолжительности разработки (до сдачи на тестирование) от 1 до 3 месяцев. Используется водопадная модель, code review делается редко, в основном для критичных вещей, покрытие автотестами примерно 10%. ГВ>>Это ни о чём не говорит. Нужно учесть, что за проект, какой объём в строках, как меняется и т.п. P>Проект JEE Web приложение. Посчитал количество строк — 415620. Меняется — 2-3 раза в год выходят релизы.
The book "Code Complete" by Steve McConnell has a brief section about error
expectations. He basically says that the range of possibilities can be as
follows:
(a) Industry Average: "about 15 — 50 errors per 1000 lines of delivered
code." He further says this is usually representative of code that has some
level of structured programming behind it, but probably includes a mix of
coding techniques.
(b) Microsoft Applications: "about 10 — 20 defects per 1000 lines of code
during in-house testing, and 0.5 defect per KLOC (KLOC IS CALLED AS 1000 lines of code) in released
product (Moore 1992)." He attributes this to a combination of code-reading
techniques and independent testing (discussed further in another chapter of
his book).
(c) "Harlan Mills pioneered 'cleanroom development', a technique that has
been able to achieve rates as low as 3 defects per 1000 lines of code during
in-house testing and 0.1 defect per 1000 lines of code in released product
(Cobb and Mills 1990). A few projects — for example, the space-shuttle
software — have achieved a level of 0 defects in 500,000 lines of code using
a system of format development methods, peer reviews, and statistical
testing.
Цитата не из кого-нибудь, а из гуру, МакКоннелла. Обрати внимание, как это написано: это не более, чем сумма "наблюдений за зоопарком" и что (оба-на!) можно некоторыми приёмами достичь во-о-от такен-ных показателей. Можно. То есть — возможно.
Однако, если сравнить ваши показатели с процитированными, то вы просто монстры и сами можете учить кого угодно!
ГВ>>Вообще, попытка найти какой-то абсолютный метрический эталон для такой задачи — занятие бесперспективное. Сосредоточьтесь лучше на поиске причин появления ошибок и методов их исправления. Тогда сразу станет легче выносить оценки и искать способы их повысить. P>Некоторые из причин понятны баги исправляются быстро и к сдаче на Production остаются только минорные. P>Отделу тестирования в частности по времени накладно перепроверять большое количество багов.
Ну, вот это вот — плохо. Я вообще не понимаю апелляций к "накладно по времени" в этом случае. Если есть исправленные ошибки, их надо перепроверять, вне зависимости от накладности по времени. Дальше — или оптимизировать работу, или поднимать цену конечного продукта.
P>Интересна информация сколько багов допускается при сдаче на тестирование (т е кода для которого были сделаны только unit тесты разработчиком)
Ох уж, эта нормальная техническая культура, которая привыкла ждать научно обоснованных нормативов... Расслабьтесь, вы в балагане. Короче, "допуски" были бы возможны, если бы "юнит-тестирование" было каким-то стандартизованным процессом со стандартизованными же входными и выходными характеристиками. Поскольку это не более, чем практический приём (один из), то ни о каких "допускается" или "не допускается" здесь не может идти и речи. Больше того, немедленно посылай далеко и надолго тех, кто попытается приклеить тут какие-нибудь "нормы" имени ведущих собаководов. Ведущие собаководы говорят о таких вещах только в терминах качественных оценок или наблюдений: это ведёт к снижению, а то — тоже к снижению, но меньше первого. Цифры здесь фигурируют только в качестве иллюстраций, для примера посмотри в эту ссылку: http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/ (буквально сегодня я её закинул в соседний топик).
То есть вы можете захотеть чего-то, не сказать странного. Например, что в коде, сданном на финальное тестирование должно быть не более двух ошибок на 10000 LOC при условии 100%-го покрытия этого кода юнит-тестами. Но вам придётся стремиться к достижению этого показателя и никакой "нормой" он от этого не станет: просто вот такие вот, хорошие вы поставили себе вот такую цель и её добились (или нет).
Короче, расскажи лучше, зачем тебе понадобилось искать, что там где "допускается"? Менеджмент укусить нужно, или что?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, playnext, Вы писали:
P>Это делается и ошибки само собой исправляются, после фазы тестирования их нет (могут оставаться минорные но их просто не проверяют чтобы сократить циклы тестирования). Чтобы их вообще не было — сложнее. Это то что требуют от разработчиков перед сдачей на тестирование. И чем выше требования тем больше усилий нужно, поэтому мне нужна была статистика в этой области. Сдавать абсолютно идеальный код перед тестированием очень затратно, тогда зачем тестирование.
Я бы зашёл с другой стороны. Договорись с менеджментом о двух вещах: о чётком критерии для отслеживания "качества" и о периодах, за которые можно сделать вывод о изменении этого самого "качества".
Иначе вы никуда не уйдёте от взаимных разборок и будете тратить время впустую. Если определитесь — дальше всё очевидно.
В качестве критерия может быть что угодно, но как правило речь идёт о количестве ошибок в продукте, которые дошли до пользователей.
Тут сходу всплывают две проблемы: во-первых, релизы происходят нечасто, т.е. период мониторинга получается очень большой, и, соответственно, очень тяжело получить нормальную обратную связь.
Во-вторых, показатель "ошибки у пользователей" комплексный — причина может быть в разработчиках, в ошибках анализа, в QA-отделе (упрощая — в тестерах) и тд и тп. Другими словами, так можно только мониторить общее состояние дел, но не делать какие-либо выводы о реальной причине проблемы.
Решение стандартное: стараемся ускорить обратную связь через уменьшение отслеживаемых периодов и введением промежуточного контроля на отдельных этапах разработки.
Подходов тут много, но единственный более-менее рабочий — микроитерации + понятие shippable product. Остальные неизбежно приводят к гонке за показателями вместо реальной работы.
Так вот, пока вы не перестроите процесс разработки так, чтобы иметь быструю обратную связь — ни о каких стабильных положительных изменениях не может идти и речи. Допустим, последние два релиза прошли успешно.
Ок, как определить, что именно повлияло на успех?
Как гарантировать, что ошибки из прошлых релизов не всплывут снова?
Что делать, если о проблемах станет известно к середине/концу итерации?
Пока вы с менеджментом не задумаетесь над этими вопросами — у вас так и будут "претензии к качеству" с попытками лечения через "а у других ещё хуже"
Неправильно ставишь вопрос. Допустимое количество багов определяется условиями эксплуатации — может быть, проект вообще никто не запускает, а может быть, требуется "пять девяток" и простой не более 16 часов в год.
P>Итересуют разные метрики в том числе абсолютно количество багов на релиз, отношение к общему объему работ, другие зависисмости.
Глянь PDF-ку по ссылке, там есть кое-что полезное. Например, разделение "ошибок" на ошибки-дефекты-сбои.
P>У нас например при количестве разработчиков 8, багов бывает от 100 до 400 количественно при продолжительности разработки (до сдачи на тестирование) от 1 до 3 месяцев. Используется водопадная модель, code review делается редко, в основном для критичных вещей, покрытие автотестами примерно 10%.
Это ни о чём не говорит. Нужно учесть, что за проект, какой объём в строках, как меняется и т.п.
Вообще, попытка найти какой-то абсолютный метрический эталон для такой задачи — занятие бесперспективное. Сосредоточьтесь лучше на поиске причин появления ошибок и методов их исправления. Тогда сразу станет легче выносить оценки и искать способы их повысить.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
P>Хотелось бы оценить качество и эффективность разработки в связи с чем возник вопрос. P>Какое количество багов в среднем бывает (допустимо) на проекте?
Это неправильный вопрос, из разряда "на сколько сантиметров нужно отклонять стрелку тахометра?".
Метрики типа "количество тикетов на релиз"/"тикеточасов на человека" и прочая-прочая — это просто индикаторы, которые с некоторой погрешностью отражают усреднённое положение дел на проекте.
Стремиться привести индикаторы к "норме" это всё равно что "управлять стрелкой бензобака". Эффект может и будет, но слегка не тот, что ожидали.
Единственно правильных подходов нет, всё очень зависит от проекта, стиля разработки и от команды. Как правило, всё сводится к петле "мониторим состояние" — "определяем проблему" — "вносим изменения" — "мониторим состояние"… , дальше — сплошные нюансы вперемешку с баззвордами.
P> Используется водопадная модель
Для классического водопада подобные метрики в принципе бесполезны: слишком длинная петля обратной связи, вы получаете инфу об ошибках не через день максимум, а на этапе тестирования, т.е. в лучшем случае — через несколько недель.
P>Хотелось бы оценить качество и эффективность разработки в связи с чем возник вопрос. P>Какое количество багов в среднем бывает (допустимо) на проекте?
Вот, что нашлось в архивах
Источник: Watts S. Humphrey, The Future of Software Engineering, 2004 by Carnegie Mellon University (в интернетах сходу не нашел)
Здравствуйте, playnext, Вы писали:
ГВ>>То есть хочешь — не хочешь, а вам придётся именно исправлять ошибки и работать над тем, чтобы их не было. Правда, работать придётся обоим сторонам: и менеджменту, и программистам. А статистикой по индустрии можете греть себе душу на митингах. P>Это делается и ошибки само собой исправляются, после фазы тестирования их нет (могут оставаться минорные но их просто не проверяют чтобы сократить циклы тестирования). Чтобы их вообще не было — сложнее. Это то что требуют от разработчиков перед сдачей на тестирование. И чем выше требования тем больше усилий нужно, поэтому мне нужна была статистика в этой области. Сдавать абсолютно идеальный код перед тестированием очень затратно, тогда зачем тестирование.
Погоди, не надо ставить слишком много глобальных вопросов, эдак вы уйдёте в дебри высокой философии, не добившись ничего конкретного. Займитесь прямым решением поставленной задачи: снизить количество ошибок в коде, который вы передаёте на финальное тестирование. Для этого, как это правильно сказал Sinix, вам нужна быстро работающая обратная связь и соответственно, готовность воспринимать эту связь и вносить коррективы в разработку. Что там сделают с отделом тестирования — то не ваше дело. Постарайтесь сделать то, что можете сделать сами на своём участке работы.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, playnext, Вы писали:
P>Какое количество багов в среднем бывает (допустимо) на проекте?
Мне кажется, что это очень индивидуально. Задачи могут быть однотипные и багов в таких задачах допускать нельзя, а могут быть исследовательские — там баги не особо критичны. Количество сильно зависит и от проработанности предыдущих ТЗ, т.к. в случае доработок пользователи могут многое чего багами назвать; качества тестирования — баги могут быть незамечены годами; и т.п.
P>Итересуют разные метрики в том числе абсолютно количество багов на релиз, отношение к общему объему работ, другие зависисмости.
Я знаю, где используют баги/на отработанные часы; баги/на задачи; баги на релиз. Но, любая метрика хороша, когда есть система мотивации. Конкретно у нас не рассматривается пока такая метрика.
Здравствуйте, playnext,
P>Какое количество багов в среднем бывает (допустимо) на проекте?
А баги, знаешь ли, бывают разные. Бывают некритичные, типа "вот эта кнопка нарисована зеленой, а должна быть синей". А бывают — "программа внезапно падает с Access violation, теряются данные за весь день работы."
В самом общем случае, в релиз нельзя выпускать баги уровня blocker или critical. А minimal и trivial могут быть и десятками..... Все зависит от.
Чего именно ты хочешь добиться сбором абсолютного количества багов, или отношения к общему объему работ, или других метрик? Вот от этих целей и надо плясать.
Да всё там не так. Сравнение "яблоко vs квадратный" aka "TSP vs CMMI5", шелковистые волосы один дефект на 17k строк благодаря TSP и прочая сфероконина в вакууме.
Здравствуйте, playnext, Вы писали:
ГВ>>Короче, расскажи лучше, зачем тебе понадобилось искать, что там где "допускается"? Менеджмент укусить нужно, или что? P>Со стороны менеджмента претнзии к качеству продукта. В связи с этим пытаюсь понять где норма.
Понятно. Ну что же, придётся тебя огорчить.
Первое. Никакой "нормы" тут попросту нет. Сумма наблюдений вроде тех, к которым апеллирует МакКоннелл — это продукт баланса и конфликта интересов и способностей программистов, менеджмента и пользователей. От неё бывают отклонения как в одну, так и в другую сторону, при этом всем плевать, как оно происходит у других: если "нас" всё устраивает, остальные идут лесом.
Второе. Если менеджмент не устраивает качество продукта, ты никак не поможешь рассуждениями о том, что где-то код ещё хуже. Это просто нелепица какая-то: отказываться исправлять ошибки и совершенствовать процесс разработки, говоря о среднем показателе по индустрии.
То есть хочешь — не хочешь, а вам придётся именно исправлять ошибки и работать над тем, чтобы их не было. Правда, работать придётся обоим сторонам: и менеджменту, и программистам. А статистикой по индустрии можете греть себе душу на митингах.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Хотелось бы оценить качество и эффективность разработки в связи с чем возник вопрос.
Какое количество багов в среднем бывает (допустимо) на проекте?
Итересуют разные метрики в том числе абсолютно количество багов на релиз, отношение к общему объему работ, другие зависисмости.
У нас например при количестве разработчиков 8, багов бывает от 100 до 400 количественно при продолжительности разработки (до сдачи на тестирование) от 1 до 3 месяцев. Используется водопадная модель, code review делается редко, в основном для критичных вещей, покрытие автотестами примерно 10%.
Здравствуйте, craft-brother, Вы писали:
CB>Источник: Watts S. Humphrey, The Future of Software Engineering, 2004 by Carnegie Mellon University (в интернетах сходу не нашел)
Team Software Process; and TSP are service marks of Carnegie Mellon University.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, craft-brother, Вы писали:
CB>>Источник: Watts S. Humphrey, The Future of Software Engineering, 2004 by Carnegie Mellon University (в интернетах сходу не нашел) S>
S> Team Software Process; and TSP are service marks of Carnegie Mellon University.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, playnext, Вы писали:
P>>Хотелось бы оценить качество и эффективность разработки в связи с чем возник вопрос.
ГВ>Поищи в гугле по ключевым словам "bugs per release". Например: http://www.pearsonhighered.com/samplechapter/0201729156.pdf
P>>Какое количество багов в среднем бывает (допустимо) на проекте?
ГВ>Неправильно ставишь вопрос. Допустимое количество багов определяется условиями эксплуатации — может быть, проект вообще никто не запускает, а может быть, требуется "пять девяток" и простой не более 16 часов в год.
Продукт работает круглосуточно и достаточно нагруженно
P>>Итересуют разные метрики в том числе абсолютно количество багов на релиз, отношение к общему объему работ, другие зависисмости.
ГВ>Глянь PDF-ку по ссылке, там есть кое-что полезное. Например, разделение "ошибок" на ошибки-дефекты-сбои.
P>>У нас например при количестве разработчиков 8, багов бывает от 100 до 400 количественно при продолжительности разработки (до сдачи на тестирование) от 1 до 3 месяцев. Используется водопадная модель, code review делается редко, в основном для критичных вещей, покрытие автотестами примерно 10%.
ГВ>Это ни о чём не говорит. Нужно учесть, что за проект, какой объём в строках, как меняется и т.п.
Проект JEE Web приложение. Посчитал количество строк — 415620. Меняется — 2-3 раза в год выходят релизы. ГВ>Вообще, попытка найти какой-то абсолютный метрический эталон для такой задачи — занятие бесперспективное. Сосредоточьтесь лучше на поиске причин появления ошибок и методов их исправления. Тогда сразу станет легче выносить оценки и искать способы их повысить.
Некоторые из причин понятны баги исправляются быстро и к сдаче на Production остаются только минорные.
Отделу тестирования в частности по времени накладно перепроверять большое количество багов.
Интересна информация сколько багов допускается при сдаче на тестирование (т е кода для которого были сделаны только unit тесты разработчиком)
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, playnext, Вы писали:
ГВ>>>Неправильно ставишь вопрос. Допустимое количество багов определяется условиями эксплуатации — может быть, проект вообще никто не запускает, а может быть, требуется "пять девяток" и простой не более 16 часов в год. P>>Продукт работает круглосуточно и достаточно нагруженно
ГВ>Ясно. Цену простоя и выявленных ошибок, я так понимаю, не считали. То есть она варьирует в диапазоне от "ужас-ужас-ужас" до "и фиг с ним".
P>>>>У нас например при количестве разработчиков 8, багов бывает от 100 до 400 количественно при продолжительности разработки (до сдачи на тестирование) от 1 до 3 месяцев. Используется водопадная модель, code review делается редко, в основном для критичных вещей, покрытие автотестами примерно 10%. ГВ>>>Это ни о чём не говорит. Нужно учесть, что за проект, какой объём в строках, как меняется и т.п. P>>Проект JEE Web приложение. Посчитал количество строк — 415620. Меняется — 2-3 раза в год выходят релизы.
ГВ>Отлично. То есть при 400-х ошибках на 400К строк — это одна ошибка на 1000 строчек. Теперь набираем в гугле "j2ee defects per LOC" и смотрим, например, сюда http://amartester.blogspot.com/2007/04/bugs-per-lines-of-code.html :
ГВ>
The book "Code Complete" by Steve McConnell has a brief section about error
ГВ>expectations. He basically says that the range of possibilities can be as
ГВ>follows:
ГВ>(a) Industry Average: "about 15 — 50 errors per 1000 lines of delivered
ГВ>code." He further says this is usually representative of code that has some
ГВ>level of structured programming behind it, but probably includes a mix of
ГВ>coding techniques.
ГВ>(b) Microsoft Applications: "about 10 — 20 defects per 1000 lines of code
ГВ>during in-house testing, and 0.5 defect per KLOC (KLOC IS CALLED AS 1000 lines of code) in released
ГВ>product (Moore 1992)." He attributes this to a combination of code-reading
ГВ>techniques and independent testing (discussed further in another chapter of
ГВ>his book).
ГВ>(c) "Harlan Mills pioneered 'cleanroom development', a technique that has
ГВ>been able to achieve rates as low as 3 defects per 1000 lines of code during
ГВ>in-house testing and 0.1 defect per 1000 lines of code in released product
ГВ>(Cobb and Mills 1990). A few projects — for example, the space-shuttle
ГВ>software — have achieved a level of 0 defects in 500,000 lines of code using
ГВ>a system of format development methods, peer reviews, and statistical
ГВ>testing.
ГВ>Цитата не из кого-нибудь, а из гуру, МакКоннелла. Обрати внимание, как это написано: это не более, чем сумма "наблюдений за зоопарком" и что (оба-на!) можно некоторыми приёмами достичь во-о-от такен-ных показателей. Можно. То есть — возможно.
ГВ>Однако, если сравнить ваши показатели с процитированными, то вы просто монстры и сами можете учить кого угодно!
ГВ>>>Вообще, попытка найти какой-то абсолютный метрический эталон для такой задачи — занятие бесперспективное. Сосредоточьтесь лучше на поиске причин появления ошибок и методов их исправления. Тогда сразу станет легче выносить оценки и искать способы их повысить. P>>Некоторые из причин понятны баги исправляются быстро и к сдаче на Production остаются только минорные. P>>Отделу тестирования в частности по времени накладно перепроверять большое количество багов.
ГВ>Ну, вот это вот — плохо. Я вообще не понимаю апелляций к "накладно по времени" в этом случае. Если есть исправленные ошибки, их надо перепроверять, вне зависимости от накладности по времени. Дальше — или оптимизировать работу, или поднимать цену конечного продукта.
P>>Интересна информация сколько багов допускается при сдаче на тестирование (т е кода для которого были сделаны только unit тесты разработчиком)
ГВ>Ох уж, эта нормальная техническая культура, которая привыкла ждать научно обоснованных нормативов... Расслабьтесь, вы в балагане. Короче, "допуски" были бы возможны, если бы "юнит-тестирование" было каким-то стандартизованным процессом со стандартизованными же входными и выходными характеристиками. Поскольку это не более, чем практический приём (один из), то ни о каких "допускается" или "не допускается" здесь не может идти и речи. Больше того, немедленно посылай далеко и надолго тех, кто попытается приклеить тут какие-нибудь "нормы" имени ведущих собаководов. Ведущие собаководы говорят о таких вещах только в терминах качественных оценок или наблюдений: это ведёт к снижению, а то — тоже к снижению, но меньше первого. Цифры здесь фигурируют только в качестве иллюстраций, для примера посмотри в эту ссылку: http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/ (буквально сегодня я её закинул в соседний топик).
ГВ>То есть вы можете захотеть чего-то, не сказать странного. Например, что в коде, сданном на финальное тестирование должно быть не более двух ошибок на 10000 LOC при условии 100%-го покрытия этого кода юнит-тестами. Но вам придётся стремиться к достижению этого показателя и никакой "нормой" он от этого не станет: просто вот такие вот, хорошие вы поставили себе вот такую цель и её добились (или нет).
ГВ>Короче, расскажи лучше, зачем тебе понадобилось искать, что там где "допускается"? Менеджмент укусить нужно, или что?
Со стороны менеджмента претнзии к качеству продукта. В связи с этим пытаюсь понять где норма.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, playnext, Вы писали:
ГВ>>>Короче, расскажи лучше, зачем тебе понадобилось искать, что там где "допускается"? Менеджмент укусить нужно, или что? P>>Со стороны менеджмента претнзии к качеству продукта. В связи с этим пытаюсь понять где норма.
ГВ>Понятно. Ну что же, придётся тебя огорчить.
ГВ>Первое. Никакой "нормы" тут попросту нет. Сумма наблюдений вроде тех, к которым апеллирует МакКоннелл — это продукт баланса и конфликта интересов и способностей программистов, менеджмента и пользователей. От неё бывают отклонения как в одну, так и в другую сторону, при этом всем плевать, как оно происходит у других: если "нас" всё устраивает, остальные идут лесом.
ГВ>Второе. Если менеджмент не устраивает качество продукта, ты никак не поможешь рассуждениями о том, что где-то код ещё хуже. Это просто нелепица какая-то: отказываться исправлять ошибки и совершенствовать процесс разработки, говоря о среднем показателе по индустрии.
ГВ>То есть хочешь — не хочешь, а вам придётся именно исправлять ошибки и работать над тем, чтобы их не было. Правда, работать придётся обоим сторонам: и менеджменту, и программистам. А статистикой по индустрии можете греть себе душу на митингах.
Это делается и ошибки само собой исправляются, после фазы тестирования их нет (могут оставаться минорные но их просто не проверяют чтобы сократить циклы тестирования). Чтобы их вообще не было — сложнее. Это то что требуют от разработчиков перед сдачей на тестирование. И чем выше требования тем больше усилий нужно, поэтому мне нужна была статистика в этой области. Сдавать абсолютно идеальный код перед тестированием очень затратно, тогда зачем тестирование.
Здравствуйте, playnext, Вы писали:
P>Хотелось бы оценить качество и эффективность разработки в связи с чем возник вопрос. P>Какое количество багов в среднем бывает (допустимо) на проекте? P>Итересуют разные метрики в том числе абсолютно количество багов на релиз, отношение к общему объему работ, другие зависисмости. P>У нас например при количестве разработчиков 8, багов бывает от 100 до 400 количественно при продолжительности разработки (до сдачи на тестирование) от 1 до 3 месяцев. Используется водопадная модель, code review делается редко, в основном для критичных вещей, покрытие автотестами примерно 10%.
Зачем вам сравнивать свои цифры с какими-то чужими? Ладно если сравнивать похожие проекты, но где их найти?
Поэтому
* Финальную оценку все равно даст продакшен, доволен заказчик или нет. Будет ему (и вам) легче если вы принесете ему цифры что в отрасли и хуже бывает?
* Сравнивать в первую очередь надо с прошлым релизом. Так вы поймете стало лучше или хуже.
* Анализируйте причины изменения метрик (ввели\убрали ревью, увеличили\уменьшили покрытие). От этих цифр и надо будет плясать в разговоре на тему "а че у вас все такое глючное"
P>Хотелось бы оценить качество и эффективность разработки в связи с чем возник вопрос. P>Какое количество багов в среднем бывает (допустимо) на проекте? P>Итересуют разные метрики в том числе абсолютно количество багов на релиз, отношение к общему объему работ, другие зависисмости. P>У нас например при количестве разработчиков 8, багов бывает от 100 до 400 количественно при продолжительности разработки (до сдачи на тестирование) от 1 до 3 месяцев. Используется водопадная модель, code review делается редко, в основном для критичных вещей, покрытие автотестами примерно 10%.
Зависит от размера проекта. Например у меня сейчас серии небольших, которые удается сдавать либо вообще без багов, либо с 1-2 минорами.
На больших проектах — обычно время на багофикс равно 25% от трудозатрат в разработке.
Здравствуйте, playnext, Вы писали:
P>Хотелось бы оценить качество и эффективность разработки в связи с чем возник вопрос. P>Какое количество багов в среднем бывает (допустимо) на проекте?
Качество это соответствие продукта потребностям клиента и оценивать качество нужно именно с этой точки зрения.
Нет абсолютных величин количества дефектов определяющих качественный продукт или нет, так как вы как менеджер не можете менять качество продукта не повлияв на стоимость и сроки.
Если ваш клиент считает, что то количество дефектов, которое он видит его устраивает, за ту цену, которую он тратит на разработку и продукт он получает вовремя, значит продукт качественный. Если не устраивает, значит у вас есть в этой области проблемы.
Если нужны абсолютные цифры — обсудите с клиентом, какие последствия для его бизнеса несут разные классы дефектов в различных частях функционала и зафиксируйте это в SLA.
При фиксации оцените, сколько будет стоить достижение требуемого качества и включите это в стоимость разработки.
P>Хотелось бы оценить качество и эффективность разработки в связи с чем возник вопрос.
Я сейчас крамолу напишу. На эффективность разработки бизнесу насрать. Безнес хочет рост продаж, отсутствие возвратов и положительные отзывы.
Вы вкурсе, что ненужный софт, который не продается, довольно часто может быть очень качественным?
P>У нас например при количестве разработчиков 8, багов бывает от 100 до 400
Я нехочу никого обидеть, но у вас либо мало опыта, либо бесполезная мотивация.
Количество багов не зависит от кол-ва разработчиков. Количество багов зависит от:
— Количества продаж/клиентов
— Количества людей что отвечают клиентам на письма "йо совтфаре дазнт ворк проперли"
Здравствуйте, VladCore, Вы писали:
VC>Здравствуйте, playnext, Вы писали:
P>>Хотелось бы оценить качество и эффективность разработки в связи с чем возник вопрос.
VC>Я сейчас крамолу напишу. На эффективность разработки бизнесу насрать. Безнес хочет рост продаж, отсутствие возвратов и положительные отзывы.
Продукт продается и дает больше всего прибыли по сравнению с остальными продуктами разрабатываемыми в компании. По отзывам я детали не знаю этим поддержка занимается но положительных больше.
Бизнесу в нашем случае интересно сократить кое где бюджет и иметь при этом качество не хуже текущего а в идеале лучше, это естественное желание. Продукт на рынке с 2002 года.
Исходя из пожеланий бизнеса вышестоящий менеджмент пытается улучшить качество и таким образом сократить циклы тестрирования. Это по их мнению позволить сэкономить бюджет.
QA работает исходя из критичности багов и их количества (но не в кеом случает не сложнности и скорости исправления их разработчиком). Чем больше заведено багов тем больше работы у тестеров тем больше ресурсов требуется. Отсюда требования снизить количество багов.
Но по ресурсам и квалификации у разработчиков ничего не меняется. Здесь бюджет остается тот же.
Поэтому предлагается по большей мере изменением процесса и давлением на разработчиков улучшить качество продукта. На рефакторинг времени отдельно не дается. Изменений в коде очень много на релиз и затрагивает почти все области.
VC>Вы вкурсе, что ненужный софт, который не продается, довольно часто может быть очень качественным?
P>>У нас например при количестве разработчиков 8, багов бывает от 100 до 400
У нас примерно также 10 разработчиков багов от 50 до 450 в среднем
VC>Я нехочу никого обидеть, но у вас либо мало опыта, либо бесполезная мотивация.
На счет опыта не знаю. Мотивация не меняется. Есть требование от менеджеров сделать качество продукта лучше. Бюджет как они говорят не позволяет добавлять ресурсы. Они в основном указывают на недостаки процесса в частности. VC>Количество багов не зависит от кол-ва разработчиков. Количество багов зависит от: VC>- Количества продаж/клиентов VC>- Количества людей что отвечают клиентам на письма "йо совтфаре дазнт ворк проперли"
Это как я писал выше не знаю но знаю что количество клиентов растет.
Здравствуйте, playnext,
P> Есть требование от менеджеров сделать качество продукта лучше. Бюджет как они говорят не позволяет добавлять ресурсы.
Менеджеры могут выдать тебе некий цифровой критерий измерения этого самого качества, чтобы ты мог обоснованно утверждать, что "качество стало лучше" или "качество стало хуже"? Нет? Тогда прежде всего договорись с ними о таком измеримом критерии. Обоснуй тем, что "я не могу управлять тем, что я не могу измерить". И зафиксируй этот критерий письменно, в какой-нибудь там внутренней инструкции или регламенте. (А то, знаешь ли, менеджеры любят говорить сегодня одно, а завтра совсем другое. Типа "ты меня не так понял, я имел в виду другое" — в зависимости от того, чего просит очередной жирный клиент.)
Ну и имей в виду, что "качество" не может измениться одномгновенно, по приказу, — сегодня было плохо, а завтра все уже хорошо. Управление качеством — достаточно протяженный во времени процесс. Я бы считал целесообразным трекать изменения "качества" где-то за полгода-год.
Здравствуйте, Вячеслав Бенедичук, Вы писали:
ВБ>Здравствуйте, playnext, Вы писали:
P>>Хотелось бы оценить качество и эффективность разработки в связи с чем возник вопрос. P>>Какое количество багов в среднем бывает (допустимо) на проекте?
ВБ>Качество это соответствие продукта потребностям клиента и оценивать качество нужно именно с этой точки зрения. ВБ>Нет абсолютных величин количества дефектов определяющих качественный продукт или нет, так как вы как менеджер не можете менять качество продукта не повлияв на стоимость и сроки.
Тут предлагается прежде всего улучшить процесс. Есть также претензии что разработчики работают плохо, но я так не думаю. Ни стоимость ни сроки менять нет желания. ВБ>Если ваш клиент считает, что то количество дефектов, которое он видит его устраивает, за ту цену, которую он тратит на разработку и продукт он получает вовремя, значит продукт качественный. Если не устраивает, значит у вас есть в этой области проблемы.
Хотят сделать получше, в целом устраивает. ВБ>Если нужны абсолютные цифры — обсудите с клиентом, какие последствия для его бизнеса несут разные классы дефектов в различных частях функционала и зафиксируйте это в SLA.
Мы обсуждаем с вышестоящим менеджементом а они уже по Бизнесом. ВБ>При фиксации оцените, сколько будет стоить достижение требуемого качества и включите это в стоимость разработки.
У нас бюджет плохо изменяется в строну увеличения. Сроки немного могут но тоже сложно просить.
Анализ у нас есть на кждый релиз.
Здравствуйте, playnext, Вы писали:
P>Исходя из пожеланий бизнеса вышестоящий менеджмент пытается улучшить качество и таким образом сократить циклы тестрирования. Это по их мнению позволить сэкономить бюджет. P>QA работает исходя из критичности багов и их количества (но не в кеом случает не сложнности и скорости исправления их разработчиком). Чем больше заведено багов тем больше работы у тестеров тем больше ресурсов требуется. Отсюда требования снизить количество багов.
Т.е. основная проблема, которая у вас есть это "высокие" трудозатраты или стоимость тестирования?
Если я правильно понял, тогда подумайте над организацией этого процесса. Возможно вам поможет внедрение автоматических тестов например с помощью silenium. Ну и в целом стоит посмотреть на эту часть процесса.
Так же введите разбор дефектов. Дефекты должны классифицироваться, на каком этапе они возникли, что явилось корневой причиной. дальше смотрите, по каким причинам у вас возникло наибольшее число дефектов и работаете с их устранением.
.jpg)
