Extrem Programming

1.       Why eXtreme Programming is considered eXtream?
a.       If code reviews are good, we will review code all the time ( pair programming)
b.      If testing is good, everybody will test all the time (automate unit testing)
c.       If design is good, we will make it part of everybody’s daily business (refactoring)
d.      If simplicity is good, we will always leave the system with the simplest design that supports its current functionality (the simplest design that meets the requirement)
e.      If architecture is important, everybody will work defining and refining the architecture all the time (metaphor)
f.        If integration testing is important, then we will integrate and test as soon as code change is made (continuous integration)
g.       If short iterations are good, we will make them really short. (small iteration)
  
2.       Values
a.       Communication
b.      Simplicity
c.       Feedback
d.      Courage
3.       Basic Principles
a.       Rapid feedback
b.      Assume simplicity
c.       Incremental change
d.      Embracing Change
e.      Quality Work
4.       Secondary principles
a.       Teaching and Leaning
b.      Small initial investment
c.       Play to win
d.      Concrete experiments
e.      Open, honest communication
f.        Work with people’s instincts, not against them
g.       Accept responsibility
h.      Local adaptation
i.         Travel light
j.        Honest measurement
5.       Practices
a.       Small releases ( 1-3 weeks)
b.      User stories drive the scope of each release
c.       Metaphor
d.      Simplest design
e.      Automate Unit Testing
f.        Refactoring
g.       Pair programming
h.      Collective ownership
i.         Continuous Integration
j.        40 hours a week
k.       Ono-site customer ( whoever owns the requirements need to be available for the development team all the time)
l.         Coding standard
6.       What programmers do in their daily working activities
a.       Coding ( write production code)
b.      Testing ( write unit test code and make them pass)
c.       Listening (listen to the users, listen to fellow programmers, listen to testers. Of course, they also ask lots of questions)
d.      Designing (have design before coding for any given user store)
7.        The promises
a.       To programmers: XP promises that they will be able to work on things that really matter every day. They won’t have to face scary situation alone. They will be able to do everything in their power to make their system successful. They will make decisions that they can make best, and they won’t make decisions they aren’t best qualified to make.
b.      To customers and managers, XP promise that they will get the most possible value out of every programming week. Every few weeks, they will able to see concrete progress on goals they care about. They will be able to change direction of the project in the middle of development without incurring exorbitant cost. 
8.       When XP is not suitable
a.       When a project committed to lots of documentation deliverables
b.      When the culture requires project members to put in long hours to prove their “commitment to the company”
c.       When the team members spared all over the places. Or when all team members work in their own cubbies

9.       Where to start?
       Pick up the most problematic project, and start to go for eXtreme.

No comments:

Post a Comment