Agile Scrum

Trong thế giới phát triển phần mềm hiện đại, Agile và Scrum đã trở thành những phương pháp phổ biến và hiệu quả để quản lý dự án và phát triển sản phẩm. Bài viết này sẽ giúp bạn hiểu rõ về Agile, Scrum framework, và cách áp dụng chúng vào thực tế để đưa sản phẩm đến tay người dùng một cách nhanh chóng và hiệu quả nhất.

Agile là gì?

Agile là một phương pháp phát triển phần mềm linh hoạt, tập trung vào việc đưa sản phẩm đến tay người dùng càng nhanh càng tốt, càng sớm càng tốt. Thay vì phát triển toàn bộ sản phẩm trong một lần rồi mới giao cho khách hàng, Agile chia nhỏ công việc thành các phần nhỏ, phát triển và giao hàng liên tục để nhận phản hồi sớm và điều chỉnh kịp thời.

Tại sao Agile ra đời?

Trước khi có Agile, các dự án phần mềm thường sử dụng mô hình Waterfall (thác nước) - một quy trình tuần tự, cứng nhắc. Mô hình này có nhiều hạn chế:

• Khách hàng chỉ thấy sản phẩm khi đã hoàn thành (có thể mất hàng năm)
• Khó thay đổi yêu cầu khi đã vào giai đoạn phát triển
• Rủi ro cao vì không có phản hồi sớm
• Tài liệu nhiều nhưng giá trị thực tế thấp

Agile ra đời để giải quyết những vấn đề này, tập trung vào việc tạo ra giá trị thực sự cho khách hàng thông qua việc giao hàng nhanh và phản hồi liên tục.

Tuyên ngôn Agile (Agile Manifesto)

Năm 2001, một nhóm các chuyên gia phát triển phần mềm đã gặp nhau và đưa ra Tuyên ngôn Agile, định nghĩa các giá trị cốt lõi của phương pháp này:

Chúng tôi đã phát hiện ra cách phát triển phần mềm tốt hơn bằng cách thực hiện nó và giúp đỡ người khác thực hiện. Qua công việc này, chúng tôi đã đi đến việc đánh giá cao:

4 giá trị cốt lõi của Agile

1. Cá nhân và sự tương tác hơn là quy trình và công cụ
   • Con người và cách họ làm việc cùng nhau quan trọng hơn các công cụ và quy trình cứng nhắc
2. Phần mềm chạy tốt hơn là tài liệu đầy đủ
   • Sản phẩm hoạt động được quan trọng hơn việc có đầy đủ tài liệu
3. Cộng tác với khách hàng hơn là đàm phán hợp đồng
   • Làm việc cùng nhau để tạo giá trị quan trọng hơn việc tranh cãi về hợp đồng
4. Phản hồi với các thay đổi hơn là bám sát kế hoạch
   • Linh hoạt thích ứng với thay đổi quan trọng hơn việc tuân thủ nghiêm ngặt kế hoạch ban đầu

Lưu ý quan trọng: Mặc dù Agile đánh giá cao các giá trị bên trái, nhưng không có nghĩa là bỏ qua hoàn toàn các giá trị bên phải. Cả hai đều quan trọng, nhưng Agile ưu tiên các giá trị bên trái hơn.

12 Nguyên lý của Agile

Đằng sau Tuyên ngôn Agile là 12 nguyên lý cụ thể hướng dẫn cách áp dụng Agile trong thực tế:

1. Thỏa mãn khách hàng thông qua chuyển giao sớm và liên tục

Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các phần mềm có giá trị. Thay vì chờ đợi hàng tháng hoặc hàng năm, khách hàng nhận được giá trị ngay từ những tuần đầu tiên.

2. Chào đón sự thay đổi

Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển. Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng. Trong thế giới thay đổi nhanh chóng ngày nay, khả năng thích ứng là một lợi thế cạnh tranh.

3. Chuyển giao phần mềm thường xuyên

Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng. Từ vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn. Chu kỳ ngắn hơn giúp giảm rủi ro và tăng tốc độ học hỏi.

4. Hợp tác chặt chẽ

Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án. Sự hợp tác này giúp đảm bảo mọi người hiểu rõ mục tiêu và cùng hướng tới một kết quả chung.

