2018-09-06 10:38:34 weixin_34248487 阅读数 15
  • 构建高效DevOps团队

    构建高效DevOps团队视频教程,本课程融合了敏捷,Scrum/Kanban,用户故事地图,影响地图等一系列被广泛认可的佳实践和方法,配合微软 Team Foundation Server,Azure云计算平台和Docker所提供的Devops工具链支持,为参训者提供体验式的DevOps实施指导。

    3449 人正在学习 去看看 开发服务

前言

上回书,我们简单地入门了敏捷开发中的scrum模式,在实施的过程中,其实也是出现了不少问题需要解决。
那么这种模式有无弊端呢?--有!临时加入的需求排不过来怎么搞?开发时间延时交付不了需求被喷怎么办!一天站会这么多?!
那有什么解决方法呢?--尝试另一种敏捷模型,kanban管理。 为了解决敏捷模式中遇到的瓶颈,考拉技术开发小分队实践了kanban管理,由此对敏捷有了新的认识。

一、scrum的痛

scrum作为敏捷的落地方法之一,用不断迭代的框架方法来管理复杂产品的开发。通过其独特并固定的管理方式,从角色、工件、和会议出发,保证项目的不断优化。
在落地过程中,需要与团队的具体情况结合,不然,就可能会衍生很多问题:

  1. 项目估时不清晰:由于scrum没有具体交付日期,需求方会不间断增加新的需求,导致开发团队整体进度延后,出来的效果不尽人意;
  2. 团队分工不清晰:product owner无法清晰知道每个需求的进度。

scrum模型多适用于职能单一的团队,他们能够较好地管理需求,团队内部分工也较为清晰,product owner也可以更加合理安排内部分工。
那么对于经常周旋于不同任务之间的开发团队呢?kanban管理或许能够解决开发团队的问题。

二、kanban管理的起源

kanban管理最初起源于20世纪40年代末,是丰田汽车公司为了达到及时生产(JIT)方式控制现场生产流程的工具。
JIT生产方式与拉式开发理念不谋而合,具有以下优点:

  1. 控制库存:下游需要时上游才开始生产,有效控制库存;
  2. 加速流动:进入生产环节的物料和半成品,很快就被拉入下一环节,实现了保证安全库存的前提下物料最快流动,提高工程的运转效率;
  3. 灵活响应:用户需求变化通过看板行程的信息流快速传递至各个环节,系统能够做出快的响应;
  4. 促进改善:库存降低和流动加速,能够使生产问题快速暴露,比如生产环节的质量问题很快就会被下个环境发现。 JIT认为库存会带来商品的堆积,导致成本的增加,它鼓励企业逐步消除库存,以减少生产过程中的成本,逐步达到"零库存"状态。

三、kanban管理的优势

基于kanban管理的工作方式,能够将商品的库存量和实际消耗量对齐,只有当库存消耗殆尽才会发出信号,让生产端开始交付新一批产品。在降低库存下,降低了库存管理以及仓储开销,并能更加灵活地调整生产计划,及时发现生产过程中的问题。

四、敏捷开发中的kanban核心和原则

  1. 可视化工作流(价值流);

kanban管理让产品的价值和价值流具体可见,工作流分为不同的阶段,每个阶段的需求都代表了不同的价值,一个需求从开始提出,经过分析、实现,测试,到最终完成,其价值不断提高。因此产品的价值流是从左至右不断提高的过程,也是信息的产出过程。
价值流中,用户价值是可视的,开发团队要清晰每个需求的用户价值,从用户的视角去组织;其次,价值从提出到交付的整个过程,也应该是可视化的;最后,问题以及block也应该可视化。在价值流中会存在一些需求不明确、开发难度大等问题,不及时处理容易堆积成长队列,影响开发效率。 随着价值流动,开发团队可以及时发现项目中的问题,找到队列最长的阶段就可以发现问题,这跟交通系统的瓶颈处总是出现长长的候车队是一个道理。

  1. 限制工作进程(WIP)

WIP指在对某一个环节内的所有工作(包括正在进行以及等待安排)的进行数量上的限制。若在环节内在制品数目未饱和,可以从上一个环节加入新的需求,否则维持现有需求数量不变。 通过这个环节,团队可以更加专心开发目前的项目,缩短任务从进入系统到交付的时间。同时及时暴露团队协作存在的问题,如沟通不良、需求定义错误、开发难度大、资源分配不均衡等。

  1. 显示化流程规则

