敏捷水管工

敏捷水管工

本文来自Terazen Technology Inc的创始人+CTO的 David Ing的《Agile Plumbers》(这也墙?),我的其文中的这个帮事翻译过来(和前些天发的SOAP的S是Simple异曲同工)。

也许你会觉得这个比喻不恰当。但我想告诉你的是,这个故事告诉我们,教条主义和以方法论为中心的危险。十条不错的编程观点中第一条—— The only “best practice” you should be using all the time is “Use Your Brain”.

————————————————————

(门铃响……)

事主:啊, Agile 水管工吗? 请进,感谢谢你们这么快就来了——这的确很紧急,我这真是很乱。

水管工1: 先生,没问题,我们就是敏捷的。在我给你做Presentation前,我先给你介绍一下我的两个同事。

事主:Presentation?啊,我们有时间吗?这的水已经流得到处都是了……

水管工1:……先生,我们必需坚持这个。我们只是想保证你能成为动态搜寻解决方法的一份子。你是我们的 champion sponsor,也就是我们团队内的 consultant!你可以提供一个白板给我们使用吗?

事主:我没听懂,你们不觉得这变复杂了吗?我觉得我应该告诉你们这水是从房子哪儿流出来的,就是那……

水管工2:你这有让我脱衣服的地儿吗?

事主:什么?

水管工2:我要坐在你的浴盆里——我还需要肥皂和托鞋。因为我们运作的方法是“测试驱动”, Red, Green, Red。你可以看到我们是怎么驱动的……

事主:为什么你会需要这样做?水都从楼梯上流下来了,水管爆裂了,马桶堵了,你能现在就开始吗?

水管工3:非常不错的feedback——感谢你!你介意先填一下这些 3×5 的卡片吗?我希望你能使用名词,让我们迭代一下刚才你说的“水灾……

水管工1:别那么着急,Domain Model 可以等的,让我们现在先生成一些想法——我们应该先把所有的业务需求都写出来,然后调查其动机。先生,是不是所有的功能都是 “关键业务’”?你能先给马桶评个等级吗?另外,如果你有100美金……

事主:你在开玩笑吗?你看,如果你们不能干这个,那么我就……

水管工2:我去拿个扳手。

事主:好!终于!等等,你就拿来一个扳手?可是你们有三个人哦。

水管工1:不这样的,先生!我还是在这里做个初始的Presentation,我一会就走了。但是,我还是会对项目的进度非常感兴趣的。我会打电话过来参加明天的 stand-up meeting。

水管工2 :另外,和你阐清一下,我们两个留下来的会分享同一把扳手,因为我们是结对水管工……

水管工3:……你能看到这会更有生产率,我们轮流使用这把扳手。并能保证很高的质量以及持续的工作激情!

事主:我没搞懂——你们以前应该就干过这个事了吗,不是吗?500美金的出场费还不能让你们有工作激情?

水管工1:你得想得长远一些,先生。你看,我们可以一起来经历整个过程。这是多么令人兴奋的事!我对此超级兴奋!

水管工2:哦,不。看看这个,这些是铜制的水管吗?有多少人在这住?

事主:什么?这个房子有5年了。就我和我太太在这里,但是你问这个是什么意思?

水管工3:嗯~~。我有些害怕,情况并没有那么简单!这些都是Legacy的水管,我们需要对它们做重构,而且,这些老的水管也无法适合我们新型的板手。重构看起来并不难……

水管工2:喔,我们可以使用新的在机场使用的防水层系统。另外,还有更多的工作需要花在一个大的O型环性能配置上, 但是这会让住在这里的数千人都到影响。我想,我们得做个迭代……

事主:什么??!!

水管工1:先生,也许我们可以从你这做一些case study。我们可以为这里创新。让我们先安排一个游戏,这样我们可以进行一个头脑风暴。而最简单有可能做的事——先生,你有水桶吗?

事主:够了!你们给我滚出去!真是荒唐——很明显,你们根本不知道你们在做什么。给我滚出去!

水管工1:先生,我开始怀疑你根本没有一个Fackbook社交平台策略(Facebook Social Platform Strategy)用来做解决方案?

————————————————

(全文完)

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

好烂啊有点差凑合看看还不错很精彩 (20 人打了分,平均分: 3.40 )
Loading...

敏捷水管工》的相关评论

  1. GlacJAY :

    个人感觉,用修水管来比喻软件开发不是那么的合适。

    其实是可以那么类比的,有很多需求就是这么急,就像是救火。这样的事经历的太多了。

  2. 实际的需求确实有像修水管这样的情况,选择合适的开发方式才是正理。是否选择敏捷方式其实是事主的责任,真正类似的修水管的工作很可能就是核心的开发人员个人主义先开发然后再维护重构,可能都没啥章法可言。说到头来应该不是敏捷的错了。

  3. 感觉酷壳有点过了…
    太过于感性了。
    期待酷壳那种冷静、理智的文章。

  4. @tmy13 哈哈。这就是一个make fun的文章。

    @旁观者 哦,本站之前还有很多这样的文章呢。比如程序员的笑话,比如Windows编程发展史,还有各种编辑器的学习曲线。而且都是翻译过来的。呵呵。

  5. 一点都不过,大量不明真相的围观群众就需要这样有笑感的文章才好明白什么,前面的那些太学术,看不太懂。

  6. coolshell什么时候这么幽默了?没做过啥大项目,不过偶尔有些筒子确实让人不能忍受……

  7. 其实这个笑话就是让大家别钻牛角尖,并不是特制敏捷开发吧?
    不管是敏捷也好,TDD也好,OOP也好,设计模式也好,其实都是工具,都有自己发挥长处的空间范围,把他们放在合适的地方才能体现其价值。否则像文章那样水都漏成那样了还不紧不慢的按部就班、生搬硬套理论,根本就不对路嘛,的确有些可笑了。

    貌似有些朋友误解这篇文章,我说的对不?

  8. 陈皓 :
    @tmy13 哈哈。这就是一个make fun的文章。
    @旁观者 哦,本站之前还有很多这样的文章呢。比如程序员的笑话,比如Windows编程发展史,还有各种编辑器的学习曲线。而且都是翻译过来的。呵呵。

    哥,有点过头了。。。
    平时的文章仅仅是博主自我娱乐的翻译。但是这次让读者觉得目的性很强。
    皓哥 还是回到以前轻松愉悦的话题吧 没必要在这上面纠缠了。

  9. 恩,您的中心思想是完全合理而正確的。但例子確實不夠恰當,軟件還是有其特殊性的。敏捷的一些方法確實有待實際檢驗,但如果以這篇例子的說法,那普通的軟工流程豈不是更長?

  10. @OhMyGod
    你有没有考虑过这个问题—— 为什么需要流程?!(无论是敏捷还是瀑布,没有那个比那个好,但是只要你教条了,他们都是一样的烂)

  11. @陈皓
    敏捷和標準的爭論仿佛就像在政治討論,怎么搞才算共產主義一般。敏捷和標準只不過是思維著重點不同,其他其實都以樣,敏捷和瀑布流程都在不斷進化,而且進化的越來越像,就總體方法看不都還是在搞迭代么?幹的都是一樣的事,舉的大旗不同,僅此而已。敏捷是後起之秀,喜歡喊口號,給大家洗洗腦,洗洗更健康,最終還是新瓶裝舊酒,我PARTY也是這么過來的。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注