Sharing this book helps too!
Project planning and tracking is a vital part of any non-trivial project. Most students use ad hoc 'back of the napkin' 'inside your head' planning. They tend to avoid elaborate project planning or 'fake it' for the sake of appearances because of two reasons:
It is a frustrating activity. Since things rarely go according to the plan, it seems like a waste of energy to draw up a plan.
They think they know all that is there to know about planning. Since the meaning of 'planning' is well-known, students think there is nothing much more to learn about it.
In reality, a typical student project can get by without much elaborate planning because of the flexibility in available time and expected deliverables. For example, they can respond to a project crisis by skipping other course work to spend more time on the project, heroics such as overnight coding sessions, or simply not delivering what was initially promised.
However, project planning is integral to the learning experience of a project course.That is why sincere project planning is usually given extra credit. Dilligent students who want to use the project to learn the valuable skill of project planning will find the tips in this section very useful.Preferably, planning should be done as a collaborative activity. When the plan is built upon team consensus, your plan itself tends to be of better quality and others tend to follow the plan more willingly. Even if your team wants you - the team leader - to draw up the plan, do not simply allocate work to others at your discretion. Instead, present them with a draft plan and get their feedback before adopting it.
Any non-trivial student project should be done in iterative fashion. The waterfall process [http://tinyurl.com/wikipedia-waterfall] may suit certain kinds of projects, for example, when a team of seasoned programmers builds a product they have prior experience in. Most certainly your project does not fall into this category.
If you are serious about having a well-defined process for your project, you can choose from many available processes such as eXtreme programming, Unified Process, SCRUM, etc. However, smaller projects can survive just fine by simply using an iterative approach to developing the product. Elaborate process-specific practices advocated by those processes may turn out to be an overkill for small, short-term projects.
If we are following an iterative process (we should) and the product has many features, we have to figure out in which order we will implement them. While many factors influence this decision, two most important ones are the value and the risk. One strategy is to use the following order [adapted from the book Agile Estimation and Planning by Mike Cohn]: first, we implement high risk, high value features; then, low risk, high value; last, low risk, low value, leaving out high risk, low value features.
This order emphasises that 'critical' features - those that are difficult to implement (i.e. 'high risk') yet vital to the proper functioning of the product (i.e. 'high value') should be scheduled early in the project although the client/instructor does not demand it that way. This gives us enough time to recover if something goes wrong while implementing those features.
Another important factor we must consider is feature dependencies. This analysis might even discover a critical path of features in the project. A critical path is a tightly packed chain of features each one dependent on the previous one. A delay in one feature will cause a delay in the final delivery date.
iteration 1 [weeks 1-2] V0.0 : skeleton architecture, feature 1.
iteration 2 [weeks 2-3] V0.1 : feature 2, feature 3.
iteration 3 [weeks 3-4] V0.9 : feature 4.
iterations 4-7 [2 months] V1.0: features 5,6,7 and 2 additional features from the 'nice to have' list.
This plan tells us which features we will deliver from each iteration. At the end of each iteration, we plan our next iteration in more detail (we can call this the iteration plan). Here, we will break down each feature in that iteration into fine-grain tasks, estimate the effort required, and schedule them appropriately.
Align your iterations appropriately with external milestones imposed by the course instructor or the external client. For example, if your iteration ends one day before the external milestone, you have a buffer of one day to pit against any last minute delays.
If we can use a simple table or a spreadsheet to document the project plan and still achieve all the objectives easily, there is no need for fancy templates, diagrams, and charts. See here [http://tinyurl.com/simplePP-doc] for a sample project plan, maintained as a simple MSWord document.
A floating deadline (i.e. "Let's finish our tasks and email each when we are done") is a sure way to slow down the project. Estimate how long the iteration will take, and fix a deadline based on the estimates. Deadlines are a way to get a commitment from all, and push the project tasks up their priority list ("I have to finish this by Friday, or the team will let me have it!"). Of course if you find yourself finishing the work before the deadline, set a shorter deadline next time.
Start with one-week iterations. If things go according to the plan, you can try longer iterations; if they do not, make the next iteration even shorter. If you can gather all team members together for a couple of hours, consider starting with a mini-iteration that lasts only a couple of hours.
Once you have found an iteration size that fits you, try to stick to it. Try to schedule milestones on the same day of the week. Doing so helps your team to 'get into a rhythm' and makes subsequent iterations easier to plan. This especially makes sense since most of your work from other courses also follows a similar pattern.
When you need to define tasks, make sure they are verifiable. 'Complete the parser' is a verifiable task. Either the parser is complete, or it is not. 'Add more functionality to the parser' or 'Finish 50% of the parser' are not verifiable. Always plan an iteration using verifiable tasks. How else will you decide when the task is done?
While you may not have a lot of past data/experience to help in estimating, and while you are not usually required to use sophisticated estimation techniques, do resist the temptation to give the first number that pops into your head. Take some time to consider the following factors:
In rare cases when you have absolutely no idea of the size of a task, you may want to try out a similar task at a MUCH smaller scale before venturing an estimate. Such a tryout is called a spike solution. While this delays the planning process a bit, it is much better than planning based on guesstimates.
We can estimate the task size as a team or as a sub-group of teammates related to the task. You can ask the person who is likely to do the task for an estimate. Then, others can add their opinion, especially if they think the task is being over/underestimated by a big margin.
If you feel that some team members are padding estimates to evade work, here is a bit more elaborate and fun way to estimate task size (this approach is called planning poker [http://www.planningpoker.com/]):
Floating tasks are the tasks not in the critical path. Their completion time is generally flexible. E.g. 'looking for a good format for the user manual' can be done any time, as long as it is done before starting the user manual. Identify floating task for idle team members (those who have completed their tasks, and waiting for others to finish) to do.
Unlike industry practitioners, your commitment to the project is not full-time (because you are taking other courses at the same time). This means the number of hours you spend on the project is different from one day to another. Therefore, estimate task duration using person hours, not person days.
E.g. If you think a task has a size of five hours, and the time you can devote for the project is Monday - two hours, Tuesday - zero hours, Wednesday four hours, you should ask for time until the end of Wednesday to finish the task.
Let's face it: estimates can never be 100% accurate. The larger the task is, the less precise the estimate will be. First, break larger tasks into smaller ones. Second, do not give seemingly precise values to largely uncertain estimates. Using scales such as 1,2,3,5,8 (Fibonacci series) or 1,2,4,8 reflects that when the task is bigger, our estimates are less precise [adapted from the book Agile Estimation and Planning by Mike Cohn]. For example, using the first scale means when a task is bigger than five hours, we put it into the eight hours bucket instead of choosing between six, seven, and eight hours.
According to Ed Yourdon's book Death March, one reason for project failure is the naïve 'we can do it over the weekend' optimism. An overconfident student might think he can develop any system over a weekend, and things such as documentation, error-handling, and testing are so 'minor' that they do not need much time.
We should keep accurate measures of the time we spend on each task, compare it with our initial estimates, and adjust our future estimates accordingly. Do not be surprised if you found your estimates were less than half of the actual time you took.
Things like unit testing, adding comments, and routine refactorings are usually considered integral parts of coding and, therefore, should not generally be shown as separate activities in the project plan. However, it is better for student teams to include them as separate activities [adapted from the book Agile Estimation and Planning by Mike Cohn], at least until they become a habit. This practice will help us to consciously allocate time for these important activities that may be overlooked otherwise. Also, remember to allocate time for fixing bugs (found in features delivered in previous iterations).
Do not forget to include meeting times in the project plan, too. However, we should not include things that do not add value to the project (e.g. answering emails).
Some teams allocate one member to 'do the project plan'. This member creates a nice project plan and submits it, while others never get to see it, let alone follow it. Instead, each team member should have an intimate knowledge of the project plan, at least the part that applies to him. One should always be able to answer the following question: "According to the project plan, what should you be doing today?"
It is not enough to know the plan. You should also try to follow the plan. Always refer to the plan when choosing what to do next.
Planning is not over until the project is over. 'Revise plan' should appear frequently in the project plan. It is also advisable to put someone in charge of this aspect.
Do a post-mortem analysis at the end of an iteration. What did not go according to the plan, and why? Change the master plan as necessary.
When there is a mismatch between what you actually did and what the plan says, it means the plan needs adjusting. But remember, you should not adjust the past plan to match what you did up to now, but you should adjust the future part of the plan to match what you now think you can do (as opposed to what you originally thought).
Evaluators know that a project plan never revised at least once is most likely a fake.
Do not assume that everything will go according to the plan. Insert buffers to strategic locations of the task chain. If task B depends on the completion of task A, try not to schedule task A immediately before task B. Scheduling task A a little earlier creates a buffer between A and B. That way, a delay in A is less likely to affect B.
Note that buffers should be explicitly shown in the plan. Inflating all estimates by 10% is not the same as adding buffers.
Consider the following true story: A team claims to have implemented all the features of the product, but did not have enough time to hook up the functionality with the GUI, and therefore, had no way of demonstrating those features. They offer to take the evaluator through the code to prove their claims, an offer he politely declines. The team receives a very low grade, although they supposedly fell only a small step short of the complete product. They could have got a much higher grade if they had omitted some features and used that time to hook up the remaining features to the GUI.
The moral of the story: When short of time, you have to sacrifice some features so that at least the other features survive. If you realise you are behind schedule, and if late submissions are heavily penalised (they should be!), you should not carry on with the current plan as if nothing is wrong. Choose wisely what you will include in the product, and what you will have to omit. Do not blindly re-allocate time from one task to another (e.g. from documentation to coding) - the decision should depend on the amount of credit you stand to gain from each. Do not skimp on testing no matter what - it is better to have 90% of the features 100% tested (i.e. a good product that lacks some features) than 100% of the features 90% tested (i.e. a lousy product. Period).
Similarly, when you cannot make the iteration deadline (an internal deadline set by the team), drop/postpone features rather than extend the deadline. Changing deadlines disrupt the rhythm of your team.
If you are ahead of the schedule, do not 'take it easy' until the plan catches up with you, and do not use the extra time for 'gold plating' (i.e. adding unnecessary adornments to the product). It simply means the plan was wrong, fortunately, in a good way. Do what you would do if you were behind schedule; consider the current status, revise the schedule accordingly, and carry on.
Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]comp.nus.edu.sg
|
|
Sharing this book helps too! |
---| This page is from the free online book Practical Tips for Software-Intensive Student Projects V3.0, Jul 2010, Author: Damith C. Rajapakse |---