5. Xây dựng dự án xung quanh những cá nhân có động lực

Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc. Con người là tài sản quý giá nhất của dự án.

6. Giao tiếp trực tiếp

Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp. Một cuộc trò chuyện 5 phút thường hiệu quả hơn một email dài hoặc tài liệu phức tạp.

7. Phần mềm chạy tốt là thước đo tiến độ

Phần mềm chạy tốt là thước đo chính của tiến độ. Không phải số dòng code, không phải số tài liệu, mà là phần mềm thực sự hoạt động.

8. Phát triển bền vững

Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn. Làm việc quá sức không phải là giải pháp lâu dài.

9. Quan tâm đến kỹ thuật và thiết kế tốt

Liên tục quan tâm đến các kỹ thuật và thiết kế tốt để gia tăng sự linh hoạt. Code chất lượng cao giúp dễ dàng thay đổi và mở rộng trong tương lai.

10. Sự đơn giản

Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản. Làm những gì cần thiết, không làm những gì không cần thiết.

11. Nhóm tự tổ chức

Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức. Nhóm tự quyết định cách làm việc hiệu quả nhất.

12. Cải thiện liên tục

Đội sản xuất sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn. Sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp. Không có gì là hoàn hảo, luôn có thể cải thiện.

Đặc trưng của Agile

1. Tính lặp (Iterative)

Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại. Các phân đoạn (được gọi là Iteration hoặc Sprint) này thường có khung thời gian ngắn (từ 1 – 4 tuần).

Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như:

• Lập kế hoạch
• Phân tích yêu cầu
• Thiết kế
• Triển khai
• Kiểm thử

Để cho ra các phần nhỏ của sản phẩm.

Ví dụ: Thay vì phát triển toàn bộ ứng dụng trong 6 tháng, bạn chia thành 12 sprint, mỗi sprint 2 tuần, mỗi sprint tạo ra một tính năng hoàn chỉnh.

2. Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary)

Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng. Các phần nhỏ này thường là:

• Đầy đủ
• Có khả năng chạy tốt
• Được kiểm thử cẩn thận
• Có thể sử dụng ngay

(gọi là potentially shippable product increment)

Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn.

Ví dụ: Sprint 1: Đăng nhập, Sprint 2: Xem danh sách sản phẩm, Sprint 3: Thêm vào giỏ hàng… Cuối cùng bạn có một ứng dụng hoàn chỉnh.

3. Tính thích ứng (Adaptive)

Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc lập kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển đều có thể được đáp ứng:

• Yêu cầu thay đổi
• Thay đổi công nghệ
• Thay đổi định hướng về mục tiêu

Các quy trình Agile thường thích ứng rất tốt với các thay đổi.

Ví dụ: Nếu khách hàng muốn thay đổi một tính năng, bạn chỉ cần đợi đến sprint tiếp theo thay vì phải hủy toàn bộ dự án như mô hình Waterfall.

4. Nhóm tự tổ chức và liên chức năng (Self-organizing & Cross-functional)

Cấu trúc nhóm Agile thường là:

• Liên chức năng (Cross-functional): Nhóm có đủ các kỹ năng cần thiết (developer, tester, designer, BA…)
• Tự tổ chức (Self-organizing): Nhóm tự phân công công việc, tự ra quyết định

Nhóm tự tổ chức có nghĩa là nó đã đủ các kỹ năng cần thiết cho việc phát triển phần mềm, do vậy nó có thể được trao quyền để tự ra quyết định, tự quản lý và tổ chức lấy công việc của chính mình để đạt được hiệu quả cao nhất.

5. Quản lý tiến trình thực nghiệm (Empirical Process Control)

Các nhóm Agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tính toán lý thuyết hay các tiền giả định.

Agile rút ngắn vòng đời phản hồi (short feedback life cycle) để dễ dàng thích nghi và gia tăng tính linh hoạt. Theo thời gian, các chiến lược này sẽ tiến gần đến trạng thái tối ưu.

Ba trụ cột của Empirical Process Control:

• Transparency (Minh bạch): Mọi người đều thấy được những gì đang diễn ra
• Inspection (Kiểm tra): Thường xuyên kiểm tra tiến độ và kết quả
• Adaptation (Thích ứng): Điều chỉnh dựa trên những gì học được

