Lecture Software Engineering

Lecture Software Engineering

Topics

CHAPTER 04
TEAMS

Team Organization
Democratic Team Approach
Classical Chief Programmer Team Approach
Beyond Chief Programmer and Democratic Teams
Synchronize-and-Stabilize Teams
Teams for Agile Processes
Open-Source Programming Teams
People Capability Maturity Model
Choosing an Appropriate Team Organization

Lecture Software Engineering

Team Organization

Reference

A software project is doomed to failure without competent,

well trained software engineers organized into teams, working
productively in cooperation with one another
Most products are too large to be completed by a single
software professional

Schach, S.R. (2010). Object-Oriented and Classical Software

Engineering, Eighth Edition. McGraw-Hill, ISBN: 978-0-07337618-9.

Software products must be assigned to a team

Programming tasks require interaction among team members
m persons cannot complete the n person-year task in n/m years

Brooks Law

Adding personnel to a late software project makes it even later

After Fred Brooks managing the development of OS/360
Addition of communication channels when adding a new person

Team Organization
Implementation workflow: Prime candidate for task sharing
Two extreme approaches to programming team organization
Democratic teams
Chief programming teams

Figure 4.1

Democratic Team Approach

The basic concept is egoless programming
Programmers can be highly attached to their code

Programmers are not going to try to find faults in their own code

Restructuring of social environment for programming

Programmers encouraged to find faults
A team will develop a group identity

A group of up to 10 egoless programmers

No single leader
Management may have difficulty with such a team

Advantage: Positive attitude toward finding faults

Disadvantage: Senior programmers unhappy with beginners
appraising their code
Must spring up spontaneously and cannot be imposed from
outside

Classical Chief Programmer Team Approach

Two key aspects of chief programming team

Specialization Each member carries out only tasks for which

trained
Hierarchy A chief directing action of all the other members

Reduction in the number of communication channels

Chief programmer
Successful manager and highly skilled programmer
Works on the architectural design
Works on critical or complex sections of code

Back-up programmer

In case needed to replace the chief programmer

Has to be as competent as the chief programmer

Classical Chief Programmer Team Approach

Programming secretary

Highly skilled, central member of the team

Maintains project production library (documentation of project)
Source code listings, test data
Compiles, links, loads, executes, and runs tests programs
Some organizations use the term librarian

Figure 4.3

Classical Chief Programmer Team Approach

Programmers

Do nothing but program

All other aspects are handled by the programming secretary

Impracticalities of Approach

Chief programmers are difficult to find: Skilled programmer and

successful manager
Back-up programmers very rare: Highly skilled, but just a backup
Programming secretary rare: Too much paperwork and software
professionals aversion to do paperwork

Beyond Chief Programmer and Democratic Teams

Scaling up for large projects
Implementation of product under direction of project leader
Programmers report to their team leaders
Team leaders report to project leader
For even larger products, additional levels can be added to
hierarchy
Figure 4.5

Beyond Chief Programmer and Democratic Teams

Chief programmer can be replaced by two individuals
Team leader In charge of the technical aspects
Team manager Responsible for nontechnical managerial
decisions
Figure 4.4

Beyond Chief Programmer and Democratic Teams

Decentralizing decision-making process
Combining best features of democratic and chief programmer
teams
Appropriate whenever a problem requires synergistic effect
of group interaction
New communication channels
Figure 4.6

Synchronize-and-Stabilize Teams
Organization used for synchronize-and-stabilize life-cycle
model
Utilized by Microsoft, Inc.
Builds large products
E.g., Windows 2000
30 millions lines of code
Built by over 3000 programmers and testers
Reusing much of Windows NT 4.0

Team organization vital aspect of construction of such large

projects
Each of three of four sequential builds is constructed by a
number of small parallel teams

Synchronize-and-Stabilize Teams
Very few rules

Developers must adhere to time designated to enter their code

into product database for that days synchronization
If a developers code prevents the product from being compiled:
Problem must be fixed immediately
Rest of the team can test and debug that days work

Cannot turn every organization into Microsoft, Inc.

Organization with highly talented managers and developers

Use of features can lead to process improvement

Suggested by some as a way for a group of hackers to develop
large products

Synchronize-and-Stabilize Teams
Each team

Led by a program manager

Consisting of between three and eight developers
Together with three to eight testers (one-to-one with
developers)

Team provided specifications of its overall task

Individual members are given freedom to design and
implement their portions of that task
It does not devolve into hacker-induced chaos: Because of
synchronization step performed each day
Strengths

Programmers are encouraged to be creative and innovative

Hundreds of developers work together toward a common goal
Without requiring communication and coordination of a chief
programming team

Teams for Agile Processes

All code is implemented by a team of two programmers
sharing a single computer
Pair programmers first draw up test cases, then implement
that piece of code (task)
Programmers do not test their own code
One draws up test cases for a task
Other implements code using those test cases

If one member leaves organization: Other is sufficiently

knowledgeable to continue working on the same task
Enables a less experienced software professional to acquire
skills of more experienced team member
Placement of all computers together in the middle of a large
room promotes group ownership of code: Positive feature of
egoless teams

Teams for Agile Processes

Experiment on pair programming

295 professional programmers

99 individuals and 98 pairs
Hired for a one-day experiment
Several maintenance tasks on two Java software products (one
simple and one complex)
Pair programmers required 84% more effort to perform
correctly

Analysis of 15 published studies

Pair programming effectiveness depends on programmers

expertise and complexity of system and specific tasks

More research needs to be conducted

Open-Source Programming Teams

Surprising that some very successful software products were
developed using open-source life-cycle model

Staffed by teams of unpaid volunteers

Communicate asynchronously (via e-mail)
No team meetings and no managers
No specifications or designs
Documentation is rare

Individuals volunteer for two main reasons

Sheer enjoyment of accomplishing a worthwhile task: Unlikely to

devote considerable time if not truly believing in product
Learning experience: Gaining skills in a technology new to them

Prerequisites for successful open-source development

Key individual behind project must be a superb motivator

Members of core group top-caliber individuals: Finely honed
skills and can thrive in almost any environment

Open-Source Programming Teams

An open-source project succeeds because of
Nature of target product
Personality of instigator
Talents of members of core group

People Capability Maturity Model

People capability maturity model (P-CMM): Best practices for
managing and developing workforce of an organization
An organization progresses through five maturity levels
Each maturity level has its own key process areas (KPAs) and
each needs to be addressed satisfactorily
E.g., KPAs for level 2 (managed level)
Staffing, communication, training, compensation, etc.

E.g., KPAs for level 5 (optimizing level)

Continuous workforce innovation, etc.

P-CMM: A framework for improving an organizations

processes for managing and developing its workforce
No specific approach to team organization is put forward

Choosing an Appropriate Team Organization

No one approach solves problem of team organization
The optimal way depends on
Product to be built
Previous experience with various team structures
Culture of organization

Most teams are currently organized as some variant of chief

programming approach
Not much research on software development team
organization
Not easy to determine the optimal team organization: Until
experimental results on team organization have been obtained

Choosing an Appropriate Team Organization

Figure 4.7