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. Microsoft usually adopts the "synchronization-stable product development method ". The life cycle of a typical project consists of three phases: the planning phase: the description of the completion function and the final formulation of the schedule.
Development Phase: Write complete source code
Stabilization phase: completes the product so that the three major phases of batch production (roll out), as well as the internal cycle method between the phase and the traditional water fall) 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. 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. This milestone allows Microsoft managers to clearly understand what the product development process has taken, and to flexibly delete some product features in the later stages of the development stage to meet the schedule requirements. In the planning phase, I have summarized the following: 1. clarify what kind of product you are going to make and what features this product has. 2. there is no market for this product. Why do users need this product? The trend of this product is 3. what does this product look like? Is there a general prototype display to facilitate high-level decision-making? 4. designed functions, goals, priorities, and approximate progress. Therefore, Microsoft's plan phase protects a lot of feasibility studies and product plans. More is a product plan. The plan of the development phase in the development phase allocates a set of features for each of the three or four major milestone versions, specifying the details of the features and the 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. (Refer to Microsoft's MSF model) when the tester finds an error, the developer does not leave it for future processing, but immediately corrects it 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. (There are two points here. One is to advocate early detection of defects and continuous integration, and the other is to strictly control demand changes in the future) 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 ). (The 1/3 time should be enough, and it is difficult for general R & D projects to prepare such a buffer.) After testing and stabilizing the last major milestone version, the product requires "UI freeze" to determine the main user interfaces of the product, such as menus, dialog boxes, 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. 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. In the software development process, software testing and development is a "spear and shield" relationship that complements each other and is 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. Microsoft has a dedicated SLM source code management tool for managing source code and automatic building. Developers check in and automatically compile their code SLM by pre-defined scripts before leaving work every day. On the next day, the tester downloads the build from the previous day for testing. Reflect the testing status to another tool software in a timely manner. You can use this tool to query which developer has fixed the bug activity on the day and the number of solutions, the number of bugs and other basic product quality conditions of the tester, so that the project manager can easily master the specific progress of the project. It is also important for the project manager to keep abreast of and understand the working status of each tester and developer based on this tool. (Microsoft's source code management and daily construction and continuous integration mechanisms are worth promoting) 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. Principle 2: Use imaginary descriptions and brief descriptions of features to guide the project in order to provide a sufficient development framework for continuous work, in addition, it can accommodate changes in the development process and maintain sufficient flexibility. Microsoft uses imaginative descriptions and summary instructions to guide project development, instead of 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 better, the better, try to explain "what the product does not do" (rather than "what the product wants to do "!). 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" that the program manager should consider the following questions: 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. (When we were creating a new product, we couldn't figure out many details at the beginning. There may indeed be only one framework concept. Therefore, Microsoft should also emphasize iterative development and gradual refinement, and emphasize further refined design through prototype. this is also why the prototype plays an important role in mining deep user needs. At the beginning, the user may not know what detailed functions are required, principle 3: Determine product features and their priorities based on user behavior and relevant user information. For a development project, it is usually difficult 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. (This principle fully demonstrates that Microsoft products are completely user-driven and software creates customer value.) because the behavior-based planning method focuses on the entire product, therefore, it helps project members working on different functions understand what the product is, and how the corresponding features of other products may support behaviors that require or do not require other application software 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 product design is the product infrastructure ), in particular, applications with short lifecycles should become more uniform (rather than 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. (It seems that feature-driven development is a bit similar to that of feature-driven development. Splitting of daily building function points must be fine enough.) 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 ". (The source code is the design) the feature team and the team lead as the "Content Expert"
The feature team is generally composed of three to eight developers working in the relevant feature area. The size of a group is often determined by 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. (Not the number of people in the group, but the overall skills of the group members cannot be too different) Principle 5: relying on 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. (Amazing) "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. Source: http://blog.sina.com.cn/u/493a8455010004v3
