System For Delivering Projects

Adapted From Microsoft Development Methods

Goals:

• High quality
• On time
• On budget. May not be the cheapest but meet the budget once given.

Designing Systems for Competitive Advantage 

Eagle CAD Tips And Gotchas

Atmega 128 Highlights

Media Misinformation

Organization

Each software division/project will have

• Program Management – Manages the process of product specification, scheduling, development, testing and documentation
• Development – Software designers develop software prototypes and new features.
• Testing – Software test engineers work with software design engineers (maybe in pairs) to test private releases and final products
• User Education – Prepare manuals and online documentation

Project stages and scheduling

Large projects will be divided into multiple milestone cycles with buffers and no separate product maintenance. For smaller projects only one release might be required. We will follow a pragmatic approach to documents keeping them short and to the point. (Documents, zero bugs etc are discussed in more detail later)

Here is a flow chart of a project with 2 milestone releases.
 

All schedules will be tight. This will keep people focussed and prevent them from relaxing when they figure they have some spare time built. Normally when something is due day after tomorrow and the developer estimates it will take one day, he will postpone all work till tomorrow.

We will use project buffering to keep schedules realistic. The buffers will accommodate unexpected events like some external dependency not working out well or last minute customer requirements change that must be accepted. Based on past experience, we will follow a 1/3 to ½ buffer rule.

Software developers will follow the internal milestone date without the buffer and will be held accountable to that.

Every project will have a short vision document. This will serve to guide decisions on what is important for the project and what is not. If it cannot serve this function then it is not a good vision document. An example of a bad vision document is one that includes every function that is possible.

The specification document will not only be an input to the project but will also be an output. At the start of a project a high level vision statement and outline specification will be written to get the project going rather than trying to write a complete and detailed specification at the outset.

The complete specification will serve not only as a final description of the project but also as a central basis for testing and evaluation.  The program manager will store the specification in an accessible online location and use version control to keep track of successive revisions. Feedback from developers and testers will be used to update the specification. The program manager will also track information necessary to produce the post mortem report.

We will try to use developer based estimation of schedules. In our experience developers are always aggressive and optimistic. It will be the manager’s responsibility to add buffer time for the schedule. This will also give developers more ownership of the schedule. We will initially have to be careful of new developers who try to buy lazy time. Such individuals are unsuited for our organization and should be let go.

Developers should estimate time by breaking tasks to a fine grain schedule. There should be a detailed consideration of tasks to complete. I am not yet sure about the level of granularity required but a good compromise may be 2 hours. Any task that is estimated at more than this it may be that the developer has not thought through it, any task that is estimated at less than this the chances are that the developer has thought too much about it. 

By doing a fine grain schedule we hope to avoid classic problems. For example, ask a developer how long it will take to do something and he will say 2 weeks because 2 weeks represents an infinite amount of time to him. Once you start probing into what will actually happen in 2 weeks both you and the developer realize it will take much longer than two weeks.

Features that provide only a small benefit to users but require a lot of work or lead to inconsistencies will be avoided. Feature selection and prioritisation will be based on customer needs and data. Very often the customer will not know what he really needs and we will have to examine his activities to figure it out.

Early development should concentrate on features that are known to be needed but do not have much of an user interface.

Testing will happen continuously as the product is being developed. A project or product will be considered capable of release when no severe bugs have existed for a definite time period (say a month). For example Microsoft uses a six week period of zero bugs before releasing a product, Mysql uses a six month period before classifying a beta version release worthy.

Each project or software release will have a postmortem report.

An online repository for all project documents will be maintained. It will contain all specification, sample documents, and emails. The documents will be under version control.

For all our projects we will have a common set of development languages, conventions, modules and tools. We will prefer to do all projects using this common set of tools. This common set will be defined taking into account

• module, tool and language capability,
• availability of open source libraries using those tools and
• customer demand

We will attach a price premium to those projects that cause us to deviate from our common toolset.

The most capable developers will have the most difficult tasks assigned to them. The more experienced/talented developers will work on changes that affect many parts of the system. Self contained and simple features will get assigned to junior developers.

Product quality is extremely important. Customers will often tolerate a slightly late release but they will not tolerate releases with bugs, especially bugs that damage their data.

Testing

Testing will be a separate discipline in the company comparable to development. Testing is necessary because:

• Developers do not produce perfect code and program managers do not produce perfect specifications
• People detached from the spec and the code provide an unbiased  perspective on quality
• It is much less expensive and easier to detect and fix bugs early in the development cycle when the pieces of code are less dependent on each other.

Testers will prepare for a project by

• reviewing the post mortem reports of previous projects
• talking with product support personnel

They will:

• Prepare test plans and scenarios
• Write automated test scripts and release them to developers
• Test small releases of developers
• Track bugs
• Do unstructured and stress testing