当前位置:首页 > 研发团队 > 正文

几个软件研发团队管理的小问题

2018-11-29 来源:TechExcel泰克赛尔 点击:
       作为软件开发管理的项目经理,下面的问题是不是常常萦绕在耳边呢?
       一.项目不能按时完成,总是要一拖再拖,怎么改变?
       二.软件研发需要什么类型的文档?
       三.研发中遇到难题没法解决而导致拖延进度,怎么办?
       四.测试人员总是拖慢整个项目流程,怎么解决?
       这些问题不知道你们是用什么方法去解决的呢?
       在TechExcel我们告诉你们有哪些方法可以解决上面的问题
       一项目不能按时完成,总是要一拖再拖,怎么改变?
       这个问题是怎么来的呢?因为在开发中,不断的会有旧需求改变和新需求被提出。往往在写好了代码后,新需求立马紧跟着就出现了,导致代码要重写,从而拖慢了开发进度。这样该怎么解决呢?答案就是“敏捷开发”。
       什么是敏捷开发?即,以用户需求为核心,将需求模块化,每当需求改动时,只需改变相应的模块以适应变化。借此以便快速的适应不断变化的需求。
       在敏捷开发中,Spec是其概念中最小的单元。通常情况下,Spec是来自于各种渠道的客户和产品需求,通过结合以往积累的知识文档,从而提炼出来的需求点。它们可以是正规表达的新功能、功能增强之处或修复的缺陷,并与对应的需求和知识相关联。Spec本身是高度结构化的,借此形成的树形结构可以准确地对应产品/版本功能树,借此保证开发人员不丢失任何需求。
       这样,有了Spec便可以将来自于客户或产品经理的需求文档分解为结构化的“需求树”,需求的进一步添加和修改,可以直接体现在需求树上;依照需求树,由经验丰富的技术人员将需求转变为可量化的Spec单元,通过“Spec树”直观正规地表达需求和设计;在做项目规划时,依据Spec树、团队安排和开发阶段,进行宏观层面的子项目分解,并将Spec树中的Spec直接分配到相应Sprint下,具体落实每个Sprint的开发计划。有了这棵“项目树”,Spec就能驱动产品的开发和测试了。
       这样研发团队就可以快速了解需求的变化情况,从而快速做出反应,减少开发时间的同时,按照计划完成项目开发。
       二软件研发需要什么类型的文档?
       这个问题很常见。因为软件开发需要大量的文档,它们一般分为两种类型:
       (1)是比较原始的,需要的文档是当开发人员离职后,企业需要接手的人员能够根据文档了解离职的人员所遗留的代码或模块的设计。
       (2)是较高层次的,企业为了遵从ISO9001质量管理体系或CMMI而需要的文档。
       第一种比较好理解,在编码前写一些简单的设计文档,有助于理清思路,尤其是辅以一些UML图,在交流时也是有好处的。
       但同时,我们也应该提高开发人员的编码水平来增加他编写的代码的可读性,比如增强其变量命名的可读性、用一些被大家所了解的设计模式来替代按自己某些独特思路编写的代码、和增加、改进注释等等。用以减少不必要的文档。另外推行代码的集体所有权,避免某些代码只被一个人了解,这样可以减少以此为目的而编写的文档。
       而第二种,听起来不是很能够理解。实际上,这些标准意味着对文档有着非常高的要求。而他们的目的和宗旨是一致的。即,构建高质量的产品。
       对于敏捷开发,使用手写的用户故事来记录需求和优先级的方法,以及在白板上写画的非正式设计,是不能通过ISO9001的审核的,但添加一个断言失败(类似assert(false)的断言)的测试后,则可以通过审核。
       CMMI与敏捷也是互补的,前者告诉组织在总体条款上做什么,但是没有详细的说如何去做。而后者是一套最佳实践,它们关注的在于填写按照CMMI文档所描述的假想的缺陷,却不关心这些变化是否能改进过程或产品。
       所以敏捷开发在过程中只需要编写够用的文档,和以“信息的沟通、符合性的证据以及知识共享”作为主要目标的质量体系文档要求并不冲突。因此存在下列方法可以实现敏捷开发:
       制作格式良好的、细化的Backlog。无论是复印还是照片都可以。要保证它既可以保存也可以跟踪。
       将监管工作所需要的文档也放入Backlog中。这样可以确保它们不被遗忘的同时,还能注明监管要求的成本。
       使用检查列表,以此向审核员或评估员证明活动已经执行。这样团队可以很轻松的检查已经完成的工作。
       使用敏捷项目管理工具例如DevTrack。它其实就是开发程序和记录的电子呈现方式。
       总而言之,软件开发需要的文档的形式可以是多种多样的,用Word写的文字式的文件是文档,用Visio画的UML图也是文档,保存在QualityCenter中的测试用例也是文档。但它们的类型主要就两种,合理使用它们以保证项目的顺利完成。
       三研发中遇到难题没法解决而导致拖延进度,怎么办?
       这个问题大家或多或少都曾经碰到过。而这时候,如果管理者对某个工程师的具体问题进行指导,就会陷入过度微观管理的境地。为了避免这种情况的出现,我们需要找到宏观解决办法:
       一,我们基于敏捷开发的团队有“共同的目标”这一规则。利用前面提到的集体所有权,根据集体所有权,当出现这些问题时,这些问题就变成整个团队的问题了。团队中所有可以使用的力量都将用来帮助其摆脱困境,而不是任由其他人袖手旁观。当然这里会牵扯到绩效评定的问题,比如:提供帮助的人会觉得,帮助他又无助于自己绩效评定的提高,所以为什么要提供帮助呢?因此,这需要人力资源部门在使用敏捷开发的团队的绩效评估中,尽量消除那些倾向个人的因素,还要包含团队协作的因素,广泛听取各方面的意见和更频繁地评估绩效等等。
       二,即使动用所有可以使用的力量,如果某个难题仍然无法逾越,为了减少不能按时交付的风险,产品负责人应当站出来有所作为。要么重新评估Backlog的优先级,使无法继续的Backlog迟一点交付,要么先做一些相对优先级较低的Backlog,以保证整体交付时间不至于延长;亦或是减少部分功能,给出更多的时间去攻克难题。总之强行逾越技术上难关会使团队的生产率下降,所以必须由产品负责人作出取舍。
       四测试人员总是拖慢整个项目流程,怎么解决?
