當然，IT領導和客戶都希望每個軟件項目都能更快地被交付。但是快速的開發也可能會導致錯誤的代碼、低劣的測試、不完整的解決方案，或者更糟的，不安全的軟件。雖然沒有人想要一個失敗的軟件項目，但有時在某些環境下--包括市場條件、業務需求、機會之窗--可以證明一些有利于速度的權衡措施是合理的。

 

軟件開發不僅僅是一種邏輯上的努力。它也是一門藝術，也是許多組織商業戰略中不可或缺的一部分。如果能夠高效、公平、簡單和安全地完成，在那些重疊的某個地方就存在著獲得更高效的開發流程的可能性。你只需要知道折衷方案，并做出有利于精簡項目而不是開發完美軟件夢想的決定。

 

當IT領導想要加速一個需要快速進行的特定軟件項目時，這里有11個戰略決策可供參考。

 

 

每個人都希望得到反饋，來自營銷團隊、運輸部門和會計部門的利益相關者都是帶著遠大的夢想來到會議室的。訣竅在于首先找到最容易實現的夢想。在一次奇跡般的會議中，我的軟件團隊發現，只需在一個表單字段中添加預填充的默認值，就可以為數據解析器節省數百萬小時的工作。成百上千的銷售代理每天都會從無到有地填寫這張表格。在HTML中多了幾個字符，我們就像天才一樣被對待。

 

讓利益相關者腳踏實地將有助于控制項目的范圍。如果你能讓利益相關者關注那些更小、更有價值的特性和改進，那么復選框的填充速度就會快得多了。

 

 

不僅僅是西裝會讓人忘乎所以。開發人員也需要腳踏實地。對于項目列表上的每一個項目，開發人員都將其視為最終嘗試一些聰明的、新的、非常耗時的流行術語的一個機會。屏幕上有兩列不對齊嗎?現在是時候用純函數重寫整個堆棧來實現多梯度功率下降優化量子學習算法了。

 

雖然開發人員的熱情對于實現一個加速的時間表是至關重要的，但是確保開發人員的熱情能夠被引導到一個精簡的目標上也是至關重要的。

 

 

削減需求似乎是個懶人的游戲。畢竟，如果你將“一切”都重新定義為一個更小的集合，自然就能夠很容易更快完成所有事情了。

 

但有時，讓團隊集中精力也是必要和有用的。巧妙的方法是確保基礎仍然足夠牢固，以便將來能夠重新處理被跳過的特性。例如，確保數據庫模式預期了某些增強功能，而這些功能是有人希望在以后的迭代中能夠添加的。如果這僅僅意味著現在需要稍微調整一下模式，那么當你返回到此過程中被推遲的特性時，也可以節省時間。

 

 

部署代碼的挑戰之一是在運行之前進行測試。最近的趨勢是把所有的東西都拆分成可以獨立運作的小項目。如果每個項目都必須單獨測試，那也就意味著需要進行更多的測試。一些包含大量微項目的新的微服務體系結構必須經過多次測試。

 

顯然你無法擺脫對測試的需求，但其中的一個訣竅是可以測試同時在一起工作的多個項目。有時，將幾個部分捆綁在一起可以消除獨立測試它們的需要。

 

 

如果你打算去掉一些特性，把一些工作留到以后做，有時你可以重新考慮架構的設計。有時則不是。

 

如果這些功能可能會在下個季度甚至明年出現，那么你最好把基礎保留好。但如果它們不是必需的，那么清除掉架構中的大塊內容將會是一種極大的解放。

 

 

當時間充裕時，每個人都希望在毫秒內就得到答案，同時還能夠確保數據被復制到三個地理上獨立的數據中心上，以防颶風和地震的同時襲擊。誰不想要完美呢?

 

但通常，高性能也意味著需要大量額外的緩存層、負載平衡層和復制層，而這些額外的層需要花費時間來進行構建、配置、調試和維護。減少開發時間的最簡單方法之一是說服利益相關者，如果屏幕刷新時間長了一點，希望他們可以稍微放松，或者打消這個想法--他們中的一些人會因為故障而自動消失。并不是每個項目都像腦部手術那樣需要那么多的精確度和可靠性。

 

 

花費更多時間的最簡單的方法就是探索一種新的技術。是的，從長遠來看，對下一代進行投資是很重要的，但現在不是有人敲桌子要求更快完成的時候。使用與你在過去幾十個項目中使用的相同的語言和數據庫會更快更簡單。你將移動得更快，而且有時還可以重用代碼塊。不僅如此，你還將保持一致性，使開發人員更容易在項目之間移動。

 

 

當開發人員想要完成某些事情時，他們喜歡談論“技術債務”。通過現在承諾一個有限的或快速的解決方案，開發人員可以把修復或填補空白的工作留給未來。這是一個需要認真考慮的真實概念，但有時人們的確會想要在操縱流程時調用它。

 

一些技術債務是可以接受的。使用最新的數據庫或最新的語言技術并不總是必要的。有時候，我們可以跳過三代或四代的神奇技術，直接進入最新的版本。跳躍式的前進可以避免很多頭痛和熬夜。

 

這是一種藝術的游戲，它不是沒有危險的。但很多時候，技術債務的幽靈遠比跳過幾代更新的現實更加糟糕。

 

 

太多的項目中有太多的自定義代碼了。如果你想完成某件事情，而很有可能其他人也有同樣的煩惱。有時其他人或組織已經啟動了一個開源項目，現在也正是你加入的機會。

 

開源不是萬能的。天下也沒有免費的午餐。你經常需要做出妥協，并與其他團隊一起工作，以匯集一些適合個人的代碼。當這個流程運行良好時，你只需為開源項目貢獻一小部分時間，那么每個人就都會成功。

 

 

許多項目都可以使用現成的工具來完成。使用標準web表單(比如Drupal、Google Forms或是Survey Monkey)可以構建的內容是令人驚嘆的，這些表單也可以將數據轉儲到執行分析的電子表格中。這不是耍滑頭。它甚至可能不會被程序員防御聯盟稱為是“編碼”工作。但是，如果它可以以一種可靠和可重用的方式交付答案，那么它就是完成大型開發項目最快的方式。

 

 

我們都夢想建立一個病毒式的傳播網站，所以我們總是計劃處理最極端的負載。我看到過一些細心的架構師描述他們的三層系統，其中到處都有負載平衡器和復制的數據庫，所有這些都可以支持一個每天可以照顧100人的項目。如果適當進行擴展是容易的，那就不會是問題，但是增加這些層會增加項目的復雜性，延長構建時間，并使維護變得更加復雜。引入新的程序員也會變得困難得多，而解決哪怕是最小的問題也需要長時間的團隊會議。確實，一些較新的無服務器工具(如谷歌App Engine)簡化了伸縮性，但在復雜性和成本方面也需要進行權衡。

 

優秀的工程師能夠預見未來可能出現的奇怪問題。但是，良好的成本工程需要對可能性有實事求是的態度，也許，當這些異常值出現時，是可以決定接受糟糕的性能甚至是失敗的。

 

版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。