敏捷开发是一种快速、灵活的软件开发方法，目的是高效地交付客户需求。在敏捷开发中，看板是一个非常重要的工具，它能够帮助团队实时跟踪工作进展、加强沟通、促进团队协作。看板在敏捷开发中发挥的作用有以下几个方面。

首先，看板强调可视化，以图形化的方式展现团队任务和进展情况。在敏捷开发项目中，通常使用Kanban看板，将任务分为不同的列和卡片，每个卡片代表一个具体的任务，列代表任务的状态，如待办、进行中、已完成等。团队成员只需要在适当的列中移动卡片，就可以更新任务的状态，其他成员可以通过看板即时了解项目的进展。这种可视化的方式能够帮助团队成员更清晰地了解项目的整体情况，有利于快速反应和调整。

其次，看板作为一个集中展示任务的工具，能够促进团队成员之间的沟通和协作。团队成员可以通过看板及时了解其他成员正在进行的任务，避免重复劳动和信息不对称。同时，看板还能够促进团队成员主动交流，通过对看板上任务的评论和讨论，提供协作和支持。团队成员可以根据看板上的情况计划自己的工作并分配任务的优先级，从而达到更好的工作协同效果。

最后，看板为团队提供了一种可扩展的工作管理方法。敏捷开发通常采用迭代的方式进行软件开发，每个迭代都具有明确的工作目标和时间框架。看板能够很好地适应迭代开发的需求，通过列的划分，可以实时跟踪任务的完成情况和剩余工作量，帮助团队及时调整工作进度。另外，随着项目的进行，团队可以根据项目需求和进展情况对看板进行扩展和适应，添加新的列或卡片，使得看板更符合实际工作的需要。

综上所述，看板在敏捷开发中具有多重作用，它通过可视化展示项目进展、促进团队成员之间的沟通和协作以及提供灵活可扩展的工作管理方式，帮助团队高效地开展工作并交付客户的需求。

浅谈敏捷开发方法之看板(KanBan) 最近刚刚完成Agile的课程， 对Agile的几种methodology (Scrum, Lean IT, XP,  DSDM, FDD, Etc.) 有了一个浅显的了解，之前和现在的几个project都有在用KanBan和Scrum，所以准备写篇文章记录并分享课堂和项目所学有何不当之处，欢迎各路大神指正后续会继续分享其他几种methodology

注： 本人是程序猿一名，所以会偏向介绍kanban在软件行业的使用

1. 什么是看板？

    关于看板的定义，网上一搜一箩筐这里引用一下David Anderson一段话有人可能想问这哥们是谁 一句话，Taiichi Ohno (大野耐一)是Kanban之父，David 就是把Kanban引进IT行业的先锋

这句话意思就是说，Kanban可以被引入进任何开发框架去支持和推动持续性软件开发，不管你的开发模式是Agile的(比如: XP, FDD, TDD)还是传统的开发方式(比如:waterfall, iterative)

个人的理解就是，这个一种软件开发流程管理的方法，保证软件的持续集成并且不让你的开发团队超负荷很程序猿是不是应该很喜欢听到这句 不让你的开发团队超负荷 根据团队能力，限定WIP(work in progress)的tasks数量

2. 为什么看板？

1）可视化你的工作流程所有的task的进度会全部显示Kanban上，每一个人都可以一目了然了解进度和流程

2）限制WIP中的tasks数量一般情况下，这个数量是等于Team中的developer数量

3）管理并优化流程当WIP中的某一个task完成时，在ToDo中的优先级最高的task会被移到WIP中，这也是为什么当一个项目中需要经常更改优先级时，会选择Kanban的原因

4）量化开发周期

5）缩短开发周期这个其实可以理解为发现问题，解决问题，从而找到更科学的方法提高开发效率

6）变push system (just in case) 为 pull system(just in time)新的case只能在team有能力情况下再开始

3. 看板模型

根据我们现在项目的看板，我画了一个上面的Kanban墙

