|
|
作家和顧問溫伯格（Gerald M. Weinberg）已在計算機行業活躍了半個多世紀，作為一些最具影響力書籍的作者，他在業內廣為人知，備受尊敬。
最近，他在自己的博客“顧問的秘密（Secrets of Consulting）”上發表文章，指出大家對歷史的漠不關心，創新和進步被炒作周期所包圍，似乎大家都在重復以往，沒有組織和個人從前一個周期中吸取教訓。
他正在將之前寫的書《系統分析與設計的反思（Rethinking Systems Analysis and Design）》重排為電子版格式，并打算對寫于20年前的一個章節進行修改，原標題為“超越結構化編程（Beyond Structured Programming）”。結果發現，只要將短語“結構化編程”替換為“敏捷”，這章內容就會針對到時下的“敏捷編程革命”上來。
他說：
雖然這是寫給上一輩人看的文章，如今經過兩代人了，而且對多數程序員來說，“敏捷編程革命”也已經是明日黃花，但這文章所說的仍然適用——即使對于下一波和再下一波反思風潮，也仍然適用。我相信它在版本停止更新很長時間以后，還能有現實意義。為什么？因為我們這個行業耐不住寂寞，每十年就要鬧一輪新風潮。所以，你讀這篇文章的時候，也別管圈內里正充斥著哪些風潮，只要沿用同樣的教訓就好了。
接下來他談到，很多公司將實踐創新做為口號，實際做起來，要么是盲目套用了條條框框，要么是只重簡單實踐，而并未貫徹有效變革所需的原則。
他說，如果詳加考察所謂的敏捷應用：
- 5%可認為徹底達成敏捷。
- 20%可認為充分遵循了敏捷實踐，相對于1990年的平均水平，有了明顯改進。
- 50%能部分證明是多少嘗試用到了一些“敏捷規則”，但用得稀里糊涂，成效微乎其微。
- 25%看不出有過去二十年來各種編程思想作用的痕跡，包括敏捷在內。
他鼓勵謹慎而智慧地應用敏捷實踐，因為：
那些成功達成期望、從敏捷編程中獲益的單位和個人，往往不是那些為常規的軟、硬件賣點掏錢的家伙，而是傾聽這些賣點、從中提取所需、以解決自身問題的。他們實現的是自己的想法，也并不排斥他山之石可以攻玉。總的來說，即使沒有敏捷編程，他們對問題的解決也是成功的，而敏捷讓成功錦上添花了。
本章結語中他呼吁三思而后行：
做我們這行，能輕松搞定的問題即便有，也不多。問題的成功解決，在于放低對“變魔術”的期待，以及努力實現自己想法的決心，哪怕這些想法出自公司年會酒足飯飽后的閑言碎語。總結以上教訓，我打算在編程界另立門派，本門派信條如下：
- 沒有什么能代替對問題本身的透徹認識，除非中了頭彩。
- 沒有什么解決方案能放之四海皆準，在某一場合的最佳方案，可能在別處偏偏是最差的。
- 好方法通常具有一定的普遍適用性，熟悉以往的成功案例，可以溫故而知新。
- 解決之道不光是掌握方法，還得掌握時機，這樣就能隨機應變，讓方法來適應問題，而不是削足適履。
- 就算懂得再多方法和時機，實戰不會根據現有知識來出題，很多領域前人也未曾探索，還是謙虛第一。
請記住，本文初稿寫于二十年前，本來是討論結構化編程的，僅僅是把“結構化編程”替換為“敏捷”，就變成一篇時下適用的文章，和1990年一樣。
類似地，Elisabeth Hendrickson發表了題為“對敏捷的抵觸，還是職業生涯的警鐘？（Agile Backlash? Or Career Wakeup Call）”的文章，文章說，一提到敏捷應用，整個行業似乎充斥著抵觸思維定式：
第一類思維定式中，抵觸者是在那些半癱瘓的組織里，被缺心眼兒經理強加的“敏捷”惡心到無力的人們。“缺心眼兒”指的是，有些經理以為“敏捷教練”的資質，就是兩天培訓拿到的CSM證書（譯注：Certified Scrum Master - 敏捷教練認證）；還有些經理以為，只要改改流程文檔，搜索替換幾個關鍵詞，團隊就可以敏捷、變形、出發了。幾個關鍵詞說的是：
- 階段 --> 迭代
- 項目經理 --> 敏捷教練
- 需求 --> 用戶故事
- 預計工時 --> 故事點
- 項目狀況會議 --> 站立會議
悲催的是，我們眼看“敏捷”這個詞變了味兒，誰都無能為力。每個流行語都這樣——
ISO（國際標準化認證）、CMM（軟件能力成熟度模型 - Capability Maturity Model）、CMMI（能力成熟度模型集成 - Capability Maturity Model Integration）、RUP（統一軟件開發過程 - Rational Unified Process），你隨便挑……
第二類思維定式更讓她擔心：
我發現還有一類思維定式，更讓人上火，卻又值得深究。這些抵觸情緒，并非針對“敏捷”的誤解誤用，而是攻擊敏捷實踐本身：站立會議、結對編程、協作組、開放辦公室等等。
我猜想，這里有些人是內向型性格，他們工作在一群外向型的人中間，而敏捷中包含的社交特性，讓外向型的人一下子如魚得水。內向型的人需要時間和空間，好讓自己處理事情。如果一天到晚都沒有足夠屬于自己的時間，他們會抓狂。如果這里說的就是你，希望你別把敏捷當成仇人，嘗試跟大家一起工作，為協作時間和獨處時間找一個可接受的平衡。
接下來她談到，有許多社會行為放在以前可以容忍，而敏捷團隊不能接受，而社會和心理成熟度對現今團隊更加重要。
事實情況是，具有一定復雜度的軟件系統創作，屬于社會行為，需要集體合作。光憑才氣是不夠的，歷來如此。真正有能力的團隊成員，都有社交技巧，他們傾聽、協作、分享，并做出貢獻。
InfoQ最近一篇文章探討了敏捷炒作周期“敏捷是否到了夢醒時分？（Is Agile in the Trough of Disillusionment?）”
所以，計算機行業能否從歷史車輪中學到某些東西？或者注定要一次次重復炒作新思潮？
注： 本文作者Shane Hastie是一位敏捷指導、教練和顧問，在澳大利亞和新西蘭的軟件教育聯盟工作。另外這篇新聞的討論也非常有意思，特摘出幾個以饗讀者，也希望我們能繼續討論。
Amr Elssamadisy：
浪花淘盡英雄……
我一邊讀一邊點頭，“風潮論”深合我心；而且悲哀的是，“敏捷之殤”的說法也深合我心——敏捷不靈了，因為獲益的人越來越少，因為敏捷越長越大，大到真正重要的事說不出也做不到了。
另一方面，還沒發現有誰進行結構化編程實踐（也許是我沒在意）。然而我可以想象，敏捷的核心原則，對個體和互動的關注等等……從現在起適用5年、10年、20年。
我們正在整理Steve Peha的一篇文章，即將發表在InfoQ，內容是如何將敏捷原則應用于美國的教育系統。想想結構化編程，能適用于其他領域嗎？
Udayan Banerjee：
迭代開發怎么樣？試誤法（trail and error）是否進化的關鍵因素？我認為這是敏捷的重中之重。
一個思考——20年后，我們是與人互動，還是與一個系統互動？
Jens Meydam：
Amr 你好，
……因為獲益的人越來越少，因為敏捷越長越大，大到真正重要的事說不出也做不到了。
你覺得“真正重要的事”是什么？
Amr Elssamadisy：
你覺得“真正重要的事”是什么？
嗯……僅舉幾例：
- 瓶頸在于學習；
- 所有權；
- 改進別人之前，先改進自己；
- 在每個迭代，對“完成”的狂熱偏執；
- 重視實際商業價值，而非抽象概念；
- 改變環境，以達到上述要求。
列這些的時候，我知道敏捷社區中已經有一些模糊的提法，大家都在說“文化”，但每個人對文化都有不同的理解。但我發現，包括上述在內的一些特性，在應用敏捷和精益成效明顯的團隊都有體現。
Jens Meydam：
謝謝，這個列表很有分量！
說實話，我感興趣的是，你沒把重點放在技術上（除了第四點“完成”之外）。好多XP出身的教練似乎覺得，人們半推半就被敏捷的主要原因，是技術能力缺乏，而且有人批評Scrum脫離工程實踐。
你眼光獨到地指出問題所在——學習、所有權、創造真正的商業價值——我非常同意。技術能力是必要條件，但遠遠不是充分條件。
Amr Elssamadisy：
多謝。你說的對，技術能力是必要但不充分條件，Scrum也不能例外。我懷疑的是，類似前面提到那些領域，能否成為必要且充分的條件。
非技術因素與技術因素相輔相成。你認為重要事情的列表有哪些呢？
it知識庫：軟件開發應該以史為鑒，還是從頭再來？，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
