[To] introduction of Microsoft software development model (next)

Product developing Process in Microsoft

Above: QA is a more professional testing department (Quality assurance Dept) under Microsoft's large product department.

1. Buffer time in the project schedule (Padding times)

Microsoft uses a buffer plan to strike a balance between maximum efficiency and a better estimate of the future. This time to cope with emergencies is part of every major milestone in the development and stabilization process. Buffer time is mainly used to make up for the incomplete understanding of the feature (Feature), or the technical difficulties or inadvertently forget to write the task to the progress, or the unexpected problems caused by the vulnerability. Buffering time helps a project adapt to unexpected events.

Principle two: Using an imaginative description and an overview of the features to guide the project

To provide enough development frameworks to keep work going, and to accommodate changes in the development process and to remain flexible, Microsoft uses an imaginative description and a description of the outline to guide the development of the project, rather than trying to write a complete and detailed description at the outset. The so-called imaginative description is a very short file written by the program manager and the product planner from the Marketing group, in which the goal of the product development is defined, not the specifics of the product! ）。 Usually for a brand new product, the imaginative description is generally relatively detailed and contains a rough description of the document. In general, Microsoft's vision for the description of the requirements are:

The shorter the better, as far as possible "products do not do what" (not "products to do what"!) )。

Using an imaginative description, the program manager begins to write a functional description file that explains what the product's characteristics are and how these features relate to other features and products. Initially it was just a descriptive document, and as the project progressed, the program manager would add more details to it at any time, and the final documentation would become like a user's manual. The complete description not only plays a role in describing the latest features of the product, but it is also the main basis for testing and evaluating products before they are put into production and shipped.
An imaginative description helps determine which features to delete.
The various development groups within Microsoft use an imaginative description to help refine the subject of the product version, and then use this topic to decide whether to increase each possible feature of the product. It is often not easy to change the subject you have identified, otherwise it may cause confusion in product development.

Write a note document
The documentation is intended to convey the product's vision and requirements across all members of the product team, between product groups and between product groups and management. Product attributes must be clearly described in the documentation (describe how each feature works, how it looks, and how it interacts with the user from a user's perspective). If an attribute has an interface, it should also include a diagram to show the effect of the interface and assign it the appropriate priority. The Program Manager establishes the project development schedule accordingly. In addition, the following elements should also be included: project development purpose In one sentence, a list of what the product is and what is not, a definition of the customer, a definition of the competition product, a product's requirements for the system (including operating system version, minimum memory requirements, hard disk space, processor speed, and monitor resolution), Any dependencies on third parties, such as printer drivers, components. The program Manager is responsible for coordinating and "writing down" instructions

Program Manager should consider the following issues:

What is the point of this feature?
How does the user use this attribute?
Does this feature make sense?
Is there a similar feature in this product or in other Microsoft products?
What problems have been missed?
Was the communication within the group satisfactory?
The final program manager determines the content of the feature and writes it down by discussing it with the group's developers.

1. Construction prototype

Construction prototypes are the best way for a program manager to specify a new product or a newer version, which in many ways makes it possible to develop a pre test, especially in terms of usability, and helps to make a good understanding of the user interaction, and it also makes the product description more compact.

Microsoft developers typically use VB to construct user interface prototypes, but the brush (Paint brush) is also a handy tool for working with computer screen models. A rigid description becomes a living document, stating that it should not be too detailed to limit invention. During the project development process, early versions of the documentation will be significantly increased and changed. Because changes in the description can lead to significant changes in the corresponding development effort, Microsoft is usually focused primarily on features that do not have a user interface, because it is not necessary to understand how users react to them before they are completed, which means they are unlikely to change. And then face other features. However, when a product is developed to a certain program, such as 40%, the program manager must strictly control the modification of the feature (mainly to add new features), which will not only cause development delays, but also compress the available test time.

Principle III: Determine product specificity and priorities based on user behavior and information about users

It is often difficult for a development project to determine what features should be included in the final product. For this reason, Microsoft has adopted a method called "based on behavioral planning" for feature selection and prioritization.

Start with a systematic study of user behavior, such as writing letters or budgeting, based on behavioral planning. It is then evaluated according to a particular feature in a program that supports important or regular user behavior. The advantage of this is that it is more rational to attribute trade-offs: discussion of better arrangements for what customers want to do, a more focused debate on a given feature that facilitates specific tasks, more readable descriptions, and better synchronization in marketing, user education, and product development.

1. Feature selection and priority scheduling based on behavioral planning

The key point of the behavioral planning method is to analyze the product by the internal relationship between user behavior, product characteristics and behavior and characteristics. Program managers and product planners divide the user tasks or scenarios that the product is trying to support into about 20 "behaviors," and then they try to map behavior (and any child behavior) to the characteristics of Microsoft's current features and competitor products. They also map behavior to different customer profiles or different market segments.

