分类目录归档:敏捷

停止使用重量级测试工具

专业的咨询师不仅需要对新兴的技术和趋势有足够的好奇心去探索,也要能够对过气的技术工具有自己的评价,这样当客户咨询师为什么做这样的技术抉择,而必须放弃手头已经的技术投资时,才能有足够的说服力。

这次要介绍的是2013年12月版ThoughtWorks Tech Radar中的Heavyweight Test Tool条目,状态是Hold。Hold就是建议停止使用。

继续阅读停止使用重量级测试工具

形形色色的CI Monitor

个人的观点,持续集成是敏捷软件开发中最为重要的实践,没有之一。而加速反馈的重要方式,就是持续集成结果的可视化呈现,也即信息辐射器,作为团队监控软件构建状态的接口。专业的持续集成平台,不管是像ThoughtWorks的商业产品Go,还是CI开源世界代言人Jenkins,都提供了开箱即用的CI Monitor。

下面是Go的CI Monitor界面:

tw_go

继续阅读形形色色的CI Monitor

第一个迭代计划

在Scrum中,整个团队会举行计划会议,以决定接下来的这个Sprint会做哪些事情,决定由PO和整个团队来做,依据就是优先级。PO会去选择那些从他的角度看优先级最高的,在上个Sprint已经完成工作的基础上,从Product Backlog中新添加那些对于软件用户来说最具优先级的特性,来交给团队实现。这里当然会有特别的情况,比如会有新添加的特性需求,也会有上个Sprint未完成的功能,还会有个别需要去掉的需求,需要PO在这里统筹安排,并和团队一起协商,达到一个最优化的选择和决定。

然而这里说的不是泛泛的迭代计划该怎么做,而是第一个迭代的计划该怎么做,根据什么依据或者原则来决定第一个迭代做哪些故事,我们会看到这里需要有更多的考量因素。

  • 可以组成MVP的那些故事。也有书里把MVP叫做MMF的,反正就是能够组成目前所要构建系统的最小价值组成。有个极端的例子,虽然当前需求的系统有很大的预算,也预见可以做一年,但突发情况要求只有一个迭代的时间,团队需要思考,从那么多需求中如何梳理出客户所需要的,真实的最基本的那些功能,能在一个迭代里面就可以交付的价值。这也是为客户负责,钱花得值,团队的努力有所回报而考虑的。可以认为从第二个迭代开始,从product backlog里面选取的故事,都是在丰富和扩充MVP。
  • 可以建立系统基本架构的那些故事。把那些有可能搭车系统的最基本架构的故事挑出来,这样最大的好处在于,能够尽早发现基础架构可能存在的问题,设计的问题,尽早避免在很久以后发现问题时,进行修补所带来的更大的代价。
  • 可能是技术难点和风险的故事。这些故事要尽早去做,从设计到开发到测试,把比较难的风险大的特性需求尽早完成,一直是TW团队所追求的,初衷同样是尽早消除这些技术难点和风险,并同时避免开发晚期遭遇这些技术难点和风险时,所招致的更大代价。
  • 找出处于依赖关系最底层的那些故事。也有可能是彼此间较少甚至没有依赖的故事,选择这些故事的目的在于,在迭代进行中可以不会因为故事之间的强依赖而发生开发或者测试依赖的问题。存在依赖关系的故事,可以放到先后不同的迭代里面来完成。
  • 可以让团队每个人都有活干。这一点的目的在于,选择出满足上一点的处于依赖最底层的故事后,还要确保能够并行开发的故事,就是每一对pair都能从迭代的第一天开始故事的开发,而不是有依赖和等待。这一点是对上一点的进一步优化。
  • 尽量可以让团队在第一迭代完成的故事。这会是一个估算的结果,但也是建立团队信心的需要。需要一个预测的点数,来成为以后估算出团队速率的基础值,这在选择第一个迭代的故事时,很重要的一个考量。

每一个迭代的计划过程,都是根据团队的实际情况,根据一些需求和因素来选择合适的故事进入开发流程。但对于第一个迭代来说,需要的考虑的因素稍微多一点。如上所述,每个因素间根据团队自己的特点和实际情况,会有所侧重,但结果期望会是一个相对正确的选择。

物理墙和虚拟墙之争

