EAD: Bandit Johnson

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[FW]Michael Chen谈Code Review - [敏捷软件开发]

节前跟同事聊起过PP的事情，也谈到过传统的Code Review流程的弊端，以及在XP等Agile方法中是如何解决这些问题的。不过，没有今天看到的Michael的文章谈的透彻，留个链接吧，备忘一下。:)

PP怎么老是被打PP呢？ - [敏捷软件开发]

呵呵，不知道多少人只是看标题就知道我这篇想写什么？不过，我是不想做标题党，而是实在觉得空谈的人太多了，我也不想老是吆喝AGILE或者PP有多好，只有“用了才知道！”。

今天又在Infoq上看到一篇讨论PP的文章，里面有正反两种观点，谈论对于结对编程的意见。我个人是比较偏向于Brian的观点的，因为，从来不觉得XP等敏捷开发方法是精英团队才能采纳，只是看如何应用，以及应用得到效果的程度吧。结对编程之所以被打PP的原因跟很多人对于Agile的误解一样，看上去就不太对劲：

• 需要多余的设备：原则上是需要两套鼠标、键盘、显示器？
• 一个任务需要两个人：Buildin quality如果不在意的话，PP还是不要跟老板提的好。
• 喜欢一个人做事情：程序员都比较乐观，“狮子和老虎都是独来独往的”，但是，不是谁都可以承受“一个人战斗”的感觉，同时，又能够提供满足组织需要的质量的代码。

之前看到DreamHead对于Agile China 2009的文章，说到：

从大会的内容来看，很多是我以为的常识。不过，当Dave讲那些已经记载《程序员修炼之道》上的内容，有些人如获至宝，当Fred讲起一个函数平均应该只有几行，一片惊叹。我知道，我高估了许多人。

敏捷之路，还很漫长！

我想，DreamHead说的还是太客气，很多个性、文化的问题，远比过程之类的难以解决。今天早晨在给Team成员Review代码的时候，也谈到过，当团队的成员都习惯性的采用敏捷的方法以及思路，而不是需要反复的提点的时候，敏捷才可能实施的成功。从这个意义上说，敏捷是精英团队的实践有一定的道理，不过，如果已经是精英团队，那些最佳实践已经融入了团队成员的血液，叫不叫agile，也就无所谓了。

敏捷，只是从优秀到卓越的一条经过前人验证的路而已。

Michael Chen的闲话敏捷 - [敏捷软件开发]

不晓得现在在博客上说实话风险有多大，不过，我想还是不需要隐藏自己对于敏捷开发的热衷，以及对于TW公司的向往。如果不是孩子太小，不太想出差的话，还真是想去TW面试一下试试看...，因为，我觉得那是一种真正的程序员的生活，可以给客户带来价值，同时，也给自己带来价值的生活。可惜，上海这样的公司几乎没有，如果那位知道有的话，麻烦请告诉我（北京不愧是首都，幸福的多了，像TW这样的公司还有几家）。

今天看到Michael Chen的一篇博文，大概是跟某个客户内部人员的聊天记录，有很多蛮有意思的说法，包括对于build-in quality，Metrics以及软件开发的价值流等等，值得好好思索一下...

越来越感觉，很多东西都是相通的，TOC理论的背后，就是常识管理，敏捷开发的背后，也是一些常识，只是，经过重量级过程的洗礼之后，我们把一些东西，例如软件度量、漫长的开发过程等等，当作了理所应当，而没有去思索到底对于所在的项目环境，是否是正确的？敏捷开发也好，TOC也罢，Lean也好，都是“术”；PP／Daily Building/CI等等，就像是“器”，耍得好的人，对于背后的TAO是有深入理解的，否则，也就是到了西屋，就没有办法耍出东屋学的拳法与招数。

Yesterday's quality is the single biggest determinant of todays' quality - [敏捷软件开发]

好的开发人员都是很‘懒’的，但是，好像很多开发人员是真的很懒，懒得去给变量起个好名字，懒得仔细地考虑设计，懒得好好的分配职责，懒得写UT，如果都像敏捷开发宣称的那样，该多么的麻烦阿...。

不过，这个不是本篇要说明的问题，问题是什么呢？很多时候，我们都觉得改进太小，不值得去做，可以慢慢来的嘛。中国有句古话，叫做“不以善小而不为”，这个有两个方面的含义：

其一，积沙成塔，集腋成裘。每天作一点点，会有质的变化。很久之前的博文应该也谈过，一个小闹钟跟老闹钟说“你已经工作了这么多年，累不累阿？”，老闹钟说“不累阿，你只要考虑每秒钟滴答一下就好了，很容易的。”

其二，习惯成自然。当开发人员不需要仔细的考虑，已经开始下意识的考虑起个好的变量名，如何更好的进行职责分配，选定任务与PP、重构、TDD是每天做的事情，那么，这个程序员可能不够聪明，但是，他应该已经是个高手了，至少，对于作企业级别的应用开发来说，缺的就是那些能够保证昨天的质量，从而保障明天的质量的人。

今天看到了这篇讲解TDD／PP／REFACTORING的文章（是之前一篇讲解以上实践好处的扩展说明），其中的图表很有意思，值得借鉴一下，尤其是跟Manager推荐敏捷实践的时候。牢骚、感慨，如上所述。

BTW，对于如何提升这些HARD SKILL，强烈建议去读《Implementation Patters》，《Complete Code》等等。

也谈敏捷开发的管理者支持和知识传递 - [敏捷软件开发]

这几天杂事太多，博客都没有更新。今天才有空看看之前落下的文章，正巧看到了两篇INFOQ上的文章，一篇是谈“管理层能为敏捷开发做些什么”，另外一篇是谈“叠飞机与敏捷项目知识传递”。对我个人而言，更有价值的是后面的评论，颇有些耐人寻味。

