谈谈产品开发团队的配置管理规则

标签: 产品 开发 团队 | 发表时间:2014-08-24 02:05 | 作者:zhangmike
出处:http://blog.csdn.net

作者:张克强    作者微博: 张克强-敏捷307

在《 源代码管理的新15条建议 》中的第7条建议提到:每个团队应当对代码配置项和非配置项有所说明,不要假设每个团队新人都是代码配置管理达人,小心自以为是的新手加入一些自以为是的垃圾。虽然可以删除,但发现再删除,其本身就是成本。

在《 高效组织的配置管理计划》也提到了产品线层面的配置管理,那么产品开发团队的配置管理到底应该是什么样呢?本文试图来探讨下。

首先说明本文探讨的产品开发团队的特征。这里的产品开发是指围绕某产品或者产品线开发,其产品的生命周期是长于一年以上,为了改进产品,不断有新的要求得到实现满足,也会发现产品的缺陷,需要在开发中解决。 这样的产品开发是不同于短期合同外包项目的,其产品开发团队将较长期的承担此产品(线)的运行维护,增强修改,开发建设。应当说,当前大多数团队是属于这样的团队。

什么是配置管理规则?

配置管理规则这个说法也许过于学术化,讲白了其核心就是文件如何存放和版本升级。而规则即是团队共同遵守的约定。比如在某目录下存放会议纪要,为了便于查找会议纪要的文件名以会议日期开头,格式是YYYYMMDD。

为什么需要产品开发团队的配置管理规则?

1,开发团队是多人组成,规则能够让所有人查询,有依据,协同提供效率
2,产品开发是长期过程,文件会越来越多,如果没有一定的规则,将造成文件遗失或者难以查找。

谁来制定团队的配置管理规则?

团队负责人应当为团队长远的信息资产负责,组织团队成员来商量团队自身的配置管理规则。
如果团队存在配置管理员这样的角色的话,那么配置管理规则的起草和维护当然首先是配置管理员的事情。

团队的配置管理规则有哪些内容?

对于软件开发团队,显然首要的,源代码管理是规则重点覆盖的内容。对于源代码管理,要回答如下典型问题:
1,选择什么样的源代码版本控制工具?如果组织已经选定,或者历史上已经选定,那么需要遵循。这是基础工具,一般不会经常变化,而变化必须经过慎重的考虑,当然往往的这是组织级考虑的内容。所以这个问题对于绝大多数团队而言,不是问题,因为已经有选定的工具。
2,对于源代码,选择什么样的主干分支模式? 这是显著影响团队效率的选择,必须团队骨干一起来做决定,不同的主干分支模式适用于不同的场景,需要团队中此方面的达人来提供建议,如果团队内难以做决定,麻烦组织中的高手来设计本团队的主干分支模式也是应当的,甚至有组织邀请业界专家来为重要产品线设计主干分支开发模式,并制定规则。
3,对于选定的主干分支模式,有哪些操作注意点,具体而言比如如下问题:
3.1 什么情况下从主干拉出分支?
3.2 什么情况下合并分支到主干?
3.3 什么情况下从分支拉出分支?
3.4 什么情况下从主干合并到分支?
3.5 什么情况下从分支合并到分支?
3.6 什么情况下删除分支?
3.7 如果选择主干无分支,那么需要注意什么?有什么配套手段?
4,源代码检入时需要遵循什么规则? 如何书写检入说明? 是否需要与某个变更或者需求或者缺陷进行关联? 要先本地进行静态代码扫描? 先进行code review?还是后进行扫描,或者code review
5,哪些区域的代码是信息安全高等级代码? 访问级别比较高,团队外围成员需申请后才能访问?如何申请? 
6,哪些区域的代码是核心代码? 或者是红区代码,但凡此处代码修改,对应的测试范围需要扩大,关联到其它的系统?
7,为了协同工作,在工程师本地电脑上需要如何设置?
其次是文档,文档就存活时间而言,分为两类:第一类是其生命周期与产品相同;第二类是其生命周期与特定改进、事务或者项目相当,明显短于产品生命周期。
第一类文档可称为产品级文档,比如团队配置管理规则就应当是产品级文档,值得长期得到遵循并改进,此类文档典型有:
1,产品白皮书,产品介绍
2,产品功能目录,使用说明,系统功能树
3,产品应用架构,组件(系统,子系统、模块)结构图,组件(系统,子系统、模块)接口说明
4,产品性能架构,并发控制,处理高性能要求的架构模式
5,团队章程,团队改进建议
6,产品待办需求列表,原始需求

第二类文档可称为项目级文档,此类文档是大家最熟悉的文档,如下:
1,项目计划
2,项目需求规格说明书
3,项目会议纪要
4,项目测试计划

对于两类不同的文档,对于团队配置管理规则而言,产品级文档的处理是焦点,因为这是长期的文档。

团队的配置管理规则的好处

