2019-09-04 23:19:28 ChibiMarukoChan 阅读数 83
  • SCRUM敏捷开发视频教程

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

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

一、Product Backlog

  • PB梳理:满足DEEP原则:详略得当、经过估算的、按优先级排序的、涌现的
  • PB的排序技术:MoSCow,Kano模型
  • PO是唯一的负责人
  • 遇到新需求都要放到PB表中重新排序
  • PB梳理会

二、Sprint Backlog

  • 是当前sprint工作的分解;
  • 工作不是分配下去,团队自我认领;
  • 团队商量的结果
  • 每个团队成员都可以更改sprint Backlog,是团队的资产

三、燃尽图

  • 不同情况下分析
  • 不能团队不能比较
  • 当前迭代中,迭代速率保持不变
  • 略微的缓慢下滑曲线:可能团队遇到了障碍
  • 稍微上浮:Sprint列表中加入的新任务;有些任务估算不准确

四、其他

向PO提出澄清需求——待办事项梳理会

要了解团队当前的迭代状态,查看——迭代燃尽图

敏捷团队在每个迭代都交付一样的故事点,但是管理层要求团队提高生产力,交付更多,如何做?——确保管理层理解敏捷实践

2013-12-26 13:08:00 keke_Xin 阅读数 27
  • SCRUM敏捷开发视频教程

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

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

Olga Kouzina认为使用敏捷项目管理工具需要遵守三个原则:流程优先,工具次之;开发流程需可复用;正确做法需可复制。因为人们在选择或使用敏捷项目管理工具时,往往会忽略开发流程中的某些关键要素,所以他重点对第一个原则中提到的“流程”进行了介绍,以期帮助大家对开发流程有个更加完整的认识。 

首先,我们可尝试将现有开发流程分解为3个部分: 


 


上图中的框架几乎覆盖了开发流程中的三个关键要素:工作、人、计划,它们也都是在敏捷开发管理工具中要不断复用的要素。下面我们具体看看这三个要素都有哪些需要注意的地方。 

要素一:工作 

主要是“是什么”的问题,涉及了功能、用户故事、任务、Bug等。 

  1. 你正在使用哪个工作项?开发流程中工作如何分解?工作项需要多少个层级?下面,我们可以看一个例子,来对层级结构进行了解:想法(问题)→史诗(Epic)→产品→项目→功能→用户故事(User Story)→任务。
  2. 工作项之间需要什么依赖?除了层级分解外,我们是否需要在管理工具中复用其他依赖?
  3. 如何定义一个项目或工作项结束了?我们是否需要指定一个完成范围,或者将项目与时间捆绑起来?我们是否需要为工作项的设置多个最终状态(如已完成、已解决?)

要素二:人 

主要是“是谁”(角色)的问题,涉及开发团队、产品负责人、项目主管、用户等。 

  1. 团队成员如何管理?团队功能是否有交叉?是功能团队、项目团队、部门还是压根就没有团队?
  2. 每个团队的开发流程是一样的吗?我们是否在必要时安排几支团队到“史诗”或“用户故事”层级中?
  3. 未在开发团队或项目中的“鸡”组角色是否也需要了解工作流程?如客户、经理?

要素三:计划 

时间问题,涉及发布、迭代。 

  1. 我们如何进行backlog管理?backlog项都来自哪里?我们应如何整理backlog?
  2. 项目/发布/迭代:我们是否有交叉项目(或交叉团队)的发布?是否有并行迭代或发布?我们是否将项目分解为多个阶段执行了呢(如UX、原型、功能设计)?
  3. 我们在使用哪个报告?这个非常重要。一定要检查工具是否具备了我们所需的全部报告?


可能上面没有举出所有需要注意的问题,但这里提供的3个关键要素(工作、人、计划)可以帮助我们在选择或使用敏捷开发管理工具时更加全面地把握开发流程,不致于只根据部分要素就做出选择。 

