copyright (c) 2003 cpttm 1 common fears of a software development manager common fears of a...

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

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

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

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

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 exhibitor

s.


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

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

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

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

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


– ...– 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


– 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


– 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

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

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


• 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


– Finally, we did finish the planned features in that three iterations. Once again, the estimates proved to be very accurate.


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

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


– 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


• 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


• 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


– 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

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

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

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.

copyright (c) 2003 cpttm 1 common fears of a software development manager common fears of a...

Documents

cpttm http

copyright c

director general of

feature breakdownafter

desired feature

eureka dbalthough

eureka event

major concernsafter