快速上线—— 开发、运维和敏捷迭代(社区活动总结)

原创 2016年08月29日 06:40:24


快速上线

——开发、运维和敏捷迭代

 

 

一)开发和运维不应该分离

在客户的眼中,不存在开发和运维的区别,甚至也不存在谁是项目经理的说法,他最关心的就是他自己的事解决了没有。换句话说,就是他的需求有没有被满足。


离客户最近的是什么?是线上的产品。就是那些对于客户来说,看的见,“点”的到的按钮。换句话说,也就是发布。有些发布,作为客户,能够明确的感受到,典型的如改版,或者增加了功能;不容易感觉到的,如性能改进。

出于很多种的考量,现在的产品,发布的周期越来越短,频率越来越高。如亚马逊,几乎每一秒都在发布。很显然,这种情况下,传统的人肉发布,已经不太现实了。这里已经发生了质变。

让我们简单分析下,为什么开发到发布之间会存在一些障碍,导致快速发布比较难。从开发的角度来看,首先产品依赖的操作系统可能不同,使用的各种语言、库都有可能已经升级。甚至配置参数的格式都有可能导致程序启动不了,而这些乱七八糟的各种内外依赖,可不是每个运维都能搞定的。如何接手这些烫手的山芋?

解铃还需系铃人。开发最应该负责任。当初为什么把这个配置写死,原因有可能是客户说,其他的都不考虑,也有可能的确是忘了把它抽取到配置文件里。


二)游戏介绍

1.人员与角色

现场分组的情况是,每组8人,其中1人角色是PO 1人的角色是ScrumMaster1人的角色是Tester,其余的是Developer

对于PO ScrumMaster,是否也做Develop的工作,没有限制。

 

发布组人员,从各组抽取一人,角色分别是:

Platform管理 1

Security管理 1

Release管理 1

 

客户这个角色,由专人扮演,(也就是王老师,这次社区活动的培训师)

 

2.“开发任务”

很简短有趣,就是拿Lego(乐高)积木搭建一些小玩具(“产品”),如飞机、鱼、蛇等。


“开发”的时候,需要到Platform管理那里领取一个“开发平台”。

 

3.“交付规则”

每组不同的“产品”,有不同的价值,也有批次的要求,如飞机的话,需要每次交给客户两个。

另外每次的交付物,需要打包,并且打上以下标记:

  • 产品名

  • 标号(批次号)

  • 开发团队编号

  • 文档

  • 迭代号


这么看的话,像不像一次真正的产品研发的交付物?

 

三)游戏过程

这个游戏,我们玩了三个循环(迭代),每一次都遇到了不同的情况。


1.第一次迭代(SP1

这次几个小组遇到的主要的问题是,不熟悉规则,团队的分工和运作也不是很清晰。

先看看外部表现,那就是每组都很混乱,声音很杂。

再看看游戏的结果,除一个组有成功交付外,其他的组的交付,都被拒绝了。

 

这个迭代原来设计的时候,有一个Platform的限制,也就是,每组需要去领取平台,只有平台到了,才能开工。并且平台只能由一个人来搭建。

现场的情况是“哄抢”,甚至自己动手做了。

 

由于,“产品”需要发布组的人员认可才有效,因此我们从交付过程中遇到的“Issue”来观察下:

a)被拒1:安全限制,交付的时候,才发现,积木上都有一个小的数字标签,安全组要求,不能带某些数字。

b)被拒2:有些交付,里面包含的产品,略有不同,如有的是一个大的方块,有的是用两个小的方块来代替一个大方块的。

c)被拒3产品打包的数目不对,如要求3个蛇,作为一个批次交付,那么6个蛇,应该分成两个批次,不能一次都交给客户。

d)被拒4:少了标签,或者某个产品上少了标记,等。

 

每次被打回去的产品,就是“浪费”了,不能再交付了。

 

反观这些结果,可以想见,每组的准备情况。

 

当然遇到问题不可怕,重要是总结,然后计划下次怎么做。这就是“回顾”。


 

