- 浏览: 985981 次
- 性别:
- 来自: 杭州
文章分类
- 全部博客 (826)
- 硬件 (8)
- 软件 (24)
- 软件工程 (34)
- JAVA (229)
- C/C++/C# (77)
- JavaScript (8)
- PHP (1)
- Ruby (3)
- MySQL (14)
- 数据库 (19)
- 心情记事 (12)
- 团队管理 (19)
- Hadoop (1)
- spring (22)
- mybatis(ibatis) (7)
- tomcat (16)
- velocity (0)
- 系统架构 (6)
- JMX (8)
- proxool (1)
- 开发工具 (16)
- python (10)
- JVM (27)
- servlet (5)
- JMS (26)
- ant (2)
- 设计模式 (5)
- 智力题 (2)
- 面试题收集 (1)
- 孙子兵法 (16)
- 测试 (1)
- 数据结构 (7)
- 算法 (22)
- Android (11)
- 汽车驾驶 (1)
- lucene (1)
- memcache (12)
- 技术架构 (7)
- OTP-Erlang (7)
- memcached (17)
- redis (20)
- 浏览器插件 (3)
- sqlite (3)
- Heritrix (9)
- Java线程 (1)
- scala (0)
- Mina (6)
- 汇编 (2)
- Netty (15)
- libevent (0)
- CentOS (12)
- mongod (5)
- mac os (0)
最新评论
-
kingasdfg:
你这里面存在一个错误添加多个任务 应该是这样的 /** * ...
Quartz的任务的临时启动和暂停和恢复【转】 -
kyzeng:
纠正一个错误,long型对应的符号是J,不是L。
Jni中C++和Java的参数传递 -
zhaohaolin:
抱歉,兄弟,只是留下作记录,方便学习,如果觉得资料不好,可以到 ...
netty的个人使用心得【转】 -
cccoooccooco:
谢谢!自己一直以为虚机得使用网线才可以与主机连接呢。。
主机网卡无网线连接与虚拟机通信 -
yuqilin001:
要转别人的东西,请转清楚点嘛,少了这么多类,误人子弟
netty的个人使用心得【转】
老蔡
说:
1、背景
2、存在问题
3、制度与监控
4、QA审计方法与组织级技术
管理
的介入点
我们业务软件
分公司,有200+人员,下设业务拓展部(市场),5个产品线(开发为主)、集成、支撑等各部门
此外,还有一个项目推进部(PMO)
产品线下设各项目组。需要注意的是,由于产品线由经营指标导向,而项目组是产品线下属机构,所以,PMO实际上只是一个弱PMO。
这种组织结构形成有历史原因。即使从现状看,也不可能做成强PMO,因为毕竟各产品线的业务各异,与客户、各干系人的接口不可能通过PMO进行。
实际上,有一定矩阵式的特点。
产品线经理的考核,主要是经营指标导向的,虽然也有一些其他指标,但明显弱多了。
因此,产品线经理非常注意经营指标,而忽视其他一些关键指标,甚至出现一些短期行为,这都是可以理解的。具体的说,主要有以下问题:
1、项目管理
的随意性。名义上,产品线下属的单位是3-5个项目组,项目组的负责人叫项目经理。实际上,这些项目经理即便上了PMP课,在实际工作中,仍是非常随意的作坊式工作。而产品线经理不会对这些进行辅导,只关注客户的实时要求、经营指标等。
2、对质量的极度忽视。在CMMI的观点中,把质量提高到前所未有的高度。在我们的实践则相反,只要用户无投诉,基本上不会当成项目经理什么大的过失,软件做的好坏完全以客户评价定。
3、由于无质量要求,那么系统设计、技术架构、新技术引入也都谈不上,开发工作在低水平上重复,代码复制率很高,复用率很低。这样,开发人员就缺乏一种技术成长的感觉,也会缺乏团队归属感。
Kerry 说:
产品经理的确只对产品的特性负责,项目经理对项目进度、风险、成本等进行管理
老蔡
说:
4、由于管理的随意性,人为偏好,技术成长困难等因素,导致员工的受挫感的传播,团队难以形成好的氛围。
Kerry的问题我先解释下。我们的
“
产品线经理
”
是项目经理的直接领导,PMO不是项目经理的领导。所以,他们负责的面向是完全一致的。其他问题等最后一起聊吧。
5、各类管理信息无法到达分公司管理层,导致分公司工作被动,有时是客户投诉到总公司时,分公司领导才得知此事的情况。至于组织层面的整体技术管理,根本不可行,如同昨天说到的知识
管理案例也是这么回事。
根据以前管理产品线的经验,针对这些问题,我的考虑是(1)通过《项目流程》的制度,把职责、流程、流程中各角色职责、基本行为规范、基本软件过程定下来。
(2)通过组织级QA审计,检查各项目的流程执行情况,同时取得一手信息,避免信息被项目经理、产品线经理两个管理层面屏蔽。
(3)在信息通道打开之后,技术管理等其他管理手段逐步介入。
现在就着上传的4个文档
给大家说明一下我们的工作方法
Richard李明-项目主管-北京 说:
嗯 有流程,信息流动好像不是很好
老蔡
说:
李明的问题,正是我要说的。
Richard李明-项目主管-北京 说:
请继续哈
老蔡
说:
首先,流程执行的第一个要求是客观,实际怎么执行,怎么表达。
我们是行业应用软件,一是软件开发流程,这是一个时间段。在这个时间段中,可能会出很多很多版本,一般1周至1个月出一个版本。
出版本后,要升级到现有系统去,那么就需要制作升级包,升级手册、数据库
脚本什么的。升级操作是一个
“
点
”
而不是一个时间段,但由于它非常重要,所以我们也要记录和审计。
打开《版本开发流程单》,这份文档,就是要求每个迭代版本开发时填写。
评审等过程,简化为签字,而不像CMMI要求的那样出评审报告。
对于大的版本,比如1个月出一次的,一般来说,会有与用户的原始交流,即用户提出原始需求
。
然后需求人员进行分析,出需求规格文档。
再和开发人员、项目经理开会,确认做哪些,哪些跟客户解释不做或以后做。这个会议,不要求出评审报告和会议纪要,只要相关开发人员签字认可。
接下来项目经理根据大家评审的结果,进行规划版本;后是测试
。
最后项目经理审核整个版本包,产品线经理复核。
如果是一个紧急补丁,很多过程可以简化。
这样,实际上用于
“
流程
”
的时间,也非常少。
等到版本或补丁制作完,开始准备上线时,需要进行现网操作审核
这个细节就比较多,因为维护支撑部其实没有参与前期的开发,那么他们就会对项目组期待很大,而自己不去关心版本的内容。另一面,项目经理也会有同样的期待,这里就有一个漏洞了。
QA审计要关注到这个升级操作是否明晰,是否可执行,是否可回退等。
甚至,如果现场实施人员,同时也是次日保障人员,是否可能?对于一个简单的补丁一般没有问题,但如果大版本肯定不行。
这样,理论上,项目成员只用了签字、填表的时间成本,就把关键的项目信息都透明出来了。
补充上,刚才漏了。在CMMI中,提倡对每个项目的软件过程进行定制。
在实践中,我认为基本不可能。
所以我的做法是,根据项目的重要程度,新系统开发还是迭代式,分别管理。具体见《项目检查点》上的说明。
这样,PMO维护一份项目清单,同步给各产品线,大家按照项目检查点上的要求,结合整体的项目流程,这样实际上就等同于,定义了5-6种标准过程,选择使用(PMO与产品线事前沟通选择)
最后说下执行的情况。
在最初,我摸索这个方法的时候,尽管要求项目成员填写的信息不多,但通过有限的信息,以及相关的工作产品文档,可以发现一些疑点或不清晰的地方,然后找相关人员访谈确认(这个访谈也跟CMMI不同,重实质不重形式上的覆盖率)。
这样,发现了很多并不是一般意义上的流程执行问题。
例如,可以发现补丁包制作错误,发回项目组重做后,才同意上线。
(严格的说,是否同意上线不是QA的权力,QA审计是事后的审核点。因我是分公司管理层,才可以这么做)
当我把这个方法移交给QA时,发现执行情况不理想。受CMMI熏陶过多,每个流程单十几分钟就审核完了,要么就是完全违反流程,要么就是没有任何问题。
为此,我重新考虑了我自己的审核的方法,设计了《QA审计报告》文档。本来我认为QA审计应该不受限于审计报告,而以主观经验带入为好,但这样导致我对QA无法监督,而QA发现问题越少也无所谓。现在不得以加入文档化的审计报告
这样,一方面,审计报告中体现出QA对项目原始数据的搜集。这些搜集主要不是通过询问项目人员,而是访问SVN、Jira等
通过原始数据的搜集后,对于软件过程审计,应当能分析出一些有意义的结果。
什么是有意义的结果呢?例如,一个大版本,开发人员200的,有测试报告,但Jira上却没有BUG记录?或者只有少量的小BUG,这肯定不对。
“
软件产品质量审计
”
这个小节,侧重关注产品定义是否清晰,实际上与配置管理关系很大。很多项目组的配置管理非常混乱。
部署包和升级步骤,基本上就是组织级技术管理的主要介入点之一(新系统开发的评审也是重要的介入点)。
在这个点上加强控制,可以提高升级的成功率,减少回退和次日的问题数量、紧急补丁数量。
这个部分,也是要求QA做独立意见的。
徐文锦 - IT Consultant - singapore 说:
问一下 你们有几个环境 除了dev 和production
老蔡
说:
当我看到审计报告时,如果对QA意见明显不认可,可以找QA谈,顺便指导QA的工作。
最后,版本上线情况跟踪分析,实际上形成了一个闭环。
可以关注到,项目经理、产品线经理是否有进行后续跟踪(很多产品线经理根本不管)。
然后与其他版本建立相关性,可以分析是否存在屡次升级失败,是什么原因等。
通过这个审计报告模板,基本上QA的工作可以保证达到一定的细腻度。对于分公司层面进行上线最后的确认也不会太盲目。
主要内容就这些了。麻烦徐文锦再表述一下问题?
徐文锦 - IT Consultant - singapore 说:
我说的是, 从开发环境 到 生产环境 中间还有几个环境几个步骤
老蔡
说:
正常情况下,开发环境就是开发人员的工作电脑+数据库;测试环境在公司,也独立于开发环境。生产环境不在我们公司。
独立的测试环境,和正确的版本制作方法,理论上可以保证版本升级的正确性。
不过,在实践中,项目组混同开发与测试环境的事情也不少见
各位,还有问题吗?
徐文锦 - IT Consultant - singapore 说:
个人感觉 不让开发人员接触测试环境 即QAT 可以较大的提高软件质量.
老蔡
说:
是的,我们是这个要求。但是,从分公司管理层面,到开发人员有管理层级的差距。如果去问项目经理,很可能还告诉你他们分的很清楚,只有在工作实践中的QA数据才能发现问题。
吴柯-管理-北京 说:
你们是为自己的母公司开发软件吗?
老蔡
说:
不是,为电信行业客户开发。
吴柯-管理-北京 说:
哦,一个大软件公司,业务软件分公司是一个大产品线
老蔡
说:
不是。我们的分公司,你可以理解成一个独立公司,除了财务不在我们,其他职能多少有一些。
吴柯-管理-北京 说:
哦
产品版本和项目版本怎么同步?
lastwinner-pm-bj 说:
跟上进度了,老蔡今天讲的这个层次相对较高了
我想问一下,这样做,对QA的技术素质貌似要求很高呀?
老蔡
说:
无所谓产品版本和项目版本,在配置管理混乱的情况下,只能根据各个项目的实际控制来说。实际上,基本是一个地点的一个项目一个版本。产品,只是概念上的,用于包装给客户的。
徐文锦 - IT Consultant - singapore 说:
QA
其实是软件开发中非常重要的一个环节
吴柯-管理-北京 说:
这样啊
徐文锦 - IT Consultant - singapore 说:
microsoft
的office team dev和qa的比例达到1:10
老蔡
说:
lastwinner,由于历史原因,我这边的QA薪酬相当不低。
徐文锦 - IT Consultant - singapore 说:
而且严格的项目一般是要求qa或者专门的deployment team 出包和部署
吴柯-管理-北京 说:
哪质量难以得到保障,产品发展代价反而更大
lastwinner-pm-bj 说:
怪不得分配的任务要求这么高
徐同学说的微软
的情况,国内很多公司够不适用的,连用友这样的公司都做不到
徐文锦 - IT Consultant - singapore 说:
我觉得国内公司 特别是小公司对于qa的要求太低 很难保证产品质量
吴柯-管理-北京 说:
比如一个项目里发现的BUG,修改后其他项目未必用得上
lastwinner-pm-bj 说:
国内很多公司都不适用的(刚把 都 打成 够 了)
老蔡
说:
我们是要求测试人员出包。即开发人员宣称代码已经好了,然后测试人员打上版本标签,从SVN库中取文件,用事先提供后的脚本构造编译出包。实际上,个别项目组做的到,大部分做不到。
吴柯-管理-北京 说:
这个是对的
徐文锦 - IT Consultant - singapore 说:
一般这个过程可以采用自动集成/编译/部署 ,不过一般需要专门的部署团队
吴柯-管理-北京 说:
版本一定要专人
老蔡
说:
我的方法是,开发人员可以帮助测试人员写脚本。但提交测试和部署的版本包,一般是在开发人员无法接触的情况下生成的。
吴柯-管理-北京 说:
除了SVN以外,还用到什么辅助开发管理的工具吗?
lastwinner-pm-bj 说:
老蔡你说的 "做不到",指的是代码的版本管理做不到还是说实际上他们宣称的代码已做好是不符合实际的?
老蔡
说:
这样,只要测试通过的包,拿去升级一定没有问题。
lastwinner-pm-bj 说:
老蔡-技术总监-福州 says (13:24):
这样,只要测试通过的包,拿去升级一定没有问题。
这话太绝对了,不过这样做可以说99.9%的情况下都不会有问题
徐文锦 - IT Consultant - singapore 说:
如果你有兴趣可以研究一下TFS 和微软一整套的软件开发流程
老蔡
说:
lastwinner,是项目经理的意识做不到。我现在的工作层次在组织级项目管理。
lastwinner,别这么认真啊,其实99%没问题就已经非常非常好了。我们目前升级的回退率大概5%,加上升级有问题的情况,应该快10%了。
徐文锦 - IT Consultant - singapore 说:
一般比较正交的测试 把bug降低到1%问题还是不大的, 如果有会写代码的qa 那么还会再降低Bug率
lastwinner-pm-bj 说:
如果是意识问题,那么通过你的方法灌输下去,多数项目经理就能具备这样的意识,对吧?
老蔡
说:
不只是灌输啊,要循序渐进,慢慢渗透进去。
项目经理真想做,一定能做到的。
吴柯-管理-北京 说:
一个产品同时支持多个客户?
多少个?
老蔡
说:
大部分产品是1个。现在慢慢2-4个的,但实际上,那个产品也有很大变更。你理解成项目或许更好些。
徐文锦 - IT Consultant - singapore 说:
问一下, 谁为版本回退/部署失败 负责?
吴柯-管理-北京 说:
以现场客户开发为主,还是在公司开发测试完后在现场只是部署?
老蔡
说:
项目经理
在公司开发为主。
吴柯-管理-北京 说:
这个是电信的行业特点,还是你们公司的业务特点,我们公司做金融行业,大部分是现场开发?
老蔡
说:
电信行业,一般不会大部分现场开发。金融行业,听说大部分是现场开发。
吴柯-管理-北京 说:
公司开发要求客户的需求质量比较高,变动也不能太多
你们这方面如何控制
徐文锦 - IT Consultant - singapore 说:
毕竟你们和钱打交道....软件质量会要求比较高
lastwinner-pm-bj 说:
这种管理方式感觉能让PM较快的成长起来,而且能对自己的工作职责范畴有清晰的了解
MicrosoftInternetExplorer402DocumentNotSpecified7.8Normal0吴柯-管理-北京 说:
客户不参与最后的测试吗?
徐文锦 - IT Consultant - singapore 说:
应该是参与的吧
吴柯-管理-北京 说:
你们测试完就直接上线?
蔡晓东 说:
新系统开发,会参与,但参与度低
徐文锦 - IT Consultant - singapore 说:
不过国内的就不好说了....电信那些人- -#
蔡晓东 说:
迭代式,很多情况已经是在线系统了,客户要求我们1-2周上一次版本,他们没有精力陪我们测试。要测也是等上了再说。
差不多了吧,这次记录我自己发吧
吴柯-管理-北京 说:
我们一般1-2个月一次,1-2周会不会有些短,从需求、涉及开发到测试?
徐文锦 - IT Consultant - singapore 说:
如果是迭代的话这个时间不算短,
瀑布就惨了
蔡晓东 说:
行业不同。有时客户会要求2-3天来一次。
吴柯-管理-北京 说:
哦
徐文锦 - IT Consultant - singapore 说:
你们是如何避免涟漪效应的, 就是你改了一个地方 其他其他也受影响
吴柯-管理-北京 说:
差异还真大
蔡晓东 说:
当然必须迭代。不过目前主流过程对迭代支持都不好。scrum可能会好,但是,scrum的客户参与等是不可用的,我们必须把客户做干系人管理,而不是类同团队成员。
老徐的问题,分两个层面:项目层面,看经验;组织层面,就只能在QA质量审计,QA或者分公司管理层发现疑问,追溯下去分析了。
吴柯-管理-北京 说:
用了scrum吗?
蔡晓东 说:
没有,我是在自己的方法论形成之后,才知道Scrum。感觉Scrum也是受应用场景限制的。
发表评论
-
使用Maven创建JAR工程和打包依赖(转)
2012-10-12 00:29 775添加PLUGINS <plugins> ... -
Eclipse Code Review(代码审查)工具介绍【转】
2011-04-16 01:15 1433最近组内一直在做代码 ... -
敏捷开发中的Code Review [转]
2011-04-16 01:08 1260一些敏捷团队在实施敏捷开发中忙于编码、忙于Unit Tes ... -
闲谈绩效考核——来自项目管理群的讨论[转]
2011-04-14 21:34 907不胜人生 一场醉 说 ... -
项目管理系列文章——关于软件工程在软件整个生命周期的位置[转]
2011-04-14 21:33 826关于软件 工程在软 ... -
项目管理实例—— 点评[转]
2011-04-14 21:32 804查看( 579 ) / 评论( 0 ... -
从工程师到管理者转变——来自项目管理群的讨论
2011-04-14 21:31 822城市兔子—技术主管—北京 说: Hi,各位,大家好。刚吃晚 ... -
项目管理经验谈——来自项目管理群的讨论[转]
2011-04-14 21:23 956项目管理 经验谈——来自项目管理群的讨论 ... -
PM如何整合资源——来自项目管理群的讨论[转]
2011-04-14 21:22 1006空间管理 您 ... -
知识的分享和管理——来自项目管理群的讨论
2011-04-14 21:16 827谷雨霖pharos-cto-北京说: 今天和大家交流最近看 ... -
假如我是一个项目总监/经理——我手写我心[转]
2011-04-14 21:06 998就国内中小民营企业 而 言,项目总监/经理的角 ... -
假如我是一个部门经理——我手写我心[转]
2011-04-14 20:58 966假如我是一个部门经理 ... -
项目经理的思维批判
2010-12-07 21:46 731想做好项目经理,就一定要改变你的思维方式。这对于技术出身 ... -
架构组织管理
2010-12-07 21:42 958架构组织管理的五大 ... -
克服在企业中应用敏捷方法的技术挑战
2010-12-07 21:41 837在企业中应用敏捷方法是一项具有挑战性的任务。实现敏捷不像 ... -
带领团队发挥最大潜能的10个技巧
2010-12-07 21:36 874只有你团队的成员成功了,你才能算是成功的领导者。本文介绍 ... -
工作日志之项目经理篇
2010-12-07 21:35 825大多数研发项目经理都遇到过这种困惑:“作为项目经理 ... -
项目经理要如何看待技术
2010-12-07 21:35 806当上项目经理后,技 ...
相关推荐
信息系统项目进度管理探讨——基于某港口公司生产管理系统项目实例
jsp 实例——客户管理系统(clientManger)................
project实用案例,很实用的项目管理例子
Oracle应用项目——用户管理实例.pdf 学习资料 复习资料 教学资源
“样板参照法”——项目管理团队建设的有效工具 165 IT应用的风险管理 168 风险项目投资选择与管理 172 工程项目管理中的风险分析与防范 173 项目风险管理 174 项目风险管理解决方案及应用 178 项目风险管理研究 181...
“样板参照法”——项目管理团队建设的有效工具 173 IT应用的风险管理 176 风险项目投资选择与管理 180 工程项目管理中的风险分析与防范 181 项目风险管理 183 项目风险管理解决方案及应用 186 项目风险管理研究 189...
JSP实例开发源码——图书管理系统(java+mssql).zip
本书以实现“我的Photoshop”项目的开发过程贯穿始终,通过大量实例,深入浅出地介绍了许多Visual C++ 6.0的编程技术及项目管理方法。所讲内容同时适用于Visual C++的其他版本。全书共10章涵盖了Windows编程的大部分...
jsp 实例——物流管理平台(logistics)......................
“样板参照法”——项目管理团队建设的有效工具 165 IT应用的风险管理 168 风险项目投资选择与管理 172 工程项目管理中的风险分析与防范 173 项目风险管理 174 项目风险管理解决方案及应用 178 项目风险管理研究 181...
JSP实例开发源码——会员管理系统(struts+hibernate+spring).zip
比较全面的设计报告,非常具有参考价值,此报告是来自齐鲁软件园的实地培训的真实项目。
一个完整的图书管理系统的VC源代码,包括数据库的设计,对于初涉VC准备完整开发一个小项目的人来说,绝对是超棒的教科书实例。
项目群——包含项目管理系列MMP文档,可以为项目管理提供案例,同时为学习Project 提供参考...
4.4.3C#实例——图书馆中的项目 127 4.4.4Java实例——自定义JButton 131 4.4.5优势和缺陷 133 4.4.6应用情景 134 4.5FacadePattern(外观模式) 134 4.5.1定义 134 4.5.2现实中的实例——顾客服务员 135 ...
4.4.3C#实例——图书馆中的项目 127 4.4.4Java实例——自定义JButton 131 4.4.5优势和缺陷 133 4.4.6应用情景 134 4.5FacadePattern(外观模式) 134 4.5.1定义 134 4.5.2现实中的实例——顾客服务员 135 ...
本压缩包是我在学期末做的一个项目,是学生信息管理系统。中间需要一个数据库名为Demo内部包括student,course,emp,dept,sc,tb_user等六个表。在向tb_user表中添加“username=zhang,pwd=1”的数据后即可实现登录功能...
项目管理对于项目成败至关重要,项目经理往往面临着巨大的压力和挑战:虽然已经有很多项目管理理论和方法,但实践中每个项目都有自己的独特性,没有现成的解决方案可以套用。怎么办?这部荣获软件业奥斯卡——Jolt...
软件测试技术实验报告——图书管理系统测试报告.docx软件测试技术实验报告——图书管理系统测试报告.docx软件测试技术实验报告——图书管理系统测试报告.docx软件测试技术实验报告——图书管理系统测试报告.docx软件...
微信小程序项目实例——餐厅订座小程序.zip 代码完整下载即用,无需修改确保可以运行。功能介绍 客户可以在小程序内进行卡座/包厢(不同规格大小)的订座服务,可进行小沙发卡座、大沙发卡座、多人桌、包间桌等各种...