bliki tagged by: extreme programming
C3 was the short name of the Chrysler Comprehensive Compensation project, a payroll project at Chrysler which has since become famous as the 'birth project' of Extreme Programming.
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
On-site customer is one of the practices of extreme programming, one of the twelve mentioned in the White Book. It says that a customer should sit with the developers in their open work area to be available to answer questions and interact with the development team. Indeed they are part of the development team, and recognize that the success of the team depends as much on them as it does on the developers. They don't have to give up their reqular job to do this, but they must be physically present.
Every XP aficionado knows about the 4 values and 12 practices, but how many people know about the 15 principles? I'll confess I didn't when Kent talked about them at JAOO last week. After the talk I asked Kent about them: "were they in the White Book". "Yes", he replied, "cunningly hidden in a chapter called 'Basic Principles'".
4 October 2003
I've seen this confused in a couple of places now, so I feel the urge to re-state what the meaning of the term velocity is in Extreme Programming.
10 May 2004
There are various schemes of Code Ownership that I've come across. I put them into three broad categories:
12 May 2006
Dan North's recent blog post on software craftsmanship has unleashed a lot of blog discussions (which I summarize below, if you're interested). There's a lot in there, but one of his themes particularly resonated with me, hence this post.
19 January 2011
A bunch of common misconceptions about pair-programming.
31 October 2006
When people talk about Extreme Programming, they often focus on such things as its adaptive planning style, or its evolutionary approach design. One small but growing trend that particularly interests me is the small but growing number of XP projects that have very low defect rates, by which I mean less than one production bug per month.
24 January 2004
This is the principle that says you'll get as much done today as you got done yesterday. In iterative projects it says that you should plan to do as much this iteration as you did last iteration. The term comes from the Extreme Programming community.
12 May 2004