微软的一天

1．每日构造Daily Build 
   Daily Build是所有工作的核心，而且是在半夜自动启动。 
   • Daily Build的意义： 模块得以及时整合； 要求程序员及时把最新代码放入代码库 
    • 用脚本语言和编译/链接工具实现 
    • BVT Build Verification Test ：对Build进行验证 
    • Blocking Bug ：让Build无法完成的问题； BVT中发现的问题
2．程序员每天上班前最担心什么？ 
   答案：因为自己昨天的代码check-in，造成Blocking Bug.每天的Build是所有人当天工作的基础，程序员需要Build验证与其他模块的接口；测试需要Build发现新Bug，并验证新Build中已解决的Bug。 
   有Blocking Bug怎么办？ 　解决问题，并对今天的Build打Patch。 
   答案：打开缺陷跟踪工具，查看指定给自己的Bug，解决高优先度的Bug；为质量重于新功能。 
   从版本控制工具中Check out代码； 修改代码（解决Bug或实现新功能）；取得版本工具中最新变化，在本机Build和单元测试；请开发组同事作Code Review ； Check in代码
3．测试人员第一件事做什么？ 
   答案：打开Raid/BMS，查看指定给自己的Bug，验证已解决的Bug；根据测试用例检验今天的Build ； 在Raid/BMS中记录新发现的Bug
4．专家会诊 
   • 参加者：项目经理和开发组长、测试组长 
   • 通过Raid/BMS评估每个未解决的Bug：决定Bug优先度； 可否等到下个里程碑或版本？谁来解决 
   • 预测项目实际进度和发布时间
缺陷走势图
5．回顾微软的一天 
   • 构造: daily build ； 开发: 解决blocking bugs, 实现功能, check-out, code review, check-in 
   • 测试: BVT, 使用测试用例进行测试； 项目经理/组长: 专家会诊
6．微软的做法解决了那些常见问题？
质量问题 
    • 以前解决过的问题发布时又出现了，需要返工 ；无法预估发布时间 过早发布，带来质量和维护问题 
   • 测试发现的问题被忘却或不了了之；无法衡量测试员和开发员的工作；程序中的问题往往在发布后才发现
文档管理问题 
   • 文档与程序脱节，文档成为程序结果的描述； 项目组把写文档看成负担
团队协调问题 
   • 开发人员各自为战，进行整合时发现模块衔接中的严重问题 需要作大的改动 
   • 没有保管好公司以往的版本和代码，无法满足用户对旧版本的更改要求； 开发人员离职对项目带来很大冲击，没有人知道代码在哪，或无法读懂
五．提高软件管理的步骤 
   1. 使用Raid/BMS，将流程管理自动化； 2. 使用测试用例管理工具； 3. 使用文档管理工具； 
   4. 使用版本控制工具，进行Daily Build　　　5. 建立代码标准； 6. 建立Code Review机制； 
   7. 建立专家会诊机制； 8. 建立团队沟通机制 ； 　　　　　　　　9. 根据需要调整团队结构
产品设计考虑问题 
   1 Who : 为谁设计，用户是谁？不能为所有人服务； 
   2 What：要解决哪些用户问题？ 
   3 Why： 为什麽要解决这些用户问题？例：曲别针，餐馆中尖头筷子，一正一反可供参考。
   设计之源：在于用户；设计之本：要满足用户需求，方便用户使用，并且使生产制造工艺尽可能简单；不能把软件设计单纯当作自我技术水准，个人才智表达的方式。（用户场景： 用户使用软件的特定环境或场合。）