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

最近在与一位总经理交流的时候,他谈到他们公司的软件研发管理,说:“我们公司最大的问题是项目不能按时完成,总要一拖再拖。”他问我有什么办法能改变这个境况。从这样一个问题开始,在随后的交谈中,又引出他一连串在软件研发管理中的遇到的问题,包括:

 

. 现有代码质量不高,新来的开发人员接手时宁愿重写,也不愿意看别人留下的“烂”代码,怎么办?

. 重构会造成回退,怎样避免?

. 有些开发人员水平相对不高,如何保证他们的代码质量?

. 软件研发到底需不需要文档?

. 要求提交代码前做Code Review,而开发人员不做,或敷衍了事,怎么办?

. 当有开发人员在开发过程中遇到难题,工作无法继续,因而拖延进度,怎么解决?

. 如何提高开发人员的主观能动性?

 

其实,每个软件研发团队的管理者都面临着或曾经面临过这些问题,也都有着自己的管理“套路”来应对这些问题。我把我的“套路”再此絮叨絮叨。

 

1. 项目不能按时完成,总要一拖再拖,怎么改变?

 

找解决办法前,当然要先知道问题为什么会出现。这位总经理说:“总会不断地有需求要改变和新需求提出来,使原来的开发计划不得不延长。”原来如此。知道根源,当然解决办法也就有了,那就是“敏捷”。敏捷开发因其迭代(Iterative)和增量(Incremental)的思想与实践,正好适合“需求经常变化和增加”的项目和产品。在我讲述了敏捷的一些概念,特别是Scrum的框架后,总经理也表示了对“敏捷”的认同。

 

其实仔细想想,这里面还有一个非常普遍的问题。对于产品的交付时间或项目的完成时间,往往由高级管理层根据市场情况决策和确定。在很多软件企业中,这些决策者在决策时往往忽略了一个重要的参数,那就是团队的生产率(Velocity)。生产率需要量化,而不是“拍脑门子”感觉出来的。敏捷开发中有关于如何估算生产率的方法。所以使用敏捷,在估算产品交付时间或项目完成时间时,是相对较准确的。Scrum创始人之一的Jeff Sutherland说,他在一个风险投资团队做敏捷教练时,团队中的资深合伙人会向所有的待投资企业问同一个问题:“你们是否清楚团队的生产率?”而这些企业都很难做出明确的答复。软件企业要想给产品定一个较实际的交付日期,就首先要弄清楚自己的软件生产率。

 

2. 现有代码质量不高,新来的开发人员接手时宁愿重写,也不愿意看别人留下的“烂”代码,怎么办?

 

这可能是很多软件开发工程师都有过的体验,在接手别人的代码时,看不懂、无法加新功能,读代码读的头疼。这说明什么?排除接手人个人水平的因素,这说明旧代码可读性、可扩展性比较差。怎么办?这时,也许重构是一种两全其美的办法。接手人重构代码,既能改善旧代码的可读性和可扩展性,又不至于因重写代码带来的时间上的风险。

 

从接手人心理的角度看,重构还有一个好的副作用,就是代码重构之后,接手人觉得那些原来的“烂”代码被修改成为自己引以自豪的新成就。《Scrum敏捷软件开发》的作者Mike Cohn写到过:“我的女儿们画了一幅特别令人赞叹的杰作后,她们会将它从学校带回家,并想把它展示在一个明显的位置,也就是冰箱上面。有一天,在工作中,我用C++代码实现了某个特别有用的策略模式的程序。因为我认定冰箱门适合展示我们引以为豪的任何东西,所以我就将它放上去了。如果我们一直对自己工作的质量特别自豪,可以骄傲地将它和孩子的艺术品一样展示在冰箱上,那不是很好吗?”所以这个积极的促进作用,将使得接手人感觉修改的代码是自己的了,而且期望能够找到更多的可以重构的东西。

 

3. 重构会造成回退,怎样避免?

 

重构确实很容易造成回退(Regression)。这时,重构会起到与其初衷相反的作用。所以我们应该尽可能多地增加单元测试。有些老产品,旧代码,可能没有或者没有那么多的单元测试。但我们至少要在重构前,增加对要重构部分代码的单元测试。基于重构目的的单元测试,应该遵循以下的原则(见《重构》第4章:构筑测试体系):

- 编写未臻完善的测试并实际运行,好过对完美测试的无尽等待。测试应该是一种风险驱动行为,所以不要去测试那些仅仅读写一个值域的访问函数,应为它们太简单了,不大可能出错。

- 考虑可能出错的边界条件,把测试火力集中在哪儿。扮演“程序公敌”,纵容你心智中比较促狭的那一部分,积极思考如何破坏代码。

