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.
Timeline |
Activities |
Milestone/Major Review |
Documents
and Activities |
Planning |
|
Milestone 0 |
|
|
|
Vision Statement
Specification Document |
|
Specification Review |
|
|
|
Exploratory Prototypes
Design Feasibility studies
Testing Strategy
Schedule |
|
Schedule Complete |
|
|
Project Review |
|
|
Project Plan Approval |
|
Development Subproject 1 |
- Coding
- Testing and Debugging
- Feature stabilization |
Milestone1 Release |
Implementation Plan |
|
|
|
|
-Integration
-Testing and Debugging |
|
Buffer Time |
|
|
|
Development Subproject 2 |
- Coding
- Testing and Debugging
- Feature stabilization |
Milestone2 Release |
|
|
|
|
|
-Integration
-Testing and Debugging |
|
Buffer Time |
|
|
|
|
|
Visual Freeze |
|
|
|
Feature Complete |
|
|
|
Code Complete |
|
|
|
|
Internal Testing
Buffer Time
Beta Testing
Buffer Time |
|
|
Zero Bug release |
|
|
|
Final Release
|
|
|
|
|
Postmortem Document |
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
|