Extreme Programming (2)

Introducing User Stories

introducing-user-storiesAgile Software Development: Introducing User Stories – PowerPoint Presentation

User stories are one of those areas of Agile (and in earlier form, Extreme Programming) so simple, you can tie yourself in knots trying to explain it.  This is one of many presentations explaining the principles.  The like the elevator analagy – if you cant explain your user story in less than 30 seconds, it is probably too long.  Less than 10 seconds, it is probably too short, and needs combining into a longer user story.

Remember, a user story is just a placeholder for more detailed conversations, not a specification or requirements document.

There is also a nice example here, based on coffee making, something close to my heart 🙂

XP (Extreme Programming)

During the early popularity of agile methods in the late 1990’s, Extreme Programming was the one that got the lion’s share of attention. In many ways it still does.

The roots of XP lie in the Smalltalk community, and in particular the close collaboration of Kent Beck and Ward Cunningham in the late 1980’s. Both of them refined their practices on numerous projects during the early 90’s, extending their ideas of a software development approach that was both adaptive and people-oriented.

Kent continued to develop his ideas during consulting engagements, in particular the Chrysler C3 project, which has since become known as the creation project of extreme programming. He started using the term ‘extreme programming’ around 1997. (C3 also marked my initial contact with Extreme Programming and the beginning of my friendship with Kent.)

During the late 1990’s word of Extreme Programming spread, initially through descriptions on newsgroups and Ward Cunningham’s wiki, where Kent and Ron Jeffries (a colleague at C3) spent a lot of time explaining and debating the various ideas. Finally a number of books were published towards the end of the 90’s and start of 00’s that went into some detail explaining the various aspects of the approach. Most of these books took Kent Beck’s white book as their foundation. Kent produced a second edition of the white book in 2004 which was a significant re-articulation of the approach.

XP begins with five values (Communication, Feedback, Simplicity, Courage, and Respect). It then elaborates these into fourteen principles and again into twenty-four practices. The idea is that practices are concrete things that a team can do day-to-day, while values are the fundamental knowledge and understanding that underpins the approach. Values without practices are hard to apply and can by applied in so many ways that it’s hard to know where to start. Practices without values are rote activities without a purpose. Both values and practices are needed, but there’s a big gap between them – the principles help bridge that gap. Many of XP’s practices are old, tried and tested techniques, yet often forgotten by many, including most planned processes. As well as resurrecting these techniques, XP weaves them into a synergistic whole where each one is reinforced by the others and given purpose by the values.

One of the most striking, as well as initially appealing to me, is its strong emphasis on testing. While all processes mention testing, most do so with a pretty low emphasis. However XP puts testing at the foundation of development, with every programmer writing tests as they write their production code. The tests are integrated into a continuous integration and build process which yields a highly stable platform for future development. XP’s approach here, often described under the heading of Test Driven Development (TDD) has been influential even in places that haven’t adopted much else of XP.