一.今天完成的主要事情

对之前老大讲的敏捷开发的知乎Live进行总结,提炼以后做真实项目时就按照这个总结出来的结果作为标准

一. 为什么需要敏捷开发

传统开发流程痛点:1,开发流程耗时长,风险大2.开发出来的成品和需求不匹配3.成品做好的时候需求已经发生了大的改变,成品没有价值

敏捷开发的出现是为了解决传统开发中的痛点.敏捷开发最大的作用是在用户需求不断变更的情况下最大程度的保证开发的质量.其次是降低项目开发中每个环节的风险,确定项目延期应对措施,厘清各个角色的职责

二. 敏捷开发流程中有哪些工具可以使用

三大宝:禅道,wiki,邮件.

禅道:项目进度管理工具

Wiki:文档管理工具,推荐使用Confluence版

邮件/QQ:成员之间交流工具,推荐使用网易和腾讯企业邮箱

三. 敏捷开发中涉及到的角色

产品经理,UI设计师,前端工程师,后端工程师(包括初级工程师和架构师),Android/IOS工程师,测试人员,运维人员,各个小组leader.

四.  敏捷开发流程

敏捷开发周期整体分为三个阶段:产品设计阶段,开发阶段,测试阶段

按阶段细分各个流程

第一,产品设计阶段

1.产品初步设计

任务:产品经理根据用户的要求设计产品需求

涉及角色:产品经理(一般为1人)

成果: 准备好三样东西:产品讲解PPT,产品story,原型图

标准:

产品讲解PPT标准:说明做这件事情的价值何在.

具体细节,第一,说明当前需要解决的问题是什么;第二,当前行业内解决问题的方式有哪些;第三,这些解决方案的优劣;第四,我们预计的解决方案有哪些;第五,我们具体要怎么做,做到什么程度.

Story (故事)标准:说清楚三要素,控制好粒度,明确优先级.

story三要素:第一,当前的用户角色是什么;第二,给当前的用户提供什么服务;第三,给当前的这个用户带来什么价值

以注册流程解释:作为一个想要加入我们使用我们服务的用户,想要在官网完成注册,以便享受只有注册用户才能享受到的服务

Story粒度:三个标准,第一,一个story的开发工作量不应该超过一周;第二,一次迭代中story不应该超过15个;第三,story的拆解要保证独立.验收标准用于弥补story粒度较粗的问题,验收标准比story粒度更细. story帮助我们理解需求的概念和价值,而验收标准是保证信息在传递过程中没有偏差.

Story优先级:必须明确优先级,标准有产品经理确定,开发人员按照story优先级的顺序实现功能.

原型图标准: 研发人员能否快速理解产品人员到底想做什么事情,尤其是一些复杂的行业.

具体细节,一是能否准确表达产品经理想要表达的元素,二是流程设计是否能完整体现,三是原型图必须一比一,四是页面按照模块分,将所有页面在文件夹中列出来,五是部分验收标准可以在页面中展示出来,六是不推荐在原型图中做跳转和高保真.

2.内部初步评审

任务: 初步设计出来的需求在产品组内部进行初步评审,获取他人反馈,进一步完善需求,提前控制风险

涉及人员:负责该项目的产品经理和产品组所有成员

成果: 一是确定需求的大方向,二是考察产品的细节是否周全,三是统一整个产品的风格和细节规范

标准:以是否形成成果为标准

3.需求评审(重要)

任务: 和该项目有利益相关的所有部门统一对需求进行讨论,最终确定需求

涉及人员:产品经理,产品部门,研发部门,运营部门,CTO等所有对该产品有决策权的人员, 如果研发部门的leader不能参加,那么研发部门下的各个小组的leader要参加.总之,参加人员一般为公司管理层,不推荐一般的工程师参加

成果: 第一,确定要做的需求;第二,确定该需求是否能够实现;第三,整个项目的预计完成时间,由参加需求评审的研发团队的leader预估给出;第四,研发团队的具体成员是谁;第五,定下来需求讲解的时间点.最终结论只有通过/不通过,不通过,继续从步骤1开始,通过则进入研发阶段.

