Category: BDD

The project that I’m working on at the moment is pretty small.  I’ve been given the freedom, or ability to introduce some of the concepts that I’ve been reading, and thinking about over the last year. 

To summarise – I have my own features for the functionality that I am going to implement.  These have been written as acceptance criteria using SpecFlow – and the Given, When, Then syntax.  Hopefully, this will ensure that the product that I develop delivers what the user wants (I can’t say what the user wants as this is a confidential product).  I’ve found that my customer is extremely positive about using this, although we’ve probably not had as much face-to-face conversation as I would have liked.  Maybe I should explain this…  I’m convinced that some of the acceptance criteria would be better business aligned if we had a discussion rather than e-mail chain.  Ironically, since I’m new, I’m probably a tad nervous or shy to be forcing workshops on people (people who know me might laugh at my shy reference!).

I’ve found the Given, When, Then extremely useful and forces me to think about what is important for the user.  I’ve also used BDD/TDD for it as well – I’m more than confident that the design of the component I have written is a lot cleaner than I would have written a couple of years back.  I’m pretty happy with the design and lack of duplication in the code.  I’ve tried to be extremely hard on the refactoring – something I need to work on more and more. 

The other thing I’ve started as of today is my own visual board.  The reason for this is I’ve been struggling to focus on what to work on next.  I’m interested in seeing how this works; I can already feel the benefit of having something visual forcing me to think what is next and get on with the work!  Therefore, I know have:

I’ve had to get rid of what the cards actually say sorry, but they are just succinct pieces of work for this project.  The pink items are blocks, or rather problems with the card – these need to be resolved before the card can be moved to “Done”.

I’m not going to apply Work In Progress limits yet, I’m not sure whether I need to apply this to the project – my estimate is that the work will take 10 days, so should fit in a single iteration!?

Really I should have a Continuous Integration environment for the project!

I’ve been reading through the excellent “Specification by Example” in it’s early form from Manning. I’ve often struggled with the upstream practises of Agile. Recently I attended a work presentation surrounding capturing requirements and other work which BA’s undertake – it looked very “watefall-isk”! My concern was how to counter this discussion around sign off and the need for documentation.

I’m so glad that I was able to get hold of “Specification by Example” – it’s given me plenty of ideas of how to promote a different way to work. The benefit of living documentation has got to be a good starting/selling point!?

This lead me to ponder what the role of a BA was within an agile/lean organisation. It seems to have been an area that has been left behind over the years. This is primarily due to the fact that most of the original Agile Manifesto signatories where people from the software development field.

I’ve often wondered whether User Stories is all Business Analysts should do; in fact do you need Business Analysts?

Specification by Example answers a lot of questions around capturing requirements in the early phases of an agile/lean project. I’ve tried to map out how I see the process within our organisation – I’m not sure whether it’s what is intended but it’s something that I want to try out in the future:

I will write more about the book, but my first impressions are that I would recommend this to anybody who is developing software, it is extremely informative and well written.

I’ve recently discovered BDD or rather there has been an increase in communication about this topic around me – someone mentioned Cucumber at XPManXL!

I found the extremely well written Cuke4Ninja site, and started to discuss Specs more with my colleagues. Jason highlighted that SpecFlow seemed like a good implementation for .Net development.

This all seemed to align with both Gojko Adzic at Agile Yorkshire which I unfortunately missed, but made up for with attending XPManchester where John(no) gave a presentation/discussion about BDD for his Masters… He asked us to implement a Chess Kata using some features which he has developed – these can be downloaded from GitHub.

I spent a bit of time trying to implement the features. My first experience of BDD! I found it quite overwhelming initially with all the specs running. I.e. I had quite a lot of specs/tests running and didn’t know where to start.

Retrospectively I should have included a single feature – implemented it till green and then incrementally added features as I went along. This is something I am going to do on my second attempt. I plan to throw away my initial code and start again. Although I’ll probably use a similar design I’m interested to see how after my initial attempt how it will differ – will it be better design?

Initial thoughts are that features are a way to have a shared vocabulary between developers and business users. I also think that they are the Acceptance Criteria which are usually written on the back of User Story cards.

I’m also slightly confused at when to start delving deeper from high level features in to say lower level “Behaviours/Features”. This I’m sure will become apparent as I spend more time using BDD.