五、关注交付的业务价值
客户需要的是一把梯子,系统分析员了解到的是一张凳子,开发人员做出来的是一张桌子,测试人员以为是一张椅子。看上去可笑,但这样的情况却经常发生在我们的身边。
关注交付的业务价值,意思就我们工作中的每一份工作产品,都应该是需求驱动做出来的,这样才能保证我们最终做出的软件就是客户所需要的东西。这个原理有以下几层意思:
l 小组成员要对客户的需求有一致的充分的理解。
l 要让客户积极参与到项目过程中去,随时了解小组的理解和客户的需要是否一致。
l 需求驱动地完成所有工作,保证最后的软件产品符合客户的需要。
六、保持灵巧,预测变化
软件是智力型创造性活动,保持灵活、适应变化是软件开发的最高境界了!我感觉这条原理是最难把握的一条了。
这个原理主要体现在以下方面:
l 软件开发过程
微软采用的不是RUP,也不是XP,而是类似于螺旋形的阶段式分版本发布。微软会把软件分成若干的版本发布,除了平时我们见到的Beta版、Release版,其实在Beta版之前还会有若干的内部版本。每个版本都包含相对完整的功能,都能实现部分业务价值。每一个版本就是一个开发周期,每个周期包含远景、计划、开发、稳定、部署五个阶段。这样的一种开发模型,能很好地适应需求变化,发现设计、编码缺陷,优化设计,更容易控制软件质量,便于随时做出商业决策。
图一:微软的开发模型
l 设计方案
执着于优雅设计的人士,可能很喜欢做出完美无缺的设计,关注于业务的人士,可能更关注于尽快要拿出软件。我们追求的是适度设计,而不是过度设计,如何做出一个简单的而又适应变化的设计,是对软件设计高手们的一大考验了。
七、质量投资
“质量第一”是很多软件公司的口号,而且仅仅是口号而已,你们的项目有这样的一些问题吗?
代码没有经过简单的冒烟测试,甚至不进行是否通过编译的测试,就直接提交。
为了赶时间不写设计或者写了不能指导编码的设计文档。
开发进度推迟,测试时间被压缩,为了保证软件发布的时间,在不充分测试情况下交付软件,更甚者不测试软件,直接让客户测试。
开发过程中发现的问题,只要能不解决的就不解决,进度优先!
测试中发现的易用性方面的缺陷,因不会严重影响使用,一律不解决!
质量投资要求我们有零缺陷的意识,零缺陷意识要贯穿在全部的工作中,包括:
l 零缺陷文档
计划、需求、设计等开发过程中产生的文档,要用一次写好的决心来编写,所有文档都应该发挥它的价值,而不是为了写文档而写文档。要让相关的小组成员对该文档发表意见,重视他们的意见并修改文档。
l 零缺陷代码
要用一次把代码写好,不让测试发现缺陷的态度来写好代码,写出垃圾代码是不负责任的行为!
l 零缺陷发布
用质量投资的态度对待所有缺陷,包括自己代码产生的缺陷,对用户负责,不满足质量要求的软件坚决不发布。
全体小组成员都应该同步达到零缺陷里程碑,本着一步一个脚印、不断追求高质量的态度来完成全部工作。
八、学习所有的经验
象Windows这样的一些伟大的软件,都是经过很多人通过很长的时间做出来的,工作量之大、难度之大不亚于一些伟大的建筑工程。软件工程与建筑工程最大的优势就是,如果软件做得不好,可以推倒重来,但建筑工程就不能这样做了。
我拿软件工程与建筑工程比较,目的就是想强调做软件是很强调学习的,很强调不断改进的(当然建筑工程也重视学习)。我们应该庆幸,我们这些做软件的要比做建筑工程的要幸福的多了,我们不太可能犯一些不可以弥补的错误。
“那些忘记过去的人肯定会重复过去(的错误)。”
——George Santayana
我们要让大家从自己或者别人的失败和成功中学习,要帮助小组成员再次获得成功,捕捉和共享技术的或者非技术的最佳实践,并想办法让学习制度化。
学习制度化的办法很多,如项目总结、例会等,但要注意的是学习应该是随时进行的,抱着学习一切可以学习的态度来工作。
微软的项目团队结构
谈了微软MSF的八大基本原理,我们来看看,微软的团队是怎样组成的?
很多软件公司的开发团队,大部分是由一名项目经理,若干项目成员组成,项目成员包括需求分析、架构设计、编码、测试等角色。
而微软的团队非常特别是没有项目经理的,由6类角色组成,分别是产品经理(Product Management)、程序经理(Program Management)、开发(Development)、测试(Test)、发布管理(Release Management)、用户体验(User Experience)。
图二:微软的团队角色
各类角色负责的职责如下:
角色 |
目标 |
职能领域 |
职责 |
产品管理 |
满足客户 |
市场开发 业务价值 客户拥护 产品计划 |
为项目小组充当客户角色 驱动共同的项目和方案设想 管理客户需求说明 开发和维护业务案例 管理客户期望 驱动产品特征、日程表、资源权衡决策 管理市场开发、产品宣传和公共关系 开发、维护和执行交流计划 |
程序经理 |
交付满足项目约束的解决方案 |
项目管理 解决方案体系结构 过程保证 管理服务 |
驱动开发过程以期按时的交付产品 管理产品规格说明书 - 首席项目构架师 促进小组内部的交流和商议 维护项目日程表和报告项目状态 驱使关键的权衡决策的实现 开发、维护和执行项目总规划和日程表 驱使和管理风险评估和风险管理 |
开发 |
根据规格说明创建解决方案 |
技术咨询 实现的构架和设计 应用程序开发 基础结构开发 |
指定物理设计的特征 估算完成每个特征所需的时间和精力 构建每个特征并监督其实现 准备部署时使用的产品 为小组提供技术主题的专门知识 |
测试 |
在所有产品质量事宜被识别并处理后进行发布 |
测试规划 测试工程 测试报告 |
确保了解所有问题 决定测试策略和制定计划 执行测试 |
用户体验 |
提高用户效率 |
技术交流 培训 可用性 用户界面设计 国际化 易用性 |
为项目小组充当用户的角色 管理用户需求说明 设计和开发性能支持系统 驱动可用性和用户性能增效的权衡决策 为用户提供帮助特点和帮助文档的规格说明书 开展和提供用户培训 |
发布管理 |
进行平滑的部署及日常运行 |
基础结构 支持 操作 业务发布管理 |
管理产品部署 驱使可用性和可支持性权衡决策 管理各种操作、支持和交付渠道之间的关系 为项目小组提供后勤支持 |
微软的团队模型中的6种角色,不代表团队最少要6个人组成,一个人可以兼任多种角色,也不代表每一种角色只有一个人,可以多个人公担一个角色。
微软这种团队结构与我们常见的团队结构相比,有这样的特点:
l 扁平对等的团队结构,强调每个人的价值
这种团队结构,是“赋予小组成员权力”、“清晰的责任和共同的职责”、“推动开放式沟通”这三个原理的表现。这样的结构,让每位小组成员都感受得到自己的重要性,项目的成败与每位成员直接相关。这样的结构更容易调动每位成员的工作积极性,更容易让团队激发工作热情,产生更多的创造性成果。
l 微软很重视的我们常会忽略的用户体验和发布管理
微软团队的6种角色所负责的工作,覆盖了软件开发中需要考虑的各个方面,用户体验、发布管理是常被我们忽视的地方。微软软件的用户体验都非常好,规范一致的界面,详细的帮助系统,良好易用的安装程序,良好的技术支持等。微软创造了很多界面规范,操作习惯,这些都是我们需要认真去学习的。
知识管理
软件开发团队是知识密集型的团队,学习再学习,是软件开发团队的重要特点。没有学习的团队,是没有活力的!
如何保证团队的每位成员都具备完成本项目的能力呢?就绪管理就是来解决这个问题的。
小组成员的6种角色,需要不同的技能来完成本职工作,任何一种角色技能的欠缺,都会影响最终解决方案。小组应该根据项目的前景,列出各成员所欠缺的技能,这些技能包括技术方面的也包括非技术方面的,安排相应的学习计划、培训计划,保证每位成员的技能都达到要求。
图三:就绪管理
就绪管理是知识管理的重要组成部分,知识管理还包括知识的共享和积累、技能的评估、技能提升机制等。从微软提供的系列认证,如MCSD、MCP等,大家就可以感受到微软系统的培训制度。项目团队的知识管理,应该在组织层面上进行,跨越项目组进行,每位团队成员都可以学习其他团队的经验,每位团队成员都可以共享知识给其他的团队。
MSF是灵丹妙药吗?
2000年我第一次参加MSF课程的时候,给我很大的震撼,微软的团队管理很有学问,而很切合我们这些软件开发人员的心声。MSF的团队管理办法,似乎就是解决我们开发团队管理问题的灵丹妙药。但实际上没有这么简单,这种管理办办法要成功,还必须满足这样的条件:
l 必须要有坦诚、积极、向上的企业文化。
没有这样的文化,什么“推动开发式沟通”、“质量投资”等原理是难以做到的。
l 团队中每一位成员都是能力相当水平相当的,没有素质特别差的成员。
这点做不到,是很难应用“为共同的前景工作”、“赋予小组成员权力”等原理的。
实际上这两点都是很难做到的,微软是通过招聘优秀的人来满足这两个前提条件,另外美国文化下成长的软件开发人员,都是很有主见,沟通很主动,表达能力强,也注重自我价值的,而我国开发人员,很多是少说话多干事,表达能力特别是书面表达能力差的。
当然难做到不代表做不到,MSF的团队管理中有很多值得我们学习、品味、实践的地方,我们要做的是掌握其精髓,结合我们自己的实际情况,灵活地用起来。本文结合我多年实践MSF经验,谈了自己的体会,希望对大家有用。