敏捷开发任务看板_敏捷 任务看板 - CSDN
  • 敏捷开发实践—任务看板

    千次阅读 2018-12-04 15:05:58
    –如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后,如果估计发生了变化,任务会根据变化在任务墙上做相应的调整。 通常的任务板是下面这个样子: 任务墙被...

    任务板展现了我们在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

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

     

     

     

    展开全文
  • 用 Leangoo敏捷开发工具也有一年多了,很好用的产品 上手比较快所以团队协作起来没什么压力。 给他们提过几次需求,因为每次选择卡片复制卡片或者是引用卡片的时候因为卡片太多 ,要重复动作太多次,太累了 这次...

    Leangoo敏捷开发工具也有一年多了,很好用的产品 上手比较快所以团队协作起来没什么压力。

    给他们提过几次需求,因为每次选择卡片复制卡片或者是引用卡片的时候因为卡片太多 ,要重复动作太多次,太累了

    这次他们更新了任务卡片多选 ,可以多选一整列以及泳道:

    选择看板内的“多选”按钮  

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

    这样我就不用再重复操作了 ,方便太多了 !

     

     

     

     

     

    展开全文
  • 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

    展开全文
  • SCRUM敏捷实践—任务看板

    千次阅读 2018-12-04 15:16:32
    –如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后,如果估计发生了变化,任务会根据变化在任务墙上做相应的调整。 通常的任务板是下面这个样子: 任务墙被...

    任务板(墙)展现了我们在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

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

     

     

     

    展开全文
  • (栏目目录)故事板和看板其实不是一个东西,前者是最初的敏捷开发里边的东西,受到了后者的启发产生的;而后者是制造业的东西,具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西,可以认为大致...
  • 敏捷项目与任务看板

    千次阅读 2017-08-25 13:48:56
    我们最近在多个项目中使用Topo项目管理软件实施敏捷项目管理,有些经验心得.
  • 学习使用看板进行敏捷开发

    千次阅读 2018-03-15 11:53:50
    转自:http://blog.csdn.net/lifuxiangcaohui/article/details/48342315 敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!我们可以结合 Scrum 与 Kanban...
  • 敏捷开发看板不仅仅只是看板?在敏捷开发中为什么要采用看板?如何设计好的看板任务条是改进的关键?   在我的理解中,敏捷开发中最先需要实施的三项重要工作需求用户故事化,沟通站会制以及进度看板化,这三...
  • 看板优势,看到瓶颈,把控进度,调整策略,让开发可视化 需求分类,必备需求,期望需求,超出预期需求
  • 敏捷开发中的文档怎么写

    千次阅读 2018-06-05 13:19:13
    我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-&...国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为敏捷开发。一.什么...
  • 在本课程结束时,您将准备好提高敏捷开发过程的效率,避免常见的看板陷阱,并为您的团队带来最佳工作。 以下是本 Chat 的内容目录: 介绍 精益和看板 精益思维 看板原则 核心练习 看板实践 ...
  • 用Leangoo泳道完美实现Scrum任务看板

    千次阅读 2019-03-11 20:44:31
    敏捷开发的实践当中,通过可视化的任务看板来实现团队协同和透明化管理是必不可少的一个实践。通过可视化的任务看板我们可以达到如下几个目的: 1. 可视化管理团队的目标; 2. 明确目标的优先级; 3. 明确目标分解...
  • 敏捷开发每日一贴】:看板方法

    千次阅读 2017-04-10 09:19:56
    看板方法 看板(Kanban,来源于日语)最初是丰田汽车公司的大野耐一于20世纪50年代发明的,当时是从超级市场的运行机制中得到启示,将看板作为一种生产、运送指令的传递工具而被创造出来的。 经过60多年的发展和...
  • scrum敏捷开发框架 由于Scrum和看板都属于敏捷框架的保护范围,因此许多人将其混淆或认为它们是同一回事。 但是有区别。 一方面,scrum更特定于软件开发团队,而看板则被许多类型的团队所使用,并专注于提供敏捷团队...
  • 敏捷开发的实践当中,通过可视化的任务看板来实现团队协同和透明化管理是必不可少的一个实践。通过可视化的任务看板我们可以达到如下几个目的: 可视化管理团队的目标; 明确目标的优先级; 明确目标分解后的...
  • TFS 2015 敏捷开发实践 - 看板的使用

    千次阅读 2016-07-24 19:41:55
    看板在现代应用开发过程中使用非常广泛,不管是使用传统的瀑布式开发还是敏捷开发,都可以使用看板管理。因为看板拥有简单的管理方法,直观的显示方式,所以很多软件开发团队选择使用看板进行软件开发管理。本文不在...
  • 整个敏捷开发里,最核心的就是看板机制。所谓的看板机制,就是将团队内的各个角色成员,安排在类似一条生产线上,各司其职,通力合作。 看板一词来源于,日本的丰田制造。最早为了解决,生产机器之间的协作生产问题...
  • Leangoo看板工具也融入了人敏捷管理思想,专业的敏捷团队打造,完美支持Scrum敏捷开发看板方法。 Leangoo的核心是看板,通过看板共享和实时同步团队工作。 团队工作体现为卡片,卡片上的内容可以是...
  • 看板方法”是一个制造业的术语,由David Anderson 引入到软件开发领域。David 在其的著作《看板方法》一书中这样描述看板方法与精益之间的关系:“看板方法带来了一套复杂的适应性系统,该系统的目的就是在一个...
  • 用Leangoo敏捷开发工具也有一年多了,很好用的产品 上手比较快所以团队协作起来没什么压力。 给他们提过几次需求,因为每次选择卡片复制卡片或者是引用卡片的时候因为卡片太多 ,要重复动作太多次,太累了 这次...
1 2 3 4 5 ... 20
收藏数 3,907
精华内容 1,562
关键字:

敏捷开发任务看板