Microsoft's secret: Introduction to Microsoft's Software Development Model

Microsoft's secret: Introduction to Microsoft's Software Development Model

2006.06.02

Introduction to the software development model of Microsoft
The book "Microsoft's secrets" published by Peking University press at the end of 96 is the most professional and in-depth book I have ever seen about the software product development process of Microsoft. Through this book, we can see how Microsoft manages software product development in an effective way scientifically. I think these experiences are useful to a wide range of software developers in China, especially those who are concerned about the development of China's software industry are of great benefit. Therefore, I have extracted some of the content in this book that involves software product development (chapter 4 "product definition and development process") and summarized this article with my practical experience in Microsoft's China, I hope to share it with you. As an excerpt from this article, it is natural to miss a thousand lines. Therefore, we suggest you read the original book if you have time.

In Microsoft's product definition and development process, Microsoft software development follows a strategy that can be called "stimulating creativity by improving features and fixed resources. The strategy can be divided into five principles:

Major projects are divided into several important phases of the milestone (milestone). There is a buffer time between stages, but no separate product maintenance is performed.

Use the imaginary description and program specification to guide the project.

Determine the product features and their priority based on user behavior and relevant user information.

Establish a modular and horizontal design structure, and make the project structure reflect the characteristics of the product structure.

Control by individuals and fixed project resources.

Principle 1: major projects are divided into several milestone important stages. There is a buffer time between stages, but there is no separate product maintenance.

Project schedule and milestones

Microsoft usually adopts the "synchronization-stable product development method ". The life cycle of a typical project consists of three phases:

Planning phase: Completion of Function Description and final preparation of the Schedule

Development Phase: Write complete source code

Stabilization phase: completes the product to enable batch production (roll out)

These three phases and the internal cycle methods are different from the traditional water fall development method, the latter is composed of requirements, detailed design, modular code design and testing, integration testing, and system testing. Microsoft's three stages are more like a risk-driven, progressive "Spiral" life cycle model.

The products in the planning stage are imaginative descriptions and instructions to explain what the project will do and how it will do. Before the management personnel draw up the schedule and the developer writes the Code, these things promote people's thinking and Discussion on Design Issues. The development phase focuses on three major internal product releases; the stabilization phase focuses on extensive internal and external tests.

Throughout the product production cycle, Microsoft uses the concept of buffer time. The buffer time enables the development team to deal with unexpected difficulties and changes that affect the time schedule. It also provides a means to ease the conflict between timely delivery and an attempt to accurately estimate the delivery time.

During all the time of the development and stabilization phases, a project usually uses 2/3 of the time for development and 1/3 of the time for stabilization. (The vice president of the Office department once outlined the general progress as follows: "In general, in the overall schedule, the product is written in half the time, leaving the other half time for debugging or dealing with accidents. In this way, if I have a two-year project, I will use one year to complete the first thought ...... If things are a little troublesome, I will remove the features that I think are not very important ."). This milestone work process allows Microsoft managers to clearly understand what the product development process has taken, it also enables them to flexibly delete some product features in the later stages of development to meet the requirements of the delivery period.

PLANNING PHASE

The planning phase refers to the time used by all the plans prior to development in the life cycle of a project. The planning stage produces an imaginary description, marketing plan, design goal, an initial product description, interface standards specified for integrating components developed by other groups, initial test plan, one document Plan (printed documents and online help form) and a list of availability issues (usability list ). The planning phase begins with an imaginary description. The imaginary description comes from the product manager and the program manager of each product unit. It is a marketing idea for the planning product, including analysis of competitor products and planning for future versions. Imaginary descriptions may also discuss issues that must be addressed in the previous version and the main features to be added. All of these are based on the analysis of customers and markets and the information obtained from the Product Support Service Group.

The description file starts with an outline, defines new or added product features, and assigns different priorities to them. The description file is only a preliminary overview of product features. It will increase or change 20%-30% from development to project completion. Although the change is generally small in the later stages of the lifecycle, the more late the change, the more reason the developer must make the change.