在敏捷开发中,故事墙作为information radiator,在支撑整个软件团队的日常开发,可视化开发进度和开发中出现的问题,起到非常重要的作用。团队的开发状态和进度,在任何时刻,你只需要抬一抬头,就可以一目了然:当前谁在开发什么任务,是否有闲置的资源,开发和测试的工作分配是否合理,是否有过量的Bug等待修复,不一而足。

虚拟的电子故事墙也应运而生,比如Mingle和TFS,还有一些开源的产品经过改造后,也可以极度模拟实际的物理墙界面,并更加容易创建和编辑并删除。尤其在保存开发过程历史方面,比起物理墙有着得天独厚的好处。物理墙基本上只关注当前迭代的进程,在每次进入新的迭代,物理墙更新,上一迭代的故事卡片被回收或者遗弃,难以定位和回顾。虚拟墙因为信息化的本质,更容易搜索和存档,保留快照。此外,电子故事墙在统计和制作图表方面的功能,更是物理墙无法企及的。电子墙可以随着故事卡的挪动,动态算出当前状态下的各种数据,并渲染对应的实时更新的图表,为团队和客户提供数据和可视化方面的决策支持。更重要的,虚拟墙天生支持分布式开发,因为地区甚至时区有差异的团队,如果需要共用一个故事墙时,唯一的选择只能是虚拟墙,每一方团队都能看到时刻最新的故事墙状态。

如何解决好两者之间的关系,在ThoughtWorks内部以及客户的现场,我们都遇到了类似的问题。一般来说,团队自身或者开发者们更喜欢物理墙多一点,感受直观,把注意力和时间都聚焦在故事卡对应的任务本身,而不是被动地吸引在虚拟墙软件自身以及如何学习使用并挪动虚拟墙上的电子卡上(你会看见在站会时,每一位开发人员在挪动电子卡时会有多么奇怪而有趣的事情发生),对他们是更重要的事情。而对于团队的PM或者stakeholder们来说,虚拟墙可以远程打开,开发状态一目了然,更不用提统计和图表所提供的支持。

很多团队会选择两者都采用,但不得不问到以谁为主以及如何同步的问题。以谁为主还是比较好解决,物理墙面向开发团队,虚拟墙面向管理者和stakeholder们。所以最大的问题在于如何保持两者之间的数据同步。说白了就是,物理墙上的故事卡挪动,要及时在虚拟墙上反映出来,尤其虚拟墙软件对于故事卡的每一步挪动都会记录相应的数据变化,从而为精细的图表和统计提供数据,这样物理墙和虚拟墙之间的故事卡数据同步显得尤为重要。但现实情况和经验表明,数据同步做得很不如人意,开发者的关注点在物理墙,往往容易忘记及时更新虚拟墙上的故事卡,他们甚至对于这样一件重复的事情感到愤怒。而如果由PM每天下班前对两个故事墙做同步,又显得无聊之极。

怎么办?我更相信鱼和熊掌不可兼得,对于一个团队,如果既要享受物理墙带来的可视化和信息辐射的好处,又需要虚拟墙带来的强大的编辑、统计以及图表功能,就不得不去承担因为同步二者的故事卡数据所带来的辛苦甚至是痛苦。选择团队的开发人员来各自负责同步两个墙之间的数据,还是由PM每天找一个正确的时间来同步,都是由团队自己来决定,至少我们是这么做的。你还有其他的办法吗?

测试向敏捷要什么?

敏捷软件开发与其他软件开发方法学最大的区别,在于敏捷是承认并拥抱变化的。为了这样的变化,敏捷的不同方法,比如极限编程、Scrum引入不同的技术实践和流程,像持续集成、测试驱动开发以及短迭代周期等,来确保即使在需求的快速变化下,也能保证交付的软件总是满足用户的需求,是高质量的价值交付。

从敏捷软件开发宣言来看,并没有涉及测试的内容,更不用提为QA即测试人员提供指导性的建议。就是以极限编程的14个推荐实践来看,表面上对于测试的提及也只是验收测试,甚至没有敏捷测试这个概念。这样让很多人一度认为敏捷软件开发是不是之以程序开发为导向的,是不是我们测试人员能从敏捷获得的直接支持少之又少,我们是不是被遗忘的一个种群?

