Datasheet

18
❘
CHAPTER 1 SHIPPING SOFTWARE
expectations. It works closely with the development team to test the product throughout the
developing and stabilizing phases.
Release management — Release management is responsible for the logistics of deploying
the product in a target environment. This often includes writing and testing the installation
instructions to ensure smooth rollout. It also includes working with operations teams to
ensure compliance with local procedures and policies in the target environment. Release
management contributes heavily near the end of a release, but earlier involvement greatly
increases the likelihood of successful deployment.
User experience — The user experience team is responsible for the overall experience
users have with the product. At the software level, it includes visual design, information
architecture, feature usability and discoverability, and the overall look and feel of the
system. In addition to software, the user experience team delivers documentation, help
text, and training. Making this function a peer with other team roles enables these critical
functions to be planned for and budgeted throughout the project.
The Waterfall Method
The Waterfall method is a proven technique for engineering and construction management. It breaks
a project into a series of phases, each one conducted by a specialized team with specifi c outcomes and
deliverables. The term Waterfall refers to the visual structure of a Gantt chart, which is commonly
used for planning. Figure 1 - 2, earlier in this chapter, depicts the waterfall shape of the Gantt chart.
The Waterfall method is very effective under certain circumstances, although it has had limited
success in producing modern software. It ’ s used in situations in which there are well - understood
requirements and the solution uses proven, mature technology. The Waterfall method favors
stability over agility, planning over experimentation, and documentation over discussion. The
following sections discuss these three concepts.
Stability
If system requirements are stable, you can predictably engineer a solution that meets those
requirements. For example, if you ’ re hired to build a bridge across a river, you will be given some
very concrete requirements. You will be told where the bridge should begin and end. You ’ ll be told
the volume and makeup of traffi c it must carry. There are dozens of other requirements, but for the
sake of this example, let ’ s ignore them and assume that they are relatively predictable. With stable
requirements and stable technology, an experienced engineering fi rm should be able to prepare a
reliable estimate for completing the work.
If the requirements are more dynamic, then it becomes increasingly diffi cult to estimate the time and
cost of the project, and the Waterfall method fails. For instance, if you are hired to “ move people
between Boston and Cambridge as effi ciently as possible, ” you cannot predict when you will be
fi nished because you don ’ t yet know if you ’ ll be carrying foot traffi c, cars, or trains and whether one
bridge is more desirable than two. In this case, an experienced engineering fi rm would propose a
discovery phase, possibly for a fi xed price, but could not accurately plan the project further.
With software, customers typically describe the solution they want ( “ move people ” ) rather than the
product they want ( “ a bridge ” ). This makes using the Waterfall method diffi cult because there are
simply too many unknowns at the start of a project.
➤
➤
CH001.indd 18CH001.indd 18 3/23/11 2:47:03 PM3/23/11 2:47:03 PM