2016-07-31 12:06:38 oYangShanJin 阅读数 493
  • SCRUM敏捷开发视频教程

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

    10428 人正在学习 去看看 CSDN讲师
  • 第一条 每个人都应该明确自己的目标 ,现实生活中我发现很多人都容易发散思维去做一件事情结果做一件事情导致做好几件事情,最后这件事情并没有做好也导致时间大量的流失,正确的字做法是盯住一件事情做,看板工具就很好的把自己的任务明确起来.
  • 第二条 任何一个故事都可以分解 为小任务,完成每个小任务就是完成一个大任务,每个小任务的完成时间应该控制在两天到一天之内,如果不是,那就是分解有问题
  • 第三条 增强工具 的使用,很多人在想搭建工具学习使用工具时,觉得大量浪费的时间,而且并没有实际的功能开发出来,于是按着传统的方式去做,殊不知工具这种这种东西一旦搭建好使用起来为后面节省时间可是大大的。
  • 第四条 敏捷开发强调团队协作高效,每个成员之间所做的事情应该是透明 的,快速的迭代能看到效果,增强团队成员的成就感,使团队越来越强
  • 第五条 项目启动时不一定要全部考虑全才开始架构软件,一个好的软件架构应该兼容后续发展所提出的需求,快速的不断迭代.
  • 第六条 对于项目的验收应该是更看重质量 把控,而不是时间点把控。
2018-09-07 14:28:46 leangoo 阅读数 574
  • SCRUM敏捷开发视频教程

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

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

在敏捷开发的实践当中,通过可视化的任务看板来实现团队协同和透明化管理是必不可少的一个实践。通过可视化的任务看板我们可以达到如下几个目的:

  1. 可视化管理团队的目标; 
  2. 明确目标的优先级; 
  3. 明确目标分解后的任务项; 
  4. 可视化管理任务的进展状况。 

敏捷的任务看板通常每个迭代一个,看板的结构通常包括如下几个列:

  • Story — 这一列代表的是用户故事,用户故事是敏捷开发中的需求表达方式,每个用户故事代表了从产品的用户视角表达的一条用户需求。用户故事这一列放的是这个迭代需要完成的所有用户故事,这些故事加在一起就是这个迭代的目标。这些故事通常按照优先级从上到下排列。
  • Todo — 这一列代表的是待办任务项,用户故事会被分解为对应的技术任务,这些待办的技术任务放到 Todo 列。
  • Doing — 进行中的任务,放正在进行的任务。
  • Done — 完成的任务,放已经完成的任务和用户故事。

在任务看板上除了有4个列之外,我们还要为每个用户故事建立一个泳道,通过泳道来管理故事和任务的对应关系。

一个标准的任务看板看起来如下图所示:

除了物理看板,我们也还可以可以利用电子看板来实现,这样数据也得以保存。

国内对敏捷支持最好的电子看板就是Leangoo  那我们来看一下怎么用leangoo管理敏捷迭代任务以及任务协作

下图是使用 Leangoo 实现带泳道的敏捷开发迭代看板示例:

横向为泳道,体现用户故事和任务卡片的对应

 

添加成员一起协作!

 

 

 

 

2017-04-04 21:44:38 kenneth_h_liu 阅读数 3552
  • SCRUM敏捷开发视频教程

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

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

最近又一个项目用瀑布方式做砸了(由于本文会多次提到本项目,我们就叫她项目X吧)。项目X刚开始的时候,我们部门的敏捷转型还没有起步,所有项目依然用瀑布方式。这个项目我一开始就想采用敏捷,毕竟这才是我拿手的,和客户那边也沟通过,他们也不反对尝试。而且项目的自主开发部分是用Java写的,有一定的JUnit测试覆盖和持续集成(CI)基础。但是由于我一直没有想好这个项目可以如何拆分进而迭代,所以项目的敏捷转型一直被搁置,其实际开发过程依然是瀑布方式,也遭遇了所有瀑布方式会遇到的问题。


传统需求难以描述用户的真实想法,传统瀑布开发没有快速反馈机制


瀑布不行,向敏捷转型已经是共识,但是具体怎么做呢?通过对项目X的复盘以及对其他项目的思考,以下是我的一些心得。


把项目拆分成用户故事才是硬本领


我也算是个“老敏捷”,但像前面说的,在面对一个具体项目,不会把项目拆分成用户故事,就无法敏捷起来!真正的敏捷开发必须是基于用户故事的开发过程


