敏捷开发看板三大作用

2017-11-21 11:24:06 ETIpiero 阅读数 6639

敏捷开发的看板不仅仅只是看板?在敏捷开发中为什么要采用看板?如何设计好的看板?任务条是改进的关键?

 

在我的理解中,敏捷开发中最先需要实施的三项重要工作需求用户故事化,沟通站会制以及进度看板化,这三个如果实施好了,不管你是否在实施真正敏捷还是对当前项目管理方式的一种改进,都能在研发管理过程中取得很大的进展。

 

前面两篇文章讲了用户故事和站会,这章就重点讲述项目进度看板化,本人会结合实际项目操作过程及对看板演进的过程进行讲解。

 

 

什么是看板?看板不仅仅是看板?

 

看板一词来自日本(kanban),源于精益生产实践(丰田生产),敏捷开发将其背后的可视化管理理念借鉴过来。看板使得项目管理最大的可视化,但是看板更可以将研发的过程进行管理,记录下用户故事研发过程中的细节和历程。

 

敏捷开发为什么要采用看板?

看板可以让研发过程最大限度的可视化,同时解决团队沟通障碍(实践中发现也可以作为和上级沟通项目进展的重要信息)的主要方法之一。通过看板,项目团队可以清楚了解已经完成的情况,正在做的以及后续将有可能需要做的用户故事。

看板可以作为敏捷团队每天站会的讨论的核心,及时变更看板各个用户故事的状态,通过看板,敏捷团队可以清楚的了解其它成员的工作状况及和自己相关工作的进展。

在状态墙上,除了用户故事、 bug之外,还会有一些诸如重构、搭建测试环境这样的不直接产生业务价值的任务,这三类任务用不同颜色的卡片,放到状态墙上统一管理。

敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?

                                                        1.实际项目看板

         看板状态呈现可以很简单,也可以很复杂,这都基于实际项目的需要,我结合我们在实践敏捷研发过程中,对看板的几次改进进行分享。在介绍之前需要对用户故事的“完成”状态下个定义, 用户故事的“完成”是指经过测试并可潜在发布给用户使用的状态

 

 

第一阶段:简单的反映用户故事目前处于的研发状态

        

敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?

                                               2 简单的讲用户故事的任务上墙

         刚开始实施敏捷的时候才用最简单的看板,如上图2所示,只是简单的将用户故事的研发上看板,基于此看板我们能清楚的指导目前用户故事处于的状态。但是这种简单的看板存在一些明显的问题,如研发人员和测试人员的沟通状态无法在看板上进行体现。

         所以在第一阶段我们又进行修改,增加研发和测试的衔接,如下图3所示

         敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?


3 细化“正在做”的状态

         在改进后,我们“正在做”阶段进行细分为开发中,待测试机测试验证,

         这样的看板流程可以有以下一些好处

1.       通过这个改进流程就可以通过看板呈现研发完成到测试阶段,从测试阶段到完成阶段的展示。

2.       通过看板上用户故事数量的状况,可以预测目前研发资源和测试资源配比是否合理?根据状况可以及时调整人员。

 

第二阶段,通过泳道方式,让实现用户故事团队成员间的协作得到反映

         我们开展的项目由于是端到端的系统,所以往往一个用户故事的实现会涉及多个成员的共同参与,所以一个用户故事的完成依赖于多个人员负责的Task完成。所以针对这种情况我们进化了图4的方式,

 

敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?

                                     3 采用泳道方式进行管理

         具有泳道特性的看板,在移动状态时需要参照以下流程

1.       当一个用户从“将要做”移到“用户故事”列时,需要将用户故事涉及的多方成员的工作进行任务拆分,拆分成一个个的任务。

2.       成员针对任务进行工作,当所有成员的任务完成后,将完成的用户移到测试验证列中。

3.       如果测试发现问题,则将相关的bug报给对应任务的人。

 

泳道方式的看板具有以下一些优点

1.       在多个人协助的情况下,每个人可以独立完成分配的Task,相互的影响和制约可以降低到最小。

2.       每个人完成的Task可以作为用户故事的阶段成果,可以尽早的引入测试进行功能测试。

3.       可以非常清楚的了解整个用户故事的进展情况,了解用户故事处于的障碍。

但泳道方式也存在以下不足之处

1.       由于用户故事被拆分成分工明确的Task了,所以这个用户故事内部进入了阶段提交的过程。

2.       由于大家被拆分到了Task,所以需要指定特定的人来负责整个用户故事,并需要在内部协调项目之间的工作

3.       用户故事的工时预计又被模块拆分,在长期实践中,导致工时的预计又进入负责任务的人进行预估的模式。

 

第三阶段,通合理设计任务条,实现故事,进度,工时和各类衔接工作

         在实践了一段泳道模式之后,我们重新思考了,如何让各类工作更好的衔接。最终在任务条上进行改动是最合适的。所以我们根据实践过程中发现的问题,形成了如下的任务条。

         敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?


                                                        图四 全面体现工作的任务条

此看板的任务条主要体现几大方面

1.       用户故事的描述,这个作为任务条核心部分,通过模块和ID和需求系统进行对应

2.       研发团队先对用户故事进行整体工时预估,得出这个用户故事团队的工作时间。

3.       涉及这个用户故事的所有人员都列在用户故事的下方,并且通过每天对当前用户故事的总工作量的预估,以及填写昨天的实际开发所耗工时

4.       用户故事指定相关责任人及依赖关系,可以明确的找到相关人员进行协调和解决

5.       通过bug list列出发现的问题,开发人员可以及时修改

 

