An English immigrant IT consultant in Australia. This is my journey learning to surf, consult, mountain-bike, train, hold down a decent relationship, hold my weight down, purchase as many CDs as possible before they become obsolete, grow up, grow facial hair, develop a stand-up comedy act and stand up on my own two feet.
Tuesday, 20 May 2014
The end for NeHTA?
A recent review of PCEHR produced a number of recommendations. ITNews has a good summary of the key findings, one of which is the dissolution of NeHTA.
Defining Requirement Types: Traditional vs. Use Cases vs. User Stories | TechWell
Defining Requirement Types: Traditional vs. Use Cases vs. User Stories | TechWell:
'via Blog this'
'via Blog this'
This is a great article and substantiates my thoughts that corporate IT is not capable of rigorous SW development methodologies.
I have a purple carrot (var. atrorubens) in front of me. This epitomises the SDLC for SW engineering; it is as expected, uncomplicated and readily available. It is considered the norm since the dawn of time, or at least carrot recorded history ( <900BC). Having developed and tested telecomms and OS SW for years with detailed specifications covering protocols, standardised user interfaces and messaging systems, it seems common sense to me that systems should be clearly specified in a business benefit, then technical manner.
However, over time, once the introduction of fashionable orange carrots (var. sativus) appear around C18 the appearance of a purple carrot seems unpalatable for most customers.
This is Agile.
Having come across countless end users and business representatives, who apparently are the gatekeepers to an application go-live, and have no accumen in the definition of business requirements, it makes perfect sense that corporate IT has lent towards the advantages that Agile affords; an approach that advocates regular consultation with a customer that hasn't got the time, notion or training to deal with detailed requirements.
This might seem harsh, but so many projects have proven just that; the end user representatives are both the ones most qualified to determine if the new system changes are congruent with the proposed business changes, but also the least capable to dealing with detailed business and functional requirements. They don't like purple carrots.
Ideally, the business, or end user representatives want orange carrots; they were eating something else nice and tasty for ages, and while the new fangled carrots were interesting, it was only until they became mainstream (read IT systems delivering something useful) that they became useful.
The business wants orange carrots; no BPMN, no UML, in fact, no detailed specs. We can sort out what it's meant to do once you've built it. Agile is for the IT illiterate end user.
This shouldn't be seen as a shortcoming, but rather as a take on how Agile must be used by IT staff to engage the business.
The business DO NOT CARE how nicely your UML diagram looks; they don't have the time nor inclination to understand it. It isn't outlined how they would do it (a quote from someone not 3 months ago), they don't have time to read the specifications anyway, and do the BAs really understand what we need?!
So, if your business stakeholders are not SW engineers, erm, don't treat them like SW Engineers. SW Engineers like the thought of purple carrots, as it reminds them of vi. The business wants something they can eat now, so give them microwaved carrots.
Subscribe to:
Posts (Atom)