• “С моей стороны баги вылетели…”

    Posted on February 8th, 2010 Александр Орлов 8 comments

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

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

    - Ну что, Петров, два.

    - Почему два.

    - На, посмотри в бинокль на мишень – ни одной дырки, все в молоко.

    Студент берет бинокль, смотрит: «Ну, не знаю, с моей стороны все пули вылетели…»

    Отношение к работе в духе «с моей стороны пули вылетели» часто присутствует у молодых специалистов. Которые считают, что они лично могут достигнуть успеха, даже если сам проект, в котором они участвуют, провалится. Но иногда это отношение встречается и у зрелых инженеров.

    Вот, например, есть такая активность – верификация дефектов. Стандартная ситуация в проекте: тестировщики дефекты выставляют (например, в Bugzilla), разработчики героически дефекты исправляют (переводят в состояние FIXED). А проверять то, что дефект действительно был разрешен (перевести его в состояние VERIFIED) – это уже можно сделать перед самым релизом.

    Что интересно – многих тестировщиков, на самом деле, не так сильно волнует, действительно ли были разрешены те ошибки, которые они нашли. А программистов не так сильно волнует, действительно ли те фиксы, которые они предложили, работают в системе.

    То есть, одни дефект выставили (с их стороны пули вылетели), другие фикс положили в пространство кода (с их стороны пули тоже вылетели) – и все. J

    Очень редко встречаются тестировщики, которые проверяют, что «их дефект» разрешен, как только тот перевелся в состояние FIXED. Еще реже встречаются программисты, которые пинают тестировщиков, чтобы те проверили, что дефект действительно FIXED.

    Так и летают пули по проекту туда-сюда. А бедные менеджеры тушат пожары: «А-а-а, у нас к релизу много непроверенных дефектов. Нужно еще два дня, чтобы их все проверить!..»

     

    8 responses to ““С моей стороны баги вылетели…””

    1. То ли пост с подковыркой, то ли я как то шире понимаю обязанности менеджера.

      Постановка процесса, это в общем то его [менеджера] дело. За ним остаётся право сказать кто и когда проверяет фиксы. Рассчитывать на сознательность участников в этом вопросе тоже самое, что рассчитывать на неё вообще в процессе разработки ПО. И вот когда пули летают, а менеджеры тушат такие пожары, то они не “бедные”, а виновные в этом. Уровень профессионализма разработчика (тестировщика, дизайнера, проектировщика) не указывает на его уровень знания и вовлеченности в процессы.

    2. Задача тогда считается сделанной, если общая цель достигнута.

      Цель проект без багов. Баг обозначен, что fixed, а если он в действительности не fixed значит не достигнута общая цель и виноваты все (программист, тестировщик, менеджер). Что делать каждому, чтобы достичь в итоге общей цели это уже другое дело, но сам подход.

      Это как слабое звено, команда настолько сильна насколько сильно её самое слабое звено.

    3. Согласен с Alex Sergeev. Возникновение или невозникновение подобной ситуации определяется постановкой и зрелостью процессов в компании/на проекте. Если по workflow багфиксинга положено, чтобы баги переводились в verified, они будут переводится. Этот workflow изначально устанавливается либо общими правилами компании, либо конкретными установками менеджера. В его же (менеджера) обязанности входит проверять, что эти правила исполняются.
      Другой разговор, что не все ситуации можно заранее описать правилами… Но для того ПМ и существует, чтобы разрешать ситуации, не описанные в правилах.

    4. [...] Статья в тему: http://www.happy-pm.com/blog/?p=4125 VN:F [1.8.1_1037]Rating: 0.0/5 (0 votes [...]

    5. 2 Alex Sergeev.

      И вот когда пули летают, а менеджеры тушат такие пожары, то они не “бедные”, а виновные в этом.

      Хе=хе, ну да, в этом подковырка и была. :)

      Уровень профессионализма разработчика (тестировщика, дизайнера, проектировщика) не указывает на его уровень знания и вовлеченности в процессы.

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

    6. 2 Михаил Петрук

      Это как слабое звено, команда настолько сильна насколько сильно её самое слабое звено.

      Золотые слова.

    7. [...] P.S. Статья в тему: http://www.happy-pm.com/blog/?p=4125 [...]

    8. [...] P.S. Статья в тему: http://www.happy-pm.com/blog/?p=4125 [...]

    Leave a reply

    You must be logged in to post a comment.