Mô tả cách áp dụng Agile trong một dự án Fixed price, kết quả đạt được

1.  Nguyễn Minh Phúc
 Team lead, Project Manager - FPT Software (5 years)
 Project Manager, Agile Coach - NTQ Solution (1 year)
1
About me

2. Agenda
Topics:
1. Case study
2. Lesson & practice
2

3. 1. Case study

4. Nội dung
» 1.1 Overview dự án
» 1.2 Khó khăn & thuận lợi
» 1.3 Quy trình thực hiện
» 1.4 Các giai đoạn phát triển
» 1.5 Hoạt động cải tiến
» 1.6 Thước đo năng suất
» 1.7 Đánh giá chung

5. 1.1 Overview dự án
5
1. Overview
Maintain website cho phép các cá nhân đánh giá năng lực, thẩm định thiên hướng
của bản thân. Kết quả này có thể được dùng trong nhiều lĩnh vực như:
• Với công ty: tăng năng suất, thấu hiểu nhân viên, tuyển dụng, đào tạo
• Với cá nhân: career plan, phát triển bản thân
2. Project size and Project scope
• Size： 16 人月 (MM)
• Scope： Create spec →Coding (FE & BE) →Integration Test →Deploy
3. Release date
• Start date : 01/08 (thực tế là đến 14/08 mới bắt đầu)
• Release Frontent : 30/09
(Frontent chia làm 3 website: site pháp nhân, site người trả lời, site cá nhân)
• Release Backend: 14/10
4. Các công nghệ chính đã sử dụng trong dự án
• ColdFusion 11, OS: CentOS 6
5. Nhóm Scrum
• 1 PO kiêm BA ngồi site KH
• 1 Scrum Master kiêm PM
• 5 dev, 2 test

6. 1.2 Khó khăn
6
1. Dự án start chậm 2 tuần do không có người
2. Công nghệ mới (coldfusion) cả team chưa ai từng làm
3. Spec ban đầu chưa thực sự rõ ràng
4. Không có tài liệu hệ thống, KH là end-user nên ko support được team
5. Phải tự mày mò dựng server test cho cả 2 bên (local, staging)
6. Lần đầu tiên team làm scrum

7. 1.2 Thuận lợi
7
1. Team size thích hợp để tổ chức theo mô hình Scrum (dev team ~ 7 người)
2. Team có thời gian làm với nhau từ trước nên dễ communicate
3. Dự án size trung bình, dễ control
4. PO là BA ngồi cùng KH nên trao đổi rất thuận tiện
5. Các thành viên trẻ trung, nhiệt tình, ham học hỏi
6. Lãnh đạo ủng hộ và tạo điều kiện

8. 1.3 Quy trình
8
- Kick off dự án, xác định nhóm scrum, communication plan
- Xác định các tham số quy trình phát triển
- Làm rõ yêu cầu, xây dựng product backlog
- Ước lượng các backlog, lập kế hoạch phát hành
- Test hồi quy, đóng gói, chuyển giao, họp post-mortem

9. 9
1.3 Sprint Flow

10. 1.3 Sprint Backlog (bảng vật lý)
10
• Quản lý ở mức sub-tasks
• Mỗi bước được define định nghĩa hoàn thành
• Là nơi tổ chức daily scrum

11. 1.3 Sprint burn-down chart
11
• Thể hiện tiến độ công việc thực hiện trong sprint
• Tính toán được vận tốc thực hiện của team phát triển (theo giờ)
• Là cơ sở để đánh giá tình trạng hiện tại

12. 1.3 Release burndown chart
12
• Thể hiện tiến độ chung của toàn dự án
• Tính toán được vận tốc qua từng sprint (theo story point)

13. 1.3 Retrospective
13
• Áp dụng Glad/Sad/Mad để thu thập thông tin
• Phân tích các vấn đề bằng 5Whys để tìm root cause
• Chốt lại các hoạt động cải tiến và dán lên sprint backlog

14. 1.4 Các giai đoạn phát triển (FE)
14

