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

2016-10-12 14:44:00
潘仙芝
转贴:
互联网的一些事
4713
摘要:本文将主要针对Android软件开发进行详细分析讨论,从现有敏捷团队的问题及解决方法进行分析,希望能给各位带来帮助。


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

文章分类
联系我们
  • 联系人:阿道
  • 联系方式: 17762006160
  • 地址:青岛市黄岛区长江西路118号青铁广场18楼
投稿邀请

如果您有优秀的原创文章,欢迎添加联系人直接与我们联系,或通过下方邮箱发送投稿文章,一经采用,我们会付以一定的稿件报酬。

  • 投稿邮箱: yanruiyu@easycorp.ltd
  • 投稿标题:向 [敏捷开发] 网站投稿
  • 稿件要求:与敏捷开发相关的任何内容

更多投稿相关请点击 更多进行了解~