2019-10-26 18:04:50 ZYD45 阅读数 3148
  • CSDN在线培训:如何借助JIRA玩转敏捷电子看板

    JIRA作为项目与事务跟踪工具被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA的功能十分丰富。但是,由于JIRA配置十分灵活,在国内中文文档偏少,又缺乏优秀项目实践的分享,使得许多人虽然使用了JIRA,但是效果不佳。

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

整个敏捷开发里,最核心的就是看板机制。所谓的看板机制,就是将团队内的各个角色成员,安排在类似一条生产线上,各司其职,通力合作。

看板一词来源于,日本的丰田制造。最早为了解决,生产机器之间的协作生产问题,发明了“kanban”:B机器在空闲时,发出一张“kanban”卡,A机器接收到此卡就进行推送任务。

 整个看板的原型,有两个重要的点:1.To Do 起始点 2.Done 终点。在两点之间夹杂着任务的生成过程。

To Do

可以称为待办清单,但在敏捷开发里,一般称之为 积压板。注意,这里的To Do 里的内容,基本上是已经确定要处理的事,和需求清单有一定区别。

需求,往往是使用级别的事务。而且很多需求需要经过分析后,转换为若干待办事项。比如:“想要一辆自动驾驶的车”,这是一个需求,但是经过分析,可能会拆分为,“自动驾驶系统实现”,“车架生产”这两项工作项。而且,整个敏捷团队开发就是为了快速小步迭代,有时一个需求拆分出的多个工作项,为了实现快速迭代,不一定会将这些工作项统一放到一个迭代中。

积压板区域,最大的作用就是告诉团队成员,“我们还有多少工作没做”。

Done

这是个事务完结区,主要是开发完成的工作项(待办清单内容进入实际开发中,就称为工作项),基本上都是已上线的工作项。

之所以有这个区域,一是因为敏捷开发时,有些功能是灰度上线——有可能带着不经意察觉的问题,万一上线的出了大问题,可以调度工作项。另一原因就是,能够告知整个团队,此次迭代完成了哪些工作项,能够在后期团队项目总结时,有根可寻。

Doing

在起止点之间的部分,就是生成过程了,也就是开发过程。

可以用泳道来标识各个状态。而泳道是由团队角色决定的,常规开发团队中有 产品、开发以及测试。那中间的状态泳道往往是由这三类角色所需要的状态构成。

有了看板原型,我们可以看到各个整个团队成员的工作,能够了解每个人工作量,大致预览项目进度。

但是撑起整个看板的,不是看板本身,而是工作项。

如果说,看板是整个敏捷开发的核心,核心的核心就是工作项。工作项是大家实际的工作指导,以及实际开发过程的数据载体。从一开始界定要实现的目标,就记录在工作项上,再到中间的开发过程都应反馈在工作项本身,以及后面所暴露的开发缺陷,一个工作项都可以承载。

既然看板是工作项的展示容器,工作项的状态就等于看板的泳道。一个工作项在正常进行中,是从头跑到尾,但是难免有些工作项因为种种原因被关闭了,所以此时会有一个回收站来收集这些工作项。

这些泳道中,最核心的就是三条 产品(设计分析)、开发、测试。

 

表设计部分

看板只是个容器,看板所承载的工作项才是具体的业务,虽然说工作项可以存在各个泳道,但是从数据存储上,它其实就是一张表,通过不同的字段来区分,例如,工作项的时间 虽然有九个日期,因为整体业务表现都是依序进行的,所以除了两个完结时间点,其他的从新建(积压板状态)直到测试完成 采用的是 ADate、BDate...GDate,关闭采用的是ClDate/发布则是用RelDate。

而对于工时,这张表就是工作项表的细表,因为一个工作项可能产生多个工时,也就会产生多行工时数据。

To be Continued

当然,以上所述这些,都是一些指导性原则,任何东西都有个性化的一面,就像加勒比海盗里说的那样

法典只不过是一些指导,它并不是必须遵守的规定

