敏捷开发看板应该具备什么_敏捷开发 看板 - CSDN
精华内容
参与话题
  • 使用看板进行敏捷开发

    千次阅读 2016-10-18 21:09:47
    今天想与大家分享一款敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?! 我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效...

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

    展开全文
  • 敏捷其实很简单(4)--初识看板

    万次阅读 2016-11-04 23:01:23
    今天我们来介绍一下敏捷开发中常用的第二个实践,看板方法。其实,看板方法实际上可以说是精益产品开发的重要实践,与其他敏捷方法相比,它具有更强的可实施性,提升端到端价值交付能力,更好支持系统的改进。而且它...
    今天我们来介绍一下敏捷开发中常用的第二个实践,看板方法。其实,看板方法实际上可以说是精益产品开发的重要实践,与其他敏捷方法相比,它具有更强的可实施性,提升端到端价值交付能力,更好支持系统的改进。而且它也可以和很多其他敏捷方法无缝连结。

    看板方法的起源
    中文意思带来误解
    看板方法的英文为kanban,和中文的看板正好音同,这个当然不是巧合了,看板起源于日本,它的日文注音也正好是'kanban',在日文中它也可以写作汉字“看板”,当然也可以写成日本假名。但是这两个意思完全不同,写作看板时接近“可视化的板”,而日文假名则为“信号卡”。
    软件开发中的看板应该更接近于信号卡,但是在国内,大家往往因名生义,把它看做可视化的板,所以往往忽略了其本质的意义,这也是看板系统在国内被普遍误解的一个重要原因。但是在国外,英语有对应的可视化的板---“kanban board”。所以我们称其为看板墙。
    信号卡的概念来自于精益制造,最早出现于丰田生产系统(TPS),我们先可以从制造中的看板学起,
    从而帮助我们理解本质,消除误解。

    我们可以从上图中看到,丰田生产过程有多个工序构成,其中有加工站,前工程,后工程。
    我们可以看到当后工程取件的时候,这个时候,前工程会有产品被拿走,导致空缺,然后加工站会根据前工程的产品空缺来进行生产,填补空缺。
    看板时丰田生产方式的两个核心工具之一,看板向上传递的信息流拉大乡下的物流,一直到交付客户,这样就导致了实际上最终拉动生产的是客户的需求。而产品开发则是借鉴的这个思路。
    这里我们就要讲一下什么是拉式开发和推式开发了。
    传统的推式开发,各个工序按照预先计划生产,将完成的组件推向下游,最求每个工序的产能最大。
    而拉式开发则是通过用户需求,从下游向上游传递信息,达到控制。
    那么拉动生产方式到底有哪些优点呢:
    1。控制库存:下游需要时上游才开始生产,有效控制库存
    2。加速流动:进入生产环节的物料和半成品,很快就被拉入下一环节,实现了保证安全库存的前提下物料最快流动,提高工程的运转效率。
    3。灵活响应:用户需求变化通过看板行程的信息流快速传递至各个环节,系统能够做出快的响应。
    4。促进改善:库存降低和流动加速,能够使生产问题快速暴露,比如生产环节的质量问题很快就会被下个环境发现。
    但是产品开发和生产制造有本质的区别,所以我们不能照搬看板方法,产品生产要有自己的看板方法。
    David J. Anderson 最早在软件开发中借用了看板实践,并且形成为完整的方法体系。我们下面按照看板方法5个核心实践来介绍。

    建立看板系统的3个实践:
    1)可视化价值流:产品开发中的价值流是不可见的,这样也就很难管理和优化。为此,看板方法首先要让工作和工作流可视化。
    从上图中我们可以看到可视化价值流的三个特点:
    • 首先可视的是用户价值,产品开发的目标也是交付用户价值,工作也应该从用户的角度来组织,图片中每个蓝色的卡片代表一个用户的价值,典型的是一个可以验证,可以交付的用户需求。
    • 接下来是用户价值端到端的流动过程,这里的端到端是指价值提出到价值交付的整个过程。
    • 最后所有问题和瓶颈也都要可视化,问题指的是阻碍价值流动的因素,包括需求不明确,技术问题,外部依赖等。而瓶颈包括价值积压等。

    2) 显示化流程规则

    价值流动过程也是团队协作交付价值的过程。为了更好的协作,团队还需要明确价值流转的规则。如下图所示,流转规则是价值从看板上一列到下一列必须达到的目标。
    显示化指的是明确并达成共识,这点和可视化不能混为一谈。
    所谓显示化流程规则只明确价值流转和团队协作的规则并达成共识。这个也是团队改进的基线,团队可以进行修正。
    3)控制在制品

    在制品(WIP)指的是在某一环节内所有的工作--包括进行和等待的。上图中红色数字就是在制品。
    环节内在制品数目小于这个数目的,可以从上一个环节拉入新的工作,否则不允许拉入。
    控制在制品数量可以是环节内并行工作降低,当个工作项的完成加等待时间缩短,工作项从进入看板到交付的时间也会缩短。因此,加入用户价值的流动。
    而且更重要的是,控制在制品数量可以帮助团队暴露问题和瓶颈。举个例子,上图中如果测试的在制品数目达到上限,就不能在拉入新的工作了,团队应该聚焦于完成当前的工作,及时处理出现问题,如果测试这里长期积压,那么说明这个地方已经成为了团队工作的瓶颈,更早的 暴露问题所在。

    控制在制品实际上成为了一种拉动机制,下游工作顺畅的时候才能从上游拉动工作,这样最终拉动整个用户价值流的交付。控制在制品是整个看板方法的核心,也是很有争议的地方,因为它很难落地在实际开发环境中。这个问题如果有兴趣的读者我们可以进一步根据实际例子交流。

    运作看板方法的2个实践:
    1。 管理价值的流动
    管理工作流包括三个部分,
    1)准备队列填充,准备队列是整个看板系统的输入和价值流动的源头,管理好准备队列非常重要
    2)站会。站会是管理价值流动的活动,一个站会要发生每天的同一个时间看板前,团队成员更新并且根据看板上的卡片,关注出现的问题和阻碍,并且形成解决方案。
    3)评审。评审是需求发布前的活动,决定上限哪些功能和相关的策略。

    2。建立反馈,持续改进

    其实现实中总会有各种问题让价值流动不畅或者阻碍,同时这也是我们的改进机会。当然这个前提是团队必须建立有效的反馈系统,从问题中发现根本原因。
    反馈的目的是为了改善。团队根据反馈形成系统的认知必须最终落实到具体的改进行动,而这些行动也可以放到看板系统的调整中,而且其中一部分也可以放到看板外,比如说产品设计,团队调整,环境及工具的改进等。但是无论哪种改进,效果都要通过看板系统中价值流的状态的度量来考察,从而形成看板系统的改进闭环。
    本文初步介绍了一些看板相关的知识,其中看板的核心方法是控制在制品数量的拉动系统,通过这个来暴露问题,团队能够根据问题进行反馈和改进,从而提高价值交付能力。



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

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

     

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

     

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

     

     

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

     

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

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

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

    1. 看板方法

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

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

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

    1. 看板中的管道管理

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

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

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

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

     

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

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

    展开全文
  • 现在市面上的任务管理工具太多了,不可能一个一个的试用,简单的说几个必备特性,或者可以帮助缩小范围。 目标: 在尽量简单、简洁的情况之下提高我们团队的工作效率。 选择一个合适的工具并匹配我们的工作模式会...
  • ThoughtWorks的敏捷开发

    千次阅读 2018-07-23 11:19:45
    ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发...
  • 2011年,敏捷开发试点项目大获成功之后,平安科技驶入敏捷推广的加速车道。2012年试点范围扩大到10个团队,引入Scrum、看板(Kanban)、持续集成等流行的敏捷方法。2013年“开启敏捷2.0”,在组织架构上成立“敏捷中心...
  • 敏捷开发中的文档怎么写

    千次阅读 2018-06-05 13:19:13
    我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-&...国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为敏捷开发。一.什么...
  • 什么看板

    千次阅读 2017-03-30 15:21:05
    现在很多软件开发都流行...敏捷开发里的“看板”,或者称为贴满纸片的墙其实并不是看板系统,他们仅仅是可视化控制系统,是让团队以可视化方式观察WIP并进行自组织,便可自行分派任务,讲工作从待办列表中移到完成状
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 软件工程 - 敏捷开发

    2019-08-31 17:48:09
    敏捷开发中,软件开发在构建初期被切成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个互相联系,但也可独立运行但小项目,并分别完成,在此过程...
  • 敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此...
  • 我们在开发项目的时候常常会用软件工程方面的设计模型,如瀑布模型、快速... 有的团队已经应用了一些敏捷开发的实践,然而效果不理想,不知道是敏捷开发的问题,还是自己实践方式不得当; 有的团队听说了敏捷开发...
  • 105.敏捷开发模型

    热门讨论 2020-03-23 23:25:54
    什么敏捷开发?2.敏捷开发宣言3.站立会议的意义4.敏捷开发想解决什么问题?5.如果用敏捷的方式盖房子6.敏捷开发和瀑布模型的差异(1)敏捷开发是怎么做需求分析的?(2)敏捷开发是怎么做架构设计的?(3)敏捷...
  • 敏捷开发

    2018-08-10 11:26:13
    第一个管理的项目采用的是敏捷开发,以下是个人对敏捷开发的一点实践总结。希望能给大家提供一些帮助。 (关于敏捷开发的3355,敏捷宣言,十二准则在最下边有。) 敏捷开发流程: 1.首先需求负责人理清需求。 2....
  • 敏捷开发小结

    2017-01-05 20:46:21
    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中, 软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。 换言之,...
  • 看板(Kanban)开发方法是近年来最热门的敏捷和精益开发方法。越来越多的案例表明,它能够改善协作、优化管理,显著提高交付速度、质量和灵活性。看板开发方法的规则简单,但其有效实施依赖于对原理的理解、对原则的...
  • Scrum敏捷开发

    2019-11-12 15:29:06
    什么是Scrum敏捷开发 Scrum是敏捷开发的一种,是一种以人为本,迭代式增量软件开发的过程,以英式橄榄球争球队形(Scrum)为名,因此可以想象,整个团队是高效而富有激情的。以人为本,即Scrum开发特别强调沟通,...
  • [敏捷开发]研发管理 开发过程管理

    千次阅读 2020-04-29 16:05:35
    开发过程管理,主要面向开发人员的管理。其核心目的,是通过一个项目管理软件,来管理不同项目,然后通过项目的里的工作项,了解开发人员的工作量,效率,从而来管理开发人员,合理调配开发人力。 名词解释 项目...
  • 敏捷开发 宣言 思想 认识误区

    千次阅读 2014-12-11 14:16:54
    一个是敏捷开发的宣言 另一篇是稍微具体的方法
1 2 3 4 5 ... 20
收藏数 1,200
精华内容 480
关键字:

敏捷开发看板应该具备什么