How to become an author
Search
Write a publication
Pull to refresh

Comments 43

Зачем же так загонять людей, чтобы у них не было хотя-бы 5-6 часов в неделю на исправление багов хотя-бы в той функциональности, которую они сами породили?
И еще, у вас все на ноутбуках работают? Будет у вас команда сутулых ребят скоро…
Total votes 16: ↑10 and ↓6+4
И еще, у вас все на ноутбуках работают?


Я думаю, это потому, что они не на своих привычных рабочих местах с мониторами. Отцепили буки от них и принесли в переговорку с собой, дело обычное.
Total votes 7: ↑7 and ↓0+7
А когда ноутбук подключается к монитору, в него мы больше не смотрим что-ли?
И чего все минусят? Объясните в чём я не прав…
Total votes 5: ↑1 and ↓4-3
Ноутбук на рабочем месте подключается к монитору (опционально двум) кто-то использует сам ноутбук кто-то нет, дело каждого. Кто не хочет сидеть сгорбившись за ноутбуком вполне может этого не делать.
Total votes 3: ↑3 and ↓0+3
Сейчас существуют doc-станции, в которые можно вставить ноутбук, а потом подключить уже к этой станции мониторы, клавиатуру и мышь. Например, image
This comment wasn’t rated yet0
обычно не смотрят, да, подключают клавиатуру и рабоают как со стационартным
This comment wasn’t rated yet0
Зачем же так загонять людей

К сожалению, на исправление всех багов не хватает времени.


Я думаю, это потому, что они не на своих привычных рабочих местах с мониторами

Да, верно.

Total votes 6: ↑4 and ↓2+2
Но у них не хватает времени потому, что компания не дает им этого времени! Мне кажется, это отжимание сотрудников в чистом виде. Сначала давайте работайте как угорелые, да так чтоб у вас времени не было даже не исправление багов, а потом давайте еще за день исправьте багов сколько сможете и получите мягкую «чтобы это ни было» на ленточке за свои труды. То есть, вместо того, чтобы нанять немного больше людей, которые бы разгрузили разработчиков, лучше устроить им тест-драйв по исправлению дефектов, которые вообще не должны копиться, при чем в таком темпе можно и еще выродить несколько новых.
Но зато вы прекрасно спонсируете иностранных владельцев.
Я не пытаюсь дерзить или хамить, это скорее попытка разобраться чего можно ожидать от работы в такой компании, как Авито.
Total votes 19: ↑17 and ↓2+15
Приведите пример компании в которой нету пары тысяч багов в беклоге ;)
Total votes 4: ↑3 and ↓1+2
В компании, название которой вам все равно ничего не скажет, где я работаю, в QC висит аж 5 багов в трекере, которые ожидают ответа от других команд, бизнес отдела и тп., то есть численность открытых багов и никем не обработанных, стремится к нулю. Я думаю, тут в первую очередь играет роль то, как организован процесс разработки. У нас, как только баг появляется, тот, кто разрабатывал — в течении недели его и правит. Для этого выделяется время специально. А если ты багов не плодишь — пожалуйста, время твоё, иди пей кофе.
Total votes 5: ↑2 and ↓3-1
А если ты багов не плодишь — пожалуйста, время твоё, иди пей кофе.
Как вы сказали, ваша компания называется?
This comment wasn’t rated yet0
Стартап, у которого бэклог ещё не вырос? :))
Total votes 5: ↑5 and ↓0+5
Организация, у которой 16 тыс корпоративных клиентов и 1400 человек в IT отделе. Все у нас выросло, потому и процесс налажен. И еще управленцы хорошие, денег не жалеют на нормальную технику и сотрудников нанимают достаточно, чтобы работники от дедлайнов невыполнимых не страдали.
Total votes 1: ↑1 and ↓0+1
Открытых? И как оно живёт? В системе, которая стоит на многих сотнях рабочих мест у большого количества клиентов открытых тикетов на программиста или тестера с десяток, причём часть из них — «у нас тут идея, но мы не знаем зачем оно нам и что это даст клиенту». Потому КТТС. Или ждут поставки оборудования под задачу. Часть активных с разным приоритетом. Тикеты бывают разные — может быть «поправить сообщение в отчёте», а может быть «реализовать приложенное масштабное ТЗ», которое потом может разделиться на группу тикетов по задачам, а может и нет.
Там тысячи за годы работы, но тысячи открытых — это какой-то сюрр.
Total votes 1: ↑1 and ↓0+1

