Не верю в отсутствие ошибок. Ошибки появляются всегда, в любой программе. И не все ошибки одинаковые. Может где-то это все удается решить через общение в рамках итерации. Но когда народу много, ошибки необходимо фиксировать, хотя бы для того, чтобы не забыть об имеющихся проблемах.
Мы тут пытаемся выработать свою линию поведения в случае обнаружения ошибок в проекте.
Фиксируются ошибки немного по разному, в зависимости от того, к какой части проекта они относятся. Ошибки по функционалу, не разрабатываемому в данный момент попадают в беклог. Ошибки по текущему функционалу не зависимо от критичности линкуются к текущей истории.
В процессе итерации программистам вроде бы нечего делать, основной функционал уже написан, и они начинают чинить все баги подряд, надо же чем-то себя занять. Но это приводит к тому, что тестировщики продолжают колупать фичу, при этом генерируется еще много низкоприоритетных багов и все идет по кругу.
Когда же остановиться? Нужен Definition of done, и он у нас негласно есть. Нельзя закрыть фичу, пока в ней присутствуют критические или высокоприоритетные баги. Надо это крупными буквами написать на доске.
А оставшиеся баги? Помоему оставшиеся даже не следует начинать. Эта моя революционная мысль вызвала бурные дебаты на работе. Как можно не исправлять баги? Да очень просто.
Что важнее, эти вот низкоприоритетные баги, или очередная фича по плану? Можно так заковыряться с мелочами что к концу итерации нечего будет демонстрировать.
Тестировщик при создании бага должен честно оценить важность этого бага. Он важен для релиза? Важен - чиним, не важен - не чиним. Тут трудно выразить конкретные критерии, даже опечатка в одну букву может быть критична для релиза.
Если возникает желание починить какую нибудь из мелких багов - возможно эта бага не так уж незначительна как казалось? может быть она всетаки важна - тогда поднимаем приоритет и чиним, нет - фтопку.
С другой стороны не все важные с точки зрения тестировщиков баги стоит сразу же чинить. Возможно важность баги завышена - если это так - понижаем приоритет и фтопку.
Я не предлагаю выкидывать баги. Просто в конце итерации все не взятые в работу баги перекочуют в беклог и будут там пылиться до скончания веков. Может быть когда нибудь, мы сделаем все фичи, исправим все более важные баги и дойдем до этих...
когда нибудь...
Мы тут пытаемся выработать свою линию поведения в случае обнаружения ошибок в проекте.
Фиксируются ошибки немного по разному, в зависимости от того, к какой части проекта они относятся. Ошибки по функционалу, не разрабатываемому в данный момент попадают в беклог. Ошибки по текущему функционалу не зависимо от критичности линкуются к текущей истории.
В процессе итерации программистам вроде бы нечего делать, основной функционал уже написан, и они начинают чинить все баги подряд, надо же чем-то себя занять. Но это приводит к тому, что тестировщики продолжают колупать фичу, при этом генерируется еще много низкоприоритетных багов и все идет по кругу.
Когда же остановиться? Нужен Definition of done, и он у нас негласно есть. Нельзя закрыть фичу, пока в ней присутствуют критические или высокоприоритетные баги. Надо это крупными буквами написать на доске.
А оставшиеся баги? Помоему оставшиеся даже не следует начинать. Эта моя революционная мысль вызвала бурные дебаты на работе. Как можно не исправлять баги? Да очень просто.
Что важнее, эти вот низкоприоритетные баги, или очередная фича по плану? Можно так заковыряться с мелочами что к концу итерации нечего будет демонстрировать.
Тестировщик при создании бага должен честно оценить важность этого бага. Он важен для релиза? Важен - чиним, не важен - не чиним. Тут трудно выразить конкретные критерии, даже опечатка в одну букву может быть критична для релиза.
Если возникает желание починить какую нибудь из мелких багов - возможно эта бага не так уж незначительна как казалось? может быть она всетаки важна - тогда поднимаем приоритет и чиним, нет - фтопку.
С другой стороны не все важные с точки зрения тестировщиков баги стоит сразу же чинить. Возможно важность баги завышена - если это так - понижаем приоритет и фтопку.
Я не предлагаю выкидывать баги. Просто в конце итерации все не взятые в работу баги перекочуют в беклог и будут там пылиться до скончания веков. Может быть когда нибудь, мы сделаем все фичи, исправим все более важные баги и дойдем до этих...
когда нибудь...
2 коммент.:
Так, может, выделить просто отдельных людей, которые будут непосредственно фиксить "подвисшие" баги в отдельной ветке, а вы, как и прежде, будете ваять фичи?
Тогда когда будет пофикшен баг, из bugfix-ветки просто делается merge в рабочую.
У меня на работе похожая ситуация: есть ряд проектов с общей архитектурой, но сильно кастомизированный под каждого заказчика. Пришлось по каждому заказчику создавать свою индивидуальную ветку проекта и создавать общую production-ветку, в которую будут вноситься доработки/исправления багов по всем заказчикам. Преимуществ здесь два:
1. Доработки по одному заказчику не влияют на другого.
2. При необходимости можно сделать полноценный апгрейд установленного ПО до самой свежей версии - production.
У нас специфика немного другая. На поддержке наверное так можно. Но мы пишем код бля. Лишних людей, чтобы фиксить низкоприоритетные баги у нас нету. :)
Ветки у нас тоже как-то не прижились пока. В перфорсе ветки немного тяжеловаты, может быть поэтому. Используем их только для релизов.
Отправить комментарий