1）划分list， backlog:还没做的，一般是来自产品部(新需求)或者你们的线上support的客服人员(bug)design:正在准备design的，一般这个部分都是solution architecture或者UI Designer负责，并不是所有的task都会到这个list中来 development:这部分就很明显是coding部分，由developer负责 test:测试部分，由测试人员负责，done：已完成，等待上线每个项目可以根据自己的需求建立自己Kanban上面这个不是唯一的

2）在上面的每个流程中设置了限定的task数量这是Kanban核心思想之一，意思就是说同一时间，只能做这么多task比如Design是2 这个阶段只能有两个task进行这个一般是根据人数来决定这个限定数目

3）我们project已经上线，所以经常会有一些bug来自我们客户，同时也会有些新需求来自我们的产品组，有时也会需要对项目中某一部分的function做一个提高所以我们用不同颜色的代表不同类型的需求蓝色是bug，绿色是improvement，紫色是新需求这样可以更加清晰和归类

4）我们项目的产品组是project的stakeholder，所以一般由他们来划分backlog中task优先级然后team在做完一个task之后，去选择下一个最高优先级的task产品组是可以随时更改这些backlog中task的优先级除了下面两种情况：1. task已经开始，不可以替换正在做的task2. 项目周期剩余时间已经小于task的预估完成时间，这个task是不可以更改作为下个更高优先级

4. 卡片模型

 1) Ticket ID 是某个task的唯一标识 我们项目中，是使用了物理看板(就是买的一个大白板，自己画里面的内容)，当某一个task结束上线后，我们就会把task取下录入系统做备份所以每次去系统里，我们都会根据ID找这些task

2）task的描述就是这个task要做什么

3）Estimated Cycle Days 就是预估完成这个task要花费的时间根据这个时间，我们可以预估出完成所有task可能需要的时间我们也能预估出一个迭代能够做多少task，从而可以更好的排列backlog中task的优先级一般是由开发组集体讨论给出这个预估时间

4）Actual Cycle Days 是完成一个task真正花费的时间，如果这个时间跟Estimated Cycle Days（预估时间）相差很大的话，整个team就要做回顾和总结，哪里出了问题从而解决问题一般一个新的组建初期，estimated Cycle Days和Actual Cycle Days相差都会比较大通过几次迭代之后，大家都相互了解之后，estimated Cycle Days会变得越来越准确

5）task优先级用来排序拿个task要先做的这个是由产品拥有者来决定，scrum里面叫product owner, 传统项目中叫bussiness user 就是谁来出钱做这个项目的 我们项目中是由产品组的人来决定

6）task 负责人这个很明显了，就是要做这个task的人

5. KanBan和Scrum的区别

   有的项目可能用的是Scrum，Scrum会比Kanban来的复杂很多在Scrum有严格角色定义，开发周期管理但是看板是没有的个人总结，Scrum是一个完成的开发管理框架，比较完善的，而kanban只是开发流程的管理工具，可以放到各种开发框架中去的各位可以看下面的图来对比Kanban和scrum板的区别可能不是包括所有的不同

大家也可以去看下这篇文章，https://blog.csdn.net/iamdll/article/details/18552607

6. KanBan工具

kanban的工具有很多，大家可以自己去网上找找，我们的项目中主要是用物理看板，Trello和JIRA因为我们有些project是外包的，所以我们只能使用Trello和JIRA这种online的tool跟vendor沟通如果是自己的开发团队，个人建议还是使用物理看板

7. Work Agreement

其实work agreement不只是Kanban会有，Agile所有methodology都会有只是为了适应不同的methodology或者project，agreement会有不一样而已这个agreement不是给某一team或者人设立 而是给所有参加project的teamAgreement可以保证project稳定前进下面有几个例子

1）Task开始后，不可以修改task的要求或者更换task

2）task的估算时间，不可以大于迭代剩余时间（只包括working time）

3）早上9点之前到公司并开始工作，下午6点离开办公室

4） 会议期间，不可使用手机并集中会议主题

5）会议期间，只讨论跟会议主题相关内容，以保证会议可以准时结束

总结

   每个project都有各自不同的环境和人员的组成，Kanban是一种流程管理的工具， 每个project可以根据自己的情况，找出适合自己的使用方式 大家在参与的过程中才会学会更多的东西