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

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

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

1.现状

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

1.1.当前存在的问题

• 功能迭代只见树木，不见森林

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

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

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

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

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

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

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

• 工作量评估不准确

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

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

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

• 部分可重用的组件，重复开发

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

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

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

1.2.总结

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

2.理想中的工作状态

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

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

产品问题随着时间的推移越来越少。

开发效率随着技术的沉淀不断积累，不断的提升。

不做重复的优化工作。

不踩同样的坑。

开发人员的专业领域越来越深入，找到个人成就感。

开发人员之间可以互相支持，人员之间互相备用，基本不受人员流动影响。

产品都是通过了单元测试、接口测试的。

软件开发方案均得到充分的评估，不因为方案问题而返工。

规范都能实施到位。

性能优化，开发质量等问题大部分都能在开发过程中解决。

3.向着理想奋斗

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

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

3.1.调整的意义

调整考核指标，后期Android团队以开发人员在其所在领域的成就为主要考核指标，敏捷迭代功能的开发工作为次要指标。

将Android团队所有领域细分化，并分配到几个领域小组中进行持续研究和开发，不仅仅限于公共库，也包括业务功能逻辑的开发。

明确各自的职责，也明确了各自的业绩和自身的发展方向。

专业领域由专业的人做，降低功能开发时设计的缺陷，也让整个团队的能力能有效的提高。

领域专业化，每个领域都有几个开发人员，形成人员互备，降低人员流动风险。

领域专业化后，更有利于推动单元测试、接口测试、代码审查、性能优化、规范执行等事项。

3.2.细分领域

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

4.调整后的主要问题

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