- 当事情被公认应该会出错时,别忘了检查是否有异常如期被抛出。

- 不要因为“测试无法捕捉所有Bug”,就不撰写测试代码,因为测试的确可以捕捉到大多数Bug。

- “花合理时间抓出大多数Bug”要好过“穷尽一生抓出所有Bug”。因为当测试数量达到一定程度之后,测试效益就会呈现递减态势,而非持续递增。

说到《重构》这本书,其实在每个重构方法中都有“作法(Mechanics)”一段,在重构的实践中按照上面所述的步骤进行是比较稳妥的,同时也能避免很多不经意间制造的回退出现。

 

4. 要求提交代码前做Code Review,而开发人员不做,或敷衍了事,怎么办?

 

如果每个开发人员都是积极主动的,Code Review的作用能落到实处。但如果不是呢?团队管理者需要一些手段促使其有效地进行Code Review。首先,我们采用的Code Review有2种形式,一是Over-the-shoulder,也就是2个人座在一起,一个人讲,另一个人审查。二是用工具Code Collaborator来进行。无论哪种形式,在提交代码时,必须注明关于审查的信息,比如:审查者(Reviewer)的名字或审查号(Review ID,Code Collaborator自动生成),每天由一名专职人员来检查Checklist中的每一条,看是否有人漏写这些信息,如果发现会提醒提交的人补上。另外,某段提交的代码出问题,提交者和审查者都要一起来解决出现的问题,以最大限度避免审查过程敷衍了事。

 

博主Inovy在某个评论说的很形象:“木(没)有赏罚的制度,就是带到厕所的报纸,看完就可以用来擦屁股了。”没有奖惩制度作保证,当然上面的要求没有什么效力。所以,当有人经常不审查就提交,或审查时不负责任,它的绩效评定就会因此低一点,而绩效的评分是跟每年工资涨落挂钩的。说白了,可能某个人会因为多次被查出没有做Code Review就提交代码,而到年底加薪时比别人少涨500块钱。

 

5. 软件研发到底需不需要文档?

 

软件研发需要文档的起原可能有2种,一是比较原始的,需要文档是为了当开发人员离职后,企业需要接手的人能根据文档了解他所接手的代码或模块的设计。二是较高层次的,企业遵从ISO9001质量管理体系或CMMI。

 

对于第一种,根源可能来自于两个方面:

- 原开发人员设计编码水平不高,其代码可读性较差。

- 设计思想和代码只有一个人了解,此人一旦离职,无人知道其细节。

在编码前写一些简单的设计文档,有助于理清思路,尤其是辅以一些UML图,在交流时也是有好处的。但同时,我们也应该提高开发人员的编码水平增加其代码的可读性,比如增强其变量命名的可读性、用一些被大家所了解的设计模式来替代按自己某些独特思路编写的代码、增加和改进注释等等,以减少不必要的文档。另外推行代码的集体所有权(Collective Ownership),避免某些代码只被一个人了解,这样可以减少以此为目的而编写的文档。

 

对于第二种,情况有些复杂。接触过敏捷开发的人都知道《敏捷宣言》中的“可以工作的软件胜于面面俱到的文档”。接触过CMMI开发或者ISO9001质量管理体系的人知道它们对文档的要求是多么的高。它们看起来水火不相容。但是,它们的宗旨是一致的,即:构建高质量的产品。

 

对于敏捷,使用手写用户故事来记录需求和优先级的方法,以及在白板上写画的非正式设计,是不能通过ISO9001的审核的,但当把它们复印、拍照、增加序号、保存后,可以通过审核。每次都是成功的Daily Build和Auto Test报告无法证明它们是否真正被执行并真正成功,所以不能通过ISO9001的审核。但添加一个断言失败(类似assert(false)的断言)的测试后,则可以通过审核。

 

CMMI与敏捷也是互补的,前者告诉组织在总体条款上做什么,但是没有说如何去做,后者是一套最佳实践。SCRUM之类的敏捷方法也被引入过那些已通过CMMI5级评估的组织。很多企业忘记了最终目标是改进他们构建软件及递交产品的方式,相反,它们关注于填写按照CMMI文档描述的假想的缺陷,却不关心这些变化是否能改进过程或产品。

 

所以敏捷开发在过程中只编写够用的文档,和以“信息的沟通、符合性的证据以及知识共享”作为主要目标的质量体系文档要求并不矛盾。在实践中,我们可以按以下方法做,在实现SCRUM的同时,符合审核和评估的要求:

 

- 制作格式良好的、被细化的、被保存的和能跟踪的Backlog。复印和照片同样有效。

- 将监管需要的文档工作也放入Backlog。除了可以确保它们不被忘记,还能使监管要求的成本是可见的。

