2019-08-11 18:25:38 lantian08251 阅读数 172
  • 敏捷开发实践

    本课程集中介绍敏捷开发的实践,包括: 如何编写用户故事,如何进行故事估算? 如何根据特定条件判断需求的优先级? 敏捷方法中最常用的看板方法如何使用?看板原理如何理解? DOD与SOS案例

    91 人正在学习 去看看 黄啟河

“看板方法”是一个制造业的术语,由David Anderson 引入到软件开发领域。David 在其的著作《看板方法》一书中这样描述看板方法与精益之间的关系:“看板方法带来了一套复杂的适应性系统,该系统的目的就是在一个组织中催生出精益的效果。”

1. 看板方法

正如David Anderson所说,看板方法本身并不是一种软件开发流程或者项目管理方法。使用看板方法之前,你必须已经具备某种流程或方法,而看板方法的作用就在于逐渐改变你已有的流程或方法。所以可以认为看板方法是敏捷团队用来改进流程的一个方法。事实上,我们也可以把看板方法看作和精益思想一样是一个消除浪费的方法,因为对于软件开发消除浪费就是流程改进的主要目的。从这点上,看板方法和Scrum有较大区别,因为Scrum主要提供的是过程管理框架,关注于需要做哪些工作,何时做以及谁来做等项目管理类问题。

看板方法为流程管理提供了最基本的工具就是看板,看板的作用在于把整个开发流程可视化。如图8-所示就是一张典型的看板(Kanban Board),看板上的栏目是:输入队列、分析(处理中)、分析(已完成)、可开发、开发(处理中)、开发(已完成)、可构建、测试和可发布。使用这个看板的团队的工作流程可能是这样的:每个特性都需要经过分析、开发、构建和测试这几个环节。所以,团队可能会从类似下图那样的一个看板开始,在各栏目中贴上贴纸来代表经过系统中的各个工作项。

我们知道Scrum中有任务板(Task Borad)的概念,看板与任务板表现形式非常相近,但有一个本质性的区别。看板中的每一个栏目中的工作量可以设限制,这点与管道理论有非常密切的关系,我们将在下一节中具体讨论。

1. 看板中的管道管理

我们先来看一个日常开发过程中的典型场景,一个迭代的开发过程由产品提出需求、需求分析、开发、测试、产品验收和发布等几个步骤组成,在某一个特定时期,下图是看板的一个快照。

如果某一段时间测试人员生病请假,显而易见,看板上在测试这一栏中很快就会堆积很多需要测试的开发任务(见下图)。现在我们有了团队工作流程的一个更加准确的可视化结果,也很容易就发现团队的瓶颈所在。团队中已经有人清楚问题的关键,接下去就是要做开发流程上的改进,为此我们引入一个重要概念,在制品。

在制品(Work In Progress,WIP)的意思就是当前某个环节中正在开发的任务,而限制在制品就是为这个开发任务数量设定一个上限。在制品是一个看板用语,但我们可以看到它与管道中的开发任务是一致的,而限制在制品就是要管理管道中的负载。管道不能长时间的超负荷运作,看板把工作流程可视化能够帮助团队清楚地看到这种超负荷的问题。在上图中,我们已经看到测试环节已经处于超负荷运转状态了,在这种情况下,马上开始该特性的开发工作就不合时宜了,因为开发完了之后它也不过是放在那里等着,因为没有多余的人手马上测试它。

当测试工作出现瓶颈,我们有很多选择。给某个环节的在制品设置一个上限意味着限制了可以进入该步骤的任务的数量。这样可以帮助限制团队的选项,从而让团队的选择变得更容易。针对例子中的这个测试环节,如果我们把测试在制品上限设为五(见下图),当第六个开发任务即将进入测试环境时,我们就会发现它已经超过了这个环节的在制品上限。通过在图8-中添加一栏“被测试推迟”的任务,就可以将这个问题充分暴露出来。同时,也就意味着我们需要停下来考虑一下如何解决测试资源不足的问题,解决的一种思路是从其他团队调用一个测试人员过来做短期支援,或者鼓励全民测试,或者其他任何有效的方法。从瓶颈被发现到被解决,整个过程可以在本文三张图的流转过程中得到可视化管理。

 

如果对文章感兴趣,可以关注我的微信公众号:程序员向架构师转型,或扫描下面的二维码。

我出版了《系统架构设计:程序员向架构师转型之路》、《向技术管理者转型:软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍,并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》,欢迎交流。