Generally, the program manager uses VB to create a project prototype. They also carried out design feasibility studies to understand the trade-offs in the design and make decisions involving product descriptions as soon as possible. Instructions on important products should be reviewed by the company's senior leadership. For less important products, some managers should complete them.

Development Phase

The plan in the development phase allocates a set of features to three or four major milestone versions one by one, specifying feature details and technical relevance, record the tasks of the single developer and the estimation of the progress. In the development phase, the developer writes the source code under the guidance of the functional description, and the tester writes the test project team to check whether the product features and work scope are normal. User Education) compile the draft document.

When a tester finds an error, the developer does not wait for further processing, but immediately corrects the error and continuously and automatically performs the test throughout the development phase. This improves product stability and makes it easier to estimate the release date. After reaching a certain stage of the project (40%), the developer tries to "Lock" the main functional requirements or features of the product, and then only small changes are allowed. If developers want to make major changes after this point, they must discuss and negotiate with the program manager and the Development Manager, and may also ask the product department manager for advice.

A project is organized around three or four major internal versions, or "milestone sub-projects. Generally, two to four months are used to develop each major milestone version. Each version includes its own encoding, optimization, testing, and debugging activities. The project retains 1/3 of the total development time for accidents, namely, the "buffer time" (padding time ). (Apple's team is isolated and independent, and they develop their own things. It will only take three months to integrate all the things. Borland will perform development in an incremental way, that is, dividing the work into many small parts, and always make development work. It seems that this gradual method is time-consuming, but it is almost never used for a long time, because it allows you to always grasp the real situation .)

After the last major milestone version is tested and stabilized, the product requires "UI freeze" to determine the main user interface of the product, such as menus, dialogs, and file windows. After that, the user interface will not be significantly changed, so as to avoid the difficulty of synchronizing and modifying the relevant documents.

Stabilization phase

The stabilization phase focuses on product testing and debugging. At this stage, the project should try not to add new functions unless it is a competitor or a change in the market. The stabilization phase also includes buffer time to cope with unforeseen problems or delays.

