Ở nơi đầu tiên tôi làm việc, PM (Project Manager) nói với tôi rằng team đang vận hành theo mô hình Agile Scrum. Nhưng anh lại chẳng thể nào giải thích rõ ràng cho tôi Agile là gì? Scrum là gì? Scrum hoạt động như nào? Các vai trò trong Scrum ra sao? Và lợi ích của phương pháp Scrum trong phát triển phần mềm là gì?

Làm sao tôi biết team của tôi có thực hành đúng quy trình Scrum hay không khi tôi còn chưa hiểu tí gì về Scrum?

May mắn thay, nhờ vào những trải nghiệm trong công việc và tìm được đúng tài liệu, tôi đã không còn mơ hồ như xưa và có cái nhìn rõ ràng về Agile và Scrum.

Bài viết này cung cấp đầy đủ kiến thức và tài liệu về Agile và Scrum. Hi vọng chúng sẽ giúp ích cho các bạn.

1. Agile là gì?

1.1. Các phương pháp phát triển phần mềm trước Agile

Trước khi có Agile, các phương pháp phát triển phần mềm truyền thống được sử dụng phổ biến, điển hình là mô hình phát triển phần mềm thác nước (Waterfall).

Tuy nhiên, các mô hình truyền thống ấy gặp phải những hạn chế sau:

• Tỷ lệ sai sót cao: Trong mô hình thác nước có 6 giai đoạn thực hiện nối tiếp nhau và nếu tỷ lệ sai sót ở mỗi giai đoạn là 5%, nó sẽ tăng theo mức luỹ thừa trong cả quá trình thành một con số khủng khiếp (~30%).
• Cứng nhắc và phản ứng kém với thay đổi: Trong mô hình thác nước, nếu có phát sinh thay đổi, nhà quản trị thường có hai cách phản ứng hoặc loại bỏ thay đổi bằng những cách khéo léo hoặc quay lại đỉnh của waterfall để chào đón thay đổi.
• Lãng phí: Tài liệu và chức năng ở từng giai đoạn có thể không được sử dụng ở giai đoạn khác trong quá trình phát triển gây ra sự lãng phí lớn.

Những lý do trên cho thấy sự lỗi thời của các phương pháp phát triển phần mềm truyền thống, thúc đẩy sự ra đời của các phương pháp linh hoạt và hiệu quả hơn như Agile.

1.2. Giới thiệu về Agile

Agile là một phương pháp luận (methodology) về quản lý dự án bao gồm việc phân chia dự án thành các giai đoạn và nhấn mạnh sự hợp tác và cải tiến lên tục.

Tuyên ngôn Agile (Agile Manifeso) là tài liệu nền tảng cho tư tưởng Agile trong phát triển phần mềm. Nó được 17 nhà phát triển phần mềm (gọi chung là Liên minh Agile - Agile Alliance) tạo ra vào tháng 2 năm 2001 trong một cuộc họp ở Snowbird, Utah.

Bản dịch Tuyên ngôn Agile dưới đây được công bố bởi Hanoi Scrum vào năm 2011 và được biết đến rộng rãi ở Việt Nam. Bản gốc tiếng anh: http://agilemanifesto.org/

Bốn giá trị cốt lõi trong Tuyên ngôn Agile bao gồm:

1. Cá nhân và sự tương tác hơn là quy trình và công cụ: Agile nhấn mạnh tầm quan trọng của con người và sự cộng tác của họ hơn là việc tuân thủ nghiêm ngặt các công cụ hoặc quy trình.
2. Phần mềm chạy tốt hơn là tài liệu đầy đủ: Thay vì dành nhiều thời gian cho việc tạo tài liệu, Agile tập trung vào việc cung cấp phần mềm chạy tốt một cách nhanh chóng.
3. Cộng tác với khách hàng hơn là đàm phán hợp đồng: Sự tương tác thường xuyên với khách hàng hoặc các bên liên quan được coi là có giá trị hơn việc bám chặt vào các thỏa thuận hoặc hợp đồng ban đầu.
4. Phản hồi với các thay đổi hơn là bám sát kế hoạch: Agile team có khả năng thích ứng và có thể xoay vòng dựa trên phản hồi hoặc yêu cầu thay đổi, thay vì tuân thủ nghiêm ngặt kế hoạch ban đầu.

1.3. Chiếc ô Agile

Chiếc ô Agile nhằm chỉ các phương pháp thực hành Agile phổ biến bao gồm Scrum, Kanban, XP (Extreme Programming), Lean, FDD (Feature-Driven Development), DSDM (Dynamic Systems Development Method).

2. Scrum là gì?

2.1. Tổng quan về Scrum

Scrum là phương pháp nổi tiếng và phổ biến nhất (chiếm ~52% tỷ lệ thực hành) trong tập hợp các phương pháp phát triển phần mềm theo tư tưởng Agile.

