Creating your team project gives you an electronic repository for all your team information. But that is only one piece of the project puzzle. For a project to succeed, you need a project team of dedicated individuals from all aspects of the organization. All team members need to understand their role or roles. They need to be accountable for their actions, but not fearful of that accountability. One way to ensure this is to make sure lines of communication are always open between all team members.
Your project team should not consist of just technical people, such as the developers and testers. To really ensure the success of the project, as well as make the most of Team Foundation Server, you should also include the business users who requested and will be using the finished product, the managers who will oversee the project, and those who will help design and architect the project, to name just a few.
Team Foundation Server provides multiple ways to communicate the project status to everyone on the team. Using the project portal site, team members can stay up-to-date on the latest documentation and project status. Using Team Explorer, they can query Team Foundation Server to return the latest information on bugs, work items, and changes. Using Microsoft Excel they can view different lists of information from Team Foundation Server, as well as update that information. All these options serve to allow the team members to easily communicate with each other, as well as stay up-to-date on the status of the project.
Given this, let's take a brief look at the different roles that are defined in the MSF Agile process.
The MSF Agile Process Model defines six different roles for individuals who are involved with the Team Project. Each role has specific responsibilities, and one person can handle multiple roles, if required.
The following are the six roles, each with a short description of the role and its responsibilities. The following information was taken in part from the MSF Agile Process Guidance information that ships with Visual Studio Team System.
Business Analyst - The Business Analyst role is responsible for defining the business needs of the application. Team members in this role also work with customers to understand their needs and turn those needs into requirements that the developers will use to build the application. They are advocates for the customer, and look out for the customer's needs and interest as related to the project.
Project Manager - The Project Manager is responsible for delivering the project on time and within the defined budget. Project Managers handle the planning and scheduling duties that revolve around the project and monitoring the project status. They interact with Business Analysts, Architects, Developers, and Testers throughout the planning and managing of the project, and help ensure communication between the different roles.
Architect - The Architects are responsible for designing the application, both its organizational and physical structure. They must take into account usability, maintainability, and security, among other things, during the design. The architecture of an application is extremely important, as it can effect how easy an application is to build and maintain.
Developer - The Developers are responsible for building the application within the timeframe established by the Project Managers. In addition, they can contribute their ideas to the design of the application, help with the planning and deployment, and provide technical details as related to the project.
Tester - The Testers are responsible for finding problems with the application and ensuring those problems can be fixed. This does not just mean finding problems with the code. Testers can also find problems in the design or deployment of the project. Once they have found a bug, they need to document its re-creation process, and then ensure the bug has been fixed in later versions of the project.
Release Manager - The Release Managers are responsible for determining when a project is ready for deployment, and for deploying the product. They do this by creating a release plan, and working with the appropriate groups or departments to ensure a successful rollout.
You could have multiple roles involved in a large project. For example, a large project could have several Business Analysts and many Developers and Testers. But, for smaller projects or development shops, you may not need a team large enough to assign each role to a different person. In that instance, you will probably have a person who engages in multiple roles, as defined above.
A Developer might also wear the hat of an Architect or a Release Manager. A Business Analyst might also work as a Tester. There is no right and wrong way ultimately, though MSF Agile does give you some guidelines about which roles should not be combined with others. In the end, you should go with what works best for you and your environment.
For more detailed information on the MSF Agile process, you should visit the MSF for Agile Software Development Web site at http://msdn.microsoft.com/vstudio/teamsystem/msf/msfagile.