2.第二次迭代(SP2

我把我们组的回顾放在这里描述,是因为这个SP1的回顾输出,其实就是SP2开发的要点。

首先,我们还是计划了下,要做哪些产品,也就是哪些“最贵”。

针对上次的混乱,我们决定有个人,专门做“backlog的管理”,也就是无论谁,要做什么,都要先到这个管理人那里去领一个标签,上面写明迭代号,产品,组编号,数量等。

开发人员搭建好了后,放在平台(A4纸一张)上,带上标签,一起去找Tester验证。

 

针对发布过程中,遇到的安全等等问题,我们组的PO非常积极主动,这轮游戏一开始,去先去把规则要了回来。

 

果然,这轮游戏下来,我们斩获不菲。

其实,仔细分析下,我们回顾出来的要点是:

  • 流程清晰,分工明确;

  • 规则优先,避免重复

 

3.第三次迭代(SP3

这个迭代比较有意思,因为发生了两个变化,

一个是打散了发布组人员,发布组人员,虽然角色和任务还在,但是,回到了各组,也就是没有专职的“发布人员”了。

这样,就是客户直接收这些产品了。

另一个,就是针对每组交的产品,标准不一,如有的组,做的小飞机非常精致,有的比较粗糙,客户制定了标准,也就是给出了标准的小飞机长什么样,都得照着做。

 

还是直接说下这轮游戏交付时候,遇到的状况吧。

首先,可以明确看到的是,各组的产量大增,这肯定得益于流程改进,配合都很好了。

 

客户只要4组蛇,其中一组,迅速提交了第4组蛇的产品,另外一组的蛇,虽然做好了,但是,由于客户的需求已经满足了,也就“浪费”了。

 

 

四)关于DevOps的讨论


这里,王老师,引入了“八荣八耻”的概念,也就是引入了大讨论,我们应该怎么做,争论比较大的是,“以微服务为荣”,“以整体框架为耻”,网友为什么这么提,想表达什么?

还有一个就是关于“迁移”的讨论。这里说的迁移,应该是指,数据中心内容,某个服务或组件失效的时候,应该由其他的组件来接替这个服务。是“高可用”范畴的讨论,而不是指旧业务迁移到新业务的问题。

 


 

App后台开发运维和架构实践学习总结(5)——App产品从需求到研发到开发到上线到产品迭代全过程

前言 如果没有做过开发,研发过产品的人,很难体会做产品的艰难,刚进公司的人,一般充当的是程序开发,我这里说的是开发,它与研发是有区别的. 一个需求下来,如果不能很好地理解产品需求,如果不能很好的驾驭...

大连程序员社区活动——敏捷之旅2011大连站暨QClub大连站2011年第三期

11月份的大连程序员社区活动已经确定,期待大家的参与。 敏捷之旅2011大连站暨QClub大连站2011年第三期 2011年11月19日,我们会非常高兴地看到,敏捷之旅作为全球...

敏捷2016 总结 (包括16年社区活动的收获问答)

敏捷2016 总结  今天是最后一个工作日了,2016年除了好好的写代码,忙的最多的,就是敏捷了。 首先得感谢 公司的王琴, 把我拉到了 北京的敏捷社区,和各位大咖有了很多的亲密接触。 ...

2013年组织社区活动总结

不觉间,又到了年末岁尾。时间过得真快啊。每到这个时候,总是需要对过去的一年做个总结,再对明年的事情做个计划,今年也不例外,呵呵。接下来我就对程序员社区相关工作,先做下2013年的总结,再计划一下201...

记一次有趣的社区活动

欢迎关注微信公众号:一只程序媛一只程序媛 通过学姐介绍,知道了FCC在西安将举办活动,果断拉着舍友报名,星期六的早晨,匆匆吃过早餐就在约定的地方见面出发。  收获:计划是走向成功重要的一步...
  • ting119
  • ting119
  • 2016年10月20日 16:08
  • 302

敏捷开发的26条至理名言 快速迭代式开发使用方法总结

敏捷开发真正的问题是什么?其实敏捷主要还是一种观念,一种意识,通过人来推动。本文总结了26条有关敏捷开发的关键原则,如何快速迭代式开发,供读者参考借鉴,以指引敏捷软件开发团队。 1、完整地干完一件事后...

敏捷开发的26条至理名言 快速迭代式开发使用方法总结

敏捷开发真正的问题是什么?其实敏捷主要还是一种观念,一种意识,通过人来推动。 本文总结了26条有关敏捷开发的关键原则,如何快速迭代式开发,供读者参考借鉴,以指引敏捷软件开发团队。 1、...

AzureDev 社区活动获奖者公布

今天,我们高兴地宣布 AzureDev社区活动的获奖者,并向这 5 个非盈利技术教育组织发放 10 万美元奖金。在 2013 年的Build大会上宣布的 AzureDev 活动专注于通过代码改变世...

参加拥抱HTML5大会及TOPGEEK社区活动纪实

4月16日,图灵公司谢老师和傅老师参加了由w3ctech举办的拥抱HTML5大会。图灵的忠实读者在展台前挑选自己喜爱的书智。此次图灵带到现场100本Javascript DOM编程艺术一书及其它图灵出...

技术人员为什么应该参加社区活动?

2008年经济危机的时候,周围的惶恐情绪不断蔓延,而且各种如何躲过裁员的帖子也层出不穷。那时,美国的同事给组里发了一篇文章链接。记忆中,那个标题是“我是在裁员潮中拿到了几家offer”.文章中,这个人...
  • Adali
  • Adali
  • 2012年05月29日 15:47
  • 2777
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:快速上线—— 开发、运维和敏捷迭代(社区活动总结)
举报原因:
原因补充:

(最多只允许输入30个字)