Сохранение гибкости с политикой отсутствия ошибок / дефектов

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

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

Но я не уверен, что этот подход правильный. Я склонен согласиться с тем, что нам всегда нужно исправлять серьезные ошибки как можно скорее, и мы должны отбрасывать неинтересные ошибки. Но как насчет ошибок, которые важны, но не так важны, как новые функции? Я склонен думать, что они должны быть поданы в отставание с подходящим приоритетом.

Я приведу пример, чтобы он был понятнее - в моем проекте мы работаем с пользовательским интерфейсом, написанным на flex. У нас есть экран мастера, который открывается одинакового размера для каждого разрешения экрана. Оказывается, когда мы расширяем окно мастера, одна из страниц выглядит не очень хорошо (есть вертикальная полоса прокрутки, которая не исчезает, хотя мастер теперь может представить все и не требует полосы прокрутки). Я думаю, что эта ошибка ужасна. Я уверен, что это ДОЛЖНО быть исправлено. Но у нас плотный график, и у нас есть множество функций, которые, как мы боимся, не сделают удар и войдут в релиз. Я чувствую, что мы можем жить с такой ошибкой. Его нужно исправить, но с более низким приоритетом, чем у других функций (поэтому, в случае, если мы не сможем его завершить, по крайней мере, мы не пропустили более важные функции). Но,

Мне бы очень хотелось услышать мнения о том, как справляться с ошибками, которые я не хочу отмечать как «не исправить», но которые не имеют особого значения.

Исправление ошибок перед написанием нового кода на самом деле является одним из двенадцати пунктов теста Джоэла . Джоэл также объясняет, почему это необходимо:

В общем, чем дольше вы ждете, прежде чем исправить ошибку, тем дороже (по времени и деньгам) ее нужно исправить.

У тебя есть выбор:

• Либо вы реализуете крайне востребованную функцию и откладываете исправление ошибки, что неизбежно увеличит стоимость ее исправления,

• Или вы исправляете ошибку прямо сейчас, учитывая, что клиенты будут разочарованы тем, что вы настолько медлительны в предоставлении функции, в которой они так нуждаются.

Если ошибка не очень важна, в то время как функция есть, руководство будет склонно сначала попросить ее реализовать, а затем исправить ошибку. С точки зрения бизнеса это вполне обоснованный выбор, поскольку руководство четко понимает последствия, т. Е. Исправить ошибку позже, чем сейчас, будет сложнее.

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

При этом риск того, что очень важные функции будут реализованы до исправления незначительных ошибок, имеет риск: где поставить ограничения? Является ли функция, запрошенная 1 000 клиентов, более важной, чем ошибка, обнаруженная 100 клиентами? Как оценить, следует ли выполнять данную функцию перед исправлением данной ошибки?

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

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

В этой связи я считаю очень важным отметить, что в упомянутой вами политике «ошибки всегда имеют более высокий приоритет, чем функции», в частности, слово всегда отклоняется по крайней мере от двух из четырех принципов, изложенных в Agile Manifesto :

Индивидуумы и взаимодействия над процессами и инструментами

Реагирование на изменения после плана

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

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

Люди и взаимодействия над процессами и инструментами,
и у нас есть обязательные процессы и инструменты для контроля того, как эти люди (мы предпочитаем термин «ресурсы») взаимодействуют

Работа программного обеспечения над исчерпывающей документацией,
если это программное обеспечение полно документировано

Взаимодействие с клиентами по переговорам о заключении контракта
в рамках строгих контрактов, конечно, и при условии строгого контроля изменений

Реагирование на изменения в соответствии с планом
при условии наличия подробного плана для реагирования на изменения и его точного соблюдения

Ради полноты, политика нулевой ошибки, кажется, отклоняется не только от гибких принципов.

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

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

• ^{Вы случайно работаете над критически важным программным обеспечением? Я спрашиваю, потому что в этом случае политика нулевой ошибки имеет довольно хороший смысл и стоит компрометировать гибкие / не-гибкие / любые принципы. Хотя мне трудно представить, как в этом случае будет проворный процесс.}

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

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

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

Что вы можете сделать, так это, когда о новой проблеме сообщат, принять трехстороннее решение:

1. Это подлинная ошибка, которую нужно исправить как можно скорее
2. Это настоящая ошибка, но она не критична для функционирования приложения: превратите его в обычную историю и предоставьте владельцу продукта возможность расставить приоритеты.
3. Это не ошибка, или дубликат, или его решение не стоит того, чтобы его отвергать: отклонить по соответствующей причине.

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

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

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

Мое предложение состоит в том, чтобы заставить приоритет ошибки увеличивать каждый спринт. Допустим, у вас есть ошибка на уровне 5 (масштаб 1-высокий, 5 = низкий). Это начинается как 5, 4 спринта позже, это ошибка уровня 1. Однако для расчета приоритета необходимо установить «Текущий приоритет - количество спринтов», а не «Повысить приоритет нерешенных ошибок в конце каждого спринта» - это предотвращает «сброс» приоритета для его дальнейшей отсрочки.

Ошибки уровня 1 должны быть устранены в следующем спринте ......

Это просто объяснить, легко реализовать ....

Теперь, чтобы показать запросы, может быть другая скорость. Через некоторое время запрос должен быть обработан - либо выполнен, либо отклонен, предотвращая отставание функций, которые не имеют значения ......

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

Некоторые приложения настолько велики, что имеют разделы, которые вообще не связаны. Я не понимаю, почему каждая новая функция модуля кредиторской задолженности должна быть приостановлена, потому что в графическом интерфейсе выплат сотрудникам есть несколько досадных ошибок. Если в разделе закупок на веб-сайте компании было обнаружено какое-то раздражающее действие графического интерфейса мастера, исправьте его, но многие ошибки, возможно, придется устранить, если добавленная функция является результатом дополнительной безопасности, бизнес-необходимости и особенно изменений в нормативных документах.

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

Написание тестов, показывающих ошибку при запуске теста, является хорошим началом для исправления ошибок. Но при попытке исправить ошибки, которые имеют наименьший приоритет, мы должны дважды подумать, прежде чем продолжить. Я не хотел пропустить исправление. Но мы можем использовать некритические ресурсы для исправления этих ошибок. Скажем, в моей команде мы обучаем новые ресурсы с ошибками с наименьшим приоритетом в списке ошибок. Таким образом, мы получаем возможность обучать новый ресурс, а также придаем им уверенность в том, что они исправили ошибку при входе в приложение. Это, безусловно, заставит их добровольно выполнить следующую приоритетную задачу.

Надеюсь это поможет :)