Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile trong dự án fixed price case study

409 views

Published on

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

Published in: Software
  • Be the first to comment

Agile trong dự án fixed price case study

  1. 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. 2. Agenda Topics: 1. Case study 2. Lesson & practice 2
  3. 3. 1. Case study
  4. 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. 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. 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. 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. 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. 9 1.3 Sprint Flow
  10. 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. 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. 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. 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. 14. 1.4 Các giai đoạn phát triển (FE) 14
  15. 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. 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. 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. 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. 19. 1.7 Đánh giá chung (dự án) 19 4. Effort efficiency
  20. 20. 2. Lesson & practice
  21. 21. 2.1- Cải tiến là chìa khóa tăng năng suất 21
  22. 22. 2.2- Để nhóm tự chủ thay vì kiểm soát 22
  23. 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. 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. 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. 26

×