移动端敏捷开发之实践

最新推荐文章于 2024-06-14 11:20:36 发布

weixin_34413357

最新推荐文章于 2024-06-14 11:20:36 发布

阅读量377

点赞数

文章标签： json java python

原文链接：https://my.oschina.net/hailongqiu/blog/1583752

版权

2019独角兽企业重金招聘Python工程师标准>>>

由于本人水平有限，还往和多多大家交流，指出本文可以提升的地方，谢谢.

|传统的开发模式

瀑布模型
增量模型
快速原型模型
螺旋模型
喷泉模型
... ...

每种开发模型都各有各的好处，应用的场景也不一样，我无法去评价或者诋毁某种开发模式，因为我不够格。

在互联网公司，需要进行快速迭代，用户的需求可能每天或者每周，每个月都在变。

冗长的开发周期敌不过用户的需求变化，所以敏捷开发就诞生了，不能说敏捷开发十全十美，它只是一套方法论而已，需要改进去适应。

真正的竞争对手不是来自其它公司，而是用户不断变化的需求.

|敏捷开发

一句话概括敏捷开发——"将整个项目周期分成多个敏捷开发周期。”

测试？后台？产品？设计？开发？

全部东西拆分成多个迭代后，每次迭代后出来的东西是看的见，摸得着的，也可以快速得到反馈，而不是等到全部东西出来。

敏捷开发流程的一些疑问与困惑

测试如何早期介入？测试用例评审会什么时候开？

开发与测试本来就是一个团队的。

沟通的效率高了，尤其是开发和测试，因为很多问题开发和测试可以先沟通，这样很多问题也就可以提前解决了。

测试要更早的介入开发中，可以尝试用测试驱动的方法，这一点尤其对自动化来说更重要，但要知道，并不是每个开发任务都能这么做，这个主要是测试要多和开发的人进行沟通。

测试用例评审无论是敏捷开发还是传统开发都会遇到，这个感觉很尴尬，如果是全部都来，感觉不太合理，很浪费时间.（需要不断的实践，找出合适自己的方法）

当然，评审也可以变通一下，如果时间允许，可以找个会议室一起认真的过一下，如果时间不允许，可以发送給功能相关人员，让他们提供意见即可，或者测试人员内部简单过一下也可以，不要拘于形式，以项目实际情况做适宜的变通。

技术可行性如何介入？

场景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"
        } 
    }
}]

android retrofit + okhttp + rxjava，使用 Interceptor 拦截器也是可以返回假数据。

// 拦截器. (除了用作单元测试，还可以用作缓存处理，与服务端的并行开发)
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。