2015-06-12 16:53:14 leangoo_cooperation 阅读数 558
  • 敏捷开发实践

    本课程集中介绍敏捷开发的实践,包括: 如何编写用户故事,如何进行故事估算? 如何根据特定条件判断需求的优先级? 敏捷方法中最常用的看板方法如何使用?看板原理如何理解? DOD与SOS案例

    91 人正在学习 去看看 黄啟河

编者注:对于需要在不同地点、时间协同的团队,可以用电子看板,比如 Leangoo

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

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

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

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

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

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

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

leangoo

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

这个表格有 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,有意思的事情即将发生!

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

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

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

leangoo

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

leangoo

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

leangoo

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

leangoo

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

leangoo

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

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

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

leangoo

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

leangoo

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

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

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

leangoo

文章来源:http://my.oschina.net/huangyong/blog/196883

2018-11-30 15:06:09 weixin_42646080 阅读数 171
  • 敏捷开发实践

    本课程集中介绍敏捷开发的实践,包括: 如何编写用户故事,如何进行故事估算? 如何根据特定条件判断需求的优先级? 敏捷方法中最常用的看板方法如何使用?看板原理如何理解? DOD与SOS案例

    91 人正在学习 去看看 黄啟河

在找适合我们团队的协作工具的时候,我们也是费了好大一把劲~

一款好的看板协作工具在团队协作和项目管理中起着非常大的作用,但是我们要的不仅仅是看板,还有要满足企业管理者的需求,

要求是:

1. 看板式并支持Scrum敏捷开发

2.对人员的任务分配以及时间安排一目了然

3.因为一个sprint里会有不止一个需求,哪个需求对应哪些小的任务卡片,可以清晰分别

4.跟踪开发进度以及缺陷的管理,最好是可以链接devops

5.一个成员会存在多个项目的情况,想可以看到他在哪几个项目以及每个项目上的占比

6.在领导层面,可以更多的看到整个项目的一些进度,包括缺陷和需求以及成员的一些进展情况

7.好用性 易用性  这些肯定都是必须的,不希望团队在熟悉工具上多浪费时间

带着以上这些问题,我们寻找到了一款最适合的,当然中间也有试用过Kanboard,Wekan,trello,jira等等,心都累了!

Kanboard也非常的不错,值得推荐!

但是我们最终选了国内的一款叫 Leangoo(领歌),当然这是团队和领导共同决定的,我个人也比较喜欢Kanboard,虽然界面没有那么酷,但是功能很齐全,确实很不错!(虽然不能全部满足以上几点)

我们团队不是很大,20几个人,leangoo用起来居然毫无压力, 上手很快,很简单,基本上是一看就会用的那种。

我们用的是leangoo企业版,以上提的几点基本上都可以满足。费用是:99元/人/年

满足点:

1.官方宣传:leangoo的核心是看板,完美支持scrum敏捷开发!

2.Leangoo看板上是以拖拽的方式将成员拖拽至任务卡片上,也可以为每一张卡片添加截止日期

3.需求对应,在 leangoo中可以利用泳道实现

4.跟踪进度有燃尽图,项目进度条还有整个团队的速度都可以查看

5.leangoo也打通了devops。使用场景是,当你的用户故事要发布的时候,把它放在“完成列”就会自动触发Jenkins进行自动化构建和发布,具体可以参考他们的配置指南:https://www.leangoo.com/13461.html

6. 站在管理层的角度,也可以清晰的看到一个成员参与了几个项目以及在每个项目上的占比

7.在领导层面,可以更多的看到整个项目的一些进度,包括缺陷和需求以及成员的一些进展情况

8.好用性 易用性  这些肯定都是必须的,不希望团队在熟悉工具上多浪费时间

Leangoo的易用性更是不用多说,简洁又轻量,团队用起来上手也很快!

 

我的分享希望对你有帮助!

 

 

 

 

2018-11-07 18:16:07 leangoo 阅读数 1639
  • 敏捷开发实践

    本课程集中介绍敏捷开发的实践,包括: 如何编写用户故事,如何进行故事估算? 如何根据特定条件判断需求的优先级? 敏捷方法中最常用的看板方法如何使用?看板原理如何理解? DOD与SOS案例

    91 人正在学习 去看看 黄啟河

什么是Leangoo(领歌)

Leangoo(中文名:领歌)是一款基于看板的项目管理工具。

我们可以使用Leangoo管理项目需求、任务、或者是问题和文档,随时跟踪团队工作进展。

Leangoo看板工具也融入了人敏捷管理思想,专业的敏捷团队打造,完美支持Scrum敏捷开发和看板方法。

Leangoo的核心是看板,通过看板共享和实时同步团队工作。

