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

原创 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的讨论


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

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

 


 

版权声明:

相关文章推荐

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

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

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

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

记一次有趣的社区活动

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

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

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

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

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

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

2008年经济危机的时候,周围的惶恐情绪不断蔓延,而且各种如何躲过裁员的帖子也层出不穷。那时,美国的同事给组里发了一篇文章链接。记忆中,那个标题是“我是在裁员潮中拿到了几家offer”.文章中,这个人...
  • Adali
  • Adali
  • 2012-05-29 15:47
  • 2708

敏捷软件开发——项目版本迭代

开发人缘和客户决定迭代规模,一般需要两周。同样地,刻骨选择他们想要在首次迭代中实现的素材(功能)。他们不能选择与当前开发速度不符的更多的素材。     迭代期间用户素材的实现顺序属于技术决策范畴,开...

敏捷开发免费管理工具——火星人预览之三:迭代,计划会,分配

这是火星人预览系列的第三篇(之一,之二,之三,之四,之五问答,之六,之七)。之一:需求与故事结构之二:编辑故事,产品管理,组织结构之三:迭代,计划会,分配任务之四:故事板,燃尽图,我的工作项之五:常见...

腾讯敏捷开发及快速迭代

http://www.biaodianfu.com/tencent-agile.html 从2006年开始,腾讯的研发规模开始膨胀,开发模式急需规范和标准化,到底走IPD(集成产...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

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