|
Rarely has a professional field evolved as rapidly as software
development. The struggle to stay abreast of new technologies, to deal with accumulated
development and maintenance backlogs, and to cope with people issues has become
a treadmill race, as software groups work hard just to stay in place. A key goal
of disciplined software engineering is to avoid the surprises that can occur when
software development goes awry. Software surprises almost always lead to bad news:
canceled projects, late delivery, cost overruns, dissatisfied customers, and unemployment
because of outsourcing. The culture of an organization is a critical success
factor in its efforts to survive, improve, and flourish. A culture based on a
commitment to quality software development and management differentiates a team
that practices excellent software engineering from a gaggle of individual programmers
doing their best to ship code. In a software engineering culture, the focus on
quality is present at all levels—individual, project, and organization. In
this book, I share a cultural framework that was effective in improving the results
obtained by several software groups at Eastman Kodak Company. Most of our projects
involved small teams of one to five developers, with typical durations of six
months to two years. Each part of the book discusses several guiding principles
that shaped the way we chose to create software. I also describe the specific
software engineering practices that we adopted to improve the quality and productivity
of our work. We believe a culture based on these principles and practices has
improved our effectiveness as software engineers, the relationship and reputation
we have with our customers, and our level of collaborative teamwork. Many of the
experiences related and suggestions offered are most relevant to workgroups of
two to ten engineers. Since even large software products are often constructed
by small teams of engineers working together, these technical activities are applicable
in a wide variety of organizations. With this book I hope to reach first-line
software managers, project leaders, and practitioners who wish to drive progress
toward an improved, quality-oriented culture in their organization. My goals are
to provide practical ideas for immediately improving the way a team performs software
engineering, and to show that continuous software process improvement is both
possible and worthwhile. I am assuming that the reader has the ability to actually
change the culture of his software group, or at least to positively influence
those who can drive changes. I present here a tool kit composed of many
ideas and practices for those who wish to improve the quality of the software
they develop, along with case studies of how these methods really worked. Our
groups have applied all the methods described, and I have used nearly all of them
personally. Every anecdote is real, although the names have been changed. While
not every team member has used every good method on every project, we invariably
obtained better results when we applied these solid engineering practices than
when we did not. An organization grows a quality-directed software culture
by blending established approaches from many sources with locally developed solutions
to specialized problems. To help point toward useful sources in the voluminous
software literature, each chapter provides an annotated bibliography of references
and additional reading materials. The references I feel are particularly valuable
are marked with a bookshelf icon. Each chapter contains several "Culture
Builder" tips (marked with a handshake icon), which are things a manager
or project leader can do to promote an attitude and environment that leads to
software engineering excellence. "Culture Killers" are also described,
and are marked with a skull and crossbones warning icon. Culture killers are management
actions that will undermine a team devoted to superior software engineering or
prevent such a culture from developing. Sadly, many of these are real examples.
You can probably think of other culture killers from your own experience, as either
victim or unknowing perpetrator. Although both builders and killers are written
in the form of recommendations, remember that the culture killers are tongue-in-cheek.
Don't rush into work next Monday with an agenda of action items selected from
the culture killers! Some of the experiences of our software groups at Kodak
were published originally in the following articles; material is included here
with permission from the publishers: —Wiegers, Karl E. "Creating
a Software Engineering Culture," Software Development, Vol. 2, No.
7 (July 1994), pp. 59-66. —"Effective Quality Practices in a Small
Software Group," The Software QA Quarterly, Vol. 1, No. 2 (Spring
1994), pp. 14-26. —"Implementing Software Engineering in a Small
Software Group," Computer Language, Vol. 10, No. 6 (June 1993), pp.
55-64. —"Improving Quality Through Software Inspections,"
Software Development, Vol. 3, No. 4 (April 1995), pp. 55-64. —"Lessons
from Software Work Effort Metrics," Software Development, Vol. 2,
No. 10 (October 1994), pp. 36-47. —"In Search of Excellent Requirements,"
Journal of the Quality Assurance Institute, Vol. 9, No. 1 (January 1995),
pp. 23-32. |
