Встречал ли кто-нибудь клинический случай развала, когда проект находиться в состоянии непрерывного исправления ошибок?
И если да то в какой конторе\проекте?
Здравствуйте, rm822, Вы писали:
R>Встречал ли кто-нибудь клинический случай развала, когда проект находиться в состоянии непрерывного исправления ошибок?
Любой реальный проект, который развивается,
находится в состоянии непрерывного исправления и внесения новых ошибок
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, rm822, Вы писали:
R>>Встречал ли кто-нибудь клинический случай развала, когда проект находиться в состоянии непрерывного исправления ошибок?
B>Любой реальный проект, который развивается, B>находится в состоянии непрерывного исправления и внесения новых ошибок
Вопрос в какой степени
разработка + тестирование \ исправление багов = 70%\30% по моему хорошо
а мне вот всретился 10%\80%,
и даже если разработка не ведется, то соотношение будет 0%\60%
причем он в таком состоянии больше года
Здравствуйте, rm822, Вы писали:
R>Здравствуйте, bkat, Вы писали:
B>>Здравствуйте, rm822, Вы писали:
R>>>Встречал ли кто-нибудь клинический случай развала, когда проект находиться в состоянии непрерывного исправления ошибок?
B>>Любой реальный проект, который развивается, B>>находится в состоянии непрерывного исправления и внесения новых ошибок
R>Вопрос в какой степени R>разработка + тестирование \ исправление багов = 70%\30% по моему хорошо R>а мне вот всретился 10%\80%, R>и даже если разработка не ведется, то соотношение будет 0%\60% R>причем он в таком состоянии больше года
Встречал, ужос нах, сбежал оттудова.
Хорошо когда хоть свои баги фиксаешь, а когда чужие... Вообще такие вещи я теперь стараюсь узнавать на собеседовании, и если ситуация так обстоит, в эту контору ни ногой.
Здравствуйте, captainPower, Вы писали: P>Встречал, ужос нах, сбежал оттудова. P>Хорошо когда хоть свои баги фиксаешь, а когда чужие... Вообще такие вещи я теперь стараюсь узнавать на собеседовании, и если ситуация так обстоит, в эту контору ни ногой.
Баг — это ответственность, которая появляется вследствие чей то безответственности. И логично делать так, что страдать должен этот безотстветственный.
Во
Здравствуйте, captainPower, Вы писали:
P>Здравствуйте, captainPower, Вы писали: P>>Встречал, ужос нах, сбежал оттудова. P>>Хорошо когда хоть свои баги фиксаешь, а когда чужие... Вообще такие вещи я теперь стараюсь узнавать на собеседовании, и если ситуация так обстоит, в эту контору ни ногой. P>Баг — это ответственность, которая появляется вследствие чей то безответственности. И логично делать так, что страдать должен этот безотстветственный.
Баг — это баг.
Не надо его персонифицировать и вызывать страдания у "безотстветственного".
Мне лично, нравится править баги, особенно чужие.
Сразу появляется охотничий азарт.
Правя чужие баги и разбираясь с чужими проблемами получаешь возможность лучше узнать систему.
Это очень полезно.
А вот свои баги находить и править не люблю
Здравствуйте, bkat, Вы писали:
B>Мне лично, нравится править баги, особенно чужие. B>Сразу появляется охотничий азарт. B>Правя чужие баги и разбираясь с чужими проблемами получаешь возможность лучше узнать систему. B>Это очень полезно.
Аналогично
Как я ловила первый баг (тот самый, чужой) это была песня
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, captainPower, Вы писали:
P>>Здравствуйте, captainPower, Вы писали: P>>>Встречал, ужос нах, сбежал оттудова. P>>>Хорошо когда хоть свои баги фиксаешь, а когда чужие... Вообще такие вещи я теперь стараюсь узнавать на собеседовании, и если ситуация так обстоит, в эту контору ни ногой. P>>Баг — это ответственность, которая появляется вследствие чей то безответственности. И логично делать так, что страдать должен этот безотстветственный.
B>Баг — это баг. B>Не надо его персонифицировать и вызывать страдания у "безотстветственного". B>Мне лично, нравится править баги, особенно чужие. B>Сразу появляется охотничий азарт. B>Правя чужие баги и разбираясь с чужими проблемами получаешь возможность лучше узнать систему. B>Это очень полезно. B>А вот свои баги находить и править не люблю
И кстати много ли ты багов то исправил (если это не корпоративная тайна)?
Т.е. таких багов что система падает раз в неделю хз почему?
Или выполняет один из 100 тыс запросов не выполняет?
И происходит это на удаленном 16-ти головом сервере к которому доступа у тебя нет а можно получить только логи, а локальное стресстестирование результатов не дает.
Я понимаю удовольствие от багов когда их МАЛО а когда их дохрена — я согласен с captainPower
Здравствуйте, rm822, Вы писали:
R>Я понимаю удовольствие от багов когда их МАЛО а когда их дохрена — я согласен с captainPower
Что значить "дохрена"?
Вот сейчас глянул, у нас на настоящий момент 161 известных непоправленных багов.
Из них 6 помечены как "критический" и около 40, как "серьезный".
Рядом сидят тестеры и я слышу, что они еще чего-то наковыряли ( спасибо им за это )
Почти все критические баги — это те, про которые нельзя однозначно сказать "виноват Вася".
На баг ставят не виноватого, а того, который предположительно
быстрее всего и качественней решит проблему.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, rm822, Вы писали:
R>>Я понимаю удовольствие от багов когда их МАЛО а когда их дохрена — я согласен с captainPower
B>Что значить "дохрена"? B>Вот сейчас глянул, у нас на настоящий момент 161 известных непоправленных багов. B>Из них 6 помечены как "критический" и около 40, как "серьезный". B>Рядом сидят тестеры и я слышу, что они еще чего-то наковыряли ( спасибо им за это ) B>Почти все критические баги — это те, про которые нельзя однозначно сказать "виноват Вася". B>На баг ставят не виноватого, а того, который предположительно B>быстрее всего и качественней решит проблему.
Ты баги в пользовательском интерфейса когда нибудь фиксил? )
Или баги в клиент серверном приложении работающим с БД?
А если их количество идет на сотни?
Там обычно нет ничего нового и интересного, ошибки возникают либо из-за плохого анализа либо из-за невнимательности программиста.
Здравствуйте, rm822, Вы писали:
R>И кстати много ли ты багов то исправил (если это не корпоративная тайна)? R>Т.е. таких багов что система падает раз в неделю хз почему? R>Или выполняет один из 100 тыс запросов не выполняет? R>И происходит это на удаленном 16-ти головом сервере к которому доступа у тебя нет а можно получить только логи, а локальное стресстестирование результатов не дает.
Ну я не bkat, но мне регулярно приходится с такими багами иметь дело. По мне так лучше бы такого не было.
Давеча вот был инцидент, когда Windows file servers в одном очень большом американском банке стали падать из-за update нашего продукта. И все что было доступно — пара memory dumps.
Это вопрос популярности софта, который фирма продает.
R>Я понимаю удовольствие от багов когда их МАЛО а когда их дохрена — я согласен с captainPower
В любом software проекте наступает фаза feature complete — когда желаемая функциональность достигнута и работа идет над stability — bug fixing.
И багов много и только и делаешь что исправляешь.
Здравствуйте, captainPower, Вы писали:
P>Там обычно нет ничего нового и интересного, ошибки возникают либо из-за плохого анализа либо из-за невнимательности программиста.
А это почти всегда так.
Обычно баг действительно правится за минуту изменением пары строчек.
В этом действительно ничего интересного нету.
Интересен как раз поиск причины и места, где проблема на самом деле зарыта.
Рутинных багов тоже хватает, но их правишь просто по ходу дела.
Это часть работы.
Здравствуйте, captainPower, Вы писали: P>Ты баги в пользовательском интерфейса когда нибудь фиксил? ) P>Или баги в клиент серверном приложении работающим с БД? P>А если их количество идет на сотни? P>Там обычно нет ничего нового и интересного, ошибки возникают либо из-за плохого анализа либо из-за невнимательности программиста.
Я год проработал в product support dev team — занимался поддержкой проектов, разрабатывавшихся для разных клиентов на базе единого кода.
3-tier приложение с БД, серверами приложений и Web UI. Много дефектов.
Через три месяца исправления дефектов в разных модулях получил возможность разговаривать с архитекторами и бизнес аналитиками на равных.
Учитесь видеть положительные стороны в исправлении дефектов.
Хотя, если в проекте Find vs. Fixed ratio не падает долгое время, возникает вопрос о судьбе проекта.
Здравствуйте, AIDS, Вы писали:
AID>В любом software проекте наступает фаза feature complete — когда желаемая функциональность достигнута и работа идет над stability — bug fixing. AID>И багов много и только и делаешь что исправляешь.
Ну наступает, и что? Программеры всегда будут писать с багами, аналитики никогда не научатся писать без ошибок, заказчик всегда будет менять требования.
Приемлемый уровень качества- когда на багфиксинг уходит не более 30% от времени разработки, как пишет автор темы, эту цифру я и раньше слышал. Когда на багфиксинг уходит 80% времени я считаю это ненормально. Кто-то обсдался. Как минимум начальство. Уверен, что оно попытается крайними в данной ситуации сделать программистов.
Здравствуйте, captainPower, Вы писали:
P>Здравствуйте, AIDS, Вы писали: P>Ну наступает, и что? Программеры всегда будут писать с багами, аналитики никогда не научатся писать без ошибок, заказчик всегда будет менять требования. P>Приемлемый уровень качества- когда на багфиксинг уходит не более 30% от времени разработки, как пишет автор темы, эту цифру я и раньше слышал. Когда на багфиксинг уходит 80% времени я считаю это ненормально. Кто-то обсдался. Как минимум начальство. Уверен, что оно попытается крайними в данной ситуации сделать программистов.
Хорошо будет если не заставят на выходных работать. А то ведь могут. Митинги о том что все хреново еще не начались? )
Здравствуйте, captainPower, Вы писали:
P>Здравствуйте, captainPower, Вы писали:
P>>Здравствуйте, AIDS, Вы писали: P>>Ну наступает, и что? Программеры всегда будут писать с багами, аналитики никогда не научатся писать без ошибок, заказчик всегда будет менять требования. P>>Приемлемый уровень качества- когда на багфиксинг уходит не более 30% от времени разработки, как пишет автор темы, эту цифру я и раньше слышал. Когда на багфиксинг уходит 80% времени я считаю это ненормально. Кто-то обсдался. Как минимум начальство. Уверен, что оно попытается крайними в данной ситуации сделать программистов.
P>Хорошо будет если не заставят на выходных работать. А то ведь могут. Митинги о том что все хреново еще не начались? )
такие митинги периодически бывают, но к ним по ходу все привыкли
когда устраивался спросил что со сверхурочными — ответ был что хрен, ну я сразу сказал что сверхурочно работать не бесплатно буду, а насчет за деньги зависит от обстоятельств. Хотя некоторые ходят в выходные....
PS: мне уже без разницы — все равно я увольняюсь %)
P>Баг — это ответственность, которая появляется вследствие чей то безответственности. И логично делать так, что страдать должен этот безотстветственный.
Это всё верно. Но на практике бывает так что приходится исправлять баги тех, кто давно уже уволился/был уволен.
Удвой число ошибок, если не получается добиться цели.
P>Ты баги в пользовательском интерфейса когда нибудь фиксил? ) P>Или баги в клиент серверном приложении работающим с БД? P>А если их количество идет на сотни? P>Там обычно нет ничего нового и интересного, ошибки возникают либо из-за плохого анализа либо из-за невнимательности программиста.
Бывает и хуже — когда баги появляются от того что были исправлены другие баги, но неправильно. А тот, кто исправлял, скажем не знал основ ООП.
Удвой число ошибок, если не получается добиться цели.
Здравствуйте, rm822, Вы писали:
R>Здравствуйте, bkat, Вы писали:
B>>Здравствуйте, rm822, Вы писали:
R>>>Встречал ли кто-нибудь клинический случай развала, когда проект находиться в состоянии непрерывного исправления ошибок?
B>>Любой реальный проект, который развивается, B>>находится в состоянии непрерывного исправления и внесения новых ошибок
R>Вопрос в какой степени R>разработка + тестирование \ исправление багов = 70%\30% по моему хорошо R>а мне вот всретился 10%\80%, R>и даже если разработка не ведется, то соотношение будет 0%\60% R>причем он в таком состоянии больше года
Что за проект? Может чувакам нужен правильный человек для выхода из этого кризиса?
Можно обсудить.
Здравствуйте, captainPower, Вы писали:
P>Здравствуйте, AIDS, Вы писали:
AID>>В любом software проекте наступает фаза feature complete — когда желаемая функциональность достигнута и работа идет над stability — bug fixing. AID>>И багов много и только и делаешь что исправляешь. P>Ну наступает, и что? Программеры всегда будут писать с багами, аналитики никогда не научатся писать без ошибок, заказчик всегда будет менять требования. P>Приемлемый уровень качества- когда на багфиксинг уходит не более 30% от времени разработки, как пишет автор темы, эту цифру я и раньше слышал. Когда на багфиксинг уходит 80% времени я считаю это ненормально. Кто-то обсдался. Как минимум начальство. Уверен, что оно попытается крайними в данной ситуации сделать программистов.
Мы используем две метрики для оценки готовности к релизу:
— Find vs. Fixed ratio — когда QA находят меньше дефектов, чем мы исправляем, т.е качество продукта улучшается.
— New defects arrival rate — т.е какое количество новых дефектов находят QA.
В общем когда они меньше определенного порога, продукт готов к выпуску.
(Разумеется когда другие критерии удовлетворены).
10 месяцев назад мы перенесли дату релиза из-за того что New defects arrival rate не падал, т.е. мы не были уверены в качестве продукта.
При этом последний месяц, два мы только и занимались bug-fixing'ом.
