来自Q微?nbsp; 蔡锫
一Q团队组l?/FONT>
1Q常见问?/B>
2Q微软团队模?/B>
各角色的职责
角色 | 职责 |
目l理 | ~写功能规范Q协调各角色关系 |
产品l理 | 客户联系的桥梁,q行需求分?/FONT> |
用户教育 | 让品容易?/FONT> |
发布l理 | 保证产品利发布 |
二.目理
1Q常见问?/B>
2Q微软项目管?- 多里E碑式流E?/B>
如何完成一个里E碑
- 基本完成需求调研和分析 Q品经理负责)
- 定大方向和长中短期目标
- 所有角色都参与讨论q真正认同结?/FONT>
- 产生的文档:
- 常见用户情景Q覆?0%以上功能
- VisionQ言意赅地说明大方向Qƈ有激励团队的作用
- 开发h员分别完成自q功能
- 使用版本控制工具
- 使程序员及时check out和check inQ避免积累大量代?/FONT>
- 及时q行模块间的整合Q及时发现问题(daily buildQ?/FONT>
- Ҏ一可试的功能进行测试,无需{待
- 使用试用例工具Q对功能q行完整和重复的?/FONT>
- 使用BMSq行~陷跟踪
- 记录所有程序问?/FONT>
- 实现解决Bug的自动流E?/FONT>
- 按照l合q度表不断检查进?BR>
- 使用的工P
- 版本控制工具 VSS
- ~陷跟踪工具 Raid/BMS
- 试用例理工具
- 试l全面地试功能Q包括性能和稳定?/FONT>
- 开发组全力配合解决Bug
- 使用BMSq行
- 监测质量情况
- 预测发布日期
- 专家会诊机制Q?/FONT>
- 军_Bug的优先度
- 军_哪些Bug可以{到下个里程或版本中解?/FONT>
- 军_p解决某个Bug
- 使用的工P
- 版本控制工具 VSS
- ~陷跟踪工具 BMS
- 试用例理工具
三. 微Y的开发管理经验:100%以Bug为核?/B>
1QBug 及常见类?/B>
2QRAID/BMS的基本功?/B>
3QBug 记录中的有效信息
|
|
4QBug 的严重程?/B>
5Q激zȝBug数量的趋?/B>
四.微Y的一?/B>
1Q?让我们看看项目中每个角色的一天是如何度过?/B>
注:里程的每个阶段每个角色的工作有不同侧重点,我们以“完成功能”阶Dؓ?/FONT>
微Y的一天从几点开始?
{案Q半?/FONT>
Z么?
因ؓDaily Build是所有工作的核心Q而且是在半夜自动启动?BR>
每日构造Daily Build
2Q程序员每天上班前最担心什么?
{案Q因己昨天的代码check-inQ造成Blocking Bug.
Z么?
因ؓ每天的Build是所有h当天工作的基Q?BR>E序员需要Build验证与其他模块的接口
试需要Build发现新BugQƈ验证新Build中已解决的Bug
有Blocking Bug怎么办?
解决问题Qƈ对今天的Build打Patch?BR>
开发h员的正事
l历对Build的提心吊胆和争分夺秒之后Q第一件事做什?BR>{案Q打开~陷跟踪工具Q查看指定给自己的BugQ解决高优先度的Bug。因量重于新功能?/FONT>
接下来,开发h员会?/B>
从版本控制工具中Check out代码
修改代码Q解决Bug或实现新功能Q?BR>取得版本工具中最新变化,在本机Build和单元测?BR>请开发组同事作Code Review
Check in代码
3Q测试h员第一件事做什么?
{案Q打开Raid/BMSQ查看指定给自己的BugQ验证已解决的Bug?/FONT>
接下来,试人员会?/B>
4Q专家会?/B>
~陷走势?/B>
5Q回־软的一?/B>
6Q微软的做法解决了那些常见问题?
质量问题
文档理问题
团队协调问题
五.提高软g理的步?/B>
1. 使用Raid/BMSQ将程理自动?BR>2. 使用试用例理工具
3. 使用文档理工具
4. 使用版本控制工具Q进行Daily Build
5. 建立代码标准
6. 建立Code Review机制
7. 建立专家会诊机制
8. 建立团队沟通机?BR>9. Ҏ需要调整团队结?/FONT>