存档

文章标签 ‘agile’

倚天出笼记

2012年1月22日 2 条评论
No Gravatar

持利器,事半而功倍。所以IT界以发明各种轮子为主要乐事。若器成则功利倍,没有人可以拒绝。在开始打造我们开发的目标团队之时,虽然还是孤身一人,但对各种使用利器之法也是有所耳闻。那段时间赋闲在家,研究一些好玩的技术,算是为某些事做准备,也可以调整自己的心态,积累精神。

一、高可用的管理平台
版本管理什么的以前都比较习惯了。从CVSSVN一路走来,就是在一个人编码的时候也在使用SVN。管理方面还对比过TracRedmine。虽然一直对Python的好感多于Ruby,但是经过比较之后还是觉得Redmine更好一些。就这样,其实在加入新公司之前,各种管理工具通过选择就已经确定了以redmine/Subversion为基础。这两种工具的结合有很多优点:
* Redmine的权限管理可以于Subversion集成。
* Subversion提交的内容与Redmine的问题可以有效地连接。
* Redmine还可以提供简单的BUG管理功能。
从某种意义上来说,我是“拒绝文档控”。一直以来想鼓吹的就是没有文档的软件开发、没有说明书的软件操作方式。但是计划还是要有的,对进度的控制也要在合理的范围内。Redmine正好提供了详细的管理能力。除了可以对项目提供计划和实施管理之外,它的问题条目还可以详细或者粗略地提供开发时间的一些细节。如果可以,使用它也可以生成项目的开发或者设计文档。

二、高可用的硬件
而且那段时间一直使用Ubuntu做为Desktop,两个显示器使用起来,调代码、测试输出效率非常高。以致于当时大致每天下午可以有一两个小时出去骑会自行车散心。所以团队组建初期就提了硬件的指标,这个配置现在看来水平也不算低。每台开发用的电脑都是4核心CPU/8G内存,显示器的概算是每个人都是双显。后来因为我们还要与其他部门一块办公,大致的双显比例是1/2强。原来的开发机都是台式机,在项目逐渐增多后后续的配置都是移动性较强的笔记本了。
我在与之前一些朋友的探讨过程中,他们不是十分理解为什么配置这么好。最多的质疑是这好的配置要多花钱,但是这个说法非常经不起推敲,以一台电脑三年的预算使用期来算,就算是花费6,000元来配置一台开发用机,一年的成本也只有2000,平均到每个月只有非常少的费用。而采用好工具对开发人员带来的,恐怕用这些钱是换不来的。比如:
* 心情的舒畅
* 工作效率的提高
* 对工作条件的满意程度
没经历过用烂机器开发过程的人永远也不能懂得执行编译似卡死的时候的那种感觉,特别是项目Deadline临近。

三、敏捷的开发框架
使用敏捷框架是必然会在突发的、时间有限的项目中被采用的。特别是新团队,原始积累不够丰富的团队。
我们常用的这两个CodeIgniter/Play框架基本上都是沿着这个思路来的。
选择CI是为了将来在虚拟主机上使用。选择Play则是由于客户要求使用Java。不过我们用absiege的测试结果PHP的还要好一些。

四、模板,一定要有的模板
对于我们来说模板程序员和美工最好的沟通工具。我们的美工甚至已经可以在程序员参与之前,就可以根据需要打造好用户的界面。以至于有个项目的甲方说这个系统你们是不是设计得太简单了?这么快就做好了?
模板系统在为我们以原型驱动的开发过程打造了一个良好的基础,客户可以更好的理解我们的想法,并给我们最真实的意见反馈。
CodeIgniter里采用Smarty模板、Play里采用了自带的Grails模板,虽然还有可以同时用于Java和PHP,甚至当我们使用了Python/Ruby都可以用得上的Mustache模板系统,但是指望一个模板系统在不同的语言下都完全保持一致是不可能的。特别是Play里那些@之类。

五、Flash,IE Killer
如果愿意享受,软件开发的乐趣非常多。但是注意有很多烦恼。我们目前最大的烦恼来自于IE6。当初我们在给客户展示图表的时候,一开始使用了HighCharts,一个基于JavaScript的图表系统,在展示单个图表的时候问题不大,但是多图表展示一度让我们怀疑系统出现了致命的问题。应该说在这个问题上Flash成为了我们开发时IE6的Killer。

六、有效的工具
有效的工具我们用过的真是很多,下面几个是常用的但不限于:
* Httpfox(Web调试)
* Notepad++(HTML开发的利器)
* Piwik(用来分析客户行为)
* Netbeans
* Eclipse

我们还在打造基于node.js和d3.js的图表系统。工具的便利,让我们开发时的倚天剑日趋成熟。
利器在手,快乐我有。

生火很好,鸭梨很大

2011年11月20日 没有评论
No Gravatar

最近有些懒。比如上次关于交通拥堵问题讨论的聚会就没有写东西。因为生活有了压力。当一辆车行驶在轨道上,很多事情无法按照预想完美的实施。太多人会对你的想法有或轻或重的影响。究其原因,还是因为视界不够宽大,对事物还没有稍微全面的判断能力所致。

之前参加过一次InfoQ大连的活动,OpenSpace形式非常有特点,可以让任何人都可以从容参与,在讨论中提升自己。这次活动(敏捷之旅2011大连站暨QClub大连站2011年第三期伯薇兄可谓是费心费力,请来了ThoughtWorks的高级咨询师李剑(@凉粉小刀)、速评网的联合创始人 王立杰先生(@王立杰_敏捷无敌)和大连富达的牛人孙伟(@sagasw),还拉来了东家中荷人寿赞助,在大连IT技术圈中这火生得好。

下午InfoQ会场。

三个话题:可视化管理 (李剑)、速度与质量的均衡之道(王立杰)、使用google app engine建立个人信息中心(孙伟)涉及Team、QA、个人爱好与工作的结合,对我们这样新起步的软件开发团队来说每一条信息都是有用的。因为最近对团队建设这块感觉问题颇多,以下的话题就集中在李剑的可视化管理方面。有意思的是,中荷人寿的两位美女在间歇还教大家跳了支舞,终于是不困了:)

每次参加技术会议都会有这样的感觉,去之前的感觉是:啊,我们现在进行得还不错,你看这我们这块是如何如何,你看我们的业务开展得如何如何,似乎一切都尽在掌握,听完的时候可能就感觉种种不足,甚至一无是处。这次李剑开篇的几个问题就让我有冷汗了:故事墙有的请举手,燃尽图有的请举手。。。这些都是想有而因为种种原因而没有的,虽然道具已备,但是鸭梨来了,于是有些事情就置后了。感觉象他提到的那个装睡的人。

当一个人装睡的时候,你是很难叫醒他的。

OpenSpace环节,李剑还谈到他们现在基本上每天都要写12小时代码,每年要读30~50本书。

当我问及草创团队如何影响已有经验的开发者转向敏捷的时候,他以“以身做则”四字回答。这个我在团队刚刚组建的时候实施得很好,现在好象其它事务越来越多,现在不重视。

最后成果,开源工具、敏捷团队该看的书:

整理了一下:

开源列表:

1. Sonar

2. Cucumber

3. SQALE – Software Quality Assessment based on Lifecycle Expectations

4. jspec/Jasmine

5.

有用的书:

1. The Agile Samurai

2. Clean Code

3. 持续集成

4. 敏捷软件开发-原则、模式、实践

5. JavaScript – the good parts

6.

嗯。鸭梨又来了,这几天Eucalyptus要看,appscale要看,node.js要看,…,还要顺道看看图表方面的书,好了,生完火,鸭梨来了,鸭梨还大了吧。

晚餐:敏捷测试以及其它问题

2011年9月30日 1 条评论
No Gravatar

总是感觉需要学习的东西太多,所以喜欢参加各种技术聚会。我是一个非常好的听众。还刻西游记中佛祖座前的黄鼠、大鹏么?听也是得道的一种方式。:)

1. 引子

9.27,正是敏捷测试大师Janet Gregory来连授课的时候,被邀参与见面,并且能将自己的疑惑提出来,幸甚。因为英语不好,结果汉英夹杂的提问,多亏有李兄翻译。

我去年10.29日正式组建的这个部门,在近满一年的时候能够得到这么有益的指导,明年和以后的发展又多了新的稳定因素。

回来之后就想动笔。关联的内容太多,比如一想到某个关键词,比如单元测试,就想到我们的团队居然基本上还没有使用。还有一些新项目即将启动,又需要策划相关事宜,更让思路如同天马行空。一写起来就感觉,想的时候如同泉涌,下笔之后似若无魂。拖拖拉拉一直到现在(2011.09.30)也没有写完。

2. 抛砖

作为一个不到一年的新团队,我们经历了1,2,3,5,8…(哦,我们的发展过程好斐波纳切)的人员成长。要对新人灌输理念,又让给新人适应的时间。每来一个人,特别是有过传统开发方式的人加入的时候,调整和适应的痛苦都会影响整个团队。虽然开发方式/结果,客户的满意情况都还不错,我们一直以来坚持的无测试策略虽然省了成本,还是出现了一些问题。所以我们的问题是:

Q: 作为小团队,我们目前没有专职的测试人员,测试工作主要由程序员和用户来完成。在性能调整等方面我们还是需要测试人员的。

A: 现在有没有出现问题?如果没有出现问题,那就没关系。长远看来,没有测试是不可能的。
Q: 如何引入测试人员?比如计划引入一个测试人员,如何能让他在未来能够组建起一个测试团队?他是否需要具备一些编程知识?

A: 这个需要根据情况来定。测试人员如果懂得编程知识更好,这样沟通起来就更高效。提出的问题更有针对性。但是一个测试人员不提倡同时参与两个项目。两个项目的不同之处会影响他解决问题和工作的效率。
Q: 成本控制,我们在团队初期不会投入太多费用。

A: 支付:现在还是未来。
Q:  改进策略,是否可以让现在的结对编程程序员,进行角色互换进行结对测试?在一定的条件下,是否可以将比较适合的那个人转换为专职的测试人员?

A: 进行互换结对测试,可以。但是进行程序到测试人员的转换?他们的思维方式不一样,工作的重点是不一样的,为什么要这样做呢?

3. 聆听

每个人都是参与者。参与和了解意味着效率。

Planning Poker Card

这种方式对于预估项目规模很有意思。不过由于我们只是一个部门,搞得太欢乐对其它部门会有影响,这个可以在条件成熟的情况下进行。

4. 引玉

设计上我们采用的敏捷框架,给我们提供了一种特别有力的帮助,我们可以在项目初始,直接由UI设计人员将界面原型设计完成,采用DEMO数据(一般会耗时1周或2周),让用户对应用系统有最直观的认识。代码编写人员也方便进行编码工作。遇到的遗憾是有个客户认为程序已经做完了(当然这是沟通之过)。这种方式您认为有什么优缺点?

为了提高新程序员的入职效率,我们在实施一种 copy-cat learning方式的学习方法。将成型的类似程序提供给新的程序员进行抄袭,在强化他们编程基础的同时,也可以完成他们经验的积累。这样在我们差不多每周进行的技术交流中就可以提出更有效率的问题。在开发的过程中,结对的有经验程序员也可以逐渐将为何如此这样的编程理念传授给他们。采用这样的方式,一般一个编程新手可以在大约1个月左右就可以真正参与到项目中去了。这种方式您认为有什么优缺点?

在向客户提交程序的时候,Google大神的beta策略影响了我们,我们一直在尝试一种保持beta状态的交付方法。保证稳定的业务实现,我们可能提供简朴的UI给用户,并逐步在上面增加方便用户使用的实验功能,有些UI可能会提供稳定和实验两种方式。敏捷的开发方法,让用户有了更灵活的选择。这种方式您认为有什么优缺点?

5. 尝试

仔细分析当晚所听所学,对我们的团队改进非常有益。作为一个敏捷开发的探索者,个人认为它应该印证一种态度、是一种方式,而不应该是一种规则。它不会是是军规,第一,你应该如何如何,第二你应该如何如何。现在团队足够稳定。我们再做一些有意思的调整,看是否可以激活每个人的头脑风暴,让我们的效率更高,让每个人可以学到的更多/得到的更多。

我们的调整主要会集中在结对上。除了结对编程、结对设计,增加结对测试、结对发布。

BTW:

1. It’s really an amazing dinner. Learning so much from Janet Gregory(@janetgregoryca). Thanks to Jack Hou(@侯伯薇), Jack Li and all the others: Lijia Sun, Yao, SQA girl from NEU.

2. 前天(2011.09.28)还去看了一下敏捷的behavior testing tools Cucumber。ruby编写。

3. freemind

Switch to our mobile site