Scrum không phải là một quy trình hay kỹ thuật để phát triển sản phẩm phần mềm, Scrum là một management framework cho phép chúng ta sử dụng những quy trình hay kỹ thuật khác nhau nhằm đạt hiệu quả cao nhất về sự thích ứng và sáng tạo.

Nguồn: Agile Y

2.2. Cách làm việc trong Scrum

Cách làm việc trong Scrum có thể được minh hoạ như hình dưới đây:

1. Product Owner tạo ra Product Goal và Product Backlog chứa các yêu cầu của dự án với những hạng mục được xếp theo độ ưu tiên.
2. Nhóm Scrum sẽ phát triển sản phẩm thông qua nhiều Sprint. Mỗi Sprint kéo dài 1 tới 4 tuần. Bắt đầu Sprint với một cuộc họp Sprint Planning để ước lượng công việc, lập kế hoạch và xác định Sprint Goal.
3. Các ngày trong Sprint, nhóm Scrum làm việc cùng nhau, thực hiện họp Daily Scrum tối đa 15 phút mỗi ngày.
4. Trong Sprint, Nhóm phát triển tạo ra các phần tăng trưởng, gọi là Increment.
5. Kết thúc Sprint, nhóm Scrum thực hiện Sprint Review để review sản phẩm.
6. Sau đó, nhóm Scrum thực hiện Sprint Retrospective để cải tiến quy trình.

3. Scrum Team là gì?

Scrum Team (nhóm Scrum) là một nhóm nhỏ, tối đa 10 người, bao gồm một Product Owner (PO), một Scrum Master và Nhóm phát triển (Developement Team).

Khi nhóm Scrum trở nên quá lớn (trên 10 thành viên), họ nên cân nhắc việc tổ chức lại thành nhiều nhóm Scrum nhỏ hơn có sự liên kết với nhau. Vì các nhóm Scrum đó đều tập trung vào cùng một sản phẩm nên họ cần chia sẻ cùng Product Goal, Product Backlog và Product Owner.

3.1. Product Owner (PO)

Product Owner là người chịu trách nhiệm tối đa hoá giá trị của sản phẩm và công việc của Nhóm phát triển.

Product owner là người duy nhất chịu trách nhiệm về việc quản lý sản phẩm, quản lý Product Backlog bao gồm:

• Phát triển và truyền đạt rõ ràng Product Goal
• Tạo ra và truyền đạt các mục trong Product Backlog
• Tạo thứ tự ưu tiên cho các mục trong Product Backlog
• Đảm bảo Product Backlog minh bạch, rõ ràng và dễ hiểu

Trong tổ chức, Product Owner có thể tham gia nhiều nhóm Scrum khác nhau.

3.2. Scrum Master

Scrum Master là người chịu trách nhiệm đảm bảo Scrum được hiểu và được thực hành đúng trong nhóm Scrum. Scrum Master thực hiện việc này bằng cách đảm bảo rằng nhóm Scrum luôn tôn trọng lý thuyết Scrum và quy tắc đã được thống nhất trong nhóm.

Trong một tổ chức, Scrum Master có thể tham gia nhiều nhóm Scrum khác nhau.

Vai trò của Scrum Master đối với Product Owner bao gồm:

• Tìm kiếm các kỹ thuật hỗ trợ việc xác định Product Goal và quản lý Product Backlog một cách hiệu quả
• Giúp nhóm Scrum hiểu được sự cần thiết của việc giữ các hạng mục trong Product Backlog rõ ràng và súc tích
• Hiểu kế hoạch phần mềm trong môi trường thử nghiệm
• Tạo điều kiện cho sự hợp tác giữa các bên liên quan khi được yêu cầu

Vai trò của Scrum Master đối với Nhóm phát triển bao gồm:

• Huấn luyện Nhóm phát triển có khả năng tự tổ chức và làm việc liên chức năng
• Giúp nhóm tập trung tạo ra Increment có giá trị cao và đáp ứng DoD
• Loại bỏ rào cản ảnh hưởng tới tiến độ của nhóm
• Đảm bảo tất cả các sự kiện Scrum đều được diễn ra hiệu quả, tích cực và giới hạn trong khung thời gian quy định

Vai trò của Scrum Master đối với tổ chức bao gồm:

• Dẫn dắt, đào tạo và huấn luyện tổ chức trong việc áp dụng Scrum
• Lập kế hoạch triển khai Scrum trong tổ chức
• Giúp nhân viên và các bên liên quan hiểu và thực hành Scrum
• Loại bỏ các rào cản giữa các bên liên quan và nhóm Scrum

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

Nhóm phát triển (Development Team) bao gồm các chuyên gia, những người có đầy đủ năng lực chuyên môn cùng cộng tác với nhau để đưa ra một phần tăng trưởng vào cuối mỗi Sprint. Chỉ có các thành viên của Nhóm phát triển tạo ra các phần tăng trưởng (Increment).