通过明确的规则,可以对整个流程不同阶段的产品质量进行把控。在前一个阶段的开发质量满足了“流转规则”之后,方可转入下一个开发阶段。
开发团队需要对即将落实到位的规则展开讨论并达成一致。通过这个步骤,开发团队可以“持续改进”产品的流程以及质量,不断优化产品。

  1. 管理工作流动

为了让用户价值顺畅、高质量地流动,团队需要管理好价值的流动。一般包含三项实践:用户价值的输入、中间过程以及输出。
1) 用户价值的输入:这是看板系统输入环节和价值流动的源头,输入清晰、明确的用户价值能够促进价值流流动,提高开发质量;
2) 用户价值中间过程:站会是管理价值流动过程的活动,开发团队每天都会安排站会,由团队成员对看板墙中的卡片进行排列,梳理每个用户价值的完成进度、遇到的瓶颈,并解决这些问题;
3) 用户价值的输出:用户价值在完成交付出去前,需要发布评审,产品经理决定上线或发布哪些需求以及发布需求的策略等。
为了对工作流进行有效管理,引入了一种度量方式--累积流量图。绘制累积流量图可以得到不同维度的信息,更形象曝光工作流中存在的问题。

5. 建立反馈,持续改进

基于价值流动,kanban管理形成了一套反馈体系,大体分为两类:一类是基于流动是否顺畅的反馈,比如阻碍问题分类、原因分析;第二类是关于用户价值质量的反馈。建立反馈系统可以让开发团队度量价值流动的状态,发现工作流中的问题,不断改进整个工作流模式,形成持续改善的闭环。
既然建立反馈体系能够暴露产品开发中的问题以及瓶颈,那么发现问题后,如何解决问题呢?kanban管理推崇2种方式--团队协作以及应用科学模型。
对于偶然出现的问题,可以通过团队协助的方式得到解决,如分配更多的资源、成员的相互支持等;而对于系统性问题,需要系统、科学的模型进行指导,通过这些方式可以不断提高团队持续改进工作流的能力,进而提升整个团队的价值交付能力。

五、kanban管理工具

基于开发团队的需求,可使用jira的kanban工具;
kanban工具有如下的功能:

  1. 不以sprint为单位,团队一直都只用一个看板,无需每周关闭和开启sprint;
  2. kanban管理一共分为8列:
    ● 创意:产品经理收集需求加到这一列,可以不以user story形式描述; ● 正在分析:产品经理正在分析的需求拖动到这一列,此时可以将创意的card拆解成几个user story;
    ● 下N个需求:产品经理不断调整任务优先级,将即将要开发的需求拖动到这一列,这一列任务数量有限制,任务太多将会让开发人员负荷过大;
    ● 正在开发:开发人员将正在开发的需求拖动到这一列;
    ● 等待测试:开发人员将开发并自测完成的需求拖到这一列,测试人员对这一列的需求进行测试,这一列任务数量有限制,任务太多将会让测试人员负荷过大;
    ● 正在测试:测试人员将正在测试的需求拖动到这一列;
    ● 等待发布:测试人员将测试完成的任务拖动到这一列,开发人员对这一列的需求进行发布,产品经理验收;
    ● 已发布:开发人员发布完成并验收完毕后,将任务拖到这里,并点击Relase记录此次发布的版本,这些任务将会不显示在看板上。
  3. 任务下方会显示该任务停留的天数,以提醒团队注意该任务;
  4. Relase功能,可以清晰看到每次发布的功能;
  5. report里面有很多图表,看板方法最常用的应该是堆叠图,可以看到各个阶段任务的数量,以了解整体的情况。

小结

在进行了kanban管理的实践后,成员了解各个需求的进度,开发团队的开发效率有了提高,就算临时插入需求,也能根据优先级调整应对。
在敏捷实施中,适应公司的情况,发现合适的开发方法,一直是令人头疼的问题。kanban管理给出了一种新的方式,从产品开发现状出发,首先可视化工作流并显示化流程规则,接着通过限制在制品数量,推动开发团队发现工作流的问题以及瓶颈,最后通过反馈系统以及团队协作等方式,不断优化工作流,提高团队的开发效率,实现一个高效、顺畅的产品开发工作流。
对考拉的dev而言,kanban管理是一种新的尝试,也希望这种新的尝试能够给更多dev带来更多实践上的革新。

参考资料:

  1. 敏捷其实很简单(4)--初识看板
  2. 精益看板方法从理论到实战 (1)—— 看板方法和看板实践体系
