Ron Jeffries, Ann Anderson, and Chet Hendrickson
These next three chapter are fairly important for extreme programming to be successful. They cover quick design sessions, programming/code quality, and pair programming. Typically in XP, once the user stories are done, most people jump into test first programming. If you are consistently running into situations where you have to have design sessions, it is possible that your user stories are to large. On the rare occasion though, it can be useful to take about 10 to 15 minutes to sketch out a basic design structure. This design meetings should never go over 30 minutes in length. Programming in XP projects are done in pairs for production coding. Your partner will probably change quite frequently based on what your are working on. Each pair is given and task and is required to complete that coding assignment. They can test its completeness through a unit test which tests every possible thing that can go wrong. If the unit test returns 100, then the item is ready for production and deployment. Within XP, there is the idea of Collective Code ownership. This basically means that all of the programmers are responsible for all the code. If a programmer needs to modify an existing class to add some utility, he can do that without consulting the person who wrote the class initially. This allows a programmer to create much quicker solutions and gets rid of the middle man when it comes to fixing problems or adding functionality. Pair programming is another essential part to XP. Having two people writing the code actually produces better code faster and you also have 2 people who understand it instead of 2 people who only understand half of it. The pair should both be actively helping program even if you are not the driver.
XP does some things that most programmers would think would not actually help production. The lack of design meetings is one of them. Honestly, sometimes having an overall structure can be useful and should be done but most of the time, it usually isn't necessary. The structure will usually define itself as the project goes along. Programming and code quality are important for any programming type, not just XP. It is important that the programming lead determine a coding style for the whole project. Without it, you run the risk of writing code that your colleagues might have trouble interpreting. I've never actually done pair programming but I think it would be really helpful. Sometime I feel like I waste so much time looking things up that someone else probably already knows how to do. It is also useful to help train some of your newer employees. By having them help out a senior programmer, they gain valuable experience while also contributing to the project.
No comments:
Post a Comment