答案必然是否定的。还以极限编程为例,除了验收测试以外,极限编程提及的完整团队、用户故事、短交付周期、持续集成等实践,都在从不同的维度对于测试工作的流程和方式甚至对它思考的角度提出了变化的要求。

完整团队从文化氛围和组织结构上明显区别与过往的测试人员参与感,测试人员不再是对软件系统质量负责的唯一角色,对质量负责的是全体团队成员的职责。用户故事改变以前对于软件系统功能和模块的划分,而是从交付的独立价值出发,改变了测试人员对于测试案例准备和验收的方法。短交付周期,无论是两周还是四周,都给整个团队带来了巨大的变化,开发和测试不再是独立而又顺序的过程,开发和测试互相穿插,成为一个快速反馈的过程。持续集成是软件系统开发过程的晴雨表,其中价值相当大的自动化测试仍然和我们的测试工作脱不了干系。

可见,敏捷和它的方法,虽然没有显式地给测试工作以指导建议,但隐式地要求了我们测试人员仔细思考测试本身在敏捷项目中所需要发生的变化,我们测试人员的职责和工作范畴发生了哪些变化。

与敏捷开发一样,敏捷测试针对不同的项目上下文和不同的团队组成和背景,有不同的适配模式。跟敏捷软件开发的宣言类似,敏捷测试也有一系列可以恪守的原则。经过不断实践和经验,ThoughtWorks的同事同样提出了《敏捷测试宣言》:

  1. Collaborative ownership over detached objectivity
  2. Targeted automation over widespread anti-regression
  3. Defect prevention over defect reporting
  4. Exploratory testing over predetermined scripting

第一点与完整团队有关。虽然独立的测试团队可以从外部视角观察软件质量,但真正的软件质量来自测试人员属于一部分的完整团队,不再区分彼此的开发团队和测试团队,不再有彼此分离的目标。整个团队为软件质量和客户价值共同负责。

第二点针对性自动化测试胜过广泛的回归测试。随着软件系统开发的进展,后期引入的新功能和缺陷都会带来大量和重复的回归测试,自动化测试是代替人工繁琐而无聊的回归测试的唯一办法。

第三点提到的如何对待缺陷恐怕是时下各个测试团队最为纠结的内容了。预防缺陷胜过报告缺陷,预防缺陷才是测试工作最大的价值所在。敏捷测试会尽早介入软件系统的开发过程,和业务分析师、客户分析需求和价值所在,以用户故事和验收条件来驱动开发,以短周期迭代和持续集成为反馈,可以尽早发现存在的缺陷,从而极大降低后期才报告以及修复缺陷所带来的高额成本。在我的团队,测试人员甚至可以和开发人员结对,共同确认缺陷根源,修复缺陷,并添加自动化测试确保缺陷不会再次发生。

第四点的探索性测试的重要性没有人会怀疑,测试人员可以凭借自己的经验积极、自由地发现质量问题,而不仅仅是反复运行已经定义好的测试。这样可以证明软件不仅仅做了它该做的事情,还证明软件没有做它不该做的事情。

为什么TDD?

1. 反映真实需求

这里存在先写测试和后写测试的区别。

先说后写测试。根据很多经验,在直接写产品实现代码时,需要考虑需求,同时需要兼顾实现的细节,用什么算法和语法。在对需求和考虑和实现细节间来回,很容易让人产生对其中一方的疏忽,遗漏掉一些需求方面,甚至在实现上存在缺陷。

有人会说我可以通过后写测试来保证。第一经验是,很多人都不会在实现完成后,补充测试,因为还有更多的工作和需求需要实现。第二是开发人员很容易在后补的测试中,只是试图去测试他已有的实现,而不是需求本身,很容易遗漏掉一些边界检查之类,在测试时,已有的实现细节会在脑子里面先入为主,即使实现存在问题或有漏洞,也很难在后补的测试中测出来。我阅读过很多面试者的测试代码,很明显都是后补的,因为一些很明显的问题没有测出来,甚至已经实现的逻辑也是只测试了一部分。而这些面试者都承认。

结果就是,一旦代码签入,开始集成之后,暴露出问题,后补的测试起不到对于实现代码的保障需求的作用,开发者不能不借助调试工具,单步跟踪实现代码的每一行去寻找问题发生的原因。