2019-04-24 14:27:29 guowanwanwan 阅读数 147
  • CSDN在线培训:如何借助JIRA玩转敏捷电子看板

    JIRA作为项目与事务跟踪工具被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA的功能十分丰富。但是,由于JIRA配置十分灵活,在国内中文文档偏少,又缺乏优秀项目实践的分享,使得许多人虽然使用了JIRA,但是效果不佳。

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

下面这个看板展示了在Leangoo看板中可视化的管理产品Backlog

列表,需求卡片,标签

https://www.leangoo.com/kanban/board/go/2808232#

 

 

 

 

 

 

 

 

 

 

 

 

2016-06-23 15:41:40 ups216 阅读数 2681
  • CSDN在线培训:如何借助JIRA玩转敏捷电子看板

    JIRA作为项目与事务跟踪工具被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA的功能十分丰富。但是,由于JIRA配置十分灵活,在国内中文文档偏少,又缺乏优秀项目实践的分享,使得许多人虽然使用了JIRA,但是效果不佳。

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

看板在现代应用开发过程中使用非常广泛,不管是使用传统的瀑布式开发还是敏捷开发,都可以使用看板管理。因为看板拥有简单的管理方法,直观的显示方式,所以很多软件开发团队选择使用看板进行软件开发管理。本文不在对看板管理理论进行过多的赘述了,只是在这里介绍一下如何使用TFS的看板功能。
最新版本的TFS提供了功能强大的电子看板(最新发布的TFS 2015 Update 2.1中,也包含了对看板功能的提升),并且能对看板的显示进行大量定制,而且还加入了泳道的功能。开发团队可以根据自己的需求来定制属于自己团队的看板!!!

TFS看板的创建

TFS默认提供3种团队项目创建模板,Scrum, Agile及CMMI。项目创建后在菜单工作下的产品积压工作页面点击就可使用看板功能。 以前这个功能是被命名为看板的,不过在TFS 2013以后就变成板了。
1

这里简单介绍下为什么默认看板展示4列?每列的列名是怎么来的?首先TFS是采用工作项的形式存储各种信息的,比如:需求、任务、Bug等等。 这些工作项就是一个个的表单,包含了很多的字段,这些字段中有一个字段叫做:状态, 如果你是使用默认的Scrum模板创建的项目,那么产品积压工作项(即需求或者用户故事)默认有4个状态,分别是:New(新建)、Approved(已批准)、Commited(已提交)以及Done(完成)。 想必你已经看出来了,看板中的每列的列名默认就是产品积压工作项的状态名称,当我们拖动卡片在各个列之间切换的时候,工作项的状态也会随之改变,默认看板显示可能远远不能满足我们的需求,那么下面让我们来看看如何使用TFS看板吧。目前TFS工作项的状态只能通过修改工作项模板然后使用命令行或者TFS Power tools提交到TFS服务器进行修改。

TFS看板功能介绍

如果你的办公室有一个70英寸的触摸屏,你就可以把你们以前使用的物理白板拖走了。 你只需要在大屏幕上打开看板,并且选择全屏模式,一个和物理板具有相同展示效果的电子版就出现啦!
2

首先把看板的列名改一下,变成团队约定俗成使用的一些用语。单击列名就可以快速修改啦!
3

TFS默认根据产品积压工作项的状态在看版上创建了4个列。团队可以根据自身需求创建看板列,下面我创建新列已选定用来展示出当前迭代或当前版本需要开发的需求
6

  • WIP (Work In Process)限制: 当前状态下的产品积压工作项数量上限。每个看板列这个数值都可能不同,并且代表了不同的含义。比如在待开发列WIP限制需要根据团队开发人员数量来决定。当超过限制数的产品积压工作项被放入当前列时意味着你的团队成员在同时展开多个需求的开发,这对团队的影响就是在固定时间段内能提供给测试人员进行测试的的需求会变少,测试人员的效率会下降。
  • 状态映射:是指当你把看板中的卡片拖到这个列时,被拖动的卡片所代表的工作项状态应该被修改为什么。
  • 每个列中的“正在进行”和“已完成”: 可以通过勾选此项在每个状态列中进行细化跟踪。比如在开发列种哪些是正在开发,哪些是已经开发完成了。
  • 已完成的定义:通过编写Markdown脚本展示此列的说明信息

