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 utilize 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.
“dEep” model is just a template frame work for adapting BDD for software maintenance projects. It may need customization as per specific project context.
By studying various Software enhancement projects I have categories the type of work into 4 different types
- Defects, “d”.
- Complex (problem space) enhancements, “E”.
- Simple (problem space) enhancements, “e”.
- Urgent production issues, “p”.
Hence the word “dEep”
The team during pre-grooming classifies work items into E, e and d. The classification of enhancements into Complex enhancements “E” and simple enhancements “e” is the trickiest aspect here. It is based on the complexity in problem space and not the size of the enhancements. This means that there could be a work item with was estimated as “XL” (T-shirt sizing ) could be classified as simple enhancements “e” and another work item estimated as “L” could be classified Complex enhancements, “E” . The reason is because here we look into the complexity of problem space and not solution space. For more reading on problem space complexity and effects on it during BDD cycle kindly read my paper - Tharayil, Ranjith (15 February 2016). "When to embrace Behaviour Driven Development (BDD)?". SolutionsIQ.
Each work items classified as “d” ,”E” ,” e” ,”p” follows different treatment wrt to the engineering practices like BDD, TDD, , Test first , Test last ,review etc which is based on context that is defined by the team . An example context is presented in my talk.
Outline/structure of the Session
- BDD Introduction 20 min (optional)
- 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