再说先写测试。按照TDD的流程,先写失败的测试,再写恰好让测试成功的实现代码,最后重构,如此往复。这样的好处在于,每先写一个测试,都是在试图用自己对问题和需求的理解,来定义实现代码的架子。从测试的不同角度,范围、边界、大小、功能等等,来定义实现代码将来会是个什么样子。一个测试接着一个测试,利用TDD的过程,把实现代码恰好不多不少,正好驱动出解决这个需求和问题的实现代码来。

这里的重点在于,先写测试可以让开发者把重点放在理解需求和实现需求上,而不是一开始就陷入实现的细节中同时兼顾需求,掉入两者都兼顾不好的境地。先写的测试代码,作为副产品,可以作为验证需求的得力保障。

2. 设计在其中

先写测试对于设计的好处在于,先写测试先定义新的类,以及定义类与类之间的关系,就是在定义类与类之间如何交互,每个类如何暴露自己的接口,类和类之间的引用关系。这时,测试代码会逼迫开发者认真考虑如何分解类与类之间的耦合关系,这样产生的实现代码更容易利用了IoC和DIP的模式,实现面向接口编程。

这样实现代码的好处还在于,代码的可测试性很高,在加入更多的测试代码和新类的时候,同样借力于已有类的面向接口和依赖反转所带来的可测试性,达到新实现代码的面向接口和可测试性,这样进入良性循环。而这对于整体的代码和设计,获益良多。换句话说,测试即设计。

回头看后写测试的情况,因为从一开始开发者把重心放在实现的细节和功能需求的往复上,对于代码设计、类的关系和定义很容易疏于考虑,产生的结果可能是耦合紧,可测试性差。

3. 增强信心

在我看来,软件开发周期、软件交付最大的问题在于交付后的运行和维护阶段,正是这个阶段才是软件在持续交付价值的时期。在软件的可维护性,在这个阶段凸显价值。在软件交付后,包括软件开发周期期间,不可避免的就是开发者在根据新的需求,逐渐添加新的功能代码,或者修复一些已知的缺陷。

很多经验表明,在开发者按照需求添加一些新的代码进入系统,或者试图修复已有缺陷时,很容易导致既有功能出错,也就是新引入的代码打破了既有代码的逻辑,导致回归问题的出现。因为软件系统的可测试性差,无法做到快速频繁自动的回归测试,带来的可维护性自然也很差。

而作为TDD的副产品之一——可以快速频繁自动运行的测试代码,可以在开发者新引入代码之际,给予开发者足够的信心,每次添加一点新代码,一个方法,一个类,都已频繁运行已有相关的测试代码,来确保新引入代码不会打破已有的功能。

在持续集成中,这些测试代码可以帮助验证每次签入的代码都不会破坏掉已有的功能。这也是《重构》里面反复提到的在每个重构小步骤后都要运行所有的测试代码的原因所在。

4. 粒度和进度

按照TDD的原则,先写测试,可以让开发者在同一时间只关注在功能需求的一小部分,把功能需求且分到一定小的粒度,用测试代码去表示这样的需求,用实现代码让测试通过,实现这样的需求,然后重构。

这样的好处在于,开发者自己的注意力和重心不用在整个功能需求内的小需求点之间犹豫,每次注重解决单个小问题,解决完一个进入下一个小问题的解决。在保证小粒度实现的同时,保证进度可以随时被打断,但同时被打断时已经做完的是完整可以运行,至少是实现了部分需求的实现代码。

而后写测试的代价是,首先实现代码很有可能包含设计上的问题,甚至含有缺陷,在完美的测试代码完成之前(事实上这是不可能的),可以交付的是可能存在严重缺陷,甚至是曲解了功能需求的实现代码。

Team的一次Code Kata

上周四的中午饭后,我们team坐下来完成了一次Code Kata练习。跟之前的几次邀请PwC team同事过来pair和coach不同,这次是我们组自己内部完成一次练习,题目来自Yuheng之前的一个练习:文曲星上的猜数字游戏。

题目规则很简单:

  1. 游戏开始后,系统会随机给出四个不重复的数字。由用户输入自己猜测的四个数字。
  2. 如果数字猜对而且位置也对,就是1一个A。
  3. 如果数字猜对但位置不对,就是一个B。
  4. 返回结果是如“2A1B”这样的字串。
  5. 猜错6次,游戏提示结束。重来。