When describing a new version of a product, the behavior planning approach helps program managers and developers focus on their energy and creativity. For projects like Excel, there are no more than four major actions to be added to each new version. Most of the features are mapped directly into these behaviors. This approach allows the project to rank the value of the user by attribute. By grading, both program managers and developers are motivated to act so that their features support as many behaviors as possible. This kind of benign competition is beneficial to the user, but also is advantageous to enhances the productivity.

2. Prepare information for customer behavior rather than product characteristics

Based on the behavior of planning progress, the project in the planning phase of the first focus on behavior, followed by the characteristics. Program managers and marketers do not think about and exclude their favorite features, and then create a draft of an imaginative description around them. What they really do is make a list of what the customer does, and then focus the imaginative description on the characteristics that support those behaviors.

3. Conduct-centric product-oriented overall consideration

Because the behavioral planning approach is based on the overall product perspective, project members who work on different functions understand what the product does, and how the corresponding characteristics of other products can support behavior that requires or does not require other application software products.

4. Do marketing research to support the Behavioral development Plan approach

To support the behavioral planning approach, product managers from marketing groups work together with program managers and developers to conduct joint research, such as directing research to users. However, it is generally the product manager who does most of the research and can make it more explicit about the evolution of Microsoft's products.

Principle four: Establish the 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 that the product infrastructure (infrastructure), especially the short life cycle applications, should be more monolithic (rather than intricate) as the project progresses. When the development group constructs the first edition of the product, they use the hierarchical structure more often, so as to provide an initial architecture for the product design. Over time, they move to a single structure so that projects can focus on feature development. Microsoft is increasingly emphasizing the sharing of features among different products. Sharing helps to harmonize the "performance and feel" (look and Feel) of different products, it also facilitates users who need more than one application, reduces code duplication, and shrinks the size of a single application.

Microsoft uses feature groups to organize product development, which makes it easy for everyone to understand how the team is associated with the entire product. The project begins with a specification outline. The outline is in the form of a list of content that has been prioritized, involving relatively independent features to be developed by the next release of the product for development by separate feature groups.

Program managers and developers divide the project into a subset of features, which are then assigned to each feature group for production in 3 to 4 major internal project milestones. This product organization and development approach enables Microsoft to incrementally increase the functionality of the product by simply adding developers and creating a large team.

5. Attribute (and function) as the development Unit

The features of Microsoft's software products are the relatively independent functional units that users can eventually see, as is the case with building materials, especially for application software products. System software products, such as NT or 95, are typically not directly visible to end users. Microsoft and other companies sometimes simply call these features "functions" that are not directly visible.

The program Manager undertakes to develop a set of features or functions that are tested, documented, and finalized from the instructions. They must work with the developer, who is responsible for estimating the schedule and perfecting each feature. Developers also need to store one or several files on a networked development computer to save the program source code for the feature. Most features are developed and improved as long as a developer, while some of the large features are a small group.

6. Product structure is the cornerstone for determining its long-term structural integrity

Product structure is the backbone of the product, it provides important structural components and how these components assembled together. Product structure and components for assembly structures provide the backbone to achieve product characteristics (i.e., detailed design and coding). The structure of a product is often not directly visible to end users. Only the attributes to be implemented by the structure are visible. Product structure is also the cornerstone of determining the long-term structural integrity of the product. Any change in product functionality should not result in a potential product structure falling apart.

7. Hierarchical structure of products

For products, it can also be analyzed by a hierarchical approach. A well-defined hierarchy is often helpful for flexible additions, deletions, and improvements to product features. In addition, a good hierarchy helps the product migrate on different platforms. (For example, Excel defines a total of five tiers, where only the lowest level of the operating system layer is platform-dependent, and the other layers are implemented by invoking API interfaces provided by their lower levels, so it is extremely convenient to migrate.) In Windows 95, support for 16-bit, 32-bit, and DOS programs is achieved through the concept of "virtual machines". ）

8. Small structure Document: Source code is a unique file

In addition to the API documentation, Microsoft does not generate the appropriate documentation for its product structure, although sometimes senior developers may write down high-level structures. For complex features, many developers record and review specific details of the structure they are responsible for at some point, but this work is optional and not enforced. In addition to source code files and feature descriptions, there are a handful of groups that provide new programmers with a document depicting a layer of structure (the main data structure, how it works, and so on). However, these files are not always updated, and managers do not require the project team to generate such internal documentation. Implementation issues are not covered in the relevant documentation. The developer should know how to implement it or be able to learn it. The documentation on the structure is so small because "a developer's job is to write the code we want to sell, rather than spend time writing high-level design files," and "design files should not be separated from source code." Split the code and "keep things simple".

9. Feature groups and team leaders as "content experts"

The feature team typically consists of a leader and 3 to 8 developers working on the relevant feature areas. The size of the group is often determined by the experience and capacity of the group's leadership. The feature team leader reports to the project development leadership and is responsible for all project development, while the project development leadership has a more holistic view of the product, which is most likely to uncover unrelated issues. Each person in the feature group is an "expert" in this field who understands how to use the product, understand the competitor's product, and understand where the future is going. Typically, to facilitate communication and improve the organization of the software (the software tends to map out the structure of the Organization in which it is structured), the small size of the feature group should be maintained.

