пятница, 30 декабря 2011 г.

Lesson 58

Друзья, эту уютненькую читают ПМы, тестировщики и программисты?

Как вы считаете, кто должен определять приоритет баг, приоритет работ по исправлению багов?
Проект еще не выдан клиентам. Но вроде уже скоро. Я - не знаю. По ощущениям - что-то не так. Что именно - не могу понять.


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

Ну а кто аргументирует или расскажет, как у них - вообще молодцы.





Слово Канеру:

Ваш багрепорт представляет вас.

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

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

Чтоб получить исправленную ошибку, ты должен убедить группу Контроля Изменений заапрувить работу по исправлению бага или убедить программиста исправить его по собственной инициативе (например поздно ночью, когда группа не работает. Убеждение людей за спиной группы может быть правильным решением в одних компаниях и неправильным в других, это зависит от вашей корпоративной культуры). Багрепорт - главное (часто единственное) средство убеждения людей. Вы можете иметь возможность защитить баг перед группой, но во многих компаниях только тестировщики (с тест-лидом и тест-менеджером обсуждают баги. От того, как хорошо вы защитите багу будет зависеть судьба вашего багрепорта.

34 комментария:

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

    ОтветитьУдалить
  2. у меня муж-разработчик. задала ему твой вопрос, вот его ответ:
    по сути, изначально руководитель проекта должен распределить. если он только продаёт продукт, то лид разрабов должен сказать чо да как, ибо он распределяет работу прогерам. тестеры тут могут только сказать своё веское слово, мол "пока этот баг не поправите, дальше тестить не могем", аналитики тут вроде как и не при чём. они сказали, как оно должно работать и всё. так что, по сути, ответ "Лид разработчиков", учитывая высказывания остальных.
    или даже так: есть руководитель проекта, тот, который отвечает за продукт. он может сообщить лиду разрабов о том, что клиент попалит баг и продукт не продадут/не примут и т.п.
    в конечном итоге, таки лид разрабов и остаётся.
    (за лид разрабов и проголосовали)

    ОтветитьУдалить
  3. Ну конечно чтоб все вместе определяли это очень круто - ровно столько же сколь и невозможно =)
    Сразу же почему то хочется отсечь разработчиков - потому что зачастую(на практике нашего отдела) ошибка как таковая редко портит им жизнь, в том плане что стопорит работу. Они если что во время разработки задачи перефигачат все +)
    Кол-во аналитиков хочется сократить до лида и до ответственного за проект.
    А вот из тестировщиков, как ни странно, хочется оставить либо лида либо "ответственного" за баг - у нас обсуждение достаточно тесное, адские-баги на слуху.

    На текущий момент у нас важность баги определяет тестировщик при заведении, приоритет лид аналитиков, а так же лид разрабов вроде, когда раскидывает баги и задачи по исполнителям. Основной инструмент изменения приоритета баги - убедить аналитиков что все плохо :D

    В итоге на приоритет влияют все "3 силы".

    ОтветитьУдалить
  4. Сомнительный вариант, особенно в случае клиентской разработки - не верится мне, что разработчики достаточно адекватно видят свое детище как "инструмент" которым пользуются =)

    ОтветитьУдалить
  5. муж-разработчик

    мне лично неприятно, еси в моём "детище" баг. особенно, еси это баг, а не nice_to_have. я деньги получаю (ну и себя прогером хорошим считаю) как раз за отсутствие багов и за хорошую продукцию.

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

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

    ОтветитьУдалить
  6. зависит от бага, как ни крути. У нас с этим и тестеры прекрасно справляются. А если спорный вопрос: всё согласно иерархии: тестер-лид тестеров-пиэм. Лид разработчиков, в принципе, может поспорить со всеми =)но на практике острых стычек не было ни разу.

    ОтветитьУдалить
  7. забавный опрос) наверняка каждый гнул свою линию, считая собственную роль более значимой)))

    ОтветитьУдалить
  8. Каждый определяет приоритеты как хочет.

    А решает что исправлять в первую очередь тот, кто отвечает за проект (главное начальство).

    При этом начальство может слушать а может не слушать тех, кто ниже по иерархии.

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


    Ну и вообще чем формальней отношения, тем хуже. Значит что-то не то.

    ОтветитьУдалить
  9. в тестировании 2 месяца. твердо была уверена что я пишу баги, а пм или тл решает что фиксим а что нет. потом возникла проблема - багов много, времени мало. говорю тл - распредели баги по приоритету - тот говорит, это задача тестера (у тл вообще первый проект). я распределила, поставила приоритеты (трекинга нет, все в табличках пока) плюс разделила баги на функциональные и визуальные. день до показа заказчикам - тл говорит - делаем все функциональное только, хотя там была половина не очень значимых багов. в итоге пришел ответ от заказчика с кучей багов которые я, как тестер, определила как важные, а тл опустил их на потом. в итоге в срочном порядке фигачили эти баги.
    мое мнение как должно быть (к критике и советам готова :))- тестер знает что за заказчик, хотя бы примерно, пм может дать такую инофрмацию (заказчику нужно красиво или главное чтоб работало, пм сам показывает функционал заказчику или тому никого не нужно и он сам все детально сидит и проверяет и т.д.). на основании данных о заказчике пм может сделать выводы и сказать их тестеру. тестер глубже всех в проекте, ведь именно он на все кнопочки нажимает и все фишечки знает (мы же все хорошие тестеры :)) после чего тестер определяет приоритеты и отправляет их тл исключительено для согласования и чтобы тот был в курсе и распределил по разработчикам.
    т.е. пм->тестер->тл->разработчики

    что думаете? или это мечты новичка? :)

    ОтветитьУдалить
  10. Все тестеры, лид разработки, ПМ аппрувит + от него мелкие замечания?
    Ок, спасибо.

    ОтветитьУдалить
  11. Ага, вот и я склоняюсь к такому мнению, лид разрабов, ПМ, аналитиков не пускать, а с тестеров оценку.

    А клиентов пока нет, они еще не могут хотеть, спасибо.

    ОтветитьУдалить
  12. Извините, скриню незнакомых, а то боты достали, а комент нечаянно удалил не тот :)

    Хм, интересная, непонятная версия... Вы единственный тестер проекта? И первый? Очень знакомая ситуация просто...

    Появитесь плз еще раз, хочу вас зафрендить

    ОтветитьУдалить
  13. Тут все блин то же самое но наоборот.

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

    ОтветитьУдалить
  14. Дадада.

    Особенно я, хочу чтоб мои баги правили первыми :)))

    ОтветитьУдалить
  15. :) очень удивилась бы, услышав другой комментарий от тестировщика)))

    ОтветитьУдалить
  16. Неее, багов сотни и тфсячи, плясать от каждого - убиццо и не жить.

    Проблематично принимать участие даже лиду тестеров, ибо приоритет бага - порядок и план работ программистов, а они не в подчинении.

    Короче, что то тут не так.

    ОтветитьУдалить
  17. имею ввиду, что каждый одеяло на себя тащит)))

    ОтветитьУдалить
  18. То, что приоритет бага могут менять - это нормально. У нас могут менять все, были бы аргументы.

    Но в работе это делается редко, затевать болтологию из за каждого бага - ересь. Поэтому решает тот, кто определяет приоритет первым.

    Твоя версия - тестер при заведении, так?

    ОтветитьУдалить
  19. Важность - тестер
    Приоритет - аналитик(хотя вернее сказать они у нас ПМы)

    ОтветитьУдалить
  20. Как у нас: на одной работе тестеры, на другой тестеры и ПМ. Правда, и там и там, не очень хорошо вообще развита приоритезация багов. Если "Ааа, все сломалось!", то чего уж тут думать, приоритет выше некуда. Если, какая-нибудь кнопка не ровно отображается, низкий (да и то, если на проекте есть чего делать посерьезнее, иначе нормальный).
    Вообще иногда хочется, чтобы кто-нибудь другой приоритезацией занимался. Потому что вот знаешь, что баг серьезный, но в какой-нибудь гораздо более значительной и используемой функциональности тоже баги есть, возможно, тоже довольно серьезные. А может, мне кажется, что эта функциональность незначительная, может пользователи ей хоть и раз в месяц пользуются, но вот этот раз наступит на следующей неделе точно, а работать оно должно четко и без сбоев. И какой ему приоритет ставить? Мне вот непонятно.
    Аналитиков у нас нет, тест-лидов по сути тоже.
    В идеале, если тестировщик не может явно определить приоритет бага, это должен делать ПМ (мы же рассматриваем идеальных адекватных ПМов, правда?), вероятно совсместно с лидом разработчиков/конкретным разработчиком, который занимается данной функциональностью (потому что он может сказать, как этот конкретный баг и его исправление повлияет на продукт в целом).
    Чего в опросе выбрать при таком раскладе не знаю. От бага зависит. От проекта зависит.

    ОтветитьУдалить
  21. ПМы не идеальные, но хорошие и адекватные, вполне, чо...

    Ну ПМ и лид разрабов норм вариант...

    ОтветитьУдалить
  22. Re: муж-разработчик

    Личная неприязнь вообще не довод и не показатель - не понятно к чему было сказано.

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

    ОтветитьУдалить
  23. Значит повезло с клиентами - ванильные мимимишечки :D

    ОтветитьУдалить
  24. Re: муж-разработчик

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

    в компании где я работал:
    разрабы отвечали за производство и устранение багов. +)
    тестеры отвечали за поиски багов и их передачу разрабам,
    ПМы отвечали за проведение проэкта, передачу нужной информации от клиентов к разрабам и наоборот (вопросы по документации и т.п.).
    аналитики? нет, не слышал.
    в итоге получалось, что тестеры с разрабами проводили проэкт и общались через ПМа с клиентом. в идеальном варианте, ПМ понимал маркетинг и ИТ, что позваляло ему как общаться с клиентом на уровне денег/времени/качества, так и с разрабами по делам багов, фичей, фиксов, в противном случае анализ требований и пожеланий проводился так же разрабами. баги, повторюсь, оставались между тестерами и разрабами.


    (чё-та как-то понаписал...)

    ОтветитьУдалить
  25. ну да, с тестеров оценку, но не решение. в итоге получается, что все лиды. так как оценка должна производиться со всех сторон:
    1) критичность
    2) временные рамки
    3) стоимость
    4) и т.п.

    и, конечно, согласен с retiro каждый на себя одеяло тянет...

    ОтветитьУдалить
  26. Может я не совсем понятно выразилась, но порядок такой: приритет ставит тот, кто открывает баг. Если кого-то он не устраивает, то его можно изменить, КРАТКО обсудив с пиэмом или, если тот почему-то недоступен, с тест-лидом. Как же можно спорить по поводу сотен багов? ;-)

    ОтветитьУдалить
  27. охохо
    не далее как позавчера мне ночальнег дал пиздюлей (ну, образно говоря) за то, что я переложила эту ответственность с себя на пиэма

    ОтветитьУдалить
  28. "муж-разработчик" и "муж - разработчик" - это два разных случая.
    "муж-разработчик" читать забавно:)

    ОтветитьУдалить
  29. согласна, смешно написала :-D

    ОтветитьУдалить
  30. я напрягалась, что комментарием вас обижу, и рада, что этого не произошло:)
    с Новым годом вас!:)

    ОтветитьУдалить
  31. я жыш филолог и сама все понимаю :) поделом мне)
    --
    и вас с наступающим новым годиком :) желаю вам правильных и четких формулировок желаний (потому что все желания всегда сбываются)))

    ОтветитьУдалить
  32. Ну это извечная проблема.

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

    Я в таких случаях просто напоминаю, чем грозят баги функционала.

    То ли Брукс, то ли Макконел писали о том, что проекты, которые инженеры считали успешными и эталонными, менеджеры считают провальными. И наоборот.

    Лично я, как инженер, считаю что прав товарищ Филипп Кроссби в теме "Качество бесплатно". Суть такова, что если (с умом) тратить много денег на доработки и поддержание качества, то эти деньги компенсируются уменьшенной стоимостью дальнейших доработок, хорошей репутацией, мотивацией и тп.

    ОтветитьУдалить
  33. Мое мнение: тестировщик определяет приоритет для дефекта. Если для него этот дефект мешает работе, то ставить выше приоритет. В остальном руководитель проекта.

    ОтветитьУдалить