《程序员》9期精彩文章推荐:敏捷和工具

标签: 敏捷 选题策划 工具 | 发表时间:2011-08-30 11:04 | 作者:chenqiuge nikelius
出处:http://www.programmer.com.cn

文 / 蔡煜

敏捷软件开发绝不再是一个新名词了,但理解还是时时有偏差。敏捷宣言中的第一条“个体和互动高于流程和工具”,有人就误读为“有了沟通,一切都迎刃而解” ,因此花费大量精力整顿团队合作,却轻视了工具(技术)。其实宣言中的意思只是想强调个人和沟通更重要而已。

实际上,既然是软件开发,在所难免得面临工具的选择,而且很多优秀软件实践离开强有力的工具支持都玩不转。在如今的软件开发世界中,工具(这里谈的是软件工具)层出不穷,数不胜数,那么到底该怎么去选择适合的工具呢?

本文将根据我十几年的企业级软件开发经验给出一点建议,和大家一起来探讨敏捷和工具(特别是在企业实施中的工具)这个话题。

为了避免不必要的麻烦,文中尽量用开源软件作为介绍,但这并不是说我排斥商业软件,恰恰相反,在很多时候,只有商业软件才提供了你需要的功能(当然大部分情况下开源软件会很快迎头赶上)。

背景知识:应用程序生命周期管理

聊到软件开发中的工具,一般都会提到这个术语“应用程序生命周期管理(Application Lifecycle Management ,ALM)” ,说句老实话,有点烂,谁都想把自己往上靠,谁都有自己的一套说法,图1为我心中贯穿企业开发项目全程的ALM全局观。

图1中列出了ALM中的各个子系统,以及我略有研究的相对应工具的名称,让我们一起先来简单地过一遍整个过程。

1

图1 开发项目中应用程序生命周期管理及其工具

产品开发始于一定的需求,需求有好几个层次,从产品需求到项目需求,进而产生出用户故事(User Story), 然后团队会分解出任务(Task)。团队开发者利用IDE(如Eclipse)去完成相应的代码,单元测试完成后,再推送到代码库(git),这些和软件配置管理(Software Configuration Management,SCM)相关。

构建系统会从代码库中获取最新的代码,进行编译、打包、功能测试和系统测试,可以设置在质量系统中显示一些相关信息,如果一切顺利,甚至能直接上传到在线系统更新上线。此外不管是开发中还是运行中一般还都会有一个缺陷管理系统。

BugZilla大家应该很熟悉了,用Redmine的人少一些,但它实际上是一个非常灵活的项目管理系统,国内也有越来越多的公司在使用了,Nexus是一个Java软件包的管理工具,需要和Maven结合使用,Sonar是一个Java项目的质量控制工具,它集成了如单元测试、覆盖率、静态质量检查等内容。为什么任务管理下的Redmine有红叉呢?我们稍后会解释。

限于篇幅,本文只会谈到其中的一部分工具。作为参考,可以阅读Manning出版社的新书《Agile ALM》,它对SCM、单元测试、功能测试等话题进行了更深入的探讨。

敏捷中有些工具是必需的

如果你说敏捷实施大半年了,但持续集成 (Continuous Integration,CI)服务器却还没有架起来,那我实在是不晓得你都在敏捷些啥东西了。无论你究竟“信仰”哪种敏捷,产品开发各个方面的自动化(Automation)和持续集成都必不可少。要了解持续集成,可以看看Martin Fowler的文章,可谓白皮书级别的经典,有中文翻译版。

2

使用CI就一定会用到CI服务器,可选的有很多,其中Jenkins是现在最流行的一个,而且架设起来也很方便。它是从Hudson继承而来(自从2011年5月Oracle决定把Hudson捐献给Eclipse组织,两者的关系和将来的发展方向也可能带来更多变数)。

在Jenkins构建服务器中,可以定义任务(在Jenkins中叫job),以完成一些构建步骤(如签出代码、编译、各种类型的测试、打包等),它有极丰富的插件(plugin)资源作为支撑,可以来集成产品软件开发的各个要素,它把你所需要的一切都自动化起来。

3

图2 Jenkins项目自己的Jenkins构建服务器

在Jenkins构建服务器的首页,每个任务还都有一个天气图标表示其状态,非常直观,例如“太阳”就代表着一切正常(至少从构建结果来看)。它是产品项目开发的晴雨表,项目状态是否正常一目了然。不管是对Jenkins不了解还是想提高,我强烈推荐阅读John Ferguson Smart的Jenkins开源书:Jenkins: The Definitive Guide。

对敏捷来说,并没有“CI服务器要还是不要”一说,它就是必须的,一定要好好地实施。基于持续集成再往前走,就是持续交付(Continuous Delivery)了,这也是敏捷的一个新热点,其中加入了很多新元素(如自动化验收测试、持续部署等)。

别让工具牵着鼻子走

工具很重要,但会不会有些误区呢?当然有,我们一起来看个我经常碰到的一个例子。

讲到敏捷实施一直都会提到白板(Whiteboard)的使用,先得提醒大家,它也是一个“工具” ,白板的其中一种用法叫任务白板,主要是提供给团队使用的。

4

图3 每日例会用的任务白板(图来自《硝烟中的Scrum和XP 》一书)

图3就是常见的任务白板,团队的需求,一般是用户故事(User Story),被放在最左边一栏“NOT CHECKED OUT”,作为团队一个迭代的输入,然后分解成任务(Task)用报事贴(俗称黄贴)贴在白板上“CHECKED OUT”那一栏,并签上自己的名字,就算是领任务啦。当做完了一个任务就把它(黄贴)挪到下一栏“DONE!:o)”,代表做完了,最右边一般还会留出部分空间,用来记录进度条和注意事项来提醒团队一些重要的事情。

如果说Jenkins构建服务器是产品开发的晴雨表,那么任务白板就是团队开发的晴雨表。

一般一大早在每日的站立会议(Daily Standup Meeting)上,整个团队所有人都会围在白板前,分享所负责任务的进度,顺便挪动一下任务到相应的状态栏,用这种方式能够减少很多不必要的汇报型会议,而且团队成员也能很快地了解开发的整体状况。相信如果某个黄贴在白板上连着三天都没动,团队里一定会有人站出来帮忙的。(没有?!那还是先组织他们参加团队合作的培训吧。)

有时候团队坐得比较分散,或者有人喜欢流行的在家办公方式,这时可能会开始使用一些图形化的电子白板来管理团队任务,大家对着屏幕介绍进度,效果似乎还不错,其他人(包括经理们)也非常高兴,因为他们可以随时从网上了解到团队的进度了。慢慢地,面对面的时间看起来也可以节省下来,只要窝在座位上点点鼠标,挪挪电子黄贴(如果支持漂亮的拖拉就更好了)就已经足够了。

这是敏捷的好实践吗?

是否嗅到了一点怪味道?它就是我想谈的工具带来的误区,电子白板会削减团队之间的沟通,降低团队的透明度,违背了敏捷重视人和团队的原则。如果你的团队成员不经常去更新电子白板上的任务时间,慢慢地你看到的都是不太准确的信息了。有人可能说我们还是面对着电子白板开每日站立会议呀,那我希望你有个很大的屏幕吧(否则这样子效果会更差)。

那为什么没说它不对呢,因为在一些场合下,它还是有作用的。关键是团队要能充分认识到它的局限性,因此我极力反对在团队组建初期用电子白板,可以等团队充分领会到敏捷中人与人沟通的重要性后再引入。

这也是在图1中特意用红叉提醒不要用Redmine来管理任务(这个白板功能的插件也很差,因为没人用)。

所以要了解你的需求,不要让一些工具牵着鼻子走,要了解敏捷实施的目的,否则出了问题还以为工具不到位,拼命要更强的功能,结果陷入大误区。

有些工具会带来意想不到的好处

传统的敏捷著述中通常会提到CI的部分,然而工具的运用并不限于此,例如我在实际项目中用到的Gerrit,它非常契合敏捷的宗旨,也给我们带来了意想不到的好处。

代码审阅是一个不错的敏捷开发实践,让人非常头疼的是实施。大企业中通常是制定出一大堆相关的规范和流程来指导代码审阅。我听说好多公司都会把代码打印出来,进行走读,这可真是累啊。这种方式会给人不信任的感觉,而且应该是挺浪费时间的。

结对编程(Pair Programming)也是非常好的一种代码审阅的方式,值得好好地学一学,只是我对它并不太感冒,体会是在大企业实行结对编程的难度很大,当然如果能找到合适的推动者,那还是可以尝试尝试的。

