2015-02-21 17:44:58 lostaway 阅读数 14736
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师

原文链接:http://blog.yeyuzhen.cn/?p=264

       最近朋友打算在项目组中推广Trello的看板管理方法。由于之前自己项目组也实践过半年的Trello看板管理方法,就与他交流了使用经验。其实,去年半年的Trello使用体验还是不错的,有不少的心得。不过,没有系统的总结过,未能很好的分享出来。趁着春节大假,该补补了。

       Trello,是免费的在线多人协作看板系统。操作体验非常好,加之看板管理的理念简洁易懂,使trello是个分分钟上手的东西。

在实践Trello之前,参考了《精益开发实战——用看板管理大型项目》。结合自己的实际情况,设计了如下的Trello看板管理方案。

Trello看板管理方案

       trello.Board 表示一个项目或一些相关的项目。可以把相关的小项目组合起来放到一个Board中,Board太多管理起来很麻烦,也容易遗漏任务。我的建议是一个项目组只用一个Board,这样容易在Board中看到整个项目组的工作瓶颈,优化项目流程。

       trello.List 是任务列表。从左到右,List 组成的一个工作流,任务在列表之间转移,走完任务的生命周期。我经过多次的调整,创建了如下的List:

待定任务
    ||
    \/
未处理需求任务、未处理优化&&学习任务、未处理Bug任务
    ||
    \/
本周待处理任务
    ||
    \/
本周处理中任务
    ||
    \/
本周测试中任务
    ||
    \/
本周已完成任务
    ||
    \/
历史测试中任务
    ||
    \/
历史已完成任务

“待定任务”任务列表用来收集一些可能做也可能不做的任务,多是一些关于项目的较长远的任务。如确实需要开发,则移动到相关的下游的未处理任务列表。

“未处理需求任务”是工作需求分解后的任务,即关于实际业务的需求,一般就是领导交代下来的任务。

“未处理优化&&学习任务”,这个就是自己优化系统性能的人,以及与项目密切相关的新技术学习任务。这个列表中的任务,体现了你对自己的要求。

“未处理Bug任务”,Bug,都是伤心事,就不多说了。

“本周待处理任务”、“本周处理中任务”、“本周测试中任务”和“本周已完成任务”是周迭代的相关的4个列表。经过,多次的调整,发现以周围迭代周期是比较合适的。周一上午,花个把小时讨论并安排一周的工作。从未处理任务列表中移动任务到“本周待处理任务”列表。开发进行开发的时候,就将任务移动到“本周处理中任务”。开发完成后,将任务移动到“本周测试中任务”,进行任务相关的测试。测试完成后,将任务移动至“本周已完成任务”。测试失败,可以将任务打回到“本周处理中任务”。

“历史测试中任务”和“历史已完成任务”。其实,“历史测试中任务”本是不应该出现的分类。项目的需求验收测试需要协调外部资源,无法做到每周一迭代。每周完成任务开发后,自己只能做功能测试。本周结束,未进行验收测试的任务,就只能累积在“历史测试中任务”列表中,等待外部资源的协调。“历史已完成任务”就是已验收完成的任务。

       trello.Card 表示一个任务卡片。每个任务卡片都可以有一个简短的任务描述显示在外,只要合理的设计,任务简述就可以在卡片上显示很多的任务信息。经多次修改后,任务简述模板如下:

任务ID:“XX:20150221_任务简述”,所属系统:???”。[Milestone:v1.0][AAA:BBB]

任务ID是这个任务的标识,会出现在关于这个任务的讨论,关于这个任务的代码提交日志等等,关于这个任务的一切东西中。其中,“XX”表示任务的类型,包括:需求、优化、学习和Bug。后续的中括号对中,可以添加任务相关的属性和状态。如,任务所属里程碑“[Milestone:v1.0]”,任务完成日期“[完成日期:2015-221]”等等。

       周迭代的情况下,在周三下班的时候就要审视一下剩余的工作任务。多“加”少补,T_T。经过多周的练习,大家应该都能比较正确的估计工作量。只要每周能按时完成周迭代,总体的项目进度也不会出现大的偏差。

       由于看板是对所有成员完全开放的,所以应用看板管理时需要全体成员主动参与进来。每个人要完成属于自己的卡片的详细内容填写和卡片在不同列表中的移动。让看板尽量实时的展现项目当前的状态。至少要保证周五下班时的看板和当前项目的进展一致,使得下一周的周迭代能有正确的起点。