软件测试人员是比较悲剧的。因为开发出来的软件需要他们去寻找BUG,而他们却往往最后才开始了解这个被开发出来的软件是干什么用的。这样就导致他们容易拖慢项目流程,因为他们需要时间去理解软件的作用。
       这个怎么解决呢?感觉不难啊,只要让他们跟着了解开发进程就好了啊。可是,这实施起来不容易啊。开发的需求本身也是在不断变化的,导致测试人员往往好不容易理解了这个需求,并且根据需求开始测试的时候,另一个新的需求又出现了。本身开发人员就已经置于需求变化的进度之后了,而测试人员更是在开发人员之后。这样就产生了牛鞭效应,可能会导致测试人员信息滞后,甚至会误解具体的需求。
       在敏捷开发中,使用统一的Spec来管理需求。将开发人员和测试人员同时纳入对需求变化的了解当中。同时使用DevTest,保证测试计划和测试任务与开发人员和需求进行同步反馈。实现快速自动递交产品缺陷。(本文于2016年发布)
 
分享到:

免责声明:
  1、研发管理评论发布的所有资讯与文章是出于为业界传递更多信息之目的,并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请浏览者仅作参考,并请自行核实相关内容。
  2、本站部分内容转载于其他网站和媒体,版权归原作者或原发布媒体所有。如文章涉及版权等问题,请联系本站,我们将在两个工作日内进行删除或修改处理。敬请谅解!

延伸阅读:

RDMR-本站推荐

more

RDMR-会议活动

more

RDMR-公开课

more

RDMR-项目管理

Copyright ©2017-2019 研发管理评论 版权所有 京ICP备17062359号-5 如转载本站文章,请注明原作者和原发布媒体

本着互联网分享精神,本站部分内容转载于其他网站和媒体,如稿件涉及版权等问题,请联系本站进行删除或修改处理

客服电话:010-89506650 89504891 非工作时间可联系:18701278071(微信) QQ在线:511524637

新闻与原创文章投稿:tougao#cpmta.com 客服邮箱:info#cpmta.com(请将#换成@)

研发管理评论——我国最大的研发管理门户网站,隶属卓橡公司

研发管理评论官方微信

PMO大会官方微信

PMO大会官方微信