6. Giao tiếp trực diện (Face-to-face Communication)

Agile khuyến khích nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ thuộc nhiều vào các loại văn bản.

Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình viên và một kỹ sư giao tiếp với nhau thông qua bản thiết kế, họ ngồi lại cùng nhau và thảo luận trực tiếp.

7. Phát triển dựa trên giá trị (Value-based Development)

Một trong các nguyên tắc cơ bản của Agile là “phần mềm chạy tốt chính là thước đo của tiến độ”. Nguyên tắc này giúp loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm.

Nhóm Agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng) để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho dự án.

Scrum Framework

Scrum là một framework phổ biến nhất để triển khai Agile. Scrum cung cấp một cấu trúc cụ thể với các vai trò, sự kiện và artifacts rõ ràng.

Scrum là gì?

Scrum là một framework nhẹ nhàng giúp mọi người, nhóm và tổ chức tạo ra giá trị thông qua các giải pháp thích ứng cho các vấn đề phức tạp. Scrum được xây dựng dựa trên triết lý thực nghiệm (empiricism) và tư duy lean (lean thinking).

Ba vai trò trong Scrum

1. Product Owner (PO)

Trách nhiệm:

• Quản lý Product Backlog
• Định nghĩa và sắp xếp thứ tự ưu tiên các User Stories
• Đảm bảo nhóm hiểu rõ yêu cầu
• Chấp nhận hoặc từ chối công việc đã hoàn thành

Đặc điểm:

• Một người, không phải một nhóm
• Phải có quyền quyết định về sản phẩm
• Đại diện cho lợi ích của khách hàng và stakeholders

2. Scrum Master (SM)

Trách nhiệm:

• Đảm bảo nhóm tuân thủ các nguyên tắc và thực hành Scrum
• Loại bỏ các trở ngại (impediments) ngăn cản nhóm làm việc hiệu quả
• Tổ chức và điều hành các sự kiện Scrum
• Huấn luyện nhóm về Scrum

Đặc điểm:

• Không phải là người quản lý dự án truyền thống
• Là người phục vụ nhóm (servant leader)
• Giúp nhóm tự tổ chức và tự quản lý

3. Development Team (Nhóm phát triển)

Trách nhiệm:

• Phát triển sản phẩm trong mỗi Sprint
• Ước lượng công việc
• Tự tổ chức và phân công công việc
• Cam kết hoàn thành Sprint Goal

Đặc điểm:

• Thường từ 3-9 người
• Liên chức năng (cross-functional)
• Tự tổ chức (self-organizing)
• Không có phân cấp trong nhóm

Các Artifacts trong Scrum

1. Product Backlog

Product Backlog là danh sách tất cả các công việc cần làm để phát triển sản phẩm, được sắp xếp theo thứ tự ưu tiên.

Đặc điểm:

• Được quản lý bởi Product Owner
• Luôn thay đổi và được cập nhật liên tục
• Các item ở trên có độ ưu tiên cao hơn
• Được làm rõ dần dần (refinement)

Ví dụ Product Backlog:

1. [P0] User có thể đăng nhập bằng email và password
2. [P0] User có thể xem danh sách sản phẩm
3. [P1] User có thể thêm sản phẩm vào giỏ hàng
4. [P1] User có thể thanh toán
5. [P2] User có thể đánh giá sản phẩm

Product Backlog Refinement

Product Backlog Refinement (hay còn gọi là Backlog Grooming) là quy trình làm rõ, chi tiết hóa và sắp xếp lại các items trong Product Backlog để chuẩn bị cho các Sprint sắp tới.

Quy trình Refinement

Trước khi một ý tưởng trở thành Product Backlog Item, nó cần trải qua quy trình refinement để đảm bảo chất lượng và giá trị:

Các bước trong quy trình:

1. Stakeholder có ý tưởng - Một người nào đó (khách hàng, stakeholder, team member) có ý tưởng về tính năng mới

2. Tìm hiểu “Why” và “What” - Product Owner và nhóm cần hiểu rõ:
   • Why: Tại sao cần tính năng này? Vấn đề nào nó giải quyết?
   • What: Tính năng này làm gì cụ thể?
