产品研发过程常见问题1:缺乏统一的管理平台
2011-09-06 09:03
519 查看
随着软件开发实践的不断深入,应用生命周期管理越来越被业界接受为一种经过实践检验的,可以创造高品质的应用程序的,可靠的软件开发模式。但是,要实施整个应用程序生命周期管理是非常复杂的,我们必须借助一些工具来帮助我们完成整个生命周期的管理。
让我们先来回顾一下绝大多数软件研发团队的典型工作情景:
【场景1】:工具满天飞
很多研发企业的管理平台非常分散,不同团队和个人使用工具不同,我们常常可以看到,产品部门收集需求使用Word、Excel,项目经理制定项目计划、进行任务划分和分配使用Project,开发部门管理任务和缺陷使用Jira、URTracker,测试部门管理测试任务使用TestDirector、TestLink,配置管理使用VSS、SVN、CVS、CC等等,这些平台相互是独立的,不仅不可以信息共享,部门之间还产生了有明显的信息壁垒,完全靠手工操作实现信息传递。
【场景2】:研发过程衔接不畅
公司的需求管理、计划管理、缺陷跟踪、测试管理等等各种研发活动,使用不同公司开发的无法整合的工具,这些不同来源的工具,既无法共享项目信息,给使用上带来很多不便,又无法在各种不同类型的数据之间建立关联,导致一些高级管理功能无法实现,比如要实现需求跟踪,就需要整合需求管理、任务管理、测试管理三个系统。
【场景3】:一个BUG引发的血案?!
软件开发人员1: 通过代码走查发现一个BUG,需要将这个BUG记入缺陷跟踪系统;
软件开发人员2(代码的作者):需要根据这个缺陷判断需要如何修改,并评估修改的工作量。如果是普通的BUG,只需要开发人员进行修改即可;一旦发现是深层次的BUG,涉及到数据结构的调整、界面的调整甚至软件架构的调整,这将牵动研发团队的项目经理、系统架构师、数据库管理员、界面设计人员、产品经理;
项目经理:收到开发人员的汇报,很不幸的发现这个问题需要在缺陷跟踪系统中将相关的人员统统拉到一起才可以解决问题;
产品经理:需要根据缺陷评估即将投入的人力成本和由此引发的后果;
系统架构师:评估架构调整的成本并拿出可行性方案;
数据库管理员:调整数据结构,并为由此带来的数据结构升级准备方案;
界面设计人员:重新调整界面,并为原来统一的风格如何调整伤透脑经;
软件开发人员3(最终确定FIX BUG的人员):根据最终收到的修改方案,制定修改计划并进行BUG的修改,而且该软件开发人员制订的开发计划需要让相关人员能准确的掌握BUG修改的进度,因为他的计划制约了后续的每一步工作;
版本经理:根据修改结果发布一个测试版本,并知道版本中已包含了此次修改;
测试人员:在拿到该版本后需要对这个BUG导致的代码修改设计针对性的测试用例,这个测试用例可能是自动测试用例,也可能是人工测试用例,总之测试人员需要在测试管理系统来记录这个BUG修改的验证过程;
版本经理(又出现了! ):一切就绪后,向客户发布版本时还需要提供release notes以指明该版本中的这个改动(假设该BUG对用户可见);
技术支持:收到版本经理发布的版本、操作手册以及相关的FAQ,做好给客户提供支持的准备;
QA:仔细分析代码走查发现的所有BUG原因,如果是典型问题,还需要将该问题写入开发经验库,并通过知识共享的形式分享给所有团队成员;
项目经理(囧!):一切却还没有结束!项目经理的职责还需要从组织级的角度把控项目过程和研发全进程。一个开发人员的代码如果被统计出问题较多,应该对该开发人员开发的代码采取补救和预防措施,要么加强测试,要么给他一些培训,要么他根本不适合这个职位应该走人;对于这个开发人员的上司,他应该如何评价这个犯错的下属,因为几个BUG就认为他的工作不称职显然是不正确的,还有他如何衡量这个开发人员的工作量,是否是该员工工作量太多导致了该员工的代码质量不高?他还想知道该员工在引入这个BUG时当时的工作任务是否过于紧迫?当然,他也可能想分析一下这个典型的BUG引入会导致多少额外的工作量产生?
…………………….
这,也太麻烦了吧!
一切就只是因为一个开发人员的某行代码的BUG引发的血案?!
拜托!这就是研发工作的特点!好吗?!
理由很简单:没有一个集中管理、统一、高度整合的管理平台!
【解决方案推荐】
工欲善其身,必先利其器。软件企业也是如此,要做到高效的软件开发和过程管理,必须选择运用灵活高效、统一整合的开发管理工具。
TechExcel DevSuite 是一款高度集成、灵活可扩展的研发管理平台,实现了在同一平台下从产品的概念形成、需求分析、项目规划、任务跟踪到开发测试等全生命周期的管理。有效且协同地控制需求、资源、工期和质量,帮助研发团队快速改进软件开发过程,提高产品质量和工作效率。
一个平台即解决所有工具问题!
DevSuite平台不但包含了项目人员、架构师、开发人员和测试人员等所有人员对应的支持功能,增强了软件开发团队中的沟通与协作。举个例子,项目经理在定制项目计划时可以直接使用需求内容,在做计划的同时又可以给研发人员分配任务,研发人员在接到任务时可以直接查看相关联的客户需求,而测试人员在遇到缺陷时可以自动提交Bug,并且能实时查看Bug的修复进度。统一的平台既节省了所有员工的工作量,也保证了信息的一致性,同时也使得项目研发的所有历史都可追踪到。
也就是说,研发过程的每一个阶段轻而易举的实现业务关联,如用户需求与产品功能、定制项目可关联;产品功能与项目规划、开发任务、测试用例、测试任务可关联;测试任务与BUG可关联;开发任务与源代码可关联;知识条目与需求、功能、任务均可关联等等!
当然必须地要提一下,DevSuite平台还适用于跨地域、跨时区协同开发,支持分布式研发团队,实现高效率的沟通与协作。
研发管理,也可以变得很简单啊!
你信吗?你不信吗?无论你信不信,反正我是信了!!!
[b]^____^[/b]
[b]作者:张蕾 文章来源:http://blog.sina.com.cn/s/blog_771398c50100u6zg.html[/b]
让我们先来回顾一下绝大多数软件研发团队的典型工作情景:
【场景1】:工具满天飞
很多研发企业的管理平台非常分散,不同团队和个人使用工具不同,我们常常可以看到,产品部门收集需求使用Word、Excel,项目经理制定项目计划、进行任务划分和分配使用Project,开发部门管理任务和缺陷使用Jira、URTracker,测试部门管理测试任务使用TestDirector、TestLink,配置管理使用VSS、SVN、CVS、CC等等,这些平台相互是独立的,不仅不可以信息共享,部门之间还产生了有明显的信息壁垒,完全靠手工操作实现信息传递。
【场景2】:研发过程衔接不畅
公司的需求管理、计划管理、缺陷跟踪、测试管理等等各种研发活动,使用不同公司开发的无法整合的工具,这些不同来源的工具,既无法共享项目信息,给使用上带来很多不便,又无法在各种不同类型的数据之间建立关联,导致一些高级管理功能无法实现,比如要实现需求跟踪,就需要整合需求管理、任务管理、测试管理三个系统。
【场景3】:一个BUG引发的血案?!
软件开发人员1: 通过代码走查发现一个BUG,需要将这个BUG记入缺陷跟踪系统;
软件开发人员2(代码的作者):需要根据这个缺陷判断需要如何修改,并评估修改的工作量。如果是普通的BUG,只需要开发人员进行修改即可;一旦发现是深层次的BUG,涉及到数据结构的调整、界面的调整甚至软件架构的调整,这将牵动研发团队的项目经理、系统架构师、数据库管理员、界面设计人员、产品经理;
项目经理:收到开发人员的汇报,很不幸的发现这个问题需要在缺陷跟踪系统中将相关的人员统统拉到一起才可以解决问题;
产品经理:需要根据缺陷评估即将投入的人力成本和由此引发的后果;
系统架构师:评估架构调整的成本并拿出可行性方案;
数据库管理员:调整数据结构,并为由此带来的数据结构升级准备方案;
界面设计人员:重新调整界面,并为原来统一的风格如何调整伤透脑经;
软件开发人员3(最终确定FIX BUG的人员):根据最终收到的修改方案,制定修改计划并进行BUG的修改,而且该软件开发人员制订的开发计划需要让相关人员能准确的掌握BUG修改的进度,因为他的计划制约了后续的每一步工作;
版本经理:根据修改结果发布一个测试版本,并知道版本中已包含了此次修改;
测试人员:在拿到该版本后需要对这个BUG导致的代码修改设计针对性的测试用例,这个测试用例可能是自动测试用例,也可能是人工测试用例,总之测试人员需要在测试管理系统来记录这个BUG修改的验证过程;
版本经理(又出现了! ):一切就绪后,向客户发布版本时还需要提供release notes以指明该版本中的这个改动(假设该BUG对用户可见);
技术支持:收到版本经理发布的版本、操作手册以及相关的FAQ,做好给客户提供支持的准备;
QA:仔细分析代码走查发现的所有BUG原因,如果是典型问题,还需要将该问题写入开发经验库,并通过知识共享的形式分享给所有团队成员;
项目经理(囧!):一切却还没有结束!项目经理的职责还需要从组织级的角度把控项目过程和研发全进程。一个开发人员的代码如果被统计出问题较多,应该对该开发人员开发的代码采取补救和预防措施,要么加强测试,要么给他一些培训,要么他根本不适合这个职位应该走人;对于这个开发人员的上司,他应该如何评价这个犯错的下属,因为几个BUG就认为他的工作不称职显然是不正确的,还有他如何衡量这个开发人员的工作量,是否是该员工工作量太多导致了该员工的代码质量不高?他还想知道该员工在引入这个BUG时当时的工作任务是否过于紧迫?当然,他也可能想分析一下这个典型的BUG引入会导致多少额外的工作量产生?
…………………….
这,也太麻烦了吧!
一切就只是因为一个开发人员的某行代码的BUG引发的血案?!
拜托!这就是研发工作的特点!好吗?!
理由很简单:没有一个集中管理、统一、高度整合的管理平台!
【解决方案推荐】
工欲善其身,必先利其器。软件企业也是如此,要做到高效的软件开发和过程管理,必须选择运用灵活高效、统一整合的开发管理工具。
TechExcel DevSuite 是一款高度集成、灵活可扩展的研发管理平台,实现了在同一平台下从产品的概念形成、需求分析、项目规划、任务跟踪到开发测试等全生命周期的管理。有效且协同地控制需求、资源、工期和质量,帮助研发团队快速改进软件开发过程,提高产品质量和工作效率。
一个平台即解决所有工具问题!
DevSuite平台不但包含了项目人员、架构师、开发人员和测试人员等所有人员对应的支持功能,增强了软件开发团队中的沟通与协作。举个例子,项目经理在定制项目计划时可以直接使用需求内容,在做计划的同时又可以给研发人员分配任务,研发人员在接到任务时可以直接查看相关联的客户需求,而测试人员在遇到缺陷时可以自动提交Bug,并且能实时查看Bug的修复进度。统一的平台既节省了所有员工的工作量,也保证了信息的一致性,同时也使得项目研发的所有历史都可追踪到。
也就是说,研发过程的每一个阶段轻而易举的实现业务关联,如用户需求与产品功能、定制项目可关联;产品功能与项目规划、开发任务、测试用例、测试任务可关联;测试任务与BUG可关联;开发任务与源代码可关联;知识条目与需求、功能、任务均可关联等等!
当然必须地要提一下,DevSuite平台还适用于跨地域、跨时区协同开发,支持分布式研发团队,实现高效率的沟通与协作。
研发管理,也可以变得很简单啊!
你信吗?你不信吗?无论你信不信,反正我是信了!!!
[b]^____^[/b]
[b]作者:张蕾 文章来源:http://blog.sina.com.cn/s/blog_771398c50100u6zg.html[/b]
相关文章推荐
- 产品研发过程常见问题4:多项目管理挑战多
- 产品研发过程常见问题2:难以量化的需求开发与管理
- 产品研发过程常见问题2:难以量化的需求开发与管理
- SAP HANA开发中常见问题- 基于SAP HANA平台的多团队产品研发
- SAP HANA开发中常见问题- 基于SAP HANA平台的多团队产品研发
- 产品研发过程常见问题3:跨部门协作困难
- PLUTO平台是由美林数据技术股份有限公司下属西安交大美林数据挖掘研究中心自主研发的一款基于云计算技术架构的数据挖掘产品,产品设计严格遵循国际数据挖掘标准CRISP-DM(跨行业数据挖掘过程标准),具备完备的数据准备、模型构建、模型评估、模型管理、海量数据处理和高纬数据可视化分析能力。
- SAP HANA开发中常见问题- 基于SAP HANA平台的多团队产品研发
- SAP HANA开发中常见问题- 基于SAP HANA平台的多团队产品研发
- 产品研发过程管理专题——编写软件测试计划需要考虑的几个问题
- PLUTO平台是由美林数据技术股份有限公司下属西安交大美林数据挖掘研究中心自主研发的一款基于云计算技术架构的数据挖掘产品,产品设计严格遵循国际数据挖掘标准CRISP-DM(跨行业数据挖掘过程标准),具备完备的数据准备、模型构建、模型评估、模型管理、海量数据处理和高纬数据可视化分析能力。
- 基于NX的研发产品设计管理平台实现(二)--设计架构
- 信息化项目实施过程中十四种常见管理问题
- 基于NX的研发产品设计管理平台实现(十五)-数据查询2
- 缺乏配置管理造成的常见问题
- 产品研发过程管理专题——软件项目范围变更流程与过程控制研究
- 统一项目管理平台(UMPlatForm.NET)产品用途
- 基于NX的研发产品设计管理平台实现(五)--物料编码的录入及管理2
- 产品研发过程管理专题——软件工程(软件目的需求开发与管理)
- 基于NX的研发产品设计管理平台实现(十六)-物料描述自动提取1