发布频率-越快越好吗

快速的发布是互联网应用的显著特点,老板巴不得今天说完一个想法,明天、哦不、最好今晚就可以看到结果。产品经理总是力争在计划里把产品需求排的满满的,这还不够,在开发过程中还总是见缝插针的挤入临时的需求。如果你问到:这个特性准备在什么时候发布?回答也许永远是越快越好。为了满足产品经理和老板的要求,于是项目[……]

继续阅读

电纸书带给我的影响

我是在3月中旬在淘宝上买了数源墨客电纸书,花了1600大洋,买之前考虑了很久最后还是狠下心收了它。
买电纸书对我来说诱惑太大:
1)家里的书实在太多了,这些年下来前前后后扔了很多书,读书人有个臭毛病就是舍不得丢掉书、好像是对知识的不敬。我去上海那会儿,去的时候一本书没有,半年时间不到回来时又是一箱子[……]

继续阅读

知易行难-敏捷实施的简单道理

和不同的团队实施敏捷实践也有一段时间了,我自己的心态和观念也在不断的更新,越来越强烈的体会到要做到真正的敏捷,实在是不容易啊。Vernon Stinebaker喜欢在他的分享中,不断地强调:“Simple,But not easy!”是啊,也许这是很多团队无法做到敏捷的原因。1.常见的声音:“我们的[……]

继续阅读

【Web交互】保存返回、保存查看和取消按钮

在我们使用的Web系统中有一个典型的多按钮提交设计,我个人感觉这个设计给用户带来了一定的使用成本,由于它经常被用到,所以这个小的使用成本也被不断的累积。但是不能单凭个人感觉来提意见。按照Google 6th rule:Data is apolitical。便花了一点时间,挖掘一下为什么这个多按钮设计[……]

继续阅读

敏捷建模–让敏捷方法整体拼图完整起来1

较大规模的团队(特别是大型产品/复杂产品团队)在实施敏捷方法时对于系统设计都会面临较大的困扰:

  • 敏捷提倡简单设计,但是简单设计这个指导原则很抽象,怎么样才算简单?如何做到保持简单?团队在实际实施时很容易变成缺少设计。我们都知道缺少设计带来的后果:
  • 缺失良好的设计导致后期的大量返工(甚至重写)
  • 缺[……]

继续阅读

用Excel制作一个Scrum Board

目前手头上没有好用的轻量级Scrum Board工具,实体白板有些团队没有形成使用习惯,如果想把白板的内容发给另外办公地点的人员,也不是很方便,有时候想要把白板打印出来时,也无从下手。当然实体白板才是王道,真正明白白板用作信息辐射器&透明协作沟通的目标,才能真正地把工具用好。否则再好的宝剑拿[……]

继续阅读

编写一个Cruisecontrol的扩展插件-RTXPublisher

老牌的持续集成工具Cruisecontrol已经很少更新了,后起之秀Hudson相比之下却是非常的活跃。CC和Hudson对插件的支持都很好,本想在Hudson上编写一个RTX消息插件,被maven绕晕了,就先在CC里面实现一个罢。RTX是一种企业办公用的即时通讯工具,界面简洁清爽,而且可以和企业组[……]

继续阅读

滞后的测试, 一个不容易跨过的门槛

最近在读微软测试专家写的《测试有道》,也看了Google中国测试经理-段念先生在中国软件质量年会上的宣讲:让测试也敏捷起来,颇有一些启发。
微软和Google采用不一样的做法,但是又有很多共通之处。

微软的质量文化:
《测试有道》:进度通常是质量的敌人,但在Microsoft,进度被看做是[……]

继续阅读

敏捷对团队有要求吗?

敏捷对实施团队有要求吗?这个问题在不同的场合被不同岗位角色问过。有些提问者在问时是在质疑敏捷方法是否适合自己的团队,觉得自己的项目情况比较特殊。有些则是担心实施难度很大、团队不适应。 记得和一个很有经验的项目经理聊时,他提到:实施了这么久,感觉敏捷的理念是不断追求的更好,敏捷要把人培养成精英,似乎只[……]

继续阅读

持续集成工具CC的一些个人经验

CruiseControl(CC)是老牌的开源持续集成工具,支持众多的插件,文档也比较全,普通的持续集成应用使用CC是可以满足要求的,CC已经比较久没有更新了。团队在选择CI工具时可以考虑使用新的CI工具:hudson 比较常见的问题:1.CruiseControl可以用来做什么语言的CI?CC本身[……]

继续阅读