3年前，我买过一套讲TOC的书，原本是希望了解制造行业的一些情况，以及TOC理论。不过，最近重新翻看Goal的时候，我发现，很多内容，确实不仅仅是制造行业的问题，而是如何进行价值判定。传统的会计，对于存货、生产成本的定义已经很多年了，但是，越来越多的人意识到评定指标的局限性。举一个Goal书中的例子，如果生产线中的某个关键资源（或者说瓶颈资源）停工一个小时，对于损失的判定是只是这个资源一个小时的成本，还是因为停工一个小时，而造成的没有办法交付订单的损失？对于软件开发也说，也是这样的，去制作管理者要求的很多图表也好，Metrics也好，他们反应了项目的真实情况了吗？还是具体交付给客户的产品，软件或者系统，更应该被作为评判的标准？

Scrum等敏捷开发方法，强调了最终交付的可运行的产品的重要性，这个才是最终价值的体现。在第一篇文章中谈到:

根据以前他和Scrum团队的接触，他认为Scrum只是一个工具，保护开发人员免受管理层的干扰，强迫管理层从开发人员的角度与开发人员打交道。

有这样的一个印象的根本还是他没有理解敏捷的含义，把team和管理层对立起来，或者说引入Scrcm的人并没有跟公司管理层讲清楚，引入的目的是为了更好的交付工作的系统等等。如果公司的文化没有办法改变，或者跟agile的背后原则想违背，实施的结果可以想象。

第二篇文章更有意思，本来文章是通过叠纸飞机的例子，来说明face to face沟通的高效性，以及PP能够带来知识传递的好处。我想这一点，本身没有什么再好去讨论的了。评论中有以下几个方面的话题：

• 人走了咋办？所以需要文档！
• 谁都知道F2F的沟通方式最高效，但很现实的问题是：人走了？咋办？ 这时候如果没有文档是不可想象的。 而且，没有文档积累，来一个新人，培训一遍，再来一个新人，又培训一遍，累不累啊？
• 纸飞机的例子太简单，造飞机用这样的方式不成！
• 5分钟可以叠一只纸飞机 但是如果是用一年的时间造一辆汽车呢？ 传递知识采用指导方式固然是最有效的，但知识的沉淀和积累难道也可以吗？ agile界总是喜欢用简单的事情来讲大道理，但现实简单吗
• 中国传统的师徒授课方式有效吗？
• 赞同，文档能起到更长期的经验积累和传递作用。 中国历史上很多“祖传秘方”就是因为使用了人传人的方式，常常传着传着走样了，最后消亡了。 其实敏捷本身并不排斥文档，是强调要写必要的文档。 不过感觉我们很多人在实施的时候过分强调文档的坏处，以近似裸奔的状态进行开发，长期下去令人担心。尤其长期深受CMM“之苦”的开发人员，借敏捷之名彻底抛弃文档，倒是有一时之快。 因此，个人认为敏捷项目必须在初期明确“必要的文档”包括哪些，但在内部交流时可以强调F2F的传递，两者要合理的结合，不能走极端。

对于第一点，个人觉得有点搞了。PP的好处之一就是作好了BACKUP，:)开发中文档是为了解决项目周期内的沟通问题，尤其是离岸开发，而非为了防止人走了，没有办法了解具体的情况。其实，完全可以通过unit test等等来解决，而且，如果公司的文化是为了防止人走而文档，那写出来的文档的质量可想而知。

第二点，大概评论人对于敏捷有些怨念。

第三点谈到的文档可以起到更长期的经验积累和传递作用，个人不敢苟同。文档的更新和从大多程度上反应真实的情况，是值得考虑的问题。不过，第三点中“不需要文档”是很多人对于敏捷的一个很大的误解。而且，其中谈到的文档与PP的结合，我觉得也是很有道理的。

我个人十分认同软件开发是个艺术活，而不是体力活。真正的开发人员，不是coder，是会把体力活变成艺术活的。以中国传统文化中的中医为例，现在的很多人已经意识到，要恢复到之前的师徒授课的形式，要抓临床。这个也从一个侧面说明了，像中医这样的艺术（决不是巫术或者简单的秘方传授，我谈的是真正的辩证论治，现在的好中医实在是太少了），不是简单的靠积累下来的文档（中医历史上的方书／经书汗牛充栋，但是，真正的验之临床，也只有《伤寒》《金匮》可以达到效验如神的地步），而是要靠师徒授课，从日常抄方／讨论中逐渐体会到运用的妙处。这个，还是需要一定的体力的！毕竟，不是人人都有张仲景／华佗那样的智慧！

BTW， 我团队的人做了PP以后，跟我说，一点都不比之前自己开发的方式轻松，哈哈。

ABTW，写完了之后，看到了Jackie的一篇文章，请留意评论中博主自己的回复最后一句。

Don't call it Scrum or Agile! - [敏捷软件开发]

之前跟某个MANAGER谈到他们使用Scrum的情况时，我言辞比较激烈，因为，我觉得他们在亵渎Agile/Scrum这些词，他们用的根本不是Scrum，只是套了一个好听的名词而已。

前面就看到过Johanna Rothman的关于Plunge in的文章，今天又看到了后续，大概是很多人不太认同前面那篇文章的原因。不过，在我看来，这是一篇给那个Manager看的很好的文章，和和。

The idea I was *trying* to get across is that if you call something agile, please make it agile. If you dip your toe into it, you have not made the commitment. If you vary your timeboxes depending on whether you finish work in the timebox, that’s not agile; that’s incremental development. You can say, “We’re experimenting with incremental development. We choose to  vary the length of the timebox so we can practice getting to done. Maybe after we practice it for a while, we’ll fix our timeboxes and see how that works.”