2012-11-05 09:07:23 iamtestingiamtesting 阅读数 42
  • 构建高效DevOps团队

    构建高效DevOps团队视频教程,本课程融合了敏捷,Scrum/Kanban,用户故事地图,影响地图等一系列被广泛认可的佳实践和方法,配合微软 Team Foundation Server,Azure云计算平台和Docker所提供的Devops工具链支持,为参训者提供体验式的DevOps实施指导。

    3449 人正在学习 去看看 开发服务

Kanban虽然有透明、限制WIP(在制品)和度量、提升工作流、PULL模式作为基本的特点,但这并不是说选择Kanban是因为Scrum不具备这些特点。应该说,两者都具备这些特点,只是在细节处各有侧重。Kanban和Scrum比较,在团队组织、交付频率、流程管理等方面有以下的不同之处,了解这些区别,会方便我们选择是否用Kanban:

2016-04-19 10:29:33 lisl1998 阅读数 1544
  • 构建高效DevOps团队

    构建高效DevOps团队视频教程,本课程融合了敏捷,Scrum/Kanban,用户故事地图,影响地图等一系列被广泛认可的佳实践和方法,配合微软 Team Foundation Server,Azure云计算平台和Docker所提供的Devops工具链支持,为参训者提供体验式的DevOps实施指导。

    3449 人正在学习 去看看 开发服务

一、    推广背景

项目的开发进度很大程度上取决于团队成员对项目当前状态的熟知程度,如果每个成员都清楚项目的当前进展和未来走向,就比较容易同心协力地向目标挺进;如果项目管理者和公司高层也能较方便地随时可视化地看到项目的综合进展状态,就更有利于任务调配和资源利用。尤其是敏捷开发团队,采用什么工具来促进项目团队成员间的沟通和协调,对项目的成败起着至关重要的作用。

传统的“甘特图”、“网络图”等计划管理、以及“香蕉图”挣值管理等项目任务进度管理方式,不光在更新上费时,同时也并不是每个开发人员和干系人都方便的去看和即时关注,甚至也不是每个人都看得明白项目整体情况。在开发的过程中,不论项目经理还是项目上层管理者,都希望有一个工具能让他们简单而快速的了解项目的进度,并且能在风险发生前做出预判,并提早采取措施进行解决。因此,我们制作了动态看板模板,推广到研发项目组使用。

 

二、改进措施

为了提高工作效率、可视化地跟踪管理项目状态,我们推行了项目动态看板,把项目任务按责任人或工作组进行动态分配,标注出计划做(To do)、正在做(Doing)、延迟(Delay)和已完成(Done)等各类事项,选择一个项目组成员都能方便看到的地方,在白板上用即时贴划出项目管理看板工具。达到灵活的分配任务,跟踪任务状态,随着进度的更新,变换即时贴的状态,无论是项目管理者还是项目组成员、或组外成员,都可以随时方便地获得项目当前的状态。

下图是初期版本的看板,基于试用经验,推广到各研发项目中使用。

 

图1  项目看板

三、  推广案例:

1)    某产品平台项目看板

该平台项目采用任务表方式,显示了在某次阶段任务迭代中,要完成的所有任务的当前状态。任务用即时贴卡片(便笺纸)来标记出任务事项、责任人、计划起始时间和结束时间等信息,状态则由板上分别标有“将要做”、“正在做”、“已做完”、“延迟”的四个区域来代表。团队成员随着任务的进展随时更新任务的状态。

 

图2  项目动态看板

2)    项目看板(任务表+燃尽图)

该项目采用任务表+燃尽图方式,不仅以看板刻划出各类需要进行的工作任务事项,用即可贴灵活分配和跟踪任务进展状态,还采用燃尽图描绘项目进展趋势,纵轴代表剩余工作量,横轴代表任务时间,显示当前冲刺中随时间变化而变化的剩余工作量(可以是未完成的任务数目),剩余工作量趋势线与横轴之间的交集表示在那个时间点最可能完成的工作完成量。它展示了项目的当前状态以及完成剩余工作的进展比率。

 

图3    项目任务看板+燃尽图

 

四、  工具推广的实际效果:

使用动态任务看板工具能够极大提高项目组成员间的沟通效率,加快了相关问题处理的速度,从而降低研发项目的进度延迟率,有效地保证研发项目的执行,提高计划执行符合率,提升研发过程质量。

动态看板工具具有以下特点:

1、    具备可视性,直观展示进度情况;

2、    具备风险预估,提醒团队目前完成情况;

3、    支持任务估量,直观显示当前还需要的时间;

