Чи правильно виправляти помилки, зроблені іншими людьми?


17

Припустимо ситуацію, коли команда з чотирьох розробників будує додаток. Під час фази тестування користувачі повідомляють про помилки. Хто повинен їх виправити? Людина, яка вчинила помилковий код, або хтось вільний?

Який переважний підхід у спритному розвитку (scrum)?


3
Хто створив ваш код, той повинен виправити ваш код
Agile Scout

Відповіді:


35

Кращим підходом у спритній розробці було б встановити їх якнайшвидше, коли це буде доступно. Це просто тому, що право власності на код попадає не на одну особу, а на всю групу розробників. Якщо одна людина постійно викликає помилки, це ще одна проблема, яку потрібно вирішувати окремо.


1
+1 для "якнайшвидше". Дійсно, виправте їх, як тільки зможете, і дозвольте своїм користувачам продовжувати тестування та повідомляти про нові помилки.

1
А як щодо зворотного зв’язку з людиною, яка вчинила помилку?

@Robert це не питання лише зворотного зв'язку. Помилка повинна бути офіційно закрита представником.

10
Також виправлення чужих помилок - чудовий спосіб навчитися. Оскільки ви цього не написали, це змушує вас реально зрозуміти, що робить код.
AndrewKS

1
@yegor, Роберт запитав про людину, яка написала помилку, а не заявника. Про важливі помилки слід повідомити, про тривіальних - ні.

8

За замовчуванням особа. Причина досить проста: відгуки. Клопи дають чудову можливість для особистого та професійного зворотного зв’язку. Якби хтось інший виправляв мої помилки, я повторив би ту саму помилку, тому що не навчився б на цьому.

Якщо ця людина недоступна, хтось інший може її виправити, але людина повинна слідувати життєвому циклу помилок.


3
Ось чому важливо спілкування. Якщо людина, яка виправляє помилку, яка не є оригінальним кодером, пояснює, в чому проблема та виправлення, було в оригінатора, то двоє людей вчаться від цього, а не один.
AndrewKS

7

Як прем'єр-міністр я уникав би пов'язувати помилки з конкретними розробниками. Якщо це потрібно зробити, нехай це зробить менеджер функціональних / розробок. Заклопотайте себе командою. Є помилка, яку команда повинна виправити.


Ми робимо те, що у нас є загальний правонаступник, якого ми називаємо «Клієнт Розробник», який може бути будь-хто в команді, і в тріаді у нас буде прапор, який відображатиме всі проблеми, призначені цьому користувачеві. Зважаючи на це, важливо, щоб ви з часом присвоїли ці завдання / помилки, щоб люди брали на себе відповідальність за них.
серпня

2

Я не знаю, як scrum впорається з цим сценарієм, але в моїй команді у нас є щось на зразок перехресного тестування / огляду коду. Таким чином, у випадку виявлення помилки і розробник, і рецензент обговорюють найкращий підхід до її усунення.

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

Rgds

Редагувати: Не впевнений, чи я зрозумів себе, але важливо підкреслити, що рецензент - ще один розробник у команді.


@Tiago: Я ціную ваше рішення, але я не думаю, що обговорення завжди необхідне.
Hoàng Лонг

1
  1. Оцініть помилку
  2. Якщо це буде швидше / мати більше сенсу для початкового розробника, щоб виправити це, надайте їм їх
  3. Якщо це може зафіксувати хтось із команди, нехай це зробить хтось.

1

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

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

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


1

Існує лише три причини, щоб дбати про те, хто виправляє помилку: вартість, швидкість та професійний розвиток.

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

Спритний підхід полягає в тому, щоб дозволити розробникам самостійно призначити проблему, я би перекрив це лише з поважної причини.


1

У моїй команді ми завжди приймаємо рішення відповідно до пріоритетності. якщо особа, яка подала код, доступна, він фіксує код. Якщо ця людина працює над історією з більш високим пріоритетом, кожен, хто є в наявності та зможе виправити код якнайшвидше, виправить це. Якщо кожен зайнятий роботою над завданнями з більш високим пріоритетом у поточній ітерації, виправлення планується в наступній ітерації відповідно до її пріоритетності порівняно з іншими історіями та дефектами.


0

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

Тож нехай вони вирішать, що робити з клопом. Вони володіють кодом, тому вони відповідають за нього.

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

Уникайте прийняття багатьох рішень, де ви (як роль прем'єр-міністра) маєте менше інформації, ніж команда.

Дивіться питання про те: Як уникнути мікроуправління командою з розробки програмного забезпечення?


0

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

Тоді ви можете показати це кодерам, показати, як вони викликають помилок.

А найкращий спосіб запобігти помилкам - це залучити всіх людей до їх виправлення. Я маю на увазі присвоїти виправлення помилок різним людям, щоб дати зрозуміти, що викликає помилки та що їх виправляє.

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


0

Коли помилка виявлена, виправити її потрібно за всією командою розробників.

Якщо люди вірять, що помилку має виправити її автор, це як би сказати: "Я не виправляю проблему, отвір не на моїй стороні човна". Але човен все одно затопить, якщо отвір не буде зафіксовано, і ви на цьому човні з усіма іншими.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.