同步发表在：http://snowdream.github.io/blog/2016/04/07/agile-development-advices/
移动互联网行业由于节奏快，产品迭代周期短，因此多采用敏捷开发进行快速迭代。
下面我从Android客户端研发的角度，说说敏捷开发中的几点建议：
模块化
当项目开始变得很大时，需要按照主要功能进行模块化。同时对人员进行分组,每组负责一个主要模块。
由于迭代周期短，任务重，可能在开发过程中，某个模块无法按照要求，在既定的时间内完成开发任务。这时，应该由产品进行评估，是否进行跨版本开发。如果进行跨版本开发，该模块在本次迭代过程中不参与合并代码，推迟到下个迭代周期。
最大限度减少模块之间的依赖，不要让某一个模块的跨版本开发，阻碍迭代周期内，整个项目的代码合并。
结构清晰，通俗易懂
项目的开发从来不是一个人的事情，而项目的每个模块也不会一直由某个人来负责。
代码逻辑结构复杂，混乱，会给人员的工作交接，需求开发带来难度，同时可能埋下很多BUG的隐患。
因此，代码逻辑结构清晰，通俗易懂，很重要。
如何保持代码逻辑结构清晰？
- 保持树形的逻辑结构。每一次从上层响应到底层实现，都应该保持直线的流程，而不是类似盘山公路那样弯弯绕绕的流程，更不应该像迷宫一样错综复杂的流程。
- 函数嵌套调用需谨慎。在一个函数中调用另外一个函数是很普通的，但是毫无意义，或者毫无理由的嵌套调用容易带来问题。举个例子，函数A内，调用了函数B。意味着，函数B是函数A内的一个环节，每次调用函数A，间接调用函数B是没有问题的。如果我在调用函数A的时候，并不需要每次都调用函数B，那么函数B不应嵌套在函数A内。
- 及时删除过期的功能和代码。在迭代过程中，不仅有功能上线，也有功能下线。对于下线功能，需要和产品确认是暂时下线，还是永久下线。如果是永久下线，应该删除掉该功能所有相关代码和资源。大量的过期代码会使得代码臃肿，结构复杂，不易维护。
- 经常梳理代码结构。迭代过程中，新增功能，新增代码可能会使得代码结构重新混乱。因此，需要经常性的梳理代码结构，使得代码结构清晰。否则，随着人员的更替，可能出现部分代码，大家都看不懂，又不敢删除的尴尬局面。
如何保证通俗易懂？
- 函数名称最好能体现该函数的功能。如果函数名称不能准确描述函数的功能，则应该在函数注释中进行准确的描述。
- 函数功能应该单一。不应该像万金油一样，包治百病。
- 函数体一般不宜过长。函数体过长，不容易看懂，不容易维护，此时，应该对函数体进行拆分。
- 对于不容易看懂的代码块应该加注释。比如，某个地方突然用了经验值，这个应该说明，不然谁也不知道这个值哪里冒出来的。又比如，某个地方用了不常规代码（Hack性质的，黑科技），也应该进行注释说明。
时间规划合理
敏捷开发是为了功能的快速实现，推给用户。那如何保证功能的稳定性，代码的健壮性呢？
- 给产品充足的时间，让他们充分考虑功能实现的各个细节，包括功能拆分，功能的预期，功能的入口（可能有多个），研发上下游（平台，客户端，H5）各自应该负责开发哪些部分等。
- 给研发充足的时间。开发功能并不是买菜做饭，按部就班。给他们构思的时间，让他们好好考虑功能应该怎么实现。记住，不给研发构思的时间，就不得不给研发更多修改BUG的时间。
- 给测试充足的时间，让他们充分测试产品功能正确与否，产品的易用性，稳定性等。
快速响应能力
如果产品发布出去了，发现重大问题怎么办？？
对于Web页面，通过紧急修改，测试，发布解决。
对于客户端而言，当然也要紧急修改，测试，发布。但由于涉及到多渠道，上线审核等因素，产品无法立刻更新发布。此时，建议采用热补丁方案。详细思路，请参考：《安卓App热补丁动态修复技术介绍》
下面是几种比较流行的开源热补丁方案：