采用了这种任务条后,就取消了泳道的模式,而是采用需求,UI设计,开发,单元测试,待测试,测试中,完成几个状态来完成。在我们项目中UI设计进行独立管理,是因为在整个UI设计是我们的瓶颈所在,需要及时查看UI任务堆积状况,及时调整UI的工作优先级状态,所以针对UI我们会独立出任务。

 

敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?

                                              5完整看板状况

 

在做好看板工作时需要注意以下几点

1.       找到一种好的材料来制作任务条,以确保任务条容易被移动,不易掉落并且容易被收藏。一旦这个环节没有做好,很可能会导致看板维护成本加大,甚至后期不维护看板。

我们在这个过程中尝试了很多,如中便签条+小便签条, 大便签条, 纸板+橡皮泥等等,最终结合我们的看板是基于玻璃的,最后选择了打印纸+透明胶的方式,移动很方便,而且不容易掉。

 

2.       及时更新任务条中的各类状态,任务条不仅仅只在看板上移动,更重要的是要记录下研发的过程,这样很容易制作燃尽图,工时消耗图等供全局使用的报表。我们的做法是在站会钱5分钟,大家先更新状态,PO及时统计各类数据。

2016-10-18 21:09:46 rdhj5566 阅读数 2277

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

2012-03-05 20:15:53 cheny_com 阅读数 18301

这是敏捷开发日常跟进系列的第三篇。 (栏目目录

故事板和看板其实不是一个东西,前者是最初的敏捷开发里边的东西,受到了后者的启发产生的;而后者是制造业的东西,具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西,可以认为大致相同。

故事板

简单说,故事板是展示迭代中的用户故事和任务的方法,在《硝烟中的Scrum和XP》的封面上就印着一个典型的故事板:

一般故事板分为三列:

To Do还没做的, Doing正在做的, Done做完的(有各种各样的中英文写法,大同小异)

有些团队的分工比较多,会出现一些中间状态,比如“还没做的/正在开发的/等待测试的/正在测试的/等待评审的”是一种典型的开发与测试分离的故事板。

故事板的用法

要解决的问题

故事板可以帮助解决一些燃尽图解决不了的问题(见上篇):

1. 有哪些故事正在做,还没有做,已经开工了但没完成……?故事板的三列正好解决问题。

2. 最后剩下了哪些故事没完成?最左边剩下的就是。

3. 有没有人不是一个一个完成故事,而是同时开工了很多故事?(这个是最后很多故事都开工了但都差一点完成不了的主要原因)这个复杂一些,下面讲。

同时开工很多故事,很容易造成思绪散乱、最后全部完不成的情况,确切说瀑布模型就是同时开工所有故事的典范。

为了防止这一点,如果是手工做的故事板,,那么注意中间一个“正在做的”列一点要窄一些,这样当里边的故事挤不下的时候,就是一个危险的很多故事都在开工的信号。

还有一种做法,是每个人只准放一个故事在中间,做完一个,才能再做一个。这个严格坚持有难度,因为经常遇到被卡住的情况,但是作为一种思路和精神应该尽量坚持。

4. 如果有跟进人,谁负责跟进哪个?可以在卡片上写上当前负责人、跟进人的名字。

通常的做法有很多种,比如每个人用自己颜色的即时贴,可以比较容易地看出每个人有多少个故事,分别处于什么状态。不过,这样就需要在“尚未开始的”里边提前分配人员了,不太利于后期的互动和互相关注;当然还可以在开始的时候重新用有颜色的即时贴重新抄一个,看大家的习惯了。

介质

尽管有很多故事板/看板工具,使用纸质方法仍然是一个很好的选择,原因就是作为“迭代中的任务”这种东西,其生存期很短,基本上2个月后价值为0,人们也就用纸片来对付了。

不过如果想在未来做几件事情,那么及早采用电子故事板/看板还是有必要的,这些事情包括:

1. 希望统计和分析哪些故事容易完不成、每个月的完成情况等

2. 大型团队,分布式团队

3. 希望留下历史数据作为以后估算的参考值和参考故事

下面这个是免费工具火星人中的故事板,做了两个案例来说明一下情况。

上面这个图是不好的情况,开发中的故事一大堆,没几个完成的,很容易造成最后所有故事都差一点。

下面这个要好的多,每个人只开工了1个(每种底色是一个人,案例中只有cheny和yock两个人),剩下的要末完全做完了,要么一点没做,即使到期末不能全部完成,也不会把太多时间卡在半截的故事上。

2012-03-07补充:

昨天下午仔细调整了美术效果,现在的故事板外观如下:

2017-04-20 08:25:40 huver2007 阅读数 2236

物理看板还是电子看板?

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

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

物理看板的优势:

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

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

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

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

物理看板的劣势:

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

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

电子看板的优势:

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

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

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

电子看板劣势:

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

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

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

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

2018-03-15 11:53:50 eleanoryss 阅读数 1961

转自:http://blog.csdn.net/lifuxiangcaohui/article/details/48342315

        敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!

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

  • 对于项目经理而言,最担心的就是项目进度不可控,不知道每位开发人员具体的工作进度,有了 Kanban 一切都是那么地清晰。
  • 对于开发经理而言,最担心的就是资源分配不合理,忙的人忙死,闲的人闲死,有了 Kanban 一切都是那么地自然。
  • 对于开发人员而言,最担心的就是绩效考核不公平,“凭什么我做的比他多,拿的工资却比他少?不公平啊!”有了 Kanban 一切都是那么地公平。

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

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


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

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


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

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

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


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


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


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


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


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


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


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


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


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


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

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