往大里说,团队配置管理规则处理的是产品信息资产,当然是值得精心制定并切实执行的。
往小里说,良好统一的协同工作平台能提升团队协作效率,让每个工程师顺畅的工作。







作者:zhangmike 发表于2014-8-23 18:05:10 原文链接
阅读:0 评论:0 查看评论

相关 [产品 开发 团队] 推荐:

谈谈产品开发团队的配置管理规则

- - CSDN博客研发管理推荐文章
作者:张克强    作者微博: 张克强-敏捷307. 在《 源代码管理的新15条建议 》中的第7条建议提到:每个团队应当对代码配置项和非配置项有所说明,不要假设每个团队新人都是代码配置管理达人,小心自以为是的新手加入一些自以为是的垃圾. 虽然可以删除,但发现再删除,其本身就是成本. 在《 高效组织的配置管理计划》也提到了产品线层面的配置管理,那么产品开发团队的配置管理到底应该是什么样呢.

Medium开发团队谈架构设计

- - 博客园_知识库
  说到底,Medium是个社交网络,人们可以在这里分享有意思的故事和想法. 据统计,目前累积的用户阅读时间已经超过14亿分钟,合两千六百年.   我们支持着每个月两千五百万的读者以及每周数以万计的文章发布. 我们不想Medium的文章以阅读量为成功的依据,而是观点取胜. 在Medium,文章的观点比作者的名头更重要.

成功产品的规律及团队角色职责

- Hu DongHai - 《程序员》杂志官网
文 / Marty Cagan 译 / 兰蔚 刘雁. Marty Cagan是享有世界声誉的产品管理专家,曾经担任网景副总裁、eBay产品管理及设计高级副总裁. 本文是他回顾自己二十多年来从事软件产品管理工作的总结和经验分享,谈到了成功产品遵循的十条规律以及产品团队的关键角色及其职责. 20世纪80年代中期我还年轻,在惠普担任程序员,参与开发一款备受瞩目的产品.

UED团队中有一种角色叫“产品文案”

- chaim - 互联网的那点事
当初设置这个岗位的时候,在发布对外招聘信息时,想当然的就写了“文案策划”,结果后续接收到的90%都是文才非凡的才子佳人,不是某报的编辑,就是某某文章高手,一时让招聘工作陷入僵局. 百度百科上对“文案策划”的定义是这样的:“文案的专业是编辑、撰写广告文字内容或影视媒体中的对话、旁白,具体产品是:广告语、大标题、内文等,总之是一切给写给消费者(最终广告受众)看的东西.

产品负责人与团队该如何协作?

- - InfoQ cn
近日,由 Henrik Kniberg撰写的博文 agile product ownership in a nutshell从产品负责人的角度高度总结了敏捷软件开发. Henrik称其为“将一天的产品负责人课程压缩为15分钟的精彩介绍”. 他建议大家观看一个 关于敏捷产品所有权的视频,该视频提供了相应的脚本.

腾讯广告平台产品团队谈PhoneGap使用

- - InfoQ cn
“ HTML5状况及发展形势报告”回顾了2012年HTML5的发展历程,并预测了2013年的趋势,就报告看来HTML5在移动终端领域将会有大的发展. 在进行跨移动终端的应用设计时,开发者普遍会选择一些框架来处理业务无关的技术细节,本期我们采访到了腾讯广告事业部设计中心总监董霙,请他和他的团队谈下在使用移动开发框架 PhoneGap时的感受.

浅谈产品团队分工的管理

- - 互联网的一些事-关注互联网产品管理,交流产品设计、用户体验心得
  团队的分工协作一直是管理学家们乐于研究的一个命题,良好的团队分工可以使团队运转的更加高效,产出的效率也会有明显的提升,这都取决于分工的合理. 产品经理要将工作分成若干个部分,分别合理的派发给不同的对象去执行,使团队成员都清楚明确的知道自己的工作任务和目标,以及完成工作的方式和方法,这样才能完美的达到分工协作的目的.

谷歌前产品经理谈创业团队管理:做好情景管理,控制团队规模

- - ITeye资讯频道
原文作者Tomasz Tunguz是Redpoint Ventures的风险投资人,曾在Google担任产品经理并参与过AdSense项目. 在文中,Tomasz Tunguz针对创业公司给出了2条极富实践性的建议: 针对不同类型的员工,做好激励和情景管理;努力平衡控制范围和管理职责范围(下文由 36Kr进行编译整理).

乔布斯的团队如何体会新用户的产品体验 ?

- - 博客园_新闻
3 月 23 日消息,iPod 之父托尼·法德尔日前在 TED 上进行演讲,分享了他从乔布斯身上学到的东西. 乔布斯坚持他的设计团队应该保持初学者的心态:去亲身体会那些从没有体验过一款产品的人的感觉. 苹果新产品上市时,和其他消费者一样,法德尔也会去苹果零售店排队,买新产品在柜台结账,然后开箱使用.