• 2009-11-09

    非完美世界的敏捷 - [敏捷软件开发]

    今天在InfoQ上看到两篇文章,一篇是谈《给成功敏捷开发的26条建议》,一篇是谈《敏捷的一个基本要素》。个人对于两篇有截然不同的看法。

    敏捷也好,LEAN也罢,传统的瀑布模型也成,都是适用于某些情景下的一堆最佳实践的总结。第一篇中提到的那些个实践,尤其是中文中特别罗列的几条,其实,在非敏捷的开发中也是很好的建议;反而对于真正有敏捷精神的团队来说,是不需多言的内容。如果你只追求“术”,而不了解背后的“道”,硬背的招数再多,还是会忘掉,或者是生硬裁剪掉,或者是“时间不够噢”(最后一个是最可笑的理由...,可惜也是最常看到的)。

    而对于第二篇的内容,从管理层次来说,如果你碰到的是那种谦卑的Boss是你的幸运,但是,在一个矩阵式管理的团队中,你不能祈求所有的Boss都理解何为敏捷,以及,敏捷需要什么样的环境?自顶而下最好,如果不成,农村包围城市也未尝不可。关键是要让团队体会到切实的好处,否则,口土莲花还是会被打下神坛,敏捷也逃不脱...

    结对很重要,但是你能开心于每天被纠正几十次更重要。测试驱动开发很有用,但是去设想一百多种让测试通不过的场景更有用。站立会议可能很有效,但是同事的信任解放了你去做自己的事情,才让会议真正有效。

    信任意味着你不得不放弃控制,放弃很多。
    设想意味着你将少了很多确定性。
    改正意味着你不得不承认从来就没有完美这回事。

    ...成功运用敏捷软件开发——或者任何其他种类的敏捷——的公司,都是那些能处理好失去控制、确定性以及完美保证的公司。

    Tag:敏捷
  • 2009-11-06

    敏捷测试 - [敏捷软件开发]

    上周的时候,有人让我用自己的话来描述对于敏捷(Agile)的理解,我当初应该是这么说的"消除浪费过程,同时能够为组织个人带来更大的价值"。我把重点用下划线标出来了。:)

    今天在slideshare上看资料的时候,发现了Allan Kelly的一篇讲解敏捷的资料:<The Future of Agile>(感觉不好的地方,正如dreamhead在谈对于09年中国敏捷大会的时候谈到了,国内对于敏捷的理解还处在初级阶段,而老外已经在考虑将来的事情了....),开始谈到了三个判断时候敏捷的测试,可以跟我上面说的作为互补吧。

    • 团队是否为客户或者市场提供了商业上的价值?
    • 团队是否学习,改变并或者成长?
    • 当帮助实施敏捷的顾问,教练或者讲师离开的时候,团队是否仍然敏捷?

    我自己的理解还侧重在于前面两点,而第三点,往往是最重要的。咨询师做得时候,是帮助团队自己找到好的解决方案,并在过程中使得团队更加认识到背后的原则/价值。说到底,还是那句老话:“授人以渔”!

    Tag:AgileTest
  • 2009-11-06

    我的那朵云在那里? - [最近技术热点]

    云计算跟几年前的on demand一样,被很多人误用或者故意拿来装点门面。地铁里面瑞星打的云杀毒的广告和张朝阳TX的搜狗云输入法(是这么说的吗?怎么有点坳口?),这几天是铺天盖地的...,但是,你在找你的那朵云的时候,免费和不敏感应该是首先要考虑的两点,如果是要收钱(少点兴许还成)或者要把关键的业务数据也放到不知道那里的云朵里,你会真的放心吗?

    不管是提供云计算的供应商,还是要使用云计算的我们,可能,这篇文章都值得好好读一读,或者耐心再等等,等到“蓝蓝的天上白云飘”的时候就好了。

    Tag:云计算
  • 2009-11-04

    GQ中的阉文--打倒土豪劣绅 - [杂七杂八]

    老横是blogbus的头头,他的博客还是蛮好看的,今天就看到一篇ZT的《打倒土豪劣绅》,非常辛辣,值得一读。要看的请早,不知道回头还在不在,哈哈。

    上海的地铁站最近GQ的广告特别多,还跟IQ/EQ扯上关系,我就晕着呢,是不是啥东西,扯上个Q就能红?后来才知道是美国时尚男性杂志的中文版,嘿嘿。

    Tag:GQ
  • 2009-11-03

    我爱豆瓣音乐 - [杂七杂八]

    我不是一个douban的狂热fans,但是,一直都觉得阿北他们做的挺好的,尤其是了解了是基于Python之后。

    言归正传,今天是在阿北的消息里面看到豆瓣电台开始公测了,就去尝试了一下。可能是我自己用其他的音乐站点比较少的原因吧,感觉douban做的很舒服,推荐的歌曲相对我都喜欢。:)界面也很清爽,不错。

    Tag:豆瓣 电台
  • 2009-11-03

    翻墙翻墙@python&swiftfox - [Python]

    FQ是什么意思,我想不需要多解释了,本来不想翻来着,昨天做一个parse功能的时候,发现不能翻就不能获取内容,:(今天在Shun同学的帮助下,终于FQ成功了,哈哈。在Swiftfox里面的配置比较容易,但是,后面发现了一个新的问题,就是原本一直用来获取网页内容的urllib2不支持socks5代理,哼哼。

    GOOGLE一下,很容易,pycurl是个不错的替代品,对于socks5的支持也不错,至此,python和swiftfox的FQ工作就完美解决了,哈哈。

    利用pycurl对于socks5的支持,主要是参考了这篇文章。我自己写了一个简单的包装功能,如下(参数需要自己调整的哦):

    import pycurl
    import StringIO

    def read_content(url):
        c = pycurl.Curl()
        b = StringIO.StringIO()
        c.setopt(pycurl.WRITEFUNCTION, b.write)
        c.setopt(pycurl.URL, str(url))
        c.setopt(pycurl.TIMEOUT, 30)
        c.setopt(pycurl.CONNECTTIMEOUT, 10)
        c.setopt(pycurl.MAXREDIRS, 5)
        c.setopt(pycurl.PROXY, '10.0.2.2')
        c.setopt(pycurl.PROXYPORT, 7070)
        c.setopt(pycurl.PROXYTYPE, 5)
        c.perform()
        c.close()
        return b.getvalue()

  • 2009-11-02

    终于把UBUNTU的ROOT空间扩大了... - [Ubuntu]

    我的Ubuntu是在VirtualBox里面运行的,但是,当初创建的时候,给Root分配的空间太小了,等到要升级到910的时候,发现不成了...

    今天在网上搜索了一下,发现了这篇文章,轻松搞定。原来使用的直接运用Gparted Live CD来copy/paste的方式不成,还是CloneZilla好用。备忘一下.:)

  • 2009-11-02

    敏捷世界有双重标准吗? - [敏捷软件开发]

    随着Scrum等敏捷开发方法被越来越多的人和公司熟知,不可避免的会被人误解或者借来装点门面,而这样做的结果自然是少有成功,尤其是在跟组织的文化差异很大或者实施团队没有更好的指导的时候。今天,看到了这篇博客,提到了以下的论点:

    I frequently hear the following concern about Scrum from developers considering it:

    "We hear one of two things about Scrum. Either Scrum was successful or if the project using it failed, it did so because they weren't using Scrum correctly."

    这个世界委实太可爱了,呵呵。竟然也有这样的观点出炉...?

    去年热映的《叶问》中,樊少皇饰演的人对叶问说“听说咏春是个娘们创造的拳法”(大意如此,个人没有诋毁女性的意思);而不知道多少人知道Scrum的应用也已经20多年了,这么长时间之前创造的东西,还适用目前的情况吗?

    毕业3年后,我明白了一个道理:凡事,成败只与人有关系。过程/技术/团队是项目或者产品成功的三要素,不能无限夸大过程(CMMI/RUP/ASD),技术(JAVA/.NET/脚本语言)的作用,但是,也不能把失败归结到过程与技术上面,很多时候,不足为外人道的原因,往往是人!

    看看Clinton Keith的回复吧...,这个世界其实没有那么复杂,标准只有一个,那就是你的标准。不过,每个人的标准不同而已,想让其他人认同你的标准,似乎是不太可能的,尤其是面对一对不明真相的人的时候。不要浪费时间在无谓的说服中了,还是低头做事的OK。

    Tag:Scrum Agile
  • 2009-10-28

    技术负债(Tech debt)的分类 - [敏捷软件开发]

    说实在话,我对于分类一向不太感兴趣,不过,今天早晨,我还是点击了这个链接,想看看infoq上有有啥新的观点。

    Bob大叔和Martin Fowler对于bad smell是否应该划入tech debt有不同的看法,不过,我个人更倾向于Martin Fowler的观点,bad smells从一定意义上也是技术负债的一种。他划分的四个象限如下:

    1. 不计后果,故意的——团队没有时间做设计,仅仅给出了一个匆忙做出的方案,缺乏对质量的预见。
    2. 谨慎,故意的——尽管有很多已知的缺陷,但团队必须现在交付产品,同时对此造成的后果心中有数。
    3. 不计后果,无意的——团队压根就不知道基本的设计原则,更不用说引入的坏味道了。
    4. 谨慎,无意的——那些拥有优秀设计师的团队很容易遇到这种情况。他们交付的方案具有商业价值,但在完成方案后才明白什么才是最好的方案。

    第二种基本上是不可避免的,而第三种,只能说是team不是很合格,需要更多的培训和指导;对于第四种,可以作为Lessons Learned来对待了;

    而对于第一种,需要再多解释或者说明吗?

  • 2009-10-23

    win32com用来转换Excel文件 - [Python]

    首先,我要承认的是,昨天做得事情其实停无聊的,是为了生成甘特图来着...,准确地说是利用Excel来维护一个FUNCTION GROUP的所有项目的信息(任务,启动/完成时间,完成状态等等),因为不是所有的人都有MS Project的license,然后,再导入到Project里面生成甘特图。

    要实现这个功能,当然还是用我熟悉的Python,再加上win32com的库(要操作office,非它莫属)。做法很简单,就是把Excel的xls文件中间的一个worksheet,转换成cvs文件,然后,再利用正则解析出需要的信息,生成一个新的符合Project导入需求的cvs,然后,再利用win32com生成xls文件。最后一步,Project打开xls文件没有在脚本里面作,有个import wizard要处理,比较复杂,还是放放吧。

    昨天碰到的主要的问题,是SaveAs的时候,指定FileFormat,Google上查到的24/6等数字,不能用,:(。在我就要放弃的时候,还是Google救了我,提示去看看testMSOffice.py($PYTHON_SITE_PACKAGES\win32com\test路径下),需要用以下语句来SaveAs就好了:

    mod = gencache.EnsureModule("{00020813-0000-0000-C000-000000000046}", 0, 1, 2, bForDemand=1)

    workbook.SaveAs(os.path.join(folder_name, to_import_xls_file), FileFormat = mod.constants.xlNormal)

    写到这里,我忍不住还是要骂娘,没有上面的EnsureModule操作,constants是那不到内容的...,什么API的设计阿?