4、    能够消除沟通瓶颈,促进项目组成员积极性,因为谁都不想在看板上看到延迟的工作中有自己的内容。

5、    让团队时刻能更新手头的障碍,并有预期的看到障碍的解决时间,方便合理地安排自己的时间;

6、    作为一个团队成员间的记录板,很容易看到别人正在进行的任务,任何问题,可以方便的找到责任人;

7、    让团队意识到自己当前的进度,调整和协调开发速度

8、    帮助项目经理预估可能遇到的困难与阻碍,避免缺陷出现,提高产品质量。

2012-12-28 09:07:12 iamtestingiamtesting 阅读数 373
  • 构建高效DevOps团队

    构建高效DevOps团队视频教程,本课程融合了敏捷,Scrum/Kanban,用户故事地图,影响地图等一系列被广泛认可的佳实践和方法,配合微软 Team Foundation Server,Azure云计算平台和Docker所提供的Devops工具链支持,为参训者提供体验式的DevOps实施指导。

    3449 人正在学习 去看看 开发服务

写这篇文章的背景是:一个项目组实施 Scrum取得成效,如何在整个开发部门推广 Scrum?看一下我们一个大产品,三个项目组共同完成的具体实践:

我们做了如下的组织调整:

1.     产品部增加一名总监(CPO ),负责公司层面的产品思路,整合三个子产品

2.     各个Scrum 小组的架构师和DBA 成 立虚拟架构师团队,架构师团队根据产品部的整体产品思路,提出并实现公司层面的技术架构(此时每一个项目组需要一个高级开发人员参加)。公司所有产品在这 个架构平台上进行开发。这样的好处是:公司整体的开发成本、维护成本降低,质量提高。同时架构师和参加架构开发的高级开发人员在项目组内可以快速将架构平 台应用在本项目组。在产品开发迭代开始之前,由“架构师团队”完成系统级的架构,然后架构师团队的成员回到自己的Scrum 团队进行每日的工作。

3.     各个Scrum 小组的QA 成立虚拟QA 团队,主要的目的是为了整合研发部QA 的资源,推出更加高效的测试方法、测试工具

4.     三个项目组的SMScrum of Scrums 的方式,每天(需要的时候随时)以会议的方式沟通1020 分钟,主要是产品间的整合、项目组见资源的协调、遇到的Impediments 如何解决等。

5.     各个Scrum 小组的美工成立虚拟美工组组,负责公司所有产品的界面(页面)设计,最大的好处是页面风格统一,页面层的技术可以共享,同时有利于公司的产品宣传和产品形象。

6.     每个Scrum 小组内部以Scrum 的方式工作,Scrum of Scrums 的沟通介质是Kanban

7.     成立部门级的支持团队,分为技术专家团队、公共组件团队、领域专家团队、独立测试团队,每个团队人数很少,但是可以使整个部门的工作有效率。例如,架构师团队的Leader就是组件团队和技术专家团队的PO,只不过他们的Product Backlog只有技术需求而已。

8.     技术专家的工作以Kanban管理,公共组件团队的工作以Scrum管理

 

以下是我们实际使用的组织架构图:

 

 

2018-09-21 13:04:43 qq_31977125 阅读数 183
  • 构建高效DevOps团队

    构建高效DevOps团队视频教程,本课程融合了敏捷,Scrum/Kanban,用户故事地图,影响地图等一系列被广泛认可的佳实践和方法,配合微软 Team Foundation Server,Azure云计算平台和Docker所提供的Devops工具链支持,为参训者提供体验式的DevOps实施指导。

    3449 人正在学习 去看看 开发服务

现在大多数团队都在谈敏捷开发,似乎觉得敏捷是软件开发的银弹。只需要实践下一些敏捷开发的模式就能如何如何,其实我觉得不论是敏捷开发还是传统的瀑布流开发都是有他们的市场的,取决于团队人员构成,取决你的产品的属性,所在市场的竞争环境。最终希望达到的目的都是一个:以最快的方式、最高的质量,实现所需的需求。

我最近所在的两个团队都是移动研发团队,一个是在相对大型的外企内部面向企业级软件,一个是创业型团队面向消费级应用。第一个团队我们是从传统的瀑布流开发模式向Scrum转变而来的,第二个团队我主导整个研发团队,结合了Scrum以及Kanban的,采用的是混合型的开发模式。

Scrum实践

Scrum的基本概念我就不赘述了,希望快速了解的人可以一步到此。

