EAD: Bandit Johnson

Just make it & Manager's role in the team - [敏捷软件开发]

我没有查询，但是，印象里之前说过JUST DO IT之类的话，所以，就把标题换成了JUST MAKE IT，哈哈。其实，意思是一样的...

人没有主见很可怕，更可怕的是把主义建立在道听途说或者臆想上面，今天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.)

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

Buy in Vs. Follow up - [敏捷软件开发]

讲TDD也好，讲UT也罢，都是随着敏捷的风行而越来越被人熟知，但是，真正执行的好的，确实不常见。为什么呢？因为buy in和follow up还是有很大的区别的...

今天看到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之前一定要确保基本功能和规范都没有问题。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

翻墙翻墙@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()

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

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

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

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

随着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。