简化的看板方案的不足

       以上的看板管理方法可能比较适合10人以下的项目组,任务管理比较粗放,也没有可实践的流程改进方案。《精益开发实战》中描述的是40~60人左右的项目组管理方法,所以更大型的项目组看板管理可能需要如书中所述的更加系统的方法。你需要在看板管理的基础上不断迭代开发流程,找到开发流程的瓶颈,不断提高开发效率。

2016-10-18 21:09:46 rdhj5566 阅读数 2235
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师

今天想与大家分享一款敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!

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

  • 对于项目经理而言,最担心的就是项目进度不可控,不知道每位开发人员具体的工作进度,有了 Kanban 一切都是那么地清晰。

  • 对于开发经理而言,最担心的就是资源分配不合理,忙的人忙死,闲的人闲死,有了 Kanban 一切都是那么地自然。

  • 对于开发人员而言,最担心的就是绩效考核不公平,“凭什么我做的比他多,拿的工资却比他少?不公平啊!”有了 Kanban 一切都是那么地公平。

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


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

image

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

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


image

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

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

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


image

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


image

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


image

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


image

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


image

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


image

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


image

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


image

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


image

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


image

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


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

image

2013-04-14 21:58:41 armylau 阅读数 3398
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师

PMP征文活动时写的, 博君一笑


看板在开发与运维项目中的应用

 

 

背景

 

自从2011年开始,公司开始上手新的项目, 我被任命为此项目的PM及PO, 开始了跨时两年多的敏捷之旅。以下与大家分享我在产品开发及运维管理中使用看板的经验。

为了使用业界的最佳实践,检验前一阶段的敏捷培训的成果,这个项目从开始就作为公司全面敏捷及应用SCRUM的几个试点大项目之一,关注点很多。我带的团队主要工作包括新特性的开发兼项目上线后的运维管理。

众所周知,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。减少了原先项目估算的不准确性,返工, 拖沓, 问题阻塞而导致的各种浪费,不均衡和风险。小粒度的用户故事可以在一两周的迭代内完成开发和测试(并行开发),从而可以缩短交付周期。而看板又可以有效管理大量小粒度user story。关于如何划分sprint, user story已经有大量的文章和资料可以参考,我们在本篇中只重点谈看板。因为一般看板的描述中,要不只照顾到新特性的开发,要不只注重于运维,如何两者兼顾,这就是我所研究的。我们的团队是国际化团队,一半在中国,一半在北美,如何使两个团队更好合作,也是一个挑战和乐趣。

我作为传统项目的PM向新的敏捷开发下的PO(ProductOwner)转变,PO会将项目发起人的一系列想法转换成具体的userstory, 计划好后交由敏捷团队来实现,可以说PO的主要工作作就是沟通和backlog的工作队列管理. 而看板和每日站会就是促进沟通和管理工作队列的强大工具。 下图[4]很好地描述了敏捷项目的基本框架stakeholder, PO, 开发团队, user story, 工作队列管理及团队容量管理。

 

 

经过管理层和团队骨干人员的讨论,决定采用以下几个阶段开展敏捷:第一阶段先在各本地团队中使用物理看板,然后再转换成电子看板,最后把两个团队的电子看板整合。整个过程中,实施每日站会,每天早上10点开始到10点15分结束,严格控制在15分钟内。


物理看板与每日站会

 

看板本来就从工厂中产生,使用的就是一块大的物理看板,每项任务都可视化,在每日站会中每个人都可以自由移动和改变相关任务块,例如从任务队列中拉一个任务出来分配给自己,从开发状态转入测试, 从测试到交付. 而关于客户的问题,则是从调查到验证方案, 到完成方案,或者说是由于受阻, 则会投递到等待状态.

