2018-11-12 10:03:57 An1090239782 阅读数 512
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10608 人正在学习 去看看 CSDN讲师

敏捷开发,之前一直关注这方面的内容,因为现在的公司是个小型团队,也是刚成立不久的公司,没有完善的体系和开发流程,无疑,敏捷开发为最适合当前使用的开发理论和方法。
之前看了很多敏捷开发方法论等知识,都觉得是无从下手,如之前的领歌当时觉得不错,就一直尝试多种敏捷开发工具的使用。
最近,BOSS推荐了一个敏捷开发工具,禅道。


首先,附上一些禅道界面。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

目前,使用的开源版,而且更多的功能仍需后续的学习和使用。

2017-03-01 10:19:32 xiaozei523 阅读数 2475
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10608 人正在学习 去看看 CSDN讲师

在敏捷开发中,我最推荐的工具是 禅道;

敏捷开中主要角色如下,技术管理这块 有些公司叫 项目管理,有些叫研发经理,有些叫技术经理;

ok 不管叫什么,他的职能是协调管理,懂技术;我们推荐这个 技术经理 角色来担当scrum master;

而产品经理 专注产品,测试专注质量,技术经理来协调沟通; 

插一张我最喜欢的图:


他们在禅道的日常工作如下:

产品经理工作:

登录禅道,进入产品视图。

1.创建产品

2.添加需求

3.发布一个产品版本


技术经理(项目/研发)经理工作:

登录禅道,进入项目视图。

1.创建项目(设置项目迭代周期,分配团队成员预计投入时间)

2.关联需求(先关联产品,再关联需求)

3.分解任务(1,来自需求的开发任务;2,技术改进/优化重构;3,新技术储备;4,文档整理总结)


测试主管工作:

登录禅道,进入测试视图。

1.创建Bug(影响版本和Bug标题,影响版本关联由产品经理先发布版本)

2.指派Bug给相关开发人员


开发团队工作:

登录禅道,进入我的地盘。

  1. 领开发任务

  2. 解决Bug


客户:

1,添加需求,确认需求。

2,提出BUG,验证BUG。

3,项目验收。


附加一些 研发过程中的方式方法来提高效率和质量:

单元测试、代码相互审核、持续集成

适度按需使用:测试驱动开发和结对编程

持续集成:每天凌晨通过jenkins 自动获取git上release分支的代码,进行编译和部署。
Web端会直接部署到Web测试服务器,客户端(PC、iPhone、iPad、Android)会自动拷贝到一个内部服务器上,供下载。
测试人员或者感兴趣的人每一天一上班就可以用到最新的版本。


2019-08-09 18:01:00 weixin_30421525 阅读数 1
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10608 人正在学习 去看看 CSDN讲师

敏捷开发

 

禅道

git

devops

转载于:https://www.cnblogs.com/cuiqq/p/11328844.html

2017-04-26 15:56:01 kenkao 阅读数 206
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10608 人正在学习 去看看 CSDN讲师

http://www.zentao.net/dynamic/80027.html

作者:李士心

来源:https://www.zhihu.com/question/21518108/answer/96043412

 

全面采用禅道的敏捷开发模式进行整个软件开发生命周期的管理,需求->设计->编码->测试->交付这四个阶段全部用禅道对应的功能进行规范化管理。

岗位划分:
1、项目经理
2、技术经理
3、测试经理
4、高级程序员(一般担任开发小组长)
5、程序员
6、前端工程师
以上2、4、5、6属于开发组,3属于测试组


具体开发工作流程如下:
1、与甲方做需求前期讨论
负责人:项目经理
参与者:技术经理、测试经理及其它有必要参与的人员

外部需求讨论阶段不需要进禅道,用excel格式的会议纪要、邮件等进行沟通


2、与甲方一起确定需要进行开发的需求及优先级
负责人:项目经理
参与者:技术经理

把最终确定的需求,细化之后把细化的需求录入到禅道并设定好优先级,优先级为1的为下一个版本要实现的需求,这里要注意一定是细化的需求,比如:原始需求是“支持多城市,定于4月15日上线区内其他4个城市”,从这个需求细化出来的应该是具体到页面的需求,如:多城市_修改订单列表页面使之支持多城市...
确定下一次发版后要完成的需求后,项目组内部开全会通报所有需求,测试经理开始准备测试用例