现在让我们来添加一些PBI和Bug作为实验数据吧。
5

现在卡片默认只显示有值的显示字段,我们可以配置在卡片中显示的字段,并且把这些字段都显示出来,不管这些字段是否有值。所有显示在卡片中的字段都能被编辑。
7

  • 核心字段:卡片默认包含字段,可以通过勾选框控制核心字段是否显示在卡片中
  • 附加字段:最多可以添加额外10字段显示在卡片上,自定义字段也可以被添加到卡片上
  • 显示空字段: 通过勾选框控制空字段是否显示在卡片上

如果开发的系统包含前台应用和后台管理,想要将分属不同的卡片区分开来显示,应该怎么做? TFS提供了泳道的功能,使用这个功能可以将看板中的卡片分组显示。
9

看板的优点就是能让团队成员一目了然地看到团队的整体情况。默认设置下对于每个成员的工作状态及工作进度的显示效果很弱。在TFS中可以通过配置显示样式的方式来加强显示效果。比如卡片的背景色,字体样式,并且可以通过条件来匹配卡片的显示规则。
10
11
在上图中 黑色背景的是没有评估工作量的,白色背景是没有指派的,每个成员认领的PBI都用不同的颜色区分,因此我们能在上图上直观的看到团队当前的迭代的研发状态及各成员的工作状态。

同样除了卡片的背景颜色可以定制,工作项的标签颜色也可以定制。
13

本文介绍了TFS看板功能,下篇文章将给大家详细讲解如何使用TFS看板完成一个Scrum迭代。


 

请关注微信公众号 【devopshub】,获取更多关于DevOps研发运维一体化的信息

qrcode_for_gh_b7c158df1fd1_430

2019-12-20 16:40:02 qq_42007293 阅读数 6
  • CSDN在线培训:如何借助JIRA玩转敏捷电子看板

    JIRA作为项目与事务跟踪工具被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA的功能十分丰富。但是,由于JIRA配置十分灵活,在国内中文文档偏少,又缺乏优秀项目实践的分享,使得许多人虽然使用了JIRA,但是效果不佳。

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

可视化实时协作看板

Leangoo支持灵活的自定义看板结构,创建列表即可轻松定义工作流程,创建泳道可以对任务进行分组对应,拖动任务以体现工作进展。实时同步看板信息,让团队工作情况一目了然,让团队成员即时协作,效率倍增。

https://www.leangoo.com

 

 

2016-10-18 21:09:46 rdhj5566 阅读数 2235
  • CSDN在线培训:如何借助JIRA玩转敏捷电子看板

    JIRA作为项目与事务跟踪工具被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA的功能十分丰富。但是,由于JIRA配置十分灵活,在国内中文文档偏少,又缺乏优秀项目实践的分享,使得许多人虽然使用了JIRA,但是效果不佳。

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

今天想与大家分享一款敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!

我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效考核更加公平!

  • 对于项目经理而言,最担心的就是项目进度不可控,不知道每位开发人员具体的工作进度,有了 Kanban 一切都是那么地清晰。

  • 对于开发经理而言,最担心的就是资源分配不合理,忙的人忙死,闲的人闲死,有了 Kanban 一切都是那么地自然。

  • 对于开发人员而言,最担心的就是绩效考核不公平,“凭什么我做的比他多,拿的工资却比他少?不公平啊!”有了 Kanban 一切都是那么地公平。

可见,项目经理、开发经理、开发人员拥有了 Kanban,也就拥有了和谐与快乐!


那么 Kanban 到底是什么呢?我们先来看看这张表格吧:

image

下面我们来理解一下这个表格吧!

  • 这个表格有 5 列:Backlog(原始需求)、Selected(被选中的需求)、Develop(开发阶段)、Deploy(部署阶段)、Live(上线阶段)

  • 其中 Develop 阶段包括 2 个子阶段:Ongoing(进行中)、Done(已完成)

  • 包括 3 中角色:产品经理(红色小人)、开发人员(蓝色小人)、部署人员(绿色小人),其实还有项目经理,只是他/她贯穿于始终,所有就没有画出来了。