模板如下:

 

看板很重要的是任务队列的管理, 这是PO的主要任务之一。但是不是所有任务就一定要由PO加到工作队列中去呢?一般来说对于新特性开发和新的release及sprint来说是的, 但对于运维任务, 则不一定.因为一般新来的运维任务都会有邮件系统通知团队,而不一定要由PO实时监视管理, PO也无法保及时把所有任务都加到backlog队列中,所以我们原来运维的team leader(screener)出马,负责观察和审核每日的新任务,以及时放到backlog队列中。但有时由于只有PO才能得到最重要的外部信息,例如客户突然要求某个特性或补丁由于商业的原因提前发布等等,而团队中其它的screener或Scrummaster都不知道,这时PO会立马出来添加高优先的工作任务到任务队列里去。

站会开始时, 很快可以见到的效果是沟通增加了,PM或者现在的PO的压力减少了, 不需要被动地接受任务, 每个人都可以主动去拿,而且大家也可以马上知道全局的工作状态。但站会的不足之处时有时轮为流水帐事的讲述,虽然所有人及所有工作状态都了解到,但重点把握不足, 有时为了避免超时,会将还没讲完的取消。于为改为从今天最重要的事开始说明,最重要的事中也按优先级顺序排列,这种可以保证要事为先的准则,而且即使时间不够,也可能保证最重要的事情先说完。


有时候看板在讨论中不知不觉地过时了,也PO, SM也尽量避免太多的控制,因此我们引入的看板主持人来引导讨论,控制时间,还有对全局所有任务的理解和相关跟进。我们采用每周一换的形式,发现效果还不错,每个人都有机会做主持人,显示自己的领导力,避免每个人只关心自己的任务,更多的是每个人都要(至少有机会)从全局上关注整个团队的任务。

         

统一的电子看板

 

在尝了物理看板和敏捷的鲜后,团队开始向下一个目标出发,如何与地理位置不同的国际团队统一流程 – 使用统一的看板。看板背后的流程与数据库,对于国际团队合作来说,如何统一看板,如何交接工作,是一个难题。物理看板只能适用于本地,因此有很大的局限性,电子看板似乎成为了我们的唯一选择。

 

我们调查了市面上的几个看板工具,例如hansoft,leankit等等,要不功能不适合,与我们现有数据库难整合,所以我们决定自己重新造轮子 - 我们自己开发了一个基于网页的电子看板,与我们现在的系统很好地整合了起来。幸好这个需求难度也不大,由于开发和运维两块我们都已经有了自己的工作界面和数据库,所要做的只是一个新的针对看板的界面而已。

 

例如我们原来的电子工作模式是,如果有一个新的特征过来,或者要做一个系统的新补丁,或者运维的任务,我们就会通过公司网页建立一个工作项,将需求(ticket或story point),人物,交付日期等填上,然后每天更新状态及进展,有需要北美团队帮助的,就写上你的需求,然后晚上对方团队就会提出他们的建议及具体工作进展。同样如果北美团队需要我们的帮助,也是同样处理。这样的工作模式对于一般的工作任务是没问题的,但是如果对于难度更大,交付日期更短的工作,交接就不能这么简单,就需要电话实时沟通与交接了。电子看板的任务不过是将原来的电子工作流整合一下,每日站会也变成了需要订带有投影议的会议室的“坐会”,大家也只能“坐”在座位上指点看板。

 

 

成长之烦恼

 

后来由于项目人员的扩张,整个团队由8个扩张到14个人,差不多一倍的增长,工作量也大增,如果还像以前一样逐个任务一分钟讲解,那时间肯定超出15分钟.这时如何将时间继续控制好,而且也还能保持以前一样高效呢?我们采取的策略是:排序和精减!不是按先后顺序对它任务,而是按优先级顺序讲述。首先讲最今天最重要的任务,然后实行round table, 每个人快速的过一次,这样可以使要事为先,也能了解每个人的状态,同样由于每人都要发言,所以也避免了某人处于空闲状态,可以使人主动地去”拉”工作队列里的工作。