开始提出的要求简单:用TDD驱动出实际代码。

大家抽签后开始pair,Yuheng还会一边计时一边催促,pair的气氛基本保持紧张有序。

在我和XuChen pair开始代码后,我们很容易写出第一个测试1,期望返回结果是”4A0B”,最简单的代码实现让测试变绿。

当我们试图写下第二个测试2,试图期望返回结果是“2A1B”时,我们发现不得不面对如何这个游戏规则的最核心算法,但可惜的是,猛然间对这个算法没有头绪。

局面一时僵住,停顿了有两分钟。

直觉和一点经验告诉我们,这时该拆解任务了。很容易想到,如果计算出几个A和几个B是很直白的拆分。

我们可以很容易写出一个测试3,测试猜测的四个数字跟事先给定的四个数字相比,有几个A类数字(循环比较),我们称之为perfect number。

也很容易写出另外一个测试4,测试猜测的四个数字跟事先给定的四个数字相比,有几个B类数字(在上个算法的基础上再循环比较),我们称之为good number。

写完针对测试3和4的实现代码,我们发现我们已经完成了最基本的算法,功能完成了。剩下的是重构代码。

从我们这次的经验看,我有一些收获和心得:

  1. 测试就是代码的设计,你看测试3和4导致的结果就是我们有了对应的两个计算方法。你打算怎么测,你的实现代码就会是怎样的。
  2. 印证了在Wikipedia中那段话,pair programming尤其适合面对一些challenging的任务(至少开始的时候是)。
  3. 分解任务是王道。我们在不同的level拆分任务,从story拆分成task,从大问题拆分成小问题,莫不如是。
  4. 囿于经验,不期望由端到端的测试能逐步甚至一下子推导出完整、完善的代码实现。而这样的练习,恰恰是我们锻造自己经验必不可少的过程。

我们在实现代码时,仍然欠缺的是:

  1. 对于测试方法名的命名,不够清晰直白。
  2. 对于算法代码的实现,简单粗糙,还需要重构。

为什么要结对编程?

以下内容摘自myThoughtWorks中对于结对编程(Pair Programming)的讨论。

结对编程与非结对编程相比那个效率会更高?

这个问题没有一个明确的答案,没有人可以很肯定的说结对编程就是会比非结对编程更有效率。效率不单单是时间,还包含效果。

如 果对于一个技术难度不高,一个人几天就可以搞定,后期不需要维护的一个小项目来说可能结对编程在效率上会低于非结对编程。但是我们twer是关注代码质量 的,面临的项目一般都是需要持续发展,而且是具有一定规模的。对于这样的项目和我们,从长远来看,结对编程会带给我们长足的发展和更高的效率。对于这点我 总结了如下几点(欢迎补充):

  1. 代码质量。结对编程与非结对编程相比,往往更加容易写出更短 的代码,做出更好的设计,产生的更少的bug。俗话说三个臭皮匠顶过一个诸葛亮,每个人的思维 都是有瓶颈的,两个人的合作通常会考虑更多的设计选项,达成更简单,更易维护的设计。研究发现结对编程bug率降低会15%到50%,这个会根据程序员的 经验以及任务的复杂度而不同,这样就会大大减少以后修bug的时间,降低维护成本。这样我们才敢一个项目只有一个QA或者没有QA呀!
  2. 互相督促。 在结对编程的过程中我们可以相互督促,比如严格去TDD减少裸奔,提高注意力避免一个人注意力不集中或者花时间上网处理个人事宜,避免偷工减料 等等,从而也可以在某种程度上保证我们的代码质量。而且人们更不愿意打断两个结对编程的人,而单独工作的人却容易被打断,这样也增加了我们专注工作的时 间。
  3. 知识共享。在结对编程我们是知识共享的,还有我们会不停的switch pair,轮流与团队中的所有其他程序员结对编程,而不是仅与某个程序员编程,使得系统的知识在整个团队中传播,减少了程序员休假或者离开团队带来的风险,从而可以保证我们项目的可持续发展。
  4. 新人成长。 这是结对编程很重要的一个作用。曾经听大大说过,他和大熊发现,在别的公司毕业刚刚一年的毕业生在项目中可以承担的还很少,但是在我们公司很多 人已经成为了项目的骨干。这很大程度上要归功于结对。当新员工进入一个项目的时候,我们往往会安排有经验的老员工去跟他们结对,这样新员工可以更快熟悉项 目情况,更快的进入状态,更快的发现自己的不足,也可以学到更多的东西,更快的成长起来为项目做出贡献。
  5. 沟通能力。结对编程需要两个人一起讨论,一起把一件事情做完,也是对我们沟通能力的一种锻炼。让我们不再是很多人眼中只会闷头写代码的木讷的程序员了。
  6. 结对可以省钱http://www.infoq.com/cn/news/2009/06/dollar-value-of-pair-programming
  7. 徐昊说结对还可以Simple Designhttp://blog.vincentx.info/2007/03/agile-101-pair-programming-simple-design/

