Simple^4 Xiaoming Wang

Project risk management

In terms of project management theory, risk management in a project can be defined into three main activities:

• Risk assessment and analysis
• Risk reduction and monitoring
• Risk management process and methodology

It might be difficult to understand the boring theory. Let me give a real example to talk through how these activities happen in a project.

Imagine, you and your partner plan to have dinner in a fancy restaurant on the Fifth Revenue for your three years anniversary. Basically, you guys need go through the following steps in order to make your wife/husband happy.

1. Find the number of the restaurant
2. Call the number and book the table
3. travel to the restaurant
4. Order
5. Eat, drink, sweet talk, eye contact, and etc…. wait, drink more
6. Pay

In the above steps, if everything is going well, brilliant! However, as you know anything could go wrong in real life, you would not know beforehand. Such as “the number is wrong”, “No table available”, “No texi, or huge traffic prevent u getting there”, “the restaurant forgets booking your table”, “Your wife/husband is not happy with the dishes”, “They do not accept credit card or your credit card does not work” and etc. There are many of them. On contrast, they might not happen if you are lucky. You might discover more risks than I list out. So generally, a brainstorming is absolutely necessary on this stage. Just remember, the brainstorming starts earlier than your anniversary and go through the whole process.

Yes, first thing we need do is to assess and analyse these potential risks and their threats so that you can decide which one you need pay more attention and which not. Let’s make a matrix for these risks.

You can easily figure out why “Your wife/husband is not happy with the dishes” is critical for this “project”. Because it might cause a big fight and ruin your “perfect plan”. The impact*likelihood of “No table available” is small because it is not some special occasion or holidays. Generally it is not that difficult to figure out based on brainstorming, assessment and analysis.

During the analysis, you can prioritize the risks by “Impact*likelihood” to determine which risk should be pay more attention and focused on.

So, when we know these risks and their threats, impact and likelihood, how do you manage them in order to reduce the impact to the lowest level? There are four ways to manage risks. They are

• Mitigation
• Transference
• Acceptance
• Avoidance

In most of the circumstance, we acceptance those risks with small “impact*likelihood” and try to avoid or transfer some risks which can be. For the rest, you might not find a way to get rid of them, so mitigation is the only thing that you can do.

For the risks specified in the matrix above, we can add columns “Strategy”, “action” and “Owner”. The duration of the action would be nice to have.

Next thing that you need do is monitoring the risks and guarantee that all the known risks are under control.

Agile project risk management

Even in agile projects, risk could be much less against waterfall model. There are still going to be risks for a project management team do deal with. So how and when to do it? Who should responsible for the risk management in an agile project?

• During the inception phase, much brainstorming will be done, so why not identify, assess and analyse some potential risks?
• During daily stand up, why not the team give a brief update of risk matrix and new risks that you can think of?
• Any time during the day, when an idea pop up your mind, why not have a discussion with the team members? If it is a risk, record it into the matrix.
• PMT, as everyone in the team is responsible for risk management
• PM, as project manager is responsible for maintain the matrix and facilitate weekly risk update meeting.

There are more that we can do for agile project risk management.

Based on our experience, where could risk come from and how it look like could be forecast and pre-prepared. However do not pre-prepare too much. Because every project is different, it might have all different risks across different projects.

There is no short cut to do risk management, just keep an eye on and make sure everything is followed up by someone.

Interestingly, by using lean project management, it could help to identify the risk priority but it does not mean that we could ignore the risk management by focusing on the bottle neck.

The last day before China National holiday, I got the chance to learn TDD from Hu Kai who is a main contributor to CruiseControl and CruiseControlEnterprise.

Basically, we made up an example for practicing. A good example for TDD exercises is “develop a calculator”.

• First thing, we did was write a JUnit test for calculator project, based on requirement
  

  As a user, I want the calculator to have absolute value function, so that I can carry complex calculations.

  with one of the three acceptance criteria.

