软件团队管理心得杂烩

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

笔者注:本文内容为本人从业12年以来的心得总结,仅供参考,谢谢。

软件产品分类

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

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

/贴吧/论坛……CRM 、OA ……

软件其它维度的分类方式

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

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

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

●按发布手段划分{租赁(限期加密锁)、零售、在线、部署、运维}

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

●按软件架构划分{集中式、分布式(B/S, C/S)}

●按软件技术特点划分

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

例:文字处理软件、印刷排版软件、CAD软件、编织打版软件,

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

(2)技术中心类:以核心技术做为支撑,技术难度大的软件。

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

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

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

(3)业务中心类:以工艺流程或业务流程为中心的软件。

例:服务平台类软件(工具类和内容类除外)、业务系统类软件。

(4)内容中心类:以提供内容为中心的软件。

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

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

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

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

软件开发过程模型

世代划分模型

对于大规模软件(指功能量级和代码量级大):

对于中小规模软件:

对于技术中心类软件:

滚动更新模型

……

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

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

请记住以下事实:

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

软件版本四级标准

I.可调试:可以启动运行,进行针对功能的开发调试。

II.可演示:实现功能基本效果、跑通一条基本流程,又分为局部可演示和整体可演示。III.可实用:功能完整、流程畅通、可以用于实际生产或应用。

IV.产品化:注重细节、产品设计(含美工)优秀、用户体验度高、有很强的市场竞争力。

软件版本划分

周期类别

●开发过程版:新功能开发过程中的版本

●Alpha版:可用性测试版本

●Beta版:稳定性测试版本

●正式版:正式发布版本

●更新版:正式版发布后,定期更新的版本

※经过beta版本的测试后,确定了发布候选版本(RC版, Release Candidate),明确了最终必需修改的问题清单,经过一个非常短暂的修改+测试过程,

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

过程类别

例行测试版:以固定周期和时间点发布给测试团队的版本。(参见最末节对软件测试的阐述。)对外发布版:可以对外发布、部署或上线运营的版本。

软件研发团队角色分工

大的分工图

还记得这个图么(见《关于研究者心态》):

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

软件研发团队内部的分工

●需求(产品)角色-决定目标、明确方向

成果物:产品规划文档、需求规格文档、原型设计、需求追溯表(其他参见下一节)

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

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

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

需求导向是市场导向的具体体现,需求应是研发团队中权力相对更大的,有对开发和测试进行需求说明和指导的权利和义务,有权决定一个功能是否必须实现、一个Bug 是否必须修改。需求角色有对开发和测试的工作进行监督的权力。

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

成果物(项目管理):过程管理体系、过程资产库、过程管理工具

成果物(项目助理):软件开发里程碑计划表

(如果企业不是按项目配置资源的话)项目管理角色应属于“过程管理研究团队”,对产品研发团队的过程管理起指导、支持和监督的作用。其工作内容包括:

(1) 指导职责:制定过程管理制度体系和执行细则(如依据CMMI),制定软件过程

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

(2) 支持职责:选定适合的过程管理工具(如项目管理平台或Project),对各产

品研发团队进行过程管理体系和过程管理工具培训,接收过程管理工具使用的

问题反馈。

(3) 监督职责:对各产品研发团队执行过程管理的情况进行巡视和督促,QA专员

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

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

(1) 团队成员会觉得自己不被决策者信任,自己的空间被挤占,产生逆反心理;

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

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

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

●开发角色-关注方法(包括架构、设计、流程和逻辑),实现版本

成果物(模型或技术中心类):总体设计文档、功能单元详细设计文档、关键技术文档成果物(业务中心类):概要设计文档、详细设计文档、接口设计文档

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

相关文档
最新文档