Personally I favour the phrase “Specification by Example” over the more commonly used term “Behaviour Driven Development” (BDD). That is because I demand the specifications are by example but only encourage my developers to do outside-in test first development (from BDD).
Continue reading
I recently explained to my team the objectives our automated test strategy had to fulfil:
The Iterative Incremental approach inherent in Agile applies to delivered functionality but also to the requirements elicitation part of the process.
I like to refine requirements over time. Start high level, just enough to remind us to have a conversation, then fill in the detail just as we need it. What starts as a simple name of an Epic Feature will turn into multiple User Stories each with several Scenarios. But you don’t need all of that at the start.
The iterative nature of requirements definition is suggestive of a spiral process – what my daughter would call a “snail”:
Agile Requirements Snail
Agilists love a good catch phrase. You Aren’t Gonna Need it (YAGNI), Do the Simplest Thing that Could Possibly Work, and Pain Driven Development are three of them. In fact these three are different ways to say the same thing.
All three phrases are about addressing a technical problem the team might face in the future. Immature teams will immediately attempt to solve the potential problem and thus add complexity to their product. More mature teams take a slower, more considered view.
In fact Agile teams should go through these stages when considering a potential problem/solution:
That considered process is Pain Driven Development.
Continue reading
Continuous delivery gives the capability to identify a requirement, code a solution, test it, and release it within a few hours. As I see it continuous delivery will become the norm amongst software companies. I think the trend is inevitable.
Continue reading
This is the last post in my series on software craftsmanship. I thought I’d end the series with a brief summary and recommending a (new or just different) definition for software craftsmanship.
Continue reading
Code Kata, Coding Dojos, and White Belt Programmers. What is it all about?
In part seven of my series on software craftsmanship I have a look at how software craftsmanship is sometimes wrapped in the language of martial arts.
I confess from the outset that the use of martial arts language really put my off software craftsmanship. But behind the kung-fu I found fairly uncontroversial practices.
I’ll have a quick look at the three software craftsmanship practices I found with a strong martial arts flavour: Code Kata, Coding Dojos, and White Belt Programmers. Then go into a more general discussion of what it is about.
Continue reading
I’m worried about Raja. Unless I do something drastic he’s going to die. In a rather messy and unpleasant way. Crushed by the weight of a 60 person-year software product.
But I think I’ve got a solution. Cucumber might well save Raja from his gruesome fate.
Continue reading
In the third post in my series on software craftsmanship I’m having at look at Bob Martin’s call to arms to software craftsmen to not write crap.
Continue reading
Quality Management, in a project context, is concerned with having the right processes to ensure both quality product and a quality project. This article describes Traditional Quality Management, Agile versus Traditional Quality Management, Agile Product Quality, Agile Project Quality, Agile Product Quality, Agile Quality Assurance and Control, and Agile Quality Improvement.
Continue reading