版本控制系统进阶
- 4. 好的项目开发经验 MSF = “Build IT Right” http://msdn.microsoft.com/en-us/teamsystem/aa718795.aspx MOF = “Run IT Right” http://technet.microsoft.com/en-us/library/cc506049.aspx
- 5. 产品操作和支持信息系统 操作手续和流程 知识库、报表和操作日志 存放文档、测试结果和源代码的文档库 项目结束报告 用户满意度调查报告 下一个版本的定义 远景和项目范围文档 项目团队结构组建完毕 风险评估文档定型 金盘 发布说明 性能测试指标数据 测试结果和测试工具 产品源代码和相关程序 项目文档 里程碑总结文档 功能说明书 风险管理计划 项目计划和项目进度 产品源代码和程序 安装脚本和安装配置文件 功能列表不再更改 测试用例 产品性能测试支持元素
- 9. 有效授权 注重产品的 商业价值 对需求变化快速反应 培养开放的沟通环境 职责明确, 分担责任 MSF团队原则 MSF团队理念 平等的 团队成员 有动力的团队 是最高效的 客户至上的 开发思维 将每个交付物 当作产品对待 乐于总结和学习 零缺陷的 开发思路
- 16. 用户使用场景 描述用户使用习惯 将场景细分成任务 编码 设计测试用例 执行测试用例 头脑风暴用户使用场景 用户场景描述了用户通常是如何跟系统打交道的。用户代表使用系统是为了完成某个目标，而场景就描述了用户尝试达到目标而执行的具体步骤。
- 17. 服务质量要求 头脑风暴QoS需求 将QoS细分成任务 编码 设计性能测试 执行测试用例 定义QoS优先级列表 描述各个需求的具体用户场景 确定QoS需求 设计安全测试 确定安全操作的目标 设计压力测试 设计负载测试 服务质量要求（QoS）描述了系统的各种特性， 例如性能（Performance）、负载（Load）、有效性（Availability）、压力（Stress）、可操作性（Accessibility）、耐用性（Serviceability）和可维护性（Maintainability）等各项指标。
- 18. 工作任务 将场景细分成任务 设计性能模型 评估任务执行进度 执行测试用例 将QoS细分成任务 编码 团队中不同的角色有不同的任务，例如程序员的任务是编码，而测试工程师的任务是设计和执行测试用例。 在TFS里面，分配给不同角色的任务的填写的域也不一样。
- 20. 风险 确定风险 构建风险解决方案原型 任何可能导致项目失败的事件或者因素都是风险。 将风险当作一个任务来看待，可以将风险记录下来并且进行有效的跟踪。 风险有可能会转变成一个有效的任务，例如一个技术上的风险可以通过分解成 重新架构和重新编码等任务来避免它。
- 23. 确定任务进度计划 T 点击“Get Work Items”按钮也可以从TFS服务器里面查询任务。 点击“Publish”按钮更新进度计划 1 在TFS里面就可以看到Project 2007当中更新的进度了 2
- 48. 3.0 新功能研发 分支 T 有些分支最终会合并到代码树主干上。 大客户定制 功能分支 2.0 售后 支持 补丁包 分支 1.0 主干（Trunk） 与分支（Branch）的应用 程序主要版本的开发
- 49. FI （Forward Integration） 的概念 当主干树里面有最新文档改动的时候，源代码服务器可以将这个更新自动发布到代码树的各个子功能分支上。 子分支树可以随时或者定期从代码树主干获取最新的更改。同步完成以后，需要执行一次较为完整的测试。 最新改动 代码树主干 功能集一 功能I 功能III 功能IV 功能II
- 50. RI（Reverse Integration） 的概念 每个功能分支树也可以将自己最新的代码合并到主干里面去。 子分支树在合并之前，需要符合一系列项目计划时定下的代码合并质量要求，例如合并进来的代码需要有足够的代码覆盖率等条件。 RI之后，其他功能分支可以通过FI操作获取最新的改动。 代码树主干 功能集一 功能I 功能III 功能IV 功能II
