We can achieve rapid development by following a four part strategy:
- Avoid classic mistakes.
- Apply development fundamentals.
- Manage risks to avoid catastrophic setbacks.
- Apply schedule-oriented practices
Four Dimensions of Development
People
people ware issues strongly influence productivity, it is also now crystal clear that any organization that's serious about improving productivity should look first to the people ware issues of motivation, teamwork, staff selection, and training. There are other ways to improve productivity, but people ware offers the greatest potential benefit. If you are serious about rapid development, you have to be serious about people ware issues.
any organization that wants to improve its productivity should be actively trying all these things.
- Team organization
- Motivation.
Process
Process, as it applies to software development, includes both management and technical methodologies.
A focus on process can help.
- work avoidance.
- Quality assurance.
- Development fundamentals.
- Risk management.
- Resource targeting.
- Life cycle planning.
- Customer orientation.
Product
The most tangible dimension of the people/process/product/technology compass is the product dimension, and a focus on product size and product characteristics presents enormous opportunities for schedule reduction.
The most tangible dimension of the people/process/product/technology compass is the product dimension, and a focus on product size and product characteristics presents enormous opportunities for schedule reduction.
Both product size and product characteristics offer opportunities to cut development time.
- Product size.
- Product characteristics.
Technology
The current move toward component ware (VBXs and OCXs) might eventually produce similarly dramatic results. Choosing tools effectively and managing the risks involved are key aspects of a rapid-development initiative.
Classic Mistakes
Some ineffective development practices have been chosen so often, by so many people, with such
predictable, bad results that they deserve to be called "classic mistakes."
Some ineffective development practices have been chosen so often, by so many people, with such
predictable, bad results that they deserve to be called "classic mistakes."
People
- Undermined motivation.
- Weak personnel.
- Uncontrolled problem employees.
- Heroics.
- Adding people to a late project.
- Noisy, crowded offices.
- Friction between developers and customers.
- Unrealistic expectations.
- Lack of effective project sponsorship.
- Lack of stakeholder buy-in.
- Lack of user input.
- Politics placed over substance.
- Wishful thinking.
- Overly optimistic schedules.
- Insufficient risk management.
- Contractor failure.
- Insufficient planning.
- Abandonment of planning under pressure.
- Wasted time during the fuzzy front end.
- Shortchanged upstream activities.
- Inadequate design
- Shortchanged quality assurance.
- Insufficient management controls.
- Premature or overly frequent convergence.
- Omitting necessary tasks from estimates.
- Planning to catch up later.
- Code-like-hell programming.
- Requirements gold-plating.
- Feature creep.
- Developer gold-plating.
- Push-me, pull-me negotiation.
- Research-oriented development.
- Silver-bullet syndrome.
- Overestimated savings from new tools or methods.
- Switching tools in the middle of a project.
- Lack of automated source-code control.
No comments:
Post a Comment