Team Communications

Team management is a critical component of successful software development. A dysfunctional team will have dismal productivity, make bad decisions (including delivering a product that disappoints the customer), and generally make the lives of everyone involved miserable. To manage teams, you need to be aware of how people communicate effectively. This may seem obvious, but in fact, many projects fail because an inappropriate communication model is set up by management. Objects facilitate the right amount of communication.

Common Vocabulary, Common Language

In order for people to communicate, it is critical that they have a common vocabulary. It never ceases to amaze me how often arguments can arise from different uses of the same words. This is even more important in software production, where it is not always possible to figure out what words mean based on the way they are used. This is probably a reflection of the newness of the discipline. Concepts are still being formulated, and the words chosen to label these concepts are not always adequate nor consistent. An example is the use of the simple verb form has, as in "Object A has Object B." Sometimes it means ownership from the point of view of object lifespan management. Other times it means one object is contained in the attribute set of another. This can be confusing to team members.

The project manager, therefore, must establish a framework for precise communication, then insist on its use. The implementation of a standard object modeling language is one component of this communications framework. The Unified Modeling Language (UML) is on its way to being adopted by the industry as the standard modeling language. The UML provides a set of static and dynamic diagrams that specify unambiguously the system and its behavior. Further, UML states a precise, clear way to capture and share requirements. As we shall see in Chapter 2 and throughout this book, the UML, if properly used, provides documentation that facilitates communication with the customer as well as among a project's members.

The initial architecture represented by the package diagram serves two purposes:

• To provide the opportunity to establish a common vocabulary.

• To create a visual representation of the common mental model of the system.

I recommend creating individual project glossaries. List the terms that should be used by the team as the project is built and maintained. You will also want to maintain the glossary online as an HTML document for easy accessibility by all team members.

Each package must have a specified function and role, each of their names should be a precise reference to that function; for example, the weather server package in the simulator provides weather data on demand. These names must be written down and adopted and used by the project team when discussing the design, for they form the basis for a common vocabulary that describes the system.

Furthermore, because most software deals with individual fields (banking, business processes, command and control, embedded engine controllers) and therefore have special terminology, such as technical terms, special word usage and abbreviations, it is important that the team have a working familiarity with this vocabulary as well. It is often essential that the team have at least one expert who can define the terms (among other duties).

The Right Amount of Communication

In The Mythical Man-Month, Fred Brooks points out that individual productivity (lines of code per day) declines with an increase in the number of developers on large software projects. As the program grows, the developers must communicate with more and more of their teammates to come to a common solution. They spend more and more time coordinating their efforts and less time writing code. Clearly, a primary focus of the project manager is to manage team communications.

Software project teams carry out the following functions: System specification System design Implementation Test

User documentation and training Maintenance

Configuration management

The project manager needs a way to explicitly manage communications between the people carrying out these functions. One of the challenges is how to partition these functions, create subteams, and manage the communications between the subteams. In this section, I will explore some common approaches. (Specific recommendations are given in Chapter 4, Planning Object-Oriented Projects.) There are three communications models a project manager can use: functional communications, unstructured communications, and the product team model.

FOR FURTHER READING

The entertaining text, Managing a Programming Project by Philip Metzger and John Boddie (Prentice-Hall, 1996), gives an example of a well-articulated view of document-driven functional management.

Previous

Table of Contents

Next

Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.

All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

LOON

® O Q Ö @

SEARCH MV ITKNOWLEDGE FAQ SITEMAP COMTACT LIS

^ SEARCH

ITKHOWLCDGE

Keyword

• Advanced Search

Search Tips

• Advanced Search

Search Tips

tU BROWSE

ÖY TOPIC

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment