【導(dǎo)讀】：如果你有不會寫代碼卻要管理程序員的領(lǐng)導(dǎo)或上級，那本文就是要給他們掃盲軟件開發(fā)的基本常識。比如：為何軟件開發(fā)工期難以估計、為何開發(fā)速度那么慢、為何程序員要“浪費”時間寫測試以及做代碼審查（Code Review）？

更快，更好，更便宜——軟件開發(fā)的藝術(shù)

沒人想交付延遲的、超過預(yù)算的軟件，我從沒見過一個軟件開發(fā)者會大早上起床后心里想著“我就想把工作干得很差勁，我怎能讓老板花更多錢呢？”但是，有太多的軟件項目進行得都并不順利。而且對于每一個新項目來說，似乎在加快軟件開發(fā)速度方面的壓力變得越來越大。所以，如果我們正在從事軟件開發(fā)的工作，那么我們應(yīng)該怎么做呢？我們應(yīng)該如何在不降低軟件質(zhì)量的前提下加快開發(fā)速度呢？

雖然歷經(jīng) 50 多年的歷史，已推出無數(shù)方法、建議和書籍，但是 IT 項目仍總是經(jīng)歷失敗?！猄usan Moore [1]

現(xiàn)在，我不是以某種專家的身份在這兒寫東西。我從沒運營過自己的軟件公司，也沒傳播從豐富的學(xué)術(shù)研究或?qū)φ諏嶒炛刑釤挾龅睦砟?，我寫這篇文章是為了組織我自己的想法，因為我想要設(shè)法了解我所看到的周遭所發(fā)生的一切。

為了正確地看待此事，我們首先需要搞清楚為什么要開發(fā)軟件？所有軟件生產(chǎn)的意義是什么？我們?yōu)槭裁醋铋_始要做的就是開發(fā)軟件？咱們暫且把開源當(dāng)做房間里的大象擱置一邊，先來探討一下商業(yè)軟件。咱們先從生意說起。

生意就是指減少客戶的痛苦

按照我的理解，為了達成一筆成功的交易，我們首先應(yīng)該找到使人們痛苦的東西（找痛點），可能是一種隱喻形式的或字面形式的痛苦（但通常是隱喻形式的），然后我們以錢作為交換，為他們提供減少痛苦的方法。例如，人們發(fā)現(xiàn)編程很難（很痛苦），所以開辟了編程書和編程課的市場；有些人不喜歡他們自己的外表，所以帶動了健身、化妝品、美容等等整套完善產(chǎn)業(yè)的發(fā)展。生意從某種程度上給客戶傳達的觀念是它們可以減少客戶的痛苦（或?qū)ν纯嗟母兄?，而且如果人們相信我們可以減少他們的痛苦，那么他們就會很樂于給我們付錢。

在軟件產(chǎn)品業(yè)務(wù)中，軟件就是我們用來減少客戶痛苦的東西。對于這種類型的業(yè)務(wù)，軟件開發(fā)就是提供價值的關(guān)鍵環(huán)節(jié)?？蛻糍I（或訂購）一件產(chǎn)品，那么軟件開發(fā)這一環(huán)節(jié)負(fù)責(zé)把它開發(fā)出來。當(dāng)然，這只適用于產(chǎn)品業(yè)務(wù)。如果我們把咨詢服務(wù)或IT作為一種支撐功能進行售賣，那么情況就會有所不同?？墒堑仓饕诵臉I(yè)務(wù)是軟件產(chǎn)品的，那么完成該業(yè)務(wù)的手段就是軟件開發(fā)。

這不是說軟件開發(fā)就是增加價值的唯一方式。例如，要是沒人知道我們的產(chǎn)品存在，那么還不如說它真的不存在呢，所以產(chǎn)品的營銷和推廣活動也是至關(guān)重要的。我們也需要確保我們的產(chǎn)品實實在在解決了客戶的真正痛點，否則，我們就是在浪費時間，所以市場調(diào)查（無論是正式的還是自組織的）同樣是非常重要的。產(chǎn)品中的摩擦是我們解決客戶問題時的攔路虎，我們也需要用戶體驗（UX）和圖形設(shè)計活動來減少摩擦，所有的這些活動（營銷、銷售、市場調(diào)研、UX、設(shè)計）都很重要，而且如果你略微瞄一下，它們看上去都挺相似。它們就好比同一個核心活動的不同方面，這個核心活動就是理解他人。但是歸根結(jié)底，所有的這些活動只為客戶價值提供計劃和承諾，而將所有的計劃和承諾轉(zhuǎn)化為實際的產(chǎn)品的則為軟件開發(fā)。[2]

當(dāng)你接受了其實“產(chǎn)品”、“設(shè)計”和“工程”僅僅是同一件事的不同方面這種觀點時，事情便都會進展得更好?！狦reg Veen

將開發(fā)時間對業(yè)務(wù)的影響最小化

如果我們能夠很好地做到“理解他人”，那么軟件開發(fā)這項活動就能穩(wěn)步推進。在軟件開發(fā)過程中，我們會更加了解那些我們致力于解決的問題，所以我們可以開始設(shè)計更優(yōu)的解決方案，因而我們創(chuàng)造的軟件產(chǎn)品也需要有所改進。為了實現(xiàn)此目標(biāo)，我們需要一支敏銳的開發(fā)團隊、一支可以快速傳播價值并且迅速應(yīng)對變化的團隊，這是軟件開發(fā)實踐中的核心目標(biāo)。正如 Dan North 指出：

“軟件開發(fā)的目標(biāo)是持續(xù)盡力降低軟件開發(fā)時間對于業(yè)務(wù)的影響。”——Dan North[4]

所以，擁有一支敏銳的開發(fā)團隊至關(guān)重要。但是如何能夠擁有一支敏銳的開發(fā)團隊呢？你會：

• 將開發(fā)者像王一樣供奉？

• 給他們買超快的、昂貴的計算機？

• 把他們送到任意他們想要參加的瘋狂科技研討會？

我們有很充分的理由做任何這種事：如果你想要維系你那支敏銳的開發(fā)團隊，那么就要對團隊中的每個人都認(rèn)真上心。運行快的計算機和優(yōu)良的科技研討會使開發(fā)者表現(xiàn)得更好，這種對開發(fā)者的投資總有一天會得到回報。但是這種投資對留住優(yōu)秀的開發(fā)者更有用，而我們想要組建的是一支敏銳的開發(fā)團隊。

所以如果不給開發(fā)者提供他們所想要的，那么我們該做什么呢？簡單的答案是，去問開發(fā)者。但是，請在合適的時間，用合適的方式問他們。我們需要理解的一點是，開發(fā)者往往是天生的問題解決者。優(yōu)秀的開發(fā)者熱愛他們的工作，熱愛的原因是他們整天能解決有趣的、復(fù)雜的難題，并且能夠因此而掙錢。優(yōu)秀的開發(fā)者陶醉于迎接復(fù)雜的挑戰(zhàn)并且找到簡約漂亮的解決方法。所以他們應(yīng)該能想出精彩的點子以變得更加敏銳。但是許多組織鼓勵開發(fā)者專注于錯誤的問題，這種鼓勵可能既不是深思熟慮的也不是有意而為之，但是卻時常發(fā)生。

專注于錯誤的問題

這是怎么發(fā)生的？我們怎么可能甚至不知道自己在做錯事，以至于最后讓開發(fā)者專注于錯誤的問題呢？因為我們將開發(fā)者從消費者身邊拉開。一個項目一有任何合理的規(guī)模，我們就會找來項目經(jīng)理和業(yè)務(wù)分析師。[5] 我們拉來這些人是出于一個非常好的理由——開發(fā)者無法完成所有的事。軟件項目是復(fù)雜的，代碼已經(jīng)夠復(fù)雜了，但是另外更重要的是，還有各種工作諸如決定構(gòu)建的內(nèi)容、規(guī)劃開發(fā)的階段、制定推廣部署的計劃、聯(lián)絡(luò)客戶……不一而足。代碼已經(jīng)夠讓開發(fā)者操心了，所以我們需要這些額外人員來幫忙。

但是，這樣做使得這些額外人員成為了開發(fā)者面向世界的接口。與外部持股者進行協(xié)調(diào)溝通的是項目經(jīng)理和業(yè)務(wù)分析師，尤其是項目經(jīng)理非常在意項目的交付。項目經(jīng)理向管理部門匯報情況，管理部門關(guān)心的是：

• 項目需要耗費多少資金？

• 項目需要進行多長時間？

• 為什么項目需花費這么多資金？

• 為什么項目拖延到這么晚？

• 為什么項目還沒有完成？

• 我的天哪，這個項目拖到這么晚每天需要燒我們多少錢？

于是我們可以理解為什么之后項目經(jīng)理開始變得專注于預(yù)測項目了。他們想要計劃、結(jié)構(gòu)、評估，他們想要知道什么時候在發(fā)生什么事。當(dāng)他們向管理部門匯報的時候，所做的預(yù)測和估量會讓他們顯得更稱職，所以他們才會向開發(fā)者探討預(yù)估、報告和截止日期。所以之后，開發(fā)者開始專注于預(yù)估、報告和截止日期，他們將精力集中在這些預(yù)估和預(yù)測性上來讓取悅項目經(jīng)理。

但是這樣做有一點不如人意的是，預(yù)估和預(yù)測性都是不可能解決的問題。每次一個開發(fā)者開始著手一個新任務(wù)時，他們就面臨一個不安的事實：任何一個給定的任務(wù)背后都可能有一個潛在復(fù)雜性的大坑，也可能沒有。我們都希望任務(wù)是簡單的，但是它有可能并不簡單，你永遠(yuǎn)都不會知道。這時霍夫史達特定律就起作用了：

霍夫史達特定律：事情總是要比你預(yù)期的花費更長的時間，甚至當(dāng)你把本定律考慮在內(nèi)時也一樣?！狣ouglas Hofstadter[6]

考慮這種情況：

一個項目經(jīng)理向一個沒經(jīng)驗的開發(fā)者問項目的估算，這個沒經(jīng)驗的開發(fā)者告訴了一個他們認(rèn)為合理的估算，然后項目經(jīng)理回去根據(jù)估算情況得出截止日期和相應(yīng)的計劃。優(yōu)秀的項目經(jīng)理為穩(wěn)妥起見，甚而會在此基礎(chǔ)上加上一點“富余”。但是之后不可避免的事情發(fā)生了——項目落后了。所以開發(fā)人員開始為趕在截止日期到來之前完成任務(wù)，開始加班加點地工作。但是長時間的工作使得開發(fā)人員疲憊不堪，他們便開始犯更多的錯誤。而且不僅如此，項目仍然在落后。項目經(jīng)理需要知道到底是什么耗費了這么長時間，所以苦惱的開發(fā)者圖省事，開始投機取巧偷工減料，這一過程中，程序漏洞源源不斷地出現(xiàn)，所以此時產(chǎn)品不僅延遲了，而且漏洞頻出。

這種情況傳達了一種消極的客戶價值。當(dāng)然這種延遲的、漏洞頻出的產(chǎn)品可能仍然能夠解決某種程度的客戶痛苦，但是這些漏洞帶來了新的痛苦，這又需要耗費時間來進行修復(fù)，這樣客戶就會對我們可以幫助他們的能力喪失信心，這使得他們更不想為我們付錢，到頭來無人從中獲益。

經(jīng)驗豐富的開發(fā)者知道這種估算是不公平的，所以他們盡其所能不蹚這灘渾水。

想象一下，

一個項目經(jīng)理來找有經(jīng)驗的開發(fā)人員問預(yù)算，開發(fā)人員便會回復(fù)他一個大到離譜的數(shù)據(jù)，但同時又小到使這個項目還不能立馬被取消。接下來，項目經(jīng)理（銷售人員）回頭開始質(zhì)疑這個荒謬的數(shù)據(jù)：“那個預(yù)算看上去比我們希望的多一點，我們有沒有可能縮減一下，讓預(yù)算少點？”這時，有經(jīng)驗的開發(fā)者便會問：“我們著手需要的預(yù)算是多少？”銷售人員回復(fù)他一個數(shù)，然后有經(jīng)驗的開發(fā)者揉揉她的下巴說：“預(yù)算有點緊，但是我們會盡量做。這樣的話我們難以滿足所有要求，只能提供最基本的性能?！比缓笏龝谧约嚎瓷先ゲ粫环Q職的前提下，預(yù)估他們可以承諾交付的是多么有限，并且這是她可以承諾的所有。這樣的話，如果她最后交付的比自己先前承諾的更多，那么每個人都很開心。但是甚至在這個情況下，霍夫史達特定律還是會出現(xiàn)，過不了多久，我們就會像從前一樣，在趕最后期限、交付低質(zhì)量代碼的泥潭中苦苦掙扎。

預(yù)算是軟件開發(fā)過程中一項必不可少卻令人生厭的東西。不幸的是，人們往往以為編軟件就像建房子或修車一樣，承包商或參與的機修工在客戶審批工作前，應(yīng)該能很好地對要完成的工作提供一個可靠的預(yù)算。[……]然而對于定制軟件，很多系統(tǒng)都是從零開始搭建，而且通常組裝、最終運行、應(yīng)實現(xiàn)的功能、完成的時間等等都在隨時發(fā)生變動，因此在工作之初，你要選的方法和最終達成的效果都是不確定的，所以很難知道到底什么時候可以完成?！猄teve Smith[7]

我這兒的觀點不是說要抱怨軟件預(yù)算，大家都知道它雖然令人生厭但又十分必要，就怪這種軟件預(yù)算會陷入一種惡性循環(huán)。為了趕截止日期，我們投機取巧偷工減料，交付低劣的代碼，還一直互相保證我們過后終將回頭將代碼進行完善，但是“過后”再也不回來。如果我們回頭修復(fù)那些漏洞的話，我們就已經(jīng)在下一個階段中又落后了。所以我們構(gòu)建的一切都建立在脆弱的、雜亂一氣的代碼上，這些代碼難以應(yīng)對快速的變化。而且一旦困在這個循環(huán)中，那么開發(fā)者的注意力將難以繼續(xù)集中在解決客能戶痛苦上，相反，他們將會專注于諸如以下的問題上：

• 有什么可能的方式能使我們最快地將任務(wù)標(biāo)為“已做”并且讓項目經(jīng)理不要再煩我？

• 我怎樣才能盡可能少接觸脆弱的代碼呢？因為這些代碼我接觸得越多，它們崩潰的可能性越大。

• 我怎樣才能在這筆巨大而過火的技術(shù)債務(wù)中，竭力維持讓我引以為豪的那一小塊代碼呢？

• 我怎樣才能向那些不知道我在干什么，或者不知道問題的復(fù)雜性的人們證明我的決定是對的呢？

• 當(dāng)客戶開始抱怨那些我沒有時間修復(fù)的軟件漏洞時，我怎樣才能將責(zé)任推到其他人身上呢？

• 我怎樣才能在我的簡歷中加入一些流行語，幫我另找一份不這樣混亂不堪的工作？

我沒見過有開發(fā)者想要交付一份延遲的、滿是漏洞的軟件，但是我們因為想要他們速度放快，所以給開發(fā)者不斷施壓。他們?yōu)榱巳偽覀円泊饝?yīng)照辦，但是由于預(yù)估往往是錯誤的，所以導(dǎo)致他們深陷泥潭，在重壓之下交付軟件。他們?yōu)榱巳偽覀?，加班加點工作，但又在軟件開發(fā)中偷工減料。因為大家一直在催問他們“完成了嗎？”使得他們在軟件質(zhì)量上做出妥協(xié)。最終沒有人開心，軟件仍然拖延，仍然滿是漏洞。

所以我知道的大多數(shù)開發(fā)者都在工作中盡其所能，但卻深陷困境。他們?yōu)榱粟s進度忙得焦頭爛額，甚至連怎么變得“更快”都顧不上想。因此他們把精力集中在了錯誤的問題上，他們重點關(guān)注的是如何讓自己活下來。好比當(dāng)你餓得快要死了的時候，你很難再去關(guān)注為退休攢錢的事兒了。也好比當(dāng)你因為一個延遲的項目一周連續(xù)工作七天后，你很難再去計劃怎樣才能做得更巧。所以第一步應(yīng)該承認(rèn)，想要項目做得更快就需要投資，而且如果事情進展不順，那么也同時需要時間/財政投資和情感投資兩項。

打破這種惡性循環(huán)

之前，我建議去問問開發(fā)者怎樣才能減少軟件開發(fā)時間對業(yè)務(wù)的影響，但是當(dāng)開發(fā)者處于“趕進度”模式時，我們不可能得到從他們那兒得到很好的回復(fù)。當(dāng)我們進入這種環(huán)境問道：“我們怎樣才能開發(fā)得更快？”可能會得到兩種回復(fù)中的一種：

1. 用火燒了它。

“我們需要出走兩年，然后重頭再來。”這種情況通常在開發(fā)者已經(jīng)被技術(shù)債務(wù)徹底壓垮時發(fā)生。技術(shù)債務(wù)太繁重了，所以他們感覺唯一的出路就是宣告破產(chǎn)。他們這樣做可能也有一定的道理，但與此同時，我們可能并沒有相應(yīng)的預(yù)算作為支撐，而且當(dāng)我們過后重建的時候市場必然不會一成不變。

2. 憤慨。

“我們已經(jīng)開發(fā)地更快了，我不敢相信你竟然覺得你只用半個小時的頭腦風(fēng)暴就能修復(fù)這個復(fù)雜的問題！你怎么敢？！”這種情況通常在開發(fā)者覺得自己被迫發(fā)行低質(zhì)量代碼時發(fā)生。他們感覺當(dāng)客戶抱怨漏洞時，自己受到了客戶的譴責(zé)。而且他們的憤慨很可能是有一定理由的。開發(fā)者懷著這種心態(tài)是不會幫我們的，除非我們可以向他們表達我們聽到了他們的心聲。他們需要知道我們理解他們的顧慮，我們同樣也需要表明我們正在嚴(yán)肅地考慮做一些改變。

在以上兩種情況中，開發(fā)者的顧慮是正當(dāng)?shù)?，但他們只關(guān)注了自己。我們希望創(chuàng)造一種每個人都為將軟件開發(fā)時間對業(yè)務(wù)的影響降到最低而努力的環(huán)境。如果開發(fā)者不能擺脫這種心態(tài)的話將難以達成以上愿景。一切策略開始的前提是，向他們表明我們正在嚴(yán)肅地考慮做一些改變，這通常包括尋找減壓的方式，即使那只是暫時的。

但是即使這樣，開發(fā)者仍然只會關(guān)注自己，除非再做一些改變。他們關(guān)于如何提升自己的工作成效會有大量的主意，其中一些想法可能很不錯，但是有風(fēng)險。我們需要讓開發(fā)者轉(zhuǎn)移對自身壓力的關(guān)注，而將注意力集中在將軟件開發(fā)時間對業(yè)務(wù)的影響降到最低上。我們需要讓他們直面客戶痛苦。

使開發(fā)者直面客戶痛苦

我們接下來該如何使開發(fā)者直面客戶痛苦呢？不計其數(shù)的人已經(jīng)對此寫過詳盡的文章，所以這里我只是輕描淡寫一下。這兒按照從最低效到最高效的順序有三條觀點：

1.讓開發(fā)者將使用自己制造的產(chǎn)品作為他們?nèi)粘９ぷ鞯囊徊糠帧?/STRONG>

這在業(yè)界被稱為喝自己的香檳，或吃自己的狗糧。這樣做的好處是使開發(fā)者變成了產(chǎn)品的用戶，所以任何明顯的錯誤或問題也會令開發(fā)者自己感到煩惱。這種方法存在一個問題，那就是開發(fā)者并不是典型的用戶（大多數(shù)時候）。開發(fā)者使用軟件的方式通常有別于大多數(shù)的客戶，所以盡管這樣可以幫開發(fā)者修復(fù)主要的漏洞，但是可能無法為典型的使用案例提供很好的見解，而且這也并非一直具有實踐性。比如說，假想我們正在為牙科保健員生產(chǎn)一個SaaS產(chǎn)品，這時開發(fā)者可能很難將這SaaS產(chǎn)品融入他們的工作流。

2. 讓開發(fā)者在支持團隊中輪班工作。

一個更佳的方式是鼓勵開發(fā)者參與到一些產(chǎn)品的支持團隊中去。（他們可能需要極強的鼓勵。）這張方式可以讓開發(fā)者親自體驗客戶痛苦。所以，他們接電話或收郵件（或推特，或其他種種）時，客戶告訴他們問題所在。開發(fā)者做這件事長達一定時間后，他們也將會開始發(fā)現(xiàn)常見問題的規(guī)律，他們會注意到一次次涌現(xiàn)的問題。無需重復(fù)聽那些相同的牢騷會成為修復(fù)軟件可用性問題的一大動力。不幸的是，人們幾乎不會聯(lián)系支持部門告訴他們產(chǎn)品運行得多么棒，所以得到的反饋是有點偏見的。

3. 定期讓開發(fā)者坐在用戶身邊，看他們是如何使用軟件的。

這種方法是最不方便的，因為它需要最多的組織進行協(xié)調(diào)，但這也可能收獲最好的結(jié)果。利用這種方法，開發(fā)者可以得知正常人是如何在現(xiàn)實生活中使用軟件去做實在的事的。他們能看得到好的、壞的和丑的。

長期持續(xù)這樣做是一件辛苦的事，需要耗費精力，需要進行組織,而且大多數(shù)開發(fā)者會對此有一種本能的抵觸。我寫這個感覺有點笨拙，因為雖然我理應(yīng)做這件事，但我并沒有經(jīng)常這樣做，但我相信值得付出努力做這件事。

使開發(fā)者直面客戶痛苦是一種用悉心努力克服認(rèn)知偏見的訓(xùn)練過程。這是一條“讓人學(xué)會謙卑”的漫漫長途。我們開發(fā)者往往認(rèn)為我們要更聰明，而且許多開發(fā)者還要更加聰明，但是我們并不是無所不知。也許我終于搞清楚了一元綁定運算和操作組合的關(guān)系，這很好，但是這并不意味著我知道了我們客戶每天使用我們的軟件時會遇到什么。使開發(fā)者直面客戶痛苦提醒我們自己我們所真正了解的東西是多么有限。

在我的經(jīng)歷中，開發(fā)者越孤立于周遭，生產(chǎn)的最終產(chǎn)品越差。大多數(shù)團隊層次中，有一層為業(yè)務(wù)分析師，他們認(rèn)為讓開發(fā)者免于接觸用戶是他們的工作，反之亦然，其實這樣做是沒有用的。若創(chuàng)造了一個開發(fā)者對于用戶一無所知的環(huán)境，那么這種狀況是非常危險的?！狫eff Atwood [9]

現(xiàn)在，所有這種面向客戶的溫情舉措非常模糊，都存在一個明顯的問題。簡單來說，這并沒有讓開發(fā)者的開發(fā)速度更快。事實上，這奪走了本應(yīng)該用來編程的時間，所以可以認(rèn)為這反倒使得開發(fā)速度變得更慢。所以我為什么認(rèn)為以上說法對呢？簡單來說就是如果你工作奮進的方向是錯誤的，那么開發(fā)速度的提升沒有絲毫意義。使開發(fā)者直面客戶痛苦重要的是方向而非速度。

咨詢開發(fā)者

我們想要可持續(xù)性地將軟件開發(fā)時間對業(yè)務(wù)的影響降到最低，我的假設(shè)是如果你為開發(fā)者指引了正確的方向，那么你可以在此基礎(chǔ)上咨詢他們接下來該如何做的意見。如果我們讓他們落實他們的意見，那么我們便應(yīng)該能看到結(jié)果。

理想地來說，這是一個持續(xù)推進的過程。我們問開發(fā)者他們是否有任何能夠加快軟件開發(fā)速度的方法，然后我們對提供的方法進行試驗，幾周之后再回來，打聽進展?fàn)顩r，繼而再去問開發(fā)者加速的方法。就這樣一直問他們，直到你每次你連問都不用問就可以直接進入他們的工作區(qū)域。他們于是開始這樣說：“我們所做的路由引擎的重構(gòu)真的成果不錯。但是我覺得如果我們把那種邏輯的一部分移出來，放入微服務(wù)層，那么我們就可以更快地進行縫補和撕毀?！蹦憧赡懿⒉恢滥且馕吨裁?，但是如果我們看到漏洞減少、客戶更加滿意，那么大家就都成為了贏家。

具體到你自己的團隊，用什么樣的方式詢問他們?nèi)Q于你自己。有些人喜歡頭腦風(fēng)暴研討會，另一些人更傾向于調(diào)研或一對一專訪。每種方法都有其不同的優(yōu)缺點，但是無論你選擇哪種方法，請確保弄清了限制。如果你僅有一筆很小的預(yù)算，要明說。如果沒有靈活延長任何截止期限的余度，請告訴開發(fā)者。假設(shè)你擁有聰明的、能干的開發(fā)者，他們能夠把以上這些都考慮在內(nèi)。而且如果他們沒搞明白，甚至在你多次解釋說明后仍不明白，那么你也從中學(xué)到了點東西……

務(wù)必在探討限制時小心謹(jǐn)慎。如果你告訴開發(fā)者沒有預(yù)算、截止期限是定死的、沒有一丁點回旋的余地……那么他們無疑將回復(fù)你他們無力幫助，這種情況下你應(yīng)該格外小心。高質(zhì)量軟件若想要提高生產(chǎn)速度，就需要花費金錢。開發(fā)者需要知道我們愿意為他們和他們的工具投資。如果沒有預(yù)算、沒有延長截止期限的余地、沒有情況好轉(zhuǎn)的跡象……那么聰明的開發(fā)者就會去考察其他方面，這種做法讓我喝彩。這是一種沒有勝方的局面，這種局面會吸引情感投資。向開發(fā)者展示我們在乎、并且愿意向他們和他們的未來投資,向他們解釋我們目前正處于資源嚴(yán)重受限的困境，這樣他們便可能會愿意想一些創(chuàng)造性的解決方案幫我們掙脫當(dāng)前困境。

假設(shè)

我在這兒要做一個較大的假設(shè)，我假設(shè)當(dāng)你向你的開發(fā)者解釋限制時，他們都很聰明，完全能夠理解。最大最顯而易見的限制就是我們并沒有無窮無盡的金錢去揮霍。開發(fā)軟件很費錢，遠(yuǎn)比大多數(shù)人預(yù)期的或意識到的要多得多。好的軟件開發(fā)者得花不少錢去請。我在這兒的假設(shè)是有至少有一個或兩個聰明的開發(fā)者可以能夠理解以上情況。

可悲的是一些開發(fā)者就是不理解，那么你該怎么做呢？答案并不簡單，但是我推測開發(fā)者不理解的原因是他們從來都沒有機會以更大的眼光去看待問題。他們只被要求做去做不現(xiàn)實的預(yù)算和加快開發(fā)速度，并沒有從客戶或那些付他們薪水的人的角度去考慮問題。唯一使他們開始理解的方式就是有人展示給他們看。

我要做的另一個大假設(shè)當(dāng)我們把開發(fā)者帶到委托人員面前時，我們相信他們不會讓公司難堪。當(dāng)然了，也有很多次我和委托人開會時，開發(fā)者說了蠢話或宣泄不滿的情況，畢竟并不是每個人都做好了站在幻燈片前展示推銷游說本領(lǐng)的準(zhǔn)備。但是如果我們相信一個開發(fā)者能夠僅禮貌地握握手打招呼，那么他們當(dāng)然至少也能做到坐在一角，靜靜地看人們使用軟件？[10]也許他們需要有人首先能帶帶他們。但是如果從來沒被給過機會，一個人還能以什么方式去學(xué)做一個組織優(yōu)秀的大使呢？

但是我離題了，咱們回到提升軟件開發(fā)速度上。

安全帶和引擎升級

咱么假設(shè)你的團隊里全是聰明的開發(fā)者。當(dāng)你讓他們出主意時，他們可能首先想出許多聽上去是反直覺的東西，比如像：

• 測試驅(qū)動開發(fā)（TDD）

• 持續(xù)集成

• 結(jié)對編程或mob編程

• 代碼審查

所有的這些技術(shù)都會降低開發(fā)速度……TDD很像是完成同樣的結(jié)果卻用了兩倍的代碼量，而結(jié)對編程就像利用了兩個高產(chǎn)的開發(fā)者卻將結(jié)果削減了一半。我能理解一些質(zhì)疑，但這不只是時髦的流行語（大多數(shù)的這些技術(shù)已應(yīng)用了幾十年之久），它們自然有存在的充分理由。

讓我試著用類比解釋一下：當(dāng)你開車時，你要系安全帶。近些天我們希望車能自帶安全氣囊和防撞緩沖區(qū)，但是當(dāng)你想開得真的很快時，你要戴賽車安全帶、頭盔和防火服，我們還會將翻滾護架、氣流偏導(dǎo)器和粘型輪胎加到車上。這個類比不完美，但是希望你能明白我想表達什么。首先，一些諸如TDD和代碼檢查的方式會使你開發(fā)速度變慢，他們會變得笨拙，不易習(xí)慣。但正是這些保障團隊更加安全地加速進展。

我們非常確信當(dāng)維護費用——許多時間和金錢考慮在內(nèi)時，TDD節(jié)省了時間和金錢?！狤ric Elliott[11]

像TDD和持續(xù)集成這樣的技術(shù)是關(guān)于提升軟件質(zhì)量的，這意味著生產(chǎn)中會產(chǎn)生更少的漏洞。在漏洞流出前將其捕獲意味著會減少重做的次數(shù)、減少尷尬、更愉悅客戶。問題通常會被更快（耗資更少）得被修復(fù)。隨著時間流逝，不耗費在修復(fù)漏洞上的時間增加。另外，這些技術(shù)支撐下寫出的代碼往往更為靈活，更易改變或再用。這意味著我們可以花費更少的時間去對抗脆弱的代碼庫，能花費更多的時間去添加新的特征或修改功能。最終結(jié)果是軟件更好，開發(fā)速度更快。

加緊反饋環(huán)

這樣的要點是減少從寫代碼到交付客戶所經(jīng)歷的時間。這樣的話，開發(fā)者可以觀測到新的代碼是如何減少客戶痛苦的。掌握了客戶反饋，那么他們可以進一步提升代碼等等，這樣我們就創(chuàng)造了一個良性循環(huán)。

我們的轉(zhuǎn)變就是從真實用戶那兒獲得反饋的時間大大減少?！狿hil Wills[12]

如果你在過去幾年一直在追隨IT發(fā)展趨勢，那么對良性循環(huán)一定很熟悉。良性循環(huán)聽上去很像持續(xù)交付，但是這種流行語并不是重點。持續(xù)交付只是一套實踐的標(biāo)簽而已。而且，這些實踐能夠提供緊湊的反饋環(huán)，反饋環(huán)能夠使得我們在提升速度的同時減少風(fēng)險。

這樣做有一個很好的理由。我們所建立軟件的環(huán)境不僅麻煩而且復(fù)雜，一個麻煩的系統(tǒng)有許多部分，實則讓一個專家都要好好理解這么多的部分是如何結(jié)合在一起的。但是一個復(fù)雜的系統(tǒng)不僅僅有許多部分，而且所有的部分都彼此連接，相互作用。所以，當(dāng)你改變了一小部分后，那么整個系統(tǒng)可能都會因而發(fā)生變化。一個經(jīng)典的案例就是眼鏡蛇效應(yīng)：

英國政府對德里的有毒眼鏡蛇數(shù)量非常擔(dān)憂，因此每捕殺一條眼鏡蛇，政府就會發(fā)放一筆賞金。起初這是一個非常成功的策略，因為很多人為了賞金開始大量捕殺眼鏡蛇。然而最終，激進大膽的人為了收益反而開始專門飼養(yǎng)眼鏡蛇。當(dāng)政府意識到這種情況后，這一獎勵計劃便被取消了，眼鏡蛇再無價值，于是導(dǎo)致飼養(yǎng)眼鏡蛇的人只好將其放生，所以野生眼鏡蛇的數(shù)量進一步增多。[13]

在復(fù)雜的系統(tǒng)中，很難預(yù)測一次給定改變所可能產(chǎn)生的影響，這是因為做兩次相同的改變可能產(chǎn)生截然不同的結(jié)果，第一次改變能引起一定的系統(tǒng)反應(yīng)，在下一次中會完全不同。這樣會導(dǎo)致非本意的結(jié)果，使計劃和預(yù)估出現(xiàn)問題。

理解復(fù)雜性的方式是，在空間中的動作會導(dǎo)致空間發(fā)生變化，而且原因和結(jié)果只有在回顧時才能被理解?！狶iz Keogh[14]

那么我們在一個復(fù)雜的環(huán)境中如何設(shè)法去完成每件事？專家建議“探索、感知并且回應(yīng)?！睋Q句話說，創(chuàng)造緊湊的反饋環(huán)去評估哪些事能成或不能成。然后我們盡快重復(fù)此動作，保持小變化、短周期。因此，與失敗關(guān)聯(lián)的風(fēng)險也控制到很小，恢復(fù)的成本也更低。我們要做很多小實驗，保留工作正常的，恢復(fù)工作失敗的。

在一個復(fù)雜的環(huán)境中，你探索、感知并且回應(yīng)，你做一些可能失敗的小風(fēng)險的事，這會幫助你對你所應(yīng)對的環(huán)境有所了解，這是高反饋、風(fēng)險和創(chuàng)新的沃土?！狶iz Keogh[15]

結(jié)論

我們不能僅靠“最佳實踐”建立一支高水平開發(fā)團隊。不幸的是，軟件開發(fā)中幾乎沒有捷徑，但是當(dāng)我們能夠謙卑地承認(rèn)我們并非無所不知時，總能利用一些方式能干得很好。

讓開發(fā)者直面客戶痛苦縮小了反饋環(huán)，這使得我們確信如果我們加快開發(fā)速度，那么我們一定在正確的方向上加快速度。一旦達成了這一點，我們便能夠以一種適應(yīng)給定情況的方式進行持續(xù)的改進了。

腳注

1. Susan Moore, 2015, “IT Projects Need Less Complexity, Not More Governance”, Smarter With Gartner, 17 July 2015

2. There are other business activities that do not directly deliver value. Things like payroll, accounting, managing taxation, and compulsory reporting. These are all important things, essential to keeping the business running. They are part of the cost of running the business.

3. Greg Veen, 2017, https://twitter.com/gregveen/status/835259928352714752, Twitter, 25 February 2017

4. Dan North, Beyond Features and Software that fits in your head

5. When the watergile scrumfall movement blew through we re-named them. Now we call them scrum masters and product owners. But in essence, the roles are still analogous.

6. Douglas Hofstadter, G?del, Escher, Bach: An Eternal Golden Braid, quoted in Wikipedia, Hofstadter’s law

7. Steve Smith, The 5 Laws of Software Estimates

8. As if reducing the estimate will somehow magically reduce the time it takes to build.

9. Jeff Atwood, 2005, ‘Ivory Tower Development’, Coding horror, 7 February 2005.

10. Yes, yes, I know there are some developers who can’t even be trusted that far. And if they really can’t be trusted to represent the organisation well, but are miraculously still a valuable coder—then by all means make an exception for them.

11. Eric Elliott, 2014, ‘The Outrageous Cost of Skipping TDD & Code Reviews’, Java Scene, 14 December 2016

12. Phil Wills, 2015, ‘Delivering Continuous Delivery, continuously’, The Guardian, 5 January 2015.

13. Wikipedia contributors, 2017, Cobra effect, Wikipedia, The Free Encyclopedia, 9 May 2017.

14. Liz Keogh, 2015, Cynefin for Developers, 7 January 2015

15. Liz Keogh, 2012, Cynefin for Devs, 11 March 2012.

本文地址： http://m.registerjl.com/suibizatan/444.html

版權(quán)聲明：內(nèi)容均來源于互聯(lián)網(wǎng) 如有侵權(quán)聯(lián)系刪除