看板管理

看板对流程和协作执行的改善

看板具有可视化工作和规则、限制在制品的数量和促进工作快速管理和流动的特性,本身就具备了横向和纵向流程、协作的元素。 1、横向:横向本身如果基于团队协作流程去自定义的话,在协作执行时会存在每个任务卡片执行完谁操作的原则的问题。一种是当前列的任务卡片负责人完成任务时修改下任务自身完成状态即可,例如标示一下已完成,然后下一列的负责人看到后把此卡片拖拉到下一列即可。还有一种时当前任务看片负责人完成后就把它拖拉到下一列。 2、纵向:纵向看板列本身包含了很多任务卡片,任务卡片自身有优先级或者任务之间的依赖性,在协作上也需要来定义执行的方式。一种可能按优先级高低来从上向下排列,也可以把相关系的任务放在一个泳道里进行独立处理之间的协作性。 那到底什么方式好那,其实对每个团队都不一样,需要成员自己达成一直即可。流程和协作需要在具体执行时不断的改善,才能找到适合自己团队的感觉和节奏。 执行一段时间可以基于回顾复盘不断的总结,不好的流程再不断的完善,最后把大家都认为好的看板和流程作为项目管理模板推广出去。

2 min read
看板管理

敏捷看板管理实践

敏捷看板是一种最直观淡化管理流程的一种项目管理工具,在做任务管理时看看有哪些实践。 1、看板泳道尽量少:建议一个实践阶段指开辟2到3个泳道最合适,原则是泳道太多,任务交叉就会增多,开发速度会减慢,就类似现实中的游泳池一样,泳道多了后相互干扰度加大。 2、单个任务时间短:单个任务评估时间最好控制在8个小时内,这种需要把任务粒度不断的细化,确保每个任务投入时间最小化,同时加快任务进展速度。 3、看板投入人力少:每个看板投入的相关人力不要多,一般建议在2-5人为好,人力太多相互间的沟通和偏差以及交叉流程也会加大,相对会减少开发速度。所以一般建议基于分工可以增加多个看板。 4、看板列尽量少:看板列尽量简化,看板列越多,说明流程或者协作过程太长,相对也会影响任务进展速度。

1 min read
看板管理

怎样用看板做任务管理

看板做任务管理是基于敏捷看板的最大特点直观性和全局性,方便个人关注自己的任务完成情况,也能直观的了解全局任务进展。 怎样用看板管理做任务管理,首先需要结合自身团队的角色组成和任务进度流程,我们就在这两个维度看一下怎样用来进行看板式的任务协作管理。 1、团队角色:团队角色的划分是用来确认团队协作和责任分工的基础,如团队角色复杂,如包括PM、BA、SA、DBA、UE、UI、Dev、QA、Ops等等,此看板在规划上就相对复杂,我们需要考虑怎样让这些角色人员更好的去管理自己的任务卡片,然后还可以进行跨角色的协作。如:我们可规划Todo、SA、UE、UI、DevDoing、DevDone、Test、Ops和Done等看板列,此看板管理包含了跨角色分工和任务状态的交叉看板。 2、

2 min read
看板管理

怎样用看板做OKR

怎样用看板做OKR,主要基于OKR和看板的结构怎样更好的结合。OKR目标管理主要分为目标和关键成果两部分,基于KR可再分解为Tasks,看板主要有可自定义的看板列、泳道和任务卡片组成。 1、部门到团队成员的看板列方式:用项目加项目管理工具创建一个看板管理的项目,为每个部门分别建立 一个OKR看板,第一列为部门总的目标列,任务卡片作为一个目标,再基于任务看片去创建分解子任务作为关键成果。其他列可同理按照团队成员去创建各自的OKR。 2、目标到关键成果的泳道方式:基于一个看板,把第一个看板作为公司总目标列,然后在目标列里创建目标卡片,并把此目标作为一个泳道,把其他关键成果分别创建为一个独立的看板列。每个看板列里的卡片再去分解为子任务作为团队成员的任务去分解完成。

1 min read
看板管理

看板任务卡片的优先级分类

看板任务卡片在具体任务执行时的优先级可能存在很大的差异性,如有的任务需要在固定的时间完成,有的可能只是建议下的需求,所以在做任务管理时可根据业务的需要定义相关的优先级分类。 1、可按优先级进行分类,把最优先的故事卡片在看板列里排在最上面,这样让整个团队成员可重点关注最优先排在看板每列最上面的优先任务。 2、可打颜色标签,可定义颜色标签,每个颜色代办一定的优先含义。这样可让整体团队通过颜色视觉标签清楚的了解相关任务的优先级。 3、按任务的轻重缓急来设置,例如可分为 加急处理、固定交付、普通类。加急类为最紧急需要处理或解决的任务,同时需要保持最多1个任务数;固定交付需要事先评估好充分的交付时间,需要在固定的时间点来完成此任务。普通类为优先级最低的任务,按照正常的任务提交时间进行排列,进行交付即可。

1 min read
看板管理

