從瀑布式開發(fā)到DevOps，有許多運動在努力推動軟件編程效率的提高。但是，并非所有人都能將開發(fā)人員從壓力下解放出來，以更快地交付結(jié)果。

自從2000年代初期出現(xiàn)極限編程（XP）以來，軟件專業(yè)人員一直在嘗試尋找新的方法來開發(fā)質(zhì)量更高的應用程序，這些應用程序在越來越緊迫的期限，較小的預算以及資源日益減少的情況下進行。這些努力的大部分推力是由于當時將內(nèi)部人才外包給價格較低的外國公司的新商業(yè)風潮所帶來的越來越大的創(chuàng)傷而給IT組織施加的壓力的結(jié)果。從真正的意義上說，專業(yè)軟件開發(fā)社區(qū)（尤其是在美國）所遭受的創(chuàng)傷促使人們越來越多地避免采用成熟的策略，以便滿足在同樣的生產(chǎn)壓力下卻沒有勇氣進行管理的技術(shù)管理。情況不斷惡化。

XP開發(fā)范例是第一個嘗試減少實際項目開發(fā)基礎的制定工作，其中包括初始計劃分析，需求分析，設計過程分析，進度分析以及由于計劃風險分析而進行的適當項目調(diào)整。想法是，由于新的微型計算機開發(fā)過程而越來越多地完成了一些項目，因此可以繼續(xù)以代碼優(yōu)先結(jié)構(gòu)來實施項目，而代碼優(yōu)先結(jié)構(gòu)仍然困擾著當今的許多IT組織。確實，XP并不打算消除所有這些基礎，而只是降低它們的重要性，而忽略了它們對高質(zhì)量軟件開發(fā)的關(guān)鍵應用程序的現(xiàn)實。

在XP之前，所有軟件開發(fā)都是在標準的“瀑布”過程中完成的，通過該過程設計了主項目設計，并適當?shù)赜媱?，分析和設計了每個步驟，然后實施了這些步驟，而每個階段所需的調(diào)整和缺陷都很簡單通過循環(huán)回到某個階段的初始起點，更正問題然后再次進入該階段來解決問題。在大型機時代這是一個耗時但最終成功的過程，并且成功地進行到了微型計算機發(fā)展的初始階段。

不幸的是，最初制定最終XP范式的嘗試經(jīng)歷了成功與失敗的bag貶不一，最終使該項目被取消，而XP則失敗了。在新興的微型計算機領域中，這都不是那么受歡迎。在許多人看來，它只是一種忽略經(jīng)過時間檢驗的開發(fā)過程的方法。而且它包含配對編程對許多信息技術(shù)領域的資深人士來說意義不大。

盡管如此，當時的專業(yè)人員仍在通過XP嘗試推廣的基本概念來尋求方法，以定義新的軟件成果。管理層（無論是技術(shù)人員還是非技術(shù)人員）間接地幫助了這一過程，最終消除了許多組織中的業(yè)務和系統(tǒng)分析人員層（也是由于大量外包以及聲稱有必要降低成本的說法），但沒有根據(jù)開發(fā)人員除了可以掌握其技術(shù)技能外，還可以吸收此類專業(yè)知識。

敏捷和DevOps

這個過程最終導致了敏捷開發(fā)范例（在某些情況下將包含XP概念），在過去的幾年中，一些組織現(xiàn)在正在讓步，轉(zhuǎn)向其概念的更企業(yè)版本，現(xiàn)在稱為DevOps。這種新的結(jié)構(gòu)是嘗試將開發(fā)和運營更緊密地集成在一起。但是，這已經(jīng)通過諸如ITIL（信息技術(shù)集成框架）之類的經(jīng)過更長時間測試的較早框架來完成。不幸的是，現(xiàn)在有這么多年紀更大，更高級的專業(yè)人士離開了該行業(yè)，幾乎沒有什么可以幫助年輕員工適應這樣成熟的過程，使他們相信自己正在用自己的解釋創(chuàng)造新的東西。

敏捷和DevOps追隨者都制定了自己的宣言，從本質(zhì)上講，這意味著這種范例既具有意識形態(tài)，又具有技術(shù)性。這種說法本質(zhì)上比實際的可靠軟件工程實踐更具意識形態(tài)意識，這可以通過開發(fā)商開發(fā)新工具來適應他們的需求來證明，這些新工具可以適應它們的使用，并且背后隱藏著越來越多的“運動”，而這些運動通常非常在他們的支持中發(fā)聲。盡管未必一定將其設想為某種意識形態(tài)，但閱讀許多推廣這些范式的文章可提供充分的證據(jù)，表明實際的意識形態(tài)涉及此處。

相反，軟件工程本身已經(jīng)制度化，幾乎沒有任何聲名狼藉的團體在鼓勵在IT組織基礎結(jié)構(gòu)中使用它。它的實踐涉及的原理，實踐和過程各不相同，并且包含許多可應用于任何類型的軟件開發(fā)工作（無論大?。┑墓δ?。這些功能還包括與敏捷所吹捧的流程非常相似的流程。

軟件工程的實踐基于對開發(fā)范式和項目分析的多年研究，后者包括成功和失敗的項目以及與之相關(guān)的因果關(guān)系。結(jié)果就是為軟件開發(fā)專業(yè)人員提供了度量分析，例如與成功的過程改進范例，CMMI或“能力成熟度模型集成”一起推廣的度量分析，可用于軟件開發(fā)工作。通過度量分析，可以建立數(shù)學基礎來正確分析和預測任何項目工作的期望。

盡管CMMI不直接與軟件工程相關(guān)，因為它還必須在一般業(yè)務和其他技術(shù)流程（例如庫存管理）中實現(xiàn)效率，但它確實提供了允許將軟件工程分析與已證明的開發(fā)項目正確集成的流程隨著時間的推移，以確保最短的開發(fā)進度在預算之內(nèi)，同時消除缺陷，使某些項目可以聲稱生產(chǎn)中的零缺陷可交付成果。

不幸的是，這兩個非常成功的流程環(huán)境都與大多數(shù)業(yè)務和技術(shù)管理背道而馳，以至于兩者之一的實施對于它的從業(yè)者以及想要從事學習和后續(xù)集成工作的人來說，通常都是一場艱苦的斗爭。這種對實用軟件工程范式的明顯拒絕基本上被認為是違反直覺的，這基本上植根于軟件開發(fā)經(jīng)理和他們自己的主管的心理中，他們通常更愿意滿足難以捉摸的期限而不是產(chǎn)生實際的質(zhì)量。

盡管敏捷和DevOps范式似乎比其他任何事物都更具文化理論，但兩者都已成功實施，并且有度量標準可以證明這種成功，但涉及的專業(yè)人員更有可能實際實施了完善的軟件工程方法和/或過程管理技術(shù)，而不是與這些新技術(shù)化身中的嗡嗡聲和炒作實際相關(guān)的任何東西。毫不奇怪，如果您要去軟件工程學院 ，將會發(fā)現(xiàn)在該組織所做的研究中提到了敏捷，但在預期的情況下卻沒有。相反，您會發(fā)現(xiàn)Agile從屬于實際的軟件工程實踐。

簡單地總結(jié)一下；除了如何開發(fā)高質(zhì)量軟件外，您不能開發(fā)高質(zhì)量軟件。您可以更改處理方式的范式，但是如果它不包含將產(chǎn)生可交付成果的必要構(gòu)造，則范式本身并不會帶來太大的意義。取而代之的是，人們經(jīng)常吹噓Google等成功的公司如何投資和使用諸如Agile之類的新架構(gòu)，現(xiàn)在它已成為DevOps的最新企業(yè)化身。但是，沒有標準軟件工程實踐中的合理概念，諸如Google，Microsoft和其他公司之類的高科技公司就無法生產(chǎn)其高質(zhì)量的產(chǎn)品。但是，這些組織并沒有完善的軟件生產(chǎn)記錄，實際上遭受了嚴重的失敗，表明在這些非常成功的實體中甚至有些不對勁。但是，對于他們的優(yōu)質(zhì)產(chǎn)品，他們的開發(fā)范例可能被稱為軟件工程以外的東西，但它們?nèi)匀粌H僅是這樣。任何認為否則的人都只是在自欺欺人。

敏捷已經(jīng)試圖糾正XP的原始缺陷，但是在許多IT組織中似乎都采用了XP，但是它并沒有采取很多措施來彌補這一缺陷。在這樣的組織中，它仍然可以“忘記要求和設計，只需要編寫代碼……”。

初步計劃分析：兩個基本概念

無論您稱其為軟件工程還是其他專業(yè)，成功的初始計劃分析都必須是任何新項目或新任務的第一階段。忽略其至關(guān)重要的意義是最終確保一定程度的項目失敗。為此，然后我們可以理解為什么如此眾多的軟件嘗試繼續(xù)以大約70％的高比率失敗，而這仍然是IT行業(yè)的總體項目失敗率。

許多人指出，在所有技術(shù)專業(yè)人員中，我們的專業(yè)仍然是唯一從未真正成熟為具有確定的標準和流程以生產(chǎn)高質(zhì)量可交付成果的專業(yè)。這直接歸因于以下事實：年輕，后代的新專業(yè)人員仍在嘗試尋找神奇的靈丹妙藥，使他們能夠在技術(shù)和業(yè)務管理制定的日益不可能的情況下創(chuàng)造優(yōu)質(zhì)產(chǎn)品。鑒于目前的趨勢，人們會期望在將來的某個時候，該行業(yè)會出現(xiàn)系統(tǒng)性的徹底失敗，因為對這種公式的徒勞的搜索仍在繼續(xù)，因為對任何高質(zhì)量軟件產(chǎn)品的創(chuàng)建速度都存在一定的限制。

應當指出，從軟件工程的角度來看，項目失敗不是全部或全部的構(gòu)造。如果未滿足計劃項目的任何方面，則將導致此類項目失敗。因此，如果一個項目超出預算，不能滿足規(guī)定的要求，不能滿足預定的期限或僅在處理過程中出現(xiàn)缺陷，則該項目將被視為統(tǒng)計失敗。這種構(gòu)造的結(jié)果是，在失敗的領域中，不必考慮某個項目是不可使用的。但是，實際上很多事實都是這樣。

合理的初步計劃分析必須在目標用戶和開發(fā)人員之間開始，并且要有兩個基本的理解……

1. 項目預期目標

2. 用戶希望控制的整個項目的各個方面

相信或不了解新項目或任務的預期目標對于其成功至關(guān)重要。因此，理解這種概念還將定義項目的預期范圍。因此，最終為此目的而計劃和設計的一切都將受到這種約束。沒有這樣的限制，開發(fā)團隊就無法進行準確的計劃和實施階段，因為在這種情況下，該項目只是開放式的以適應需求。

不幸的是，大多數(shù)項目已經(jīng)并且仍然是開放式的，期望代碼庫應盡可能靈活以包含必要的新要求。然后，這種類型的項目設置將向技術(shù)經(jīng)理開放，在某些情況下，開發(fā)人員將首選“如果...怎么辦？” 思考的場景。雄心勃勃的技術(shù)經(jīng)理或技術(shù)人員經(jīng)常提倡這種情況，他們希望其項目易于擴展，以便可以添加任何內(nèi)容。這些人員認為，所有代碼都應該是可擴展的，并且在許多情況下是通用的，因此從字面上可以像傻瓜一樣模制。這種思想是許多軟件項目所遭受的神奇思想的根深蒂固的一部分。

一方面，人們只能現(xiàn)實地規(guī)劃已知的要求，同時要注意是否可能包含特定過程的變化，例如數(shù)據(jù)的導入。在項目的后期階段，可以在可能添加的范圍內(nèi)考慮某些過程。但是，這里也有必要在某種程度上將這種定義包括在內(nèi)。說一個項目可能需要通過MSMQ導入過程數(shù)據(jù)的能力實際上并沒有說什么，因為即使在這里也需要精確的計劃。

但是，由于開發(fā)團隊無法專注于已知需求，而不得不在已知與未知之間進行分配，因此，這樣的項目是最終項目失敗的良好候選者。如果您實際上可以聘請可以預測未來的人，那將是一個不錯的技巧。這種開放性思想的結(jié)果是，一個簡明的項目無法成功地計劃和實施，以實現(xiàn)質(zhì)量的完成，因為項目的范圍經(jīng)常定期更改，從而迅速引起“功能蠕變”，這是遭受其后果的許多項目的禍根。

但是，有許多成功的項目實際上都在計劃可擴展性，但是這種能力是已知的或預期的因素，將被包含在項目生命周期的后期階段，這些階段通常包括過程中的主要完成里程碑。因此，例如，如果期望應用程序從許多來源接收可能的導入輸入（即CSV文件上傳），則可以采用以下方式設計將負責此類過程的代碼部分：添加新模塊以合并新的模塊。導入過程遵循易于識別的實施模式。但是，對于有多少技術(shù)經(jīng)理沒有為這種情況做計劃，而是寧愿考慮“異想天開的思想”作為對項目開發(fā)的適當要求，您會感到驚訝。這種想法通常屬于“也許”類別。

上面提到的第二項實際上是任何項目成功的最重要基礎。這是初始項目計劃的一部分，用戶和開發(fā)人員都將決定用戶需要和/或傾向于控制項目的哪些區(qū)域才能滿足其成功實施自己的需求。但是，無法向用戶提供完全控制權(quán)，否則項目將失敗，因為開發(fā)團隊將永遠無法對可用于其自身設計過程的項目范圍施加合法約束。同樣，允許用戶控制項目的整個過程只會使其經(jīng)受“特征蠕變”的持續(xù)有害過程。

軟件權(quán)衡三角

當開發(fā)人員與用戶或用戶團隊會面時，提出項目計劃這一方面的最佳方法是向他們展示“軟件折衷三角”圖片。

為了使項目成功，在整個項目生命周期中，軟件三角形的三個組成部分必須連續(xù)保持平衡狀態(tài)。如果不平衡，則開發(fā)人員和用戶必須就如何重新平衡達成一致。項目越復雜，隨著努力的進行，保持三角形的平衡水平就變得越關(guān)鍵。

同樣，只能允許用戶控制三角形的三個方面中的兩個。因此，如果用戶要控制產(chǎn)品和成本方面，則開發(fā)團隊將定義項目進度表。如果用戶只需要控制三角形的“產(chǎn)品”方面，則開發(fā)團隊可以提供“進度表”和“成本”組合，從而允許用戶選擇最適合其需求的組合。

為了闡明三角形的三個組成部分，我們將它們定義如下：

• 進度表–成功完成項目所需的估計時間

• 產(chǎn)品–假定產(chǎn)品具有所需的功能和質(zhì)量

• 成本–分配給項目的預算和資源

如果用戶堅持對項目的各個方面進行全面控制，則開發(fā)團隊必須通知用戶該項目將無法成功完成。

一旦了解了項目的主要目標并且由誰來控制項目的哪些方面，便會啟動一般項目范圍，以便可以開始實際需求分析。

一言以蔽之

在最初的計劃會議中，開發(fā)人員通常為用戶提供生產(chǎn)級產(chǎn)品的交付估算。用戶和技術(shù)經(jīng)理都認為，由于可能已經(jīng)定義了項目目標，因此經(jīng)驗豐富的開發(fā)專業(yè)人員也可以提供要交付的估計目標數(shù)據(jù)，然后將其作為實際交付日期。沒有東西會離事實很遠。

估計問題就是他們就是那個；在此類會議上，充其量只能根據(jù)一般性進行有根據(jù)的猜測。甚至是有根據(jù)的猜測也將這個概念延伸得太遠了。在項目計劃過程的如此早期階段就可以要求人們提供任何準確度的估計的想法，是由許多在管理高質(zhì)量軟件開發(fā)方面沒有實際經(jīng)驗的技術(shù)經(jīng)理推崇的一種觀念。它使他們對自己的業(yè)務用戶和主管看起來很好，但是這種感覺通常是短暫的。當項目認真開始時，任何這樣的估計都將很快被發(fā)現(xiàn)是完全站不住腳的，這隨后使技術(shù)經(jīng)理處于共同的位置，要求不合理的加班時間向開發(fā)人員施加壓力，迫使他們制定沒有計劃支持的截止日期。

統(tǒng)計中已明確證明，在此過程的早期階段，估計的現(xiàn)實時間對于項目完成所需的時間太長或太短。如下圖所示，這種估計的不準確性可能高達16倍。盡管此信息是20年前定義的，但它的統(tǒng)計基礎仍然與當今的項目相關(guān)，因為提供時并沒有真正改變不支持的項目估算。

所有項目時間表，無論如何計劃和定義，都遵循詳細的進度，從而使開發(fā)人員可以提供越來越準確的目標日期。這種描述準確的完成日期的分階段過程還具有以下優(yōu)勢：通常在最短的時間結(jié)束時，指定的項目本可以以高質(zhì)量的結(jié)果交付。注意上圖中的部分，開發(fā)人員可以提供一個階段到估計到實際完成日期的估計過程，這將使他們在完成這樣的完成日期時比嘗試遵守初始估計要靈活得多。如圖所示，隨著更多的設計數(shù)據(jù)被納入計劃過程，完成日期預測的準確性將提高。

為了在最初的計劃會議中避免這種情況，無論哪一方控制軟件權(quán)衡三角形的組成部分，開發(fā)人員都應主動避免提供任何此類不受支持的估計。相反，最好的做法是通知用戶，在對初始需求進行了適當?shù)姆治鲋螅o論何時完成了初始產(chǎn)品需求），都會向用戶提供一個“評估包”，但需注意的是，這僅僅是一個基于到目前為止已知的有關(guān)該項目的信息的初始估計，以及兩個，隨著計劃的進行，估計將發(fā)現(xiàn)實際上在縮小而不是擴大。

這樣的“估算包”將基于實際項目要求和提供估算時已知的數(shù)據(jù)。但是，只有在已為項目提供了所有要求并且開發(fā)人員可以分解項目中每個組成部分所需的各個時間表時，完成數(shù)據(jù)計劃的現(xiàn)實才有實際意義。

在生成該分析級別之前，可以預期所有此類估計都不過是預期項目何時完成的一般預期。再次，此類初步估計僅是任何經(jīng)驗豐富的開發(fā)人員的最佳受過教育的猜測。

在本系列的后半部分將充實準備反映實際組件時間軸分析的此類估算程序包的細節(jié)。但是，為達到這一點，我們首先必須研究項目設計的第一個關(guān)鍵方面，即需求分析。在這個階段中，將提供項目的許多基本設計數(shù)據(jù)。