Кто должен исправлять ошибки в среде Scrum/Agile?

По вашему мнению, кто должен исправить ошибку? Программист, да? Хорошо, но на самом деле, кто... позвольте мне объяснить.

Я - мастер Scrum по ряду проектов Scrum. Scrum говорит: "Кольцо забор ваших ресурсов, где это возможно", с которым я полностью согласен.

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

После каждого Sprint мы предлагаем Demo и Restrospective для наших клиентов и продвигаем наш код разработки в среду UAT (наш клиент обычно не хочет, чтобы небольшая часть его проекта продолжала жить, но что до них - сохраняя нашу сторону сделки, обеспечив развертывание рабочего и проверяемого кода).

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

Во время этой фазы UAT не все разработчики нуждаются в проекте в 100% случаев, поэтому нам нравится перераспределять их по другим проектам. Тем не менее, Scrum говорит, что "по возможности забирайте свои ресурсы".

Моя проблема заключается в том, что я выделяю разработчиков на этап UAT одного проекта, одновременно запуская отдельный проект Scrum с ними в другом месте. Не идеально - однако, это коммерческая реальность на данный момент.

Я могу либо:

1) Живите с ним и разработчики исправите свой собственный код - и выделите некоторое время (скажем, 20%) разработчика на предыдущий проект UAT.

2) Убедитесь, что передача обслуживания на месте и у 1 или 2 разработчиков, посвященных исправлению ошибок, в 100% случаев.

Мне нравится 1), но это создает реальную боль в заднице.

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

Что думают люди?

Ответ 1

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

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

Ответ 2

ScrumMasters не выделяют ресурсы разработчика. ScrumMaster - это роль, выполняемая кем-то из команды.

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

Необходимо улучшить технику, чтобы команды (ов) приближались к нулевым ошибкам. "Ошибки", которые живут за концом Sprint, должны перейти в Product Backlog, чтобы приоритет был у владельца продукта.

Ответ 3

Это очень интересная тема, управление проектами имеет жизненно важное значение, и надлежащее распределение ресурсов имеет важное значение.

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

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

Немного другой способ взглянуть на него.

Приветствия Натан

Ответ 4

Ваша команда НЕ должна начинать работу над новым проектом до тех пор, пока не будет отправлен текущий корабль. Я думаю, что большинство практиков-практикующих утверждают, что в UAT нет места в схватке (как это было сделано в водопаде). То, что вы ищете, называется стабилизационным спринтом и является вашим последним спринтом прямо перед тем, как начать жить. Команда WHOLE работает над этим. Вещи, которые выполняются в это время, включают в себя ошибки в последнюю минуту, настройки украшений GUI, документацию для развертывания, справочные руководства, обучение работе и длительные обеды. Также, возможно, прекрасное время для команды, чтобы самостоятельно узнать что-то новое без "давления" на доставку предметов, или немного расслабиться, прежде чем начинать что-то новое. Основываясь на ожиданиях клиента UAT; если он имеет тенденцию находиться на более длинной стороне; вы также можете отложить задачи, не связанные с клиентом, для этого спринта, такие как мониторинг журналов, сценарии настройки сервера, экраны обслуживания или другое построение инструмента.

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

Ответ 5

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

Ответ 6

Мне действительно не нравится вариант 2), потому что:

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

Итак, вариант 1) имеет мои предпочтения (но, пожалуйста, прекратите говорить о ресурсах и ресурсах).

Наконец, небольшая цитата:

Если у вас есть отдельные циклы тестирования и исправления, вы слишком поздно тестируете. --M. Poppendieck

Да, я знаю, легче сказать, чем делать... но, тем не менее, она чертовски прав.

Ответ 7

Я проголосовал за # 2. Как разработчик я ненавижу переключение контекста и то, что вы на самом деле навязываете # 1. Что касается проблемы владения кодом, то наличие у разработчиков собственных фрагментов кода является анти-шаблоном. Стремитесь к совместному владению: вводите спаривание, вращение и т.д.

Во второй комментарий @kevindtimm UAT - это еще один спринт. Возможно, меньше/меньше разработчиков.

С другой стороны, ядро манифеста Agile Software должно постепенно увеличивать бизнес-ценность, поэтому в идеале вы должны нажать на PROD в конце каждого спринта. Если это так, то UAT не должен быть частью каждого спринта. Разве это не то, чем занимается Демо?

Ответ 8

Я ведущий разработчик команды Scrum. Способ, которым мы стремимся работать в моей организации, таков:

