Software Engineering
Dr Kingsley Sage
Copyright By PowCoder代写 加微信 powcoder
What is this lecture about? • Not this:
• Working in a team – The issues
– Organization styles – Team structures
• Group work
– Value and challenges
– Notions of group dynamics
What is this lecture about?
• Working in a team – The issues
– Organization styles – Team structures
• Group work
– Value and challenges
– Notions of group dynamics
All highly idealised!
Staff Organization
• As you might expect, there is no “best organisation” for the development of software.
• Many factors come into play: – Personalities
– Individual skills and weaknesses – The nature of the project.
Issues in staff organization
• There are several issues to bear in mind when organizing a software team:
– Accountability: every member of the team should be accountable for their actions – the organization should attempt to minimize the scope for finger-pointing.
– Administrative overhead: some management structures require more administration than others; the costs should always be weighed up against the benefits.
– Morale: developers will not work well if morale is low. Teamwork and individual application are equally important.
Communication paths
• Consider a team of 4 people. The number of communication paths within the team is six: there are six ways of linking one person with another.
• In a team of 8, on the other hand, there are 28 communication paths, and in a team of 16, there are 120 paths. The number of paths increases as the square of the number of people.
• Every path carries an administrative overhead. If all communication is on an individual basis, a lot of effort will be expended in communication.
• One goal of organization is to reduce the number of communication paths by providing fixed channels through which groups can communicate as a whole.
Organization styles
• We consider three distinct styles of organization:
– Democratic decentralized – Controlled decentralized – Controlled centralized
Democratic decentralized
– Structure: The team works as a collection of peers, with no formal leader. Temporary leaders may emerge from time to time as particular areas of expertise are required.
– Benefit: A loose, informal style, which gives developers great freedom, so it is good for projects which require non-trivial research and creativity. The lack of top-level control implies that schedules may slip. There are many communication paths, so this is more suitable for small, tough projects.
Controlled decentralized
– Structure: There is a defined leader who coordinates activity, but problem solving is a group activity. The team leader may partition work among subgroups. There is horizontal communication between the groups, and vertical communication from groups to the leader.
– Benefit: An organization that encourages group work and creativity, but is mildly more rigid. Reliable software can be expected, particularly if the product is obviously modular.
Controlled centralized
– Structure: Everything is managed by the leader. Most essential communication is between individuals and the leader.
– Benefit: This organization has the benefit of great managerial control and little communication overhead. It is therefore suitable for straightforward but large projects.
Broad objectives
• When choosing a staff organisation, it is helpful to consider the broad objective of the project.
• Consider these 3 categories of task: – Open-ended, requiring great creativity – Problem resolution
– Tactical execution
Creativity
• A project whose main objective is creativity involves coming up with a brand new concept or approach. At the start of the project, the requirements are not clear.
– E.g. “develop new ways to develop income streams from mobile apps”
• A free and easy environment in which ideas can be tried and rejected without embarrassment is the ideal, so a democratic decentralized organization may work best.
• Academic research is almost always organized this way.
• Autonomy is the point to be emphasized.
Problem resolution
• A problem resolution project involves attempting to fix a complex and ill-defined problem.
• Problem resolution often requires quick work, but needs a good deal of creativity and research. The team must be pragmatic, trustworthy and focused. The problems to be addressed are often quite small.
– E.g. “fixing a CO2 scrubber problem using anything you can find on a spaceship”
– A controlled decentralized approach might be best.
• Trust between the team members is of foremost importance.
Tactical execution
• A tactical execution project is one in which a concrete plan is ruthlessly driven to conclusion to produce a new piece of software quickly and with minimum fuss.
• Software upgrades are of this kind: some bugs need fixing, some new functions need adding. A to-do list can be formed and items ticked off as they are achieved.
• This kind of project usually has a tight deadline. A controlled centralized organization is in order – the developers just need to get on with their work, with little need for communication.
• Clarity of thought and action is the most important point.
Team structures
• There are many different team structures which can be employed. Often these structures differ only in the attitude which the members are intended to have, rather than the formal chain of command or communication topology.
• We shall consider:
– Business teams
– Chief-Programmer teams – Skunkworks teams
– Features teams
– SWAT teams
– Professional athletic teams – Theatre teams
Business teams
• A business team is a controlled decentralized team.
• A technical lead is appointed to take the major technical decisions. The rest of the team work as a peer group, organized by area of expertise.
• This is a very flexible structure, and therefore quite widely applicable. It does not reduce the communication overhead dramatically.
Chief-programmer teams
• First used by IBM in the 60s and 70s.
• Designed to take advantage of superstar developers.
• The chief programmer model places the superstar at the top of the hierarchy: the chief programmer is fully responsible for the entire project. The rest of the team play supporting roles. Examples of supporting roles include:
– backup programmer: a second-in-command
– administrator: money, equipment, …
– toolsmith: makefiles, macros, building the releases
– language lawyer: an oracle for esoteric features of the language being used
• Much less success for other companies.
Skunkworks teams
• Crazy name, crazy structure.
• Skunkworks teams are unconstrained, unstructured collections of individuals assigned to develop with a completely free hand.
• No quality system! No process!
• No management visibility… Such teams are essentially black boxes from the management point of view. This hands-off approach can lead to very high morale and creativity, but it is hard to monitor and control schedules.
• This is what academia is like 🙂
• One of the more famous:
https://www.lockheedmartin.com/en-us/who-we- are/business-areas/aeronautics/skunkworks/skunk-works- origin-story.html
Feature teams
• The Features Team structure builds on a traditional basic structure of analysis, design, programming and QA groups, organized in hierarchies as usual.
• A collection of Feature Teams is then built by taking one or more members from each group. Each feature team is made fully and solely responsible for a particular chunk of product functionality.
• This is very good for empowerment: each team has all bases covered so can expect their decisions to be taken seriously. For the same reason, it leads to strong accountability: if a feature team does something wrong, there is nobody to point the finger at.
• There is a high communication overhead, because communication must take place between feature teams and within the traditional groups.
SWAT teams
• SWAT teams take their lead from the military “special weapons and tactics” teams. In software engineering, SWAT stands for “skilled with advanced tools”.
• A SWAT team consists of a few developers who all know a particular language, tool or application very well. They may not work full-time as the SWAT team, but are occasionally called upon to develop something in their specialist area in double quick time.
• On a tactical-execution project, a SWAT team may be able to produce solutions very quickly. Creativity is not expected – speed is.
Who decides who takes what role?
• Athleticsteams • Theatre teams
Athletic teams
• This team structure has an analogy with sports teams. A football team has a collection of players with fixed roles: goalkeeper, centre backs, wing backs, midfield players and strikers. It also has a manager whose job is to select the team and coordinate their roles, but not to play football.
• In a tactical-execution project, this kind of team can be set up by choosing developers with strong individual talents and giving them each a specialist role to play. They will not change their role during the project, but will get on with their job until the product is ready.
Theatre teams
• By contrast, in the theatre, actors audition and negotiate for their roles.
• A Theatre Team structure involves several individuals auditioning for a role on the project, which is overseen by a director. The director is responsible for the project’s conceptual integrity, and gives the project its focus.
• The main point which distinguishes such teams from business teams is that here the developers are explicitly encouraged to negotiate (audition) for the role they take, rather than always playing to their strengths. This can be good for morale and interest, but is not so good at exploiting personal expertise.
• Google is said to use auditions.
What is the value of group work anyway?
What is the value of group work anyway?
• Division of labour
• Cooperation
• Mutual learning
• Shared experience
• Social belonging
• Enjoyment
• Creativity
• Interaction
What do you need for group work to be successful?
What do you need for group work to be successful?
Trust / honesty
Mutual respect / Courtesy
Responsibility / Motivation / Commitment Inclusiveness / Recognition of diversity
Group dynamics
Good teamwork makes life easier
• In the long run, a team of mediocre programmers that cooperate well, will beat a team of superstar programmers that don’t get on
• Fighting with team members consumes great amounts of energy, and destroys morale
• Good teamwork doesn’t happen by magic, but requires care and social intelligence
• Social intelligence, like everything else, is learned by practise. Practise takes time
• Teamworking skills help you in all parts of life
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com