Reading Summary - Teamwork + Team Structure + Configuration Management

7

Click here to load reader

description

Teamwork [Mcconnell] Team Structure [Mcconnell] Configuration Management Principles and Practices – [Kirk Kandt] SW Configuration Management in Agile Methods – [Koskela 2003]

Transcript of Reading Summary - Teamwork + Team Structure + Configuration Management

Page 1: Reading Summary - Teamwork + Team Structure + Configuration Management

****** Teamwork [Mcconnell] ********************************************************************

Software uses of Teamwork

• Developing and reviewing the project's requirements • Developing the project's architecture and the design guidelines that will be used by the whole project • Defining aspects of the technical environment that will be used on the project (including the programming languages, compilers, source-code libraries, code generators, editors, and version-control tools) • Developing coding standards that will be used by the whole project

• Coordinating work on related pieces of a project (including defining interfaces between subsystems, modules, and classes) • Designing difficult parts of the system • Reviewing individual developers' designs and code • Debugging difficult parts of the system • Testing of requirements, design, and code • Auditing a project's progress • Maintaining software once it has been built (including responding to maintenance requests and making emergency fixes)

Importance to Rapid Development

Small projects can get away with not addressing teamwork issues, but they will benefit from addressing them. Large projects are group efforts, and characteristics of the groups play an important role in those projects' success, Managers who are concerned about rapid development would be better off to assign developers based on their abilities to contribute to a cohesive team first and only then based on their individual capabilities.

Creating a high performance team

Teams need common, shared vision or goals to help them build trust and keep the team focused. Having agreement on

project vision also help to streamline decision making on smaller issues. To have a motivating effect, the vision also needs to be

elevating. The teams needs to be presented with challenging work. As team members work together toward their common vision,

they begin to feel a sense of team identity. For a team to have a results-driven structure, roles must be clear and everyone must

be accountable for their work at all times; team must have an effective communication system; should have means of monitoring

individual performance and providing feedback; and decisions must be based on facts rather than on subjective opinions. Team

members need to be chosen based on who has the competencies that are currently needed. On an effective team, members have

a mix of skills, play different roles and commit to the team. Team members rely on each other’s individual strengths, they look for

ways to become dependent on other team members. Cohesive teams need to stay in communication with each other constantly.

Effective teams have the sense that they are free to do whatever is necessary without interference, having sense of autonomy.

They also need to feel empowered to take whatever actions are needed to succeed. Regarding the team’s size, if the project requires

more than 10 members, if should be broken into multiple teams. For single-project teams, if it can stay together across several

projects, it can expand the size as long as the team shared a deep-rooted culture. Most productive teams are enjoyable, people like

to be productive, they naturally spend more time doing things that they enjoy and what makes a team jell is adopting a group sense

of humor. A cohesive team creates an “us” and the manager is in the sticky position of being not completely “us” and not completely

“them”.

Why teams fail

• Lack of common vision • Lack of identity • Lack of recognition • Productivity roadblocks

• Ineffective communication • Lack of trust • Problem personnel

Long term teambuilding

Reasons to keep teams together permanently:

Higher productivity

Lower startup costs

Lower risk of personnel problems

Less turnover

Idleness question

Page 2: Reading Summary - Teamwork + Team Structure + Configuration Management

****** Team Structure [Mcconnell] *******************************************************************

Consideration in organizing a team is to determine the team’s broad objective. According to Larson & LaFasto: Problem

resolution, Creativity and Tactical execution. The structure that’s more appropriate depends on the team’s objective. The

characteristic that is most important for the kind of team should be emphasized: for problem resolution team, emphasize trust; for

creativity team, emphasize autonomy; and for tactical-execution team, emphasize clarity.

Additional Team-Design features are:

Clear roles and accountabilities

Monitoring individual performance and providing feedback

Effective communication

Fact-based decision making

*There’s no such thing as a single best ‘rapid-development team structure’ because the most effective structure depends on the

context.

Team models

Business team: Composed of a tech lead and other equal developers.

Chief-programmer team: is organized around chief programmer who is an expert programmer. The other team members have

other, specialized roles, such as librarian, which support the chief programmer in his primary task of designing and coding the sw.

Skunkworks team: group of talented, creative product developers, working in a facility freed of organization’s normal bureaucratic

restrictions, turns them on the loose to develop and innovate.

Feature team: Small, dynamically formed team that develops a small activity. Multiple minds are always applied to each design

decision and also multiple design options are always evaluated before one is chosen

Search-and-Rescue team: focused on solving a specific problem.

Swat team: each member is highly skilled with a particular tool or practice, trains extensively to be prepared when crisis hits they

can work as a unit.

Professional athletic team: carefully selected people w/very specialized roles

Theater team: “director” assigns roles to others

*Large teams pose special problems of communication and coordination.

Managers and technical leads

Technical lead is responsible for the technical work and for a single team. The manager is responsible for the

nontechnical direction of the team and responsible for 2 or more projects.

******** Configuration Management Principles and Practices – [Kirk Kandt] **************************

A CMS includes a set of policies, practices, and tools that help and organization maintain software configurations. Its primary purpose is to maintain the integrity of the sw artifacts of an organization. * is the discipline of controlling the evolution of complex systems

Principles • Protect critical data and other resources • Monitor and control sw development procedures and processes • Automate processes and procedures when cost effective • Provide value to customers • Sw artifacts should have high quality

• Sw systems should be reliable • Assure that products provide only necessary features, or those having high value • Sw systems should be maintainable • Use critical resources efficiently • Minimize development effort

Page 3: Reading Summary - Teamwork + Team Structure + Configuration Management