3. Kiểm tra “Why” rõ ràng chưa?
   • Nếu chưa rõ → Quay lại bước 2 để làm rõ với stakeholder
   • Nếu rõ → Tiếp tục
4. Kiểm tra “What” rõ ràng chưa?
   • Nếu chưa rõ → Quay lại bước 2 để làm rõ với stakeholder
   • Nếu rõ → Tiếp tục
5. Kiểm tra đóng góp cho Product Vision
   • Nếu không đóng góp → Loại bỏ, không lãng phí thời gian
   • Nếu có đóng góp → Tiếp tục
6. Kiểm tra có giá trị không?
   • Nếu không có giá trị → Loại bỏ
   • Nếu có giá trị → Tiếp tục

7. Viết Product Backlog Item - Chính thức thêm vào Product Backlog

8. Bắt đầu Product Backlog Refinement meeting - Nhóm sẽ refinement item này chi tiết hơn

Quy trình Backlog Refinement Meeting

Đặc điểm quan trọng:

• Refinement là Collaborative! - Tất cả mọi người cùng tham gia, không phải chỉ Product Owner

Các bước trong Backlog Refinement:

1. Sprint Goal được outline
   • Xác định lý do hoặc mục đích cho Sprint
   • Thiết lập “tone” cho Sprint
   • Đảm bảo tất cả các team đều hiểu và đồng thuận
2. Product Owner chuẩn bị Stories
   • Stories đã rõ ràng với một số acceptance criteria được định nghĩa
   • Đã được sắp xếp ưu tiên để giữ cho session tập trung
   • Mục tiêu là có ít nhất 1+ Sprint worth of stories sẵn sàng để được refinement
3. Team review và đảm bảo hiểu rõ intent
   • Collaborate! - Làm việc cùng nhau
   • Thêm acceptance criteria phù hợp
   • Chia nhỏ hoặc split stories nếu cần
4. Điều chỉnh/Split/Thêm User Stories nếu cần
   • Chia các stories lớn thành các stories nhỏ có thể thực thi được
   • Thêm stories mới nếu phát hiện thêm yêu cầu hoặc nhu cầu

Kết quả:

• Tất cả Definition of Done nên được cập nhật trong session đó
• Stories đã được làm rõ và sẵn sàng cho Sprint Planning
• Nhóm hiểu rõ về các stories sẽ làm trong Sprint tiếp theo

Tần suất Refinement:

• Thường diễn ra liên tục trong suốt Sprint
• Có thể có một session chính thức mỗi tuần
• Product Owner và Development Team làm việc cùng nhau để refinement

2. Sprint Backlog

Sprint Backlog là tập hợp các Product Backlog items được chọn cho Sprint hiện tại, cộng với kế hoạch để hoàn thành chúng.

Đặc điểm:

• Được tạo ra trong Sprint Planning
• Thuộc về Development Team
• Có thể thay đổi trong Sprint (nếu cần)
• Bao gồm Sprint Goal

3. Increment

Increment là tổng hợp tất cả các Product Backlog items đã hoàn thành trong Sprint hiện tại và tất cả các Sprint trước đó.

Đặc điểm:

• Phải là “Done” (hoàn thành theo Definition of Done)
• Phải có thể sử dụng được (potentially shippable)
• Phải hoạt động tốt

Các Sự kiện (Events) trong Scrum

1. Sprint

Sprint là khung thời gian cố định (thường 1-4 tuần) trong đó một Increment có giá trị được tạo ra.

Đặc điểm:

• Thời gian cố định, không thay đổi
• Mục tiêu rõ ràng (Sprint Goal)
• Không được gián đoạn
• Kết thúc bằng Sprint Review và Retrospective

2. Sprint Planning

Mục đích: Lập kế hoạch cho Sprint sắp tới

Thời gian: Tối đa 8 giờ cho Sprint 1 tháng

Nội dung:

• Phần 1: Chọn Product Backlog items cho Sprint
• Phần 2: Lập kế hoạch làm thế nào để hoàn thành các items đó

Kết quả:

• Sprint Goal
• Sprint Backlog

3. Daily Scrum (Daily Standup)

Mục đích: Đồng bộ hóa công việc và lập kế hoạch cho 24 giờ tiếp theo