所谓用户故事就是含有一定业务价值的端到端交付。瀑布开发是把项目按照不同生命周期阶段横向拆分的过程。而敏捷开发是把项目或产品或业务目标竖向拆分成若干可体验、可交付的用户故事的过程。一个用户故事,应该是用一两个月甚至几个星期或更短时间就能做出来的东西,我们可以通过它更早地获取用户反馈,从而确定产品的正确性。这也符合敏捷倡导的“小步推进,频繁验证”的原则,是降低项目风险最有效的方法。



瀑布和敏捷的不同拆分过程


只有基于用户故事开发才能快速交付和持续交付


正如前面所说,我们用一两个月甚至几个星期把第一个用户故事做出来并给用户体验和反馈,而不是大半年甚至一两年后在项目后期才把产品给用户体验,我们更早、更快地交付并获取反馈,而不断重复这样的过程,就是持续交付的过程。在整个过程中,我们都在交付业务价值,而不是战战兢兢地拿着一堆半成品面对那个死亡日期的逼近。


项目X最终呈现给用户的是不同类型的基金报表,其实每一类报表就是一个用户故事。如果我们一开始就以最重要的一类报表,作为首个用户故事进行开发,只需要两、三个月的时间,我们就可以把这个用户故事完成并交付给客户进行测试和反馈,有任何的反馈我们都可以及时进行修正。得到客户认可后,我们就可以如法完成其他报表。更重要的是,从第一个用户故事,也就是最早可测试产品获得的用户反馈将确保其他用户故事的开发也在正确的方向上。而在瀑布方式下,两个月后我们才刚刚收到需求文档,什么开发都没有开始。



尽早定义和交付最早可测试产品可及时获取用户反馈,确保产品正确


因此,定义好用户故事是实施敏捷的基础,没有这个基础,其他敏捷实践的实施其实只是局部改善,依然是战术上的改良,而不是战略上的改变,长远来看,收效有限并容易倒退。敏捷开发是一个有机体系,各种具体的方法论和实践需要打组合拳才能发挥出其应有的效力,基于用户故事开发是一切的基础:


1.    如果不是基于用户故事开发,简单地把项目的长周期拆分成短周期并不是真正的迭代,因为每个周期都没有可体验、可交付的东西,依然像瀑布一样在不断堆积半成品,这也不是真的Scrum

2.    如果不是基于用户故事开发,测试驱动开发(TDD)和行为驱动开发(BDD)很难开展,因为缺乏具体用户场景的描述,很难写出具体、简明的测试用例,因而很难累积足够的自动化测试提高系统的可改性,内部质量、重构、持续优化便无从谈起;

3.    如果不是基于用户故事开发,持续集成(CI)也意义不大,因为提交的代码并没有构成可交付的产品,其实并没有真的在集成。