А вы не пробовали в обязательном порядке добавлять в спринты время на исправление багов?

Total votes 14: ↑13 and ↓1+12
Мне кажется, 3 фидбэка из 4х отвечают на этот вопрос. Всегда есть мелочь, на которую нет времени, но ее хочется поправить.
This comment wasn’t rated yet0
Идея отличная, но не для всех команд применима. Реальность такова, что для многих быстрая доставка важных фич приоритетнее исправления сразу всех багов.
Total votes 1: ↑1 and ↓0+1

В скраме есть одно правило. Обязательно должно выделяться время для улучшения взаимоотношений в команде, условий труда и прочих вещей, призванных сделать разработчиков счастливее. Если баги беспокоят разработчиков, то их можно чинить как раз в это время. Если баги никого не беспокоят, то тогда вообще нет проблемы.

This comment wasn’t rated yet0
Отличная идея! Нужно предложить Баготон руководству — ведь это сразу несколько зайцев убивает: закрывает баги, улучшает качество продукта, мотивирует и сплочает команду, да и вообще весело!
Total votes 8: ↑4 and ↓40
Похоже на субботники в СССР. Некоторым нравится коллективный труд во благо…
А первая фотка ужасна, если честно. Смертная казнь в 21 веке — это варварство, ужасный акт насилия.
Total votes 13: ↑3 and ↓10-7

Чего вы накинулись-то? Команды по исправлению багов работали в РАБОЧИЙ ДЕНЬ!
Т.е. специально выделили один рабочий день на фикс багов. Мне кажется это хороший подход. Когда перманентный цейнтнот в виде "если мы исправим этот баг — нам это не принесёт денег! Забейте!" — то бэклог реально растёт как не знаю кто.
А здесь специально выделяют день на фикс багов. Это конечно не совсем то, чтобы брать в спринт баги, но тоже очень крутая тема. Ну конечно на мой взгляд человека, который устал видеть огромный бэклог на который "у нас нет времени!".

Total votes 11: ↑11 and ↓0+11
Просто смешно, что фикс багов представлен ну прям как «мероприятие», «соревнование» и аж целый ивент. Людям дали 1 раз в чёрт-знает сколько времени не писать быстрый говнокод, а поработать как люди, разгрести проблемы.
Total votes 1: ↑1 and ↓0+1
Как можно пофиксить трудновоспроизводимый баг?
Ну вот правда — его же нужно сперва увидеть?
Вот у меня есть тикет «Device hangs over weekend» — это тестеры оставляют его работать на выходные, приходят, а устройство висит.
Ну сделали они мне этот тикет, а что там на самом деле происходит — да ктож его знает…
Total votes 2: ↑2 and ↓0+2
Дату/время сдвинуть не пробовали?
This comment wasn’t rated yet0
Нет, не пробовал и не буду. Это что-то с железом — там специфичный микрокомпьютер, что-то или с драйверами или с АПИ, которое плохо документированно, но используется методом проб и ошибок.
Total votes 1: ↑0 and ↓1-1
Ставится на пару дней стенд в рабочее время (викенд — два дня), он двое суток пашет, плюёт непонятный лог, но примерно понятно где. Улучшаем логирование (если лог понятен, то это уже не непонятный баг), ставим снова. И так несколько недель (повисание раз в неделю в среднем), находим что ускоряет повисание в процессе и вот виновник найден и исправлен (или сделан обход, если виновник — компонент другого производителя, используемый и без аналогов — потому незаменим). Так тоже получается и в данном случае «багодень» ничего не даст.
This comment wasn’t rated yet0
Ага, только починят самые простые баги. На лицо попытка очень весело задорно со смузи прикрыть проблемы в организации процесса разработки.

И я искренне не понимаю, как можно делать что-то разумное за ноутбуками с такими маленькими экранами.
Total votes 9: ↑4 and ↓5-1

А от чьего лица статья? Почему где-то разработчики это «мы», а в абзаце про подарки это «они»?


