The Second Lecture (2007-08-10)

In the second lecture last Friday, we learnt how XP project is processed and more details about planning game.

After the lecture, we made up a team and practiced planning game. During the game, some questions occurred.

"Do we need to wait until the customer finish writing story cards?"

- No, we need to communicate with the customer to help him/her to write the story cards better.

"Should we estimate the time to develop a function in front of the customer?"

Yes, as communication is very important to have a good agreement between the customers and developers, we need to do that in front of the customers in order to communicate with them.

I would really like to meet customers and start a project as soon as possible, on the other hand I'm a little bit worrying that I have not only one group work and project. The other subjects are also project subject. Furthermore, I also work and all those things make me anxious. However, I believe I can do it and I'll make it!

After the First Lecture (2007-08-03)

After the First Lecture (2007-08-03)

(I copied this post from one of my posts on my uni blog.)

Today I had the first lecture of eXtreme Programming (XP). I'd like to be a good programmer and a good developer so chose this subject.

I have a little knowledge of system development from my work experience and Systems Development Project (SDP) subject. In the SDP, I practiced waterfall model so it wasn't related to XP. In my work, there are several methodologies, used to support system development such as incremental development and time boxing from Rapid Application Development as well as some features from XP. However, just some features of XP are used thus I don't really know about XP.

XP is the one most prominent methodology of agile methodologies. It is, according to Avison and Fitzgerald (2006), used to support quicker development for small and medium size system and application development. They also affirm that XP is more rapid in software development than step-by-step methodology such as waterfall model. In XP, there are often customer meetings to get user requirements and to apply immediately these into the system development, thus it can guarantee the certain level of quality.

In the today's lecture, I learnt the values and the practices that XP has.

There are 4 values of XP which are:

1. Simplicity
2. Communication
3. Feedback
4. Courage

and 12 practices which are:

1. The Planning Game
2. On-site Customer
3. Small Releases
4. Simple Design
5. Pair Programming
6. Testing - Test First
7. Refactoring
8. Collective Ownership
9. Coding Standards
10. Continuous Integration
11. 40 Hour Week
12. Metaphor

The followings are what I've understood from the lecture.

■ XP Values

• Simplicity: choosing simple design, and small release can produce the system quickly with satisfying the customers' requirements for the current iteration of the project.

• Communication: good communication through the pair programming and frequent customer meetings can deliver a good result.

• Feedback: From testing, customer meetings & stories, pair programming and small timeboxes to repleat project process, enough feedback can be gained to improve the quality of the system.

• Courage: When it is certain that the changes made by a programmer do not bring about some unexpected problems, the programmer can be confident to refactor and redesign the system to make it better (Testing can be the key of this).

■ XP Practices

• The Planning Game: At the beginning of the project, customers write what functionalities they want the system to have on the 'story cards' then developers and programmers estimate the time required to make each function, and write it down on each card. After that, the customers choose the cards which have what they want the system to have in one week. Those are probably the most important or essential functions in customers opinion.

• On-site Customer: The customers are sitting next to the developers, thus the developers can easily ask what the customers really want. As the customers do usually not know what they want at the beginning of the project, but they will know as the project is progressed, their requirements can be changed frequently. If they are near the developers, the developers can easily make conversation with them so it can increase the quality of the system (software). Good communication => High quality software.

• Small Releases: The software is often released rather than the one final software is released at the end of project. Thus, the customers can know what the software will look like and if it fulfills what they want. The developers can also get the feedback from the customers which can help the developers to make the system as what it should be. It can bring about another benefit. As each time releases working version of software, the developers and customers can, somehow, have the software with the certain functionalities when the project is cancelled.

• Simple Design: Design the system as simple as possible but works. It can prevent from over-engineering. This can also deliver business value quickly so the customers can get what they want early. In this case, both customers and developers can have more time and money to reconsider what are more required. The developers can always refactor the existing code and simple design can help them to do so, for "simple design" does NOT mean "bed design". It might mean simple to maintain, simple to understand and simple to redesign.

• Pair Programming: Two programmers share one computer to programme. When they work together, one think tactically about the part of the programme which hs/she is about to code whereas the other one thinks strategically about how that part fits into the whole programme. With pair programming, The one can learn from the other one who is more experienced, and vice versa. This practice can cause better communication and feedback, and those can heighten the quality of the software. As both know about the programme they are working on, it can increase truck factor which means reducing the risk of the project failure.

• Testing - Test First: The tests are created first before starting coding. First with all those tests, the programmers can know what functions they need to make. They can also know whether their programme fulfills the requirements or not. They can code the programme pass each test, and passing all the tests means completion of the software. It can also help to check if any changes, made after the programme is passed the tests, cause any problems or unforeseen results.

• Refactoring: Refactoring is changing the existing code to improve its design and readability. It can make simple design possible, and can help the programmers easily change the programme as customers require. It is easy to refactor with tests. After refactoring, if the programme is still passed all the tests, it may mean the changes did not break any existing code. (The recommended book to read for refactoring is "Refactoring, Improving the Design of Existing Code" written by Martin Fowler and published by Addison Wesley. ISBN: 9780201485677, $79.95).

• Collective Ownership: There is no owner of any particular code so anyone can change any code. It can improve productivity and reduce the risk of the truck factor. Tests and coding standard make it possible.

• Coding Standards: Every programmer follows one agreed coding standard, including indentation, capitalisation, names and so on, can improve speed and help the programmers communicate with each other. They also can focus on the real issues rather than focus on reformatting others' code to make these understandable.

• Continuous Integration: Team members integrate and test frequently what they made rather than waiting all of them finish the parts assigned and put them all together to test. If they wait until all the members finish coding, they will face many problems to make the programmes work.

• 40 Hour Week: No overtime! Overtime rather decreases than increases the productivity. I'd like to quote the words from Jason Statham, performing in the movie 'Transporter', which is my favourite.
  
  "I can't think straight when I'm tired. After a good night's sleep...I always see things better."

• Metaphor: Using a simple metaphor to describe what the system is like can help to understand the programme and communicate with it. (Metaphor is probably the least popular XP practice)

Am I right???

I'm very excited at learning XP. I hope we all enjoy this subject.

※ References

Avison D. & Fitzgerald G. 2006, Information Systems Development, 4th edn, Mc Graw Hill, Maidenhead.

Wells, D. 2001, Extreme Programming: A gentle introduction. viewed 03 August 2007, <http://www.extremeprogramming.org>

First Post

I've just started using blogger!