重塑敏捷100天记录

1

38个追帖

1

1/16 第1天

重建团队,百废待兴

虽然服务市场13年上线,插件市场16年上线,但因为团队迅速的扩张,我们已然变成了一个新团队。敏捷没有得到传承,我们出了问题。

激励出了问题,我们是有梦想的战士,不是一群雇佣兵。决策出了问题,每个人是否真的站在团队的角度考虑问题。评估出了问题,每个故事是否真的从用户价值的角度进行评估。

改变,行动起来。

张松然   2018-01-16 15:04
2

1/17 第2天

定期回顾,加速变革

今天召开了久违的回顾会,由何留留敏捷教练主持,大约1个半小时,会议非常充实,大家吐槽了现在的问题,并制定了改进的决议。

决议内容如下:

1 找回团队节奏感,尝试定期发布(每周二、周四发布,周一、周三确定上线内容,提前周知所有干系人)。

2 每周三15:30-17:00定期回顾会,非常时期单周会,后期调整一周回顾,一周分享。

3 完成自测之后,再进行提测,保护好测试妹子。

沟通技巧:面对面,可视化,实例化需求(举例子)。

管理者要更及时的向上沟通。

张松然   2018-03-24 18:58
3

1/18 第3天

向上沟通,定期演讲

早上8:50-9:00与宝哥进行了10分钟的汇报,说了本次团队回顾的内容,表明了未来会更主动进行沟通和汇报,宝哥回答关注结果,但过程也很重要,尤其关键的里程碑。所以,在阶段目标交付节点,我们会约宝哥进行面对面的交付演示。

早上9:20-9:30何留留参与了团队的站会,并指出了相应的问题,一看板是摆设,二我被汇报。所以,下午的时候,重新梳理了服务市场的融合项目,并实体化看板。

张松然   2018-03-24 21:53
4

1/19 第4天

基于沟通,基于理解

之前使用电子看板进行敏捷提效,妄图系统自动化、数据化团队,但是没有沟通,不能称之为团队,没有理解,不能称之为需求,所以,无论使用什么看板,沟通和理解才是目标。

张松然   2018-03-24 23:14
5

1/22 第7天

跨级汇报,更加透明

团队Leader除了要向直属上级沟通外,还要更多主动单独的跨级汇报(直属领导支持的情况下),上级也是希望团队更加的透明化。但跨两级汇报,还是建议与直属上级一起进行汇报。

张松然   2018-03-24 23:15
6

1/23 第8天

看板演讲,发现瓶颈

早会听取何留留的建议,改变了形式,不再由每人进行依次汇报,改为团队每周轮流主持看板,从后向前依次对每个故事进行提问式、引导式发问,更新看板故事进度。

张松然   2018-03-24 23:15
7

1/24 第9天

交通规则,目标与规则

Team Leader的角色定位是制定团队目标,并制定团队规则。就像交通规则一样,制定红绿灯的规则,让团队执行,而不是关注每辆车在路上是怎么跑的。

今天进行了第二次团队回顾会议,会上首先对上次决议的改进目标进行确认是否执行,如果发现没有执行,那么回顾会就没有价值,然后核实并删除那些伪目标。

本次会议决议如下:

删除项:

1 找回团队节奏感,尝试定期发布(每周二、周四发布,周一、周三确定上线内容,提前周知所有干系人)。

新增项:

1 确定早会Checklist:站会主持人引导站会进行卡片走查更新进度发现问题、团队目标是否达成、产品信息同步(包括需求、方案、时间点等)。

排期原则:需求正常评估、正常排期,过程中的风险和问题及时向上沟通,及时调整排除阻碍(添加资源、砍需求、延期),评估影响因素,确认延期就不要硬扛着。

张松然   2018-03-24 23:15
8

1/25 第10天

同侪压力

早会在走查卡片时,由测试同学报出一个产品功能缺陷的问题,影响团队目标达成。此事团队要求产品同学确认解决,并承诺给出解决时间。早会后1个小时内,该问题就被解决了。(之前会下沟通问题就不知拖到什么时候了)

张松然   2018-03-24 23:16
9

1/29 第14天

目标一致,众志成城

在走查看板时,我们看到二期阶段目标达成是黄色圈内的核心故事(迭代发布),但其中有一个同时负责了三个故事,且形成了瓶颈,这时,团队迅速调整,进行资源调配,不是自己的故事完成就没事了,团队的目标是每个人共同的目标。

张松然   2018-03-24 23:16
10

1/31 第16天

目标达成,团队力量

今天团队召开第三次团队回顾会,确定了团队名称、价值观和团队愿景。

名称:春 (春如破晓,万物复苏)

价值观:合作 责任 热情

团队愿景:我们期望成为商家0投诉,项目0延期,团队0冲突的团队。

张松然   2018-03-24 23:16
11

2/2 第18天

纪律与能力