其中保证优先级最高的任务先完成是最重要的一点,为此我们还修改了电子看板的工具,加多一条横向的泳道表示最高优先级的任务。

 

反思

 

实施了一看,有以下几个观察,好现象是:

  1. 增加了团队的沟通,提高了士气.
  2. 及时反映出工作中的问题以便及时解决.
  3. 减少空闲状态,提高了团队的工作效率.

不足之处:

  1. 重要任务只有站会不够
  2. 自已电子看板的统计功能不够
  3. 任务不能及时清理, 不像物理看板, 要清理任务, 把便笺条一撕就行了。

总结的最佳实践

  1. PO使用优先级管理看板
  2. 使用看板主持人引导讨论以及采用轮换
  3. 对于一些重要的不能在看板讨论完的任务采用的是war room重点攻关
  4. 对于跨地区团队来说,尽量使用统一的电子看板


相应的后续措施:

  1. 关于统计和衡量功能,会继续参考其它公司的如Leankit来增强

 

总结

 

在国际化团化的协作中,电子看板能完成物理看板所不能实现的合作,是必不可少的。按优先级及roundtable来运行每日站会,即使团队扩大也能控制好时间。对于最重要的技术难题,使用warroom进行焦点攻坚。

 

 

Reference:

  1. 拿看板拯救你——我的“红”项目
    http://www.infoq.com/cn/articles/kanban-distressed-projects?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_articles_clk
  2. 看板和Scrum——相得益彰
    http://www.infoq.com/cn/minibooks/kanban-scrum-minibook-cn
  3. 看板任务管理
    http://www.infoq.com/cn/articles/hl-kanban-task-management/
  4. PO in a nutshell
    http://www.youtube.com/watch?feature=player_embedded&v=502ILHjX9EE
    http://pan.baidu.com/s/1qpqt9

 

 

更新

2014-01/07 - 添加看板最佳实践,更新看板主持人及轮换实践



2019-11-20 18:42:29 ones_ai 阅读数 253
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师

随着敏捷开发的普及,各类敏捷管理⽅法已被业界充分实践。但是在数百人或千人级别的研发团队进行协作时,简单的复制小团队的敏捷方法却会遇到诸多问题。SAFe 作为⽀持⼤型研发团队敏捷落地的一种方式,重新定义了可扩展的敏捷框架模型,同时也降低⼤型团队管理的复杂性。给大家分享在 ONES 发展过程中,我们的产品研发团队对于敏捷和 SAFe 的应用。

当我们是几个人的小团队时,用简单的物理看板就解决了大部分的管理协作问题,然后团队人数继续增长,我们引入了 Scrum,一直保持着多个 Scrum Team + 矩阵式架构的模式。

 

但是团队规模还在继续增长,简单复制 Scrum Team 的模式也不可避免的出现了一些弊端:

  • 部门内,组员不清楚整体的大目标,容易出现局部改进;而从决策者角度,需要保证业务价值最大
  • 部门间,因角度不同,各个部门对同一问题很容易出现分歧
  • 团队规模增长,不能再简单地拍脑袋做产品改进,迫切需要数据支撑,但是缺少度量的手段和方法,导致改进没有方向

 

基于以上这些问题,我们团队梳理出了大型团队的管理需求:

  • 各个敏捷小组需要定期的沟通整体业务目标
  • 业务、产品、技术等各类任务需要统一制定优先级标准,业务效率优先,兼顾职能效率
  • 有效的量化方法

 

为了满足这些需求,我们团队做了五件事:

 

引入 PI(项目群增量)会议和 PI 回顾会议

所谓的 PI 会议,其实就是包括4个角色的人参与的,每个月或者每个季度召开的会议。开这个会的主要目的有两个,一是确定出统一的优先级,二是解决部门间对齐和沟通问题。

 

