软件开发发展至今，已经诞生很多经典的开发方法，结合我司的项目情况，这里介绍我们常用的开发方法---敏捷开发（Scrum 客户参与、增量式移交、接受变更、强调开发人员的作用和及时反馈）。
一、敏捷开发定义
采用传统软件开发模式的最大问题是开发周期过长，迭代速度慢。移动互联网行业发展速度快，需求不断变化，产品更新迭代的频率高，基于移动互联网的特点，传统软件开发方法已经满足不了移动互联网的发展，所以就引入了 敏捷开发。
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
二、项目可行性分析
项目可行性分析适用于自研项目或甲方需求，合作开发中的乙方一般是不需要关注项目可行性。
- 经济可行性：也称为投资收益分析或成本效益分析，主要评估项目的建设成本、运行成本和项目建成后可能的经济收益
- 技术可行性：也称为技术风险分析，研究的对象是信息系统需要实现的功能和性能，以及技术能力约束。技术可行性主要通过考虑以下问题来进行论证
- 法律可行性：也称为社会可行性，具有比较广泛的内容，它需要从政策、法律、道德、制度等社会因素来论证信息系统建设的现实性
- 用户使用可行性：用户使用可行性也称为执行可行性，可以细分为管理可行性和运行可行性
从经济、技术、社会环境、用户等方面进行综合分析，得出可行性研究报告，如果可研通过，则制订详细的开发计划；也就是只有通过项目可行性分析才能进入下一步的开发流程。
三、敏捷开发流程
敏捷开发总的流程如下：
- 需求分析及讲解
- 方案评审（概要设计）
- 每日立会
- 版本软件
- 迭代回顾
3.1 需求分析及讲解
需求分析过程是整个 APP 软件开发的开始阶段，同时也是非常重要的阶段，需要最终用户和软件厂商的紧密配合，包括需求的收集，需求的分析整理，需求的评审，需求的变更管理等过程。很多用户在选择了软件开发厂商后，就只等软件开发厂商交付软件系统，实际上这是非常错误的，没有经过充分的需求沟通而交付的系统肯定是一个不能满足用户需要的系统，用户的满意度也一定非常低。
需求分析: 就是需求人员所要处理的事情，主要负责把本次版本中的功能分析清楚。我们一直强调一点，"需求要明确"，不允许在需求文档中出现类似 " 跟XXX一样 " 等这种含混不清的字眼。一般来讲，分析到此业务的背景，解决的问题，用户的操作场景，有这些信息有可以了。
3.2 方案评审（概要设计）
根据收集整理的需求，进行系统的架构和设计，类似于建筑行业施工前的相关设计。软件设计是系统开发的基础，是整个系统的核心和灵魂，设计工作一般主要由软件开发厂商的设计人员完成，界面的设计也在这个阶段。
如果是基于软件产品基础上的定制开发，那么需要考虑在现有产品的功能、设计和技术架构下进行设计，结合现有的业务需求，这就要求现有的软件产品需要具有较好的架构和设计，拥有较好的扩展性和二次开发能力，同时需要考虑到个性化的开发不能够破坏现有产品的设计，否则后续产品的升级需要重新整合和开发，成本和工作量非常大（这点在很多的软件产品中普遍存在，与软件的架构和和设计水平有关）。
具体点就是对于APP开发，首先读懂产品方案原型图，过一遍 APP 流程，了解 APP 特点，整理开发思路，归纳出其中的难点、不同地方实现用到的共同点；理出一个大概的开发计划，确认开发方案（包含：时间安排 + 功能点开发顺序 + 开发的难点所要运用的解决方案）
3.3 每日立会
系统开发：软件开发厂商根据系统的需求和设计，组织开发人员进行系统的代码编写，最终用户一般很难将需求一次性完成的提出，开发过程中涉及到需求的问题需要对设计进行细节的调整。开发人员对需求的理解、编码的规范和质量等，对软件系统的质量和稳定性、安全性等方面影响非常大。 （这个就是敏捷开发的优势了）
系统测试：依据需求对系统进行功能测试、性能测试（对使用用户数非常多可能需要进行性能测试）、安全性检测，功能测试一般由软件开发厂商和用户同时进行。
产品开发完成就进入测试和修复BUG的阶段。测试人员把测试得到的问题提交到BUG管理软件，每个BUG应该包含3个部分。
- 问题描述和重新步骤
- 测试人员
负责解决这个问题的人员，如果测试人员不知道具体负责人，把这个问题提交给项目负责人，由项目负责人指定解决问题的研发人员。
每日例会：每日例会前，团队成员应该整理各自的任务列表，包括：
- 昨天完成了哪些任务，每个任务使用了多少时间，没完成的任务估算还要多少时间。
- 剩余的开发时间
例会中产品经理和开发团队的成员都要参加，如果可以的话，让运营人员和市场人员也参与进来，这样可以使团队每个成员都对公司的产品有个整体的了解。
每个人在例会上报告一下3方面的事情。
- 昨天做了哪些工作？
- 今天准备做哪些工作？
- 有什么工作需要其他同事配合？
注意避免在会议上讨论问题，如果真的需要讨论，请在会议后和同事讨论，不要浪费整个团队的时间。
3.4 版本软件
系统开发完成后需要交付给最终用户使用，即 APP 全部修改完成后，需要进行上架，上传到苹果商店和安卓市场（Google、百度、阿里、腾讯）。
3.5 迭代回顾
研发完成后开回顾会议，每个成员都在会议中提两点。
- 这轮迭代过程中做得好的地方
- 这轮迭代过程中做得不好的地方
这个过程走两轮，即每个成员都要提两点做得好和不好的地方。注意当一个成员提出自己的意见时，其他成员不做任何的评论。
持续改进是敏捷开发的一个重要需求，敏捷团队在一轮迭代完成以后应进行一次回顾，迭代回顾有以下原则：
- 只用于找出改进措施，不用于表扬和批评，建议考评负责人不参与
- 迭代回顾会议引导人只做引导，杜绝一言堂，要让项目成员畅所欲言
- 从亮点和待改进点两个角度提出问题，包含开发流程的各个环节，不限于开发人员
- 每一项待改进点要有责任人，以及闭环日期
四、总结
在敏捷开发过程中，每个人必须学会主动去为自己的事情负责。敏捷开发并不仅仅是一个开发流程，更是一种管理的方式：
- 第一、明确职责的分工
- 第二、Leader都需要了解自己的团队的状况
- 第三、不断的去强化和培养这种做事的习惯
捷开发不是万能的，敏捷开发更适用于需求多变，开发周期端的项目，但APP的大部份项目适用于敏捷开发。