Thời gian: 15 phút, mỗi ngày cùng một thời điểm

Nội dung: 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ó trở ngại nào không?

Lưu ý: Không phải là báo cáo tiến độ cho Scrum Master, mà là để nhóm tự đồng bộ.

4. Sprint Review

Mục đích: Kiểm tra Increment và điều chỉnh Product Backlog nếu cần

Thời gian: Tối đa 4 giờ cho Sprint 1 tháng

Nội dung:

• Development Team trình bày những gì đã hoàn thành
• Nhận phản hồi từ Product Owner và stakeholders
• Cập nhật Product Backlog dựa trên phản hồi

Kết quả: Product Backlog được cập nhật

5. Sprint Retrospective

Mục đích: Cải thiện quy trình làm việc của nhóm

Thời gian: Tối đa 3 giờ cho Sprint 1 tháng

Nội dung:

• Nhóm xem xét Sprint vừa qua
• Xác định những gì làm tốt và cần cải thiện
• Lập kế hoạch cải thiện cho Sprint tiếp theo

Kết quả: Action items để cải thiện

User Story và Task

User Story là gì?

User Story là cách mô tả yêu cầu từ góc nhìn của người dùng cuối. User Story thường được viết theo format:

Là một [loại người dùng],
Tôi muốn [hành động],
Để [mục đích/lợi ích].

Ví dụ:

Là một khách hàng,
Tôi muốn đăng nhập bằng email và password,
Để có thể truy cập vào tài khoản của mình.

Đặc điểm của User Story:

• Là thành phần của sản phẩm có thể chuyển giao được
• Product Owner quan tâm đến User Story
• Có giá trị cho người dùng cuối
• Có thể được test và demo

Task là gì?

Task là các công việc cụ thể cần làm để hoàn thành một User Story. Task thường là các công việc kỹ thuật mà Development Team tự chia nhỏ.

Ví dụ Task cho User Story “Đăng nhập”:

• Tạo form đăng nhập (UI)
• Validate email và password
• Tích hợp API đăng nhập
• Viết unit test
• Viết integration test

Đặc điểm của Task:

• Không phải là thành phần chuyển giao được
• Product Owner không quan tâm đến Task
• Là công việc kỹ thuật nội bộ của nhóm
• Không có giá trị trực tiếp cho người dùng cuối

Sự khác biệt giữa Story và Task

Ví dụ minh họa:

User Story: “Là một khách hàng, tôi muốn thêm sản phẩm vào giỏ hàng, để có thể mua nhiều sản phẩm cùng lúc.”

Tasks để hoàn thành Story này:

• Thiết kế UI nút “Thêm vào giỏ”
• Implement logic thêm sản phẩm vào giỏ hàng
• Lưu giỏ hàng vào localStorage
• Hiển thị số lượng sản phẩm trong giỏ hàng
• Viết test cho chức năng này

Story Points và Estimation

Story Points là gì?

Story Points là một đơn vị đo lường tương đối được sử dụng để ước lượng độ phức tạp và công sức cần thiết để hoàn thành một User Story. Story Points không phải là đơn vị thời gian (giờ, ngày), mà là một con số đại diện cho nhiều yếu tố kết hợp.

Story Point đại diện cho điều gì?

Một Story Point là một con số đơn lẻ đại diện cho sự kết hợp của 4 yếu tố:

1. Volume (Khối lượng): Công việc này lớn đến mức nào?
   • Số lượng code cần viết
   • Số lượng tính năng cần implement
   • Quy mô của công việc
2. Complexity (Độ phức tạp): Công việc này khó đến mức nào?
   • Logic phức tạp
   • Thuật toán khó
   • Tích hợp với nhiều hệ thống
3. Knowledge (Kiến thức): Chúng ta có đủ kỹ năng không?
   • Team đã từng làm việc tương tự chưa?
   • Cần học công nghệ mới không?
   • Có expertise trong lĩnh vực này không?
4. Uncertainty (Sự không chắc chắn): Còn điều gì chưa biết?
   • Yêu cầu có rõ ràng không?
   • Có rủi ro tiềm ẩn không?
   • Có nhiều câu hỏi chưa được trả lời không?

Nguyên tắc quan trọng: Story Points là tương đối. Các Stories được ước lượng so với nhau, không phải so với một tiêu chuẩn tuyệt đối.

Ví dụ minh họa:

• Công việc lớn, điểm cao: Giống như một tòa nhà cao tầng - nhiều công việc, phức tạp, cần nhiều thời gian
• Công việc nhỏ, điểm thấp: Giống như các khối xếp hình nhỏ - đơn giản, nhanh chóng, dễ dàng

Các thang đo Story Points

Có nhiều cách để đo Story Points, nhưng có 3 phương pháp phổ biến nhất:

1. T-Shirt Size Scale

Thang đo đơn giản sử dụng kích cỡ áo phông:

• Small (S) - Công việc nhỏ, đơn giản
• Medium (M) - Công việc trung bình
• Large (L) - Công việc lớn
• Extra Large (XL) - Công việc rất lớn

Ưu điểm:

• Dễ hiểu, không cần số học
• Phù hợp cho người mới bắt đầu
• Tránh được việc tranh cãi về số điểm cụ thể

Nhược điểm:

• Không chi tiết bằng các thang đo số
• Khó so sánh chính xác giữa các stories

2. Power of 2 Scale

Thang đo dựa trên lũy thừa của 2:

• 2⁰ = 1
• 2¹ = 2
• 2² = 4
• 2³ = 8
• 2⁴ = 16
• 2⁵ = 32
• 2⁶ = 64
• …

Đặc điểm:

• Khoảng cách giữa các mức tăng theo cấp số nhân
• Phù hợp khi có sự khác biệt lớn giữa các stories
• Giúp nhóm tránh ước lượng quá chi tiết cho các công việc lớn

3. Rounded Fibonacci Scale (Phổ biến nhất)

Thang đo Fibonacci được làm tròn là phương pháp phổ biến nhất:

1, 2, 3, 5, 8, 13, 20, 40, 100

Đặc điểm:

• Dựa trên dãy Fibonacci (mỗi số bằng tổng 2 số trước)
• Được làm tròn để dễ sử dụng
• Rất phù hợp khi ước lượng các công việc lớn

Tại sao Fibonacci phổ biến?

1. Phản ánh sự không chắc chắn: Khi công việc lớn hơn, độ không chắc chắn tăng nhanh hơn. Fibonacci phản ánh điều này tốt hơn thang đo tuyến tính.

2. Tránh tranh cãi: Khoảng cách lớn giữa các số giúp nhóm không tranh cãi về sự khác biệt nhỏ (ví dụ: 8 vs 9).

3. Tập trung vào tương đối: Nhóm tập trung vào việc so sánh stories với nhau thay vì cố gắng đo chính xác.

Planning Poker Cards:

Các thẻ Planning Poker thường sử dụng Fibonacci scale:

• 0 - Không có công việc hoặc đã hoàn thành
• 1/2 - Công việc rất nhỏ
• 1, 2, 3, 5, 8, 13 - Các mức điểm phổ biến
• 20, 40, 100 - Công việc rất lớn
• ? - Cần làm rõ thêm
• ∞ - Quá lớn, cần chia nhỏ

Cách ước lượng Story Points

Planning Poker

Planning Poker là kỹ thuật phổ biến nhất để ước lượng Story Points:

Quy trình:

1. Product Owner trình bày Story - Giải thích User Story và acceptance criteria

2. Nhóm đặt câu hỏi - Mọi người có thể hỏi để làm rõ

3. Mỗi người chọn một thẻ - Mỗi thành viên chọn một thẻ Planning Poker đại diện cho ước lượng của họ (không cho người khác thấy)

4. Tất cả cùng lật thẻ - Mọi người cùng lúc lật thẻ để công khai ước lượng

5. Thảo luận nếu khác biệt lớn
   • Nếu tất cả chọn cùng một số → Chấp nhận số đó
   • Nếu có khác biệt lớn (ví dụ: 3 vs 13) → Người chọn số cao và thấp giải thích lý do
6. Lặp lại - Lặp lại bước 3-5 cho đến khi đạt được đồng thuận

Lợi ích của Planning Poker:

• Tránh ảnh hưởng của người có tiếng nói lớn
• Mọi người đều có cơ hội đóng góp ý kiến
• Thúc đẩy thảo luận và làm rõ
• Tạo sự đồng thuận trong nhóm

Relative Estimation (Ước lượng tương đối)

Nguyên tắc: So sánh stories với nhau, không so sánh với thời gian tuyệt đối.

Cách làm:

1. Chọn một Story baseline - Chọn một story đơn giản làm chuẩn (ví dụ: 2 points)

2. So sánh các stories khác - Mỗi story khác được so sánh với baseline:
   • “Story này lớn gấp đôi baseline” → 4 points
   • “Story này lớn gấp 3 lần baseline” → 6 points (làm tròn thành 8)
   • “Story này nhỏ hơn baseline một chút” → 1 point
3. Điều chỉnh khi cần - Khi có story mới, so sánh với các stories đã ước lượng

Ví dụ:

Baseline: "Hiển thị danh sách sản phẩm" = 2 points

"So sánh với baseline:"
- "Thêm sản phẩm vào giỏ hàng" = 3 points (phức tạp hơn một chút)
- "Thanh toán" = 8 points (phức tạp hơn nhiều)
- "Đăng nhập" = 5 points (trung bình)

Velocity và Sprint Planning

Velocity là tổng số Story Points mà nhóm hoàn thành trong một Sprint.

Ví dụ:

• Sprint 1: Hoàn thành 21 points
• Sprint 2: Hoàn thành 23 points
• Sprint 3: Hoàn thành 20 points
• Average Velocity: ~21 points

Sử dụng Velocity trong Sprint Planning:

1. Xem Average Velocity - Nhóm có thể hoàn thành khoảng bao nhiêu points mỗi Sprint?

2. Chọn Stories cho Sprint - Chọn các stories có tổng points tương đương với velocity

3. Không cam kết quá mức - Không nên chọn nhiều hơn velocity trung bình

Lưu ý quan trọng:

• Velocity chỉ là hướng dẫn, không phải cam kết chắc chắn
• Velocity có thể thay đổi khi nhóm học hỏi và cải thiện
• Không so sánh velocity giữa các nhóm khác nhau
• Velocity của nhóm này không áp dụng cho nhóm khác

Best Practices khi Estimation

1. Ước lượng theo nhóm - Không để một người ước lượng một mình

2. Sử dụng Planning Poker - Đảm bảo mọi người đều có tiếng nói

3. Không ước lượng quá chi tiết - Story Points là tương đối, không cần chính xác tuyệt đối

4. Chia nhỏ stories lớn - Nếu story quá lớn (> 13 points), nên chia nhỏ

5. Không chuyển đổi sang giờ - Story Points không phải giờ, đừng cố chuyển đổi

6. Re-estimate khi cần - Nếu hiểu rõ hơn về story, có thể re-estimate

7. Tập trung vào tương đối - Quan trọng là so sánh stories với nhau

Quy trình làm việc với Scrum

Chu kỳ Sprint

Sprint Planning
    ↓
Daily Scrum (mỗi ngày)
    ↓
Làm việc phát triển
    ↓
Sprint Review
    ↓
Sprint Retrospective
    ↓
Sprint Planning (Sprint tiếp theo)

Ví dụ một Sprint 2 tuần

Tuần 1:

• Thứ 2: Sprint Planning (2 giờ)
• Thứ 3-6: Daily Scrum mỗi ngày + phát triển
• Thứ 7: Làm việc phát triển

Tuần 2:

• Thứ 2-5: Daily Scrum mỗi ngày + phát triển
• Thứ 6:
  • Sprint Review (1 giờ)
  • Sprint Retrospective (1 giờ)

Lợi ích của Agile và Scrum

1. Giao hàng nhanh hơn

• Khách hàng nhận được giá trị sớm hơn
• Giảm thời gian từ ý tưởng đến sản phẩm

2. Phản hồi sớm

• Nhận phản hồi từ khách hàng ngay từ những sprint đầu tiên
• Điều chỉnh hướng đi kịp thời

3. Linh hoạt với thay đổi

• Dễ dàng thay đổi yêu cầu
• Thích ứng nhanh với thị trường

4. Tăng chất lượng

