软件团队管理心得杂烩.docx

软件团队管理心得杂烩.docx

《软件团队管理心得杂烩.docx》由会员分享，可在线阅读，更多相关《软件团队管理心得杂烩.docx（12页珍藏版）》请在冰豆网上搜索。

软件团队管理心得杂烩

笔者注：

本文内容为本人从业12年以来的心得总结，仅供参考，谢谢。

软件产品分类

理清软件产品的分类，是我们讲述一切问题的根本。

按照软件产品特点共分了5个大类，每个大类软件都有各自的特点，产品策略、盈利模式、开发过程和管理模式都是各不相同的。

软件其它维度的分类方式

●按软件对企业的作用划分｛战略目标、过程手段｝

●按盈利模式划分｛合同项目、通用产品、运营、广告嵌入｝

●按用户和研发的关系划分｛定向用户、广泛用户｝

●按发布手段划分｛租赁（限期加密锁）、零售、在线、部署、运维｝

●按产品策略划分｛世代划分模式、滚动更新模式｝

●按软件架构划分｛集中式、分布式（B/S,C/S）｝

●按软件技术特点划分

（1）模型中心类：

以建立数学模型、图形模型或文档对象模型为中心的软件。

例：

文字处理软件、印刷排版软件、CAD软件、编织打版软件，

2D/3D绘图或制图软件、电子游戏软件等。

（2）技术中心类：

以核心技术做为支撑，技术难度大的软件。

例：

数据安全和备份软件、网络信息安全软件、网络信息监控软件、

多媒体信息处理软件、人体特征识别软件、压缩与加解密软件、以及

服务平台类中的工具类软件等。

（3）业务中心类：

以工艺流程或业务流程为中心的软件。

例：

服务平台类软件（工具类和内容类除外）、业务系统类软件。

（4）内容中心类：

以提供内容为中心的软件。

例：

服务平台类中的内容类软件。

以上四大类软件，研发团队的角色人力配比、各类角色的工作重心、工作计划策略等都是不相同的，要根据各类软件自身的特点来决定，不可一概而论。

譬如业务中心类的软件，比较适合于下述的滚动更新模型；工作计划策略适合于“时间点-成果物”模式（到既定的时间点必须提供要求的成果物）。

而模型中心和技术中心类的软件，比较适合于下述的世代划分模型；在开发前期工作计划策略比较适合于“步骤-跟踪”模式（预先识别技术难点，制定详细可行的工作步骤，定期跟踪进展，动态调整下一步工作计划）；进入规模化开发期或系统集成期之后，才适和采用“时间点-成果物”模式。

软件开发过程模型

世代划分模型

对于大规模软件（指功能量级和代码量级大）：

对于中小规模软件：

对于技术中心类软件：

※注：

后维护期一般要持续到下一世代的第一个正式版本发布为止。

滚动更新模型

这种适用于规模量级较小，不需要维护期的软件产品。

以上模型中，都强调了“稳定期”的概念，这是很多团队比较忽略的问题。

请记住以下事实：

没有软件是没有Bug的，没有软件是一开发完成即可实用的，这与软件规模量级无关。

软件版本四级标准

I.可调试：

可以启动运行，进行针对功能的开发调试。

II.可演示：

实现功能基本效果、跑通一条基本流程，又分为局部可演示和整体可演示。

III.可实用：

功能完整、流程畅通、可以用于实际生产或应用。

IV.产品化：

注重细节、产品设计（含美工）优秀、用户体验度高、有很强的市场竞争力。

软件版本划分

周期类别

●开发过程版：

新功能开发过程中的版本

●Alpha版：

可用性测试版本

●Beta版：

稳定性测试版本

●正式版：

正式发布版本

●更新版：

正式版发布后，定期更新的版本

※经过beta版本的测试后，确定了发布候选版本（RC版,ReleaseCandidate），

明确了最终必需修改的问题清单，经过一个非常短暂的修改+测试过程，

确定正式版本。

如果此过程非常短暂，RC版本无需做为一个独立的版本周期类别。

过程类别

例行测试版：

以固定周期和时间点发布给测试团队的版本。

（参见最末节对软件测试的阐述。

）

对外发布版：

可以对外发布、部署或上线运营的版本。

软件研发团队角色分工

大的分工图

还记得这个图么（见《关于研究者心态》）：

套用到软件研发团队，我们来变化一下：

软件研发团队内部的分工

●需求（产品）角色－决定目标、明确方向

成果物：

产品规划文档、需求规格文档、原型设计、需求追溯表（其他参见下一节）

这里说的是广义的需求角色，包含软件产品角色和需求分析角色。

另外，也包含

用户体验角色（产品设计、美工）和用户教育角色（帮助文档或用户手册编写）。

工艺流程的分析设计，以及数据规格或SDK接口规格的汇总统筹工作也包含在内。

需求导向是市场导向的具体体现，需求应是研发团队中权力相对更大的，有对开发