Mock, Stub, Fake

上次郑晔给大家做游戏,徐昊问到台上的咨询师,Mock、Stub和Fake的区别是什么?

自己虽然心里有点印象,但还是下来搜了一下:

Wikipedia的解释是这样:

Some authors[1] draw a distinction between fake and mock objects. Fakes are the simpler of the two, simply implementing the same interface as the object that they represent and returning pre-arranged responses. Thus a fake object merely provides a set of method stubs.

In the book “The Art of Unit Testing”[2] mocks are described as a fake object that helps decide if a test failed or passed, by verifying if an interaction on an object occurred or not. Everything else is defined as a stub. In that book, “Fakes” are anything that is not real. Based on their usage, they are either stubs or mocks.

Mock objects in this sense do a little more: their method implementations contain assertions of their own. This means that a true mock, in this sense, will examine the context of each call— perhaps checking the order in which its methods are called, perhaps performing tests on the data passed into the method calls as arguments.

这里还有StackOverFlow的回答

扩展阅读:

ThoughtWorks有什么不同?

仅仅入职两个月时间,就试图看清楚说明白新入职公司的不同,注定是浅陋的。但是这并不妨碍我说出目前我心目中的ThoughtWorks。

昨天和前同事聊天,被问起了ThoughtWorks跟之前公司有哪些不同的地方。我想了想说,你所知道的敏捷的全部,在ThoughtWorks都能找到;没有拖沓碎叨更像是status update的standup; 我看到了自组织的团队,每个人都在团队中承担自己的职责,自信且淡定;扁平的层级文化,没有看不到头的title层次,可以把精力聚焦在项目上和自己感兴趣的事情上;可以向整个公司发邮件,表达自己的担心和困惑,评论社会现实,公司的老大也会加入进来讨论;可以让自己承担起公司主人的角色,为公司的发展做出自己的努力和影响;还有ThoughtWorks对于利用软件和技术改善人类生活的社会责任的担当;ThoughtWorks一直致力于用最先进的技术和方法来帮助客户,这会让做技术的人很high。这些在别的公司都是很难见到的。

我之前的工作经历很有代表性,先是一家国内大型软件企业,然后是一家大型外资企业,这样的经历让我有在不同企业背景和文化下的体验,也让我现在有了相对的参照系,来比较现在所在的环境——ThoughtWorks有什么不同。

如果答案仅仅止步于上面那些不同,我想这是肤浅的。是什么造就了这些以及更多的不同?有一些线索可以帮助理清楚:

在TWI上徐昊提到了Martin Fowler写的一篇博客,讲的就是ThoughtWorks是Roy的社会化实践。Roy希望借这场实践来证明那些认定下面结论的观点是错误的:

  • 你的公司不可能只由能力强的人们组成,必须存在能力差别
  • 能力强的人往往无法合作
  • 大型公司必须有强有力的管理结构,以避免分崩离析
  • 不可能为考虑长远而做事
  • 成为国际化公司是为了利用欠发达国家的人才
  • 不能暴露自己的弱点,尤其对于公司外
  • 不要赋予员工权利,否则会被滥用而伤害公司
  • 文化是次要的,你需要一个优越的商业模型

“社会化实践”,是不是挺震撼的?事实是,ThoughtWorks的确在全球网罗到了一批才能很高的人,在共同致力发展这个公司,守护这样的文化。我们成为了Roy的实验品,但软件这个特殊的行业,工程师这个简单又复杂的职业,这样一群人,的确在印证着Roy的实验趋向成功。