Practices. They support the previous ten principles. Management Practices • Maintain a unique read-only copy of each release • Control the creation, modification, and deletion of sw artifacts following a defined procedure • Create a formal approval process for requesting and approving changes

• Use change packages • Use shared build processes and tools • A version manifest should describe each sw release • Segregate derived artifacts from source artifacts

Quality Practices • All artifacts should be under configuration control • Use a change control board • Build sw on a regular, preferably daily, basis, followed by immediate invocations of regression test suites • Document identified sw defects

• Sw artifacts that comprise a release should adhere to defined acceptance criteria • Each sw release should be regression tested before the test organization receives it • Apply defect repairs to every applicable release or ongoing development effort

Protection Practices • Use a software system to perform configuration management functions • Repositories should exist on reliable physical storage elements

•Configuration management repositories should be periodically backed-up to non-volatile storage and purged of redundant or useless information • Test and confirm the backup process

Tools Practices • Check code in often • Configuration management tools should provide patch utilities • Do not work outside of managed workspace

• Do not share workspaces • When developing sw on a branch other than the primary development branch, regularly synchronize development with the development branch.

Capabilities. Used to analyze and compare various products Version Control >> maintain a collection of versioned artifacts. Configuration Control >> maintain collections of aggregated artifacts that form larger systems and subsystems. Model Control >> Provide a domain model for sw artifacts. Build Control >> construct derived artifacts from source artifacts Change Control > handle all types of change requests and monitor them to closure. Deployment Control >> automatically deploy sw to customers or notify them when appropriate releases are available for deploymentProcess Control >> automate the workflow of the sw development process and to ensure that practitioners of an organization follow the desired software process Security Control >> ensure that users of the configuration management tool perform the operations that they have been granted and no more User Interface Control >> provide a Graphical User Interface (GUI) to users that enhance their productivity and overall experience

Page 4: Reading Summary - Teamwork + Team Structure + Configuration Management

****** SW Configuration Management in Agile Methods – [Koskela 2003] ************************* Software configuration management (SCM) is a method of controlling the software development and modifications of software systems and products during their entire life cycle. Agile methods focus on generating early releases of working products and on delivering business value immediately from the beginning of a project. SCM differs from general CM: First, software is easier and faster to change than hardware, and second, SCM can potentially be more automated.

Configuration identification is a process where a system is divided into uniquely identifiable components, called configuration items, it consists of selecting the CI’s and recording their functional and physical characteristics and technical documentation. Examples of CIs are project plan, specifications, design documents, source codes, test plans, test data, executables, tools and SCM plan. Per configuration phase, a project baseline is a document that has been formally reviewed and serves as basis for further development.

Configuration control > after the configuration items of the system have been identified, the control of the changes comes to place. Baseline have important role in managing change. They can only be changed going through formal change control procedures as the ones in the following image. A change request can results from new features or enhancements.

Configuration status accounting consists of recording and reporting the information needed to manage a configuration effectively, including a listing of approved configuration identification, the status of proposed changes to the configuration and implementation status of approved changes. The purpose of Configuration audits is to ensure that the software product has been built according to specified requirements, to determine whether all the items identified as a part of CI are present in the product baseline, and whether defined SCM activities are being properly applied and controlled. A representative from management, the QA department, or the customer usually performs such audits.

Page 5: Reading Summary - Teamwork + Team Structure + Configuration Management

The main purpose of the SCM plan is to answer questions as: who is going to do that, when, where, and how. It serves as a guideline Automating manual SCM tasks provides more time to do the actual development work, leading to improved speed and productivity. SCM common tools: Version Control (manage different versions of congifuration objects that are created during the sw eng process); Workspace management (prevent users from interfering with one another’s work); Concurrency control (files are not locked when checking them out, and there may be simultaneous modifications to the same files by multiple users, a locking mechanism comes into use); System building (combine needed file versions and compile them to create the app); Press control and support (mechanism to help reality conform to the model).

Page 6: Reading Summary - Teamwork + Team Structure + Configuration Management

In agile methods, working software is delivered early and often. It is valued more than comprehensive documentation, and therefore documentation can be added later when there is time.

1. Adaptive Software Development Offers an agile and adaptive approach to high-speed and high-change software projects. It encourages incremental, iterative development, with constant prototyping. Lifecycle used is a dynamic speculate-collaborate-learn lifecycle. Disadvantage > ASDs practices are difficult to identify because of continuous adaptation.

2. Agile Modeling Practice-based methodology for effective modeling and documentation of software-based systems. It is not a complete software process, the focus is primarily on effective modeling and documentation.

3. Crystal Family Methodologies Focuses on individuals’ talents and emphasizes that every team should utilize a process uniquely tailored to itself. Process and tools are secondary. Based on 2 rules: incremental development and self-adaptation.

4. Dynamic Systems Development Method It is a framework of controls supplemented by guidance on how to apply those controls. Provides a user-centred, iterative and incremental way of developing applications systems that serves the needs of the business.

5. Extreme Programming For teams developing software subject to rapidly changing requirements. It is characterized by short development cycles, incremental planning, continuous feedback, reliance on communication, and evolutionary design.

6. Feature Driven Development Focused on delivering frequent, tangible, and working results. Doesn’t cover the entire sw dev process, it rather focuses on the design and building phases.

7. Internet-Speed Development Focused on moving the product quickly to market. The quality depends on how important it is to customers and how good the devs are.

Page 7: Reading Summary - Teamwork + Team Structure + Configuration Management

8. Pragmatic Programming Set of programming best practices. It does not include process, phases, distinct roles or work products, It contains tips that cover most programming practicalities.

9. Scrum Management and control process that focuses on building software that meets business needs. Teams are fully autonomous and guided by their knowledge and experience, rather than formerly defined project plans. Leaves the power of decision to the devs.