• Then run the test. When we saw the test failed, we know that it was time to develop some functions to make the test successfully.
• After we accomplish the the code part, then re-run the test. This time test passed
• It is not done yet. Add one more test case, run test. Failed, then improve the code.
• When we added the last two test cases, test would not fail so it meant that our function was achieved based on the requirement.
• Next step refactoring code. Done. The code looked neat and pretty

But it looked something missing…… Ah! Comments! Yes, I remembered that the first thing my teacher taught me in Java programming was “Don’t forget writing down your comments, otherwise people would not understand them.”

Hu kai, why did not write some comments in your code?— Xiaoming

You don’t have to because all the tests and code are self-explaining and highly comprehensive.— Hu Kai

Then people in the room had a discussion when should we have comments in Java code with Agile practice. My idea was that for those legacy system, if there were no comments or documents, how could people understood them? Different opinion was to write as high-level self-explaining code as possible. For example, make the names of classes, functions human-readable. I would buy their ideas except in some cases, comments are necessary

• Interfaces, libraries. Yes these abstract information need comments to help programmers to understand how to use them. We might call it “User guide” rather than comments.
• Complex algorithm. It would be very difficult for programmer to understand without spending much time on it. So it’d better to have comments for the brief explanation of this section of code.

Meanwhile, functions should be as simple as possible so you don’t have to write comments for complicated ones. Basically breaking down complex functions into simple ones would be a good idea.

All in all, when we initiative to learn something, it always came to the end with more knowledge and experience in your pockets. What a brilliant enthusiasm of learning!

Unfortunately, in most of the university classes and labs, students have not got chances to do useful exercises like this. I highly recommend doing more in our universities classes or labs.

~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.

According to Lingling’s question, let me give a real example. Firstly list the three acceptance criteria.

Given a positive integer A ,When I calculate it with abs function, then I get the same number A.

Given a negative integer “-B” ,When I calculate it with abs function, then I get a positive number “B”.

Given number “zero” ,When I calculate it with abs function, then I get zero.

Let’s write the first test case: My idea is to show the logic so it would not be the real code

Public boolean testAPositiveNumberShouldReturnPositiveNumberWithSameValue(4){
if(object.abs(4)=4){
return true;}
else{
return false;
}
}

When we have this test case for acceptance criteria one, and run the test. Obviously, the test failed because we do not have the function abs yet. So let’s try to write some code to make the test pass

Public int abs(a){
if(a>0){
return a;
}
}


Build the code, once you run the calculator tests, it will pass because the method provide the function of test “testAPositiveNumberShouldReturnPositiveNumberWithSameValue”

Then we add another test case based on Acceptance Criteria two

Public boolean testANegativeNumberShouldReturnPositiveNumberWithSameValue(-4){
if(object.abs(-4)=4){
return true;}
else{
return false;}
}

When you run the test, you can imagine that the test failed.

It is time for you to write some code to fix the fail test. Can you do it? OK let me do it for you:-)

Public int abs(a){
if(a>0){
return a;
}
else{
return -a;
}
}


Build, run test, Yeh!!!! Test passed!!! Even when u try the third test case, it passed either. It means that you don’t have to write more code about it. This is the beauty of TDD

Next step code refactoring. You may use Math.abs() to replace that piece of code

So, let’s answer your question one by one:

• Is each test case designed to test one of the three acceptance criteria?

The answer is “Yes” You can write the three test cases all together. However I highly recommend to write each by each.

• How do you define the test is “failed”? e.g. If the result data is not “exactly match” the expected data? or the test doesn’t run properly?

I might not need answer this question. If you do not have the function to satisfy the JUnit test, the test would definitely fail. If you are familiar with Eclipse you might easily understand what I am talking about.

• Why did you “pass” this test with only one test case for each requirement?

The beauty of Agile is to do every little bit each time then increase little by little. As soon as you find out that no more code is needed, the job is done!!