由于本人水平有限,还往和多多大家交流,指出本文可以提升的地方,谢谢.
每种开发模型都各有各的好处,应用的场景也不一样,我无法去评价或者诋毁某种开发模式,因为我不够格。
在互联网公司,需要进行快速迭代,用户的需求可能每天或者每周,每个月都在变。
冗长的开发周期敌不过用户的需求变化,所以敏捷开发 就诞生了,不能说敏捷开发十全十美,它只是一套方法论而已,需要改进去适应。
真正的竞争对手不是来自其它公司,而是用户不断变化的需求.
一句话概括敏捷开发——"将整个项目周期分成多个敏捷开发周期。”
测试?后台?产品?设计?开发?
全部东西拆分成多个迭代后,每次迭代后出来的东西是看的见,摸得着的,也可以快速得到反馈,而不是等到全部东西出来。
开发与测试本来就是一个团队的。
沟通的效率高了,尤其是开发和测试,因为很多问题开发和测试可以先沟通,这样很多问题也就可以提前解决了。
测试要更早的介入开发中,可以尝试用测试驱动的方法,这一点尤其对自动化来说更重要,但要知道,并不是每个开发任务都能这么做,这个主要是测试要多和开发的人进行沟通。
测试用例评审无论是敏捷开发还是传统开发都会遇到,这个感觉很尴尬,如果是全部都来,感觉不太合理,很浪费时间.(需要不断的实践,找出合适自己的方法)
当然,评审也可以变通一下,如果时间允许,可以找个会议室一起认真的过一下,如果时间不允许,可以发送給功能相关人员,让他们提供意见即可,或者测试人员内部简单过一下也可以,不要拘于形式,以项目实际情况做适宜的变通。
场景1:技术可行么,不会开发到一半写不下去了?技术方案要不要写?如何去技术选型?要不要去评估,又要浪费多少时间?
场景2:等到原型或者需求文档完全出来,然后在会议上进行各种讨论,很大程度上浪费了大家的时间,然后反复如此?时间都浪费在开会上了,效率低下。(可怕的是这个会议只是需求评审,并不关注可行性,又或者 需求评审,技术可行性一起来~!~!~!~!)
该这么办?
在早期产品 整理需求,用户数据,调研,竞品分析,进行产品 原型制作以及产品需求文档的过程中,
该项目的负责人或主要开发人员 就应该协助产品经理了解 产品的开发难度以及可行性,逻辑错误 等等,让产品做好原型或需求文档的调整。
场景:我们时常会遇到这种情况,后台有部分接口没有开发完毕,你需要等待他完成,你才能进行,拖延进度可不是一天,两天哈。
下面介绍了三种方式 ServiceMock 和 网络请求三件套(retrofit + okhttp + rxjava),后台直接暴力返回假数据:
- // 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;
- }
- ... ...
- }
1. 开一次 原型的需求评审,是为了让 测试,产品,开发,等等达成共识,这次会议很重要.(按照我们公司实际的情况,这种会议要开几轮,看大家情况而定吧)
2. 产品与UE,UI一起商讨界面的细节,比如跳转动画等等.(也可以开个会议或者私下沟通,不拘泥于形式)
3. 测试用例也不一定需要开会,主要看时间急不急,不拘泥于形式嘛.
4. 设计师根据原型图完成设计稿.(这里会影响 sprint backlog的进度)
5. 产品 排序 Product Backlog 的优先级 .
6. 计划会议 Sprint 中能够领取多少个 Backlog ,并估算时间。
7. 然后就是开发,每日例会,修BUG.
8. 迭代的最后一天,还有两个环节要做:成果展示(评审会议 review)和 团队的内部总结(回顾会议),也有可能就发布了。
Sprint周期(2~4周):
Sprint 计划会议非常关键,应该算是 Scrum中最重要的活动(这当然是我的主观意见)。
要是它执行的不好,整个 sprint 甚至都会被毁掉。
Sprint计划会议(1~2天),将领取的Backlog分解成一个个实际的开发任务,并评估开发时间。
最后,根据产品经理的优先级和开发人员的估算时间,确定最终的开发任务和优先级,即完成Sprint backlog。
例会目的:
例会内容:
每日例会前,开发人员整理各自的任务列表,包括
1. 昨天完成的任务,每个任务使用了多少时间,没完成的任务估算还要多少时间。
2. 剩余的开发时间
例会注意事项:
相关开发人员在评审会议中向全体人员演示APP的功能。(这次可以当成验收)
网上有些文章是取消掉这个环节,还有的是经过评审会议 就发布de等等。
仁者见智吧,适合自己的才是最好的。
回顾会议我们能说是复盘么?还只是总结会议?还是一场批斗大会?表彰大会?
研发完成后开回顾会议,每个成员都在会议中提出两点:
这个过程走两轮,即每个成员都要提两点做得好和不好的地方。注意当一个成员提出自己的意见时,为了避免误变成批斗大会,其他成员不做任何的评论。
最后再总结如何改进等等。
敏捷开发概念
敏捷开发-实例1
SCRUM敏捷开发教程
如何在项目中实施敏捷开发scrum
从PM的角度聊聊敏捷开发
敏捷开发之Scrum扫盲篇
瀑布与敏捷的对比
没有敏捷工具如何做管理敏捷项目
敏捷革命
来源: https://juejin.im/entry/5a292af85188252da053544d