3、确定好将要发版的组件版本
负责人:项目经理
每一次发版的版本号规范如下:
1)版本号第二位加1,第三位为0,如:V2.2.0
2)在正式发版之后如果有小改,则第三位递增,如:V2.2.1,V2.2.2...
一般来说,按两周发布一个版本的周期发版
在项目-版本中定义好版本,并把版本与需求关联起来(一个需求可以和多个版本关联,比如:需求002:订单列表页支持多城市的不同操作员只能看到本城市的订单,此需求牵涉到:订单中心组件V2.2.0、商品中心组件V2.2.0、微商城/PC商城组件V2.2.0这几个版本,都要关联上)


这里要注意的是,要分组件定义版本,要求所有组件的版本号都保持一致,举例如下:
1)微商城/PC商城组件V2.2.0
2)订单中心组件V2.2.0
3)商品中心组件V2.2.0
4)门店系统组件V2.2.0
5)呼叫中心组件V2.2.0
6)门店APP组件V2.2.0
在项目-版本-查看bug,可查看此版本下的bug的清单


4、根据需求细化并分配开发任务
负责人:技术经理
禅道路径“项目-任务”,做开发任务分配的时候,一般来说都会从一个需求分出多个开发任务,任务是最原子的事务,一个任务只能是一个执行人,如:
需求为:修改XXX页面使之支持不同城市的操作员只能显示本城市的信息
分配出3个任务:
1)修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-详细设计
2)修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-后端编码
3)修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-前端编码


5、根据开发需求做设计文档
负责人:分配了任务的开发组相应人员
监督人:技术经理
根据情况安排编码程序员做设计文档(没有太大难度的功能)或者是由高级程序员或技术经理做设计文档(有一定难度的功能),统一放到SVN。
文档标题格式:设计文档_需求ID_需求标题,如:设计文档_需求001_修改XXX页面使之支持不同城市的操作员只能显示本城市的信息


6、编码阶段
负责人:分配了任务的开发组相应人员
监督人:技术经理、开发小组长
1)程序员根据禅道上的任务按计划编码和做单元测试
2)程序员每天早上要自己去开启分配给自己的任务,任务完成后点击“完成”
这里要特别强调: 采用禅道来分配任务并不是说不需要当面沟通,当面沟通依然是最重要的
禅道可与SVN集成,使得技术经理可以直接在禅道上review代码(社区版无此功能)
3)技术经理负责每天的代码review和解决技术难题
4)项目经理负责每天监控开发进度,发现情况及时沟通处理,项目经理根据任务的完成情况,及时修改需求的进度,使得甲方能及时了解进度情况,需求的进度统一写在备注”,格式如下:
研发完毕时间:2016-04-08晚上7点
测试完毕时间:2016-04-19晚上7点
发布上线时间:2016-04-20凌晨2点

7、编码完成,提交集成测试
1)技术经理自测后认为可以提交集成测试后, 在禅道路径“项目-版本”里,提交测试
2)技术经理把代码部署到测试服务器上
3)测试经理安排测试并提交bug(提交bug的时候,属于这次发版要修正的bug,严重程度设为1,其他不属于这次发版的bug,设为2或3)
4)如果测试进入收尾阶段,即将定版的,技术经理把当前提交测试的代码在SVN上打一个对应版本的Branch分支(名称格式:V2.2.0_Testing),修改bug的人员集中在几个核心程序员上,减少引发新bug的几率,在通知核心程序员switch到此Branch后,立即修改SVN上的权限设置从Trunk上删除核心程序员的读写权限避免人为错误,其他程序员在Trunk分支上继续后续的开发
注意:
1)测试-bug中提交bug的时候,务必要选择对应的版本号
2)每次技术经理更新文件到测试服务器,都要在钉群里通告大家,并附上此次更新修复的bug清单


8、测试完成,发版前的最后审核
在测试经理回归完所有1级bug,认为可上线后
1)测试经理报告项目经理可以发版了
2)项目经理自己要再做一次测试,确保品质
3)项目经理测试后也认为没问题了,提交给甲方进行发版前的验收测试(如果有必要的,也可让甲方在阶段7参与测试)


