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

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

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

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

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

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

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

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

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

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

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

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()

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

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。

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

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

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

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

要实现这个功能，当然还是用我熟悉的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的设计阿？