敏捷开发团队:如何打造高软件质量的应用

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

本文将主要针对Android软件开发进行详细分析讨论,从现有敏捷团队的问题及解决方法进行分析,希望能给各位带来帮助。

mingjiekaifa

敏捷团队,一个以产品功能迭代为核心驱动力的团队,他们的目标是快速迭代出用户需要的新功能。这个目标当然没有问题,但是却与开发高质量的软件这个目标相冲突。合理的化解这个冲突,改善软件开发质量,这就是本文的重点。

1.现状

在阐述问题之前,有必要先说明一下当前团队的结构与运作过程。为了能更细致的说明问题,本文将主要针对Android软件开发进行详细分析讨论,以下是当前的人员组成结构图:

750ceca426231fc7f68e325958464451

1.1.当前存在的问题

功能迭代只见树木,不见森林

身处于迭代开发的软件开发人员,往往只了解自身功能的需求,然后根据对应的需求进行设计,容易导致一些不合理的设计,轻则导致后期维护问题,或者一些小概率事件导致的bug问题,重则导致功能重新设计开发,影响迭代速度。

功能完成为主要业绩,软件高质量为次要业绩

功能完成是一个比较容易考察的指标,而软件高质量却不是,如果还主次有别,软件高质量将无法有效的执行完成。

忽视性能问题,总是事后处理

以快速完成功能为目标,往往为了进度在性能这块做妥协,总是在出现很明显的性能问题时,才进行对应的优化,导致应用性能越来越差。

随着开发团队规模变大,规范推动执行难度也越来越大

受限于沟通成本,人员迭代功能的实际工作任务,审查的复杂度的增加,这块越来越难以实际执行。

工作量评估不准确

由于参与实际迭代的开发人员个人能力的差异,不能很好的量化实际工作量。

交互不合理时,不能有效的沟通,提供合理的建议

开发人员与交互沟通时,往往会向交互妥协,或者直接否定,导致一些不合理的交互设计方案出现。

部分可重用的组件,重复开发

开发人员受限于对团队的了解情况,受限于共用库的维护情况,受限于个人的意愿,导致部分重复开发工作。

单元测试基本无法实际执行

受到开发进度的逼迫,以及考核的指标的影响,单元测试无法实际执行。

1.2.总结

问题有很多,其中最大的问题是对软件人员的业绩评估方向出了问题,或者软件人员的工作重心出了问题。当前Android开发人员以完成迭代功能为主要工作重心,认为自己的迭代功能完成了,业绩也就实现了。所以,解决这个根本性问题,才能有效的开发出高质量的应用。方向不正确,再多的努力也起不到应有的效果。

2.理想中的工作状态

梦想还是要有的,万一现实了呢?想要在某一方面有所成就,就需要持续不断的在某个领域进行研究和思考。想要提升应用开发的效率,提升应用的运行性能,提升应用的可靠性等,都需要在应用开发上做持续深入的研究,不是一个人研究,而是整个团队持续不断的深入研究,逐渐沉淀,持续改进。

人们眼中的天才之所以卓越非凡,并非天资超人一等,而是付出了持续不断的努力。1万小时的锤炼是任何人从平凡变成超凡的必要条件。–丹尼尔·科伊尔

  • 产品问题随着时间的推移越来越少。
  • 开发效率随着技术的沉淀不断积累,不断的提升。
  • 不做重复的优化工作。
  • 不踩同样的坑。
  • 开发人员的专业领域越来越深入,找到个人成就感。
  • 开发人员之间可以互相支持,人员之间互相备用,基本不受人员流动影响。
  • 产品都是通过了单元测试、接口测试的。
  • 软件开发方案均得到充分的评估,不因为方案问题而返工。
  • 规范都能实施到位。
  • 性能优化,开发质量等问题大部分都能在开发过程中解决。

3.向着理想奋斗

敢想敢做,目前需要对现有团队结构做一定的调整,具体的调整如下:

c5e84b0f5c080b1b9aa4942c75d7ecd2

看似小的调整,却有着本质的不同,以前的Android开发团队只提供共有的开发类库,其他事情均有对应的开发人员搞定,引起了很多不确定因素。现在由领域小团队全权接手,Android组装者的工作更多的是小部分业务逻辑,任何一个功能基本上都有多个专业团队的人协作完成。以前一个功能负责人需要完成90%的代码,10%的代码由团队提供,经过这样的调整过,我们希望达到功能负责人只需要完成10%的代码,其余90%由各领域团队提供,让专业的人做专业的事。

3.1.调整的意义

  • 调整考核指标,后期Android团队以开发人员在其所在领域的成就为主要考核指标,敏捷迭代功能的开发工作为次要指标。
  • 将Android团队所有领域细分化,并分配到几个领域小组中进行持续研究和开发,不仅仅限于公共库,也包括业务功能逻辑的开发。
  • 明确各自的职责,也明确了各自的业绩和自身的发展方向。
  • 专业领域由专业的人做,降低功能开发时设计的缺陷,也让整个团队的能力能有效的提高。
  • 领域专业化,每个领域都有几个开发人员,形成人员互备,降低人员流动风险。
  • 领域专业化后,更有利于推动单元测试、接口测试、代码审查、性能优化、规范执行等事项。

3.2.细分领域

以下是目前领域细分的一个范本,它仅仅代表了一个方向,领域的细分不是一蹴而就,需要逐步完善。

60c9221791baa607c12f63ce114ae2a7

4.调整后的主要问题

经过这样调整后,一个app的开发往往有一个功能负责人和几个领域的相关人员参与需求评审,然后几个开发人员根据需求和自身的专业领域共同设计和执行开发。领域团队的人员负责提供对应的开发库,或者提供对应的技术支持协作开发。这样做,增加了部分沟通成本。但是,我相信随着该模式的持续运作和改善,随着各个领域逐渐的专业化,软件的整体的开发效率和稳定性会相比于现在有明显的提高,值得一试。

 

本文由 @空穴来风 原创发布于人人都是产品经理。未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。
2人打赏

评论( 6

登录后参与评论
  1. 逻辑不清晰

    回复
    1. 回复

      同感,前后逻辑有问题,而且并没有针对敏捷做真正的说明,或者所说的事情和敏捷没有什么关系

    2. 回复

      已在你楼下的评论中回复,不知道我解释清楚没,对你们产生的误导深表歉意,我不是标题党。。。

  2. 请问,你的标题是不是有问题。你是不是想表达“如何打造高质量软件的应用”

    回复
    1. 回复

      好吧,看来逻辑真有问题,我是想说,敏捷开发导致开发人员更多的关注功能迭代完成,导致软件变得越来越臃肿,质量也得不到有效的控制。因此,软件团队不能简单的以接功能的方式对接敏捷团队,软件团队需要以领域化为核心,敏捷迭代功能为简单任务来实施敏捷开发,不知道我解释清楚没?

    2. 回复

      我再看下

加载中