Девелоперы vs тестеры
Artjom Serdyuk
Девелоперы взяли за привычку обвинять тестеров в плохой работе. При
этом объективных критериев "хорошести" работы тестеров нету, всё чисто
субъективно: пропустили какой-то баг, ушли точно вовремя, не показали
достаточной преданности делу команды и т.п.
Сталкивался ли кто-то с такой ситуацией? Как вы с этим боролись и
насколько успешно?
Anton Maryukhnenko
--
Sincerely,
Anton Maryukhnenko
Yaroslav Gnatyuk
драка, или они помирятся.
Проблема не в измерении производительности тестеров, а в переходе на личности.
Тестеры все время указывают девелоперам на их ошибки, ничего не
поделаешь, для этого они и нужны.
Важно чтобы все это понимали и не обвиняли друг друга, а наоборот,
помогали все исправить.
2009/1/28 Anton Maryukhnenko <maryuk...@gmail.com>:
Иван Мосев
свидетельствует в первую очередь о том что у вас есть переработка,
причины её могут быть разные.
В этом случае причина ИМХО в том, что команда работает по методологии
NMP (Not My Problem).
28 января 2009 г. 13:39 пользователь Artjom Serdyuk
<artem....@gmail.com> написал:
--
__
Best regards
Ivan Mosev aka Verber
ver...@rambler.ru
i.k....@gmail.com
Artjom Serdyuk
У нас у большинства народа гибкий график, и многие задерживаются
позже по своей воле или потому что пришли позже (а не потому, что
дедлайны горят).
Скорее тут случай, когда "я колбасил до семи, а тестеры ушли в
17-00... вот нехорошие люди".
On Jan 28, 2:17 pm, Иван Мосев <i.k.mo...@gmail.com> wrote:
> Извиняюсь, что не по теме, но, наличие "проблемы" "ушли точно вовремя"
> свидетельствует в первую очередь о том что у вас есть переработка,
> причины её могут быть разные.
> В этом случае причина ИМХО в том, что команда работает по методологии
> NMP (Not My Problem).
>
> 28 января 2009 г. 13:39 пользователь Artjom Serdyuk
> <artem.serd...@gmail.com> написал:
>
> > Столкнулись на ретроспективах с такой проблемой:
> > Девелоперы взяли за привычку обвинять тестеров в плохой работе. При
> > этом объективных критериев "хорошести" работы тестеров нету, всё чисто
> > субъективно: пропустили какой-то баг, ушли точно вовремя, не показали
> > достаточной преданности делу команды и т.п.
>
> > Сталкивался ли кто-то с такой ситуацией? Как вы с этим боролись и
> > насколько успешно?
>
> --
> __
> Best regards
> Ivan Mosev aka Verber
> ver...@rambler.ru
Alexey Maslov
Regards,
Alexey Maslov
Иван Мосев
У нас график перестал быть гибким после введения скрама. По двум
связанным между собой причинам:
1) Дейли скрам обязателен для всех по определению
2) Его лучше проводить перед началом работы (по карйней мере у нас в
этом случае синхронизация лучше)
При таком раскладе если кто-то (или даже все) вынуждены задерживаться
на работе это и будет "переработка".
28 января 2009 г. 15:54 пользователь Artjom Serdyuk
<artem....@gmail.com> написал:
Sergiy Movchan
то есть если это первая-вторая ретроспектива, то надо просто работать над ошибками проведения ретроспективы - учить народ высказываться конструктивно. не в плане "вот это было сделано плохо", а "в следующий раз надо будет сделать так-то и так-то". Это дело скрам-мастера.
опять же судя по тону автора вопроса он не считает тестировщиков объективно в чём-то виноватыми. взяв это за рабочую гипотезу (ну, то есть отметая очевидные вещи типа поругать провинившихся) получаем, что разработчики просто маскируют реальную проблему за наездами. Опять же скарм-мастер должен (если больше никто не хочет) помочь её выявить - там через 5 почему (http://en.wikipedia.org/wiki/5_Whys) или другие техники.
если же это из раза в раз такое, то хм... а как такое может быть?
--
...dali bude...
Artjom Serdyuk
друга.
On Jan 28, 4:00 pm, Alexey Maslov <amas...@gmail.com> wrote:
> А насколько тесно общаются разработчики и тестировщики?
>
> Regards,
> Alexey Maslov
>
> 2009/1/28 Artjom Serdyuk <artem.serd...@gmail.com>
Artjom Serdyuk
Мы бежим уже пятый месяц (десятый спринт). За "конструктивные
высказывания" - спасибо, обязательно воспользуемся на следующем ретро.
По моему мнению, тестеры объективно не виноваты. Скорее девелоперы
чувствуют себя обиженными, так как "мы тут вкалываем, а они с работы
уходят вовремя". Т.е. обвиняют тестеров в плохой демонстрации
преданности проекту. Я смотрю на другие команды и вижу в некоторых
примерно ту же картину: девелоперы недовольны тестировщиками, причем
без конкретных причин. При этом девелоперы могут затягивать "code
freeze", не обращать внимания на комментарии тестировщиков и т.п.
Мне всё же любопытно - кто-то с подобным сталкивался? Как вы с этим
боролись?
Разбор полётов был достаточно детальный (не такой формальный, как 5
why's). Определённые проблемы всплыли, но наши девушки-тестировщицы по
ходу расплакались... вроде бы без особых причин.
С моей точки зрения, тут две возможных root cause:
1) есть нормальное давление со стороны команды на всех её членов;
2) тестировщи страдают от сознания собственной "неполноценности": их
работа вроде бы "проще" девелоперской, и платят им меньше (тут уже без
кавычек), и вклад их в общий продукт не так ценится и не так виден,
как вклад девелоперов.
Как это изменить - я без понятия.
Ярослав, какой тут тимбилдинг поможет?
On Jan 28, 5:03 pm, Sergiy Movchan <sergiy.movc...@gmail.com> wrote:
> а как долго вы уже бежите?
>
> то есть если это первая-вторая ретроспектива, то надо просто работать над
> ошибками проведения ретроспективы - учить народ высказываться конструктивно.
> не в плане "вот это было сделано плохо", а "в следующий раз надо будет
> сделать так-то и так-то". Это дело скрам-мастера.
>
> опять же судя по тону автора вопроса он не считает тестировщиков объективно
> в чём-то виноватыми. взяв это за рабочую гипотезу (ну, то есть отметая
> очевидные вещи типа поругать провинившихся) получаем, что разработчики
> просто маскируют реальную проблему за наездами. Опять же скарм-мастер должен
> (если больше никто не хочет) помочь её выявить - там через 5 почему (http://en.wikipedia.org/wiki/5_Whys) или другие техники.
>
> если же это из раза в раз такое, то хм... а как такое может быть?
>
> 2009/1/28 Alexey Maslov <amas...@gmail.com>
>
>
>
> > А насколько тесно общаются разработчики и тестировщики?
>
> > Regards,
> > Alexey Maslov
>
> > 2009/1/28 Artjom Serdyuk <artem.serd...@gmail.com>
Borys Lebeda
--
Borys L.
Yaroslav Gnatyuk
Хорошо продуманный и спланированный, и скорее всего даже не один.
Если объективных причин для обид действительно нет и тестировщики
честно выполняют свою работу, то вашей команде надо просто больше
общаться вместе, и лучше в неформальной обстановке. Чтобы когда
девелопера Сашу спросят о тестерше Лене, первое что придет ему в
голову было не "А, это та что ни разу не задержалась на работе?", а
"Да, Лена - классная девушка, хороший человек и вообще мне с ней
приятно работать".
2009/1/29 Borys Lebeda <borys....@gmail.com>:
Alimenkou Nikolay
уже давно: тестирование должно как можно меньше осуществляться как
Quality Control. Ведь именно это дает противостояние между
разработчиками и тестировщиками, потому что одни стараются написать
хорошо, а вторые как инстанция свыше пытаются указать на проблемы.
Надо чтобы все работали одним лагерем как Quality Assurance, а задачу
QC оставляли на автоматизированные тесты. На них можно злиться сколько
угодно, но проблема на лицо. Когда тестировщики и разработчики
работают вместе над достижением одной цели - качественного продукта,
то ругаться им не будет смысла. Надо обязательно включить работу
тестировщика в критерий DONE. Это значительно поможет наладить
коммуникации. Кроме того совместное написание аксептанс или
функциональных тестов тоже положительно влияет на поддержание хороших
отношений.
Маленькое замечание по поводу тимбилдинга. Он не помогает из моего
опыта если все равно остается отношение "мы VS вы". Мол вы
понаписывали, а мы покажем вам что все лажа. Пока не будет единой
команды с едиными целями ничего не получится.
Tim Yevgrashyn
Полностью присоединяюсь к высказываниям о том, что всех нужно объеденить в одну команду. Пусть даже на время.
На мой взгляд, основной исходной проблемой как раз и является то, что у команды разработчиков и команды тестеров свои разные цели, которые где-то различаются. Этот скрытый конфликт интересов и приводит к открытым личностным (!) конфликтам.
По поводу "построения команды"... За последнее время, самое сильное впечатление на меня произвела книга Патрика Ленсиони "Пять пороков команд". Считаю, что каждому ScrumMaster'у/PM'у/TL'у нужно ее прочитать. Модель описанная в книге простая и понятная и что самое главное действительно работает - проверено на личном опыте :-)
Команда должна иметь общую цель (в т.ч. и общие SprintGoal) и вместе нести ответственность за достижение или не достижение этой цели. Если объяснить им основные "подводные камни" (пороки), то уже через пару месяцев можно увидеть ощутимые результаты.
P.S.
Кстати, совместные мероприятия - это как раз упражнение по преодолению первого порока "отсутствие доверия" (боязнь уязвимости). Люди в команде часто не знают лично друг-друга достаточно хорошо, чтобы доверять и не париться вопросом кто когда ушел.
Tim Yevgrashyn,
Phone: +380 67 408 53 30
Skype: spidertim
LinkedIn: http://www.linkedin.com/in/yevgrashyn
sun
--
sun
Артур Ракицкий
Хочу лишь добавить уточнения для простоты решения проблемы Артемом:
1. Наезды - это персональная активность, а не процесс, поэтому поговорить с "наезжающим" нужно персонально. Строго. Потом свести его персонально с объектом наезда и добиться от них двоих четкого решения, которое исключит подобное в дальнейшем.
2. Если наезды не персональные, добиться от "критика" конкретики и конструктива. Возможно за общими фразами скрывается серьезный менеджерский просчет, на который критик и пытается так реагировать.
3. Тим-билдинг нужно не просто "проводить", нужно достигать конкретных целей. Для этого менеджер должен поставить перед собой не просто идею, а задачу со сроками и критериями оценки результата. Иначе это все просто for fun.
4. Объективные критерии "хорошести" любой работы существуют. У нас, например, оценивается динамика открытия, закрытия и перепроверки багов, разнесенных по категориям, и соотнесенных с количеством реального рабочего времени потраченного разработчиками и тестировщиками. Таже, мера покрытия кода багами, мера покрытия требований (User Stories) багами. Собранная статистика регулярно анализируется. Также, при ретроспективе проводим case-study на самых ярких примерах.
Конечно, идеальных людей (тестировщиков, девелоперов) не существует, но динамика увеличения "хорошести" о многом говорит.
5. Финальная оценка "хорошести" любой проектной работы дается потребителем. Ее можно организовать так, что будет привязка к виду деятельности и области требований (а значит и к автору/исполнителю). Подробный case-study по оценке потребителем дает полноценную картину по каждому участнику проекта.
--
С уважением,
Артур Ракицкий
------------------
ICQ: 21062147
Borys Lebeda
:))))
--
Borys L.
Artjom Serdyuk
Закупаемся пистонами ;)))
On Jan 29, 3:56 pm, Borys Lebeda <borys.leb...@gmail.com> wrote:
> Отличная мысль! Сначала вставить пистонов девелоперам, а уж потом почитать
> книгу Патрика Ленсиони "Пять пороков команд"
>
> :))))
>
> 2009/1/29 sun <aleksey.solnt...@gmail.com>
>
>
>
> > А по-моему для начала не помешало бы вставить пистонов девелоперам.
> > 2009/1/29 Tim Yevgrashyn <yevgras...@gmail.com>
> >> 2009/1/28 Artjom Serdyuk <artem.serd...@gmail.com>
Alexei Lupan
словами...
1) Посадить всех вместе!
2) Установить общие приоритеты для всех членов обоих команд.
3) Ббольше совсестных задач между девелоперами и тестерами.
4) Мотивировать их совместно. Например, обещать не бить батогами
нещадно при большом скоплении народа, если билд будет завален.
Прошу ему внемлить, и если надо, я дам зуб вместо него.
Artjom Serdyuk
Вы собираете по работе тестеров те метрики, которые назвали?
- динамика открытия, закрытия и перепроверки багов
- соотношение динамики открытия, закрытия и перепроверки багов с
реальным временем, затраченным девелопером и тестировщиком;
- покрытие кода багами;
- покрытие юзер сториз багами.
Почему именно такие метрики Вы выбрали? И как потом ими пользуетесь?
> 28 января 2009 г. 13:39 пользователь Artjom Serdyuk <artem.serd...@gmail.com
Artjom Serdyuk
On Jan 29, 11:42 am, sun <aleksey.solnt...@gmail.com> wrote:
> А по-моему для начала не помешало бы вставить пистонов девелоперам.
> 2009/1/29 Tim Yevgrashyn <yevgras...@gmail.com>
> > 2009/1/28 Artjom Serdyuk <artem.serd...@gmail.com>
Артур Ракицкий
Динамика открытия, закрытия и перепроверки багов лично мне дает прогноз готовности билда к поставке в продакшн. Благодаря двум графикам
- соотношения отккрытые/закрытые и закрытые/перепроверенные можно принимать решение о дальнейшей нагрузке по обеспечению качества, а также о достаточности усилий по тестированию.
- соотношение с реальным временем дает картину распределения усилий между работами по существующим багам и работы по нахождению новых. Динамика изменения соотношения количества багов к реальному времени говорит об изменении сложности багов, а динамика изменения соотношения оценки трудозатрат по багам с реальным временем - об изменении точности оценки багов.
- покрытие юзер сториз дает нам картину проблемных мест, а динамика - картину понимания требований разработчиками или тестировщиками (в зависимости от того что сравниваем - время на фикс или время на перепроверку).
- покрытие кода - дает нам картину проблемной архитектуры, а при оценке перепроверки - картину квалификации тестировщиков (если долго висят не провереными баги, относящиеся к сложной логике).
Конечно, цифры не дают ответов на вопросы, но сигнализируют о тех проблемах, которым нужно уделить дополнительное внимание, исследовать если нужно.
Artjom Serdyuk
Что было сделано (благодаря рекомендациям коллег с Agile Ukraine)
1) Введена метрика качества продукта. Не сработало (как оправдание
тестеров).
Будем ли мы продолжать мерять эти цифры - разберёмся на ретро.
2) Порешали личные проблемы людей. Сработало.
В частности - разобрались с плохим настроением одного девелопера, и
передвинули одного тестера в другую команду (по её желанию). Страсти
улеглись.
3) упорядочили работу тестеров. Сработало.
Беклога тестирования пока нет, но до этого уже не далеко. Зато вместе
с тестерами описали все их Testing activities за спринт и поставили им
оценки (в человеко-часах).
Теперь даже сами тестировщики знают, чем они занимались целый
спринт ;))
4) я пересел в комнату к "проблемной" команде.
Не знаю, помогло ли, но (пока) тут никто ни на кого не кричит )))
Результатами я доволен. Коллеги, спасибо за помощь!
Alexey Krivitsky
Artjom Serdyuk
> Девелоперы и тестеры вместе планируют спринты?
да
> Вместе ли они проводят daily scrum?
да
> Вместе ли готовят демо?
Демо готовит и показывает в этой команде один человек. Это девелопер в
одном спринте и тестер в следующем.
> Пробовали ли вы практику парного тестирования (девелопер+тестер за одним
> компом)?
В этом спринте попробовали. Выигрыш - в тестировании тестером фичи до
коммита (на компьютере девелопера). Так как девелопер фиксил баги, то
особого выигрыша в качестве это не принесло. Но идея хорошая, думаю
будем пробовать и дальше.
> Поможет ли вы вместе составлять критерии приёмки фичи на фазе планирования?
думаю, поможет. Понемножку внедряем.
On Feb 23, 9:43 pm, Alexey Krivitsky <alexeykrivit...@gmail.com>
wrote:
> Артём
> Девелоперы и тестеры вместе планируют спринты?
> Вместе ли они проводят daily scrum?
> Вместе ли готовят демо?
> Не думаешь ли ты, что может помочь для каждой фичи выбрать пару
> ответственных: девелопер+тестер?
> Пробовали ли вы практику парного тестирования (девелопер+тестер за одним
> компом)?
> Поможет ли вы вместе составлять критерии приёмки фичи на фазе планирования?
>
> Лё
>
> 2009/2/18 Artjom Serdyuk <artem.serd...@gmail.com>
Sergiy Movchan
> Пробовали ли вы практику парного тестирования (девелопер+тестер за однимВ этом спринте попробовали. Выигрыш - в тестировании тестером фичи до
> компом)?
коммита (на компьютере девелопера). Так как девелопер фиксил баги, то
особого выигрыша в качестве это не принесло. Но идея хорошая, думаю
будем пробовать и дальше.
это должно давать не прямой выйгрыш. мне кажется, что главная цель этой практики - показать девелоперам, что тестеры не их достают, а баги ищут и это тоже тяжолая работа.
--
...dali bude...
Artjom Serdyuk
вводить какую-нибудь практику. Слишком мало гарантий, что нам удастся
кого-то в чем-то убедить ;((
Вы что-то такое делали у себя? Довольны результатами?
On Mar 10, 11:42 am, Sergiy Movchan <sergiy.movc...@gmail.com> wrote:
> 2009/3/10 Artjom Serdyuk <artem.serd...@gmail.com>
Sergiy Movchan
--
...dali bude...
Alimenkou Nikolay
http://www.markhneedham.com/blog/2009/05/04/adding-humour-to-testerdeveloper-collaboration