tagged by: extreme programming
For many that come briefly into contact with Extreme Programming, it seems that XP calls for the death of software design. Not just is much design activity ridiculed as "Big Up Front Design", but such design techniques as the UML, flexible frameworks, and even patterns are de-emphasized or downright ignored. In fact XP involves a lot of design, but does it in a different way than established software processes. XP has rejuvenated the notion of evolutionary design with practices that allow evolution to become a viable design strategy. It also provides new challenges and skills as designers need to learn how to do a simple design, how to use refactoring to keep a design clean, and how to use patterns in an evolutionary style.
with Jack Bolles
In late June over a hundred people gathered on the Mediterranean island of Sardinia to take part in the XP2000 conference to discuss Extreme Programming (XP) and other flexible methodologies.
One of the attractive things about XP is that it gives quite definite statements about what you should do to be doing XP. Furthermore that set of practices is carefully designed to fit together. Taking anything out has serious consequences. Yet one of the principles of XP and other agile methods is that they be self adaptive: that is you should change the process as you are developing the project. How does this notion fit in with the rigid practices of XP?
An interview done with Pearson to promote our book Planning Extreme Programming. We banter about the background to XP and the role planning plays in an XP project.
23 May 2001
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
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
Velocity is a notion from ExtremeProgramming that helps calibrate a plan, tying broad statements of effort into elapsed time. Velocity is a statement of how much stuff a team (or a person if it's personal velocity) gets done in a time period. You should usually determine velocity by measuring how much got done in past periods, following the principle of YesterdaysWeather. A typical approach is to average the velocity the past three time periods to determine velocity for future time periods. Velocity has spread far beyond its XP roots and is now used widely in agile projects of all flavors.
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.
1 May 2006
At the end of May 2002, the XP community once again descended on the Mediterranean island of Sardinia. In this article I look at the plenary speeches from Ken Schwaber, David Parnas, Enrico Zaninotto, Bill Wake, and the Standish Group's Jim Johnson. They lead me into some thoughts on the essence of agile development, the role of mathematical specifications, the complexity of irreversibility, metaphor, and the best way to drastically cut software costs.
2 July 2002
When I went to Snowbird in 2001 for the meeting that led to the Manifesto, Jim interviewed me for a book he was working on. It provides a snapshot on my thinking on extreme programming and this thing that a few days later we called agile software development.
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.
3 August 2004
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
Extreme Programming (XP) is a software development methodology developed primarily by Kent Beck. XP was one of the first agile methods, indeed XP was the dominant agile method in the late 90s and early 00s before Scrum became dominant as the noughties passed. Many people (including myself) consider XP to be the primary catalyst that got attention to agile methods, and superior to Scrum as a base for starting out in agile development.
11 July 2013
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