另外还有一篇文章《为什么我要把公司做成扁平型》,作者是37signals的创始人之一,他讲述了公司确实发生过的事情,当试图为一些资深员工创造一个管理职位和职务来发展时,遇到的问题和冲突。经验证明,让团队自己管理自己是效率更高的方式,因为的确有这样的一些人,不介意有那样垂直发展的梯子供自己攀爬。

最后是今天看到的米高写的一篇《全面成功》,这跟我在团队同事那里听到的一样。怎样定义项目的成功,只顺利结项拿到款是肤浅和单薄的。客户满意,项目质量高,团队得到发展,不一而足。ThoughtWorks的文化追求,也导致了全面成功是每个项目组的诉求。在这样的环境下,团队才会是自组织的,个人最后也才是充实和成功的。

DevOps之Puppet

Puppet在一款自动化系统配置管理的工具,它可以让你在很短的时间内对大量硬件和系统基本类似的系统,进行统一的系统配置管理。

说的简单点,就像开网吧,你需要对网吧的每一台机器安装操作系统,配置完全一样的软件,比如QQ和360,供网友上网,在系统和软件有损坏时,很简单的一个恢复操作就可以让机器回到刚刚安装好操作系统和软件的状态。

Puppet就是可以干这个事儿的,不同在于,Puppet是给网络管理员用的,而针对的系统多是*nix系统,因为Puppet目前对Windows支持的很少,但这不妨碍Puppet成为DevOps实现过程中的利器,另外一个类似的工具是Chef

Puppet本身基于Ruby实现,但即使没有Ruby的经验也没甚大碍。Puppet自己提出了所谓Puppet Language,是一种DSL(Domain Specific Language)语言,用直白而描述性的语言,定义系统应该具有的状态,比如一个简单的例子tmpfile.pp:

file { 'testfile':  
    path => '/tmp/testfile',
    ensure  => present,
    mode    => 0640,
    content => "I'm a test file.",    
}

在安装了Puppet了机器上运行:

puppet apply tmpfile.pp

结果就会在/tmp下新增加一个testfile,内容是This is a test file。
这个例子太简单。除了file这种类型外,Puppet提供了大量的资源类型,供对系统的状态进行描述,比如打开(如果不存在会自动下载)某项服务,自动增加一个用户。当管理的机器成百上千,这样的自动化服务达到的效果就很可观了。

puppet apply是Puppet在单机上运行和测试的工具,真实的使用情景会是,一台机器(master)专门保留所有机器配置管理的状态信息,而每台机器(agent)会在指定的时间向master发起查询,从而更新自己的系统状态,以期与指定状态保持一致。

 

 

DevOps是什么?

DevOps是什么?

devops is an emerging set of principles, methods and practices for communication, collaboration and integration between software development (application/software engineering) and IT operations (systems administration/infrastructure) professionals. It has developed in response to the emerging understanding of the interdependence and importance of both the development and operations disciplines in meeting an organization’s goal of rapidly producing software products and services.

— from Wikipedia, http://en.wikipedia.org/wiki/Devops

简单的说,DevOps是一组原则、方法和实践的集合,用来改善软件研发和IT运维之间的沟通、协作和集成,从而让软件产品和服务以更快的速度发布。

这里的快不是真正的目的,真的目的在于终端用户不会察觉到快速交付带来的不爽(质量、性能、安全性变差),而是享受到版本变化带来的更优质服务,这样才能让软件企业立于不败之地。至于为什么要快,我不说,你懂的。

一边要快,一边要稳定。说到稳定,就没法把运维避开不谈了。所以DevOps就是试图消除软件研发和运维之间的壁垒,让二者结合为更高效的软件交付团队。

DevOps涉及到什么?

DevOps是基于Agile的理念,并试图用Agile去影响其他部门、团队和实践。这里涉及到Agile和Lean中各式各样试图提高效率、消除浪费而采取的过程式、理念式、工具式的实践。可以包含但不限于以下内容:

  • 让开发人员和运维人员交叉参加部门会议
  • 让开发环境与运维环境保持一致
  • 自动化任何运维过程可以自动化的过程

如果有人或者公司说,用了我们的blabla产品,就是DevOps了,这只会引来明白人的窃笑。这个效果,基本和说我们每天都Stand Up所以我们就是敏捷也可以跳舞一样可笑。

