敏捷开发 看板_敏捷开发 看板 工具 - CSDN
  • –如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后,如果估计发生了变化,任务会根据变化在任务墙上做相应的调整。 通常的任务板是下面这个样子: 任务墙被...

    任务板展现了我们在Sprint过程中所有要完成的任务。在Sprint过程中我们要不断的更新它。–如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。

    无论每日站会过程中或者之后,如果估计发生了变化,任务会根据变化在任务墙上做相应的调整。

    通常的任务板是下面这个样子:

    任务墙被横竖分割成许多格子,每一行代表一个Prouct backlog项也可以称作一个用户故事.

    在Sprint计划会议期间,Scrum团队会分解每个用户故事得到许多的Sprint backlog项,每一项作为一个任务卡放到任务墙上。

    每个任务卡从To Do这一列开始。常用的列如下:

    • 用户故事–根据产品需求分解出的一个个用户故事.
    • To Do–需要完成的,但还未开始的任务。
    • Doing–刚刚开始,或正在进行中的任务。
    • Done–所有已经完成的任务卡都会放在这里,Sprint结束的时候可以拿掉它们。

    先是一些常见的任务墙的样例:

    金属任务板,使用磁铁来压住任务卡

    一个挂在开发团队办公室的任务板

    现在也有很多电子任务板,Kanboard ,trello,,Wekan,Leangoo 等等

    电子任务板和物理任务板各有优劣:https://www.leangoo.com/9414.html

    这是一个标准的电子看板示例图:

     

     

     

    展开全文
  • 2019独角兽企业重金招聘Python工程师标准>>> ...

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

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

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

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

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

    07133535_ihPg.jpg

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

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

    07133535_5RR7.jpg

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

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

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

    07133535_6IDn.jpg

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

    07133535_AnKN.jpg

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

    07133535_OWfR.jpg

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

    07133535_VyGt.jpg

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

    07133535_JZ88.jpg

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

    07133535_Zkpg.jpg

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

    07133535_1TxZ.jpg

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

    07133535_y87q.jpg

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

    07133535_GBBy.jpg

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

    07133535_sJtE.jpg

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

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

    07133535_MUFn.jpg

    转载于:https://my.oschina.net/997155658/blog/502263

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

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

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

    以下是本 Chat 的内容目录:

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

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

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

    FtooAtPSkEJwnW-9xkCLqSTRpBKX

    展开全文
  • 无可厚非,敏捷项目的最终成败与看板本身是物理的还是电子的没有直接关系。这里只是讨论:如果你打算用看板,那么哪种看板更适合你?当然前提都是要有一面较大的墙。 首先分别对比物理看板与电子看板的优势和劣势。 ...

    物理看板还是电子看板?

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

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

    物理看板的优势:

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

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

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

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

    物理看板的劣势:

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

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

    电子看板的优势:

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

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

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

    电子看板劣势:

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

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

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

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

    展开全文
  • 转自:http://blog.csdn.net/lifuxiangcaohui/article/details/48342315 敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!我们可以结合 Scrum 与 Kanban...
  • 今天我们来介绍一下敏捷开发中常用的第二个实践,看板方法。其实,看板方法实际上可以说是精益产品开发的重要实践,与其他敏捷方法相比,它具有更强的可实施性,提升端到端价值交付能力,更好支持系统的改进。而且它...
  • 敏捷开发看板不仅仅只是看板?在敏捷开发中为什么要采用看板?如何设计好的看板?任务条是改进的关键?   在我的理解中,敏捷开发中最先需要实施的三项重要工作需求用户故事化,沟通站会制以及进度看板化,这三...
  • 1. 看板式并支持Scrum敏捷开发 2.对人员的任务分配以及时间安排一目了然 3.因为一个sprint里会有不止一个需求,哪个需求对应哪些小的任务卡片,可以清晰分别 4.跟踪开发进度以及缺陷的管理,最...
  • 看板方法 看板(Kanban,来源于日语)最初是丰田汽车公司的大野耐一于20世纪50年代发明的,当时是从超级市场的运行机制中得到启示,将看板作为一种生产、运送指令的传递工具而被创造出来的。 经过60多年的发展和...
  • (栏目目录)故事板和看板其实不是一个东西,前者是最初的敏捷开发里边的东西,受到了后者的启发产生的;而后者是制造业的东西,具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西,可以认为大致...
  • Leangoo非常适用于Scrum和敏捷开发,我们可以用它轻松的创建Sprint Backlog,添加用户故事卡或任务卡,为用户故事添加估算的故事点,或通过拖拽来移动卡片到不同的状态列表。您还可以通过把团队成员拖动到一个任务卡...
  • 只要是在IT互联网行业工作的人肯定对 Scrum敏捷开发 都多多少少有一些了解。工欲善其事,必先利其器,那我给大家介绍一款敏捷开发项目管理工具-Leangoo。 它是由国内最早推广敏捷 也是最权威的 Scrum中文网 研发...
  • 现在市面上的任务管理工具太多了,不可能一个一个的试用,简单的说几个必备特性,或者可以帮助缩小范围。 目标: 在尽量简单、简洁的情况之下提高我们团队的工作效率。 选择一个合适的工具并匹配我们的工作模式会...
  • Leangoo看板工具也融入了人敏捷管理思想,专业的敏捷团队打造,完美支持Scrum敏捷开发看板方法。 Leangoo的核心是看板,通过看板共享和实时同步团队工作。 团队工作体现为卡片,卡片上的内容可以是...
  • 看板原理二:拉动式生产 拉动式生产是 “准时生产(Just In Time)”得以实现的技术承载。这也是大野耐一从美国超市售货方式中借鉴到的生产方法。相对于过去的推动式生产,前一作业将零件生产出来“推给”后一作业...
  • 前段时间火星人敏捷开发云做了Beta测试,已经上线运行了,网址位于:http://scrum.org.cn/,可以点击里边的沙盘项目体验一下。先介绍一下最简单的看板驱动模式,demo1~demo3中的缺省配置是看板模式,其中第一个项目...
  • 可视化实时协作看板 Leangoo支持灵活的自定义看板结构,创建列表即可轻松定义工作流程,创建泳道可以对任务进行分组对应,拖动任务以体现工作进展。实时同步看板信息,让团队工作情况一目了然,让团队成员即时协作...
  • 1. 看板式并支持Scrum敏捷开发 2.对人员的任务分配以及时间安排一目了然 3.因为一个sprint里会有不止一个需求,哪个需求对应哪些小的任务卡片,可以清晰分别 4.跟踪开发进度以及缺陷的管理,最...
  • 下面这个看板展示了在Leangoo看板中可视化的管理产品Backlog 列表,需求卡片,标签 https://www.leangoo.com/kanban/board/go/2808232# ...
1 2 3 4 5 ... 20
收藏数 5,539
精华内容 2,215
关键字:

敏捷开发 看板