正文
由于本人水平有限，还往和多多大家交流，指出本文可以提升的地方，谢谢.
|
传统的开发模式
-
瀑布模型
-
增量模型
-
快速原型模型
-
螺旋模型
-
喷泉模型
-
... ...
每种开发模型都各有各的好处，应用的场景也不一样，我无法去评价或者诋毁某种开发模式，因为我不够格。
![]()
在互联网公司，需要进行快速迭代，用户的需求可能每天或者每周，每个月都在变。
冗长的开发周期敌不过用户的需求变化，所以敏捷开发 就诞生了，不能说敏捷开发十全十美，它只是一套方法论而已，需要改进去适应。
真正的竞争对手不是来自其它公司，而是用户不断变化的需求.
|
敏捷开发
一句话概括敏捷开发——"将整个项目周期分成多个敏捷开发周期。”
![]()
测试？后台？产品？设计？开发？
全部东西拆分成多个迭代后，每次迭代后出来的东西是看的见，摸得着的，也可以快速得到反馈，而不是等到全部东西出来。
敏捷开发流程的一些疑问与困惑
测试如何早期介入？测试用例评审会什么时候开？
开发与测试本来就是一个团队的。
沟通的效率高了，尤其是开发和测试，因为很多问题开发和测试可以先沟通，这样很多问题也就可以提前解决了。
测试要更早的介入开发中，可以尝试用测试驱动的方法，这一点尤其对自动化来说更重要，但要知道，并不是每个开发任务都能这么做，这个主要是测试要多和开发的人进行沟通。
测试用例评审无论是敏捷开发还是传统开发都会遇到，这个感觉很尴尬，如果是全部都来，感觉不太合理，很浪费时间.（需要不断的实践，找出合适自己的方法）
当然，
评审
也可以变通一下，如果时间允许，可以找个会议室一起认真的过一下，如果时间不允许，可以发送給功能相关人员，让他们提供意见即可，或者测试人员内部简单过一下也可以，不要拘于形式，以项目实际情况做适宜的变通。
技术可行性如何介入？
场景1：技术可行么，不会开发到一半写不下去了？技术方案要不要写？如何去技术选型？要不要去评估，又要浪费多少时间？
场景2：等到原型或者需求文档完全出来，然后在会议上进行各种讨论，很大程度上浪费了大家的时间，然后反复如此？时间都浪费在开会上了，效率低下。(可怕的是这个会议只是需求评审，并不关注可行性，又或者 需求评审，技术可行性一起来~!~!~!~!）
该这么办？
在早期产品 整理需求,用户数据，调研，竞品分析，进行产品 原型制作以及产品需求文档的过程中，
该项目的负责人或主要开发人员 就应该协助产品经理了解 产品的开发难度以及可行性，逻辑错误 等等，让产品做好原型或需求文档的调整。
移动端开发与后台开发如何并行开发，而不用等待？
场景：我们时常会遇到这种情况，后台有部分接口没有开发完毕，你需要等待他完成，你才能进行，拖延进度可不是一天，两天哈。
下面介绍了三种方式 ServiceMock 和 网络请求三件套(retrofit + okhttp + rxjava)，后台直接暴力返回假数据：
-
ServiceMock服务模拟，本公司或第三方合作，需提前约定接口，传入的参数，返回的JSON。(最后移动端使用返回假数据)
// data.json 返回JSON数据.
// git地址:https://github.com/dreamhead/moco
// http://blog.csdn.net/shensky711/article/details/52770686
// java -jar moco-runner-0.11.1-standalone.jar http -p 12345 -c data.json
[{
"request" : { "uri" : "/hello" },
"response" : {
"json" : {
"code": 1,
"message": "foo"
}
}
}]
// 拦截器. (除了用作单元测试，还可以用作缓存处理，与服务端的并行开发)
public class MockInterceptor implements Interceptor {
@Override
public Response intercept(Interceptor.Chain chain) throws IOException {
// 根据 path 的请求路径，返回相应的数据.
// HttpUrl uri = chain.request().url();
// String path = uri.url().getPath();
String responseString = ""; // 返回相应的数据.
Response response = new Response.Builder()
.code(200)
.message(responseString)
.request(chain.request())
.protocol(Protocol.HTTP_1_0)
.body(ResponseBody.create(MediaType.parse("application/json"), responseString.getBytes()))
.addHeader("content-type", "application/json")
.build();
return response;
}
... ...
}
-
由服务端API接口返回假数据(服务端同学的压力偏大一些)。
敏捷开发总体流程概述
![]()
1. 开一次 原型的需求评审，是为了让 测试，产品，开发，等等达成共识，这次会议很重要.(按照我们公司实际的情况，这种会议要开几轮，看大家情况而定吧)
2. 产品与UE，UI一起商讨界面的细节，比如跳转动画等等.(也可以开个会议或者私下沟通，不拘泥于形式)
3. 测试用例也不一定需要开会，主要看时间急不急，不拘泥于形式嘛.
4. 设计师根据原型图完成设计稿.(这里会影响 sprint backlog的进度)
![]()
5. 产品 排序 Product Backlog 的优先级 .
6. 计划会议 Sprint 中能够领取多少个 Backlog ，并估算时间。
7. 然后就是开发，每日例会，修BUG.
8. 迭代的最后一天，还有两个环节要做：成果展示（评审会议 review）和 团队的内部总结(回顾会议)，也有可能就发布了。
敏捷开发流程Sprint中的4个会议
![]()
Sprint周期(2~4周)：
-
1~2天计划会议.
-
1~3周的开发.
-
2~3天的测试，修复BUG.
-
1天的评审会议，回顾会议.
Sprint计划会议(Planning)
Sprint 计划会议非常关键，应该算是 Scrum中最重要的活动（这当然是我的主观意见）。
要是它执行的不好，整个 sprint 甚至都会被毁掉。
![]()
Sprint计划会议
(1~2天)，将领取的Backlog分解成一个个实际的开发任务，并评估开发时间。
-
对于需要使用的新技术，要估算学习和调研的时间。
-
我们需要编写什么样的接口？
-
我们需要创建什么样的架构？
-
我们需要更新哪些表？
-
我们需要更新或是编写哪些组件？
-
根据统计，每个程序员每天的有效工作时间是5个小时左右，其他时间都被沟通，喝水，休息，上洗手间等占据，所以如果某个任务估算超过5个小时，那就代表了这个任务完成需要超过一天的时间。
-
对于开发任务，估算尽可能的细，一般来说，每个任务的估算不应该超过5个小时，如果超过5个小时，就应该再把这个任务细分。只有尽可能细的估算任务，总的时间是大概精确地，因为估算时间是一个正态分布，有的任务估算的时间偏大了，有的时间任务估算的时间偏小了，估算越细，总体下来估算还是准确了。
最后，根据产品经理的优先级和开发人员的估算时间，确定最终的开发任务和优先级，即完成Sprint backlog。
Sprint每日站会(Daily)
![]()
![]()
例会目的：
例会内容：
每日例会前，开发人员整理各自的任务列表，包括
1. 昨天完成的任务，每个任务使用了多少时间，没完成的任务估算还要多少时间。