在 Backlog 中放置了许多小卡片,它们在 Kanban 中被称为 WIP(Work In Process,在制品)。对于产品经理而言,WIP 是需求,而对于开发人员与部署人员而言,WIP 却是任务。

实际这些 WIP 卡片上都带有一些文字描述,包括:标题、描述、优先级等信息。

需要注意的是,Selected、Develop、Deploy 下方有一个数字,该数字表示此阶段中最多可以放置的 WIP 数量。例如,在 Selected 中最多只能放 2 个 WIP;在 Develop 中(包括它的子阶段)最多只能放置 2 个 WIP。这里的数字只是一个示例,具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”,减 1 表示大家需要协作,例如:4 人的团队,WIP 上限是 7。

也许有人会提出,为什么没有 Test 阶段?—— 这个可以有,这里只是一个示例而已,你不妨自行加上去。

对于多个项目而言,可以在这张表格中添加更多的泳道(行),每一行相当于一个项目,所有的项目进度清晰明了。

好!继续我们的 Kanban,有意思的事情即将发生!


image

产品经理挑选了 2 个 WIP 到 Selected 中,此时,由开发经理决定该任务的技术难度,并由项目经理将任务分配到指定的开发人员,也可将同一个任务分配给两个人,让他们去结对编程。

开发人员(架构师与程序员)可对 Selected 中的需求进行工作量评估,可采用投票的方式进行,最终给出一个合理的评估值,整个估算过程,项目经理无需参与,主要是开发人员共同完成。

开发经理可以对任务设置一个“分值”,这个分值可直接影响到后续的绩效考核,所以对大家来说,这个分值是公开可见的,谁做的多,谁做得少,一目了然。当然,开发人员也可以主动承担具有更具挑战的任务(为了锻炼自己,也为了多拿点钱),但任务分配的决定权始终在项目经理手中。


image

现在假设 A、B 两个任务已经分别被不同的开发人员处理了,那么这些任务就应该移动到 Ongoing 中,同时,产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。


image

有人已经把 A 做完了,那么 A 就可以移动到 Done 中了。随后,部署人员就可以开始干活了。


image

部署人员就可以将 A 从 Done 中移动到 Deploy 中,表示部署人员正在做这件事情。同时,做完了 A 任务的开发人员可以再做其它新任务,只需从 Selected 中移动到 Ongoing 中,移动这件事情不是开发人员随意操作的,而是有项目经理负责的。产品经理发现 Selected 中只有一个 D,就可以考虑放入一些新的需求了。


image

此时,部署人员遇到了问题,发现 A 部署的时候总是报错,跑不起来了。同时,其他开发人员也完成了 B 任务。


image

完成了 B 任务的开发人员本来是可以做新需求的,但项目经理发现 Develop 中只能放 2 个任务,所以肯定是后面的阶段出现了问题,导致整个流程受阻了。项目经理可以灵活调度人力资源,集中火力解决现在所遇到的问题。


image

所以项目经理不得不放弃新的任务,去让开发人员去帮助部署人员来解决问题。此时,其他的开发人员还在进行 C 任务。


image

部署的问题还没来得及解决,此时 C 任务也完成了,同时,产品经理也放入了新的 K 需求,确保 Selected 这个水池是装满水的。


image

整个部署问题看起来比较搞人,所有的开发人员全都上阵了,集中更多人的智慧,解决这个棘手的问题。此时,产品经理不能放入更多的需求,由于此时 Selected 已经满额了。其实,开发人员面对太多的需求时,往往都会倍感压力,身心憔悴。


image

看来这个部署问题,确实够折腾的,连产品经理都过来了凑热闹了。但他或许不懂技术,但多个人多个头脑吧,正所谓“当局者迷,旁观者清”,最终经过大家的努力,肯定会攻克这座碉堡!


image

几天之后,Kanban 流程依旧是稳定的,大家分工协作,人力资源合理利用。大家是一个团队,目标就是把项目做好,不会因为自己的事情做完了就闲置了。


我们不妨将这张表格贴到墙上去吧!让每个员工都可以看到,让过路的老板们也可以看到我们的辛苦努力,这确实是一种非常好的项目管理方法!

image

用看板做敏捷开发

阅读数 558

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