Có một câu nói nổi tiếng trong quản lý dự án: "Lập kế hoạch là tất cả, bản kế hoạch là không gì cả." - Dwight D. Eisenhower.
Machine Learning projects là hiện thân của câu này. Bạn không thể lập kế hoạch mọi thứ từ đầu vì:
Theo Gartner, 85% dự án AI thất bại - không phải vì kỹ thuật kém, mà vì quản lý dự án tồi. Waterfall planning (lập kế hoạch hết 6 tháng trước) không work với ML. Bạn cần Agile.
Nhưng Agile cho ML khác Agile cho software. Bài này sẽ chỉ ra cách adapt phương pháp Agile cho ML projects.
Scrum là framework phổ biến nhất của Agile, dựa trên:
1. Product Owner (PO)
Trách nhiệm:
- Định nghĩa tầm nhìn sản phẩm
- Sắp xếp ưu tiên backlog (làm cái gì tiếp theo)
- Chấp nhận/từ chối công việc (definition of done)
- Liên lạc giữa business và team
Trong ML:
- Hiểu giá trị business của ML models
- Cân bằng accuracy vs. latency vs. cost
- Quyết định khi nào "đủ tốt" để ship
Ví dụ quyết định của PO:
Tình huống: Model dự đoán churn
- Model A: 92% accuracy, 500ms latency
- Model B: 88% accuracy, 50ms latency
PO chọn: Model B
Lý do: Trade-off 4% accuracy có thể chấp nhận được,
phản hồi real-time quan trọng cho UX
2. Scrum Master (SM)
Trách nhiệm:
- Điều phối các ceremonies của Scrum
- Gỡ bỏ blockers
- Bảo vệ team khỏi gián đoạn
- Huấn luyện team về Agile practices
Trong ML:
- Đảm bảo data pipeline không chặn experiments
- Phối hợp với infrastructure team
- Quản lý discussions về technical debt
3. Development Team
Team đa chức năng:
- Data Engineers: Xây data pipelines
- ML Engineers: Train & deploy models
- Data Scientists: Thử nghiệm & phân tích
- Backend/Frontend Devs: Tích hợp
- QA: Test models & applications
Tự tổ chức: Team quyết định LÀM SAO để làm việc
1. Product Backlog
Danh sách có thứ tự của tất cả công việc (features, bugs, tech debt).
ML-specific backlog items:
EPIC: Hệ thống Phát hiện Gian lận
Stories:
□ Với vai trò data scientist, tôi cần dữ liệu giao dịch sạch để train models
Ước lượng: 13 points (lớn)
□ Với vai trò ML engineer, tôi cần baseline model (logistic regression) để có benchmark
Ước lượng: 5 points (trung bình)
□ Với vai trò business analyst, tôi cần dashboard phát hiện gian lận để theo dõi xu hướng
Ước lượng: 8 points (lớn)
□ Với vai trò data engineer, tôi cần automated data pipeline để data refresh hàng ngày
Ước lượng: 8 points (lớn)
Ưu tiên Backlog:
Phương pháp MoSCoW:
Must have: Chức năng cốt lõi (API phát hiện gian lận)
Should have: Dashboard monitoring
Could have: Framework A/B testing
Won't have: UI explainability (nice-to-have, delay)
Ma trận Giá trị vs. Nỗ lực:
Giá trị cao │ Quick Wins │ Major Projects
│ (Làm trước!) │ (Plan cẩn thận)
────────────┼────────────────┼────────────────
Giá trị thấp│ Fill-ins │ Tránh
│ (Làm nếu còn │ (Đừng lãng phí
│ thời gian) │ thời gian)
└────────────────┴────────────────
Nỗ lực thấp Nỗ lực cao
2. Sprint Backlog
Công việc cam kết cho sprint hiện tại.
Sprint Planning:
Năng lực team: 40 points (sprint 2 tuần, 5 người)
Items được chọn:
1. Clean dữ liệu giao dịch (13 pts)
2. Baseline model (5 pts)
3. Model evaluation metrics (8 pts)
4. API endpoint prototype (8 pts)
5. Tech debt: refactor data loader (6 pts)
Tổng: 40 points
3. Product Increment
Output có thể ship được sau mỗi sprint.
Ví dụ ML increments:
Sprint 1: Dataset đã clean + báo cáo EDA
Sprint 2: Baseline model (logistic regression) + evaluation
Sprint 3: Model cải tiến (Random Forest) + so sánh
Sprint 4: Model API + integration tests
Sprint 5: Model deployed + monitoring
1. Sprint Planning (Đầu sprint)
Thời lượng: 4 giờ (sprint 2 tuần)
Agenda:
Phần 1: LÀM GÌ
- Review product backlog
- Chọn stories cho sprint
- Định nghĩa sprint goal
Phần 2: LÀM SAO
- Chia stories thành tasks
- Ước lượng tasks
- Gán người chịu trách nhiệm
Output: Sprint backlog
ML-specific planning:
Story: "Train model phân tích sentiment"
Tasks:
□ Thu thập & gán nhãn 10k tweets (Data Scientist - 1 ngày)
□ Tiền xử lý text (lowercase, loại stopwords) (DE - 0.5 ngày)
□ Feature engineering (TF-IDF, word embeddings) (DS - 1 ngày)
□ Train baseline (Naive Bayes) (DS - 0.5 ngày)
□ Train advanced (BERT fine-tune) (MLE - 2 ngày)
□ Đánh giá trên test set (DS - 0.5 ngày)
□ Document kết quả (DS - 0.5 ngày)
Tổng: 6 ngày (vừa với sprint 2 tuần có buffer)
2. Daily Standup (Mỗi ngày)
Thời lượng: 15 phút (timeboxed!)
Format: Mỗi người trả lời 3 câu hỏi:
1. Hôm qua tôi làm gì?
2. Hôm nay tôi sẽ làm gì?
3. Có blockers không?
Ví dụ:
Alice (DS): "Hôm qua train baseline model (78% acc). Hôm nay sẽ thử Random Forest. Không có blockers."
Bob (DE): "Hôm qua xây data pipeline. Hôm nay deploy lên staging. Bị block: cần AWS permissions."
Scrum Master: "Tôi sẽ giúp Bob lấy permissions sau standup."
Anti-patterns:
❌ Thảo luận giải quyết vấn đề (đưa ra ngoài)
❌ Báo cáo status cho manager (đây là peer sync)
❌ Quá 15 phút (timebox nghiêm ngặt)
3. Sprint Review (Cuối sprint)
Thời lượng: 2 giờ
Người tham dự: Team + Stakeholders
Agenda:
1. Demo công việc đã hoàn thành (working software!)
2. Phản hồi từ stakeholders
3. Cập nhật product backlog
Ví dụ ML demo:
"Đây là model phát hiện gian lận v2:
- 88% accuracy (tăng từ 82% baseline)
- 50ms latency (đáp ứng yêu cầu)
- Deployed lên staging, test với 1000 giao dịch
- Dashboard hiển thị predictions real-time
[Demo trực tiếp]
Stakeholders: Có thể thêm explainability không? Tại sao model đánh dấu giao dịch này?
PO: Đã thêm vào backlog, ưu tiên cho sprint tiếp."
4. Sprint Retrospective (Sau review)
Thời lượng: 1.5 giờ
Người tham dự: Chỉ team (không gian an toàn)
Format:
1. Cái gì tốt? (tiếp tục làm)
2. Cái gì không tốt? (dừng làm)
3. Cải thiện gì? (action items)
Ví dụ:
Tốt:
✓ Model training nhanh hơn với GPU instance mới
✓ Collaboration tốt giữa DS và MLE
Không tốt:
✗ Data pipeline bị hỏng 2 lần
✗ Không rõ definition của "model sẵn sàng production"
Action items:
→ Thêm data validation tests (Owner: Bob, Due: Sprint tiếp)
→ Định nghĩa model release checklist (Owner: Alice, Due: Tuần này)
Giờ: Ước lượng thời gian tuyệt đối
"Cái này sẽ mất 8 giờ"
Story Points: Độ phức tạp/nỗ lực tương đối
Fibonacci: 1, 2, 3, 5, 8, 13, 21
1 point: Trivial (load CSV file)
3 points: Nhỏ (EDA trên single dataset)
5 points: Trung bình (train baseline model)
8 points: Lớn (xây data pipeline)
13 points: Rất lớn (fine-tune LLM)
21 points: Epic (quá lớn, chia nhỏ!)
Tại sao Story Points?
Người khác nhau, tốc độ khác nhau:
- Senior DS: Train model trong 4 giờ
- Junior DS: Train model trong 8 giờ
Cả hai đồng ý: Task là "5 points" (độ phức tạp trung bình)
→ Velocity san bằng qua các sprints
Kỹ thuật: Team ước lượng cùng nhau.
Quy trình:
1. PO đọc story
2. Team hỏi câu hỏi làm rõ
3. Mỗi người chọn thẻ riêng (1,2,3,5,8,13,21)
4. Mọi người lật cùng lúc
5. Thảo luận sự khác biệt
6. Ước lượng lại cho đến consensus
Ví dụ:
Story: "Implement data augmentation cho ảnh"
Vòng 1:
Alice: 5, Bob: 8, Charlie: 13
Thảo luận:
Charlie: "Tôi nghĩ 13 vì cần test 5 kỹ thuật augmentation"
Alice: "Ồ, tôi nghĩ chỉ flip/rotation cơ bản (5 points)"
Bob: "Làm rõ với PO"
PO: "Chỉ flips, rotations, color jittering - kỹ thuật cơ bản"
Vòng 2:
Alice: 5, Bob: 5, Charlie: 5 → Đồng thuận!
Lợi ích:
Khi story quá mơ hồ để ước lượng chính xác:
XS: < 1 sprint
S: 1 sprint
M: 2-3 sprints
L: 4-6 sprints
XL: > 6 sprints (chia nhỏ!)
Ví dụ:
Epic: "Xây hệ thống recommendation"
Size: L (4-6 sprints)
Chia nhỏ:
- Thu thập data (S)
- Collaborative filtering baseline (M)
- Deep learning model (M)
- A/B testing (S)
Technical Debt: Những shortcuts được lấy để ship nhanh hơn, tạo gánh nặng bảo trì sau này.
│ Liều lĩnh │ Thận trọng
─────────┼──────────────────┼──────────────────
Cố ý │ "Không có thời │ "Ship bây giờ,
│ gian design" │ refactor sprint sau"
─────────┼──────────────────┼──────────────────
Vô tình │ "Layering │ "Giờ mới biết
│ là gì?" │ đáng lẽ nên làm sao"
ML-specific Technical Debt:
1. Data Debt:
# Nhanh & bẩn
df = pd.read_csv('data.csv')
df = df.dropna() # Mất 30% data!
model.fit(df)
# Đúng cách (mất thời gian hơn)
df = load_with_validation('data.csv')
df = impute_missing(df, strategy='domain_specific')
df = remove_outliers(df, method='IQR')
model.fit(df)
2. Model Debt:
# Nhanh
model = RandomForestClassifier() # Default params
model.fit(X, y)
# Đúng cách
model = RandomForestClassifier()
grid_search = GridSearchCV(model, param_grid, cv=5)
grid_search.fit(X, y)
best_model = grid_search.best_estimator_
3. Pipeline Debt:
# Nhanh
# Manual script chạy hàng ngày
python extract_data.py
python train_model.py
python deploy_model.py
# Đúng cách
# Automated Airflow DAG
extract_task >> transform_task >> train_task >> deploy_task
Phân bổ năng lực:
Mỗi sprint:
70% features mới
20% tech debt
10% buffer (vấn đề bất ngờ)
Track debt tường minh:
Backlog:
□ [DEBT] Refactor data pipeline cho testability (8 pts)
□ [DEBT] Thêm model performance monitoring (5 pts)
□ [DEBT] Document feature engineering logic (3 pts)
Quy tắc "boy scout":
"Để code sạch hơn khi bạn tìm thấy nó"
Mỗi lần chạm vào code:
- Thêm docstring thiếu
- Viết một test
- Refactor một function
Software truyền thống:
✓ Code được viết
✓ Tests pass
✓ Code reviewed
✓ Deployed lên production
Bổ sung ML:
✓ Model accuracy đạt ngưỡng (ví dụ: >85%)
✓ Model latency chấp nhận được (ví dụ: <200ms)
✓ Fairness metrics được đánh giá (không bias)
✓ Model được document (kiến trúc, hyperparameters)
✓ Reproducibility đảm bảo (seeds, versions)
✓ A/B test plan được tạo
✓ Monitoring dashboard sẵn sàng
Spike: Research có thời hạn với không có deliverable ngoại trừ kiến thức.
Khi nào dùng:
Uncertainty quá cao để ước lượng story thường
Ví dụ:
"Có thể dùng GPT-4 cho task này không?"
→ Spike: 2 ngày để prototype & đánh giá
→ Output: Báo cáo với khuyến nghị
Sau đó tạo implementation story thực tế dựa trên findings
Format Spike:
Story: [SPIKE] Đánh giá BERT vs. GPT cho classification
Thời hạn: 3 ngày
Câu hỏi cần trả lời:
- Model nào chính xác hơn?
- So sánh latency?
- So sánh cost?
- Dễ deploy?
Deliverable: Tài liệu quyết định 1 trang
Thách thức: Không phải experiment nào cũng thành công.
Cách tiếp cận tệ:
Sprint goal: "Đạt 90% accuracy"
→ Nếu best effort chỉ đạt 85%? Sprint thất bại?
Cách tiếp cận tốt:
Sprint goal: "Đánh giá 3 kiến trúc model và chọn tốt nhất"
Stories:
□ Train baseline (Logistic Regression)
□ Train Random Forest
□ Train Gradient Boosting
□ So sánh và document findings
Thành công = Đã thử 3 approaches và document learnings
(Không phụ thuộc vào việc đạt accuracy cụ thể)
ML projects cần nhiều disciplines:
Data Scientists ←→ ML Engineers
↕ ↕
Data Engineers ←→ DevOps
↕ ↕
Analysts ←→ Product
Patterns giao tiếp:
Daily Sync:
DS: "Model sẵn sàng, accuracy 88%"
MLE: "Tôi sẽ containerize và deploy lên staging"
DE: "Pipeline sẵn sàng, data refresh mỗi đêm"
Product: "Có thể A/B test với 10% traffic không?"
DevOps: "Tôi sẽ setup monitoring và alerts"
Handoffs:
DS → MLE:
- File model (.pkl, .h5)
- Training notebook
- requirements.txt
- Performance metrics
- Feature documentation
MLE → DevOps:
- Docker image
- API specification
- Load testing results
- Hướng dẫn deployment
Định nghĩa: Story points hoàn thành mỗi sprint.
Sprint 1: 35 points
Sprint 2: 40 points
Sprint 3: 38 points
Velocity trung bình: 38 points
Dùng cho planning:
Năng lực sprint tiếp ≈ 38 points
Lưu ý:
❌ Không so sánh velocity giữa các teams (scales khác nhau)
❌ Không dùng làm performance metric (gaming system)
✓ Dùng cho capacity planning của chính team
Trực quan: Công việc còn lại theo thời gian.
Points
40 │╲
│ ╲
30 │ ╲_
│ ╲
20 │ ╲__
│ ╲
10 │ ╲__
│ ╲_
0 └──────────────╲─
Ngày 1 5 10 14
Burndown lý tưởng vs. Thực tế
Giải thích:
Trên đường lý tưởng: Chậm tiến độ
Dưới đường lý tưởng: Trước tiến độ
Phần phẳng: Không có tiến độ (điều tra!)
Định nghĩa: Thời gian từ "bắt đầu" đến "xong".
Vòng đời story:
Backlog → In Progress → In Review → Done
↓ (2 ngày) (1 ngày) ↓
Cycle Time = 3 ngày
Mục tiêu: Giảm cycle time
- Stories nhỏ hơn
- Ít WIP hơn
- Reviews nhanh hơn
Vấn đề: Experiments bất tận, không bao giờ ship
Giải pháp: Timebox experiments
- Sprint 1-2: Thử nghiệm
- Sprint 3: Chọn tốt nhất, productionize
- Ship ngay cả khi "chưa hoàn hảo"
Vấn đề: Chỉ tập trung vào model accuracy, bỏ qua infrastructure
Giải pháp: Phân bổ năng lực
- 50% model development
- 30% data engineering
- 20% infrastructure/monitoring
Vấn đề: "Model sẵn sàng" nhưng không production-ready
Giải pháp: DoD checklist tường minh
□ Accuracy threshold đạt
□ Latency chấp nhận được
□ Có monitoring
□ Có documentation
□ Đã A/B test
Vấn đề: Demo model, stakeholders không hài lòng
Giải pháp:
- Involve stakeholders sớm (Sprint Reviews)
- Hiển thị prototypes hàng tuần
- Thu thập feedback liên tục
Nhớ rằng:
Agile không phải:
- Không lập kế hoạch
- Không documentation
- Hỗn loạn
Agile là:
- Lập kế hoạch linh hoạt
- Documentation vừa đủ
- Iteration có kiểm soát
Trong bài tiếp theo, chúng ta sẽ khám phá Technical Communication - nghệ thuật giải thích khái niệm kỹ thuật cho stakeholders phi kỹ thuật.
Bài viết thuộc series "From Zero to AI Engineer" - Module V: Soft Skills & Management