Является ли исправление ошибок других людей хорошим подходом?

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

Каков предпочтительный подход в гибкой разработке (scrum)?

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

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

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

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

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

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

Rgds

Изменить: Не уверен, если я дал ясно, но важно подчеркнуть, что рецензент является еще одним разработчиком в команде.

1. Оцените ошибку
2. Если это будет быстрее / более разумно для первоначального разработчика исправить это, дайте им это
3. Если это может исправить кто-то в команде, пусть кто-нибудь сделает это.

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

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

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

Есть только три причины заботиться о том, кто исправляет ошибку: стоимость, скорость и профессиональное развитие.

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

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

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

Подумайте: у кого есть больше информации об ошибке? Команда разработчиков.

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

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

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

См. Вопрос о том, как избежать микроуправления командой разработчиков программного обеспечения?

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

Затем вы можете показать это кодерам, чтобы показать, как они вызывают ошибки.

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

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

Когда ошибка обнаружена, ответственность за ее устранение несет вся команда разработчиков.

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

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