業務架構的基本思路大型網站系統有很多功能，一次性明確所有的功能需求並設計出一個龐大的業務架構是一件費力不討好的事情。因為在項目前期，難免會忽視一些瑣碎功能，而隨著開發的進行，也會有很多新的想法產生，基本上不會存在完全按照最初的業務架構設計完成的軟件產品。因此，業務架構不僅要做到“規整功能模塊，厘清產品業務邏輯”，更重要的是如何做到“有規劃性地應對項目過程中的需求變更”。遞進思想傳統的軟件開發基本上都遵循瀑佈開發模型，即項目開發過程必須嚴格按照需求分析、設計、編碼、測試和維護等步驟執行。瀑佈開發模型的流程和產出物如圖2.5所示。在一般的瀑佈開發模型中，每個階段都需要有明確的產出物，通過嚴格的評審後才能進入下一階段。瀑佈開發模型的理想狀態是每個階段隻執行一次，一次性完成整個項目。瀑佈開發模型很大程度上依賴需求分析階段的明確性，因為在瀑佈開發模型中默認需求是充分和明確的，需求幾乎不存在被改動的情況，所以設計和編碼階段都是完全以需求分析為依據的。如果在項目後期才發現有重要的需求變更或者有其他遺漏，往往就會導致項目失敗或者項目重新啟動。圖2.5 瀑佈開發模型的流程和產出物在上節節中曾提到，大型網站系統的需求很難做到完全明確，在項目開發過程中往往會有更好的想法產生。如果我們完全采用瀑佈開發模型的思維方式開發大型網站項目，並且想一次性確定需求並交付項目，那麼很可能在項目的後期才會發現需求有遺漏，或者很可能在網站基本定型後才發現大部分功能使用起來並沒有預想的好。這些情況都會在很大程度上導致項目失敗。瀑佈開發模型的弊端很明顯，即需求必須是完全明確的，對需求的變化適應性差。瀑佈開發模型一般就是我們執行項目時的慣性思維，正是因為這種慣性思維，使得開發者在項目開發過程中對需求的變更是恐懼的。針對瀑佈開發模型的弊端，敏捷開發模型被提出來而且逐漸流行。敏捷開發模型不是確切的項目管理框架，它是一套軟件開發的原則。敏捷開發主張適度的計劃、迭代開發、提前交付和持續改進，並且提倡快速與靈活地看待開發與變更。簡單地說，就是在開發過程中保持溝通，不斷交付完成的部分，並持續地改進，而不是一次性交付項目。遵循敏捷開發原則的項目流程如圖2.6所示。圖2.6 遵循敏捷開發原則的項目流程不過，軟件開發終歸逃不出需求分析、設計、編碼、測試和維護等步驟，沒有一個明確的主體需求也會導致開發無法進行，盲目地持續改進更會造成很大的成本浪費。因此筆者認為瀑佈開發模型的流程也不是不能借鑒。敏捷開發提倡的是溝通，通過持續的溝通和改進最終得到一個滿意的結果，而非以一開始想象中的全部需求來指導整個項目開發。因此，不用在意項目開發是遵循瀑佈開發模型還是敏捷開發模型，關鍵是如何在明確需求的同時適應需求變化。筆者認為，項目開發需要有遞進思想。遵循遞進思想的項目流程如圖2.7所示。可以看到，應先完成主體功能，然後再添磚加瓦，需求不用一次性完全明確，而是持續地進行溝通和改進，每個部分開始編碼前其需求必須是明確的，這樣通過多個遞進階段完成整個項目。圖2.7 遵循遞進思想的項目流程項目流程隻有遵循遞進思想，才能更好地應對需求變化。同樣，業務架構也需要遵循遞進思想，才能有規劃地應對項目開發過程中的需求變更。在明確主體需求的前提下，可以適當省略一些次要或瑣碎功能的細節，但不能完全忽視這些次要或瑣碎功能，完全忽略這些需求會導致工期失控。等主體功能開發完成後，再對次要功能的細節進行明確，等次要功能完成後，再對一些瑣碎的功能進行明確，以遞進的方式逐步細化和修改業務架構。版本計劃逐漸完善在上面曾提到，項目流程隻有遵循遞進思想，才能更好地應對需求變化。那麼，項目應該規劃為多個版本，以方便逐步完成。一般來說，項目版本可以劃分為主功能階段、次要功能階段和優化階段。版本計劃逐步完善的項目流程如圖2.8所示。圖2.8 版本計劃逐步完善的項目流程1.主功能階段主功能階段主要實現整個主體功能，這一階段的業務架構需要完全明確主體功能需求，次要功能和瑣碎功能的細節可以先忽略，但次要功能和瑣碎功能也要體現，因為它們會影響技術架構和迭代計劃。項目開發過程中可能會對主體功能進行調整，但是偏離程度不能太大，不能說一開始隻想要一個網頁，而項目開發過程中卻想加入App客戶端。2.次要功能階段次要功能階段的目標是實現之前忽略的次要功能。這一階段可以根據實際情況進一步細分成多個次要功能階段。在這個階段中，不需要一次性明確全部的次要功能，隻需要明確當前階段的次要功能即可。次要功能階段可能會出現頻繁的需求變更，因為次要功能一般是一些用戶體驗方面的功能，經常會發生改動。但是，最好能按照過往經驗和精品網站的要求做盡量好的方案，這樣能在一定程度上減少需求變更的發生。3.優化階段因為項目開發過程是不停地讓業務部門或者客戶使用網站系統的過程，所以其間難免會有很多新的想法，有一些甚至是從來沒有提及的需求。這些新需求一定不能在主功能階段和次要功能階段添加（除非這些需求所需的工作量非常小，或者這些功能是主要功能或次要功能中必不可少的部分），因為這樣會打亂這兩個些階段的開發節奏和既定計劃，導致進度失控。要想把進度失控的項目重新拉到正常的狀態是很困難的，很多時候失控隻會越來越嚴重。因此，這些需求可以先記錄下來，在優化階段再仔細評估和處理這些需求。在優化階段再處理這些“突發奇想”的需求，既可以保證前面的項目進度，又可以集中控制這些需求帶來的風險。持續優化，推陳出新很多項目的失敗與團隊經驗、技術水平或項目管理水平沒有直接的關系。大部分項目失敗的原因是妄想網站第一次上線就具備市場上所有的好功能，同時還要具備特色功能。這個想法如果占據主動，則會添加過多其實並不需要的偽功能，也會習慣性地修改需求，最後在不知不覺中導致時間成本和人力成本的嚴重超支，以致項目崩塌。對於大型網站而言，由於功能繁多，所以值得斟酌的地方也會有很多，加之項目工期較長，開發人員看上去也充足，因此需求經常被改變，導致項目在不知不覺中失控。羅馬非一日建成。時間成本和人力成本是有限的，好的功能也會隨著市場競爭被更好的功能所取代。而且從用戶使用的角度講，通過多個迭代版本持續學習新功能往往會比一次性地接受過多功能更有吸引力。因此，大型網站項目應該持續優化，且要不斷推陳出新，而非一次性地完成全部功能，即通過一期項目、二期項目、三期項目等有規劃地逐步構建大型網站才是合理的。對於業務架構而言，如果出現一些好的想法或功能，但是其工作量很大，則需要考慮是否將其放在下一期的項目中實現。本文給大傢講解的內容是大型網站架構面臨的挑戰：業務架構的基本思路下篇文章給大傢講解的內容是大型網站架構面臨的挑戰：技術架構的基本思路覺得文章不錯的朋友可以轉發此文關註小編；感謝大傢的支持！