- 使用检查列表,以向审核员或评估员证明活动已执行。团队对“完成”的定义(Definition of “Done”)可以很容易转变为一份检查列表。

- 使用敏捷项目管理工具。它其实就是开发程序和记录的电子呈现方式。

 

总而言之,软件研发需要文档(但文档的形式可以是多种多样的,用Word写的文字式的文件是文档,用Visio画的UML图也是文档,保存在Quality Center中的测试用例也是文档),同时我们只需写够用的文档。

 

6. 当有开发人员在开发过程中遇到难题,工作无法继续,因而拖延进度,怎么解决?

 

这也是个常遇到的问题。如果管理者对于某个工程师的具体问题进行指导,就会陷入过度微观管理的境地。我们需要找到宏观解决办法。一,我们基于Scrum的“团队有共同的目标”这一规则,利用前面提到的集体所有权,当出现这些问题时,用团队中所有可以使用的力量来帮助其摆脱困境,而不是任其他人袖手旁观。当然这里会牵扯到绩效评定的问题,比如:提供帮助的人会觉得,他的帮助无助于自己绩效评定的提高,为什么要提供帮助。这需要人力资源部门在使用Scrum开发的团队的绩效评估中,尽量消除那些倾向个人的因素,还要包含团队协作的因素,广泛听取个方面的意见,更频繁地评估绩效等等。

 

二,即使动用所有可以使用的力量,如果某个难题真的无法逾越,为了减少不能按时交付的风险,产品负责人应当站出来,并有所作为。要么重新评估Backlog的优先级,使无法继续的Backlog迟一点交付,先做一些相对较低优先级的Backlog,以保证整体交付时间不至于延长;要么减少部分功能,给出更多的时间去攻克难题。总之逾越技术上难关会使团队的生产率下降,产品负责人必须作出取舍。

 

7. 有些开发人员水平相对不高,如何保证他们的代码质量?

 

当然首先让较有经验的人Review其要提交的代码,这几乎是所有管理者会做的事。除此之外,管理者有责任帮助这些人(也包括水平较高的人)提高水平,他们可以看一些书,上网看资料,读别人的代码等等,途经还是很多的。但问题是你如何去衡量其是否真正有所收获。我们的经验是,在每年大约3月份为每个工程师制定整个年度的目标,每个人的目标包括产品上的,技术上的,个人能力上的等4到5项。半年后和一年后,要做两次Performance Review,目标是否实现,也会跟绩效评定挂钩。我们在制定目标时,遵循SMART原则,即:

 

Specific(明确的):目标应该按照明确的结果和成效表述。

Measurable(可衡量的):目标的完成情况应该可以衡量和验证。

Aligned(结盟的):目标应该与公司的商业策略保持一致。

Realistic(现实的):目标虽然应具挑战性,但更应该能在给定的条件和环境下实现。

Time-Bound(有时限的):目标应该包括一个实现的具体时间。

 

比如:某个人制定了“初步掌握本地化技术”的目标,他要确定实现时间,要描述学习的途经和步骤,要通过将技术施加到公司现有的产品中,为公司产品的本地化/国际化/全球化作一些探索,并制作Presentation给团队演示他的成果,并准备回答其他人提出的问题。团队还为了配合其实现目标,组织Tech Talk的活动,供大家分享每个人的学习成果。通过这些手段,提高开发人员的自学兴趣,并逐步提高开发人员的技术水平。

 

8. 如何提高开发人员的主观能动性?

 

