Planning Principles
The communication activity helps you to define your overall goals and objectives (subject, of course, to change as time passes). However, understanding these goals and objectives is not the same as defining a plan for getting there. The planning activity encompasses a set of management and technical practices that enable the software team to define a road map as it travels toward its strategic goal and tactical objectives.
Try as we might, it's impossible to predict exactly how a software project will evolve. There is no easy way to determine what unforeseen technical problems will be encountered, what important information will remain undiscovered until late in the project, what misunderstandings will occur, or what business issues will change. And yet, a good software team must plan its approach.
There are many different planning philosophies. 2 Some people are "minimalists," arguing that change often obviates the need for a detailed plan. Others are "traditionalists," arguing that the plan provides an effective road map, and the more detail it has, the less likely the team will become lost. Still, others are "agile ists," arguing that a quick "planning game" may be necessary, but that the road map will emerge as "real work" on the software begins.
What to do? On many projects, overplanning is time-consuming and fruity (too many things change), but under planning is a recipe for chaos. Like most things in life, planning should be conducted in moderation, enough to provide useful guidance for the team -no more, no less. Regardless of the rigor with which planning is conducted, the following principles always apply:
Principle 1. Understand the scope of the project. It's impossible to use a road map if you don't know where you're going. Scope provides the software team with a destination.
Principle 2. Involve stakeholders in the planning activity. Stakeholders define priorițies and establish project constraints. To accommodate these realities, software engineers must often negotiate order of delivery, timelines, and other project-related issues.
Principle 3. Recognize that planning is iterative. A project plan is never engraved in stone. As work begins, it is very likely that things will change. As a consequence, the plan must be adjusted to accommodate these changes. In addition, iterative, incremental process models dictate replanning after the delivery of each software increment based on feedback received from users.
Principle 4. Estimate based on what you know. The intent of estimation is to provide an indication of effort, cost, and task duration, based on the team's current understanding of the work to be done. If information is vague or unreliable, estimates will be equally unreliable.
Principle 5. Consider risk as you define the plan. If you have identified risks that have a high impact and high probability, contingency planning is necessary. In addition, the project plan (including the schedule) should be adjusted to accommodate the likelihood that one or more of these risks will occur.
Principle 6. Be realistic. People don't work 100 percent of everyday Noise always enters into any human communication. Omissions and ambiguity are facts of life. The change will occur. Even the best software engineers make mistakes. These and other realities should be considered as a project plan is established.
Principle 7. Adjust granularity as you define the plan. Granularity refers to the level of detail that is introduced as a project plan is developed. A "high-granularity" plan provides significant work task detail that is planned over relatively short time increments (so that tracking and control occur frequently). A "low-granularity" plan provides broader work tasks that are planned over longer time periods. In general, granularity moves from high to low as the project timeline moves away from the current date. Over the next few weeks or months, the project can be planned insignificant detail. Activities that won't occur for many months do not require high granularity (too much can change).
Principle 8. Define how you intend to ensure quality. The plan should identify how the software team intends to ensure quality. If technical reviews' are to be conducted, they should be scheduled. If pair programming is to be used during construction, it should be explicitly defined within the plan.
Principle 9. Describe how you intend to accommodate the change. Even the best planning can be obviated by uncontrolled change. You should identify how changes are to be accommodated as software engineering work proceeds. For example, can the customer request a change at any time? If a change is requested, is the team obliged to implement it immediately? How is the impact and cost of the change assessed?
Principle 10. Track the plan frequently and make adjustments as required. Software projects fall behind schedule one day at a time. Therefore, it makes sense to track progress on a daily basis, looking for problem areas and situations in which scheduled work does not conform to actual work conducted. When slippage is encountered, the plan is adjusted accordingly.
To be most effective, everyone on the software team should participate in the planning activity. Only then will team members "sign up" to the plan.
0 Comments