Archive

Posts Tagged ‘agile’

The Programmer and the Paper Plane

2013/03/23 Leave a comment

This week at work we were visited by an agile expert who presented a workshop on agile task estimation techniques such as:

During the Planning Poker segment we were to use Fibonacci sequence poker cards to estimate a hypothetical project were the aim was to create a series of items made from folded paper including:

  • Simple helicopter
  • Paper plane
  • Decorated plane
  • bird
  • decorated bird
  • and so on…

Having made many Origami flapping birds, cranes, frogs, flowers when I was in my teens, I eagerly raised my hand when the question was asked:

“Has anyone ever made paper items before?”

Before I realised what was going on I was being passed a sheet of paper and told to make a paper airplane in front of everyone whilst being timed.  Normally I don’t like this level of attention but it was all in good fun.

I started off well, remembering to fold the paper in half but unfortunately the only design that came to mind was probably the most obvious from my early youth.  I continued to fold and crease, trying my best to keep it neat all awhile the imaginary tick-tick-tick from a stopwatch from afar encouraging me to go faster.

I kept at it till it resembled something that could fly at which point it was ready to give it its maiden flight.  I picked it up, raised it high above my head and carefully tossed it with all the grace I could muster into the boardroom skyline, only to watch it gently fall to the table in exactly the same way that feathers don’t. 😉

At which point someone said:

…and this is why developers should not test their own code!

To which we all including myself broke out in hysterics. Smile

Categories: Development Tags: , ,

Agile is Nice Until You Need to Test Your Software

2011/05/28 3 comments

We recently started to use an agile process model with Team Foundation Server 2010 (TFS).  TFS seems to going rather well but I’m not too sure about the agile model; this is not the fault of TFS of course since agile is independent of TFS and TFS is independent of process models as a whole.  The problem is to do with requirements and testability concerning the system we are developing.  Now,  unlike CMMI, agile does not really have the notion of a pure requirement; instead agile has a user story.  By a pure requirement, I mean that a requirement should independently describe functionality without being tightly coupled with a system action/verb/use case, actor and context.  (That’s why CMMI has use cases).

Unfortunately this is exactly what a user story is – it is the coupling of functionality, actor and context.

Due to this interesting marriage, our quality assurance (QA) teams have confirmed that such a thing is untestable.  For one, user stories are too wordy. Unlike CMMI requirements, agile user stories are made up of not a single line but rather several paragraphs!  Imagine you are only allowed to test a single feature in one paragraph in your home mortgage contract – you can’t, there is just far too much information to be covered by a single test. This is the first arguable short-sight of agile in an dev environment where a reasonable level of QA is being performed.   The same thing would happen in the world of CMMI if the business analyst (BA) were to pass his interview notes in paragraph form straight to developers instead of producing atomic requirements.

Even if the user story were short consisting of a single line similar to CMMI, the structure or grammar of user stories makes it hard to test due to the above-mentioned fusing of functionally, actor and context.

i.e.

As a <type of user> I want <some goal> so that <some reason>”

This is what I refer to as a scenario.  You could have the same thing in CMMI if had a use case UC.01 and two actors User and Admin.  From this example two scenarios could be derived – the scenario where the User invokes UC.01 and the other where Admin invokes UC.01.  Its the same functionality in both scenarios, however the context is different due to the different actors.  Imagine it visually by drawing an ellipse that encloses UC.01 and User and another ellipse around UC.01 and Admin.  In any event, QA would most likely have just a hard a time testing a CMMI system in this fashion if only scenarios and no requirements were provided.

Therefore the same is arguably true for user stories.

Needless to say I’m being a complete TFS geek at the moment! 😉

Categories: Development Tags: , ,