Перед началом спринта каждому разработчику будет выделен процент от того, насколько продуктивно мы думаем, что они будут во время спринта. Например, более опытный опытный разработчик, вероятно, сможет быть продуктивным на 70-80% своего общего времени во время спринта. Это дает время для неожиданных встреч, исправлений ошибок. Я на мгновение приеду на исправления ошибок. Мы получим оценки для всех задач, подписанных, а затем планируем работу разработчиков.

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

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

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

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

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

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

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

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

Ответ 9

Частично это относится к владельцу продукта, чтобы определить приоритеты, если некоторые ошибки важнее, чем некоторые мои карты. Если PO - "Исправить эти ошибки сейчас", тогда должны быть исправлены ошибки в верхней части списка. Если существует множество ошибок с высоким приоритетом, возможно, стоит иметь стабилизационный спринт, где исправлены ошибки, и никаких новых функций не будет сделано. У меня возникло бы желание спросить PO, сколько времени они хотят потратить на ошибки, хотя я не уверен, насколько это практично.

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

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

Ответ 10

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

Я также немного обеспокоен ошибками, которые появляются в UAT. Было бы возможно, чтобы некоторые из тех, кто тестировал людей в командах, поймали их раньше? Такие вещи очень распространены в проектах, где он перебрасывается через забор из группы в группу. Единственный способ, которым я видел это, - это объединить эти группы в команды и пересмотреть стратегии тестирования. Затем UAT делает то, что вы хотите, чтобы он выполнял... проблемы и требования к удобству использования. Вы правы, они не уйдут полностью, но они будут сведены к минимуму.

Ответ 11

Я думаю, что люди также должны исправить свой собственный код. Зачем тратить все время на передачу?

Возможно, стоит делать UAT, когда и когда каждая функция завершена; поэтому "тестеры" работают вместе с "разработчиками" при тестировании. Тестеры должны иметь возможность запускать критерии UAT.

Если в UAT есть больше проблем с держателями акций, тогда они являются запросами на изменение или критерии принятия, вероятно, в первую очередь являются двусмысленными!

Ответ 12

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

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

Признание чувства собственности и гордости имеют решающее значение. Если вы этого не сделали, вы всегда рассчитываете на угрозу наказания, чтобы заставить их делать правильные вещи.

Ответ 13

Всегда старайтесь, чтобы оригинальный разработчик исправил свои собственные ошибки, ИМХО. Эта часть проста. Если у вас есть несколько разработчиков, которые ведут себя непрофессионально и уклоняются от своих обязанностей по созданию высококачественного программного обеспечения, дайте им ботинок. Если проблема является культурной, прочитайте "Бесстрашное изменение" Линды Райзинг и приступите к работе в роли SM в качестве агента изменения. Я здесь с тобой, поэтому я не просто избиваю тебя по голове; Я делаю то же самое на своей работе:).

Однако у вас большие проблемы.

Вы мастер Scrum, выделяющий ресурсы? Хлоп. Scrum guide вызывает SM для

... [служит] команде разработчиков несколькими способами, в том числе:

Коучинг команды разработчиков в самоорганизации...

Я понимаю, что у всех нас нет идеальной организации, в которой можно практиковать Scrum; однако это должно грызть вас ежедневно, пока оно не улучшится. Scrum gude ставит его просто:

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

** Во-вторых, перестаньте говорить ресурсы. Просто прекрати это. Ресурсами являются уголь, древесина и природный газ. Люди не являются ресурсами. **

В-третьих, этот UAT является большим препятствием для команды Scrum. Если я правильно понимаю вас, у клиента есть гигантская красная кнопка, которую они могут нажать и полностью взорвать "Готово" , сказав: "Вы должны это исправить, пока не закончите". Любые команды Scrum, которым это подвергается, больше не имеют скорости, прогнозов и т.д. Эти вещи все измеряют "Готово" и потенциально "Готово" ; они зависят от программного обеспечения "Готово" , которое потенциально может быть отгружено. Вот как руководство Scrum описывает Приращение Продукта:

Приращение - это сумма всех завершенных элементов продукта. во время спринта и значения приращений всех предыдущих Спринт. В конце Sprint новый приращение должен быть "Готово" , что означает, что он должен быть в пригодном для использования состоянии и соответствовать командам Scrum определения "Done." Он должен быть в работоспособном состоянии независимо от независимо от того, решит ли владелец продукта фактически освободить его.

Вы можете улучшить эту ситуацию UAT несколькими способами:

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

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

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

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