Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Let's assume the situation where a team of four developers is building an application. During the testing phase, bugs are reported by users. Who should fix them? The person who committed the erroneous code, or anyone who is free?
What is preferred approach in agile development (scrum)?
The preferred approach in agile development would be to get them fixed as quickly as possible, by whomever is available. This is simply because the ownership of the code does not fall to any one person, but to the entire developer group. If one individual is consistently causing bugs, that is another issue that needs to be addressed separately.
By default the person. The reason is quite simple: feedback. Bugs provide a great opportunity for personal and professional feedback. If someone else fixed my bugs, I would make the same mistake again, because I wouldn't learn from it.
If that person is not available, somebody else can fix it, but the person should follow the bugs life cycle.
As a PM I would avoid linking bugs to specific developers. If it needs to be done let the functional/development manager do that. Concern yourself with the team. There is a bug the team needs to fix.
I don't know how scrum handles this scenario, but in my team, we have something like a cross testing / code review. This way, in case a bug is found, both the developer and reviewer discuss the best approach to fix it.
I believe that, as long as the solution fits, does not matter if the developer or reviewer applies it. Is important however, to avoid any kind of conflict between developer and tester.
Rgds
Edit: Not sure if I made myself clear, but is important to highlight that the reviewer is another developer in the team.
There are only three reasons to care about who fixes a bug: cost, speed and professional development.
And there are pros and cons for all three. For instance professional development, on one hand it's an opportunity for someone else to learn more about the code on the other it's an opportunity for the one that made it to recognize the kind of mistakes make and avoid some in the future. Or take cost, presumably the one that made the mistake would be able to fix it faster, and probably cheaper, on the other hand there's a cost for the time spent identifying who made the mistake, and assigning it to the appropriate person -- time, which in a lot of cases, exceeds that of fixing the bug.
The agile approach is to let the developers self assign the problem, I would override that only for a good reason.
I say, you need a bug tracking system, to record bugs, caused by what, reported by, and then assign the bugs, to different people based on their work load. Also indicated whose code caused the bug, and then have a report showing how many coders, and what apps, have caused x number of bugs during the week.
Then you can show that to coders, to show how they are causing bugs.
And the best way to prevent bugs, is to get everyone involved with fixing them. I mean assign a bug fix to different people, to give round-out experience of what causes bugs and what fixes them.
Then maybe after a month or two of everyone fixing bugs, revise or create your coding style guideline to help prevent future bugs, system wide, by having written/documented standards for how you program.
In my team, we always decide according to priority. if the person who submitted the code is available, he/she fixes the code. If that person is working on some higher priority story, anyone who is available and can fix the code as soon as possible will fix it. If everyone is busy with working on higher priority tasks in the current iteration, the fix is scheduled in the next iteration according to its priority as compared to the other stories and defects.
I totally agree with Steven about the code belongs to all team; and there's some more reasons that you shouldn't give the bug to their creators:
As I know, in many cases it's hard to identify who caused the bug. Even if you are using a document management system like SVN, tracking down the error code may consume lots of time. So, in my view, just give the bug for anyone who are free.
If you want to track how the bug produced, in leisure time you can ask the repairer about the case (before all team). As your team is small, I think this would share the experience about possible bugs, and not make anyone embarassed.
Think about: Who has more information about the bug? The development team.
So let they decide what to do with the bug. They own the code, so they are responsible for it.
You can help them by managing the project, allocating some time on project scope for bug fixes and letting they alone to do the job.
Avoid taking to many decision where you (as PM role) has less information than the team.
See the question about: How to Avoid Micro-Managing a Software Development Team?
When a bug is found, it is the responsibility of the whole development team to fix it.
If people believe that a bug should be fixed by its author, it is like saying "I'm not fixing the problem, the hole's not on my side of the boat". But the boat will still sink if the hole is not fixed, and you are on that boat with everyone else.
Individuals need to realize that they are part of a team and understand that the code, along with its responsibilities, belongs to all of them. The success of a project rests on all team members.