Các kỹ năng cụ thể mà Nhóm phát triển cần có thường rất rộng và sẽ thay đổi tùy theo lĩnh vực công việc. Tuy nhiên, Nhóm phát triển giữ các trách nhiệm sau:  

• Lập kế hoạch cho Sprint, xác định Sprint Backlog
• Thúc đẩy chất lượng bằng cách tuân thủ DoD (Definition of Done)
• Điều chỉnh kế hoạch mỗi ngày hướng tới Sprint Goal
• Chịu trách nhiệm cùng nhau như những chuyên gia

Nhóm phát triển có những đặc điểm sau:

• Là nhóm tự tổ chức công việc mà không cần ai chỉ định hoặc phân công công việc. Nghĩa là trong nhóm sẽ không có chức danh quản lý hay lãnh đạo. Tuy nhiên, trong nhóm sẽ có những cá nhân đảm nhận vai trò lãnh đạo và vai trò này có thể thay đổi dựa trên kinh nghiệm, kỹ năng hoặc tình huống cụ thể.
• Là nhóm liên chức năng có tất cả kỹ năng cần thiết để tạo ra sản phẩm hoàn chỉnh.
• Quy mô của nhóm phải đủ lớn, khuyến nghị 7 - 9 thành viên.
• Các thành viên trong nhóm phát triển không có các chức danh khác nhau, bất kể công việc họ thực hiện là gì.
• Là đơn vị nhỏ nhất, không thể bao gồm các nhóm nhỏ hơn.
• Các thành viên trong nhóm phải chịu trách nhiệm cùng nhau cho kết quả đầu ra, không quy trách nhiệm theo cá nhân.

4. Các sự kiện trong Scrum

4.1. Sprint

Sprint là khoảng thời gian bao gồm tất cả các sự kiện Scrum khác. Nó được coi là trái tim của Scrum, nơi ý tưởng được biến thành giá trị.

Một Sprint mới thường bắt đầu vào thứ 2 với sự kiện Sprint Planning, ngay sau khi kết thúc Sprint trước đó và kết thúc vào thứ 6 cùng sự kiện Sprint Restrospective.

4.2. Sprint Planning

Sprint Planning là cuộc họp lập kế hoạch công việc cho Sprint sắp tới, thời diễn ra vào đầu Sprint. Đây được coi là sự kiện khởi đầu của Sprint.

Sprint planning thường đề cập tới Increment (phần tăng trưởng của Sprint) là gì và chúng sẽ được hoàn thành như nào.

Thành phần tham dự	ScrumMaster Product Owner Nhóm phát triển
Thời gian	Tối đa là 8 giờ cho Sprint 4 tuần
Kết quả	Sprint Backlog Sprint Goal

Trong Sprint Planning, các nhóm hay dùng đơn vị ước lượng là giờ vì nó trực quan và dễ hiểu. Tuy nhiên, phương pháp Scrum khuyến nghị sử dụng một đơn vị trung tính hơn là Story Point.

Story Point không phải là một con số cụ thể và không bị ràng buộc bởi bất kỳ thước đo cụ thể nào về thời gian hay độ phức tạp. Thay vào đó, nó được sử dụng để so sánh nỗ lực tương đối của các hạng mục công việc với nhau

Các nhóm hay dùng kỹ thuật Planning Poker dùng dãy số Fibonacci để ước lượng Story Point.

Để mô tả cách nhóm Scrum sử dụng Story Point như nào, tôi có một ví dụ sau:

User story: "Là người dùng, tôi muốn đặt lại mật khẩu của mình để có thể lấy lại quyền truy cập vào tài khoản của mình nếu lỡ tôi quên mật khẩu."

Các bước thực hiện ước lượng bằng Story Point:

1. User story: PO giới thiệu chi tiết User story, đảm bảo tất cả đều hiểu rõ yêu cầu.
2. Ước lượng: Trong Sprint Planning, mỗi thành viên trong nhóm chọn một lá bài từ bộ bài mà họ cảm thấy thể hiện nỗ lực cần thiết cho User story ở trên. Các lá bài chứ một số thuộc dãy Fibonacci: 1, 2, 3, 5, 8, 13, 21, ...
3. Tiết lộ: Sau khi mọi người đã chọn một thẻ, tất cả các thành viên trong nhóm sẽ đồng thời tiết lộ thẻ của mình. Giả sử, A bốc được 5, tương tự B - 8, C - 5 và D - 8
4. Thảo luận: Nếu có sự khác biệt lớn trong ước lượng (ví dụ: A chọn 3 trong khi B chọn 21), nhóm sẽ thảo luận lý do đưa ra ước lượng của họ. Trong ví dụ này, chỉ có một sự khác biệt nhỏ: một số chọn 5 và những người khác chọn 8. Cả A và C chọn 5, có thể giải thích lý do tại sao họ cảm thấy cần nỗ lực ít hơn, B và D chọn 8, có thể làm rõ lý do tại sao họ cần nhiều nỗ lực hơn.
5. Ước lượng lại (nếu cần): Việc cá nhân chọn lại thẻ có thể diễn ra nếu cần.
6. Đồng thuận: Nhóm đạt được sự đồng thuận về ước tính nỗ lực. Trong ví dụ này, sau khi thảo luận, mọi người có thể thống nhất rằng 8 là story point.

Kết quả: User story trên có story point là 8.

4.3. Daily Scrum

Daily Scrum là cuộc họp diễn ra trong tối đa 15 phút, tại một thời điểm cố định, tại một vị trí cố định, trong đó các thành viên trong nhóm phát triển lần lượt trả lời đúng 3 câu hỏi sau:

1. Tôi đã làm gì trong 24 giờ đã qua để đạt được Sprint Goal?
2. Tôi sẽ làm gì trong 24 giờ tiếp theo để đạt được Sprint Goal?
3. Tôi thấy có trở ngại gì ảnh hưởng tới tôi hoặc nhóm phát triển để đạt được Sprint Goal?

Sau khi mọi thành viên của nhóm phát triển trả lời đủ 3 câu hỏi này, nhóm phát triển sẽ đồng bộ kế hoạch với nhau và có ngay kế hoạch cho 24 giờ tiếp theo, được cập nhật trong Sprint Backlog, để hướng tới Sprint Goal.

Thành phần tham dự	Nhóm phát triển ScrumMaster
Thời gian	Tối đa là 15 phút
Kết quả	Kế hoạch được cập nhật cho ngày

Các đặc điểm của Daily Scrum bao gồm:

• Daily Scrum thường được gọi là daily standup meeting.
• Daily Scrum được thực hiện vào một thời điểm cố định trong ngày, tại một địa điểm cố định.
• Daily Scrum chỉ diễn ra trong timebox 15 phút.
• Daily Scrum chấp nhận những câu trả lời như “tôi không làm gì để đạt được Sprint Goal trong 24 giờ đã qua”, “tôi sẽ không làm gì để đạt được Sprint Goal trong 24 giờ tới”.

Cần lưu ý rằng Daily Scrum không phải là lần duy nhất trong ngày Nhóm phát triển được phép điều chỉnh kế hoạch của mình. Họ có thể gặp nhau vào thời điểm khác trong ngày để thảo luận chi tiết hơn về việc điều chỉnh hoặc lập lại kế hoạch cho Sprint.

4.4. Sprint Review

Sprint Review là sự kiện được tổ chức vào cuối Sprint để đánh giá kết quả của Sprint.

Thành phần tham dự	ScrumMaster Nhóm phát triển Product Owner Các bên có liên quan
Thời gian	Tối đa là 4 giờ với Sprint 4 tuần
Kết quả	Product Backlog được chỉnh sửa cho phù hợp với Sprint tiếp theo

4.5. Sprint Retrospective

Sprint Retrospective là cuộc họp để để nhìn lại Sprint vừa qua và lên kế hoạch để nâng cao chất lượng và hiệu quả cho các Sprint sắp tới, thường diễn ra sau Sprint Review và trước Sprint Planning.

Thành phần tham dự	ScrumMaster Product Owner Nhóm phát triển
Thời gian	Tối đa là 3 giờ với Sprint 4 tuần
Kết quả	Cải tiến quy trình

Sprint Retrospective là một sự kiện đặc biệt quan trọng trong Scrum. Tuy vậy, rất ít tổ chức thực hiện hoặc thực hiện không đúng Sprint Retrospective khiến nhóm Scrum không đạt được hiệu quả như mong muốn.

4.6. Backlog Refinement (Grooming)

Backlog Refinement (Tinh chỉnh Backlog, còn được gọi là Grooming) là một sự kiện diễn ra để cập nhật và sắp xếp ưu tiên cho Product Backlog. Đây không phải là sự kiện bắt buộc trong Scrum như Daily Scrum hay Sprint Review.

Backlog Refinement có thể diễn ra nhiều lần trong tuần hoặc vào những khoảng thời gian phù hợp tuỳ thuộc vào tính chất của dự án và thói quen của nhóm.

Thành phần tham dự	Product Owner Nhóm phát triển Scrum Master (không bắt buộc)
Thời gian	Không có khung thời gian cố định nhưng thường chiếm tối đa 10% quỹ thời gian có sẵn của Nhóm phát triển
Kết quả	Product backlog được cải tiến với các hạng mục rõ ràng

5. Scrum Artifacts

Artifact (tạo tác) trong Scrum được hiểu là những thể hiện của công việc hoặc giá trị, được minh bạch nhằm tạo khả năng thanh tra và thích ứng.

5.1. User Story

5.1.1. User Story là gì?

User story (câu chuyện người dùng) là một thuật ngữ để nêu ra yêu cầu trong phát triển phần mềm với Agile.

Lý do gọi là User story vì yêu cầu được viết dưới góc nhìn của người dùng, và vì vậy giúp nhóm phát triển hiểu được giá trị họ mang lại cho người dùng, chứ không phải là thực hiện những công việc khô khan, nhằm khuyến khích họ thực hiện công việc.

User story thường có dạng: Là <người dùng>, tôi muốn <mục tiêu>, để <giá trị>

5.1.2. Các tính chất của User story

Một User Story được coi là tốt nếu đáp ứng được theo mô hình INVEST:

• Independent (độc lập): User Story này không bị ràng buộc với những User Story khác, và có thể triển khai một cách độc lập;
• Negotiable (có thể thương lượng): User Story có thể được thương lượng về mặt scope, accept criteria để đảm bảo được hoàn thành trong nhiều nhất một Sprint;
• Valuable (có giá trị): User Story phải cung cấp giá trị kinh doanh, nghiệp vụ cho người dùng; điều này cũng giúp Nhóm phát triển hào hứng hơn khi nhìn thấy công việc của mình không lãng phí;
• Estimable (có thể ước lượng): User Story phải có thể ước lượng được theo Story Point hoặc giờ để đảm bảo hoàn thành trong tối đa một Sprint;
• Small (nhỏ): User Story phải đủ nhỏ để dễ hiểu và hoàn thành trong tối đa trong một Sprint.
• Testable (có thể kiểm thử): User Story phải có thể định nghĩa việc kiểm thử, accept criteria nhằm đánh giá được mức độ hoàn thành trong Sprint Review.

5.1.3. Các giai đoạn của user story

Các giai đoạn của User story bao gồm:

1. Phân tích: Là <người dùng> tôi muốn <mục tiêu> để <giá trị>
2. Release Planning: Là <người dùng> tôi muốn <mục tiêu> để <giá trị> Hoàn thành khi: <deadline>
3. Sprint Planning: Là <người dùng> tôi muốn <mục tiêu> để <giá trị> Hoàn thành khi: <deadline> Để thực hiện phải <nhiệm vụ>

5.2. Product Backlog

Product Backlog là một danh sách các hạng mục được sắp xếp theo độ ưu tiên, và khi những hạng mục đó được hoàn thành thì dự án hoàn thành. Product Owner là người duy nhất chịu trách nhiệm quản lý Product Backlog.

Do những hạng mục trong Product Backlog được sắp xếp theo thứ tự ưu tiên nên Nhóm phát triển chỉ cần nhận chúng theo thứ tự từ trên xuống dựa trên các yếu tố như năng lực hiện tại của nhóm và hiệu suất làm việc trước đây của nhóm.

5.3. Product Goal

Product Goal mô tả trạng thái tương lai của sản phẩm, đóng vai trò là mục tiêu dài hạn để lập kế hoạch của Srum Team.

Sự cam kết thực hiện Product Backlog chính là Product Goal (Mục tiêu sản phẩm). Tại bất kỳ thời điểm nào, chỉ có một Product Goal cho mỗi Product Backlog.

Product Owner là người chịu trách nhiệm tạo ra Product Goal và truyền đạt nó tới các thành viên khác trong nhóm Scrum.

5.4. Sprint Backlog

Sprint Backlog như tên gọi là Backlog cho Sprint, thay vì Backlog cho cả sản phẩm như Product Backlog.

Sprint Backlog được quản lý bởi Nhóm phát triển và bao gồm các thành phần sau:

• User story: câu chuyện người dùng bao gồm mô tả tính năng viết từ quan điểm của người dùng
• Task name: tên của đầu việc
• Task description: mô tả đầu việc
• Task prioritization: đánh số ưu tiên cho đầu việc
• Sprint burn-down chart: burn-down chart là một biểu đồ mô tả công việc còn lại phải làm so với thời gian cần thiết để hoàn thành nó
• Daily time allocation: thời gian hoàn thành một task trong ngày dưới dạng số giờ hoặc số phút

5.5. Sprint Goal

Sprint Goal là mục tiêu duy nhất của Sprint và được cam kết thực hiện bởi Nhóm phát triển.

Sprint Goal được tạo bởi nhóm Scrum trong buổi họp Sprint Planning dựa trên các hạng mục có giá trị nhất ở Product Backlog.

5.6. Increment

Increment (phần tăng trưởng của Sprint) là những gì được Product Owner kỳ vọng, phần giá trị có thể tạo ra từ những hạng mục còn lại trong Product Backlog.

5.7. Definition of Done