• Test liên tục trong mỗi sprint
• Phát hiện lỗi sớm
• Code được review thường xuyên

5. Tăng sự hài lòng

• Khách hàng hài lòng vì nhận được giá trị sớm
• Nhóm phát triển hài lòng vì có quyền tự chủ và môi trường làm việc tốt

6. Giảm rủi ro

• Rủi ro được phát hiện sớm
• Có thể điều chỉnh kịp thời

Thách thức khi áp dụng Agile/Scrum

1. Thay đổi văn hóa

• Cần thay đổi cách suy nghĩ và làm việc
• Không phải ai cũng sẵn sàng thay đổi

2. Yêu cầu sự cam kết

• Cần sự cam kết từ cả nhóm và tổ chức
• Cần thời gian để học hỏi và cải thiện

3. Khó khăn trong ước lượng

• Ước lượng trong Agile khác với cách truyền thống
• Cần thời gian để làm quen

4. Quản lý Product Backlog

• Cần Product Owner có kinh nghiệm
• Cần thời gian để làm rõ các User Stories

Best Practices khi áp dụng Scrum

1. Giữ Sprint length cố định

• Không thay đổi độ dài Sprint
• Giúp nhóm có nhịp độ làm việc ổn định

2. Đảm bảo Definition of Done rõ ràng

• Mọi người hiểu rõ “Done” nghĩa là gì
• Đảm bảo chất lượng sản phẩm

3. Tổ chức Daily Scrum đúng cách

• Đúng giờ, đúng địa điểm
• Tập trung vào đồng bộ, không phải báo cáo

4. Tôn trọng các sự kiện Scrum

• Không bỏ qua hoặc rút ngắn các sự kiện
• Mỗi sự kiện đều có mục đích riêng

5. Product Owner phải có quyền quyết định

• PO phải có thể đưa ra quyết định về sản phẩm
• Không thể chỉ là người truyền đạt yêu cầu

6. Nhóm phải tự tổ chức

• Không có người quản lý chỉ huy
• Nhóm tự phân công và tự quản lý công việc

Tài liệu tham khảo và chứng chỉ

Chứng chỉ Scrum

• Professional Scrum Master I (PSM I): https://www.scrum.org/professional-scrum-master-i-certification
• Đây là chứng chỉ phổ biến nhất về Scrum Master
• Có thể thi online và nhận chứng chỉ ngay

Sách tham khảo

Sách chính:

• Tiếng Anh: “Scrum And XP From The Trenches” - Henrik Kniberg
• Tiếng Việt: “Scrum và XP từ những chiến hào” - Henrik Kniberg

Tài liệu chính thức:

• Scrum Guide: https://scrumguides.org/scrum-guide.html
  • Tài liệu chính thức về Scrum framework
  • Được cập nhật định kỳ bởi các tác giả của Scrum

Tài liệu tham khảo khác:

• “Agile Estimating and Planning” - Mike Cohn
• “Agile Project Management with Scrum” - Ken Schwaber

Lộ trình học Scrum

Dưới đây là một lộ trình học Scrum mẫu có thể tham khảo:

Kết luận

Agile và Scrum không chỉ là các phương pháp quản lý dự án, mà còn là một triết lý và văn hóa làm việc mới. Chúng tập trung vào:

• Con người hơn là quy trình
• Giá trị hơn là tài liệu
• Hợp tác hơn là đàm phán
• Thích ứng hơn là tuân thủ

Để áp dụng thành công Agile và Scrum, bạn cần:

1. Hiểu rõ các giá trị và nguyên lý - Không chỉ học thuộc mà phải hiểu sâu
2. Bắt đầu từ nhỏ - Áp dụng từ một nhóm nhỏ trước
3. Kiên nhẫn - Cần thời gian để thay đổi và cải thiện
4. Học hỏi liên tục - Luôn tìm cách cải thiện
5. Có Scrum Master tốt - Người có thể hướng dẫn và hỗ trợ nhóm

Agile và Scrum không phải là giải pháp cho mọi vấn đề, nhưng chúng đã chứng minh được hiệu quả trong việc phát triển phần mềm và quản lý dự án trong thế giới thay đổi nhanh chóng ngày nay.

Chúc bạn thành công trong hành trình áp dụng Agile và Scrum!