Skip to content
Home » Extreme Programming Agile Model

Extreme Programming Agile Model

    Here is my notes on Extreme programming and Agile process. Agile process model works on action based software development, the practitioners of agile prefer face-to-face communication, daily meeting and active software development approach. They want to build software that is useful and have required components rather than all the fancy unwanted features.

    Agile Principles 

    Agile Principles
    Agile Principles

    Extreme Programming Philosophy

    1. Extreme programming starts with user stories, which are scenarios that customer and user would like in the system. Detailed requirements are not mentioned in User Stories.
    2. XP Team then estimates how long it will take to implement the user scenario.
    3. Based on the User Stories and Estimates, the release planning is done in advance. That define the user stories built in which release and release dates of this release.
    4. Frequent release of iteration is employed.
    5. An acceptance test is also built from these stories bugs found in the iteration, becomes work item for next iteration.

    XP and Agile Process

    An iteration starts with iteration planning, user stories to implemented in selected high values and high risk are of high priority.

    Agile Programming Philosophy
    Agile Programming Philosophy
    If an iteration failed the acceptance test, then it is included in the next iteration.
    An Iteration of XP Model
    An Iteration of XP Model

    Some unique practices of XP programming

    • Programming is done in a pair , not individually.
    • A unit test is written first and then actual software code written to pass the test.
    • Changes are not made to the obsolete codes, instead, focus on refactoring the codes. All unused functionality is eliminated and what is necessary is built first.
    • Keep everything simple.
    • At a time, only one pair can integrate into the Base unit.
    Overall XP Model
    Overall XP Model

    Other Rules

    1. Rights of customers and programmer.
    2. Communication between Team Members, every morning they do a small meeting.
    3. Decide how meetings should be conducted?
    4. Spike solutions to resolve technical or architectural problems.