19 KiB
19 KiB
開發工作流程
概述
建立標準化的開發工作流程，確保團隊協作效率、代碼品質和專案進度控制。
敏捷開發框架
Scrum工作模式
- Sprint週期: 2週一個Sprint
- 團隊組成: Product Owner + Scrum Master + 開發團隊
- 儀式會議: 每日站會、Sprint計劃、檢討會、回顧會
- 產出物: Product Backlog、Sprint Backlog、增量產品
- 透明度: 燃盡圖、累積流量圖、速度追蹤
Sprint工作流程
Sprint計劃會議 (每2週一次)
## Sprint計劃會議議程 (4小時)
### 第一部分: 什麼要做 (2小時)
- [ ] 檢視Product Backlog優先級
- [ ] 確認Sprint目標和成功標準
- [ ] 選擇要完成的User Stories
- [ ] 確認Definition of Done
### 第二部分: 如何做 (2小時)
- [ ] 將User Stories分解為具體任務
- [ ] 估算任務時間和複雜度
- [ ] 識別依賴關係和風險
- [ ] 確認團隊容量和可用性
### 產出物
- Sprint Backlog
- Sprint目標聲明
- 風險和依賴關係清單
每日站會 (15分鐘)
## 每日站會格式
每位團隊成員回答三個問題:
1. **昨天完成了什麼?**
- 完成的任務和達成的目標
2. **今天計劃做什麼?**
- 優先處理的任務和預期產出
3. **遇到什麼障礙?**
- 需要協助的技術問題
- 依賴關係阻礙
- 資源不足等問題
## 會後處理
- Scrum Master記錄和跟進障礙排除
- 必要時安排專門討論會議
- 更新燃盡圖和任務狀態
開發流程管理
任務管理系統
Jira/Linear工作流程
# 故事狀態流程
story_workflow:
- backlog: "產品待辦清單"
- ready: "準備開發 (需求明確、設計完成)"
- in_progress: "開發中"
- code_review: "代碼審查中"
- qa_testing: "QA測試中"
- staging: "Staging環境驗證"
- done: "完成並部署到生產環境"
# 任務優先級
priority_levels:
- critical: "Critical (系統故障、安全問題)"
- high: "High (核心功能、用戶影響大)"
- medium: "Medium (重要功能、效能優化)"
- low: "Low (UI改進、技術債務)"
User Story撰寫標準
## User Story模板
**作為** [角色]
**我希望** [功能/目標]
**以便** [商業價值/原因]
### 接受條件
- [ ] 條件1: 明確的可測試條件
- [ ] 條件2: 邊界條件和錯誤處理
- [ ] 條件3: 效能或安全要求
### 定義完成 (Definition of Done)
- [ ] 功能按接受條件實現
- [ ] 單元測試覆蓋率 >= 80%
- [ ] 代碼審查通過
- [ ] QA測試通過
- [ ] 文檔更新完成
### 技術任務
- [ ] 任務1: API端點開發
- [ ] 任務2: 前端UI實現
- [ ] 任務3: 資料庫遷移
- [ ] 任務4: 測試用例編寫
### 估算
- 故事點數: 5 (基於斐波納契數列: 1,2,3,5,8,13)
- 預估小時數: 16-20小時
版本控制工作流程
Git分支策略
graph LR
A[main] --> B[develop]
B --> C[feature/JIRA-123]
B --> D[feature/JIRA-124]
C --> B
D --> B
B --> E[release/v1.2.0]
E --> A
A --> F[hotfix/critical-bug]
F --> A
F --> B
分支管理規則
# ✅ 分支命名規範
main # 生產環境代碼，永遠可部署
develop # 開發整合分支，最新開發進度
feature/JIRA-123-user-login # 功能開發分支
hotfix/fix-payment-issue # 緊急修復分支
release/v1.2.0 # 發布準備分支
# ✅ 功能開發流程
# 1. 從develop創建feature分支
git checkout develop
git pull origin develop
git checkout -b feature/JIRA-123-dialogue-analysis
# 2. 開發過程中定期提交
git add .
git commit -m "feat(dialogue): implement scoring algorithm"
# 3. 開發完成推送並創建PR
git push origin feature/JIRA-123-dialogue-analysis
# 在GitHub/GitLab創建Pull Request到develop
# 4. Code Review通過後合併
git checkout develop
git pull origin develop
git branch -d feature/JIRA-123-dialogue-analysis
Code Review流程
PR創建清單
## Pull Request Template
### 變更摘要
簡短描述這個PR的主要變更和目的
### 相關票證
- 修復 #123
- 關閉 JIRA-456
### 變更類型
- [ ] 🚀 新功能 (feature)
- [ ] 🐛 Bug修復 (fix)
- [ ] 📝 文檔更新 (docs)
- [ ] 💄 UI/樣式變更 (style)
- [ ] ♻️ 代碼重構 (refactor)
- [ ] ⚡ 效能優化 (performance)
- [ ] ✅ 測試相關 (test)
- [ ] 🔧 建構/工具變更 (chore)
### 測試
- [ ] 已新增/更新單元測試
- [ ] 已新增/更新整合測試
- [ ] 手動測試已完成
- [ ] 回歸測試已通過
### 檢查清單
- [ ] 代碼遵循團隊規範
- [ ] 自我審查已完成
- [ ] 相關文檔已更新
- [ ] 不會破壞現有功能
Review要求和流程
review_requirements:
minimum_reviewers: 2
required_reviewers:
- tech_lead: "技術負責人 (必須)"
- domain_expert: "相關領域專家 (建議)"
review_criteria:
- functionality: "功能正確性"
- code_quality: "代碼品質和可讀性"
- performance: "效能影響評估"
- security: "安全性檢查"
- testing: "測試覆蓋度"
- documentation: "文檔完整性"
approval_process:
- all_required_approved: true
- ci_checks_passed: true
- conflicts_resolved: true
- final_review_by_tech_lead: true
品質保證流程
自動化測試管道
CI/CD Pipeline
# .github/workflows/ci.yml
name: Continuous Integration
on:
push:
branches: [ develop, main ]
pull_request:
branches: [ develop ]
jobs:
# 代碼品質檢查
code-quality:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '18'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Lint check
run: npm run lint
- name: Type check
run: npm run type-check
- name: Format check
run: npm run format:check
# 單元測試和覆蓋率
unit-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '18'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Run unit tests
run: npm run test:coverage
- name: Upload coverage to Codecov
uses: codecov/codecov-action@v3
# 整合測試
integration-tests:
runs-on: ubuntu-latest
services:
postgres:
image: postgres:15
env:
POSTGRES_PASSWORD: postgres
options: >-
--health-cmd pg_isready
--health-interval 10s
--health-timeout 5s
--health-retries 5
steps:
- uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '18'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Run database migrations
run: npm run db:migrate
env:
DATABASE_URL: postgresql://postgres:postgres@localhost:5432/test
- name: Run integration tests
run: npm run test:integration
env:
DATABASE_URL: postgresql://postgres:postgres@localhost:5432/test
# 建構測試
build-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '18'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Build application
run: npm run build
- name: Test build artifacts
run: |
ls -la dist/
node dist/server.js --version
部署流程
Staging部署
# 自動部署到Staging環境
staging_deployment:
trigger: "push到develop分支"
steps:
- code_quality_check: "代碼品質檢查通過"
- automated_tests: "所有測試通過"
- build_artifacts: "建構產物生成"
- deploy_to_staging: "部署到Staging環境"
- smoke_tests: "基本功能煙霧測試"
- notification: "通知團隊部署完成"
rollback_conditions:
- smoke_tests_fail: "煙霧測試失敗"
- health_check_fail: "健康檢查失敗"
- error_rate_high: "錯誤率過高"
Production部署
production_deployment:
trigger: "手動觸發或release分支創建"
approval_process:
- qa_sign_off: "QA測試通過確認"
- product_approval: "產品經理批准"
- tech_lead_approval: "技術負責人批准"
deployment_steps:
- pre_deployment_checks: "部署前檢查"
- database_migration: "資料庫遷移 (如需要)"
- blue_green_deployment: "藍綠部署策略"
- health_checks: "健康檢查和監控"
- gradual_traffic_shift: "流量逐漸切換"
- post_deployment_validation: "部署後驗證"
rollback_strategy:
- automatic_rollback_triggers: "自動回滾觸發條件"
- manual_rollback_procedure: "手動回滾程序"
- data_recovery_plan: "資料恢復計劃"
專案管理工具
開發工具整合
必要工具清單
project_management:
- tool: "Jira / Linear"
purpose: "需求管理、Sprint規劃、進度追蹤"
- tool: "Confluence / Notion"
purpose: "文檔管理、知識庫、會議記錄"
- tool: "Slack / Microsoft Teams"
purpose: "即時通訊、團隊協作、通知整合"
version_control:
- tool: "GitHub / GitLab"
purpose: "代碼託管、Code Review、CI/CD"
- tool: "Git"
purpose: "版本控制、分支管理"
development:
- tool: "VS Code"
purpose: "統一開發環境、擴展套件"
- tool: "Docker"
purpose: "容器化開發環境"
- tool: "Postman"
purpose: "API測試和文檔"
monitoring:
- tool: "Sentry"
purpose: "錯誤監控和追蹤"
- tool: "DataDog / New Relic"
purpose: "效能監控和分析"
- tool: "LogRocket"
purpose: "前端用戶行為分析"
工具整合配置
{
"jira_integration": {
"commit_message_format": "JIRA-123: commit message",
"branch_naming": "feature/JIRA-123-description",
"pr_title_format": "[JIRA-123] PR title",
"auto_transition": "commit觸發狀態轉換"
},
"slack_notifications": {
"pr_created": "#dev-team",
"pr_approved": "#dev-team",
"deployment_success": "#general",
"build_failure": "#dev-alerts",
"critical_errors": "#dev-alerts"
},
"monitoring_alerts": {
"error_rate_threshold": "5% in 5 minutes",
"response_time_threshold": "500ms average",
"downtime_alert": "immediate",
"deployment_monitoring": "30 minutes post-deploy"
}
}
會議和溝通規範
定期會議安排
## 團隊會議時程表
### 每日會議
- **每日站會**: 早上 9:30-9:45 (15分鐘)
- 地點: 會議室 / Zoom
- 參與者: 全體開發團隊
- 目的: 同步進度、識別障礙
### 週會議
- **技術分享會**: 週五 15:00-16:00 (1小時)
- 地點: 會議室
- 參與者: 技術團隊
- 目的: 技術交流、最佳實踐分享
### 雙週會議
- **Sprint計劃會**: Sprint開始第一天 9:00-13:00 (4小時)
- **Sprint檢討會**: Sprint最後一天 14:00-15:00 (1小時)
- **Sprint回顧會**: Sprint最後一天 15:00-16:00 (1小時)
### 月會議
- **架構審查會**: 每月第一個週三 14:00-16:00 (2小時)
- **產品路線圖會**: 每月最後一個週五 10:00-12:00 (2小時)
有效會議原則
## 會議最佳實踐
### 會議前準備
- [ ] 明確會議目的和議程
- [ ] 提前分享相關資料
- [ ] 確認必要參與者
- [ ] 準備會議室和設備
### 會議進行
- [ ] 準時開始和結束
- [ ] 專注議程不偏題
- [ ] 記錄決議和行動項目
- [ ] 確保每個人都有發言機會
### 會議後續
- [ ] 24小時內分享會議記錄
- [ ] 追蹤行動項目執行
- [ ] 更新相關文檔和票證
- [ ] 安排必要的後續會議
知識管理和文檔
技術文檔管理
文檔類型和負責人
documentation_types:
api_documentation:
owner: "後端開發負責人"
tools: "Swagger/OpenAPI, Postman"
update_frequency: "每個Sprint"
architecture_documentation:
owner: "技術架構師"
tools: "Confluence/Notion, Draw.io"
update_frequency: "重大變更時"
user_guides:
owner: "產品經理"
tools: "Confluence/Notion"
update_frequency: "功能發布時"
runbooks:
owner: "DevOps工程師"
tools: "Confluence/Notion"
update_frequency: "部署流程變更時"
文檔審查和維護
## 文檔生命週期管理
### 創建階段
- [ ] 確定文檔類型和模板
- [ ] 指派文檔負責人
- [ ] 設定審查時程
- [ ] 建立版本控制
### 審查階段
- [ ] 技術準確性審查
- [ ] 可讀性和結構檢查
- [ ] 範例和代碼驗證
- [ ] 相關人員簽字確認
### 維護階段
- [ ] 定期內容更新
- [ ] 過時資訊清理
- [ ] 用戶回饋整合
- [ ] 存取權限管理
### 退役階段
- [ ] 標記過時文檔
- [ ] 建立重導向連結
- [ ] 通知相關使用者
- [ ] 歸檔或刪除處理
知識分享機制
技術分享會規劃
## 月度技術分享主題
### 技術深度分享
- React Native效能優化技巧
- PostgreSQL查詢最佳化實戰
- OpenAI API整合經驗分享
- AWS服務架構設計心得
### 工具和流程分享
- Git工作流程最佳實踐
- 自動化測試策略分享
- 代碼審查技巧和心得
- 監控和告警系統應用
### 外部學習分享
- 技術會議參與心得
- 線上課程學習成果
- 開源專案貢獻經驗
- 行業趨勢和新技術調研
風險管理和應變
常見風險識別
技術風險管控
technical_risks:
dependency_vulnerabilities:
monitoring: "Dependabot自動掃描"
response_time: "24小時內評估"
mitigation: "立即更新或尋找替代方案"
performance_degradation:
monitoring: "持續效能監控"
threshold: "API回應時間 > 500ms"
response: "自動告警 + 立即調查"
third_party_service_outage:
monitoring: "服務健康檢查"
backup_plan: "降級模式或替代服務"
communication: "用戶通知和狀態頁面更新"
data_security_breach:
monitoring: "安全性掃描和審計"
response_plan: "安全事件回應流程"
recovery: "資料恢復和系統加固"
專案風險應對
project_risks:
timeline_delays:
early_warning: "Sprint燃盡圖異常"
response: "資源重新分配或範圍調整"
escalation: "每週向管理層報告"
team_capacity_shortage:
monitoring: "團隊工作負載追蹤"
response: "外包支援或功能優先級調整"
prevention: "提前識別關鍵技能需求"
quality_issues:
monitoring: "代碼品質指標和用戶回饋"
response: "增加測試投入或重構計劃"
prevention: "強化代碼審查和自動化測試"
緊急事件處理
事件等級分類
## 事件嚴重程度分級
### P0 - 緊急 (Critical)
- 描述: 服務完全中斷，影響所有用戶
- 回應時間: 15分鐘內
- 解決時間: 1小時內
- 升級: 立即通知管理層
- 範例: 主要服務完全無法存取
### P1 - 高 (High)
- 描述: 重要功能故障，影響大量用戶
- 回應時間: 30分鐘內
- 解決時間: 4小時內
- 升級: 2小時後升級
- 範例: 支付系統故障
### P2 - 中 (Medium)
- 描述: 部分功能異常，影響部分用戶
- 回應時間: 2小時內
- 解決時間: 24小時內
- 升級: 標準工作時間處理
- 範例: 特定功能性能下降
### P3 - 低 (Low)
- 描述: 輕微問題，不影響核心功能
- 回應時間: 24小時內
- 解決時間: 一週內
- 升級: 正常開發週期處理
- 範例: UI顯示小問題
事件處理流程
flowchart TD
A[事件發生] --> B[事件檢測/報告]
B --> C[事件分級]
C --> D[組建事件響應團隊]
D --> E[初步診斷和評估]
E --> F[實施緊急修復]
F --> G[驗證修復效果]
G --> H{問題是否解決?}
H -->|否| I[深入調查]
I --> F
H -->|是| J[事件關閉]
J --> K[事後檢討會議]
K --> L[改進措施實施]
持續改進機制
團隊回顧和改進
Sprint回顧會模板
## Sprint回顧會議 (Retrospective)
### 會議資訊
- Sprint: Sprint #12
- 日期: 2024年9月5日
- 參與者: 全體開發團隊
- 主持人: Scrum Master
### 回顧內容
#### 做得好的方面 (Keep)
- [ ] 項目1: 代碼審查品質提升，bug減少30%
- [ ] 項目2: 團隊溝通更順暢，每日站會效率提升
- [ ] 項目3: 自動化測試覆蓋率達到85%
#### 需要改進的方面 (Problem)
- [ ] 問題1: API文檔更新不及時，影響前端開發
- [ ] 問題2: 測試環境不穩定，影響QA測試進度
- [ ] 問題3: 技術債務積累，需要專門時間清理
#### 改進行動項目 (Try)
- [ ] 行動1: 建立API文檔自動生成流程 (負責人: 後端Lead)
- [ ] 行動2: 升級測試環境硬體配置 (負責人: DevOps)
- [ ] 行動3: 每Sprint分配20%時間處理技術債務 (負責人: 技術Lead)
### 下次檢查
下個Sprint回顧會檢查改進行動的執行情況
指標追蹤和改善
開發效率指標
development_metrics:
velocity_tracking:
measurement: "每Sprint完成的故事點數"
target: "穩定在35-45點之間"
trend: "應該保持穩定或略有增長"
cycle_time:
measurement: "從開發開始到部署完成的時間"
target: "平均5天以內"
trend: "持續降低"
defect_rate:
measurement: "生產環境發現的bug數量"
target: "每Sprint < 3個"
trend: "持續降低"
code_quality:
test_coverage: "> 80%"
code_review_participation: "100%"
technical_debt_ratio: "< 5%"
改進策略制定
## 持續改進策略
### 月度改進檢討
- [ ] 收集和分析開發效率指標
- [ ] 識別瓶頸和改進機會
- [ ] 制定具體改進行動計劃
- [ ] 分配責任人和時間表
### 季度技術回顧
- [ ] 評估技術架構和工具選擇
- [ ] 檢討開發流程和最佳實踐
- [ ] 規劃技術升級和創新項目
- [ ] 團隊技能發展規劃
### 年度流程優化
- [ ] 全面檢視開發工作流程
- [ ] 對比行業最佳實踐
- [ ] 制定下年度改進路線圖
- [ ] 投資新工具和技術培訓
待完成任務
立即執行
- 設置專案管理工具 (Jira/Linear) 和工作流程
- 建立Git分支策略和保護規則
- 設置CI/CD pipeline基礎架構
- 制定代碼審查模板和檢查清單
短期目標 (2週內)
- 完成開發環境標準化設置
- 建立自動化測試框架
- 設置監控和告警系統
- 制定文檔管理規範
中期目標 (1個月內)
- 建立完整的部署自動化流程
- 設置效能和品質指標監控
- 建立知識分享和培訓機制
- 制定事件回應和處理流程
最後更新: 2024年9月5日
負責人: Scrum Master / 技術Lead
下次檢討: 每月月末進行流程檢討和優化