团队工作体现为卡片,卡片上的内容可以是需求、任务、bug等等。

Leangoo看板上的主要元素包括列表和泳道,列表管理工作的不同阶段或状态,泳道实现任务的分组对应,从两个纬度让团队的工作高度可视化、一目了然。

Leangoo提供永久免费的在线版,在线企业版和私有部署企业版三个版本,供用户自由选择!

在Leangoo中,标签的使用可以有多种,下面我们来看几种吧!

一.   用标签给任务卡片分类

         1)先点击标签后面的笔,为标签命名。

            然后直接将标签拖拽至任务卡片上即可。

这是分类好的 看板示例:

也可批量为任务卡片添加标签-点击看板内的多选按钮

然后选择要添加同一标签的卡片,选好之后直接对右边的标签打勾即可

二.   用标签标注Bug的严重性以及紧急程度(两种管理bug的方式)

下图为看板示例

三.   用标签>>>

..............................没写完

 

 

个人写法  不喜勿喷

 

2017-04-20 08:25:40 huver2007 阅读数 1976
  • 敏捷开发实践

    本课程集中介绍敏捷开发的实践,包括: 如何编写用户故事,如何进行故事估算? 如何根据特定条件判断需求的优先级? 敏捷方法中最常用的看板方法如何使用?看板原理如何理解? DOD与SOS案例

    91 人正在学习 去看看 黄啟河

物理看板还是电子看板?

敏捷宣言有一句“个体和交互胜于流程和工具”。虽然敏捷项目的最终成败与看板本身是物理的还是电子的没有直接关系。这里只是讨论:如果你打算用看板,那么哪种看板更适合你?当然前提都是要有一面较大的墙。

首先分别对比物理看板与电子看板的优势和劣势。

物理看板的优势:

1.       物理看板墙有助于团队的互动和协作,而且置于团队工作区内,随时供所有走入工作区的人高度可见。同时也可防止有人坐着看会,防止每日站会变成每日坐会;而且大家要看着看板才能跟上步调,防止有看手机、刷微信等削弱互动性。

2.       物理看板便于对看板系统作变化,只需要马克笔重新设计或更改即可。物理看板可随便你怎么创新可视化,只有你想不到的,没有你做不到的。电子看板则很难做到。团队刚刚开始导入敏捷,导入看板,在没有充分实践的情况下,极有可能要对看板进行变动,如:细分流程,增加“编码完成”。在物理看板上画2分钟即可完成。

3.       启动快。只要团队统一意见,立刻就可以找一片“根据地”,花10分钟就可以布置好物理看板,立刻就可以把相关工作可视化。

4.       成本低。物理看板几乎不需要建设和维护成本,简单一点在某个墙上贴一些泳道条,买一些即时贴即可。100元能运行几个月!

物理看板的劣势:

1.       没有历史数据的沉淀,缺乏整体性。看板协助团队实施当前迭代,但是对于之前迭代的相关信息没有有效利用,使敏捷相关信息失去规模性、整体性。另一方面,质量管理人员可能因为缺少历史数据,而逐步失去客观质量分析评价。

2.       需要耗费额外的人力成本更新大量物理看板上的数据到工具里。凡是用了两套系统(物理看板和电子看板),就面临保证同步性的挑战。

电子看板的优势:

1.       团队跨区域,甚至大型项目团队跨越多个城市或多个国家,这时电子看板就自然显出优越性。

2.       如果大量项目数据存储在数据库里,比如backlog、bug等数据本来就有相关工具管理e.g. 禅道,这时如果有支持与已有工具集成的看板工具就便于数据的维护和更新,度量数据也比较容易生成。

3.       电子看板支持度量数据自动统计和更新;用物理看板做度量需要很多手工的工作,至少需要手工录入数据,这使得一些团队没有坚持度量统计,启动时新鲜,做了一段时间就放弃了。

电子看板劣势:

1.       找到一个适合自己团队的电子看板不容易,购买成本也很高,自己开发成本也不低,且要长期维护。

2.       显示器尤其是大屏幕的成本较高,项目团队特别多的时候,需要多个显示器,且只能固定在某个位置,不方便移动。

综合考虑,团队在刚刚接触敏捷时,尤其希望降低工具成本,建议使用物理看板;当团队对敏捷流程相对熟悉、团队内部相对稳定,且有较充裕的资金,建议导入电子看板,只有这样才能让敏捷习惯持续养成并传承。

有的企业采用了大型触摸电视屏配电子看板,集电子和物理看板的双重优势。有钱就是任性!

什么是看板方法?

阅读数 613

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