I will describe the Micosoft software development model in the following diagram: (this diagram describes Microsoft's testing in detail, I personally think that Microsoft testing is a very important and distinctive division of labor in Microsoft software product development. I have come to this conclusion by observing Microsoft for nearly a year and analyzing similar enterprises in China. We all know that software developers in China are not doing enough in this regard, and especially do not pay attention to internal software testing. In their thinking, there may be a misunderstanding: users are responsible for testing. In fact, in the software development process, software testing and development are a "spear and shield" relationship that complements each other, indispensable. At Microsoft, this kind of relationship may reach the extreme: Sometimes the Development Department and the Test Department work hard, and the Development Manager and test Manager are in the same position, sometimes even test managers are superior to development managers, but there is no fundamental conflict of interests between them. There is only one common goal: to improve the quality of products .)

One more point: (a brief description of Microsoft's testing process) within Microsoft, there is a dedicated team responsible for providing tools and software for Microsoft engineers for their daily work and management, they are non-profit organizations, and their main task is to develop the tools and software required by Microsoft:

For example, SLM (source library tree), source code management tool, responsible for managing the source code of Each programmer in the software development process, each programmer is responsible for writing their own modules, check-in code is sent to the SLM tree of a central server every day. This SLM tree is compiled by a pre-defined script at a fixed time. Generally, this process takes several hours, therefore, Microsoft has its own rules based on the situation of various project teams. For example, developers must check-in the modified Code before getting off work (such as PM, in this way, SLM compilation starts.

The next day, the testers In the QA Team downloaded a build from the server and started the test the previous day. The test results were promptly reflected in another tool software: RAID (raid is a tool for entering, tracking, analyzing, and reporting product defects during development and maintenance .). This tool is responsible for managing product bugs. Each bug contains many attributes, such as status (active, resolved, and closed), severity level, priority, region, version, discoverer, and developer to which the bug is assigned. You can also use this tool to query the basic product quality of the developer's bug activities, the number of solutions, and the number of bug quality of the tester, in this way, the Project Manager can easily grasp the specific progress of the project. If the number of bugs found during the development stage of the project is more than the number of bugs solved (meaning that the product has more and more bugs), it may mean that the project has encountered problems, policy makers can quickly make appropriate decisions and promptly correct product development errors (many products have been canceled by Microsoft due to such factors ). It is also important for the project manager to keep abreast of the working status of each tester and developer based on this tool. Many people have said that Microsoft has defeated countless competitors by virtue of SLM and raid. Through my experience at Microsoft, I think this is true.

These two tools are indeed very outstanding tools. Microsoft uses them to a very artistic level and plays a very important role in Microsoft's success. What's even more valuable is that these tools are constantly being improved and upgraded in terms of functions, making Microsoft's engineers even more powerful in their work, how can such an enterprise fail?

In the testing process, it is not a random use of software products without any purpose. Microsoft also has a set of very advanced methods and tools to support every aspect of the testing: for example, ATCM (access Test Case Management) is a test case-based test management tool.

Microsoft may rely on "the cleverness of programmers and the diligence of testers" to build the building of the software empire and write the brilliant career of software.

Padding time in the project schedule)

Microsoft uses the buffer plan to strike a balance between the highest efficiency and better predictions for the future. The time to cope with such emergencies is part of every major milestone in the development and stabilization processes. Buffer time is mainly used to make up for vulnerabilities that are caused by incomplete understanding of features, technical difficulties, neglect of writing tasks, or unexpected difficulties. The buffer time helps a project adapt to unexpected events.

Principle 2: guiding the project by Using Imaginary descriptions and brief descriptions of features

In order to provide sufficient development frameworks for continuous work, and to accommodate changes in the development process and maintain sufficient flexibility, microsoft uses imaginative descriptions and summary descriptions to guide project development, rather than writing a complete and detailed description at the beginning. The so-called imaginary description is a very short document jointly prepared by the program manager and product planners from the Marketing Group, in this section, we mainly define the product development goal (no specific product details are involved !). Generally, an imaginary description of a brand-new product is relatively detailed and contains a rough description file. In general, Microsoft's requirements for imaginative descriptions are:

The shorter the product, the better. Try to describe what the product does (rather than what the product does !).

Using Imaginary descriptions, the program manager starts to write a functional instruction file that explains what features of the product are and how these features are related to other features and products. At first, it was just an overview document. As the project progresses, the program manager will add more details to it at any time, and the final description file will become the same as the user manual.

The complete description not only describes the latest features of the product, but also serves as the basis for testing and evaluating the product before it is put into operation and delivery.

Imaginary descriptions help determine which features to delete.

Various Microsoft development teams use imaginary descriptions to help refine the defined themes of product versions, and then decide whether to add various possible features of the product. Do not change the subject easily. Otherwise, it may cause confusion in product development.

Write instructions

The description document serves to convey product ideas and requirements among all members of the product team, between product teams, and between product teams and management departments. The description file must clearly describe product features (describe how each feature works, how it looks and how it interacts with the user from the user's perspective. If a feature has an interface, it should also contain a interface to display the effect of the Interface), and assign it to the corresponding priority. The program manager establishes a project development schedule accordingly. In addition, it should include the following items: project development purpose expressed in one sentence, list of what the product is and what it is, definition of the customer, and definition of competing products, product requirements for the system (including the operating system version, Minimum Memory Requirements, hard disk space, processor speed and display resolution), any dependence on third parties (such as printer drivers, components. The program manager is responsible for coordinating and writing down instructions

The program manager should consider the following issues:

What are the key points of this feature?

How do users use this feature?

Does this feature make sense?

Are similar features in this product or other Microsoft products?

What problems have been missed?

Is the communication in the group satisfactory?

Finally, the program manager decides the content of the feature through a joint discussion with the developers in the group and writes it down.

Build a prototype

Prototype construction is the best way for the program manager to specify a new product or a new version, which makes pre-development testing possible in many ways, especially in terms of availability, it also helps to make a good understanding of the interaction with the user, it can also make the product description more compact.

Microsoft developers usually use VB to construct a user interface prototype. However, painting brush is also a useful tool for building computer screen models. The rigid description becomes a biological document, and the description should not be too detailed to limit the invention and creation. During project development, it indicates that the earlier versions of the file will be greatly increased and changed. Because the changes described may lead to significant changes in the corresponding development work, Microsoft usually focuses on the features that do not have any user interfaces, this is because you do not have to know how users respond to them before you complete development. That is to say, these features are unlikely to change. And then other features. However, after a product is developed into a certain program, for example, after 40%, the program manager must strictly control the modification to the feature (mainly to add new features), otherwise it will not only cause development delay, it also compresses the available test time.

Principle 3: Determine product features and their priorities based on user behaviors and relevant user information

It is usually difficult for a development project to determine what features should be included in the final product. For this reason, Microsoft adopted a behavior-based plan method to select features and arrange priorities.

The behavior-based planning method begins with systematic research on user behavior, such as writing letters or budgeting. Then, evaluate a Feature Based on programs that support important or frequent user behaviors. The advantage of doing so is to make a more rational choice of features: to discuss what the customer wants to make better arrangements, and to determine whether a given feature facilitates a more concentrated debate on specific tasks, more readable description, and better synchronization in marketing, user education, and product development.

Behavior-based plan in Feature Selection and priority arrangement

The key aspect of behavior-based planning is to analyze products based on the internal relationships between user behaviors, product features, and behaviors and features. Program Managers and product planners divide the user tasks or schemes the product tries to support into about 20 "actions", and then they try to divide the actions (and any sub-Actions) it is mapped to the current features of Microsoft and the features of competitor products. They also map behaviors to different customer images or different market segments.

When describing a new version of a product, action-based planning helps program managers and developers concentrate on their energy and creativity. For projects such as Excel, we strive to add up to four major actions in each new version. Most features are directly mapped to these actions. This method enables the project to classify user values based on features. By classification, program managers and developers are encouraged to take actions to support as many behaviors as possible. This benign competition is beneficial to users and increases productivity.

Prepare materials for customer behaviors rather than product features

Based on the action to develop the plan progress, the project first focuses on the behavior in the plan phase, and the second is the feature. Program Managers and marketing personnel do not think about and exclude their favorite features, and then draft imaginary descriptions around them. What they really do is to list what a customer does, and then concentrate their imaginary descriptions on the features that support those behaviors.

Behavior-centric comprehensive consideration of Products

Because the behavior-based planning method focuses on the entire product, it helps project members who work in different functions understand what the product is doing, and how the corresponding features of other products can support behaviors that require or do not require other application software products.

Conduct marketing research to support behavior-based planning

In order to support behavior-based planning, product managers from marketing groups, program managers and developers, should work together to conduct some joint research, for example, to guide the user's research work. However, in general, product managers do most of the research and can make it more clearly affect the evolution of Microsoft products.

Principle 4: Establish a modular and horizontal design structure, and make the project structure reflect the characteristics of the product structure

A key concept in Microsoft's product design is the product infrastructure. Especially for applications with short lifecycles, the infrastructure should be simpler (rather than more complex) as the project progresses ). When developers construct the first version of a product, they use more hierarchical structures to define an initial architecture for product design. Over time, they moved towards a single structure so that the project can focus on feature development. Microsoft is increasingly emphasizing feature sharing between different products. Sharing helps to unify the performance and feeling of different products. It also facilitates users who need more than one application software and reduces repeated code writing, reduces the size of a single application.

Microsoft uses a feature Group to organize product development. This method makes it easy for everyone to understand how the group is associated with the entire product. The project starts with the summary of the provision. The summary is in the form of a list of content that has been prioritized, involving the relatively independent features to be developed in the next version of the product for development by separate feature groups.

Program Managers and developers divide projects into feature subsets and allocate them to each feature group for production in 3 to 4 major internal project milestones. This product organization and development method enables Microsoft to gradually add product functions by simply adding developers and creating a large group.

Use features (and functions) as the Development Unit

The features of Microsoft software products are relatively independent functional units ultimately visible to users, such as building materials, especially for application software products. System software products, such as the features of NT or 95, are not directly visible to end users. Microsoft and other companies sometimes simply call these invisible features as "functions ".

The program manager is responsible for developing a set of features or functions to implement the process from being tested, documented, and finally completed. They must work with developers who are responsible for estimating the schedule and improving each feature. Developers also need to store one or more files on a networked development computer to save the source code of the feature program. Only one developer is needed for the development and improvement of most features, while some large features require a small group.

The product structure is the cornerstone of its long-term structural integrity.

The product structure is the basis of the product. It specifies important structural components and how these components are assembled together. The product structure and components used to assemble the structure provide the pillar for implementing product features (that is, detailed design and coding. The product structure is usually not directly visible to end users. Only the features to be implemented by the structure are visible. The product structure is also the cornerstone of the long-term structural integrity of the product. Any changes to product functions should not lead to potential dismounting of product structures.

Product hierarchy

You can also use a hierarchical structure for product analysis. Generally, well-defined hierarchies help to flexibly add, delete, and improve product features. In addition, a good hierarchy helps to port products on different platforms. (For example, Excel defines a total of five layers. Only the underlying operating system layer is related to the platform, and other layers are implemented by calling the API interfaces provided by the lower layer, therefore, it is extremely convenient to transplant. In Windows 95, the concept of "Virtual Machine" is used to support 16-bit, 32-bit, and DOS programs .)

Small structure document: the source code is a unique file

In addition to API documentation, Microsoft does not generate relevant documentation for its product structure, although sometimes senior developers may write down high-level structures. For complex features, many developers record and review the structure details specific to them at certain points, but this is optional and is not enforced. In addition to source code files and features, a few groups of new programmers outline documents describing a certain layer of structure (the main data structure, how to work, etc ). However, these files are not updated frequently, and managers do not require the project team to generate such internal documents. Implementation issues are not involved in the relevant instruction files. Developers should know how to implement or learn. There are so few documented documents about the structure because "An developer's job is to write the code we want to sell, rather than spending time writing high-level design files ", "design files should not be separated from source code ". Separate the code and "keep things simple ".

Feature team and Content Expert Team Lead

The feature team is generally composed of three to eight developers working in the relevant feature area. The size of a group depends on the experience and ability of the group leader. The feature team lead reports to the project development team and is responsible for all the development work of the project. The project development team has a more holistic view of the product, in this way, you are most likely to find problems that are not correlated. Each person in the feature group is an expert in this field who knows how to use products, what their competitors are, and where they will go in the future. Generally, to facilitate communication and improve the organizational structure of the software (the software tends to map out the structure of the organization that constructs it), the small scale of the feature group should be maintained.

Principle 5: personal responsibility and fixed project resource implementation control

For software projects, it is very difficult to accurately estimate the product development and delivery progress. In this regard, Microsoft takes the responsibility of schedule and work management to the bottom layer, that is, individual developers and testers. This ensures that everyone is not only part of the group, but also has personal responsibilities. Independent developers set up their own schedules. The program manager summarizes the separate schedules and adds the buffer time to develop a comprehensive project schedule. The top-level general manager also has fixed personnel and time and other basic resources to ensure that the project is centralized and restricted in their efforts and creation procedures.

The key objective, especially for application software, is to specify the product's target production date and strive to stick to it as long as possible. The program manager and developer trace back from the production date to specify the date of the project milestone in the middle. This "fixed production date method" is centered on developers. To avoid consuming one year or more in a loop of useless design, redesign, and testing because the project does not have a fixed end point.

Developers make their own progress estimates

"Date setting method. However, developers generally make optimistic estimates, so developers also need to adjust the date they provide and add the buffer time to avoid problems due to incomplete information. The advantage of Microsoft's method of making progress is that it gets more cooperation from people, because the date is set, not set by the Manager; The progress is always progressive, because developers will inevitably underestimate the time they really need.

Detailed task progress estimation

The second scheduling method of Microsoft is to make a very detailed consideration of the tasks to be completed. On this basis, ask the developers to give their estimation of the "Implementation, in this way, we try to "promote" more realism and avoid excessive underestimation.

Generally, Microsoft refines the task to four hours (half a day) to three days. Microsoft's manager knows the exact schedule as follows: "If a task lasts for more than a week, people will not fully consider it. If it takes less than half a day to complete a task, he takes too much consideration of it. He should spend more time programming and less time thinking ". For operating systems such as Windows NT, the schedule is more difficult, and it is generally estimated by the unit of work for a few days or half a week.

Psychology when developers and groups are arranged

When the project grows, Microsoft divides its employees into groups. Then the manager will distribute the responsibilities and ownership of the Progress as much as possible until the group and the individual; this gives both a sense of working. It also puts pressure on individuals, especially group leaders, to keep up with the expected progress of other colleagues because managers may balance the progress, take the work from a team or individual behind. In this way, the pressure between colleagues allows managers to strictly control the processes of individuals or individual groups without too much effort.

Fixed production date (RTM: release to manufacture)

To restrict creativity to time constraints, Microsoft is striving for a fixed production date before the start of a new product or product version, at least with an internal goal of a production date. This puts pressure on people to hack features and concentrate on a project, forcing them to think hard about which new features should be added to the product. Although the delivery goal of the final product may be set by senior executives, developers and teams still set their own schedules.

Microsoft generally estimates an RTM date based on the advance time and progress, and then goes back to the corresponding milestone dates, for example, RC, beta, tree lock, UI freeze, feature complete, CC (code complete) and other milestone corresponding dates. Develop a very detailed product research and development time schedule, and all members of the product development team should coordinate the work with this Schedule as the goal. Microsoft attaches great importance to teamwork spirits in software development. This concept runs through various stages of Microsoft product development. This is also a very important reason for Microsoft's success.

Summary: synchronization-stable development

PLANNING PHASE

Define product imaginative descriptions, descriptions, and progress

Imagining describes product and program management departments that use a wide range of customer opinions to determine and optimize product features.

Description file

The functional and structural problems of the features defined by the program management department and the development team, as well as the relevance between each part, are described based on imagination.

Development schedule and construction feature team

In the instruction documents, the program management department coordinates the schedule and arranges feature teams. Each team includes approximately one program manager and three to eight developers, 3-8 testers (working in parallel with developers at a rate .)

Development Phase

Use 3-4 subprojects, each of which generates a milestone product delivery to complete feature development. The Program Manager coordinates the development process. Developer design, coding, debugging. The tester is paired with the developer for Continuous testing.

The first 1/3 features of Sub-Project 1: The most important features and shared components.

Sub-project 2 features 1/3 in the middle.

The last 1/3 feature of sub-project 3: the least important feature.

Stabilization phase

Comprehensive internal and external testing, final product stabilization and delivery. The Program Manager coordinates OEMs and ISVs to supervise the feedback from customers. Developers conduct final debugging and code stabilization. The tester found and cleared the error.

Internal Test

The company conducts a detailed test on the entire product.

External test

The company's external beta testing points, such as OEM, isV and end users, conduct detailed tests on the entire product.

Delivery preparation

To prepare and release the final "Golden Disk" and documents for bulk production, we also need to perform various rigorous checks before production: such as politically sensitive term checks, virus checks, and file relevance checks. (End)