Definition of Done (DoD: định nghĩa hoàn thành) cho biết chính xác thế nào là một công việc được coi là “hoàn thành”. DoD được coi như một bài kiểm thử, nếu công việc hiện tại đáp ứng được tất cả những yêu cầu trong DoD, công việc được coi là hoàn thành. Ngược lại, chỉ cần một yêu cầu không được đáp ứng, cả công việc được coi là chưa hoàn thành.

5.8. Burn-down Chart

Có 2 loại Burn-down Chart phổ biến là Release Burn-down Chart và Sprint Burn- down Chart, hướng tới việc theo dõi tiến độ và khả năng đạt được của Release Goal và Sprint Goal. Như tên gọi, 2 loại biểu đồ này nhằm cung cấp thông tin về khả năng nhóm Scrum có thể đạt được những mốc để release sản phẩm hay Sprint.

6. Ba trụ cột của Scrum

6.1. Minh bạch

Minh bạch (Transparency) là tất cả các thông tin cần thiết cho việc hoàn thành công việc đều được cung cấp đầy đủ, chính xác và nhất quán cho các bên liên quan.

Minh bạch đảm bảo mọi thành viên đều có chung sự hiểu biết và kỳ vọng đúng về những gì đang diễn ra, giúp họ đưa ra quyết định chính xác và kịp thời.

Minh bạch thể hiện ở các Scrum Artifact như

• Product Backlog và Sprint Backlog: Mọi người đều có thể cùng quan sát công việc đang diễn ra như nào.
• Sprint Review: Kết quả công việc được cung cấp cho các bên liên quan về những gì đã và chưa hoàn thành.

6.2. Thanh tra

Thanh tra (Inspection) là việc kiểm tra liên tục và thường xuyên công việc để xác định vấn đề phát sinh cần giải quyết.

Thanh tra đảm bảo phát hiện sớm và giải quyết nhanh chóng các vấn đề phát sinh, nhằm giúp dự án diễn ra suôn sẻ, bám sát mục tiêu đề ra.

Thanh tra thể hiện thông qua các sự kiện Scrum như

• Daily Scrum giúp nhóm Scrum kiểm tra tình hình hiện tại và điều chỉnh kế hoạch nếu cần.
• Sprint Backlog cho biết tình hình hiện tại với tần suất từng giờ.
• Sprint Retrospective cho biết những gì đã xảy ra, so sánh với kỳ vọng.

6.3. Thích nghi

Thích nghi (Adaptation) là việc điều chỉnh hành vi hoặc kế hoạch hoặc phương pháp dựa trên kết quả của việc thanh tra.

Thích nghi để ứng phó với sự thay đổi liên tục từ môi trường, đem lại hiệu quả cao nhất.

Thích nghi thể hiện thông qua các sự kiện Scrum như

• Sprint Retrospective thúc đẩy nhóm Scrum xem xét lại quá trình làm việc và tìm cách cải thiện trong Sprint tiếp theo.
• Dựa vào phản hồi từ Sprint Review, nhóm Scrum có thể điều chỉnh Product Backlog cho các Sprint sau.

7. Năm giá trị cốt lỗi của Scrum

7.1. Dũng cảm (Courage)

Dũng cảm (Courage) là việc nhóm Scrum có đủ can đảm để đối diện và giải quyết các vấn đề, thách thức và đưa ra những quyết định khó khăn.

Dũng cảm giúp nhóm Scrum đạt được sự tiến bộ, đổi mới và khắc phục mọi rủi ro và vấn đề một cách nhanh chóng.

Dũng cảm được thể hiện qua việc đội Scrum đưa ra quyết định dựa trên lợi ích dài hạn, ngay cả khi quyết định đó là khó khăn hay không phổ biến.

7.2. Cởi mở (Openness)

Cởi mở (Openness) là việc mọi thành viên trong nhóm Scrum đều sẵn lòng chia sẻ ý kiến, cảm xúc và thông tin một cách trung thực và cởi mở.

Cởi mở tạo ra một môi trường làm việc tin tưởng, hỗ trợ lẫn nhau và đối diện trực tiếp với các vấn đề.

Cởi mở được thể hiện qua việc mọi người đều tham gia vào việc đánh giá và phản hồi trong các sự kiện Scrum như Sprint Review và Sprint Retrospective.

7.3. Cam kết (Commitment)

Cam kết (Commitment) là việc mọi thành viên trong nhóm Scrum đều tận tâm và cam kết thực hiện nhiệm vụ của mình, đồng thời hỗ trợ đồng đội để đạt được Sprint Goal.

Cam kết đảm bảo mọi thành viên đều chịu trách nhiệm, đồng lòng và hướng tới việc hoàn thành công việc một cách hiệu quả.

Cam kết được thể hiện qua việc mọi thành viên trong nhóm Scrum đều tham gia vào việc lên kế hoạch Sprint và đồng lòng thực hiện mục tiêu đã đề ra.

