選擇適合團隊的開發流程，是工程效能的基礎。

軟體開發模型#

沒有「最好的」開發模型，只有「最適合的」。選擇模型要考慮團隊情況、項目特點、業務需求。

寶玉在《軟體工程之美》中詳細介紹了各種開發模型。

瀑布模型#

flowchart TD
    A[📋 需求分析] --> B[🏗️ 系統設計]
    B --> C[💻 編碼實現]
    C --> D[🧪 測試驗證]
    D --> E[🚀 部署上線]
    E --> F[🔧 維護運營]

    style A fill:#e3f2fd
    style B fill:#e8eaf6
    style C fill:#fce4ec
    style D fill:#fff8e1
    style E fill:#e8f5e9
    style F fill:#f3e5f5

特點：

• 階段分明，前一階段完成才進入下一階段
• 文檔驅動，每個階段有明確的交付物
• 變更困難，後期變更成本高

適用場景：

• 需求明確穩定
• 大型系統、關鍵系統
• 合規要求嚴格

不適用場景：

• 需求不確定或經常變化
• 需要快速迭代的產品
• 小團隊、創業公司

敏捷開發#

敏捷不是一種具體方法，而是一種價值觀和原則。

敏捷宣言的核心：

• 個體和互動 高於 流程和工具
• 可工作的軟體 高於 詳盡的文檔
• 客戶合作 高於 合同談判
• 響應變化 高於 遵循計劃

常見的敏捷實踐：

敏捷的常見誤區#

很多團隊以為「敏捷就是不寫文檔」「敏捷就是隨時改需求」。這是對敏捷的誤解。

寶玉指出的問題：

選擇開發模型的考量#

考慮因素：
├── 需求穩定性：變化多→敏捷，穩定→瀑布
├── 團隊規模：小團隊→輕量流程，大團隊→需要規範
├── 項目類型：產品迭代→敏捷，交付項目→瀑布
├── 組織文化：需要全組織配合
└── 客戶期望：有些客戶需要詳細計劃和文檔

大多數團隊會採用混合方式。例如，用敏捷做迭代開發，但在架構設計階段用更瀑布式的方法。

開發流程實踐#

Sprint / 迭代#

典型的 Sprint 結構：

flowchart LR
    subgraph DAY1 [📋 Sprint 計劃 第1天]
        A1[評審待辦事項]
        A2[承諾本迭代要完成的工作]
        A3[分解任務]
    end

    subgraph DEV [💻 開發階段 第2-9天]
        B1[每日站會 15分鐘]
        B2[開發、測試、修復]
        B3[持續集成]
    end

    subgraph END [🎯 Sprint 結束 第10天]
        C1[Sprint 評審：展示完成的工作]
        C2[Sprint 回顧：總結改進點]
        C3[為下個 Sprint 準備]
    end

    DAY1 --> DEV --> END
    END -->|下一個迭代| DAY1

    style DAY1 fill:#e3f2fd
    style DEV fill:#fff3e0
    style END fill:#e8f5e9

每日站會#

站會的目的：

• 同步進展
• 識別障礙
• 協調工作

站會的三個問題：

1. 昨天做了什麼？
2. 今天計劃做什麼？
3. 有什麼阻礙？

站會不是狀態匯報會。如果變成向領導匯報，而不是團隊互相同步，就失去了意義。

需求拆分#

用戶故事格式：

作為 [角色]
我想要 [功能]
以便 [價值]

驗收標準：
- 當 X 時，Y
- 當 A 時，B

好的用戶故事的標準（INVEST）：

• Independent：獨立的
• Negotiable：可協商的
• Valuable：有價值的
• Estimable：可估算的
• Small：小的
• Testable：可測試的

持續集成/持續交付#

CI/CD 的價值#

寶玉強調 CI/CD 的重要性：

持續集成和持續交付是現代軟體開發的基礎設施。沒有 CI/CD，很難做到快速、可靠的迭代。

持續集成（CI）：
├── 頻繁合併代碼（至少每天）
├── 自動化構建和測試
├── 快速發現和修復問題
└── 保持代碼庫健康

持續交付（CD）：
├── 代碼隨時可以部署
├── 自動化部署流程
├── 一鍵發布能力
└── 快速回滾機制

CI/CD 流水線#

flowchart LR
    subgraph CI [持續集成 CI]
        A[📤 代碼提交] --> B[🔍 代碼檢查]
        B --> C[🔨 構建]
        C --> D[🧪 單元測試]
        D --> E[🔗 集成測試]
    end

    subgraph CD [持續交付 CD]
        E --> F[📦 部署測試環境]
        F --> G[✅ 驗收測試]
        G --> H[🚀 部署生產環境]
    end

    style A fill:#e8f5e9
    style H fill:#c8e6c9

實施 CI/CD 的建議#

CI/CD 不是一步到位的。從最基本的自動化構建開始，逐步完善。關鍵是「持續」改進。

代碼管理#

版本控制策略#

寶玉介紹了常見的分支策略：

Git Flow：

gitGraph
    commit id: "init"
    branch develop
    checkout develop
    commit id: "dev-1"
    branch feature/login
    checkout feature/login
    commit id: "feat-1"
    commit id: "feat-2"
    checkout develop
    merge feature/login
    commit id: "dev-2"
    checkout main
    merge develop tag: "v1.0"

GitHub Flow（更簡單）：

gitGraph
    commit id: "init"
    branch feature/new-ui
    checkout feature/new-ui
    commit id: "feat-1"
    commit id: "feat-2"
    checkout main
    merge feature/new-ui
    commit id: "deploy" tag: "v1.1"

Trunk-Based Development：

gitGraph
    commit id: "init"
    commit id: "small-change-1"
    branch short-lived
    commit id: "quick-fix"
    checkout main
    merge short-lived
    commit id: "small-change-2"
    commit id: "small-change-3"

代碼評審#

為什麼要做 Code Review：

• 發現 Bug 和設計問題
• 知識共享和技術交流
• 保持代碼一致性
• 提升代碼質量文化

Code Review 的最佳實踐：

審查者：
├── 及時響應（24小時內）
├── 關注重點（架構、邏輯、可讀性）
├── 提供建設性反饋
└── 不要雞蛋裡挑骨頭

提交者：
├── 保持 PR 小（200-400行）
├── 寫清楚描述和背景
├── 先自我審查
└── 對反饋保持開放

會議效率#

技術團隊常見會議#

減少不必要會議#

寶玉的建議：

• 能用文檔/消息解決的不開會
• 有明確議程再開會
• 只邀請必要的人
• 嚴格控制時間
• 會後有記錄和行動項

技術人員的時間被會議碎片化，無法專注編碼。要保護團隊的專注時間。

本章要點#

1. 沒有最好的模型：根據團隊和項目情況選擇
2. 敏捷的誤區：不是不寫文檔，不是隨意改需求
3. 站會三問：昨天做什麼、今天做什麼、有什麼障礙
4. CI/CD 是基礎：持續集成、持續交付，逐步完善
5. Code Review：發現問題、知識共享、文化建設
6. 會議要高效：有議程、有時限、有跟進