软件团队管理心得杂烩.docx
- 文档编号:17540393
- 上传时间:2023-07-26
- 格式:DOCX
- 页数:12
- 大小:430.20KB
软件团队管理心得杂烩.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.软件实现与需求规格严重不符合
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 团队 管理 心得 杂烩