System Metaphor in Extreme Programming
Extreme Programming has lots of things that are worth being studied and described in greater detail. XP practices are one of them. In this article we will talk about Extreme Programming system metaphor practice. Some people find XP practice hard to understand. The only thing we can say about it is: “This is a wrong mindset”. We will explain the main principles and goals of this practice, but before doing that we should find the proper definition for XP and describe its main features.
As we know, Extreme Programming is an Agile methodology. It means that all Agile principles like strong customer involvement, supreme communication inside of the team and iterative cycles are applicable to it. However, there are several features that distinguish XP among other Agile methodologies.
The first thing we should know about it is that this methodology was created to deliver large amounts of software within the shortest time. Extreme Programming teams are able to manage the hardest projects with the shortest terms. Additionally, the quality of their production is really impressive. XP is a methodology with 12 practices that allow its developers to create the best software within the shortest amounts of time.
Strict time frames are the reason for short iterative cycles that are typical for Extreme Programming. A standard cycle lasts only one week. Like in other Agile methodologies, the end of each cycle is the period when the intermediate product is introduced to the customer.
The range of customer involvement in Extreme Programming is the highest among other Agile methodologies. It is the only method where the client must participate in all team meetings personally. He is also responsible for writing or gathering user stories. Each user story is a description of a certain feature of the future software product. The customer is able to influence all software development processes in an Extreme Programming team. But his main task is to formulate strict acceptance criteria and estimate the final product according to them. In some cases the final users are also involved into the process of Extreme Programming projects realization. They may participate at product testing or writing user stories.
The above mentioned features of the Extreme Programming methodology formulate its 12 practices. Metaphor is one of them.
An Extreme Programming system metaphor is a practice that is used by the XP developers to replace the standard project architecture used in traditional software development methodologies.
The idea of system metaphor in Extreme Programming is quite simple: according to this practice each chunk of the code gets its own name. These names should be understandable to all stakeholders of the project, including the developers, the customer, and the final users. That is why XP programmers use metaphors to call them. The names of these parts of code cannot be complex. They should not contain hard technical terms or phrases that are used only by software developers, because in other case the customer may not understand them. As we have already mentioned, the customer is a part of the Extreme Programming team. He participates at all stages of software development process. That is why the names of product elements must be simple and understandable to him.
XP practice of metaphors is strongly connected with user stories. These stories are simple enough to make them understandable for the customer and final users. At the same time they fully describe the functionality of the software product. That is why Extreme Programming teams often use their parts as metaphors for certain pieces of code.
