Organizational Paradigm for Software Team
Constantine [CON93] is suggests 4 organizational paradigms for the software engineering teams.
1. By the closed paradigm structures a team beside a traditional hierarchy of authority which is similar to a CC team. Many teams can work well when producing software which is quite same to past efforts but they will be less like as to be innovative when working within the closed paradigm.
2. A random paradigm structures a team depends and loosely on the individual initiative of the team members. When innovation /technological breakthrough are needed teams following the random paradigm will excel. But such team's may or struggle when orderly performance is needed.
3. The open paradigm attempts to structure a team in the manner which can achieves some of the controls that are associated with the closed paradigm but also much of the innovation which occurs when using the changing paradigm. Work is performed collaboratively with consensus based decision making and heavy communication. Open paradigm team structures are well known to the solution of complex problems but it will not perform as efficiently as other teams.
4. The synchronous paradigm relies on the natural compartmentalization of a problem and it organizes team members to work on pieces of the problems by little active communication between themselves.
As in the historical footnote the previously software team industries was a controlled centralized (CD) structure generally called the chief programmer team. Harlan Mills was first proposed this structure and it is described by Baker [BAK72]. The nucleus of the team is composed of a senior engineer which is the chief programmer who plans to co ordinates and reviews all technical activities of the team and technical staff (normally 2 to 5 people) who conduct development and analysis activities and a backup engineer who supports the senior engineer in project continuity.
The chief programmer may be served through one or more specialists for example telecommunications expert, database designer, support staff example, technical writers, clerical personal and a software librarian. The librarian gives various performs and teams the following functions controls and maintains all the elements of the software configuration like source listings, documentation, data, magnetic media which helps collect and format software productivity data catalogs and indexes reusable software modules assists the teams in research, document preparation and evolution. The importance of a librarian cannot be overemphasized. The librarian acts as a coordinator, controller and potentially an evaluator of the software configuration. Regardless of Team Company the goal for every project manager is to help develop a team which exhibits cohesiveness. In their book, DeMarco, peopleware, and Lister [DeM87] who discuss this issue:
We tend to use the term team fairly loosely in the business world by calling any group of people assigned to work together as a team. But several of these groups just do not look like teams. They do not have a common definition of any identifiable team spirit or success. What is missing is a phenomenon which we call jells.
A jelled is a group of people which is strongly knit that the whole is greater than the sum of the components... Once a team starts to jell, the probability of success goes way up. The team can become unstoppable and a Juggernaut for success... they do not require to be managed in the traditional way and they certainly do not want to be motivated. They have find momentum.
Lister and DeMarco contend that members of jelled teams will be significantly more motivated and more productive than average. They share a common goal and a common culture, and in various case a sense of eliteness which makes them unique.