1 min to read
Extreme Programming
Living on the edge
I never had the chance to practice in RL but I heard about it in books like Extreme Programming Explained
- Multiple short development cycles
- Automate testing as much as possible so you can fun it frequently TDD
- Write a test and implement as little code as possible to make it pass
- A 5m physical communication is superior to a long email chain. Body language is important.
- Rapid frequent feedback - the sooner you know it’s not working as desired the sooner you can change it
- Courage: if you can’t deliver on time tell the customer as soon as possible
- Respect: every member of the team must care for the project. This is superior to employee of the month.
- Programming Pairs change frequently so everybody knows about the entire project
- Anyone can change the code, you check it didn’t break anything with tests
- Sustainable pace 40 hours a week, if OT in one week none in the next week
- People perform best if they are rested
- Frequent deploy, frequently tested, minimize need to do OT
- Open space, no cubicles
- Shared computers
- Conference table for spontaneous discussions, allow people to join in when they have something to contribute to the meeting
- Cross training is done by default because of the pair programming. If one person leaves your productivity doesn’t suffer because you don’t have to wait for a person to learn this part of the project, they already know it through pair programming.
- One developer writes the test, the other writes the passing code and then switch
- No one person is a bottle neck for changes all developers know all parts of the system
- More efficient to have one meeting instead of many meetings amongst the developers throughout the day
Sprint Planning Meeting
- What did you do yesterday?
- What are you doing today?
- Is anything getting in your way?
Sounds a lot like agile
