Project plan skills
English original
Suggested Scott W. Ambler, president of planning next project, Ronin International, December 14, 2000
Project planning techniques are required for today's software developers. There are some suggestions that help you effectively plan the next project.
Recognizing that the confidence comes from the planning process, not the plan itself. Creating a project plan will force you to consider how to build your system before writing a line of code - reducing the risk of the project, because you have already considered a variety of strategies and methods and have chosen the most meaningful item. Your purpose should not just just have a plan; it should have a practical plan, you can successfully manage your project according to it. The software process promotes the development of the plan. Each software process has a different collection, which includes organizational team activities and technologies commonly used by projects. For this reason, project planning based on Rational Unified Process (RUP) is different from the plan of the OOSP project, while OOSP projects are planned different from the plan of the Extreme Programming (XP) project. Different processes have different plans. Start from the gross granular plan. At the beginning of the project, a coarse grain size should be developed, and the program is determined to determine project advanced activities and expected milestones. Rough granular plans will organize iteration - according to the size and nature of the project, each iteration is usually between three weeks to eight weeks (four weeks more than the six weeks). Some iterations will focus on the initial period of the project, and many iterations will be developed throughout the application, and some iterations are concentrated in transit into a product. The implementator should be a planned personnel. The best person to create a project plan is responsible for the implementation of the plan. When the plan is created by one person and is implemented by another person, if the project cannot be completed or beyond the budget on time, they don't believe the plan, and it is very likely to blame it. That is, everyone participating in the project should be invested in the development and progress of the project plan. Don't forget "Don't forget something." The plan must not only reflect the "real" work of demand design, modeling, programming, and testing, but also reflects the auxiliary activities (but still important), which includes:
Vacation and statutory holiday training and education project management activities, such as planning and personnel management overhead, such as systematic time, conference and reply to email architecture definition testing system rework system delivery and reuse related activities, such as universalization will Imagine and constrain documentation. When you plan, you always make some assumptions, such as getting new distributions in the application server in time, or you can get developers who are familiar with the techniques and techniques you are applying. At the same time, you will work under some constraints, such as the impact of the mandatory deadline or resource restrictions. Create these assumptions and constraints, so that when you implement the project any time update plan, you can remember some of the "unusual" decisions you have made. Recognizing that different resources means different plans. Ten experienced developers 'teams create a result of far more than 10 beginners' results created. To be more practical, your plan must reflect the real situation of the resources available to the project. Create a reality plan. The project team must believe in the purpose, valuation and timetable of its project. To do this, you have to be truly planned to avoid planning to exceed the range you can understand. Can only be ignorant when you intend to study unknown matters. Only plan valuable things. The IBM DeveloperWorks website provides many best practices that can be applied to your project. However, according to the nature of the project, not all of these technologies will be suitable for your unique situation. To simply see these best practices as tools you are placed in Project Management Toolbox, you can use these tools as needed. Appropriate use of project management tools. Some project management tools, such as Microsoft Project, providing important features, such as the development of the Gantt chart (activity schedule), planning and actual results, the development of the PERT chart (network chart), the definition of tasks, the relevant task Definition, resource allocation and resource balance of the task. All these things seem to be a good idea, and they are usually good ideas - but they need many energy to create and maintain, and rarely provide actual value for the project group. Indeed, it makes some project managers feel rich. Indeed, senior management likes to see you have a plan. However, no code is generated by all this activity. Planning is valuable activities; but invested a lot of time to create a planning chart is usually not valuable. For more information on project planning, see:
