Конченный

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

нормально, когда проект качественный а количество записей в багтрекере со статусом Opened - это специфичная метрика, и метрика эта явно не к тестировщику или разработчику относится, и даже не к понятию качества продукта это просто некоторое число, которое можно пользовать аккуратно для специфичных оценок той или иной метрики проекта (иногда и качества, но в частном случае, а не как правило)

Правильно, главное – качество))))

И что такое по вашему качество?

Копченый

Ясное дело, что пользователю до фени на внутреннюю кухню.

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

ну трекер старый предложил кто-то другой, но вот по числу записей в бэклоге - вообще вопрос начался с того, что тяжело 500-700 записей ревьювать, так вот вполне ок мониторить тысячи записей, как командно, так и лично - главное иметь логику в действиях

к тому, что количество открытых багов ни на что не влияет

И что такое по вашему качество?

Качественный баг уводит систему в аут. Количественные баги – только раздражают )

тем более если это в таких количествах происходит

нормально, когда проект качественный а количество записей в багтрекере со статусом Opened - это специфичная метрика, и метрика эта явно не к тестировщику или разработчику относится, и даже не к понятию качества продукта это просто некоторое число, которое можно пользовать аккуратно для специфичных оценок той или иной метрики проекта (иногда и качества, но в частном случае, а не как правило)

Ненормально этим хвастать. На минутку, именно об этом и была моя запись.

к тому, что количество открытых багов ни на что не влияет

лол) Скажите это своему ПМу )

Ненормально этим хвастать. На минутку, именно об этом и была моя запись.

а где там я хвастал?

коллега, вы прикопались на ровном месте

Качественный баг уводит систему в аут. Количественные баги – только раздражают )

никак нет например, трекать решения "почему не фиксим" лучше по багам и их triage value. также мониторить открытые проблемы по компонентам, по воспроизводимости и по тому, в каких форках присутствуют лучше именно в трекере

а где там я хвастал?

Речь шла про Романа. Коллега, мир не крутится вокруг вас :)

а, пардон

никак нет например, трекать решения "почему не фиксим" лучше по багам и их triage value. также мониторить открытые проблемы по компонентам, по воспроизводимости и по тому, в каких форках присутствуют лучше именно в трекере

Здесь соглашусь.

Речь шла про Романа. Коллега, мир не крутится вокруг вас :)

а где я хвастал? я ответил на эту тему кстати пару постов назад

Хватит писать "коллега" - это ужасно (

а не хотите - 2000 стабильно открытых? )))

Вот :)

Хватит писать "коллега" - это ужасно (

как скажете, коллега

Хватит писать "коллега" - это ужасно (

А в чём дело, коллега?

Вот :)

а в контекст треда в тот момент глянуть? )))

а в контекст треда в тот момент глянуть? )))

в контексте хвастовста я это и воспринял :)

просто вы увели всё к "числу", хотя там как раз был вопрос менеджируемости

и потому псто про менеджируемость приехал аж после срача про хвастовство, но срач был годный и ня ???

лол) Скажите это своему ПМу )

ПМ согласен со мной, и поэтому мы не заводим то, что не предполагается фиксить

Кошмар какой.

риальне ужос

окей

а зачем заводить такие баги?

как раз вот то, что можно пофиксить сразу - можно не заводить, а то, что хз или не будем фиксить сча или вообще - всегда заводить

Типа, быстропофикшенное упавшим не считается?

И как, путаницы нет и говнокода?

ПМ согласен со мной, и поэтому мы не заводим то, что не предполагается фиксить

оригинально. мы всё регистрируем. а дальше пути: 1) фиксим в этой версии 2) фиксим в следующей версии 3) фиксим когда-нибудь (метка - сомнительные хотелки) 4) кроем тикет

а зачем заводить такие баги?

потому что можно иметь статус "но плэн ту фикс", а когда юзеры словят этот баг в продакшене - он сразу станет критичным и придут к тестерам и спросят "а чойто мы такое важное профтыкали?" а вы им "а фиг там - вот ваш десижен и текноут"

ааааааааааааааааааааааааааааааааааа

вот оно что

Типа, быстропофикшенное упавшим не считается?

нет, просто привязки не к багам, а к спекам фичи/стори

причём чобы просто закрыть тикет - лид или ПМ должон прописать почему и т.д.