7.4. Tập trung (Focus)

Tập trung (Focus) nghĩa là mọi thành viên trong nhóm Scrum đều tập trung vào công việc và mục tiêu của Sprint, không bị xao nhãng hay phân tâm bởi những vấn đề không liên quan.

Tập trung giúp tối ưu hoá hiệu suất làm việc, giảm thiểu rủi ro và đảm bảo chất lượng công việc.

Trong Scrum, tập trung được thể hiện qua việc nhóm Scrum chỉ làm việc trên những nhiệm vụ đã chọn trong Sprint và không bị gián đoạn bởi những yêu cầu ngoài kế hoạch.

7.5. Tôn trọng (Respect)

Tôn trọng (Respect) là việc  mọi thành viên trong nhóm Scrum đều tôn trọng lẫn nhau, tôn trọng quy trình và tôn trọng các quyết định được đưa ra.

Tôn trọng hỗ trợ xây dựng một môi trường làm việc hòa nhã, động viên và gắn kết đội ngũ.

Tôn trọng được thể hiện qua việc các thành viên trong nhóm Scrum lắng nghe và tôn trọng ý kiến của nhau, đồng thời tôn trọng quy trình và giá trị của Scrum.

8. Những hiểu lầm phổ biến trong Scrum

8.1. Agile là Scrum; Scrum là Agile

Đây là hiểu nhầm rất phổ biến, đặc biệt với những người mới tìm hiểu về Agile bởi bạn có thể thấy trong rất nhiều bài báo (cả Agile Vietnam và Hanoi Scrum) viết là: Agile\Scrum. Bạn cần hiểu rằng Agile là phương pháp luận (methodology), và Scrum là một phương pháp cụ thể (method).

Nhưng tác giả những bài báo viết Agile\Scrum cũng không sai, thường là do ý đồ cụ thể để những độc giả mới làm quen với Agile thấy “quen thuộc” hơn; nhất là với hơn 50% thị phần sử dụng, Scrum thường là con đường bước vào thế giới Agile của những nhóm mới thực hành Agile.

8.2. Sự khác biệt giữa Product Owner và Project Manager

Trong nhiều công ty ở Việt Nam, người ta vẫn tuyên bố mình phát triển phần mềm theo phương pháp Scrum mà không thấy có vị trí Product Owner (PO), thay vào đó là vị trí Project Manager (PM). Từ đó, dẫn tới sự hiểu nhầm vai trò của hai vị trí này là như nhau.

Tuy PM và PO có nhiều vai trò chung như xác định tầm nhìn, mục tiêu, độ ưu tiên công việc, thúc đẩy nhóm hoàn thành mục tiêu đề ra và đều có sự tương tác với các bên liên quan nhưng hai vị trí này là hoàn toàn khác biệt.

Tiêu chí	Product Owner	Project Manager
Nguồn gốc	Scrum	Thường thấy ở Waterfall và các phương pháp dựa trên dự án khác
Mục tiêu	Tối đa hoá giá trị của sản phẩm	Hoàn thành dự án trong phạm vi, thời gian và ngân sách cho phép
Trách nhiệm chính	Quản lý Project Backlog	Quản lý dự án
Kết quả	Một sản phẩm hoặc phần tăng trưởng của sản phẩm mang lại giá trị cho các bên liên quan, đáp ứng tầm nhìn và mục tiêu của sản phẩm	Một dự án đã hoàn thành, đáp ứng được các mục tiêu trong giới hạn thời gian, phạm vi và ngân sách
Thẩm quyền	Có quyền quản lý Product Backlog và đưa ra quyết định về mức độ ưu tiên của công việc, nhưng họ không có quyền quyết định quy trình làm việc hoặc phương án giải quyểt công việc của nhóm	Có quyền quyết định liên quan tới nguồn lực, thời gian và điều chỉnh phạm vi của dự án. Nghĩa là họ có thể can thiệp vào quy trình làm việc hoặc phương án giải quyết công việc của nhóm
Sự tương tác	Làm việc trực tiếp với các bên liên quan như Nhóm phát triển và Scrum Master	Làm việc với các bên liên quan như Nhóm phát triển, nhà cung cấp và đôi khi là khách hàng. Có tương tác thường xuyên với team lead hoặc trưởng bộ phận.

Từ bảng so sánh, ta có thể nhận thấy vai trò của PM tập trung vào hoàn thành dự án dự án, còn PO tập trung vào tối đa hoá giá trị sản phẩm. Vì thế, trong một vài trường hợp, PM có xu hướng tập trung vào những mục tiêu ngắn hạn hơn dài hạn như hi sinh chất lượng của sản phẩm để đảm bảo dự án hoàn thành đúng tiến độ.

