一.今天完成的主要事情

1.对老大关于敏捷开发的知乎live的后半部分进行整理

6 研发阶段（ leader 的职责/设计方案/晨会/MiniDemo/每日部署/环境/晨报/CodeReview/性能测试/Demo/燃尽图/Task/延期风险/接口文档/UI 自测表/打包和部署)

方案设计:内容包括DB设计,关键sql语句,用户量预估,具体部署到哪一台机器(开发,测试,线上),原数据的迁移,历史系统的遗留问题,架构图(web和service的关系),逻辑图,核心算法.按照需求story设计方案,一般是说清楚功能的实现即可.方案设计时把所有想到的实现方案都列出来,并说出来自己的观点,最后在方案评审的时候定论.

定义接口:原本定义接口是在方案设计之后进行,但是如果后端的方案设计评审时间超过三天,那么就要先大概定义出接口的总数和一些接口的字段(避免后端拖累前端进度),接口的字段尽量和DB的字段相同.

建议前端此时先不写页面,而是根据原型图去写逻辑实现.

定义接口时由前后端一起来定接口,接口设计过程中的关键点有:

1.       用什么方法(一般为restful风格),写明是GET,POST,PUT,DELETE

2.       URL路径是否规范.不同的请求的URL有不同的规范,命名要符合restful风格的命名.

3.       传参,返回值,以及备注

设计接口要遵循的几个原则:

1.       尽量保证接口能够被复用,一个页面和接口耦合性要小,接口依据模块来分

2.       多个模块的接口如果要合并要满足两个条件,一个是用的特别多,另一个是不合并影响性能,否则就不合并

3.       接口中传输的数据尽可能少,如果有循环和嵌套,到底采用什么数据结构传输

接口由后端来写,但是一些具体的细节,比如加减字段,字段命名,字段类型等前后端人员都可以更改

接口文档:.接口文档的整体布局是先分模块,一般分为字段约定,前台接口,后台接口三个部分.每个模块中需要多少接口.接口文档设计好之后,后端提供假数据,因为敏捷开发中不存在前后端联调的概念,一直是持续集成,每一天都要看到一天的成果.当天把代码部署到svn或者git,把项目部署到开发环境中,第二天做minidemo.所以提供假数据的目的前后端已经开始持续集成的联调接口.

接口文档一定要及时更新,这一点非常重要,否则会非常影响团队的效率!

拆解task.目的是将每个story分解为一个个明确具体的步骤,预估出每个步骤所需的时间,时间粒度是0.5小时到4个小时之间,task要细致到怎样如何一步步的实现该story,(问题:拆解task时,测试和codereview环节是否也要拆在task中?如果需要,算作哪个story中呢?)

晨会:晨会从需求讲解之后贯穿至整个开发阶段.但在方案评审过了之后显得尤为重要

参与人员:所有研发人员

会议时间:一般15分钟,站会形式

会议内容:

1.昨天做了哪些事情,通过minidemo演示真实结果,否则,就不算有成果.晨会讨论时的粒度是完成几个task, 但晨会结论的粒度是story.

2.今天计划做哪些事情,粒度同上.晨会讨论时相互沟通要做什么事情,如果需要其他人配合,提前说明.

3.遇到的问题,有可能导致项目延期的问题,给出解决方案,该方案的粒度较粗,一般只定下具体讨论的时间节点,而不讨论具体的问题

4.晨会结论.晨会中最重要的结论就是当前项目是否会延期.判断的依据则是燃尽图,所以作为开发人员必须维护好燃尽图,否则无法提前预知开发风险.

燃尽图通过每天更新task时间维护,如果没完成,记录已花费的时间,然后再继续估计完成时间,如果已完成,记录花费的真实时间.

晨会结论以邮件的形式展示,粒度为story.晨报中要包括昨天完成了几个story,今天计划完成哪些story,有没有可能使项目产生延期的问题,项目可运行的结果地址,禅道地址,项目是否延期,延期几次,每次多少天,延期原因等.

Codereview:找其他的工程师来看代码写的怎么样

要求:

1.       代码是否规范

2.       代码中有没有风险,逻辑错误或者没有考虑的问题

3.       实现方式是否和方案设计一致

由水平比你高或者和你水平相当的其他工程师进行

Codereview的结论只有过与不过两种.codereview不过,不允许demo,codereview如果没过,项目风险要由自己承担,codereview如果不过,原则上是当场改正,改正之后再codereview,直到过了为止.

性能测试:要求复杂的接口一般不超过200ms,简单的接口不超过50ms,后端针对性能测试的结果要对接口进行优化,具体优化要对一个接口的总响应时间中的每一步所花费的时间了如指掌才可以.

