Solfware
Soft Engineering
There are several lessons to be learned from how Microsoft builds software products.
Frequent Synchronizations and Periodic Stabilizations
The main idea is synch-and-stabilize:“Continually synchronize what people are doing as individuals and as members of parallel teams, and periodically stabilize the product in increments as a project proceeds, rather than once at the end of a project.”
Microsoft follow a process that iterates among design, building components, and testing and also overlaps these phases and contains more interactions with customers during development.
Strategies and Principles
Microsoft has two strategies for defining products as well as developing processes and sets of principles that seem critical to making the sync-and-stabilize style of product development.
Microsoft teams begin the process of product development by creating a “vision statement” defining the goals for a new product and orders the user activities that need to be supported by the product features.
The project managers then divide the product and the project into parts (features and small feature teams) and divide the project schedule into three or four milestone junctures (sequential subprojects) representing completion points for major portions of the product.
Defining Products and Development Processes
To define products and organize the development process, leading Microsoft product groups follow a strategy we describe as “focus creativity by evolving features and ‘fixing’ resources.” Teams implement this strategy through five specific principles:
Divide large projects into multiple milestone cycles with buffer time (20%–50% of total project time) and no separate product maintenance group.
Use a “vision statement” and outline feature specifications to guide projects.
Base feature selection and priority order on user activities and data.
Evolve a modular and horizontal design architecture, mirroring the product structure in the project structure.
Control by individual commitments to small tasks and “fixed” project resources.
Developing and Shipping Products
To manage the process of developing and shipping products, Microsoft follows another strategy we describe as “do everything in parallel with frequent synchronization.” Teams implement this strategy by following another set of five principles:
- Work in parallel teams but “synch up” and debug daily.
- Always have a product you can ship, with versions for every major platform and market.
- Speak a “common language” on a single development site.
- Continuously test the product as you build it.
- Use metric data to determine milestone completion and product release.
Large-scale projects are simpler to schedule and manage if they proceed with clearly defined functional groups, sequential phases, and precise rules and controls.
A common site and common language and tools help teams communicate, debate design ideas, and resolve problems face to face.
Synch-and-stabilize vs. sequential development
Synch-and-Stablize (Microsoft) Sequntial Development Product development and testing done in parallel Separate phases done in sequence Vision statement and evolving specification Complete “frozen” specification and detailed design before building the product Features prioritized and built in 3 or 4 milestone subprojects Trying to build all pieces of a product simultaneously Frequent synchronizations (daily builds) and intermediate stabilizations (milestones) One late and large integration and system test phase at the project’s end “Fixed” release and ship dates and multiple release cycles Aiming for feature and product “perfection” in each project cycle Customer feedback continuous in the development process Feedback primarily after development as inputs for future projects Product and process design so large teams work like small teams Working primarily as a large group of individuals in a separate functional department
CN
Microsoft builds software 的核心方法是 “Synch-and-Stabilize（同步并稳定）”。也就是：小团队并行开发、频繁同步代码、分阶段稳定产品，而不是等到最后一次性集成和测试。
微软的软件开发有几个关键点：
- 先定方向，但不过度把需求“锁死” 微软会先写一个 vision statement，说明产品目标和用户最需要的功能；然后再写功能规格说明，但不会一开始就把所有细节彻底定死。开发过程中，功能集合还会持续调整，文章提到规格里的功能甚至可能变化 30% 以上。
- 把大项目拆成多个里程碑（milestones） 一个大产品不会一次做完，而是拆成 3 到 4 个阶段性子项目。每个里程碑都要经历：开发、集成、测试、修 bug、稳定版本。这样团队能逐步推进，而不是把所有风险留到最后。文章中的图示还说明，每个 milestone 通常持续 2 到 4 个月。
- 用小型功能团队并行工作 微软试图把“大团队做大产品”变成“很多小团队协作做大产品”。每个 feature team 通常由 1 名 program manager、3–8 名开发、3–8 名测试人员组成。这样既保留灵活性，也便于快速推进。
- 每天同步（daily build） 开发者先在自己的私有代码副本上完成功能和测试，再把代码提交到主版本。随后由专门人员每天生成一次完整 build，重新编译整个产品，并运行自动化回归测试。 这意味着：问题不是等到项目末期才暴露，而是几乎每天都会被发现。 如果谁提交的代码破坏了 build，就要立刻修复。
- 持续测试，而不是最后才测试 测试人员和开发并行工作，微软还会在开发过程中做内部测试、外部 beta 测试、可用性实验，甚至请真实用户试用原型。测试不是项目尾声的单独阶段，而是贯穿整个开发过程。
- 定期“稳定”产品 每完成一个 milestone，团队都会集中修复大部分错误，让产品进入一个相对稳定的状态。这样团队始终清楚：哪些功能已经完成，产品离发布还有多远。
- 用数据决定是否进入下一阶段或发布 微软会跟踪 bug 数据，比如新发现多少、修复多少、仍然活跃多少。文章第 6 页的图表就展示了 bug 统计如何配合 daily build 来判断项目状态。也就是说，推进项目不是凭感觉，而是看指标。
- 追求“足够好并可发布”，而不是一开始追求完美 文章强调，微软的策略不是等产品“完美”再推出，而是尽快做出可工作的版本，边开发边改进，后续通过升级不断演进功能。这很适合变化快、竞争激烈的软件市场。