Adapting BDD for software maintenance projects using the “dEep” model.
Behaviour driven development has been a tried and tested technique to help us build the right product. In the recent years many teams who are in green field development projects are adopting it and finding great success. The core of BDD is the collaboration angle that enables teams to build the right product. BDD team members work together in identifying different scenarios and elaborated them in the form of examples. During these discussions, technology facing members get a better understanding of business and vice-versa. It has also been observed that identifying, discussing and debating scenarios helps the team in analysing and studying the feature in much detail. Many teams benefit from this practice as it aids them shape their product.
But when it comes to teams whose primary responsibility is to maintain previously built software system, BDD as a technique is something that they really don’t know how to make the best of it. This is because BDD’s primary focus is on driving the development of new features / stories, in case of enhancement projects this driving the development phase was history. Also we are considering a context in which these projects run-on lots of legacy code. This article discusses on how software maintenance projects can benefit from this second generation agile methodology. As you would all agree we will not able to use BDD as it is directly, we need to customize according to our needs to get the best of it. We discuss one such customisations called the “dEep” model.The “dEep” is a model that I have come up with for software maintenance projects teams that I coach to get the best of BDD.
Outline/Structure of the Talk
- Introduction 2min
- The problem 5 min
- The problem and solutions space theory 3min
- “dEep” Model 6min
- Measuring complexity 2min
- Q&A 2min
Knowledge on how to adapt BDD for software maintenance projects
Developers , Product Owners,Scrum Masters,Leadership