|
“微软是如何组织和进行产品开发”其实是一个很大的题目。在微软内部我们有一个卓越软件工程团队,主要为员工提供为期数日的课程,内容涉及微软软件开发方法概述、工程系统、组织架构、最佳实施办法,以及用以保证产品质量、可靠性及安全性的内部工具和技术等等。这并不意味着我们的体系已经十全十美,但我们的确积累了很多知识和经验可以与大家分享。实际上,我们也在以适当的方式与全球(包括亚洲)同行分享这些成功。
因为这是一个大题目,我想在这篇文章里着重介绍我们工程系统中的一个方面,即我们研发团队的核心专业和每个专业在产品开发中所扮演的角色。因为我相信微软在这一方面的做法不同于我们的同行(即使在美国也是如此),尤其在中国,目前业界还没有充分理解这些核心专业及其所扮演的角色。
微软的工程体系一直由三个核心专业组成:“开发(Development)","测试(Test)"和"项目管理(Program Management)",英文简称分别为"Dev","Test"和"PM"。在此,我将以另一个顺序作简单介绍:
PM:提及软件专业时,大多数人都马上想到"Dev" 。但是对我来说,一切则从项目管理开始。在微软,“PM” 意味着很多事情,对我而言,这个角色主要意味两件事:
1.了解用户的需求,并将其转换为用于开发的功能说明(functional specification)。这是一切的开始,如果我们无法理解用户,我们就不能开发出合适的产品。
2 .协调Dev 和Test,将最初的功能说明转变成真正的产品。
我发现很多人,特别是在中国,一听到”PM”就认为这是“Project Management”。事实上,这仅是PM工作的一部分(上述第2点)。PM真正的技能在于倾听用户并从他们的角度理解问题,然后设计出解决问题的方案。这并不意味着简单地为用户提供他们所需要的,而是在真正理解需求后设计最好的解决方案,即使这是连用户自己都从未想到的解决方案。常言道,如果我们一味地遵循用户的要求而只是去找寻一匹更快的马匹,那么汽车永远也不会诞生。
Dev:三个专业中,Dev可能总是人们知道得最多的。他们负责实际设计和开发软件产品。Dev 的主要工作是实现PM制定的功能说明。在系统级的、关键任务级的软件世界里,这个实现应该极为可靠、 安全、 便于管理、 可以扩展和高性能。Dev的设计和功能实现应经得起时间的考验,并在未来版本中得到重用。
Test:外界对微软测试工程师存在许多误解,内部有时也存在这个问题。多年前我刚进入微软时,我(愉快而)惊奇地发现在微软Tester的人数几乎和Developer同样多。在我之前服务的公司,测试人员要少很多(当然产品的质量会相对薄弱),因此在微软工作了一段时间后,我才真正了解测试专业的本质。在微软,我们何时可以发布产品并不取决于我们何时完成产品的设计和实现,而是取决于我们何时能完成产品测试。因为我们所发布的每个产品,尤其是系统类型的软件,必须通过一个极高的质量标准。测试专业的确是一个非常复杂的领域,一个Test必须花好几年时间才能掌握悟我们所应用的测试种类—— 单元测试、功能测试、集成测试、压力和远距测试、性能测试、安全性测试,以及本地化测试等。我们在测试中运且用的一整套工具和技术的复杂性令人印象深刻——自动测试套件,自动测试生成工具,自动检测故障分析工具,自动安全模糊测试和基于状态机的测试。
以上三个核心工程专业就像一张3条腿的凳子——一个也不能少,并且需要一个合适的工程组织保持其平衡。没有一方可以凌驾于其他任何一方,否则这个组织就无法与客户需求保持一致,或者无法在产品质量上下足功夫。这 3个专业类似政府部门间的制衡机制,这套机制确保了我们能理解客户需要,设计高品质产品,同时每个发布的产品都在各方面满足顾客的期望。
综上所述,与我们常规的项目不同点在于
1.微软的研发是产品
2.微软具有非常流程化的操作框架
3.流程转化为了意识
所以,微软没有SQA这个职位
汲取的优点
1.建立合适的流程
2.让需求人员作为项目经理主导项目,市场人员监督
3.让设计人员同时设计、编码,不要分离
4.尽早的发布Beta版本进行用户测试
5.提供客户及用户适合的,而不是完美的
上一篇:【候选城市投票】思步网线下活动 下一篇:第七届系统与软件过程改进年会 |
|