Demo:研发人员演示自己的成果.提前准备,约定好谁去演示,标准是只要有任何一个肉眼可见的bug,都不允许过,因为要求demo之后的代码可以直接打tag. Demo的结论只有过和不过,如果不过,列出问题,定下次demo的时间;如果通过,给出测试时间和预计上线时间.

如果需求改动发生的延期,除了研发团队加班处理,只能对需求进行取舍,一些不是很重要的需求可以暂时先砍掉,放在下一个版本中迭代,总之,尽量保证不延期

打包,部署:demo之后要对代码进行存档,这个过程叫打tag.发布测试环境的代码是tag版本的代码.测试环境一般一天发布一次,不能一天发布多次,发布前要发申请邮件.发布测试环境一般只有两种情况,一个是修改bug之后发布测试环境,此时要挂上bug的地址,还有一个是新的迭代之后发布,此时要挂上新需求的禅道地址.

Wiki中上有专门的发布测试页面,记录每天发布的项目,版本号,发布步骤.其中发布步骤写的是发布的脚本,运维按照发布步骤发布,如果出现问题,那就是开发人员的问题

7 测试阶段(Bug 的级别/发布/发布日志/版本管理/发布步骤/上线时间）

Bug级别:见wiki文档

1.critical

2.block

3.major

4.normal

5.minor

修复优先级:

minor,normal级别的bug是可以放在下一个迭代版本中进行修复

major级别的bug需要你停下当前正在开发的项目,优先进行修复

block,critical级别的bug需要你在线上立刻修复

bug流转流程,见wiki文档

bug的接受时间要在2小时之内,bug流转要留痕

bug修复之后要发布测试,发布测试中发布功能描述只有两种,一种是版本迭代,此时要贴出来新版本的功能描述;还有一种是bug修复,bug修复时要贴出来bug号,bug链接.

发布步骤不是写链接,而是写清楚具体的步骤,负责人是谁去发布,有问题应该找谁

现在只是将老大的语音转化为文字,后续还要对整体进行提炼总结,最后弄好了也会分享出来的

2.参加老大为我们报名的腾讯主办的企业IT自动化运维解决方案的主题沙龙

一共有四场分享

分别是:

从0到1构建支撑企业自动化运维系统的PaaS

蓝鲸的持续集成部署设计与实践

世界五百强企业中的DevOps转型之道

使用DevOpsOne实现一站式软件交付

听完讲座,感触最深的是:所有新技术的出现都是为了解决原有的老问题

传统的软件部署方式存在的问题:对于一些规模比较大的企业,业务量非常大,有时一天可能要部署上百个版本,这些如果都用人工去部署,那么成本非常大,而且非常容易出错,因为企业的严格的部署流程有很多步骤,所以慢慢演化出了企业的自动化运维系统实现自动化运维部署,这就是DevOps

通俗点说,DevOps平台就是让开发人员编写的代码能够快速的上线,让用户感受到

但是自动化运维部署存在一些问题,如果购买现成的自动化部署工具,各种工具之间相互不兼容,无法互联互通,所以很多公司都选择自己开发持续部署平台,能够实现持续交付,将一些重复的工作交给持续交付平台来做,简化人为的部署工作,大大提高效率.但是在实施过程中也有一些问题,比如软件交付的工具链太多,缺乏自助式的交付流水线,流水线缺乏质量关卡,信息碎片化,无法暴露出交付流程中的问题等,使得DevOps一直难以落地

而这次DevOpsOne一站式软件交付平台集成腾讯开发的蓝鲸自动化运维系统,不仅能够解决传统运维的问题,而且还能够解决一站式软件交付实施中的问题,大大提高软件交付的效率,降低开发,测试,运维之间的沟通成本,将原本的链式环节变成了容器式的方式,在每个环节上都对开源的工具进行很好的支持,使我们可以简单的通过在页面上的点击就完成环境搭建,代码检查,性能测试,打包部署的一系列复杂的过程,提高效率

目前就只能先理解这么多,后续的免费的产品会下载下来尝试用一下的,感觉这应该是一个趋势,因为一直都是这样,新技术的出现就是为了提高开发效率,进而改变一个行业.

最后,当然要感谢老大给我们这次长见识的机会,否则真的是在坐井观天了,感谢老大,老大最帅!

三.遇到的问题

沙龙中讲的东西太多,一时理解不过来,先把资料存起来,以后随着学习的深入再去理解

四.收获

以上

五,项目进度情况

目前还剩下前端的页面需要实现,我暂时没有任务可做,应该是先跟着改几个bug,熟悉bug修复流程并且感受一下真实项目的氛围.