9、甲方确认可以发版,正式发版
在甲方进行验收测试认为可以发版后,
1)测试经理,进禅道路径“测试-版本”,修改已测试好的版本,设为“已完成”
2)技术经理把此次发版需要更新的代码、数据库SQL脚本打包出来
3)项目经理从禅道的项目-需求列表里导出(复制出)此次发版关联的需求为Excel文件,此文件就是提供给甲方的changelog文档
4)项目经理向甲方提供changelog文档,并让甲方签署上线确认书
5)技术经理把将要发版的文件小心谨慎地发布到生产服务器上
6)项目经理在禅道“产品-发布”中设定与项目-版本相同的发布,备注好发版时间和发版内容,并把版本和发布一对一关联起来
7)技术经理在发版第二天,在SVN上从Branch里导出一个Tag,名称格式:V2.2.0_Release


10、版本维护阶段
在发版之后,一般来说,还是会发现一些之前没注意到的Bug需要修改,因此,在下一次大版本发版之前,需要继续维护当前版本,具体做法如下:
1)技术经理从之前发版的Tag下的Release导出一个Branch,如:V2.2.0_Fixbug
2)测试经理根据客户处反馈的情况,继续发bug到禅道上,严重程度为1,版本号为V2.2.0
3)技术经理安排相关人员在V2.2.0_Fixbug分支下修改bug(一般来说,只安排专职负责旧版本维护的程序员去处理这些bug,最好是技术经理自己负责处理),这里要注意SVN的权限,此Fixbug分支只给具体修改的程序员分配读写权限
4)测试经理安排做回归测试
5)2、3、4步骤循环进行,直到认为可以发版了,则确定版本号,比如为:V2.2.1,并从V2.2.0_Fixbug导出一个Tag为V2.2.1_Release,由技术经理更新的生产服务器上(发版前也要导出修改的bug清单给甲方确认)
以上2、3、4、5步骤迭代循环,直到停止维护此版本


11、停止维护老版本
在新版本即将发布前夕,一般是5天内,则停止老版本的维护
1)技术经理在告知相关程序员把本地的工作目录switch到Trunk后,关闭svn上的老版本Branch的程序员读写权限
2)项目经理关闭老版本的发布,禅道路径“产品-发布”,设置此版本对应的发布为“停止维护”(这个步骤不能忘记,否则在bug里边选择版本的时候,没有被停止维护的发布对应的版本会一直显示出来)

这里要特别注意的是: 不是说这一次发版完成了才开始新的一次发版之旅,一般来说,在步骤2完成之后,项目经理就要开始和甲方一起沟通下一次发版的需求了,然后是技术经理从需求分配任务,开始新一次发版之旅。这就是螺旋状上升的敏捷迭代开发之路。

2019-06-27 01:13:47 morpheus_1125 阅读数 552
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10608 人正在学习 去看看 CSDN讲师

基于禅道的敏捷开发模式的周期

下面是对全面采用禅道的敏捷开发模式进行整个软件开发生命周期的管理简单介绍和整理。
【需求->设计->编码->测试->交付->维护】,整个周期的六个阶段全部用禅道对应的功能进行规范化管理。

岗位划分

  1. 产品经理(Product Manager)
  2. 项目经理(Developing Manager,Project Leader)
  3. 测试经理(Testing Manager,Test Leader)
  4. 高级程序员、程序员(Software Engineer)、前端工程师(UI Designer)

适用范围

  1. 小型的应用类项目,可以采用SCRUM模型。

  2. 大型的开发项目,可以整体采用瀑布模型,局部使用SCRUM模型。

     但Zentao一般用得多的也是小型应用类项目了。
    

工作流程

全览:
全览

