This chapter is from the book
This chapter is from the book
This chapter is from the book
Summary
In practice, most software processes require manual enactment, where collecting data and tracking progress are expensive. Up front, such processes need lots of documentation, training, and management, and they have high operating and maintenance costs. Most significantly, the process artifacts and effort do not contribute in any direct way to the delivery of customer value. Project managers can often spend 40 hours a week cutting and pasting to report status.
This constraint has left process as an exercise for managers, specialist Program Management Offices, and skilled practitioners, who sometimes define metrics and activities quite divorced from the interests of the practitioners or the tools used to implement them. The dominant paradigm in this world has been the work-down view, where software engineering is a deterministic exercise, similar to other engineering pursuits.
In contrast, the business forces driving software engineering today require a different paradigm. In keeping with the dictum "As simple as possible, but no simpler," a team today needs to embrace the paradigm of customer value, change, variance, and situationally specific actions as a part of everyday practice. This is equally true whether projects are in-house or outsourced and whether they are local or geographically distributed. Managing such a process usually requires a value-up approach instead.
Typically, the value-up approach requires tooling. Collecting, maintaining, and reporting the data without overhead is simply not practical otherwise. In situations where regulatory compliance and audit are required, the tooling is necessary to provide the change management and audit trails. Team System is designed from the ground up to support the value-up approach in an auditable way. The rest of this book describes the use of Team System to support this paradigm.