Team Model


Team communication is key to the success of any project. One of the most common logical structures used in an organization is the Hierarchy structure. At the top are the managers and business analysts, followed by your team leads and the team members. Figure 21-8 illustrates the Hierarchy structure.

The problem with this structure is that there is a disconnect between the higher-level management and staff. For example, testers typically have to communicate through their leads to reach the business analyst. This reduces the agility of your team. The MSF Team Model assumes that all members of your team are working as peers toward the same goal, each role is set up as an advocacy group. In effect, you are leveraging the experience and collective mindset of your group. Figure 21-9 shows the structure of the MSF Team Model within the MSF for Agile Software Development process. (The CMMI version doesn't differ very much — it simply adds the user experience advocacy role.)

image from book
Figure 21-8

image from book
Figure 21-9

Note

The MSF Team Model was created as a mix of waterfall and cyclical models. This model isn't just theoretical; it outlines a structure in which you can effectively organize your software team.

Here are the primary outcomes of the Team Model:

  • Accountability: Each member of the team is accountable for his or her actions and the outcome of the project. The effectiveness and quality of a project depends on collective responsibility and communication. This concept is also called the team of peers.

  • Scalability: To solve problems, teams may scale in or out. Teams must refine themselves based on the requirements of the project. MSF calls this "stretch to fit."

  • Advocacy: See the following section for further details.

Important

The Team Model is essentially a risk-management strategy. The formerly named "Role Clusters" are now "Constituencies of Concern" (or Risk). Roles in MSF "advocate" for these constituencies, with a role typically advocating for only one constituency, but often several roles have a responsibility to advocate for the same constituency.

Advocacy

Advocacy provides a balanced view of the project by all members of the software development team and the stakeholders in a project. A strong advocacy within your group will provide a framework that enables you to avoid operational and functional errors, miscalculations, and bad decisions. Each role within your team has a mandate to ensure that your project plans meets practical and functional expectations.

MSF for CMMI Process Improvement includes functional areas within Advocacy Groups by adding managers, auditors, and officers to make it easier to monitor each stage of the development of a project. This process also includes a new advocacy group, User Experience, which accounts for a portion of the training requirement of CMMI — for example, the role of a Technical Writer who can carefully document the product for the end user. There are seven advocacy groups found in MSF for CMMI Process Improvement, as follows:

  • Product managers: The customer wants a software product that effectively solves a problem. The product has to fulfill the customer's needs. Usability is a consideration that all team members have to understand and strive for. The product manager is the advocate in MSF for "Customer Business."

  • Business analyst: This role advocates for the customer. This team member's mandate is to make sure the solution meets the customer's business needs.

  • Program manager: This is an advocate for product delivery. The PM's mandate is to ensure that the software solution is delivered on time and on budget. The customer's needs and expectations have to be met and managed. Program managers in MSF are advocates for the "Solution Delivery."

  • Architects: This advocate is for the solution. The mandate of the architect is to map out the solution infrastructure, interoperation between system components, quality of service, and long- term viability. Architects are the advocates for the "System in the Large."

  • Developers: This role advocates for the most effective technical approach. The mandate for the developer is to design a clean infrastructure, effectively estimate project parameters, and create high-quality code. According to MSF, the developer is the advocate for the "Technical Solution."

  • Testers: These team members are advocates for the customer and the quality of the end product. The mandate of the tester is to report any issues that may affect the customer in terms of quality or usability. MSF calls the tester the advocate for "Solution Quality from the Customer Perspective."

  • User experience: This person is an advocate for the needs of the end users and the usability of a software product. MSF states that the user experience expert is the advocate for "the most effective solution in the eyes of the intended users."

  • Release managers: These team members advocate for the smooth deployment of a solution through any number of delivery channels. The release manager in MSF is the advocate for "the smooth delivery and deployment of the solution into the appropriate infrastructure."

Mindsets

Mindsets enable your team members to deal with situations in a consistent way. They should be enforced early in the project life cycle and maintained right through to completion. Mindsets can help your team members to correctly manage their work and interactions. This part of MSF isn't tool driven — it's behavioral. One of the key concepts of any Agile methodology is that the process should be "people-centric." This part of MSF includes best practices to set up and manage a team on an interpersonal level.



Professional Visual Studio 2005 Team System
Professional Visual Studio 2005 Team System (Programmer to Programmer)
ISBN: 0764584367
EAN: 2147483647
Year: N/A
Pages: 220

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net