既然用户故事是敏捷开发的重中之重,那么如何定义好用户故事呢?诚然,这是敏捷转型的难点。业界有关具体定义用户故事的说法并不多,这也是为什么用户故事一直被忽视,因为还没有标准答案,大家无从下手。《用户故事地图》是为数不多的较具体地阐述用户故事定义方法的书籍。所谓用户故事地图就是从左至右按时间顺序罗列用户行为(也就是流程的每一步),在每个用户行为下从上至下罗列相应的细节,包括所需要的开发点,构成一个二维的“地图”。基于这个地图,还可以对每个开发点的业务价值进行审视,找出最小可用产品(MVP并制定发布计划。但是直接从整个项目或产品入手编制用户故事地图其实非常困难。



《用户故事地图》是为数不多的较具体地阐述用户故事定义方法的书籍


具体用户场景+用户故事地图则是我认为比较可行的方法


所谓具体用户场景,就是设想一个用户在使用某个功能的具体过程。比如我们使用共享单车,具体的场景是用户找到一辆单车、用手机扫码和开锁、骑行、到达目标地、锁车、支付费用。这个场景的每一步,按照时间顺序从左到右罗列出来,然后再分解每一步所需要的系统或模块,在每个系统或模块下从上到下罗列所需要的细节,包括所需要开发点,便形成一个用户故事地图。如果这个场景依赖于其他场景,比如注册,那么就设想注册的场景及其用户故事地图。如果注册就是所有其他场景的前置条件,就优先开发它。



场景+地图是一对好基友


再举一个传统金融项目的例子。比如银行开户,其中一个典型场景就是具体某类客户通过某个渠道开某类账户的过程。在这个例子里,可以想象它会有很多个不同的场景,而每个场景都是一个交付。有了一个具体场景,我们就可以分析要实现这个场景,背后需要哪些系统来支撑,每个系统需要开发什么,形成一个用户故事地图。


当然,以开户为例,开发首选场景的过程会相对较长,因为软件从无到有有打地基的过程,业务实现也需要各个系统的统筹配合,但它并没有看起来那么困难和漫长,因为:


1.    由于一个具体场景相对于整个项目要简单得多,相比传统方式下各个系统各顾各围绕所有功能进行开发,开发内容相对简单很多,集成的难度也相对低;

2.    首选场景的开发其实为其他开户场景打下了大量基础,其他场景的开发会相对快和容易很多,交付会加速;

3.    可以采用微服务架构、云服务、容器和像SpringBoot这样的快速开发框架在技术上大大缩短了从搭地基到业务逻辑开发的前置时间。


项目X中,开发第一个用户故事确实会是开发周期最长的一个用户故事,但是由于它为其他用户故事打下了大量基础,它们的开发会大量重用第一个用户故事的代码,开发与交付会大大加快。


基于场景更易理解和测试


因为场景具体和相对简单明了,不像传统需求的功能描述那么抽象和割裂,它更容易解释、理解和测试,也是测试驱动开发(TDD)和行为驱动开发(BDD)的基础。


基于场景考虑用户体验


设想场景也是考虑用户体验的过程,前面提到的更早和频繁获取的用户反馈也包含用户体验。

用户体验并不是互联网产品的专有名词,在传统的业务开发中,用户体验同等重要,只是它一直在瀑布开发中被忽视。


在项目X后期,离原定交付日期只有一个月了,客户提出在测试过程中发现,由于一个请求需要在不同系统中处理,很难追踪,建议增加一个统一的请求ID作为识别。这时我们有两个选项:


1.    我们的目标是按照计划把原定的所有报表按时交付,因此这是新的需求或需求变更,不应该在这个时候考虑;

2.    我们的目标是实现业务价值,客户在测试中发现的这个问题在上线后必然会被无限放大,不解决这个问题,用户体验和可用性极差,我们应该优先解决这个问题。由于时间有限,我们要和客户沟通能否先集中精力测试某类报表,确保操作的用户体验和可用性,把一个月后的发布目标改为先上线这类报表,实现部分业务价值,其余报表在这次发布后再测试和上线。


前者是瀑布的思维,后者是敏捷的思维。而按照瀑布思维交付,就像我们新装修完一间会议室,电视机、视频会议主机、电话都有,每个设备单独都能通电开启,但是电视机不能连接视频会议主机进行视频会议,也不能连接电脑进行演示,电话也没有设置好不能进行通话,也就是所有设备对用户来说其实都是不可用的。这样的交付有何意义?这几个需求哪怕只有一个能被满足,都比现在这种情况要好。


其实每个项目的需求或产品的设计,都是由一个个具体的场景构成的


如果我们和客户能从一开始就以场景作为切入点,我们的眼里就不再是一个个孤立的功能,而是一个个有具体业务价值、可交付的用户故事,开发的过程便是这一个个业务价值的持续交付过程,这也是一个产品长期演进的过程,项目只是产品演进的一个个小插曲,软件开发中最不可控的因素——时间对于客户来说也变得不那么敏感。在此基础上,再结合其他敏捷方法论和实践,锦上添花。


总  


传统瀑布开发是半成品堆积而且缺乏快速反馈的过程,传统需求只考虑功能而不考虑场景和用户体验。敏捷开发是基于用户故事的业务价值的持续交付过程。把项目拆分成用户故事是实施敏捷的基础。具体用户场景+用户故事地图是定义好用户故事的一个具体方法。



关于作者


o       早期敏捷践行者

o       起步于极限编程

o       熟悉极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发


关注公众号


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