Principle five: Personal responsibility and fixed project resource real rotation control

For software projects, it is difficult to accurately estimate the development and delivery progress of a product. Microsoft's approach is to push the schedule and job management responsibilities to the bottom, the individual developers and testers. This ensures that everyone has a personal responsibility in addition to being part of the group. Individual developers set up their own schedules, and the program manager aggregates the individual schedules, plus the buffer time, to work out a comprehensive project schedule. The top level general manager also fixes basic resources such as personnel and time to ensure that the project is focused and limits its effort and creation procedures.

The key goal, especially for application software, is to specify the product's target date and try to stick to it as long as possible. Program managers and developers backtrack from the production date to specify the date of the intermediate project milestones. The center of this "fixed production Day Law" is on the developer. To avoid the fact that the project does not have a fixed end point, which causes a year or more of time to be consumed in the final useless design, redesign, and testing cycle.

10. Developers make their own progress estimates

"Date Setting method". But developers typically make more optimistic estimates, so development managers need to adjust the dates they provide and add buffer time to avoid problems that may arise from incomplete information. The advantage of Microsoft's approach to making progress is that it gets more cooperation from people, because dates are customized, not managers, and progress is always aggressive, as developers inevitably underestimate the time they really need.

11. An estimate of the progress of meticulous tasks

Microsoft's second scheduling approach is to take a very detailed look at the tasks to be done, and on that basis, ask developers to give them an estimate of "implementation" to try to "get" more realistic and avoid excessive undervaluation.

Microsoft usually refines the task to 4 hours (half a day) to 3 days. As for the precise schedule, the manager of Microsoft knows: "If any task is more than a week, then people must not fully consider it." Any task that a person estimates to be completed in less than half a day, he considers it too much. He should spend more time programming and less time to think. Scheduling is more difficult for an operating system like Windows NT, and it typically takes days or a half weeks for the work unit to estimate the progress.

12. The psychology of arranging the progress of developers and groups

When the project gets bigger, Microsoft divides its employees into groups. The manager then distributes the responsibility and ownership of the progress as far as possible to the group and the individual, which creates a feeling of working. It is also under pressure from groups, individuals, especially in group leadership, to keep up with the expected progress of other colleagues, as managers may be able to balance progress and take work from backward groups or individuals. In this way, peer pressure makes it less necessary for managers to enforce strict control over individual or individual team processes.

13. "Fixed" Production day (Rtm:release to manufacture)

In order to limit creativity to time constraints, Microsoft now strives for a fixed production date, at least for the internal purpose of the product day, before new versions or products are launched. This gives people the pressure to cut off and focus on a project, forcing them to think about which new feature to add to the product. Although the delivery target for the final product may be set by the senior executive, the developer and the team still set their own schedule.

Microsoft generally estimates an RTM date based on the advance schedule and then forwards the corresponding milestone dates, such as RC, Beta, tree Lock, UI Freeze, Feature complete, and CC (Code Complete) and the corresponding dates for each milestone. Work out a detailed schedule of product research and development, and each member of the product development team will coordinate with this schedule for the purpose of harmonization. Microsoft attaches great importance to the teamwork spirits in the software development process, which runs through all phases of Microsoft's product development. This is also a very important reason for Microsoft's success.

Summary: Synchronous-Stable development method

Planning Phase
Define the product's imaginative description, description, and progress

· The imaginative description of product and program management uses a wide range of customer opinions to identify and optimize product characteristics.

· The description file is based on the imaginative description, the function of the Program Management department and the development Group to define the features, the structural problems, and the correlation among the parts.

· Develop a schedule and structure feature group with its documentation, process management coordination schedules, and set up feature groups, each comprising approximately 1 program managers, 3-8 developers, and 3-8 testers (working in parallel with the developer in 1:1 proportions). )

Development phase
A 3-4-order subproject, each producing a milestone product, is sent to complete the development of the feature. The program manager coordinates the development process. Developer design, coding, debugging. The tester paired with the developer and tested continuously.

· Sub-item 1: The first 1/3 features are the most important features and shared artifacts.

· Sub Item 2 Characteristics of the middle 1/3.

· Sub-item 3 characteristics of the last 1/3: the least important feature.

　

Phase of stabilization
Comprehensive internal and external testing, final product stabilization and delivery. The program manager coordinates with the OEM and ISV and supervises the feedback received from the customer. The developer carries out the final debugging and code stabilization. The tester discovers and clears the error.

· Internal testing company to complete the entire product to do a detailed test.

· External test companies ' beta ' test points, like OEM,ISV and end users, perform exhaustive testing of the entire product.

· Shipment preparation for mass production ready to release the final "Gold disk" (Golden disk) and documentation, before making, also need to carry out a variety of rigorous inspection: such as political sensitivity of the term check, virus detection, file correlation check.