Một điểm khác biệt cơ bản giữa PM và PO là PM có quyền ra quyết định tập trung, thể hiện ở điều phối nguồn lực của dự án, quyết định quy trình làm việc hoặc phương án giải quyết công việc của nhóm. Trong khi PO chỉ có quyền quản lý Product Backlog; nhóm phát triển tự quản lý phần việc của họ. Điều này tạo thuận lợi để ra quyết định phi tập trung, giúp nhóm làm việc linh hoạt.

8.3. Sự khác biệt giữa Product Owner và Business Analyst

Sự khác biệt giữa Product Owner (PO) và Business Analyst (BA) được thể hiện trong bảng sau:

Tiêu chí	Product Owner	Business Analyst
Nguồn gốc	Scrum	Thường thấy ở Waterfall và các phương pháp dựa trên dự án khác
Mục tiêu	Tối đa hoá giá trị của sản phẩm	Hiểu nhu cầu kinh doanh và chuyển chúng thành các yêu cầu có thể thực hiện được
Trách nhiệm chính	Quản lý Project Backlog	- Thu thập các yêu cầu chi tiết từ các bên liên quan - Ghi lại các quy trình và yêu cầu - Xác thực và xác minh các yêu cầu
Kết quả	Một sản phẩm hoặc phần tăng trưởng của sản phẩm mang lại giá trị cho các bên liên quan, đáp ứng tầm nhìn và mục tiêu của sản phẩm	Tài liệu yêu cầu chi tiết cung cấp các chỉ thị rõ ràng và ngắn gọn để phát triển
Thẩm quyền	Có quyền quản lý Product Backlog và đưa ra quyết định về mức độ ưu tiên của công việc	Chỉ cung cấp thông tin chi tiết và đề xuất nhưng thường không có quyền đưa ra quyết định cuối cùng về mức độ ưu tiên của sản phẩm
Sự tương tác	Làm việc trực tiếp với các bên liên quan, trong đó có Nhóm phát triển và Scrum Master	Là cầu nối giữa nhóm Kinh doanh và Nhóm phát triển hay phòng IT

8.4. Scrumbut

Khái niệm ScrumBUT để chỉ việc thực hành Scrum không theo Scrum tiêu chuẩn. Thuật ngữ này thường có cấu trúc như: "Chúng tôi thực hành Scrum, nhưng ...". Ví dụ:

"We use Scrum BUT we don’t have Daily Scrum – chúng tôi thực hành Scrum nhưng không thực hiện Daily Scrum."

"We use Scrum BUT we do Sprint Retrospective for 5 hours – chúng tôi thực hành Scrum nhưng sử dụng 5 giờ cho sự kiện Sprint Retrospective."

Sự tồn tại của ScrumBUT nói lên rằng tổ chức đang phải đối mặt với thách thức trong việc áp dụng đầy đủ Scrum hoặc đang phải thoả hiệp với một số hoạt động do các ràng buộc khác nhau như văn hoá, lịch sử, ...

Trường hợp một vài công ty ở Việt Nam tuyên bố thực hành Scrum nhưng chỉ có Project Manager, nhưng không có Product Owner là một ví dụ điển hình của ScrumBUT.

9. Tóm tắt

Agile là một phương pháp quản lý dự án bao gồm việc phân chia dự án thành các giai đoạn và nhấn mạnh sự hợp tác và cải tiến lên tục.

Scrum là phương pháp nổi tiếng và phổ biến nhất (chiếm ~52% tỷ lệ thực hành) trong tập hợp các phương pháp phát triển phần mềm theo tư tưởng Agile.

Scrum Team có tối đa 10 người, bao gồm 3 vai trò chính: Product Owner, Scrum Master, Developement Team (nhóm phát triển).

6 sự kiện trong Scrum: Sprint, Sprint Planning, Daily Scrum (còn gọi là Daily Stand-Up), Sprint Review, Sprint Retrospective và Backlog Refinement (còn gọi là Grooming).

3 trụ cột của Scrum: minh bạch, thanh tra, thích nghi.

5 giá trị của Scrum: dũng cảm, cởi mở, cam kết, tập trung, tôn trọng.

Scrum Artifacts (tạo tác): Product Backlog, Sprint Backlog, Release Burn-down Chart, Sprint Burn-down Chart, Definition of Done.

Cần phân biệt rằng Agile khác Scrum thể hiện ở Agile là phương pháp luận (methodology), và Scrum là một phương pháp cụ thể (method).

Product Owner (PO) có vai trò khác biệt với Project Manager (PM) và Business Analyst (BA).

Khái niệm ScrumBUT để chỉ việc thực hành Scrum không theo Scrum tiêu chuẩn.

10. Tài liệu tham khảo

1. Agile Y - Hien Nguyen
2. Scrum Guide 2020
3. Product Owner, Product Manager, or Project Owner?

Bài viết có liên quan

• Jira là gì? Giải mã phần mềm đa năng Jira Software