1. 需求分析

  1. 与甲方做需求前期讨论
  • 负责人:产品经理
  • 参与者:项目经理、测试经理及其它有必要参与的人员
    外部需求讨论阶段不需要进禅道,用Word格式的会议纪要、邮件等进行沟通
  1. 与甲方一起确定需要进行开发的需求及优先级
  • 负责人:产品经理
  • 参与者:项目经理
    客户最终确认 的需求分为 产品需求项目需求 ,分别编写 产品文档项目文档 。讲两份文档上传到禅道图产品-文档】中,分为产品和项目两部分。说明:项目文档是对产品文档的补充,项目定制化的需求描述,在SVN目录中也将文档归档一份。
    同时将需求 细化 之后把细化的需求录入到禅道,设定好优先级。
    优先级为1的为下一个版本要实现的需求,这里要注意一定是 细化 的需求,比如:原始需求是“支持多城市,定于4月15日上线区内其他4个城市”,从这个需求细化出来的应该是具体到页面的需求,如:多城市_修改订单列表页面使之支持多城市…
  1. 确定好将要发版的组件版本,创建发版计划
  • 负责人:产品经理
    每一次发版的版本号规范如下:

    1)版本号第二位加1,第三位为0,如:V2.2.0
    2)在正式发版之后,如果有小改,则第三位递增,如:V2.2.1,V2.2.2…

    一般来说,按两周发布一个版本的周期发版在【项目-版本】中定义好版本,并把版本与需求关联起来(一个需求可以和多个版本关联,比如:需求002:订单列表页支持多城市的不同操作员只能看到本城市的订单,此需求牵涉到:订单中心组件V2.2.0、商品中心组件V2.2.0、微商城/PC商城组件V2.2.0这几个版本,都要关联上)
    这里要注意的是,要分组件定义版本,要求所有组件的版本号都保持一致。
    举例如下:

    1)微商城/PC商城组件V2.2.0
    2)订单中心组件V2.2.0
    3)商品中心组件V2.2.0
    4)门店系统组件V2.2.0
    5)呼叫中心组件V2.2.0
    6)门店APP组件V2.2.0

    禅道图项目-版本-查看bug】中可查看此版本下的bug的清单

  1. 项目启动KickOff会议:
    确定下一次发版后要完成的需求后,项目组内部开全会通报所有需求,测试经理开始准备测试用例

2. 项目设计开发测试

  1. 根据发版版本创建项目,并将需求关联到项目中
  • 负责人:项目经理
    在禅道【项目】中创建发版对应的项目,将需求关联进项目。
    从上一发布版本的develop分支上checkout出发版的功能分支,功能分支命名方式:function/组件名称+版本号_上线时间
  1. 根据需求细化并分配开发任务
  • 负责人:项目经理
    禅道图项目-任务】中针对单个需求做开发任务分配的时候,一般来说都会从一个需求分出多个开发任务,任务是最原子的事务,一个任务只能是一个执行人。
    如:需求为:修改XXX页面使之支持不同城市的操作员只能显示本城市的信息。
    分配出3个任务:

    1)修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-详细设计
    2)修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-后端编码
    3)修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-前端编码

  1. 根据功能需求做设计文档
  • 负责人:分配了任务的开发组相应人员
  • 监督人:项目经理
    根据情况安排编码程序员做设计文档(没有太大难度的功能)
    或者是由高级程序员或项目经理做设计文档(有一定难度的功能)
    统一放到SVN。(按需求组织)
    文档标题格式:设计文档_需求ID_需求标题,
    如:设计文档_需求001_修改XXX页面使之支持不同城市的操作员只能显示本城市的信息
  1. 编码阶段
  • 负责人:分配了任务的开发组相应人员
  • 监督人:项目经理、开发小组长
    1)程序员根据禅道上的任务按计划编码和做单元测试
    2)程序员每天早上要自己去开启分配给自己的任务,任务完成后点击“完成”。
    3)任务需要多天时,记录当天已投入工时,以及还需要的工时,由禅道自动计算任务进度。
    4)项目经理负责每天监控开发进度,定期review代码和及时解决技术难题
    5)产品经理根据需求相关的完成情况,及时修改需求的进度,使得甲方能及时了解进度情况。需求进度统一写在备注。格式如下:研发完毕时间:2016-04-08晚上7点;测试完毕时间:2016-04-19晚上7点;发布上线时间:2016-04-20凌晨2点。
  1. 编码完成,提交集成测试
  • 负责人:项目经理
  • 监督人:产品经理
    1)项目经理自测后认为可以提交集成测试后, 由产品经理阶段性验收通过。在禅道图项目-版本】里,创建版本,并将代码合并到Release分支提交测试。
    2)测试经理通过部署脚本将代码部署到测试服务器上
    3)测试经理安排测试并提交bug(提交bug的时候,属于这次发版要修正的bug,严重程度设为1,其他不属于这次发版的bug,设为2或3)
    4)测试经理发布 测试通过报告 后,项目经理把当前提交测试的代码在Release分支上打一个对应版本的Tag(名称格式:V2.2.0_Testing),修改bug的人员集中在几个核心程序员上,减少引发新bug的几率。
    注意:

    1)【测试-bug】中提交bug的时候,务必 要选择对应的 版本号
    2)每次项目经理更新文件到Release分支上,都要在钉群里通告大家,并附上此次更新修复的bug清单,由测试经理择机重新部署指定版本的代码。

