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

Question

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

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

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

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

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

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

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

Я могу либо:

1) Смиритесь с этим и есть разработчики исправить свой собственный код - и выделить некоторое время (скажем, 20%) от разработчика до ЕСХНА предыдущего проекта.

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

Наконец, немного цитата:

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

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

Answer 6

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

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

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

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

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

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

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

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

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

Я надеюсь, что это помогает :)

Answer 7

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

Это в стороне, владелец продукта - это «менеджер проекта команды», и он должен бороться за ресурсы, необходимые для стабилизации продукта в производство.

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

Answer 8

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

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

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

Answer 9

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

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

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

Answer 10

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

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

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

Answer 11

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

Независимо от того, что вы делаете, не делайте никаких работ за пределами границ Спринта. Это скользкий склон в водопад-эск, планирующий забвение.

Answer 12

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

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

Answer 13

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

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

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

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

тренерской команды развития самоорганизации ...

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

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

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

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

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

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

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

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

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

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