RSS
Логотип
Баннер в шапке 1
Баннер в шапке 2

Microsoft Solution Framework Team Model

Product
Developers: Microsoft

[[The methodology of software development of Microsoft Solution Framework appeared in 1994. In fundamentals of methodology of MSF the accumulated experience of Microsoft company in the field of human resources management and workflows is put during development of software solutions. This knowledge is based on experience of Microsoft company over large projects on development and support of the software and also other experience of the IT industry.|The methodology of software development of Microsoft Solution Framework appeared in 1994. In fundamentals of methodology of MSF the accumulated experience of Microsoft company in the field of human resources management and workflows is put during development of software solutions. This knowledge is based on experience of Microsoft company over large projects on development and support of the software and also other experience of the IT industry.]]

The basis of methodology is formed by models and disciplines.

Models:

  • model of a project team;
  • model of processes.

Disciplines:

  • discipline of project management;
  • discipline of risk management;
  • discipline of management of preparation.

In the context of subject of this article we will not consider discipline, and we will concentrate attention on application of model of a project team by small development teams.

The model of project team MSF (MSF Team Model) describes approach Microsoft to the organization of the personnel working on the project and its activity for the purpose of maximizing success of the project. This model defines role clusters, their competences and areas of responsibility and also the recommendations to members of a project team allowing them to perform successfully the mission for the embodiment of the project in life. According to the MSF model project teams are under construction as small multi-profile commands which members distribute among themselves responsibility and supplement areas of competences of each other. It gives the chance to accurately focus attention on needs of the project. The project team is rallied by uniform vision of the project, aspiration to its embodiment in life, high quality requirements of work and desire to self-improve.

The project team includes the following role clusters (fig. 1):

  • Product Management. The key purpose of this role cluster - happy customers. The project cannot be considered as successful if it did not lead to satisfaction of needs of the customer. The situation when the project team met the budget and terms is possible, but success was not achieved as business needs of the customer were not satisfied.
  • Program Management. The main objective of this role cluster - to provide implementation of the solution within restrictions of the project. The schedule of the project, volume of work and the budget which is taken away on the project are for this purpose controlled. The considered cluster provides timely achievement of required results and satisfaction of expectations of the sponsor throughout the project.

In the version of MSF 4 the cluster Management of architecture which means the organization and accomplishment of high-level design of the solution, creation of the functional specification software and management of this specification in development process, determination of a framework of the project and key compromise solutions was brought out of this role cluster.

  • Development. Development is a paramount problem of a role cluster creation of the solution according to the specification. Its accomplishment means creation of the solution meeting the expectations of the customer and conditions formulated in the functional specification. Also this role cluster strictly follows the developed architecture and design of the solution which together with the functional specification are the summary description of an end product.
  • Test. A problem of this role cluster - product output approval only after all defects are revealed and settled. Any software contains defects. But it is necessary to detect and settle everything from them before the product is released. Settling of defect can mean different solutions, beginning from elimination and finishing with documentation of methods of a bypass of defect. Delivery of a product with the known defect, but with the description of methods of its bypass is more preferable, than delivery of a product with undetected defect.
  • Satisfaction of the consumer (User Experience). The purpose of this role cluster - increase in efficiency of use of a product.
  • Management of release (Release Management). The purpose of this role cluster - free implementation and maintenance of a product. This role serves as a link between a project team and groups of processes of maintenance.

File:Microsoft Solution Framework 01.jpg

Fig. 1. Role clusters of methodology of MSF

Existence of the listed role clusters does not mean that the command should consist strictly of the same number of participants. One employee quite can integrate several roles, however at the same time some roles are not recommended to be integrated, and to integrate some roles in general inadmissibly. The matrix of compatibility of role clusters is presented in table 1.

Table 1. Matrix of compatibility of role clusters of MSF.

File:Microsoft Solution Framework 02.jpg

Д - it is admissible, N - it is inadmissible, N/Zh - is not desirable

Analyzing this matrix it is possible to draw the following conclusions:

  • It is inadmissible to combine role clusters of product management and program management.
  • The role cluster Development cannot be combined with one other role cluster.
  • Combination of other clusters are admissible, but parts of them - are undesirable.

For example, product management and program management have the interests contradicting each other and, therefore, should not integrate. Management of a product aims to satisfy the customer while management of the program provides readiness of a product in the allowed time and within the available budget. In case of a combination of these roles there is a risk that the change requested by the customer or will not be considered with due attention, or it will be accepted without proper analysis of its influence on the project. Representation of these roles by different people in a project team provides balance of two contradicting points of view. The same treats attempt of consolidation of roles of development and testing.

Thus, the minimum collective applying methodology of MSF can consist only of three people who will combine role clusters as follows (fig. 2):

  • Satisfaction of the consumer, Product management, Testing.
  • Program management, Management of release.
  • Development.

File:Microsoft Solution Framework 03.jpg

Fig. 2. Combination of role clusters in the minimum development team.

Let's note that such cast on a matrix is admissible without restrictions, and two main restrictions are observed: the role of the developer is not combined with one other role; also there is no combination of the roles having the predetermined conflicts of interest. Also it should be noted the recommendation Microsoft regarding combination of roles: when the project team consists of six or smaller number of the participants executing all project roles - activities for project management are exercised of a role cluster Program management.

If increase in number of project participants is necessary (from 10 and more), Microsoft offers splitting big commands for small groups of the directions (feature teams). Such groups work in parallel, with permanent synchronization of results of work. Thus, there is a flexible scaling of model of a project team. The example of option of scaling is given in fig. 3.

File:Microsoft Solution Framework 04.jpg

Fig. 3. Scaling of a project team (option).

As a final output to article it is possible to cite Steve C McConnell words: "Even in the presence of the qualified, motivated and hardworking people the incorrect structure of a command is capable to nullify their efforts instead of resulting them in success. The weak structure of a command can cause increase in time of development, decline in quality, lowering of moral spirit, increase in a staff turnover and, finally, to lead to a project failure".

Thus, the competent organization of structure of a command implementing the basic principles of methodology of MSF will be a basis of a project success and will allow to make project teams more effective and successful.