15. 1.5 Hoạt động cải tiến
15
1. Define task common trong buổi lập kế hoạch (Sprint 2)
2. Khi có khó khăn nếu chưa giải quyết được ngay thì sẽ chuyển qua task khác,
trong thời gian này SM sẽ tìm phương án giải quyết (Sprint 2)
3. 2 người làm 1 chức năng để nâng cao trình độ nhanh hơn (Sprint 2)
4. Trong daily scrum, SM sẽ liên tục nhắc nhở để member chú ý đển time
estimation (Sprint 2)
5. Xác định độ ưu tiên của task trong buổi làm mịn (Sprint 3)
6. Limit WIP: Chọn 3 feature priority cao nhất để thực hiện (Sprint 3)
7. Đội dev tổ chức học tập để chia sẻ về kỹ thuật và hệ thống (Sprint 3)
8. Transfer việc deploy bản build để backup trong trường hợp bận (Sprint 4)
9. Deploy tối đa 2 bản/ 1 ngày vào 9h sáng và 3h chiều (Sprint 4)
10.Tạo tài liệu chia sẻ về business của hệ thống cho người mới (Sprint 4)

16. 3.3 PMB Portable Mac1.6 Chỉ số năng suất
1. Năng suất tổng (total FP)
• 3 sprint đầu làm khoảng 40%
• 2 sprint sau làm khoảng 60%
16
2. Năng suất trung bình (FP/1 dev)
• Sprint 5 năng suất tăng gấp đôi
so với trung bình của 2 sprint đầu tiên

17. 1.7 Đánh giá chung (con người)
17
1. Cải thiện khả năng estimate
2. Cải thiện khả năng làm việc nhóm
3. Cải thiện khả năng giữ commitment
Sprint 3 Sprint 5

18. 1.7 Đánh giá chung (dự án)
18
1. Delivery:
• Site pháp nhân: 13-Sep
• Site người trả lời: 20-Sep
• Site cá nhân: 30-Sep
• Site backend: 11-Oct
2. Chất lượng:
• Internal test: 101 bugs / 1500 test case (tỉ lệ <10%)
• Acceptance test from customer: 6 bugs / 23 CRs
3. Năng suất:
• Site pháp nhân: 4 tuần (Sprint 1 -> 4)
• Site người trả lời: 1 tuần (Sprint 5)
• Site cá nhân: 1,5 tuần (Sprint 6)
• Site backend: 1,5 tuần (Sprint 7)

19. 1.7 Đánh giá chung (dự án)
19
4. Effort efficiency

20. 2. Lesson & practice

21. 2.1- Cải tiến là chìa khóa tăng năng suất
21

22. 2.2- Để nhóm tự chủ thay vì kiểm soát
22

23. 23
 1. Chuyển nhận thức từ
“Điểm mù” sang “Cơ hội để
phát triển” (Thay đổi nhận
thức)
 2. Chuyển từ “Cơ hội để
phát triển” sang “Năng lực
cốt lõi” (Thay đổi năng lực)
Ban đầu, có cảm giác Scrum làm cho mọi thứ tồi tệ hơn, nhưng thực tế đây là 1
phần của việc trở nên tốt hơn
2.3- Cross training

24. 2.4- Managing as a Coach
1. Managing
• Tạo project plan
• Quản lý stakeholders
• Quản lý communication
• Quản lý project team
• Quản lý risk/issue
• Quản lý schedule
• Quản lý budget
• Quản lý project delivery
24
2. Leading
• Quan sát
• Lắng nghe
• Định hướng
• Trao quyền
• Làm gương
• Giữ người
• Tạo động lực
• Cải tiến quy trình

25. 2.5 Yếu tố bên ngoài
 Cần có phase phân tích yêu cầu trước khi ký hợp đồng để giảm thiểu rủi ro
estimate sai lệch quá nhiều. Ở phase này cần có BA ngồi site KH.
 Chia nhỏ các mốc release để team có thể thấy rõ target cần thực hiện. Ví dụ
thay vì mốc release FE thì chia thành 3 mốc release cho từng website. Các
mốc release về cơ bản là không thỏa hiệp.
 Quản lý chặt về change request, đánh giá độ ưu tiên trước khi thực hiện.
25

26. 26