1． 微软的开发流程
· Scenarios – Or more appropriately named, business objectives. These laid out the goals the division had for this release.
· Value Prop– The value from the customer perspective. Stated as “Why the customer would pay for this” All value props were traced to Scenarios.
· Experiences – The experience of the customer to realize the value. You can think of them as business level use cases, or scenarios, or epic stories.
· Features – The feature we needed to implement, so to enable the Experience to release the Value Props to meet the divisional goal. Features were the break-down of the work.
前三者用于规划产品，确保我们开发出正确的产品；而最后一项是用于管理开发。这些称呼可能在不同的公司，不同的开发领域有不同的称呼或增删，但他们的意义是相同的。
2． 微软的特性小组
微软管理着1200个独立的Feature，它们都基于一个单一的程序基线。当所有的工作都同时开展，每个小组都关注于他们自己开发的特性时，他们是如何保持这些程序的品质呢？
答案是特性小组。它是学自Office组的一个模型：
当一个特性小组开始开发一个特性时，其生命周期如下：
- 特性小组创建一个主程序的分支，以提供一个独立的工作环境。这个环境隔离于任何其他的程序分支。
- 他们开发一个特性时，有两个检查点。这些检查点是用于项目管理。检查点1是关于设计的，在这里检查特性是如何被计划和实现的。
- 检查点2是关于演示实现的功能，在这里检查该特性是否被实现。
- 一旦他们完成了特性，这些特性将被集成到主程序分支中。
- 在集成之前，所有的特性小组需要通过一系列的“质量门”。这些“质量门”包括："No performance regressions"、"70% code coverage through automated testing"等。
- 当这些特性小组通过了这些“质量门”，他们就可以真正被集成到主程序分支中。这些“质量门”用以保护主程序分支，始终保持在“接近发布”的状态。
注：目标是一个特性小组在4～6周内得以完成。
一个特性组被完成前，需要经过16个“质量门”的检测。其中一些“质量门”如下所示：
当这些特性小组开发他们自己的特性时，所有这些小组的工作被管理为一个一个迭代。下图显示了特性小组的分支如何被集成回主程序分支。特性小组之间是互相重叠的，迭代见也是重叠的。
3． 开发流程的实现
微软使用工作项来跟踪开发流程中的各种信息。
（1） Value Proposition工作项
1) Scenarios是通过在Value Proposition工作项上创建一个Scenario项来实现的。它是一个列表可以选择。由于Scenarios是相对固定而且数量比较少，因此这样做是合适的。
2) Value Proposition和Experiences之间的关系，是通过将Value Proposition工作项链接到Experience工作项上来实现的。
3) Value Proposition工作项含有几个项来定义Value Prop的，显而易见，Description项就是用来描述Value Prop是什么的。
（2） Experience工作项
1) Experience工作项向上链接Value Proposition工作项。
2) Experience工作项向下链接Features工作项。
（3） Feature工作项
1) Features工作项链接到Experience工作项。
2) Feature工作项也有许多项来定义它。
3) 有关更多的信息，可以通过One Page spec项中的链接来找到。
下面介绍如何计划一个新的产品或特性的开发。
在Feature工作项上有一个Planning页，上面含有各种计划的信息。
可以将这些信息整理到一个表格中。
这是一个TFS绑定的Excel表格：
（1） 估算的工时等数据，直接从TFS中引用过来。
（2） 从上而下列出了所有特性。
（3） 在表格中增加了一些逻辑，可以比较实际工时。如果达到了70%就显示黄色；如果超出了100%，就显示红色。
这些给出了一个该做什么、不该做什么的直观视图，而不需大量的工作。它能帮助作出应该的决策。
4． 开发进展的追踪
在Feature工作项上有一个Progress页。
只要看一下，就能了解现状。特性小组的人只要每周更新一下其中的数据，无需发邮件或写任何的文档。特性小组自己可能使用MS Project、SCRUM、Excel等等来进行管理，但这些都是无关紧要的，只要填写了Progress页就可以。也许你觉得这有些太过儿戏了，但实际上它是一个非常具有说服力的工具，这将在以后介绍。
现在还是说明一下Progress也中的项。
（1） 关键日期：有四个关键日期需要跟踪：开始日期、结束日期和两个检查点日期。
注意：在特性小组启动时，需要承诺检查点1的日期，并估算检查点2的日期和结束日期。在检查点1，需要承诺检查点2的日期，并估算结束日期。在检查点2，需要承诺结束日期。
（2） 完成程度：更新整个特性下组的的剩余工作量和已完成工作量。我们无需关心特性小组是如何管理自己的。
（3） 风险等级：第一个项是一个红绿灯指示器。绿色：正常；黄色：有风险；红色：已延期。第二项是描述文字。
（4） 其他的我们感兴趣的日期。
（5） 特性小组的简单描述。
5． 风险的追踪
首先我们看一下Feature工作项的Progress页。你会看到两个项是与风险关联的。每周项目经理会检查发布在Feature工作项上的日期，判断是否是如期进行，然后更新相应的风险等级，同时添加所需的说明。以下是报告：
这份报告是用Excel制作的，它绑定了一个所有风险等级不是绿色的查询上。它上面的颜色是由Excel来生成的。
6． 质量的追踪
在Orcas开发支出，某位高层提出了以下两点要求：
（1） VS2008不能比VS2005有性能的衰退。
（2） 我们使用自动测试，覆盖70%的程序。
这只是两点要求，但却是非常大的要求。如何确保一个3000人的组织，在2～3年内增加100多个特性后，这个要求仍然被满足？
我们的答案是质量门。在Orcas开发中，我们有16个质量门，从“必须书写规格书”到“覆盖70%程序的自动测试”。
在Feature工作项上，我有一个专门的页用于质量门。
前4个是关于文档的，只要他们存在，并且被发布了，就可以通过。
剩下的则是通过是否发布和一个状态指示器来追踪。
在特性小组标记一个特性完成之前，他们必须确保通过了所有的质量门。为了证明这一点，他们需要填写这些质量门项，是通过、不适当还是免于检测。这些特性工作项规则使得它的状态不能为“完成”，除非这些质量门都被通过了。如果任何的质量门被标志为“异常”，则一个“异常授权”的项变为了必须的，这就需要项目主管对此异常给予承认。
这好像回避了问题的实质：你怎样保障不被欺骗？答案是我们不需要。我们真的要去追查每个特性被标志为通过时，是否真的通过了么？不。确认这些需要大量的时间和精力。这是一个基于信任的系统。我们信任他人会做正确的事情，而且我认为绝大多数人也是如此的。
另外的预防是，其中一部分质量门在主程序分支中是会被重复的。如所有的性能测试、自动测试。
为了追踪这些质量门的进展，我们使用以下报告：
这也是一个基于Excel的报告。就像其他报告，每周，我们的项目经理展示这个报告，并会问：
- 我注意到你们已经接近开发的尾声（上面报告的RI列），但是你们还没有开始任何的质量门，能说一下原因么?
- 你们已经标志了一些质量门为红，为什么？需要我的帮助么？
7． 透明的报告
在此，将展示几个报告，上到C×O高层，下到个别的特性。
开发部门的展示板：
针对高层的报告，展示对于Value Props的实现进程：
展示与Value Props相关的所有Experience和Feature的进程：
展示与Experence相关的Feature的进程：