我谈下我们是如何操作的:

  1. team角色的分配:产品,研发,Program Manager。产品提供业务的需求描述,MockUI。研发包括Scrum Master, Developer, QA,负责软件的研发测试。Program Manager负责整个项目的进度控制以及对外team的沟通协调等等。

  2. 使用的工具:VersionOne用于整个Scrum开发的项目管理,后期我们换成了Jira Agile,主要是因为我们也用Jira来做bug Track,分散在不同系统管理也是挺复杂的。代码管理Github,文档管理Confluence,测试用例TestLink。

  3. 流程:

我们以一个月作为一个release周期,每个月的15号到下个月15号,发布一般在下个月15号的那个周五。一个月分为3个dev sprint, 1个release sprint。

Release Planning阶段

Release kickoff meeting: 周期开始阶段,产品team负责解释未来一个release要做的功能。通常产品team是维护Epic,并且将Epic分解成backlog(具体需求),并排好backlog优先级。

Engineer backlog discuss meeting: 拿到backlog,研发团队就需要对backlog进行分析,理解需求,并能分解成Task (任务),并对每个task的工作量进行估计。这时会有两种方式进行工作量的估计,传统的人天,或者用Poker Points。

人天的方式比较容易操作,大家熟悉也比较好理解,但这种方式是没有办法去衡量一个团队的生产力变化情况。对于一个固定人数的团队,在固定时间内可以产出的人天数是固定的。

Poker Point的做法是选定一个task作为基准,比如1分,然后评估其他任务的时候始终以这个基准作为参考给出相应的分数。这个时候其实需要注意避免一言堂,所以很多时候是通过出扑克牌的方式来达成整个团队的一致的,可以通过多轮的出牌,一定要整个团队都对这个分数表示同意为止。使用Point的评估方法相对难操作,但好处也是显而易见的,通过每个release point的数量可以非常明晰的了解团队生产力的变化。

这个阶段通常需要在1~2天完成,一个好的planning对于整个release的成功与否至关重要!好的开始以为着成功了一半!

Plan结束后我们会在VersionOne/Jira Agile系统中填入所有数据:

Development Sprint

Daily Scrum Meeting: 很多团队都是使用这个,每天的scrum站立会议,通常是每个成员介绍自己昨天的工作,今天的计划以及碰到了什么问题。这个会议一定要强调效率,15分钟内解决,所以超过10人的团队建议拆分分别开这个会议。Scrum Master在这个会议需要起到一个计时的工作,保证控制会议的节奏,如果碰到复杂问题一定要会后再讨论,不要陷入无休止的讨论中。

每人都要及时记录自己做的任务的情况,做了多少,还剩多少。这样可以产生一个非常有用的图表,Burndown Chart。这个图表可以很容易看到项目进展的情况。
在这里插入图片描述
在整个Dev Sprint里面,测试团队是和开发团队紧密合作的,测试应该是在整个开发周期最开始就介入,一起讨论需求,一起评估,同时写测试用例,不断进行新功能的测试以及迭代测试。理想状态下3个星期的开发周期内,开发和测试一直是同步的,3周内开发完成,新功能测试也基本能完成。

Release Sprint

这个阶段是为了稳定产品质量,为发布做准备。我们采用标准的Git flow来管理代码库。

在这里插入图片描述

在Release sprint开始的时候,我们会从develop分支checkout出Release分支。在Release分支只接受bug fix的commit,在develop分支依旧可以提交新功能,不过这时提交的新功能是要到下个发布周期才会发布的。

发布的标准:

  1. 没有高优先级的问题

  2. 没有regression的问题,就是以前版本是好的,新版本导致

发布时,将release分支的代码同时merge到develop和master分支,并在master分支上打上标签。

每个release结束后还需要retrospective meeting, 大家可以总结,并进行不断的改进。

Scrum是个相对完善的项目开发模式,各种工具也非常完善。我觉得需要注意几点:

  1. 固定的发布周期:这样可以培养良好的开发迭代的周期性,同时也容易可以评估每个周期的效率。

  2. 产品团队和研发团队的时间是不一样的,一般产品团队工作要提前1~2个星期,保证研发团队不会因为需求的不明确而影响效率。

  3. 避免需求的变更,无论何种开发模式,需求的变更总是不可避免,所以最好是将周期缩短,可以让产品团队可以忍受延迟些时间来实现这些变更的需求。

  4. 要预留一定的buffer,毕竟程序员也是人,也会有不能出活的时候,也需要学习分享知识,所以不要把时间完全填满,留给大家时间调剂。

没有更多推荐了,返回首页