标准:一是是否将所有需求都过了一遍;二是是否敲定了所有需求的细节;三是不允许存在大概,差不多这类的结论,结论必须要精确

TIPS: 1.需求评审通过之后,其他人员不能再对需求有异议.如果在需求评审之后发现需求有问题,那么就是所有参加需求评审的人员的失职.

2. 需求评审之后,PPT,Story,原型图应该不再发生变化.此时测试人员写测试用例,测试用例的要求是保证没有漏掉需求出现的任何可能,保证不会漏测.

4.需求讲解(重要)

任务:产品经理向整个研发团队人员讲解需求.产品经理负责讲清楚需求,研发团队负责理解需求并思考需求的大概实现.研发团队的任务一是必须要准确理解需求,包括为什么这么做以及需求的细节是否考虑到,有不理解的及时与产品经理沟通,二是思考需求的大概实现方案,要求是第一时间判断需求能不能实现,实现时有哪些不确定的地方,需求有没有逻辑混乱的地方,需求是否合理.

涉及人员:产品经理,参与产品开发的所有研发团队成员

成果: 研发团队定出方案设计的时间,定下方案评审的时间点.

标准:产品经理讲清楚需求的标准是以下四点是否讲清楚, 一是为什么会有这个需求,二是整个产品的业务流程大概是什么样,三是原型如何跳转,四是细节如何交互等.

研发团队理解需求的标准一是要知道为什么这么做,二是需求的细节是否考虑到,有不理解的及时与产品经理沟通,三是第一时间判断需求能不能实现,四是实现时有哪些不确定的地方,需求有没有逻辑混乱的地方,需求是否合理等.

TIPS:1.原则上:需求讲解是讲给所有研发团队人员听,而且需求评审和需求讲解的间隔时间在2天内,如果研发团队人员短期凑不齐,那么产品经理可以多讲两次.

       2. 需求讲解研发团队在需求讲解上一定要把需求弄明白,不明白的需求坚决不能做,而且不弄明白需求也不能停止需求讲解,一定要把需求弄明白.

       3. 如果研发人员对需求有意见或者研发人员认为需求不合理,原则上要尊重产品人员的意见,作为产品人员也要尊重开发人员的意见,如果开发人员的提到的意见产品人员考虑过,向开发人员解释,开发人员尊重产品人员的决策.如果没有考虑到,则是产品人员的失职,返回重新考虑.

第二,产品研发阶段

5.方案设计,定义接口文档(重难点)

任务:研发团队人员根据需求设计实现方案

涉及人员:研发团队所有人员,包括前后端,安卓,IOS等

成果:接口文档,设计好的方案,数据表

标准:

实现方案: 要包括DB设计,关键sql语句,用户量预估,部署机器(开发,测试,线上),原数据的迁移,历史系统遗留问题解决方案,架构图(web和service的关系),逻辑图,核心算法.

接口文档:内容包括要按照模块划分接口,有几个web就分几个模块;必须要有字段约定;接口中HTTP请求方法,URL路径,传参,返回值以及备注必须符合规范,要求HTTP请求标注具体使用的方法,不同请求采用不同的URL路径,路径命名一律使用restful风格请求.

TIPS:

1.所有人员写方案,架构师负责评审方案

2.实现方案按照story设计,一般说清楚功能的实现即可.方案设计时把所有想到的实现方案都列出来,并说出自己的观点,判断不同方案的优劣,最后在方案评审的时候定论.

3.接口由前后端人员一起对照原型图中的页面一起定义

4. 设计接口要遵循的几个原则.一是尽量保证接口能够被复用,一个页面和接口耦合性要小;二是对于多个模块的接口,只有用的特别多和不合并影响性能时才会合并接口;三是接口中传输的数据尽可能少;四是接口由后端来写,但是一些具体的细节,比如加减字段,字段命名,字段类型等前后端人员都可以更改;五是接口字段尽量和DB字段相同,避免二次映射

5. 接口文档必须要及时更新

6.方案评审

任务:评估方案设计是否合理

涉及人员:开发组成员

成果:方案是否通过,不通过存在的问题是什么

标准:???

TIPS:

7.拆解task

任务:将每个story分解为一个个明确具体的步骤,预估出每个步骤所需的时间

