tagged by: requirements analysis
ConversationalStories
Here's a common misconception about agile methods. It centers on the way user stories are created and flow through the development activity. The misconception is that the product owner (or business analysts) creates user stories and then put them in front of developers to implement. The notion is that this is a flow from product owner to development, with the product owner responsible for determining what needs to be done and the developers how to do it.
4 February 2010
bliki
DecreedStories
An approach where stories are written by product owners or analysts and passed to developers to build. I see this as a profound misunderstanding of agile thinking and thus greatly prefer ConversationalStories.
bliki
FixedScopeMirage
Many companies like the idea of writing a contract that fixes scope and price because they think it lowers their risk. The mirage says that their financial obligation is fixed at the price of the deal. If they don't get satisfactory software, then it won't cost them.
30 September 2004
bliki
ObservedRequirement
Requirements are the things that you should discover before starting to build your product. Discovering the requirements during construction, or worse, when you client starts using your product, is so expensive and so inefficient, that we will assume that no right-thinking person would do it, and will not mention it again.
-- Suzanne and James Robertson
Agile methods violate this underlying assumption by intending to discover the 'requirements' during construction and after delivery. But even this cavalier disregard of the above sage advice is nothing compared to what many leading web sites do these days. These sites explore requirements by observing what the users do on their sites and using that information to generate ideas for new features along the following lines:
16 September 2008
bliki
RollerSkateImplementation
A key property of agile development is figuring out how to make a system go live with a small subset of features. We build software for the business value it offers, the quicker we go live, the faster we get at least some of that business value.
9 September 2007
bliki
SpecificationByExample
I was attending a workshop at XP/Agile Universe in 2002 when the phrase 'Specification By Example' struck me as a way to describe one of roles of testing in XP.
18 March 2004
bliki
UseCases
Use cases are a technique for organizing and eliciting requirements. They were originally popularized by Ivar Jacobson in the late 80's and early 90's.
bliki
CustomerAffinity
When someone is looking at what makes up a top-class enterprise software developer, often the conversation may turn to knowledge of frameworks and languages, or perhaps the ability to understand complicated algorithms and data structures. For me, one of the most important traits in a programmer, or indeed in a development team, is something that I'll call Customer Affinity. This is the interest and closeness that the developers have in the business problem that the software is addressing, and in the people who live in that business world.
28 July 2006
bliki
FeatureDevotion
A common, perhaps dominant, practice of agile methods is to develop a list of features (often called stories) for the software that's being built. These features are tracked with index cards, work queues, burndown charts, backlogs, or whatever your tool of choice is.
2 November 2006
bliki
HistoryIsNotBunk
History is more or less bunk
-- Henry Ford
I recently got an unhappy email from a reader of UML Distilled. It's never a good start to my day when an irate reader regrets buying, let alone reading, my words of occasional wisdom. But there was something particularly interesting about this reader's beef. His concrete complaint was about my 'unnecessary history'.
15 July 2003
bliki
OnsiteCustomer
On-site customer is one of the practices of extreme programming,
one of the twelve mentioned in the White
Book
bliki
ScopeLimbering
One of the basic tenets of agile development is that requirements changes aren't just expected, they are welcomed. This poses a particular challenge when an external company, like ThoughtWorks, is doing work for client. Many clients want a FixedPrice arrangement, which is really fixing scope because they see the FixedScopeMirage. But a fixed scope contract is totally at odds with agile development, so what is a company like us to do?
27 October 2004
bliki
StandardStoryPoints
I've heard a couple of questions recently about coming up with a standard story point mechanism for multiple teams using extreme programming's planning approach. The hope is have several teams all using equivalent story points, so that three story points of effort on one team is the same as on another.
I think trying to come up with this at best of limited value, and at worst dangerous.
6 September 2004
bliki
UseCasesAndStories
What is the difference between UseCases and XP's stories?
18 August 2003
bliki