那看看开源社区是怎么解决这个问题的呢,使用的又是什么工具呢?Google的Android系统是现在非常热门的开源项目,它的代码审阅(包括贡献者的代码)使用的是Gerrit,非常棒的东西,在自己的企业中架设起来也非常方便,我一用就爱上它了。

Gerrit是一个基于Web的代码评审和项目管理的工具,面向基于Git版本控制系统的项目,所以如果你没用git(干嘛不用呢),就没法用Gerrit了,接下来来看看在Gerrit中怎么实施代码评审的。

● 首先开发者(贡献者)的代码变更通过 git 命令被推送(push)到Gerrit管理下的Git 版本库,推送的提交转化为一个一个的代码审核任务(见图4)。

● 代码审核者可以通过Web界面查看审核任务、代码变更,通过Web界面做出通过代码审核(Review)或者拒绝(Reject)等决定。

● 测试者(一般可以设定为CI服务器执行)可以通过访问来获取(fetch)代码变更进行相应测试,如果测试通过,就可以把这个评审任务设置为校验通过(Verified)。

● 最后经过了审核(Review)和校验(Verified)的代码变更可以通过Gerrit界面中提交动作合并到版本库的对应分支。

相比代码走读,它的好处在于,审阅动作发生在向主干提交代码前,可以只看变更的部分显得很贴心,网上随时随地审阅起来也很方便,这也是有别于结对编程的一个好处。

任何人都可以审阅提交的代码,整个团队的代码都一目了然,审阅起来更方便,非常符合开放、透明的敏捷精神。使用之后能够显著提高代码质量,甚至于等到习惯了以后,代码不被审阅一下,都觉得实在是不好意思提交代码到主干上去。

Gerrit中,通过特定分支,任何审核任务的代码变更都能访问,所以如果需要细看或是合并到本地都异常方便。

Gerrit刚开始实施可能会有点不习惯,毕竟整个工作流有所变化,因此实施时需要通盘考虑。

如上只是近期我特别喜欢的一个工具,其实类似的工具还有许许多多,这不过是沧海一粟而已。

总结

水能载舟,也能覆舟,工具和敏捷的关系亦如此,下面我给出几点建议:

● 积极尝试新工具,如今的软件开发世界中,工具层出不穷,要不断与时俱进,了解最新动向和如何用有效的工具去辅助敏捷的实施,在自己的软件开发环境中去尝试和了解这些工具,尝试这一点很重要,不要只看说明或戴有色眼睛去看待这些工具,应该通过实践摸索找到最适合你的选择。

● 人总是第一位的,要了解你的团队,了解他们的需求,有些时候甚至可以为了团队,冒险一下采用新技术、新工具,这样可以提高团队的凝聚力(敏捷要素之一)。我待过的一些部门推动Git时,就是这么来的,很多时候过多的讨论其优缺点反而是浪费时间,不如多花点时间多试试。

● 实施敏捷也离不开组织的支持,特别大型企业涉及到的人很多(可能水平不一),这时候推动者就必须用专业的手段建立一个持续渐进的工具引入过程,这样会使得实施更容易些。

● 唠叨这么多,实际上也只是讲到一些皮毛,还有很多东西需要我们继续研究下去,本文得到了《Maven实战》作者许晓斌,敏捷宣言简体中文版翻译的协调者徐毅,敏捷之旅中国组织者滕振宇和同事代鹏的帮助,他们提供了很多宝贵的意见,特此致谢!

本文选自《程序员》杂志2011年09期,更多精彩内容敬请关注09期杂志
《程序员》杂志订阅火热进行中
http://dingyue.programmer.com.cn/

本文选自《程序员》杂志2011年09期,更多精彩内容敬请关注09期杂志

《程序员》杂志订阅火热进行中

相关 [程序员 文章 工具] 推荐:

《程序员》9期精彩文章推荐:敏捷和工具

- nikelius - 《程序员》杂志官网
敏捷软件开发绝不再是一个新名词了,但理解还是时时有偏差. 敏捷宣言中的第一条“个体和互动高于流程和工具”,有人就误读为“有了沟通,一切都迎刃而解” ,因此花费大量精力整顿团队合作,却轻视了工具(技术). 其实宣言中的意思只是想强调个人和沟通更重要而已. 实际上,既然是软件开发,在所难免得面临工具的选择,而且很多优秀软件实践离开强有力的工具支持都玩不转.