提高开发人员的主观能动性,少不了激励机制。不能让开发人员感到,5年以后的他和现在比不会有什么进步。你要让他感到他所从事的是一个职业(Career),而不只是一份工作(Job)。否则,他们是不会主动投入到工作中的。我们的经验是提供一套职业发展的框架。框架制定了2类发展道路,管理类(Managerial Path)和技术类(Technical Path),6个职业级别(1-3级是Entry/Associate,Intermediate,Senior。4级管理类是Manager/Senior Manager,技术类是Principal/Senior Principal。5级管理类是Director/Senior Director,技术类是Fellow/Architect。6级是Executive Management)。每个级别都有13个方面的具体要求,包括:范围(Scope)、跨职能(Cross Functional)、层次(Level)、知识(Knowledge)、指导(Guidance)、问题解决(Problem Solving)、递交成果(Delivering Result)、责任感(Responsbility)、导师(Mentoring)、交流(Communication)、自学(Self-Learning),运作监督(Operational Oversight),客户响应(Customer Responsiveness)。每年有2次提高级别的机会,开发人员一旦具备了升级的条件,他的Supervisor将会提出申请,一旦批准,他的头衔随之提高,薪水也会有相对较大提高。从而使每个开发人员觉得“有奔头”,自然他们的主观能动性也就提高了。

 

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Visio 软件研发流程主要包括需求分析、设计、编码、测试和发布阶段。 首先是需求分析阶段,团队与客户沟通,深入了解客户的需求和期望。通过进行用户调研和市场研究,确定开发的目标和范围。在这个阶段,团队会制定出详细的需求文档,包括功能需求、性能需求、界面设计等。 接下来是设计阶段,根据需求文档,团队开始进行系统的设计。在这个阶段,团队会确定软件的架构和系统的模块划分,并绘制相应的UML图表和流程图以便于后续的开发工作。此外,团队还会制定详细的数据库设计和界面设计。 在设计完成后,进入编码阶段,开发人员根据设计文档进行编码工作。根据开发语言和技术选型,团队使用相应的开发工具和框架进行开发。同时,团队遵循良好的编程规范和代码质量管理,确保代码的可维护性和可扩展性。 完成编码后,进行测试阶段。测试团队根据预先编写的测试计划和测试用例进行功能测试、性能测试、稳定性测试等,以确保软件的质量。在测试过程中,团队会修复发现的问题并进行回归测试,直到软件达到预期的质量标准。 最后是发布阶段,团队准备好正式发布软件的各项准备工作。包括文档编写、培训、发布计划等。团队还会进行最后一轮的综合测试,确保软件的稳定性和兼容性。一切就绪后,软件将正式发布到市场上。 总结起来,Visio 软件研发流程包括需求分析、设计、编码、测试和发布等多个阶段。每个阶段都有相应的工作和目标,并且团队成员之间需要密切协作,确保软件开发的高质量和客户满意度。 ### 回答2: Visio软件研发流程主要包括需求分析、设计、编码、测试和发布等阶段。 首先,需求分析阶段是研发流程的起点。在这个阶段,团队与用户进行沟通,收集用户需求和期望,明确软件功能、性能和界面设计等方面的需求。 其次,设计阶段是确定软件架构和技术方案的重要环节。团队根据需求分析的结果,进行系统设计,包括数据库设计、模块设计和界面设计等工作,确保软件的可扩展性和稳定性。 然后,编码阶段是将设计方案转化为具体的代码实现的过程。开发人员根据设计文档,运用编程语言和工具进行编码,开发各个功能模块。 接下来,测试阶段是对软件进行功能和性能等方面的测试,以确保软件的质量和稳定性。测试人员会针对功能需求进行验证,测试各种边界条件和异常情况,以发现潜在的问题并修复。 最后,发布阶段是将研发完成的软件正式发布给用户使用。在发布之前,需要进行一系列的准备工作,包括版本控制、文档编写、问题修复等,以保证用户能够顺利使用新版软件。 此外,研发过程还需要进行不断的迭代和优化,以提升软件的功能和性能。在用户使用软件时,开发团队还需要进行用户反馈的收集和分析,积极参与用户需求调研,为下一个版本的迭代提供参考和改进方向。 总的来说,Visio软件研发流程包括需求分析、设计、编码、测试和发布等阶段,每个阶段都有具体的任务和目标,并需要不断迭代和优化,以提升软件的质量和用户体验。 ### 回答3: Visio软件研发流程通常涉及以下几个阶段:需求分析、设计、编码、测试和发布。 首先是需求分析阶段。在这个阶段,研发团队与相关的利益相关者和客户沟通,了解他们的需求和期望。通过与用户讨论和收集反馈,研发团队能够明确软件的功能、性能和界面等方面的需求。 然后是设计阶段。在这个阶段,研发团队会根据需求分析的结果,设计软件的整体架构和各个模块的详细设计。设计阶段目标是确保软件的功能和性能满足需求,并考虑到软件的可扩展性和可维护性。 接下来是编码阶段。在这个阶段,研发团队将根据设计阶段的规划,使用合适的编程语言和工具进行编码开发团队成员按照设计的模块进行分工,并实现各自负责的模块功能。编码阶段需要严格遵循编码规范,保证代码的可读性和可维护性。 完成编码后,进入测试阶段。在这个阶段,研发团队会对软件进行各个层面的测试,包括单元测试、集成测试和系统测试等。目的是检测软件的功能是否符合需求,是否存在缺陷和错误。测试旨在发现并修复所有潜在问题,确保软件的质量和稳定性。 最后是发布阶段。在通过全面测试并修复所有错误后,研发团队会准备软件的发布版本。这包括进行最后的软件优化、文档编写和产品发布计划等。经过发布前的确认和准备工作后,软件会被正式发布给用户,并提供支持、更新和维护等服务。 Visio软件研发流程需要经过以上几个阶段,每个阶段都有其特定的目标和任务。通过这些流程,研发团队能够确保软件开发按需求进行,并最终提供一款功能强大、稳定可靠的Visio软件

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值