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

敏捷开发团队 ：如何打造高软件质量的应用 本文将主要针对A ndro id软件开发进行详细分 讨论 ，从现有敏捷团队的问题及解决方法进行 分 ，希望能给各位带来帮助。 敏捷团队 ，一个以产品功能迭代为核心驱动力的团队 ，他们的目标是快速迭代出用户需要的新功能 。这个目标当然没有问题 ，但是却与开发高质量的软件这个目标相冲突。合理的化解这个冲突 ，改 善软件开发质量 ，这就是本文的重点。 1.现状 在阐述问题之前 ，有必要先说明一下当前团队的结构与运作过程。为了能更细致的说明问题 ，本文 将主要针对A ndro id软件开发进行详细分 讨论 ，以下是当前的人员组成结构图 ： 1.1.当前存在的问题 功能迭代只见树木 ，不见森林 身处于迭代开发的软件开发人员 ，往往只了解自身功能的需求 ，然后根据对应的需求进行设计 ，容 易导致一些不合理的设计 ，轻则导致后期维护问题 ，或者一些小概率事件导致的bug问题 ，重则导 致功能重新设计开发 ，影响迭代速度。 功能完成为主要业绩 ，软件高质量为次要业绩 功能完成是一个比较容易考察的指标 ，而软件高质量却不是 ，如果还主次有别 ，软件高质量将无法 有效的执行完成。 忽视性能问 ，总是事后处理 以快速完成功能为目标 ，往往为了进度在性能这块做妥协 ，总是在出现很明显的性能问题时 ，才进 行对应的优化 ，导致应用性能越来越差。 随着开发团队规模变大 ，规范推动执行难度也越来越大 受限于沟通成本 ，人员迭代功能的实际工作任务 ，审查的复杂度的增加 ，这块越来越难以实际执行 。 工作量评估不准确 由于参与实际迭代的开发人员个人能力的差异 ，不能很好的量化实际工作量。 交互不合理时 ，不能有效的沟通 ，提供合理的建议 开发人员与交互沟通时 ，往往会向交互妥协 ，或者直接否定 ，导致一些不合理的交互设计方案出现 。 部分可重用的组件 ，重复开发 开发人员受限于对团队的了解情况 ，受限于共用库的维护情况 ，受限于个人的意愿 ，导致部分重复 开发工作。 单元测试基本无法实际执行 受到开发进度的逼迫 ，以及考核的指标的影响 ，单元测试无法实际执行。 1.2.总结 问题有很多 ，其中最大的问题是对软件人员的业绩评估方向出了问题 ，或者软件人员的工作重心出 了问题。当前A ndro id开发人员以完成迭代功能为主要工作重心 ，认为自己的迭代功能完成了 ，业 绩也就实现了。所以 ，解决这个根本性问题 ，才能有效的开发出高质量的应用。方向不正确 ，再多 的努力也起不到应有的效果。 2.理想中的工作状态 梦想还是要有的 ，万一现实了呢 ？想要在某一方面有所成就 ，就需要持续不断的在某个领域进行研 究和思考。想要提升应用开发的效率 ，提升应用的运行性能 ，提升应用的可靠性等 ，都需要在应用 开发上做持续深入的研究 ，不是一个人研究 ，而是整个团队持续不断的深入研究 ，逐渐沉淀 ，持续 改进。 人们眼中的天才之所以卓越非凡 ，并非天资超人一等 ，而是付出了持续不断的努力。1万小 时的锤炼是任何人从平凡变成超凡的必要条件。–丹尼尔·科伊尔 产品问题随着时间的推移越来越少。 开发效率随着技术的沉淀不断积累 ，不断的提升。 不做重复的优化工作。 不踩同样的坑。 开发人员的专业领域越来越深入 ，找到个人成就感。 开发人员之间可以互相支持 ，人员之间互相备用 ，基本不受人员流动影响。 产品都是通过了单元测试、接口测试的。 软件开发方案均得到充分的评估 ，不因为方案问题而返工。 规范都能实施到位。 性能优化 ，开发质量等问题大部分都能在开发过程中解决。 3.向着理想奋斗 敢想敢做 ，目前需要对现有团队结构做一定的调整 ，具体的调整如下 ： 看似小的调整 ，却有着本质的不同 ，以前的A ndro id开发团队只提供共有的开发类库 ，其他事情均 有对应的开发人员搞定 ，引起了很多不确定因素。现在由领域小团队全权接手 ，A ndro id组装者的 工作更多的是小部分业务逻辑 ，任何一个功能基本上都有多个专业团队的人协作完成。以前一个功 能负责人需要完成90%的代码 ，10%的代码由团队提供 ，经过这样的调整过 ，我们希望达到功能负 责人只需要完成10%的代码 ，其余90%由各领域团队提供 ，让专业的人做专业的事。 3.1.调整的意义 调整考核指标 ，后期A ndro id团队以开发人员在其所在领域的成就为主要考核指标 ，敏捷迭代功 能的开发工作为次要指标。 将A ndro id团队所有领域细分化 ，并分配到几个领域小组中进行