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

1.现状

1.1.当前存在的问题

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

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

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

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

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

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

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

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

工作量评估不准确

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

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

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

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

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

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

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

1.2.总结

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

2.理想中的工作状态

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

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

3.向着理想奋斗

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

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

3.1.调整的意义

3.2.细分领域

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

4.调整后的主要问题

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