There has been lot of discussion about TDD, Test Driven Development and Scrum lately. TDD in short, means that you write unittests before an implementation, you make sure that they fail at the first run and then after this you provide the implementation. This means in practice that you have to do the design of an interface first in order to be able to write tests. I believe that there are many good things in TDD and it really helps you to improve the code quality.
The Scrum is agile way of doing a software development. Very trendy way to do things at the moment:) The idea of scrum is that you pick an item from the work or requirement list called product backlog and add it to the sprint backlog. A sprint can be something like two weeks period and during that period you commit to do the things that your team has put in the sprint backlog. In practice, backlog can be in an Excel sheet, Post-it notes or you can use more advanged tools for managing backlogs.
In Scrum you have a product owner (client) who is reposible of defining what the application you’re working on should do in high level without knowing too much about the technical details (usually). The product owner is responsible of maintaining the product backlog. The product backlog contains high level user stories that can be divided to the smaller stories. For example a user story could be something like: “User must be able to take a picture by pressing a shutter key of N900“. This is of course quite large task to do in one sprint, so it is possible to divide it into the smaller user stories. When all the smaller user stories are done, the you can happily say that the larger user story is done i.e. feature complete. Of course when there are no items left in the product backlog, then the project is done.
Today I had an idea. Someone has probably already figured out this same idea before, but could we have Bug Driven Development? Basically the idea behind BDD is that it is a combination of TDD and Scrum. Here is how it goes:
- The product backlog is in a bug management tool like Mantis or Bugzilla
- In the first place all unimplemented features are put in the bug management tool as a bug. For example the “User must be able to capture a picture by pressing a shutter key of N900” would be that “It is not possible to capture a picture by pressing a shutter key of N900“
- These larger “bugs” which work as requirements, should of course be divided into smaller bugs like: “It is not possible to get an image from gstreamer pipeline”, “it is not possible to get HW event from the shutter key” and so on. For example in Bugzilla this “high level” bug would have a dependency to all “sub bugs.
- In a sprint planning day the team will choose which bugs they commit to “fix” in the becoming sprint.
- When a developer picks a “bug” (assigns it to herself) to implement, she first creates tests for the header and then provides the implementation. Here we use TDD. Basically the unittest should test the descibed bug in Bugzilla.
- After when a feature is “fixed” i.e. implemented it can be marked as done.
- The high level feature would be implemented (done) when all the sub bugs that it depends are fixed. When there are no smaller bugs left the whole feature is implemented.
- In this way unittesting tests all the features that should be implemented. If an unittest fails, the bug that it tests, must be re-opened.
I’m halfly joking here, but I guess there could be a seed of an idea in BDD. The biggest thing would naturally be in the first phase where you need to create bugs from all the features that Product Owner requires. But if you do scrum, then this phase (product backlog) needs to be done in anyway. Of course it’s up to the team if they want to split some larger features in a smaller sub components.