涉及人员:每名开发人员

成果:在禅道能够看到拆解的每个task以及所需要的时间

标准:一是时间粒度要在0.5小时到4小时之间,二是task要细致到怎样一步步的实现该story

TIPS:开发阶段后端首先要提供假数据,因为敏捷开发中不存在前后端联调的概念,一直是持续集成,每一天都要看到一天的成果.当天把代码部署到svn或者git,把项目部署到开发环境中,第二天做minidemo.所以提供假数据的目的前后端已经开始持续集成的联调接口.

8.开发阶段

任务:完成拆解好的task,通过晨报,晨会记录项目进度,提前控制风险.

涉及人员:开发人员,项目leader

成果:晨报,禅道燃尽图

标准:每天开晨会,每天早上发晨报,每天下班前上传成果至svn和开发环境,更新task时间

TIPS:

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

参与人员:所有研发人员

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

会议内容:

1.昨天做了哪些事情,通过minidemo演示真实结果,否则,就不算有成果.晨会讨论时的粒度是完成几个task, 但晨会结论的粒度是story,是否完成标准以能否在开发环境上看到成果为准.

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

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

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

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

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

9.codereview阶段

任务:请水平和自己相当或者水平比自己高的工程师查看

涉及人员:开发人员

成果:是否通过,不通过说明问题

标准:一是代码是否规范,二是代码中有没有风险,逻辑错误或者没有考虑的问题,三是实现方式是否和方案涉及一致

TIPS:1.由水平比自己高或者水平相当的其他工程师进行

2.如果不通过,不允许demo,而且项目风险由自己承担,原则上当场改正,改正之后再codereview,直到过了为止

10. 性能测试

任务:工程师对自己实现的接口进行性能测试

成果:将简单接口的访问时间控制在50ms以下,复杂接口访问时间控制在200ms以下.

标准:工程师要对每一个接口中时间的消耗情况了如指掌

11.项目demo阶段

任务: 研发团队完成了所有需求并把成品交付给产品团队

涉及人员: 产品经理,研发团队小组leader,测试人员,甚至是技术总监

成果:研发团队人员讲述做了哪些东西,并将所有流程都跑一遍,得出demo结论,通过/不通过,通过定下测试时间和预计发布时间,不通过列出问题,定下次demo时间.

标准:不能出现任何一个肉眼可见的bug

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

12.打包部署

任务:对代码进行存档

涉及人员:开发人员,运维人员

成果:发布结果

标准:测试环境一天发布一次,发布前要发申请邮件,登记wiki的相关页面

TIPS: 1.发布测试环境一般只有两种情况,一个是修改bug之后发布测试环境,此时要挂上bug的地址,还有一个是新的迭代之后发布,此时要挂上新需求的禅道地址.

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

第三,测试阶段

13. 测试阶段

任务:

涉及人员:有运维,测试以及开发.

成果: 测试人员 跑测试样例,对产品进行测试,不仅能够找出bug,同时还能够推动bug解决

标准: 一是测试环境要保证稳定,二是测试人员不仅要能够找出bug,确定bug优先级,还要负责追踪并推动bug解决.整个团队需要关注的是具体的线上发布时间.

14.发布线上

任务:产品上线

涉及人员: 有运维,开发团队,项目leader,测试等所有和该项目有关的人员.

成果:

标准:

有了这个标准,以后做项目的时候就知道每个环节要做什么事情,做到什么程度,标准是什么,就不会出现像是没头苍蝇一样不知道做什么,同时也有一个标准判断team中的成员做的怎么样

2.下午参加了韦杰这一组的复盘项目的方案评审

发现了一些问题:

比如表中记录有冗余,有删除用户数据的问题,用户续投的产品上下架续投失效的问题

通过复盘评审,自己也发现了一些他们在设计上的可取之处

比如后台添加银行时先判断银行是否存在,将排序字段直接写在表中等

二.明天计划完成的事情

1.继续Hibernate的学习,主要学习Hibernate的query查询和criteria查询,主要关注项目中常用的动态查询,批量查询等

三,遇到的问题

暂无

四,收获

以上

五,项目进度情况

又延期了,我继续学习刷基础吧