标签归档:Agile

形形色色的CI Monitor

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

下面是Go的CI Monitor界面:

tw_go

继续阅读形形色色的CI Monitor

物理墙和虚拟墙之争

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

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

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

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

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

为什么TDD?

1. 反映真实需求

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

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

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

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

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

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

2. 设计在其中

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

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

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

3. 增强信心

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

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

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

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

4. 粒度和进度

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

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

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

为什么要结对编程?

以下内容摘自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/

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,徐叉教导我们,要用代码证明自己的观点,要反过来关注问题本身。

Pair时的心态

为什么我们需要pair programming,以及pair有什么好处,不是这篇文章要说的内容,关于这些方面,网上能找到的太多太多。这篇只是想说说对于pair中心态的问题,我在pair时的体会。

对于有过开发经验的人来说,离开几年来一直专属自己的那个格子间,坐到一张开放会议桌边写代码,旁边还坐着自己的pair,度过半天甚至一天的开发旅程,并不见得都是一帆风顺的过程。

每个人有自己的开发经验、背景和知识,成为pair就要为Story的代码质量负责。怎样合力以解决问题产生代码,是需要彼此Open心态,针对问题解决问题,而不是:

  1. 妄自尊大,容纳不下对方的观点
  2. 对对方不闻不问自顾自操作机器
  3. 炫耀自己的知识面而鄙视对方
  4. 甚至出言不逊,伤了对方还浑然不知

这是一个成长的过程,也是一个自我剖析让自己更open的过程。所以我们一般会安排由具有丰富pair经验的老同事带着新同事一块来pair,还会有乒乓和keyboard-mouse方式来控制pair的节奏。在知识传递的同时,逐渐打开每个人闭锁自我的心态,逐步提高pair的效率从而提高team的velocity。

从小处看,这是个人心态改变的过程,从大处看,这是开发文化不同导致的诉求。

OO训练营第二三课

这两节课徐X给出的问题是,用代码表达在停车场停车的模型和逻辑。

首先,还是任务分解。分解出任务列表的样子,取决于对程序架构的理解。理解不同,导致划分出来的任务列表也不一致。但要保证每个任务能够衍生出1-2条可以测试的子任务,变成代码。对于测试任务的设计,既可以从状态变化上来考虑,也可以从行为上来考虑。而且,由分解出来的任务列表,可以反推出需求是什么。

课上有一对pair最后没有完成测试及实现代码,原因在于双方对各自的实现方案争执不下,被徐X拿来教导我们:在这种情况下,要放下争执,去还原真实的业务场景和需求是什么,来解决实际的问题。

总会有分别都是正确观点的双方在争执,就像民主之于正义。这个时候我们要evidence over opinion,通过代码来表达自己的观点。

最后,徐X再度施展重构神技。

TWI is Over

Today, we finished 3-day TWI(ThoughtWorks Immension) in ThoughtWorks China, which is also the sixth TWI here.

4 people from Xi’an office also came with us, and we spent a good time together. I have now a deep impression on the company culture, Agile Methodology, and a more closer observation on the story things and xp practices. All of what we saw and heard differentiate a lot from what we did before in a more traditional way. This introduced too much dicussion and questions, which even blocked the progress of courses.

Good to see this happened, when TW China grows up and attract more and more experienced people, it has to embrace and absorb those who are willing to join after survived from bad software engineering career, with its own special culture. I believe these people are here not wishing to get satisfying salary or anything, but to see how and why software engineering works here and people are happy at the same time.

I am shocked totally when teacher told ThoughtWorks company is actually a social experiment by Roy Singham, founder of company. I believe I will be shocked time and time when I understand more about company.

I am very pleasure to be the witness for this experiment is ongoing, and hopefully it will be successful.

Pair小记3——争论

Team的人员组成各不相同,有可能是经验丰富的团队,也有可能有将近半数的新人。这样对于有交付压力的项目来说,采用怎样的技术栈会有不同的观点。有保守起见,不愿意引入复杂框架的观点,也有要努力利用成熟框架学习新技能的想法,何去何从?

Well,这是一个team,自组织的团队,区别在于这样的争论可以让整个team的人来加入来选择,来承担可能好可能坏的结果。

更有帮助的是,可以咨询具备丰富实践经验的来自团队外的专家。然后还是由团队自己来决定。

自组织的团队让我很消受,Who is Boss? Who care!

Pair小记2

今天Pair遇到的问题是,我跟我的Pair在某一个问题上纠结太久,没能找到解决的方案。这是一个很典型的问题。

浏览器兼容的问题,历来让前端开发头疼。再加上是遗留系统,页面上引入了太多了三方和自己的js导致IE下页面无法显示。

看得出,我的Pair对前端开发经验不多,而我又不能一下子指出问题所在(可恶的IE),Pair自信心比较高,会很坚持用自己的方式来解决,他试图修改一些JS的内容来减少业务逻辑的涉入,以测试能否在IE下显示完整。而根据我的经验,这种IE特有的问题多半是某些JS语法的(不兼容)问题,但办法只有从上到下一个一个JS的排除,直到找到问题JS。Pair的做法引入了业务逻辑变化的不确定性,背离问题本身,反而容易引入更复杂的变化。

可惜我对Pair时所应有的态度和精神体会不深,尝试过说服Pair,但见他坚持,不忍冲突,结果是时间白白浪费。

回家路上跟彦辉君聊到此事,他的建议是:
1. 寻求技术帮助
2. 正义提出自己的想法
3. 如果2不可行,寻找更具说服力的力量

还是需要一种Open的态度。

Pair小记

今天跟凡哥pair,遭遇CXF的蹂躏。客户遗留系统糅杂了JAXB,CXF诸多Java EE和web service“高端”特性,调试很难,好不容易找到负责(反)序列化的XmlAdapter实现,才看到遗留系统工程师编写的奇怪正则表达式,过滤了本不该过滤的字符串,导致web service接收端接收数据不完整。

一边pair,一边感叹,Java的企业应用现在如此复杂,Java技术发展已经背离了最初解决问题的初衷。Java出路在哪里呢?