今天早会产品开始划水,不全程参加早会,原因在于产品去参加运营侧早会,这造成研发侧内容无法及时同步产品,效率极差,问题严重。在沟通无果后,升级与产品侧负责人面对面沟通,要求产品必须全程参加研发早会。产品与研发相互沟通、信息同步是非常重要。决议执行。

在敏捷自组织团队里,能力和纪律很重要。早会的纪律是底线,不允许任何人越线,对于违规者必须坚决顶回去。

张松然   2018-03-24 23:17
12

2/5 第21天

通宵达旦,步履蹒跚

今天三期正式上线,发现最大问题:临时抱佛脚。

三期其实很早就提测了,但是直到上线当天才进行产品验收和制定上线计划,一天修改产品验证发现的bug就弄到晚上11点,然后才开始上线,整个三期上线又是铁板一块,只能一起上,更糟糕的是每一步进行的都很不顺利,整个上线一直上线到第二天9点,近乎10个小时。好在,上线平稳、无大问题。

张松然   2018-03-25 12:53
13

2/7 第23天

把脑袋里的东西放在看板上

吸取了三期上线的教训,二期上线制定了二阶段的上线方案,并提前进行产品验证,并把验证发现的问题全部透明到看板上,进行即时处理。

今天本是第四次团队回顾会,但上线在即,与何留留沟通。达成共识,团队的第一目标是发布上线,第二目标是产品价值,自主目标是改进,也是优先级,所以,回顾会如果和上线冲突,一切以上线为第一优先级。

张松然   2018-03-26 09:16
14

2/8 第24天

延期上线

今天二期测试进行第3天,出现很多问题,第一遍全回归都没有完成,主流程跌跌撞撞,以现在进度完成测试的上线时间点预计就是放假前一、二天,如此的话风险极大。团队目标达成很重要,但是由于春节的特殊因素,上线一旦出问题就会完全失控。综合考虑多方因素,多方负责人讨论沟通,与宝哥确认延期春节后上线。

这件事的启发:二期年前上线的目标没有达成,承诺没有实现,这受限于团队整体能力,时间点到了没有达到上线标准,不是逞英雄甩不掉偶像包袱的时候,敢于把真话说出来,忠言逆耳,领导听起来可定会不舒服,但明知有问题不说,挡着大雷上线,那将是巨大的焦油坑。

另外补充的,不作甩锅侠,更不作背锅侠。研发外部,是产品问题就是产品问题,是测试问题就是测试问题,绝不背锅,但是研发自己问题也不甩锅。研发内部,该整顿整顿,该调整调整。

张松然   2018-03-27 08:55
15

2/22 第38天

Step By Step

春节假期,布置了寒假作业,团队每个人都梳理一遍二期、移动版服务市场的需求,整理成用户故事。

假期归来,第一步,将每个人梳理的用户故事进行讨论整合,我们做了一个游戏,先是一一PK,然后二二PK、四四PK … 如此下去,直至产出最终的用户故事。为什么是每个人,而不是分团队进行,因为只有每个人都了解背景信息,才能使团队获得持续的适应能力,否则无论通过“深井”获取怎样的效率,只要“接口失灵”,后者所导致的损失是前者无法弥补的。

第二步,全员对故事进行整体评估,尤其是规模(人日)。为什么是全员评估,而不是由几个负责人对任务拆解及评估,因为没有任何一个人敢确保自己拆解的任务和评估是准确的,必须依赖与团队的集体智慧。

第三步,也是最关键的步骤,进行阶段排期,我们要输出一个个阶段的目标(每个阶段做哪些故事)。

这是团队转型至关重要的一步,这个步幅跨多大,要求大家了解所有项目内容是否太耗时了?所以,阶段转型是希望大家要了解所有项目背景,粒度也是控制在用户故事上,具体执行会落实到具体小组中。

张松然   2018-03-28 09:16
16

2/24 第40天

一 梳理

今天进行需求用户故事的最终PK,大家坐在会议室里讨论。通过讨论不是证明谁对谁错,而是梳理出最真实的用户故事。在过程中,梳理就梳理,不发散,不考虑这个用户故事怎么做,需要多久做,这需要每个人转换角色。

经过将近2个半小时的讨论,大家一起梳理出了二期、移动版服务市场、权限融合详细的需求用户故事。

  • 二期第一阶段需求用户故事
张松然   2018-03-29 18:26
17

2/26 第42天

二 评估

由于调整了工位,重新购买了看板,看板的泳道还没有画出来,不过不影响使用。由于春节原因有些人没到岗,那些人则进行单独PK,产出的需要用户故事对现有进行补充和完善。

开始评估,我们遇到一个问题:如何评估,是绝对值评估?还是相对评估?与何留留讨论,首先评估是根据当前了解和所看到的事情进行评估,所有的评估都不是准确的。如果使用绝对值(人日)评估,可能就需要对故事进行拆分,又会很耗时,但效果又不一定有多好。所以,我们使用相对评估。