3. 验收发版

  1. 灰度环境测试,发版前的最后审核
    在测试经理回归完所有1级bug,认为可上线后,由项目经理将代码部署到灰度测试环境。

  2. 产品经理及测试经理,再次在灰度测试环境做一次测试,确保品质。

  3. 产品经理及测试经理测试后也认为没问题了,提交给甲方进行发版前的验收测试(如果有必要的,也可让甲方在阶段 2) 参与测试)

  4. 甲方确认可以发版,正式发版
    1)测试经理进禅道图测试-版本】,修改已测试好的版本,设为 “已完成”
    2)项目经理把此次发版需要更新的代码、数据库SQL脚本打包出来
    3)产品经理从禅道图的【项目-需求】列表里导出(复制出)此次发版关联的需求为Excel文件,此文件就是提供给甲方的changelog文档。
    4)产品经理向甲方提供changelog文档,并让甲方签署上线确认书
    5)项目经理把将要发版的文件小心谨慎地发布到生产服务器
    6)产品经理在禅道图产品-发布】中设定与禅道图项目-版本】相同的发布,备注好发版时间和发版内容,并把版本和发布一对一关联起来,并标记相关联的需求为**“已发布”**。
    7)项目经理在发版第二天,将Release分支合并到master分支,并在master分支上标记Tag,名称格式:V2.2.0_Release

4. 版本维护阶段

在发版之后,一般来说,还是会发现一些之前没注意到的Bug需要修改,或者客户对上线版本有细微调整需求,因此,在下一次大版本发版之前,需要继续维护当前版本,具体做法如下:
1)项目经理从之前发版的Tag下的Release分支导出一个快速修复分支,如:Hotfix_V2.2.0
2)测试经理根据客户处反馈的情况,继续发bug到禅道上,严重程度为1,版本号为V2.2.0
3)项目经理安排相关人员在Hotfix_V2.2.0分支下修改bug(一般来说,只安排专职负责旧版本维护的程序员去处理这些bug,最好是项目经理自己负责处理)。
4)测试经理安排做回归测试
5)2、3、4步骤循环进行,直到认为可以发版了,则确定版本号,比如为:V2.2.1,并将Hotfix_V2.2.0合并到Release分支,标记Tag为V2.2.1_Release,由项目经理更新的生产服务器上(发版前也要导出修改的bug清单给甲方确认)
以上2、3、4、5步骤迭代循环,直到停止维护此版本

5. 停止维护老版本

在新版本即将发布前夕,一般是5天内,则停止老版本的维护
1)项目经理在告知相关程序员检查本地分支是否有未提交代码后,将老版本对应的function/分支删除。
2)产品经理关闭老版本的发布,禅道图产品-发布】,设置此版本对应的发布为 “停止维护” (这个步骤不能忘记,否则在bug里边选择版本的时候,没有被停止维护的发布对应的版本会一直显示出来)
这里要特别注意的是: 不是说这一次发版完成了才开始新的一次发版之旅,一般来说,在步骤2完成之前,产品经理就要开始和甲方一起沟通下一次发版的需求了,然后是项目经理从需求分配任务,开始新一次发版之旅。这就是螺旋状上升的敏捷迭代开发之路。


在原文基础上有所修改,感谢Leo笑
作者:Leo笑 原文:https://blog.csdn.net/hgstclyh/article/details/81206618

没有更多推荐了,返回首页