1. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 1 Common fears of a software development manager Common fears of a software development manager: –Deadline. –Requirement. –Defect rate. –Lack of skills. –Staff turnover. –Maintainability.

2. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 2 How we managed these risks Next, I will introduce a CPTTM internal development project and show how we managed these risks. What is so special about it? It is because we used a method called “Extreme Programming” to manage these risks.

3. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 3 How it started One day in 2002, my boss, Mr. Kuan, Director General of CPTTM, told me to plan to develop a “Eureka DB”.

4. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 4 What is Eureka Eureka is international conference held in Macau about every 2-3 years. It consists of seminars and exhibition. About 1,000 participants from China, Europe and etc. will come.

5. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 5 What is Eureka DB Although we call it “Eureka DB”, it is not a database. It is a system to help us manage the Eureka event. For example: –To record the participants. –To see who have paid in full and who haven’t. –To see which hotel each participant resides in. –To generate a report containing all the exhibitors.

6. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 6 Customer’s major concerns After telling me to oversee this project, my boss asked me two questions: –Deadline: How long it is going to take? –Cost: How much is it? We can see that the deadline is not just a major of the developers, but also a major concern of the customer.

7. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 7 How long it will take? A guess How long it will take? –I thought it would take three months, but it was a wild guess. –However, my boss seemed to indicate the he only had a budget which by my calculation was enough for only two months.

8. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 8 How long it will take? A guess –Letting me handle the project seemed to be the only way to prevent it from failing, so I committed to a deadline of two months. –So the project gets a good ahead. –Don’t do this at home!

9. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 9 Recruiting developers As the project gets a good ahead, we started to look for developers. After looking under the carpet, we finally recruited two.

10. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 10 Estimate duration by feature breakdown After recruiting two developers, we let them establish how much time is needed for each desired feature (about 50): –F1: Add a participant. 1 day. –F2: List all participants. 0.5 days. –F3: Add an exhibitor. 2 days. –F4: A participant can belong to an exhibitor. 1 day.

11. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 11 Estimate duration by feature breakdown –... –F50: Print a catalog of exhibitors. 3 days. Adding these together, we found that we needed about four months, not two. However, it was too early because the estimate was inaccurate. For example, to estimate for F1:

12. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 12 Estimate duration by feature breakdown –Domain knowledge: A participant may contain just some little information or a lot of information. –General expectation level of the customer: The way to add a participant can be very primitive or very sophisticated.

13. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 13 Estimate duration by feature breakdown –Technology: How easy it is to use Linux as a development platform? How easy it is to access that PostgreSQL database? How easy it is to develop GUI using Java? How easy it is to use this Eclipse IDE?

14. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 14 Estimate duration by measuring So, we measured our development speed instead: –In two weeks’ time (an “Iteration”), try to implement some features (e.g., F1-F10). –After one iteration, we found that only 8 features could be implemented in an iteration. So, on average we can implement only 4*8=32 features. So, we didn’t really have enough time. What did we do?

15. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 15 Reducing the scope to meet the deadline We did two things: –We asked the customer to defer some non- essential features to the next release, allowing only thirty-odds features for this release. –Add more developers (me and one engineer from Cyber-Lab). This didn’t work well because we couldn’t dedicate much time.

16. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 16 Reducing the scope to meet the deadline After two months: –We did finish the most basic thirty-odds features. The estimates proved to be very accurate. –However, for the customer to consider the system usable, more features were needed. So, the contract was extended by three iterations. Why three? It was calculated from the estimates.

17. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 17 Reducing the scope to meet the deadline –Finally, we did finish the planned features in that three iterations. Once again, the estimates proved to be very accurate.

18. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 18 Summary of how we tried to meet the deadline How to try to meet the deadline: –First estimate by feature breakdown. –More accurate estimate by measuring. –Postpone some features to next release. –Add more developers.

19. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 19 How we got the correct requirements Why is it hard to get the correct requirements? –Requirements keep changing. Don’t write it down. Before every iteration, the developers talk to the customer, ask them questions and drew UIs on a whiteboard.

20. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 20 How we got the correct requirements –No one is giving any input or too many people are giving input. Too many people giving input? By my boss instruction, only the developers will only listener to the requirements from a single person (“customer representative”). So, for requirements, exactly one person will make the final decision. It is not me and not anyone else. The CR is required to have great authority for this to work. It was the manager in charge of the Eureka registration.

21. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 21 How we got the correct requirements No one is giving input? The CR is required to either know the requirements or be able to get inputs from the users. –What the users say is incomplete or inaccurate. Even if what they say is complete and accurate, the developers may get it wrong.

22. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 22 How we got the correct requirements During implementation, whenever the developers found something needed to be clarified or specified, they would talk to the customer representative face to face (by phone only if necessary). It is possible because both parties worked at the CPTTM Head Office in the same story and the CR dedicated her time to the project. After each feature was implemented, the developers showed the CR the feature in the running system and let she use it. If anything was wrong or missing, the CR would tell the developers right away.

23. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 23 How we got the correct requirements –The users don’t know what they want. Every time the CR saw the running system, she learnt more about the system and became clearer about what she wanted. The CR could invite some other users to come to see the running system so that they became clearer about what they wanted.

24. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 24 No requirement specification nor analysis phase We didn’t write any requirement spec nor an analysis phase because it wouldn’t help solve these problems at all.

25. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 25 Detect rate How we maintained software quality: –Continuously improve the design. –Automated unit test for every non-trivial class. –Automated acceptance test for every functional requirement.

26. Copyright (c) 2003 CPTTM http://www.cpttm.org.mo 26 No design specification nor design phase We didn’t write any design specification nor have a design phase because it wouldn’t help solve these problems at all.