如何进行相对评估,其实就是依次对每个故事进行比大小,排列出来。然后,找出一个规模是1的故事,进行对比,来评估其它故事的规模。那什么是1,我们把1的故事定义为售价1元,这样发现就会很好理解。我们从晚上9点到11点,花了2个小时,进行了规模的评估,然后将规模是1的故事折算为人日,这样所有的评估就都计算出来了。

张松然   2018-03-30 09:58
18

2/27 第43天

三 排期

用户故事已经评估完毕,下面就是与大家&产品确认优先级,进行迭代排期。经过多轮小组讨论、与产品、测试进行确定,整理出我们确认合理的优先级。

这里说明的是一定要确定优先级和明确目标之后,再进行团队故事认领,因为大家都会认领自己喜欢的故事,而不是最紧急重要的故事。

最后,我们将重新梳理出的需求用户故事贴到看板上,进行团队认领。

张松然   2018-03-31 12:43
19

2/28 第44天

万事开头难

今天与上层各领导、合作团队都确认了迭代排期,正式启航。但总有些小插曲冒出来干扰你,这时就看你是否意志坚定,能够灵活应变了。

插曲一:今天有一个从外部团队总监压过来的需求,很迫切,产品出了用户故事,要求尽快支持。但马上开发会完全打乱现有的工作计划,之前做的事情将完全付之东流。与宝哥、运营、产品等沟通,分析其目标是满足其服务的线上化交易,问题是现在该业务发布的服务模型不支持线上交易,为了达成这个目标,产品的方案是改造服务模型,支持线上化交易,这个工作改动量评估很大。对我们来说,这个需求是不能说NO的,仔细分析了下,发现对方的根本需求是满足线上交易,所以其实是可以通过装修模板搭建新频道页,将其服务切换到软件服务类的模型上,就能够满足其需求。而最终方案也得到了双方总监的认可,这个插曲总结到,一是服务模型过多,不同的业务就设计了不同的服务模型,造成模型切换很难,后期要抽象、整合服务模型;二是当局者迷,不同时期满足需求的手段是可以不一样的,转换思路,不是每个需求都需要开发,而是现有的功能能灵活的满足其需求。

总结,随着需求的增多,我们要考虑的是:不是因为我们有那么多需求,所以需要做那么多功能。而是我们有这些功能(能力),如何要能满足更多的需求。—— 批量需求,通用功能。

插曲二:今天晚上有紧急上线,测试准备了测试用例,但问到需要多久时,未估算,这就是典型的未计划先执行。所以,进行迅速评估,发现需要12个小时,这几乎不可接受的。大家一起分析测试用测,发现有些内容是可以合并的,考虑2/8原则,边界收益理论,减少了测试范围,评估测试2.5小时。晚上上线,真实测试了3.5小时。总结,一切行动计划先行,有步骤,有时间。

张松然   2018-04-01 08:13
20

3/1 第45天

上线依旧步履蹒跚

今天启动二期上线。

上线计划包括测试环境测试、预发环境测试、线上隔离环境测试,正式环境测试,这样能在最接近线上的环境下进行测试。但即使是线上隔离环境也是与正式环境有差别的,重新思考,预发布环境和线上隔离环境的区别,以及边际收益到底有多大。秉承2/8原则和边际收益原则,去掉线上隔离环境测试环节。但这种方案的调整是在线上隔离环境走不通的情况下才考虑到的(因为外部依赖无法实现线上隔离环境与正式环境的完全隔离),而这无异于大战来临之际换将。

上线是无法100%保证不出问题的,与其把80%的精力去实现最后20%的价值,更应该是问题驱动,考虑出现问题时如何更快的解决和回滚。

上线小插曲:

一、去掉线上隔离环境测试环节并没有减少时间,因为预发布环境并没有全流程测完,所以这些事前准备工作都没有完成就启动上线。更糟糕的是,测试需要很长时间,效率很低。

二、预发布环境和线上环境部署的不是一个分支打出来的包,这个原因是研发考虑master和branch是完全一样、打包出的代码也是一样,但这种小差异如果出问题就会在定位问题形成很大干扰。

三、测试全回归测试基本是全手工测试,测试用例也未评审过,未确定测试范围以及是否合理。测试过程,两位测试测的很累,部分研发却只能干等着(或睡觉)。

总结:

1 跨夜上线不是正常的,除极特殊情况外(如修复重大BUG),坚决抵制跨夜上线。如果一定要跨夜上线,那一定留下有干系的人,一定是每个人都职责清晰的。

2 不搞摘VIP部署线上隔离环境测试。以后尽量即提前一天完成打包测试,正式上线就是点完发布之后,进行线上验证。

张松然   2018-04-02 12:20
共38条记录 共2页 上一页 首页 1
阅读数
阅读数
阅读数
阅读数
阅读数
分享到: 更多