это зависит от влияния на аудиторию, какой % аудитории затронут багом

то есть зачем заводить баги если фича не девкомплит?

или зачем заводить баги если продукт не пойдёт в продакшен и мы можем фикс внести в продакт дизайн, а не в багобазу?

то есть просто другой тип трекинга

потому что можно иметь статус "но плэн ту фикс", а когда юзеры словят этот баг в продакшене - он сразу станет критичным и придут к тестерам и спросят "а чойто мы такое важное профтыкали?" а вы им "а фиг там - вот ваш десижен и текноут"

Верно.

ессесно если фича сломалась и вылез регрешен, то надо писать тикет - это само собой

Качественный баг уводит систему в аут. Количественные баги – только раздражают )

Тоесть вы считаете, что трекать надо только баги с severity critical или хотя бы major?

но в риалтайм разработке (и пофиг кстати, безо всяких эджайлов это так работало десятки лет назад) вполне можно оттрекать поломки без статичных тикетов

@YAMFP @DJ_ZX у вас не вотерфолл сулчаем?

что такое вотерфолл?

@YAMFP @DJ_ZX у вас не вотерфолл сулчаем?

он самый

что такое вотерфолл?

стена из воды.

вот вот

не вотерволл, а вотерфолл

стена из воды.

аххахахахаха

это когда релизы не х раз в день, а 1 раз в х недель/месяцев

водопад, лол

если совсем грубо

водопады)

как связана частота релизов с процессом?

о_О

а у кого скрам????

это когда релизы не х раз в день, а 1 раз в х недель/месяцев

вы путаете холодное с мягким

а кто видел скрам в книжном виде?

ERROR: S client not available

я вот везде какие-то гибриды скрама с местными суевериями вижу

а кто видел скрам в книжном виде?

что значит в книжном

у меня в каком то виде скрам

у нас классный скрам, мне нравится

ну, в том виде, в котором его на конференциях всякие евангелисты преподают

но в риалтайм разработке (и пофиг кстати, безо всяких эджайлов это так работало десятки лет назад) вполне можно оттрекать поломки без статичных тикетов

плюс если продукт в найтли/дейли сборке падает и причина понятна, то я тоже не сильно вижу обязательности заводить тикет, если дев может захендлить сразу - в коде и чекине коммент "фиксинг крэш в модуле модуль.сипипи" будет достаточен

как связана частота релизов с процессом?

Эммм... Напрямую?...

вроде все по канонам

ага, приходим к мысли, что скрам у каждого свой?

как связана частота релизов с процессом?

да напрямую, если есть возможность быстро зафиксить, мониторить 100500 багов нет необходимости, вылезло-завели-пофиксили-закрыли, на все про все час максимум

тоже не видел книжного скрама, к слову

вы путаете холодное с мягким

двач

ага, приходим к мысли, что скрам у каждого свой?

это же аджайл

конечно все гибко ?

Эммм... Напрямую?...

Все-таки косвенно. Не частота определяет процесс, хотя конечно принимается во внимание.

ну эджайл - это что-то совсем аморфное, очень различное

а вот скрам - он типа имеет классическое определение и классические же правила

Я так по нимаю, что agile - это методология, а скрам, хп, рад и все-такое это фреймворки

?

Все-таки косвенно. Не частота определяет процесс, хотя конечно принимается во внимание.

Если вы релизите, например, приложение в аппстор, то это завязано на двухнедельниые итерации. И хоть ты тресни, но процесс зависит от времени релиза.

Я умоляю, только не надо аджайло и скрамосрачей снова.

с мобильной разработкой согласен, там никуда не денешься

а уже были?

к чему пришли??

там приходится мониторить и только

ага

Если вы релизите в еппсторе медикал, то хоть 2 недели хоть 2 года у вас есть жесткие требования к процессу

Которые регулируются частотой релизов.

Потому что хоть обпредъявляйся с этими требованиями, но несдвигаемый дедлайн - это невдвигаемый дедлайн.

даты релиза зависят от бизнес задач, что не отменяет, что продукт, который релизится раз в 2-3-4-5-6-12 месяцев можно разрабатывать используя аджайловские фреймворки

Да, для того чтобы успевать придётся резать скоуп.

Но это и есть подстраивание процесса под сроки.