和测试进行需求说明和指导的权利和义务，有权决定一个功能是否必须实现、一个Bug是否必须修改。

需求角色有对开发和测试的工作进行监督的权力。

●项目管理和项目助理角色－关注过程

成果物（项目管理）：

过程管理体系、过程资产库、过程管理工具

成果物（项目助理）：

软件开发里程碑计划表

（如果企业不是按项目配置资源的话）项目管理角色应属于“过程管理研究团队”，

对产品研发团队的过程管理起指导、支持和监督的作用。

其工作内容包括：

（1）指导职责：

制定过程管理制度体系和执行细则（如依据CMMI），制定软件过程

各环节的成果物文档模版，维护企业的过程资产库。

（2）支持职责：

选定适合的过程管理工具（如项目管理平台或Project），对各产

品研发团队进行过程管理体系和过程管理工具培训，接收过程管理工具使用的问题反馈。

（3）监督职责：

对各产品研发团队执行过程管理的情况进行巡视和督促，QA专员

在软件产品正式发布前对其质量指标进行审核确认。

如果项目管理角色直接介入研发团队，做为实施者，其弊大于利：

（1）团队成员会觉得自己不被决策者信任，自己的空间被挤占，产生逆反心理；

（2）项目管理角色做为实施者，会因第一点以及决策者给予的压力，沦为团队

实际上的主管，实际担负了过多的责任，很累，而自己做为过程管理专家

原本的作用反而发挥不出来了。

●开发角色－关注方法（包括架构、设计、流程和逻辑），实现版本

成果物（模型或技术中心类）：

总体设计文档、功能单元详细设计文档、关键技术文档

成果物（业务中心类）：

概要设计文档、详细设计文档、接口设计文档

需负责单元测试（即理论上的单元测试，针对代码基本单元进行的自动化测试）。

●测试角色－参与过程、保证结果

成果物：

测试设计文档、测试报告文档。

与工业生产中的质保或品控不同，软件测试不仅要保证结果，也要参与到过程中来。

测试要参与需求讨论和评审，在开发做开发设计的同时编写测试设计（即用例设计）。

测试对于例行测试版本，特别是功能未开发完全时期，主要关注已实现功能的正确性和可用性（即以功能测试为主）；对于（准）对外发布版本，关注版本整体的可用性和稳定性（即以综合测试为主）。

在必要的时候，测试需要到开发现场进行现场测试，譬如开发有重要变更要提交之前，或临近正式版本发布的时候，现场测试可以加快开发与测试的交流、加速版本的稳定，

起到很好的作用。

●

软件需求过程

上图体现了需求工作的两个层次，同时也反映了测试工作的两个层次。

下图是软件需求工作流程的一种实例。

软件测试工作原则分析

零信任原则

测试对开发是零信任的。

就是说开发在开发过程中除单元测试外，当然是对功能做过了简单的集成测试（白盒测试），但是这不意味着测试可以不对功能作细化的用例覆盖。

因为测试是保证软件质量的最后一道关口，一旦软件到了用户手里暴露出了问题，对软件产品和团队的负面影响很大，有时甚至是致命的。

根本原则

软件测试对软件版本负责，保证软件版本整体的可用性，包括功能、流程和效率。

这意味着，需要有与需求规格一致的、详细的测试用例清单，每一个软件版本的测试对于每一个功能点、每一条流程分支都要覆盖到位。

简化的原则

软件测试只对变更负责，即只保证本次软件版本变更的部分的可用性。

未变更的部分的可用性则由开发团队负责保证。

由于功能或模块之间总是存在关联影响的（特别是实现了很多底层机制的大规模软件），这种简化的测试原则，使得软件质量下降或出现严重问题的风险，增加很多。

Bug趋势图

一般来说，新功能提交后，Bug总会有一个从爆发到收敛的过程，Bug趋势曲线是判断软件版本是否稳定、是否可发布的重要标准。

这里不打算对此问题展开赘述了，请参见以下资料：

Bug数量做为绩效考核指标

由上，一定要鼓励测试人员多多提Bug，各方各面的提。

Bug数量足够，Bug趋势才能发挥出作用来。

因此，Bug数量一定是对测试角色的考核指标，一定不能是对开发角色的考核指标。

这里的意思是说，不要因为Bug爆发而对开发做绩效减分，但Bug数做为开发任务目标是可以的，譬如“本迭代周期的正式版本发布前，人均严重Bug为0，非严重Bug数降至15个以下。

”

版本可测的定义（也即严重问题的定义）

指对于例行测试版本来说，是否存在阻碍或严重影响测试工作的Bug。

包括但不仅限于下列情形：

1.无法正常启动

2.操作流程不贯通（对于业务中心类软件）

3.待测功能缺失或被屏蔽

4.待测功能存在崩溃、死锁或过多的Bug，致功能不可用

5.待测功能执行效率低下

6.软件实现与需求规格严重不符合