人没有主见很可怕，更可怕的是把主义建立在道听途说或者臆想上面，今天dreamhead的博文就很好的说明了这一点，实在是不想多说什么了。

Manager确实不好当，大环境或者小环境不好的时候，更是如此。敏捷团队中的Manager，跟一般团队的Manager并没有什么不同，看看Johanna列出的这些事情吧，是不是很熟悉？

For example, what good is a functional manager? If functional managers don’t need to assign tasks and check on how the work is going (the team does this), the functional manager needs to build a trusting relationship with people, and provide career development. The manager sets the mission/purpose of the group. The manager needs to see when the team (or teams) need more people, and to start and lead the hiring process. The functional manager may act in what I think a technical lead role is: to help uncover other ways of working, whether that is specifics (extend the design this way, test that way) or to coach the person into recognizing where to look for help. And, the big decision that managers make: which project to work on now. (Of course, there is also strategic planning, customer visits, etc.)

不管是不是敏捷团队，单单只是前面两条，就不是那么简单的事情，但是，却是一切事情的基础，否则，敏捷团队也不可能心无旁骛。这也从一定的侧面，说明了敏捷的实施自顶而下的好处。

今天看到DREAMHEAD的一篇讲UT的文章，讲的非常有道理。最近，我进入了一个新的团队，他们的人员构成上Senior的人很少，但是，项目看上去还是蛮成功的。有些问题，在测试的阶段不可能全部暴露出来（例如代码的可维护性等等，要在产品生存了一定的时间才会越来越明显，可惜的是，很多时候，团队稳定的时间更短，然后，就是后来的人骂娘，然后，再被人骂娘的恶性循环），而且，你也不可能寄希望于QA／Tester去发现所有的问题，关键是要明确SE的职责，也就是Scrum中对于Done的定义。

如果我们去除那些开发流程需要的文本内容的话，从代码的三个层次来看看开发人员到底应该有些事情作完了，才叫DONE吧（一家之言）。

• 完成功能：项目确定coverage的UT；功能的demo；
• 代码规范与开发规范：利用Checkstyle等类似的工具来检查代码规范，并集成到daily building或者code commit的过程中（这点是项目开发团队SCM的事情，SE需要清楚的了解规范，并检查反馈并改进）；不能用现有工具进行的开发规范的检查（例如，报表或者UI对应的元素的字体等等），可以通过编写BVT（Build Verification Test）来进行。（对于这一点，我一向觉得，规范没有检查，只是纸上谈兵，SE以及TL要有用机器来帮助检查的意识，否则，很容易流于表面，或者让Code Review变成了规范检查，不值！）
• 代码的设计与维护性等等：PP以及Code Review希望可以解决的问题。在Code Review之前一定要确保基本功能和规范都没有问题。

能够切实理解，才能很好的执行，否则，流程最后还是会被规避，国人的聪明才智在这些方面还是很强的...

敏捷也好，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。