[GitHub Global] Translate Vibe Coding 零基础教程/50 产品变现/06 项目研发流程选择.md to zh-TW

translations/zh-TW/Vibe Coding 零基础教程/50 产品变现/06 项目研发流程选择.md

@@ -0,0 +1,306 @@
+# 專案研發流程選擇
+
+> 跑得快還是跑得穩？
+
+
+
+大家好，我是魚皮。
+
+不知道大家是否喜歡吃辣條？反正我是老愛吃了。
+
+吃辣條的時候，我會思考：美味的辣條是如何被製作出來的呢？
+
+為了滿足自己的好奇心，我還專門到網上搜了一下，結果大為震驚！
+
+發現有些辣條的製作過程是很「先進」的，不是全部靠工人來製作，而是有一條 **生產流水線** 。準備好原材料後，由機器依次完成混合、攪拌、切割、調味、炸製、冷卻、包裝等操作，而工人只需要監督就行。
+
+![](https://pic.yupi.icu/1/6f6e8ad610e6418e9556fb0fb95afda1.jpeg)
+
+有了這麼一套清晰的工序，整個生產辣條的過程就變得井然有序，工人（或機器）只需要一步一步做好自己的事情即可，整體效率更高；而且如果每個環節都經過充分的驗證，辣條的質量和安全性也會更高。
+
+這就是 **標準流程** 的重要性。
+
+回到我們今天的主題，如果我們想要開發上線一款產品，也需要有一套標準的研發流程。
+
+所謂的研發流程是指：為了高效完成產品研發，所定制的 **一系列工作步驟和方法** 。團隊成員只需依次按照這些步驟和方法來工作，就能夠順利完成高質量的產品。
+
+那麼團隊在協作開發時，應該定制什麼樣的研發流程？研發流程的步驟是越多越好，還是越少越好呢？
+
+本篇文章，會結合我自己在大廠工作以及帶小團隊的經驗，依次分享：大廠的標準研發流程、小團隊的敏捷研發、以及我們魚聰明 AI 團隊的研發流程選擇。希望能幫大家開拓思路，提高團隊的專案開發效率和專案質量。
+
+
+
+## 大廠的標準研發流程
+
+這是本文分享的重點。
+
+對於大公司，往往會有成百上千人共同參與一個專案。所以為了保證專案穩定推進，大廠的研發流程通常會非常 **完備和複雜** ，包含非常多的步驟，每個步驟的要求也很嚴格。
+
+我將大廠研發流程的步驟劃分為幾個階段，用一張思維導圖來概括，會更清晰一些：
+
+![大廠研發流程思維導圖](https://pic.yupi.icu/1/3334dda0-2177-4816-bc91-94e7d3b77bde.png)
+
+如果用生產辣條來比喻研發專案。那麼大公司研發專案的流程，就像是我開頭提到的用 **標準流水線** 生產辣條的流程。
+
+> 注意，以上階段並不是完全按從上到下的順序執行，階段間可能存在交叉，比如技術預研和技術選型其實在設計階段就應該考慮。
+
+
+
+### 需求階段
+
+需求階段的目標是：明確我們為什麼要做產品？要做一個什麼樣的產品？產品要有哪些功能？
+
+現在，假設辣條就是我們要做的產品。
+
+由於需求階段是研發流程中 **最開始** 的環節，我會詳細地分為 4 個子階段來介紹。
+
+
+
+#### 需求產生
+
+我們為什麼要做辣條呢？可能是進行了市場調研後，發現大家都愛吃辣條、做辣條能發財；可能是無意中發現了一種改進辣條口味的想法；可能是發現我們的資源很適合去生產辣條等等。
+
+需求產生階段，最重要的事就是盡可能多地收集整理需求，不要放過可能的機會。
+
+有時，可能一個不經意的想法，就是一個很有意義的需求。
+
+
+
+#### 需求評審
+
+收集了很多需求後，我們要對需求進行評審，確定其可行性、成本和收益、需求和風險、以及是否符合我們對產品的定位，而不是什麼都做。
+
+就像我們打算生產一款新口味的辣條，需要先調研評估新的口味會不會受到歡迎、能不能製作出來。
+
+
+
+#### 需求分析
+
+在對需求進行評審後，我們需要進一步分析需求，把需求細化為產品 **具體的** 功能或特性、或者要完成的工作。
+
+比如想生產一款新口味的辣條，我們要確定辣條的辣度和具體口味、研製新的配方、確保辣條的安全性、給辣條設計新的包裝袋等。
+
+
+
+#### 排期
+
+通過需求分析明確需求後，我們要進行需求排期。
+
+這個階段我們要制定生產計劃，根據需求的重要程度和所需資源等，來安排完成需求的優先順序和實現週期。
+
+比如生產辣條時，我們要先花 1 個月研製配方、然後花 3 天採購原材料、花 3 天生產辣條、花 1 天驗證安全性，同時花 3 天給辣條設計新的包裝袋。
+
+
+
+### 設計階段
+
+設計階段我們的目標是：提前想清楚我們的產品要怎麼做？功能如何實現？
+
+對於生產辣條，設計階段的目標就是「確認辣條的配方」。
+
+首先， **架構設計** 就像是確定辣條的主要材料和製作工藝，確保後續可以在此基礎上做出多種不同新口味的辣條，而不是每種新口味的配方都從 0 全新調製（可擴展性）。
+
+**概要設計** 是類似於對辣條的整體構思，比如辣椒的種類、辣椒粉和麵粉的比例、辣條的大小等。
+
+**詳細設計** 是對概要設計的補充完善，深度研究配方中的每種配料的 **細節** 、確定每個步驟的具體要求。比如先放 3 克辣椒粉、再放 100 克麵粉、再混合攪拌 3 圈（我瞎編的）。
+
+完成上述設計後，我們要分享自己的設計，和其他團隊成員共同討論，確保大家的 **方案對齊** 、想法完全一致。而不是等到上市後，讓不同的用戶吃到不同配方的辣條。
+
+在設計階段，不止需要產品經理和研發工程師，測試同學也要參與進來，提前進行 **測試用例設計** 。定義對辣條進行質量驗證的標準，例如具體的辣度在 xx ~ xx 之間、辣條長度為 10 cm 等。
+
+
+
+### 研發準備
+
+研發準備階段，我們要做的是：準備專案研發所需的基礎條件。
+
+比如正式生產辣條前，我們要先進行 **技術預研** ，通過查閱資料來提前調研我們實現新口味配方的可行性。然後我們要進行 **技術選型 **，選擇使用何種工具或機器來調製配方、切割辣條。
+
+完成技術選型後，還要進行 **資源申請** ，確認團隊的資金足夠讓我們使用先進的工具或機器、購買原材料以及配備工人。
+
+在大公司，資源的申請往往非常嚴格，像我在騰訊的時候，想要申請 1 台伺服器來部署專案，都要經過領導、運維等好幾層的審批。
+
+申請到資源後，我們需要進行 **環境準備** ，找一個乾淨衛生、配備水電的場地來放置辣條生產機器和工人。在研發流程中，環境準備的工作就是搭建開發環境、安裝開發必要的軟體和工具等。
+
+之後，我們就可以進行 **專案初始化** 和 **依賴安裝** ，把機器和工人安排到指定的位置、通水通電、啟動機器、安裝機器程式等等，讓一切準備就緒。在研發流程中，我們可能會使用腳手架之類的工具來自動生成一個乾淨的專案初始程式碼，並且使用套件管理器安裝執行專案所需的基本依賴，接下來就可以愉快地寫程式碼啦！
+
+
+
+### 研發階段
+
+研發階段是程式設計師們大顯身手的階段，這個階段的目標是寫程式碼完成專案。
+
+研發階段又可以分為：本地開發、遠端開發、程式碼優化、單元測試、開發聯調 5 個小階段。
+
+首先，每位開發者可以在自己的電腦上編寫程式碼（本地開發），也可以選擇在同一個公共機上協作開發程式碼（遠端開發）。在開發完成基本功能後，要進行程式碼優化，比如增加異常處理來提高健壯性、使用多執行緒來優化效能等。之後，要自己編寫基本的單元測試，來驗證程式碼能否正常執行並返回預期結果。最後，程式設計師們需要相互配合，進行開發聯調，即呼叫彼此的程式碼來驗證完整功能的可用性。
+
+比喻成生產辣條，這個階段就是由機器和人工相互配合，完成對辣條的攪拌、切割、調味、檢驗等操作。由於我沒有參與過辣條生產，不知道他們是不是還有人工試吃環節，如果發現味道不好，還得修一修機器（程式設計師改 Bug）、或者再人工加點兒秘料（程式碼優化）。
+
+
+
+### 測試驗證
+
+在完成開發後，我們必須進行測試驗證，這個階段的目標就是：確保產品功能的正常執行，消滅 Bug！
+
+有同學可能會問：研發階段中，程式設計師不是已經自己編寫過單元測試了麼？
+
+但是，單元測試只是一個最基本的保證，只能保證自己的程式碼沒有問題；如果多人的程式碼需要互相呼叫配合，還需要有更進一步的測試 —— **整合測試** ，來保證大家的程式碼整合到一起也沒有問題。
+
+除了單元測試和整合測試外，比較常見的測試類型還有系統測試、驗收測試。
+
+**系統測試** 是在整合測試後，對整個系統進行全面的功能和效能測試，測試的範圍更大。
+
+而 **驗收測試** 通常是測試的最後一個階段，確認系統是否滿足實際的需求以及用戶期望。
+
+這裡還有一個概念是 **產品體驗** ，是指從真實用戶的角度來感受產品功能的優缺點。嚴格來說，產品體驗不只是在測試階段才進行，而是應該貫穿整個開發過程，便於提前發現問題和改進。
+
+比喻為生產辣條，在我們生產完辣條後，不僅自己要試吃，還要有專業的品嘗師來體驗、檢查辣條的配方和製作是否有問題。
+
+
+
+### 提交階段
+
+提交階段的目標是：把已經通過測試的本地程式碼提交、推送到遠端倉庫，並且合併到主分支，為上線做好準備。
+
+實際開發中，由於專案是由多人維護的，為了減少程式碼衝突和爛程式碼，會採用 **程式碼審查** 機制。想要合併程式碼到主分支前，必須發起 MR（Merge Request） **合併請求** ，然後由專案的負責人（一般是你的領導或同事）檢查你的程式碼，沒問題後才允許合併。
+
+這樣一來，所有的程式碼會經過至少 2 名成員的檢查，程式碼質量會更高，也減少了上線出 Bug 的機率。
+
+比喻為生產辣條，程式碼審查就好像是由專業的食品衛生機構來檢驗辣條生產的安全標準，如果發現配方或生產過程有任何的問題，就打回去重做。
+
+
+
+### 發布階段
+
+經過了「九九八十一難」，我們的專案終於可以發布了！
+
+首先，要把我們生產好的辣條進行打包，變成可以售賣的包裝袋。然後並不是一開始就做大規模的宣傳推廣，而是先給一部分顧客試吃，讓他們給出一些評價。如果大家對辣條讚不絕口，那麼才可以將辣條正式上市，走向大眾。
+
+在研發過程中，我們也要對開發完成的程式碼進行 **打包構建** 。然後先進行 **預發布** （或者灰度發布），給一部分用戶進行體驗；確認沒有問題後，再 **正式上線** 。
+
+
+
+### 後續
+
+至此，我們的研發流程還沒有結束！只能說是完成了一輪上線而已。
+
+產品上線後，我們還需要持續收集和接受用戶的反饋意見，並且對用戶的評價進行統計分析，從而不斷地優化迭代我們的產品。
+
+此外，文件沉澱也是非常重要的，要把我們這次研發流程中遇到的種種問題、資料、知識全部記錄下來，便於團隊繼續改進。
+
+
+
+---
+
+
+
+怎麼樣，感覺大廠的研發流程是不是很複雜？
+
+事實上，完成第一次上線後，每當我們需要給產品增加新功能時，都要完整經歷一遍上述流程！甚至有的時候，光需求評審這一個步驟就要經歷 1 - 2 個星期的討論！
+
+這種研發流程雖然能夠保證專案的質量，但未必適合小團隊，尤其是對於創業公司來說，時間就是金錢。
+
+所以下面再分享一下適合小團隊的研發流程 —— 敏捷開發。
+
+
+
+## 小團隊的敏捷研發
+
+如果說上述大公司的研發流程更注重 **規範和穩定** ，那麼敏捷開發更注重 **團隊協作和快速迭代** 。
+
+在敏捷開發中，上述大廠研發流程的很多步驟都是可以簡化、甚至省略的，非常靈活。
+
+比如上午我們想做一個產品，中午團隊成員一起開會討論需求、並確認產品上線必做的核心功能，下午就直接開始研發寫程式碼了。先用最快的速度完成核心功能、能用就行，然後再持續地討論新需求、持續地開發和上線、改進產品。
+
+把更多的時間都投入在研發上，主打一個快！
+
+![敏捷開發流程](https://pic.yupi.icu/1/image-20230712185656368.png)
+
+如果採用敏捷研發的方式來生產辣條，大概是這樣的：
+
+我們團隊發現某個地區的人非常愛吃辣條，那麼就直接純人工用辛勤的雙手先做個幾包，以最快的速度讓這些人試吃；然後再根據這些人的反饋去改良我們的配方、升級我們的包裝；等大賣之後，再引進機器、買工廠，批量自動化生產辣條。
+
+需要注意的是，敏捷開發是一種軟體開發方法論，具體的方法不止一種，比如 Scrum、Kanban、極限編程等。但是大致了解其基本概念和適用場景就足夠了。
+
+
+
+## 研發流程選擇
+
+在了解了上述的 2 種研發流程後，我們做專案時應該如何選擇呢？
+
+首先要明確一點： **沒有絕對好的選擇** 。無論哪種研發流程，都有各自的優勢，要根據實際情況來選擇。
+
+敏捷開發雖然追求極致的快速和靈活，但也需要團隊成員之間的高度配合，並且帶來的風險也更大。有可能投入了幾周的開發時間後才發現做了個沒什麼用的專案。相對而言，大廠的研發流程雖然需要消耗更多的前期資源和精力，但可以帶來更高的產品質量、以及研發進度的穩定性。
+
+那麼對於我們魚聰明 AI 團隊來說，是選擇跑得快還是跑得穩呢？
+
+答案是：小孩子才做選擇，我全都要！
+
+![](https://pic.yupi.icu/1/image-20230712184257231.png)
+
+首先，分析我們自身的實際情況：
+
+1. 我們是一個小團隊，沒有大公司的資源和基礎建設（比如流水線自動構建平台）
+2. 我們要做的是 AI 類產品，需要快速上線搶佔市場
+3. 我們團隊的同學全在一間 40 平米的小辦公室裡，大家可以緊密協作
+
+從這幾點來看，我們會明顯更傾向於敏捷開發。但是我們在敏捷開發的基礎上，保留了大廠標準研發流程中的設計階段和提交階段，並且給網站做了完備的監控統計，用於持續改進產品。
+
+完整流程如下：
+
+![](https://pic.yupi.icu/1/image-20230712190738396.png)
+
+我們希望網站開發在追求快速的同時，能夠兼顧可擴展性和程式碼質量。因此，一方面我們在設計階段投入了更多時間，採用更通用化的架構設計來支撐整個系統（比如使用微服務架構，獨立拆分支付中心），從而能夠應對未來的業務增長。
+
+另外一方面，在協作開發中，我們使用 Git 來管理程式碼，並採用簡化版的 Git Flow 模型，讓每位研發同學都創建屬於自己的獨立開發分支。等各自的功能開發完成後，由我來負責程式碼審查，通過後再將程式碼合併到主分支，從而保證了主分支的穩定。
+
+程式碼審查界面：
+
+![程式碼審查](https://pic.yupi.icu/1/image-20230712193216012.png)
+
+有同學可能會問了：為什麼把測試驗證階段砍掉了？你們做產品都不測試麼？
+
+理想情況下，產品上線前肯定是由專門的測試工程師來測試驗證的。但現實是，我們團隊沒有測試工程師！
+
+所以我們的策略是：
+
+1. 首先，前端和後端工程師各自開發和自測功能。在上線前，我會與負責該功能的團隊成員一起開會，驗證功能是否正常。
+2. 其次，問題是無法處理完的，系統也是不斷完善的。因此，我們將盡快上線，招募一些內測用戶來體驗系統並反饋 Bug。
+
+這樣一來，我們可以把更多的時間投入到研發上，同時不失去對產品質量的關注和持續改進的機會。
+
+
+
+---
+
+
+
+
+研發流程的選擇沒有絕對的對錯，關鍵是要根據團隊的實際情況和專案需求來定制。
+
+記住這幾個關鍵點：
+
+1. 大廠研發流程注重規範和穩定，適合大團隊
+2. 敏捷開發注重快速迭代，適合小團隊
+3. 可以結合兩者的優勢，定制適合自己的流程
+4. 要保留核心環節（如設計、程式碼審查），簡化非必要環節
+5. 研發流程要持續優化，不斷改進
+
+在 Vibe Coding 時代，AI 可以幫你快速完成開發工作，但是一個好的研發流程，可以讓團隊協作更高效、專案質量更有保障。
+
+加油，找到適合自己的研發流程，讓專案跑得又快又穩~
+
+
+
+
+## 推薦資源
+
+1）魚皮 AI 導航網站：[AI 資源大全、最新 AI 資訊、免費 AI 教程](https://ai.codefather.cn)
+
+2）編程導航學習圈：[學習路線、編程教程、實戰專案、求職寶典、交流答疑](https://www.codefather.cn)
+
+3）程式設計師面試八股文：[實習/校招/社招高頻考點、企業真題解析](https://www.mianshiya.com)
+
+4）程式設計師寫履歷神器：[專業模板、豐富例句、直通面試](https://www.laoyujianli.com)
+
+5）1 對 1 模擬面試：[實習/校招/社招面試拿 Offer 必備](https://ai.mianshiya.com)