参加会议的4个角色包括:

  • BO:最终负责人,可以简单理解为 PO 的直接上级,他不是管一个两个迭代,而是在多个迭代一起去做的时候,关注业务目标问题
  • 所有小组的 PO(产品负责人)
  • SA 小组,也就是架构小组,他们主要是负责表达技术的改进需求
  • 利益相关者,主要是指外部的业务部门或是客户

为什么是这4个角色呢?一是因为这4个角色加起来可以涵盖我们平时做规划时的所有角度,二来也可以解决部门间的沟通问题。

在确定优先级时,我们采用的是 SAFe 框架里的 WSFJ(加权最短作业优先)

 

WSFJ 的衡量方法,分子是产出,分母是成本,但是官方维度和国内的国情不太一样,我们在采用的时候,从我们的角度稍微地改进了一下。

对于产出部分,我们定了两个指标,一个是延迟成本,另一个是产品/技术价值/故事点

举个栗子解释一下什么是延迟成本,假设一个需求,现在把它做了,我们服务到的客户可以为我们赚50万,如果我下个月再做,有一部分客户会流失,有一部分客户可以等,那下个月再做出来的收益是20万,这中间的差距30万就是延迟成本。

 

在做 WSFJ 有几点需要注意的事项:

  • 在做估算的时候应该要根据实际情况调整加权计算内容
  • 工作项的规模相差的不应该太大,不能一个需求是一两周可以做完的,而另一个需求是三个月才能做完
  • 对于一些无法直接量化的内容,可以采用「敏捷估算」的方法确定数值

 

「敏捷估算」是基于Delphi估算的一种估算方法,可以简单地理解为,通过一次又一次的沟通,最后达到一个相对大家统一认可的结果。

 

引入 PI(项目群增量)回顾会议,获取反馈

在我们引入一个计划会议的同时还引入了一个回顾会议,目的是为了总结计划的执行情况。PI 回顾会议类似于敏捷中的迭代回顾,需要演示已完成的功能、收集反馈并将问题加入到 Backlog 中在下一次 PI 会议讨论。

 

加入新角色,调整组织架构

刚开始提到过,我们团队之前是矩阵式的一个架构,可以从图中看到,有一组、二组、三组,每一个小组都是一个五脏俱全的迭代小组,也会有一些职能组。

 

新的组织架构里,出现了新的4个角色。业务负责人(BO)是前面提到的,管理着所有的 PO;流程管理(RTE,负责搭起所有的流程;产品管理(PMgmt)类似于产品总监,负责所有产品的规划;系统架构(SA)类似于技术总监,负责的是性能上的、大的结构上面的改进。这种架构的改变,实质上是由矩阵式的结构变成了树状的发散结构。

 

 

度量,需要使用工具结构化数据

在度量方法上,我们采用工具结构化地存储工作数据,然后像运营一样去观察,然后想改进办法去执行,执行完再观察,形成一个闭环。

 

 

经过我们的实践总结,ONES 主要关注的度量维度是:端到端数据,比如客户满意度(业务部门满意度)、特性前置时间、软件发布质量。

 

 

DevOps 自动化

DevOps的概念非常大,我们目前着重的是自动化建设。我们有两个原则,第一是能够尽早发现问题,这也是我们在选择很多东西时所秉承的原则,它也能降低复杂度;第二是流程固化到工具里,让工具、软件建构工作复杂度。

 

 

关于自动化测试,一个非常重要的,也是 ONES 受益非常大的一个实践——质量内建。质量内建要求我们做好软件开发每个环节,尽早预防,以降低缺陷出现后的修复成本,要减少对创可贴式的补丁(hotfix)的依赖。

ONES 内部的质量内建坚持两个准则,一是自动化测试,从接口测试入手,二是坚持自动化用例执行率100%才算完成

 

注:本文中 WSFJ 属性估算等功能截图来自 ONES-企业级研发管理工具

 

 

2019-06-26 19:10:06 leangoo 阅读数 167
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师

用Leangoo脑图管理OKR,目标管理

 

 

OKR目标管理

阅读数 84

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