Я не придираюсь, просто хочу уточнить

This comment wasn’t rated yet0
Статья от лица организатора, относящегося к команде разработки и тестирования)
Total votes 1: ↑1 and ↓0+1

Люто возопил от одного названия — "багодельня"! Плюсанул уже только за это. А тут и еще сама идея оказалась творческой — ввести соревновательный элемент в достаточно унылый процесс разгрёба багов. ОК, пусть идея не новая, но ругать ссср'овские субботники могут только те, кто ни на каких не был. Там обычно бывает весело ;)

Total votes 5: ↑4 and ↓1+3
В вопросе дебагинга важно не столько время, сколько мотивация.
Если с унылым лицом и мыслями исправлять баг, то на его исправление условно уйдет 1 час. И настроение ниже плинтуса.
А если в азартном соревновательном порыве решать проблему, то уйдет условно 15 минут.
Total votes 2: ↑1 and ↓10
И потом ещё несколько часов на разгребание побочек, которые обязательно проявятся спустя какое-то время, т.к. в соревновательном угаре совершенно забыл о косвенных зависимостях, державшихся на этом баге.
This comment wasn’t rated yet0
Самое интересное — как попытаться донести идею о чем-то подобное в своей компании и встретить одобрение команды? -_-
Total votes 2: ↑1 and ↓10

Какая нибудь третья Пятница Весны, обычный график до обеда. Далее все домой. Ну кроме тех кто замотивирован поскорее подавить клопов ) Вопрос что важнее, чистый код или возможно безлюдный офис.

This comment wasn’t rated yet0
Все зависит от мотивации вашей команды) Попробуйте просто закинуть идею, выслушайте мнения.
This comment wasn’t rated yet0
Если учесть, что мотивация персонала — это искусство… Скорее всего мотивация будет нулевой или отрицательной.
This comment wasn’t rated yet0

Мне интересно где и как они исправляли баги? Ну вот какоц продукт у вас, в котором можно отдельно от других отделов разработки самому что-то исправить?


Всем раздали исходники проекта и они на нем фиксили баги? Мне интересна техническая основа самого багфикса и его проверки.

Total votes 2: ↑2 and ↓0+2
Разработчики исправляют баги в своей платформе и, отправляя исправление на ревью, добавляют тех, кто ответственен за задетый код.
Total votes 1: ↑1 and ↓0+1
А мне больше всего интересно сколько новых багов появляется при таком подходе.
This comment wasn’t rated yet0
В статье есть упоминание про это:
«А теперь ответ на самый каверзный вопрос, который все любят задавать: «А сколько новых багов вы посадили?».
Ответ: не больше 2% от всех обработанных.»
Total votes 1: ↑1 and ↓0+1
Когда наша команда практиковала скрам, мы на ретроспективе договорились что в каждый спринт обязательно втягиваем 3 бага из бэклога + правим асапом все баги, которые делаем во время спринта. В целом идея оказалась удачной но были некотрые особенности:
  • Общее число багов не сильно уменьшалось, т.е отношение прироста багов к их сокращению менялось очень слабо. Почему? Просто находились какие-то новые баги, про которые до этого никто не знал + баги от спринтовых задач, упущенные во время спринта
  • Не всегда ошибка правится быстро, поэтому было введено правило что если какой-то из багов превышает время работы в 1 день, то мы переносим его в тех. работу
  • Также не стоит забывать что баги могут терять свою актуальность со временем, например, кто-то во время рефакторинга мог его случайно пофиксить, поэтому QA должен актуализировать и приоритезировать баги в бэклоге
This comment wasn’t rated yet0
Как вариант можно использовать zero-tolerance политику в отношении багов и чёткое разделение на баги и на фичи (улучшения). В этом случае команда не разрабатывает новый код, пока все баги (может быть за исключением трудновоспроизводимых и Low) не закрыты. Улучшения же идут напрямую в бэклог и там ждут своего часа. (При этом если какой-либо функционал меняется в рамках задачи, то выбираются все фичи связанные с ним и реализуются, если это возможно).
Это конечно замедляет процесс разработки, но зато улучшает качество продукта и повышает удовлетворёность пользователей от продукта.
Total votes 1: ↑1 and ↓0+1
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr