工作流程與過程
技術專案的一個重要方面，但初學者常常忽略的是對大局的理解。他們可能學習了某個工具或語言，但卻不瞭解為了交付一個完整的 Web 應用程式所需的所有庫、工具、系統和工作職責。以下各節將從高層次介紹不同的“大局”方面。
| 預備知識 | N/A |
|---|---|
| 學習成果 |
|
典型的技術組合
在構建網站時，您將使用不同技術的組合，通常稱為“技術棧”。隨著網站變得越來越大、越來越複雜，技術棧也會隨之變得複雜。當您建立演示版，只有您和少數同事會檢視它時，技術棧可能很簡單。然而，一個看似簡單的生產網站的技術棧可能比您最初想象的要複雜，因為它需要做到：
- 快速載入（這是效能的目的）。
- 同時處理大量使用者（它必須能夠擴充套件）。
- 設計良好，以便使用者可以輕鬆訪問其中包含的資訊和服務。
- 易於團隊協作和維護。
從非常高的層次來看，一個 Web 應用程式的技術棧可能如下所示：
Front-end HTML, CSS, JavaScript | Back-end Node.js, .NET, PHP, Python, or some other server-side language | Database MySQL, Postgres, MongoDB, or some other database | Web server Your own, built around a server product such as Apache, or a service like Netlify
在 MDN 上，我們主要關注前端部分，但即使是前端也可以分解成許多不同的部分。以前端為例：
- 您可能會使用 JavaScript 框架（例如 React）來定義組成使用者介面的元件。
- 該框架可能會使用某種模板語言（例如 Mustache）來定義 HTML 結構，同時提供動態包含可變內容的功能。
- 您將透過 CSS 包含資訊來樣式化您的內容，使其與框架相容。這可能以純 CSS、CSS 框架（例如 Tailwind）或預處理器（例如 Sass）編寫。
- JavaScript 專案應包含測試，以確保任何新程式碼新增不會破壞其功能。測試通常使用測試框架（如 Jest）實現。
- 大型網站將使用打包/構建工具（例如 Parcel）來透過減小檔案大小、從生產程式碼中刪除未使用的元件等方式提高效能。
- 以此類推。
注意：您經常會聽到網站和應用程式被描述為使用特定的“架構模式”構建的。例如，模型-檢視-控制器 (MVC) 是許多 JavaScript 框架遵循的一種模式，而 釋出-訂閱 (pub/sub) 通常用於訊息傳遞應用程式。您不必詳細理解這些模式，但熟悉它們對於理解新框架或工具可能會很有用。
除了實際的技術棧本身，還會有一些工具來幫助您管理它或為網站建立資產，例如：
- 計劃工具，幫助您在高層次上規劃整個專案過程中將要做的事情（例如 Miro）。
- 版本控制系統 (VCS)。您可能會使用基於 Git 的 VCS，例如 GitHub。
- 圖形/介面設計軟體包（例如 Figma 或 Canva）。
- 專案管理工具，例如 Trello 或 Asana。
好的，這有很多東西要消化。我們的建議是：不要恐慌！本文的目的不是讓您突然覺得需要學習的東西比以前多了 10 倍而感到焦慮。其目的只是讓您瞭解網站專案的大局，並讓您對可能遇到的一些術語有一個基本的熟悉。
最終，您將對上述幾種工具和技術有所瞭解，但您不會成為所有這些方面的專家，也不需要成為專家——這就是團隊的意義所在。目前，您正在做的事情絕對正確，那就是學習核心技能，例如 HTML、CSS 和 JavaScript。更多的工具和專業化將在您的職業生涯後期出現。
工作角色
在 Web 開發團隊中，涉及許多不同的工作角色；瞭解每個角色都包含什麼很有用：
- 產品經理
-
從產品角度負責整個網站——產品在市場上的表現如何，與競爭對手相比如何？它的優點和缺點是什麼？目標受眾正在尋求哪些新功能，哪些是最高優先順序的？網站的主要成功標準是什麼，最近的新功能如何幫助達到這些標準？產品經理將收集資料並撰寫報告，以幫助團隊瞭解他們的工作效率，並優先安排未來的工作。
- 專案經理
-
負責組織團隊需要完成的工作。專案經理將制定包含優先任務和截止日期的專案計劃，分配人員完成每項任務，定期召開簽到會議以檢視是否達到進度目標並發現任何問題，並根據需要調整計劃。
- 使用者體驗 (UX) 設計師
-
負責瞭解產品目標受眾的需求，並設計產品工作流/體驗，以最有效地滿足這些受眾需求。典型的 UX 問題是“當用戶登陸我們的主頁時，我們應該首先將使用者引導到哪裡？”以及“我們如何才能使註冊帳戶儘可能簡單直觀？”這項工作通常與使用者研究和測試相結合，以更好地瞭解目標受眾，並建立線框圖以傳達想法。UX 設計師是產品經理報告的主要消費者之一。
- 平面設計師
-
負責網站專案的視覺設計工作。平面設計師負責各種設計領域，例如排版、選擇配色方案、建立圖示和其他圖形資產，以及根據 UX 設計師的線框圖建立網站模型。
- 前端開發人員
-
如果您正在閱讀本文，這（可能）就是您的目標！前端開發人員使用 HTML、CSS 和 JavaScript 建立使用者互動的網站視覺部分，將 UX 和平面設計師建立的行為和視覺模型變為現實。
- 後端開發人員
-
負責網站的非視覺部分。他們編寫後端程式碼來請求內部資料，從模板生成 HTML 頁面，並處理使用者提交的外部資料。他們還處理 Web 伺服器配置、確保網站安全等。
- 全棧開發人員
-
同時處理前端開發和後端開發任務。
- 質量保證 (QA) 工程師
-
負責測試新功能以確保它們正常工作並報告錯誤，與開發人員溝通以幫助他們優先處理必要的修復。
- 內容專家/技術撰稿人
-
負責確保網站的文字內容儘可能地適合目標受眾。這包括資訊結構及其導航方式、使用者介面文字標籤、部落格文章、營銷文字和產品文件。
不太常見的工作角色
其他不太常見的工作角色包括：
- 使用者研究員
-
大型團隊通常會有一個專門的研究員來進行使用者研究和測試。
- 搜尋引擎最佳化 (SEO) 專家
-
分析網站的內容和結構，並進行更改，以使網站在相關的搜尋引擎結果中更顯眼。有關更多資訊，請參閱 SEO。
技術專案階段
一個典型的技術專案可能按以下方式進行：
- 產品經理確定了一組新的網站使用者需求。
- 他們與團隊討論，並決定可以透過向網站新增新功能來滿足這些需求。
- 專案經理與團隊討論建立新功能所需的各項工作，並建立管理這些工作的流程。
- UX 設計師為新功能設計工作流，描述其應如何工作，並建立線框圖以提供其在網站上可能適合的位置的概念。
- 平面設計師設計了一個模型，顯示該功能在網站上的外觀，以及選擇的字型和調色盤。
- 內容專家編寫該功能所需的 UI 文字，以及支援該功能所需的文件。
- 後端開發人員建立必要的系統，以安全地儲存和處理為該功能提供資料的資料。
- 前端開發人員根據平面設計師的模型建立互動式功能，並將其連線到後端，以便它檢索所需的資料。
- QA 工程師徹底測試新功能，並撰寫一份詳細報告，說明他們發現的問題。
- 開發人員修復被認為足夠嚴重以至於應該阻止該功能釋出的錯誤。
- 一旦（阻止性）錯誤得到修復並且專案獲得批准，該功能就可以在網站上上線。
這是一個簡化的檢視——在功能實現本身周圍會存在其他階段，並且這些階段不一定都按所示順序完成，但這為您提供了所涉及內容的概述。
工作管理流程
專案經理將使用某種流程來管理網站專案，監控不同工作項的進度，確保它們按正確的順序和時間完成等。兩種主要的流程型別是：
- 瀑布
-
指以清晰、固定的階段執行專案，每個階段都依賴於前一個階段，並且預計需求不會有太多變化。通常在專案結束時交付一個大型結果。團隊管理傾向於更官僚化，自主權較少。
- 瀑布專案在開始時往往有更好的規範，並且範圍蔓延（專案中期新增需求）較少。此外，更大、不那麼頻繁的產品釋出在釋出計劃、營銷、提供培訓和文件等方面更容易處理。
- 然而，瀑布通常靈活性較差，更改發生的速度也慢得多。等待數月才能獲得錯誤修復可能會令人沮喪。
- 敏捷
-
指更靈活地執行專案，多個階段可以同時進行，並且在整個專案的不同里程碑期間會交付多個較小的結果。需求變更在預料之中，並且可以根據需要透過調整優先順序來處理。團隊通常更具自主性。
- 敏捷專案靈活，可以更容易地適應需求變化。更頻繁的釋出也可能很好——錯誤修復得更快，創新更頻繁，並且營銷團隊總是有東西可以談論。敏捷團隊經常談論持續改進。
- 然而，範圍蔓延和截止日期延遲的風險更大，專案往往感覺從未真正完成，並且交付的節奏和壓力更加持續。
注意：Web 開發團隊通常更喜歡使用敏捷流程，因為軟體開發本質上容易因新錯誤、使用者反饋、公司戰略等原因導致（有時是快速的）需求變化。
Scrum 和看板
有一種特定的敏捷方法學稱為 Scrum，它有一套固定的規則來規定專案如何執行。例如：
- 負責 Scrum 的人被稱為 Scrum Master。這通常只是專案經理的另一個稱呼。
- 要完成的工作被劃分為週期，稱為“衝刺”，通常為期兩週。
- 在每次衝刺之前，會討論潛在的新工作項，如果被接受進入衝刺，它們就會被放入待辦事項列表。
- 工作項從待辦事項列表中取出，並經過不同階段直至完成，例如“進行中”和“審查中”。
- Scrum Master 每天舉行簡短的“站立會議”，每個人都會談論他們取得的進展以及可能遇到的任何問題，以便及早發現問題。
- 在每次衝刺結束時，Scrum Master 會舉行一次回顧會議，回顧哪些方面做得好，哪些方面做得不好，以及在下次衝刺之前可以吸取哪些經驗教訓。
另一種敏捷方法學稱為“看板”，它比 Scrum 規則更少，不使用衝刺，並且更側重於敏捷的持續改進方面。看板特別適用於管理沒有明確定義結束的持續流程，例如客戶支援工單。
看板
Trello 和 Asana 等工具提供視覺化介面，顯示專案中不同工作項的狀態。它們通常被稱為“看板”，儘管它們可以用於管理不同型別的流程，而不僅僅是看板。看板由不同的列組成，這些列可以代表 Scrum 專案中不同的工作狀態（“待辦事項”、“待辦”、“進行中”等）、不同型別的工作（“研究”、“設計”、“開發”等）或對您的專案有用的任何其他內容。
GitHub Projects 提供另一個不錯的工具選項，並且免費使用——您只需註冊一個 GitHub 帳戶。
實踐專案工作流
您應該閱讀上述流程，並練習使用看板跟蹤您的一些工作或個人專案。不用擔心使用複雜的 Scrum 方法；目前基本的看板就足夠了。即使您是獨自一人，練習以下工作流也會很棒：
- 建立任務。
- 決定它們的大小或需要多長時間。
- 確定任務的優先順序。
- 按截止日期排序。
- 開始處理不同的任務。
- 隨著工作的進展設定其狀態（“進行中”、“受阻”、“完成”等）。
跟蹤一個完整專案從開始到結束的進度——嘗試在您自己的網站或某種副專案上進行。此外，嘗試為一個或兩個開源專案做貢獻；它們中的許多專案都會使用類似於我們上面描述的流程來跟蹤它們的工作。
另見
- 什麼是技術棧，它們如何工作？, mongodb.com
- 網站開發團隊結構：角色和流程, truemark.dev (2017)
- 敏捷與瀑布, ProductPlan
- 什麼是 Scrum？, scrum.org