程序员必读的十篇文章

- - 文章 – 伯乐在线
作为一个Java程序员和软件开发者,我从许多『关于某某每个程序员必知』这类文章中学到了很多东西,它们会就一个特定的话题给出很多有用有深度而且难以被发现的信息. 我在求知的过程中遇到过一些很有用的文章,并将它们存为书签用于日后参考和重复阅读. 个人认为所有程序员都能从中受益,这也是我写这篇文章和跟大家分享所有这些文章的原因.

Java程序员常用工具集

- - BlogJava-庄周梦蝶
    我发现很多人没办法高效地解决问题的关键原因是不熟悉工具,不熟悉工具也还罢了,甚至还不知道怎么去找工具,这个问题就大条了. 我想列下我能想到的一个Java程序员会用到的常用工具. 1.IDE: Eclipse或者 IDEA,熟悉尽可能多的快捷键,《 Eclipse常见快捷键列表》. (1) Findbugs,在release之前进行一次静态代码检查是必须的.

每个程序员都必读的10篇文章

- - Java译站
作为一名Java程序员和软件开发人员,那些 每个程序员都应该知道的XXX的文章教会了我不少东西,它们提供了某个特定领域的一些实用的并且有深度的信息,这些东西通常很难找到. 在我学习的过程中我读到过许多非常有用的文章,我把它们添加到了书签里,方便以后阅读或者引用. 我个人认为所有开发人员都能从这些文章中受益,因此我也写了篇“ 每个程序员都应该了解的”文章,准备分享给你们.

程序员高效率工作工具推荐(必备工具)

- - CSDN博客研发管理推荐文章
一、 Xshell Xftp. 免费软件 Xshell 和 Xftp 都是 NetSarang 出品的优秀网络管理、安全传输工具. Xshell 是一个免费的安全终端仿真器,可以作为 SSH、TELNET 或 RLOGIN 的终端模拟,能够从 Windows 平台安全连接 Linux 服务器,Xftp 则是安全传输客户端,支持 FTP 和 SFTP 协议,两者都支持标签化的会话窗口.

Python超级程序员使用的开发工具

- - 外刊IT评论网
我以个人的身份采访了几个顶尖的Python程序员,问了他们以下5个简单的问题:. 你在项目中使用的电脑是怎样的. 有什么给Python程序员的建议. 就是这几个问题,我找了几个顶尖的程序员和编程书籍作家,问他们这几个相同的问题. 下面是他们的回答,希望在他们的回答中你能找到一些可以让你的开发更便捷的工具.

Java程序员须知的七个日志管理工具

- - ImportNew
Splunk>Storm 日志管理工具有Splunk、Sumo Logic、LogStash、GrayLog、Loggly和PaperTrails等等,数不胜数. 日志就像石油,二十多年了我们一直想摆脱它,却一直没有做到. 为了处理日益增长的数据,近年来出现了一大批分析和管理日志的工具,开发和管理人员能够借助这些工具来了解增长的数据.

10年DotNet老程序员推荐的7个开发工具

- - 程序师
做.NET软件工作已经10年了,从程序员做到高级程序员,再到技术主管,技术总监. 见证了Visual Studio .NET 2003,Visul Studio 2005, Visual Studio Team System 2008, Visual Studio 2010 Ultimate,Visual Studio 2013一系列近5个版本的变化与亲自使用.

文章: Go语言开发工具LiteIDE

- - InfoQ cn
Go语言最初在2009年11月对外公布,在2011年3月16日发布第一个release,第一个正式版本Go1于2012年3月28日推出. 在Go语言的正式版本推出后,Eclipse、IntelliJ IDEA、vim、emacs、gedit、SublimeText2、Textmate、Textpad、SciTE、Notepad++等IDE和编辑器开始纷纷有了各自的Go语言插件.

文章: 配合SNMP实现系统监控之工具研讨

- - InfoQ cn
在大多数情况下基于SNMP的监控方式中,SNMP只是提供了各种类型的系统运行数据,但是如何整理和归纳这些数据并使之成为可读性比较高和 比较直观的信息还需要一些工具的配合以及配置. 在该连载中,我们将介绍常见的围绕着SNMP的监控解决方案的实现方法. b.snmp + mrtg实现对网络负载的监测:.