在我看来,实施DevOps最后要面临和解决的依然是组织和人的问题,这是文化和价值观信奉的差别,与具体的产品和项目无关。我甚至预见,DevOps因为会涉及到不同业务部门,而不像敏捷只会局限在研发单一部门内,反而更难实行。所以,可以想象,在怎样的情形甚至逼迫下,会有怎样类型的企业会去追求真正意义上的DevOps。

扩展阅读:

事关挪卡(Moving Story)

最近我的team频繁遇到关于挪卡与否的事情。

可能会包括下面其中一种情况:

  1. 一个Story在前一个迭代做完了,但是客户没有及时sign-off,导致后一迭代中客户发现Sotry实现有问题,不是自己想要的东西,需要重新实现。
  2. 一个Story在前一个迭代做完了,客户已经sign-off,但在后一迭代中我们发现实现中设计有问题,会引发其他的bug。
  3. 一个Story在迭代中实现完毕,进入In QA,但发现有重要的AC没有事先提出来,导致需要补充实现。

可能还会包括其他可能的情况,不一一列举了。

我们team的对策分别是:

  1. 新开一个Story卡,对有问题的部分重新实现。这里的问题在于没有及时从客户那里取得反馈,原因自然有多种,你懂的。
  2. 新开Defect卡,对发现的问题进行修复。
  3. 直接在当前迭代中,把Story卡挪回In Dev,补充实现。但不会修改点数。

OO训练营第四五课

徐X语录:

Design Pattern是针对特定问题的特定解决方案。

是问题,而不是解决方案定义了Pattern。

模式之间存在相似性,比如Adapter和Bridge模式,只是量的差别。

先让问题再想着怎么解决 over 想清楚什么问题再下手。

面向接口编程破坏了Communication和Technical之间的平衡。会带来Communication debt。

真的需要抽取借口时,需要两个条件:1. Concret Class;2. Consumer for Interface

没有bad smell就不要重构。

Pair的节奏

这篇只想说说我对Pair节奏的理解。

Pair是需要节奏的,为什么?最简单的回答是,没有节奏,两个人都会很累。我有体会,跟team另一个新TWer一起pair,两个人会不由自主地坐在屏幕前,切分任务,你写测试我写实现,一动不动坐了整个下午,除了上厕所的时间。可想而知,离开办公室的时候那个疲惫。

不是说Pair就会比一个人“裸奔”轻松,恰恰相反,Pair就会比较累,这是无数人经验证明的。但是我们仍然需要在Pair时控制一定的节奏,不仅仅是为了减轻疲劳。

最直觉的反应是,疲劳会影响对问题的考虑,测试的覆盖度,代码的质量,这在一对Pair都疲劳的状态下,也不能免俗。当疲劳把Pair能带来的那些个好处统统赶跑后,Pair还有何存在的意义?

一般来说,对Pair经验比较少的人,节奏可以由Pair经验多的人来控制,如何划分任务,粒度以及驱动测试开发的频度如何,都可以依据Pair的双方的能力和经验对比进行安排。在划分任务和思考时,可以以提问的形式,互相提问回答,推动进度。实现代码时,可以以乒乓的形式,由一方来编写测试,另一方编写实现,并跨任务轮换,让双方都感觉到Story的实现在有条不紊地前进,充满自信。双方可以约定在一个小时左右的时间,进行一次短暂的休息,切换context,以确保有持续的精力投入后续的Pair。

因为Pair是两个人的事情,当一方因为某种原因感觉到疲劳,或者被第三方事情打扰,不能集中精力在pair中时,可以主动跟对方提出中断,以换取集中的注意力在Pair上。

如果Pair对于某个问题或技术都不熟悉,并且在可遇见的时间内无法解决,应该立即寻求有经验同事的帮助,或者暂时放下留待后期解决,坚持钻牛角尖无疑是破快Pair节奏的杀手之一。就我的经验看,Pair时钻牛角尖的几率很小,在一方出现端倪时,对方会明显感觉到并主动提出来跳出这个圈子,这应该时Pair时一个小小的好处吧。

至于可能破坏Pair节奏的另外一个杀手——两人就问题或技术有争执,一般会发上在没有较多Pair经验的人身上,这会是另外一个话题,涉及到Simple Design,徐叉教导我们,要用代码证明自己的观点,要反过来关注问题本身。