看板管理之泳道任务管理

看板管理之泳道任务管理是在当某个用户需求很复杂时,我们需要将其拆分成多个任务由多人进行协作完成,这个时候就形成了基于此需求或用户故事的泳道。 泳道看板可很好的解决讲复杂的需求进行分解,并多人协作的问题,不足之处就是子任务太多,依赖太多时会变得复杂,并且此需求必须有一个人统一复杂,并进行各个任务之间的协调。建议如下: 1、每个用户故事的下子任务分解到最小化,降低相互之间的依赖性,这样做还可以能有很快的阶段性成果产出。 2、任务数不能太多或者需求总的投入评估工时不能太大,任务数如果太多后建议尽量去再分解用户故事。任务数量多之后会增加相互的协同,任务自身的速度状态就变得很慢。总的评估工时不能太大,太大后阶段内很难有好的产出成果,再牵扯到其他团队的协作时,会拉长整体的开发周期。 3、每个泳道任务需要独立负责人,此需求负责人需要协同下面所有子任务的进展情况。 4、泳道不能太多,如果需要泳道建议同时最多开2-3条泳道,泳道多了后同理版本发布周期也会变慢。 5、总之看板中需要加泳道时需要考虑会不会影响整体的产出速度和质量问题,需要考虑直接的依赖性怎样降到最低。

2 min read
看板管理

敏捷看板实施的方法和仪式

敏捷看板通过创建看板列表即可制定某个业务流程,创建泳道即可对任务进行分组处理,拖动任务即可体现工作进展。实时同步看板任务,让团队任务协作一目了然,让团队成员即时协作,效率倍增,在实施过程中可重点关注如下事项。 1、站会 每日例行在固定时间全员参加,每人几分钟来介绍自己负责的任务状态和计划和问题。如果条件允许可以采用实体电子大屏,团队在电子大屏前即可看到整体看板,也可以随手拖拉操作,没有条件的也可以对着物理看板。 2、任务会 每个任务可选择性的根据难度或者大小,进行针对性的创建和讨论,一般有PM创建某个待办任务,然后发起和干系人的讨论,并进行确认。最后录入看板任务待办列。 3、发布会 在版本发布前,会针对计划发布的任务进行计划,主要确定要发布的任务边界。 4、回顾会 敏捷看板也是一种敏捷项目管理工具,也强调逐步完善,

1 min read
看板管理

敏捷看板的结构和业务应用关系

敏捷看板kanban可应用在不同的业务场景和团队,其本身具有灵活定制性,在看板管理时可根据不同的业务和团队按需来定义自己的看板。 敏捷看板总体结构分为看板列、看板泳道和任务卡片三部分,其目的也是让业务状态和流程更直观可视化,具体如下: 1、看板列:在看板管理角度可按需来创建拓展自己的看板列,在看板结构上是一条纵向的列。在做看板管理之前要充分了解此看板所承载的业务对象是什么?业务的流程是什么?要结合团队的实际应用场景进行规划。例如一个研发的看板,可根据研发任务的状态流程进行创建看板列,可分为 需求待办、需求设计、研发进行中、研发完成、研发自测、测试中、版本发布等看板列。可先参考项目加的迭代任务看板。 2、看板泳道:在看板结构上是一条横向的行,是每个任务卡片基于不同的看板列进行交叉流转的通道,每个看板泳道的任务卡片下可包含子任务。具体任务的执行者可左右拖拉任务卡片来修改任务完成情况。 3、任务卡片:

2 min read
看板管理

敏捷看板kanban的特点

敏捷看板kanban是由精益生产看板转化过来的一种敏捷开发工具,目前被应用在一些项目管理软件中,用来团队更方便的进行任务跟踪和管理。也是项目加最重要的一种项目管理协作方式之一。 敏捷看板主要具有如下特点,相对敏捷Scrum等工具,会更自由一些。也是因为这一特点,被更多的在产品开发中更自由一些的小团队所喜欢,但这一特点对团队成员对产品的把控要求是提高的。 1、没有固定的角色划分,不像Scrum等敏捷开发工具,会划分一个团队的固定角色。 2、可以在任何时候添加和更改任务,但每个阶段的任务数量会基于团队的投入和评估保持一定的量。 3、Task任务明细不会像Scrum那么细化,在做需求管理时会相对简单一些。 4、没有固定的开发周期和版本发布周期,基本上可按照任务的完成粒度和产品的需要就可以及时发布版本。

1 min read
看板管理

Kanban看板来源

Kanban最早来源于丰田公司Taiichi Ohno (大野耐一),灵感是从超市的运作中得到的一个启发,然后发明了一套JIT(Just-In-Time)的工具,在生产中解决发出和传送生产的指令。并在生产车间通过一个最直观的看板大屏来呈现生产工艺的相关数据,从而让每个生产人员很直观的Get到整体和自己相关的数据。 下面引用一下IT行业的看板大师David Anderson一段话:KanBan is an approach to change management that employs a Kanban system onto an existing process context in order to provoke