Tổng hợp ghi chú Agile Extreme Programing (XP) Note – Luyện thi PMI-ACP

Tổng hợp ghi chú Agile Extreme Programing (XP) Note – Luyện thi PMI-ACP

Extreme Programming (XP) is one of the most popular Agile model for software development good practices (Unlike Scrum which focuses of project management on prioritizing tasks and getting feedback). Extreme Programming is based on five core values taken to the extreme: [wc_highlight color=”yellow”]simplicity, communication, feedback, courage and respect[/wc_highlight]. This post is about the guidance practices, roles and responsibilities, events, etc. of XP.

agile xp methodology

Extreme Programming (XP) Agile Model

Extreme Programming (XP) is based on five core values:

  • Simplicity – reduce wastes and extra features, find the simplest way to achieve the goals
  • Communication – make sure everyone involved get clear communication
  • Feedback – get feedback early and frequently, prefer failing fast
  • Courage – have confidence to make changes and share progresses (e.g. thru pair programming, unit tests and automated builds)
  • Respect – respect other teammates, everyone is accountable for success of the project

XP Roles (Whole Team)

Team members can cross-functional, taking up more than 1 roles. Team members are expected to be co-located.

  • Development team – including developers, quality assurance professionals and business analysts
  • Customer – business representative to guid priorities and direction, provide the requirements and describe customer tests for testing the products
  • XP Coach – (optional) to facilitate communication and coordination and guide the processes

XP Events

  • Requirements are described in the form of User Stories
  • Iterations – iterations are usually 2-week long, developers work in pairs to work together during the iterations
    • Spikes – work carried out the reduce risks
      • Architectural Spikes – a particular type of spike to prove technological approach
    • Planning Games – the customer provides the requirements while the developer estimate the difficulty and resources required, the customer will select a prioritized set of requirements for the upcoming releases
      • Release Planning – 1-2 times per year, for defining high-level tasks and estimates and system metaphor
      • Iteration Planning – every 2 weeks, customer explain the functional requirements
    • Daily Stand up – daily meeting to get updated on the progress among teammates
    • Acceptance Tests – tests are written before code and continuously used to check for correctness in system functions
    • Customer Approval
    • Small Releases with Integration Tests

XP Practices

  • Whole Team – co-located in a place, including the customer
  • Planning Games – planning meetings for releases and iterations
  • Small Releases – frequent deployment with automated testing and continuous integration for competitive advantages
  • Customer Tests – customer define tests for expectation alignment
  • Collective Code Ownership – everyone has access to the code for visibility and bug detection
  • Code Standards – ensure a coherent coding approach
  • Sustainable Pace – avoid overtime and burnout to maintain sustainability in the long term, often making 40-hour work weeks, not to take up more story points than what can be completed in the previous iteration
  • Metaphor – making use of tangible metaphor to ensure alignment of goals
  • Continuous Integration – programmers check in the code to the code repository several times daily, integration tests are automatically carried out each time to ensure code quality
  • Test-drive Development – write tests before new codes
  • Refactoring – improve the existing code quality without amending the functionalities (to pay back technical debts)
  • Simple Design – the simplest design is the most efficient and less risky, do things once and only once
  • Pair Programming – two programmers working side by side, one to write, the other to review

Basic XP Activities for  Software Development Process

  1. Listening
    • To the customer to understand the requirements
    • To other development team members for collaboration
  2. Designing the code based on the requirements input
  3. Coding
  4. Testing for quality control and assurance


Leave a Reply

Your email address will not be published. Required fields are marked *

20 − 8 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.