敏捷开发 看板作用_敏捷开发 看板的作用 - CSDN
  • 相对于项目管理,我更喜欢看板的主要原因之一就是,项目管理关注的是项目,而看板关注的是流程,是程序。   流程作为精益管理巨大的优势之一,翻译到如看板等工具上面就是,它强调的是打造并维护一个可以允许不同...

    项目 vs. 流程

     

    相对于项目管理,我更喜欢看板的主要原因之一就是,项目管理关注的是项目,而看板关注的是流程,是程序。

     

    流程作为精益管理巨大的优势之一,翻译到如看板等工具上面就是,它强调的是打造并维护一个可以允许不同的“包(Pakcage)”以相同的质量进行通过的流程。这里关注的改进之处永远都是在流程方面,所以在这个过程中所获得的经验和教训都必须是可以应用到整个流程上面,而不仅仅是当前正在通过该流程的某个特定的项目,某个特定的“包”上面。通过这种方式,你在持续改进方面所付出的努力将会在任何时候都能体现出效果。

     

    看板流程的三个重大组成部分:

    完成的定义(Definition of Done)

     

    "完成的定义“是每个阶段的目标。这是”内部客户(比如,下一个阶段)“希望前一阶段所交付的内容。这是你在你的看板流程中为每个阶段进行角色设计的一个方法,且,更重要的是,它保证了通过看板流程的所有“包”的质量。“完成的定义”为在项目的进展过程中大家究竟需要瞄准什么样的目标提供了指导方针。它定义了团队在看板流程的每个阶段中所要努力达成的目标,却又不对完成该目标的方法进行限制。

     

    对于打造一个伟大的产品,发现问题并正确的理解该问题是至关重要的。事实上,没有正确的对问题进行认识往往是一个产品所以失败的主要原因之一。所以,作为一个不断迭代循环和改进的过程,我们在每个项目中进行学习,对每个阶段的“完成的定义”进行改进。通过这种方式,每个“包”通过这个流程时所给我们带来的知识,都能应用到所有紧跟着的“包”上面来,以确保同样的错误不会出现两次 -- 这又是另外一个精益管理上非常重要的因数。

     

    流程的持续改进

     

    说起来天下第一,做起来有心无力!针对流程而非流通这个流程的“包”进行突破,这听上去是非常反直觉的,但是在精益管理上面,这对你的产品又是至关重要的。

     

    举个例子,在发布一个新功能的过程中,你发现大量的用户生成了大量的需要客服支持的凭证,抱怨说他们不知道如何运用这个新功能。那么因为一次用户教育的失败,这就有可能会影响到用户的参与度(engagement)。此时你的技术支持团队应该已经开始着手帮助这些客户解答他们的疑问,同时你的开发团队应该也在动手提供一个针对性的更新。但正重要的是,精益管理会迫使你去找出究竟哪个环节出了问题,然后迫使你对这个流程进行改进,这样才能避免同样的错误不会在其他地方(项目,功能,增强,“包”,等等)再次发生。比如,在内测环节?易用性测试环节?还是在早期的解决方案设计环节?

     

    持续改进是确保其他项目不会犯同样的错误的关键,所以请记得将其应用到你的流程上面去。

     

    流程

     

    流程,就是你打造你的产品或完成你的项目的方式。流程的设计很大程度表示了你的团队如何开发你的产品,同时它也反映了你的团队及你的公司所宣扬的价值取向。

     

    世上并没有一个统一的标准来告诉你该如何定义你的看板流程,但根据你的产品的需要,倒是有着不少来自其他地方的值得借鉴的优秀实践。同时,随着你的生意的成长和你的产品的日催成熟,你的看板流程也会相应的跟着改变。我们为我们的产品打造MVP时候所用到的看板流程,和现在我们在用的看板流程已经相去甚远。回首当年,我们那时对产品的的认知还相当有局限性,且我们当时是一个只有10个人的团队(相比我们现在,可以说是个小团队了),随着我们对产品的深入学习和认识,团队成员也随之达到了200多号人,所以我们面临的挑战也是不可同日而语的。

     

    你的流程进行设计和改进应该源于你此前的学习成果,但也需要正确的反映你的公司的价值取向。确保你对你的生意,你的雇员,以及公司的价值取向有正确的认识。通过以提升和加强你希望在你的团队和产品中看到的价值取向的方式来使用你的流程。这同时还会是一个传播你的企业文化的非常强大的工具。

     

    以上提到的这些好处只是看板所带来的众多好处的冰山一角。看板的使用以及精益管理的原则,对于产品开发以及团队的持续交付来说,都有着极高的价值。所以我们应该从今天开始尝试在你的产品打造过程中应用上看板流程,并且确保不断的在学习的过程中改进你的看板流程。

     

    同时欢迎大家将你的看板 精益管理的应用心得在评论中提出来,以便同行们进行讨论和学习,让我们一起进步。

    展开全文
  • 转自:http://blog.csdn.net/lifuxiangcaohui/article/details/48342315 敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!我们可以结合 Scrum 与 Kanban...

    转自: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 流程依旧是稳定的,大家分工协作,人力资源合理利用。大家是一个团队,目标就是把项目做好,不会因为自己的事情做完了就闲置了。

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


    展开全文
  • 敏捷开发看板不仅仅只是看板?在敏捷开发中为什么要采用看板?如何设计好的看板?任务条是改进的关键?   在我的理解中,敏捷开发中最先需要实施的三项重要工作需求用户故事化,沟通站会制以及进度看板化,这三...

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

     

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

     

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

     

     

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

     

    看板一词来自日本(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及时统计各类数据。

    展开全文
  • 在本课程结束时,您将准备好提高敏捷开发过程的效率,避免常见的看板陷阱,并为您的团队带来最佳工作。 以下是本 Chat 的内容目录: 介绍 精益和看板 精益思维 看板原则 核心练习 看板实践 ...

    在本 Chat 中,我们将通过 Trello(一种流行的免费看板工具)来探索精益思维、看板原则和看板过程本身。由于本课程以开发人员为重点,我们将从基本设置开始,并逐步改进我们的开发过程,期间将讨论各个原则。

    在本课程结束时,您将准备好提高敏捷开发过程的效率,避免常见的看板陷阱,并为您的团队带来最佳工作。

    以下是本 Chat 的内容目录:

    • 介绍
    • 精益和看板
      • 精益思维
      • 看板原则
      • 核心练习
    • 看板实践
      • 演示概述
      • 项目可视化
      • 限制正在进行的工作
      • 管理流程
    • 流程和陷阱
      • 处理流程政策
      • 改进和发展
      • 避免坏看板

    阅读全文: http://gitbook.cn/gitchat/activity/5d145f7aa8894643edfbe4ea

    您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ,阅读更多 GitChat 专享技术内容哦。

    FtooAtPSkEJwnW-9xkCLqSTRpBKX

    展开全文
  • 物理看板还是电子看板敏捷宣言有一句“个体和交互胜于流程和工具”。无可厚非,敏捷项目的最终成败与看板本身是物理的还是电子的没有直接关系。这里只是讨论:如果你打算用看板,那么哪种看板更适合你?当然前提...
  • 看板方法 看板(Kanban,来源于日语)最初是丰田汽车公司的大野耐一于20世纪50年代发明的,当时是从超级市场的运行机制中得到启示,将看板作为一种生产、运送指令的传递工具而被创造出来的。 经过60多年的发展和...
  • 1. 看板式并支持Scrum敏捷开发 2.对人员的任务分配以及时间安排一目了然 3.因为一个sprint里会有不止一个需求,哪个需求对应哪些小的任务卡片,可以清晰分别 4.跟踪开发进度以及缺陷的管理,最...
  • 整个敏捷开发里,最核心的就是看板机制。所谓的看板机制,就是将团队内的各个角色成员,安排在类似一条生产线上,各司其职,通力合作。 看板一词来源于,日本的丰田制造。最早为了解决,生产机器之间的协作生产问题...
  • (栏目目录)故事板和看板其实不是一个东西,前者是最初的敏捷开发里边的东西,受到了后者的启发产生的;而后者是制造业的东西,具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西,可以认为大致...
  • 今天想与大家分享一款敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?! 我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效...
  • 今天我们来介绍一下敏捷开发中常用的第二个实践,看板方法。其实,看板方法实际上可以说是精益产品开发的重要实践,与其他敏捷方法相比,它具有更强的可实施性,提升端到端价值交付能力,更好支持系统的改进。而且它...
  • –如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后,如果估计发生了变化,任务会根据变化在任务墙上做相应的调整。 通常的任务板是下面这个样子: 任务墙被...
  • 只要是在IT互联网行业工作的人肯定对 Scrum敏捷开发 都多多少少有一些了解。工欲善其事,必先利其器,那我给大家介绍一款敏捷开发项目管理工具-Leangoo。 它是由国内最早推广敏捷 也是最权威的 Scrum中文网 研发...
  • Leangoo非常适用于Scrum和敏捷开发,我们可以用它轻松的创建Sprint Backlog,添加用户故事卡或任务卡,为用户故事添加估算的故事点,或通过拖拽来移动卡片到不同的状态列表。您还可以通过把团队成员拖动到一个任务卡...
  • 看板方法”是一个制造业的术语,由David Anderson 引入到软件开发领域。David 在其的著作《看板方法》一书中这样描述看板方法与精益之间的关系:“看板方法带来了一套复杂的适应性系统,该系统的目的就是在一个...
  • 现在市面上的任务管理工具太多了,不可能一个一个的试用,简单的说几个必备特性,或者可以帮助缩小范围。 目标: 在尽量简单、简洁的情况之下提高我们团队的工作效率。 选择一个合适的工具并匹配我们的工作模式会...
  • 看板在现代应用开发过程中使用非常广泛,不管是使用传统的瀑布式开发还是敏捷开发,都可以使用看板管理。因为看板拥有简单的管理方法,直观的显示方式,所以很多软件开发团队选择使用看板进行软件开发管理。本文不在...
  • scrum敏捷开发框架 由于Scrum和看板都属于敏捷框架的保护范围,因此许多人将其混淆或认为它们是同一回事。 但是有区别。 一方面,scrum更特定于软件开发团队,而看板则被许多类型的团队所使用,并专注于提供敏捷团队...
  • Leangoo看板工具也融入了人敏捷管理思想,专业的敏捷团队打造,完美支持Scrum敏捷开发看板方法。 Leangoo的核心是看板,通过看板共享和实时同步团队工作。 团队工作体现为卡片,卡片上的内容可以是...
1 2 3 4 5 ... 20
收藏数 5,539
精华内容 2,215
关键字:

敏捷开发 看板作用