英文原文：Why Software Development Methodologies Suck

　　圍繞軟件開(kāi)發(fā)實(shí)踐和方法論，總有很多教條式的口水仗。階段式（phase-gate）方法能夠有效管理軟件開(kāi)發(fā)過(guò)程的風(fēng)險(xiǎn)，還是說(shuō)只是風(fēng)險(xiǎn)管理中的花哨噱頭？TDD真的能夠促生出高品質(zhì)軟件？結(jié)對(duì)編程是代碼評(píng)審的有效替代抑或只是增加了商議溝通代價(jià)？我想說(shuō)，雖然缺乏證據(jù)判斷這些論調(diào)的謬處，但有兩條常用的法則能夠幫助我們選擇好的實(shí)踐，同時(shí)，提升我們所提供軟件的價(jià)值：劃小開(kāi)發(fā)周期以及提升反饋效率。

　　Michael Feathers給出了以下觀點(diǎn)：

我認(rèn)為，我們最終還是得倚重開(kāi)發(fā)者的能力，這才是個(gè)更重要的考量因素，而非選擇哪門(mén)語(yǔ)言或糾結(jié)于方法論間的細(xì)微差別。坦誠(chéng)地說(shuō)，我們都清楚這點(diǎn)，但我們看起來(lái)好像過(guò)度糾結(jié)于開(kāi)發(fā)能力是關(guān)鍵因素這事兒上。或許這是個(gè)經(jīng)濟(jì)學(xué)里一個(gè)被廣泛接受的觀點(diǎn)的引申，要是人人都可以替代（隨便找個(gè)人都能頂上），那該有多好呀？但事實(shí)并非如些。

　　問(wèn)題是，我們?cè)鯓硬拍苷业接校ê线m）技能的開(kāi)發(fā)者？IT界從未很好地定義個(gè)體生產(chǎn)率，從這點(diǎn)來(lái)看，那么，要找到合適技能的開(kāi)發(fā)者就是個(gè)很難解決的問(wèn)題。代碼行數(shù)（Lines of code） – 在現(xiàn)在仍然是一個(gè)主流的度量方法 – 深陷“一行代碼一個(gè)責(zé)任”泥潭，這并不是一個(gè)好的方法。而度量工作小時(shí)數(shù)則是鼓勵(lì)（個(gè)人）英雄式舉動(dòng) – 經(jīng)驗(yàn)表明，“英雄們”通常就是導(dǎo)致項(xiàng)目延期的人，依賴“英雄”往往是一開(kāi)始就采取的不該采取的冒險(xiǎn)行動(dòng)，長(zhǎng)時(shí)間工作導(dǎo)致人變得魯鈍，并導(dǎo)致低質(zhì)量軟件出 現(xiàn)。目前還沒(méi)有被普遍接受的針對(duì)IT專業(yè)人才的專業(yè)要求系列標(biāo)準(zhǔn)和雇用范式，招聘好的人才，是一門(mén)（招聘）藝術(shù)，而非（招聘）工程。

　　心理學(xué)家至少對(duì)這個(gè)問(wèn)題進(jìn)行了研究：為什么IT業(yè)的技能很難被掌握和度量？Daniel Kahneman說(shuō)（Thinking Fast and Slow），掌握技能有兩個(gè)基本條件：一個(gè)環(huán)境足夠規(guī)律以便可預(yù)測(cè)；有機(jī)會(huì)通過(guò)長(zhǎng)時(shí)間實(shí)踐來(lái)學(xué)習(xí)掌握這些規(guī)律。

　　但是典型的軟件項(xiàng)目往往是沒(méi)有規(guī)律及可預(yù)測(cè)環(huán)境的。項(xiàng)目成功的唯一正確度量就是：最終的結(jié)果通過(guò)整個(gè)生命周期里的實(shí)施達(dá)到了預(yù)期目標(biāo)嗎？ 很難知道什么關(guān)鍵活動(dòng)導(dǎo)致了項(xiàng)目成功和失敗，很少有人能夠通過(guò)舊有或現(xiàn)有的項(xiàng)目獲得答案。幾乎不可能判定哪些決策導(dǎo)致了成功或失敗（在人工智能領(lǐng)域，這叫作信度分配問(wèn)題）。

　　這些因素造成了IT專業(yè)人員很難掌握引導(dǎo)產(chǎn)品和服務(wù)走向成功所需的能力。然而，開(kāi)發(fā)者掌握能幫助他們更高效地達(dá)到目標(biāo)的技巧，將使他們更有動(dòng)力 – 通常稱之為“開(kāi)發(fā)完成”，盡可能快的、不考慮是否功能被集成以及生產(chǎn)就緒。類似的場(chǎng)景也常出現(xiàn)在其他功能性實(shí)施領(lǐng)域。

　　實(shí)際的軟件項(xiàng)目是復(fù)雜的，沒(méi)有規(guī)律可循，這會(huì)導(dǎo)致另一個(gè)問(wèn)題 – 為了證明某種技術(shù)、實(shí)踐和方法論是實(shí)際有效而收集相關(guān)數(shù)據(jù)是極度困難的，幾乎不可能在脫離收集環(huán)境的情況下歸納出這些數(shù)據(jù)。

　　在Laurent Bossavit的好書(shū)《The Leprechauns of Software Engineering》中， 他抨擊了軟件開(kāi)發(fā)的一些慣式，比如“成本變化”（或“缺陷成本”）“曲線”，這些慣式是許多其它的軟件開(kāi)發(fā)方法論知識(shí)基礎(chǔ)，稱開(kāi)發(fā)人員生產(chǎn)率的變化是一個(gè)數(shù)量級(jí)（參照確定性金字塔原理）。Laurent Bossavit說(shuō)明了相關(guān)依據(jù) – 很多人依賴從計(jì)算機(jī)科學(xué)專業(yè)學(xué)生進(jìn)行的非正式試驗(yàn)或是從無(wú)法被有效控制的項(xiàng)目中收集小量數(shù)據(jù)。這些研究組織的給出的論調(diào)基礎(chǔ)往往是不健全的，數(shù)據(jù)缺乏分析，而且，最過(guò)分的是調(diào)查結(jié)果普遍遠(yuǎn)遠(yuǎn)超出了他們的適用領(lǐng)域。

　　因此，不太可能輕易下論斷敏捷開(kāi)發(fā)實(shí)踐就比瀑布模式之流合適，反之亦然。“方法大師”的見(jiàn)解其實(shí)也沒(méi)太大指導(dǎo)意義，就像Kahneman說(shuō)的，“人們?cè)谙敕ǚ矫娴男判模⒎鞘怯行惺驴梢兄氐囊蛩?hellip;當(dāng)評(píng)估專家的想法，即使在有規(guī)律可循的情況下，你也一定要想清楚是否有合適時(shí)機(jī)可以引入其想法的可能性”。就像Ben Butler-Cole指出的（why software development methodologies rock），引入一種新方法往往會(huì)帶來(lái)一些影響。

　　你可能會(huì)認(rèn)為當(dāng)我們決定怎樣運(yùn)作一個(gè)團(tuán)隊(duì)時(shí)，我們就陷入了被動(dòng)。但細(xì)想一下為什么軟件開(kāi)發(fā)無(wú)章可循？為什么在這個(gè)環(huán)境里很難進(jìn)行一些試驗(yàn)以及獲取技能？什么實(shí)踐和決定會(huì)導(dǎo)致成功或失敗？其中的根原因就是：環(huán)境是無(wú)規(guī)律的，做出變更與理解變更帶來(lái)的結(jié)果之間的反饋過(guò)程太長(zhǎng)了。這里的“變更”一詞是指廣義上的需求變更、方法變更、開(kāi)發(fā)實(shí)踐變更、商業(yè)計(jì)劃變更、代碼或配置變更等等。

　　還是有一些辦法幫助縮短周期的，比如當(dāng)我們應(yīng)用精益軟件開(kāi)發(fā)思想 – 一個(gè)很重要的方法。縮短開(kāi)發(fā)周期在大型產(chǎn)品開(kāi)發(fā)中是很重要的：在Bret Victor的精彩視頻Inventing on Principle中提到，“如此多的創(chuàng)新被發(fā)現(xiàn)，只要你真正理解了你在做什么，你就能發(fā)現(xiàn)任何事物”。

　　但對(duì)我而言就是這樣的：我們幾乎不可能實(shí)踐持續(xù)改進(jìn)、學(xué)會(huì)怎樣使團(tuán)隊(duì)或個(gè)人變得更好、掌握成功創(chuàng)建大型產(chǎn)品與服務(wù)所需的技能。除非我們聚焦于盡可能使反饋間隔時(shí)間縮短，以便實(shí)際洞察其間關(guān)聯(lián)，以及辨別原因和影響。

　　事實(shí)上，從想法到反饋的周期盡可能短的好處是如此明顯和重要，應(yīng)該把其作為商業(yè)模式中要遵循的一個(gè)重要原則。如果你糾結(jié)于要把你的產(chǎn)品創(chuàng)建成一個(gè)用戶安裝式的軟件還是SaaS模式（Software-as-a-Service，軟件運(yùn)營(yíng)服務(wù)模式，軟件即服務(wù)），這時(shí)的想法會(huì)自然而然地推動(dòng)你強(qiáng)烈考慮SaaS模式（有感而發(fā)）。如果你要重建你的系統(tǒng)（包含硬件），應(yīng)該考慮怎樣盡快實(shí)現(xiàn)原型（how you can get prototypes out as quickly as possible），以及模塊化硬件和軟件，以便你可以快速和獨(dú)立地整合。3D printing（三維打印成型技術(shù)）技術(shù)看起來(lái)在這方面有著巨大的用武之地，因?yàn)樗梢詽M足軟件開(kāi)發(fā)應(yīng)用實(shí)踐朝硬件系統(tǒng)（原型呈現(xiàn)）的演進(jìn)。如果你想如愿以償?shù)乜s短周期，或多或少按多功能型團(tuán)隊(duì)（cross-functional teams）方式運(yùn)作是需要的。

　　軟件方法論，即使雇用一群牛人并讓他們自我組織，也是糟糕的，因?yàn)樗麄儠r(shí)常搞得“cargo-cult”（貨物崇拜，敏捷開(kāi)發(fā)里的知名小故事，形而上）：我們?cè)谧鰏tand-ups（每日站立會(huì)議），我們有優(yōu)先順序的backlog（優(yōu)先待辦事務(wù)），我們甚至看在老天的份上實(shí)踐了continuous integration（持續(xù)集成）。

　　我們的到頭來(lái)的結(jié)果為什么還這么差呢？因?yàn)槟阃俗钪匾氖虑椋?strong>建立一個(gè)學(xué)習(xí)能力和適應(yīng)能力都很好的組織。

it知識(shí)庫(kù)：為什么軟件開(kāi)發(fā)方法論讓你覺(jué)得糟糕？，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。