Xin chào các bạn, ở bài viết trước mình đã giới thiệu về Agile: https://viblo.asia/p/tong-quan-ve-agile-phan-1-aWj53pXpK6m. Nhiều người nhầm lẫn rằng Agile và Scrum là một, sai rồi nhé! Vậy thực tế Scrum là gì thì mình xin trình bày ngay sau đây:

6. Scrum

Nói PHP là một ngôn ngữ thì Laravel là một framework. Tương tự như vậy, nếu nói Agile là một ngôn ngữ thì Scrum là một framework.

Thực tế Scrum là một trong những Framework phổ biến nhất dùng để thực thi Agile. Và cũng có rất nhiều Framework khác cũng có thể dùng để thực thi Agile như Kanban chẳng hạn. Scrum là một khung làm việc trong đó con người có thể xác định được các vấn đề thích nghi phức hợp, trong khi vẫn giữ được năng suất và sáng tạo để chuyển giao các sản phẩm có giá trị cao nhất.

Scrum có ba tính chất:

• Nhẹ nhàng
• Dễ hiểu
• Rất khó để tinh thông.

Scrum là khung làm việc đã được sử dụng để quản lý quá trình phát triển các sản phẩm phức tạp từ đầu những năm 1990. Scrum không phải là một quy trình hay một kĩ thuật cụ thể để xây dựng sản phẩm hơn thế, nó là một khung làm việc cho phép bạn sử dụng nhiều quy trình và kĩ thuật khác nhau. Scrum làm sáng rõ mức độ hiệu quả tương đối của công tác quản lý và phát triển sản phẩm, từ đó cho phép bạn cải tiến nó.

Khung làm việc của Scrum có gì?

Để có thể dùng Scrum, chúng ta cần hiểu rõ và vận dụng đúng các thành tố tạo nên Scrum bao gồm các giá trị cốt lõi, các vai trò, các sự kiện và các công cụ đặc thù của Scrum.

6.1 Ba giá trị cốt lõi

Scrum được xây dựng dựa trên lý thuyết quản lý tiến trình thực nghiệm (empirical process control), hay “thực nghiệm luận” (empiricism). Lý thuyết này chỉ ra rằng tri thức đến từ kinh nghiệm và việc ra quyết định được dựa trên những gì đã biết. Scrum sử dụng các tiếp cận lặp (iterative), tăng trưởng (incremental) để tối ưu hóa tính khả đoán (predictability) và kiểm soát rủi ro.

Ba yếu tố nòng cốt tạo thành một mô hình quản lý tiến trình thực nghiệm gồm: sự minh bạch (transparency), thanh tra (inspection) và thích nghi (adaptation).

Minh bạch(transparency):

Muốn thành công với Scrum, thông tin liên quan tới quá trình phát triển phải minh bạch và thông suốt. Các thông tin đó có thể là: tầm nhìn(vision) về sản phẩm, yêu cầu khách hàng, tiến độ công việc, các khúc mắc và rào cản... Từ đó mọi người ở các vai trò khác nhau có đủ thông tin cần thiết để tiến hành các quyết định có giá trị để nâng cao hiệu quả công việc. Các công cụ và cuộc họp trong Scrum luôn đảm bảo thông tin được minh bạch cho các bên.

Các khía cạnh quan trọng của tiến trình phải được hiển thị rõ ràng cho những người có trách nhiệm với thành quả của tiến trình đó. Sự minh bạch yêu cầu các yếu tố này cần được định nghĩa theo một tiêu chuẩn để những người quan sát có thể hiểu những gì họ thấy theo cùng một cách.

Ví dụ:

1. Một ngôn ngữ chung về quy trình cần phải được chia sẻ cho tất cả các bên tham gia.
2. Một định nghĩa chung về “Hoàn thành” phải được chia sẻ bởi những người đảm đương công việc và những người tiếp nhận sản phẩm của công việc đó.

Thanh tra(inspection):

Người sử dụng Scrum phải thường xuyên thanh tra các tạo tác và tiến độ đến đích để phát hiện các bất thường không theo ý muốn. Tần suất thanh tra không nên quá dày để khỏi ảnh hưởng đến công việc. Công tác thanh tra có ích nhất khi được thực hiện bởi người có kĩ năng tại các điểm quan trọng của công việc.

Công tác thanh tra liên tục các hoạt động trong Scrum đảm bảo cho việc phát lộ các vấn đề cũng như giải pháp để thông tin đa dạng và hữu ích đến được với các bên tham gia dự án. Truy xét kỹ càng và liên tục là cơ chế khởi đầu cho việc thích nghi và các cải tiến liên tục trong Scrum.

Thích nghi(adaptation):

Nếu một người thanh tra xác định được rằng có vấn đề nào đó vượt quá giới hạn cho phép và hậu quả của vấn đề đó đối với sản phẩm là không thể chấp nhận được, thì quy trình hoặc các vật liệu được xử lý (processed material) phải được điều chỉnh. Sự điều chỉnh phải được tiến hành càng sớm càng tốt để giảm thiểu các sai sót khác có thể xảy ra.

Scrum rất linh hoạt như các phương pháp Agile khác. Nhờ đó nó mang lại tính thích nghi rất cao. Dựa trên các thông tin minh bạch hóa từ các quá trình thanh tra và làm việc, Scrum có thể phản hồi lại các thay đổi một cách tích cực, nhờ đó mang lại thành công cho dự án.

6.2 Ba vai trò

Trong Scrum, đội ngũ tham gia phát triển phần mềm được chia ra làm ba vai trò với trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù như sau:

Product Owner (chủ sản phẩm):

Từ video trên, có thể hiểu PO: là người chịu trách nhiệm về sự thành công của dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm. Cách thức để đạt được điều đó có thể rất khác nhau giữa các tổ chức, các Nhóm Scrum và các cá nhân.

Product Owner là một người chủ yếu chịu trách nhiệm về việc quản lý Product Backlog. Đây là công cụ quản lý chứa:

• Mô tả các hạng mục Product backlog

• Trình tự của các hạng mục trong Product Backlog để đạt được mục đích và hoàn thành các nhiệm vụ

• Sự đảm bảo giá trị của các công việc của Nhóm Phát triển

• Sự đảm bảo cho Product Backlog là luôn luôn hiện hữu, thông suốt và rõ ràng tới tất cả mọi người và chỉ ra những gì mà Nhóm Scrum sẽ làm việc

• Sự đảm bảo cho Nhóm Phát triển hiểu rõ các hạng mục trong Product Backlog với các mức độ cần thiết

Product Owner có thể tự mình thực hiện công việc trên hoặc để Nhóm Phát triển làm. Tuy nhiên, Product Owner vẫn phải chịu trách nhiệm chính.

Product Owner là một người, không phải là một ủy ban. Product Owner có thể cần tới một ủy ban tham gia vào Product Backlog, nhưng những người trong ủy ban muốn thay đổi trình tự các hạng mục trong Product Backlog phải thuyết phục được Product Owner.

Để Product Owner thành công, cả tổ chức phải tôn trọng các quyết định của người này. Các quyết định đó được hiển thị trong nội dung và thứ tự trong Product Backlog. Không ai ngoài Product Owner được phép yêu cầu Nhóm Phát triển làm gì khác và Nhóm Phát triển cũng không được phép làm gì theo lời bất cứ người nào khác.

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

Nhóm Phát triển (Development Team) gồm các chuyên gia làm việc để cho ra các phần tăng trưởng có thể phát hành được (potentially releasable) cuối mỗi Sprint. Chỉ các thành viên của Nhóm Phát triển mới tạo ra các phần tăng trưởng này (Increment).

Nhóm Phát triển được cấu trúc và trao quyền để tổ chức và quản lý công việc của họ. Sự hợp lực sẽ tối ưu hóa nỗ lực và hiệu quả tổng thể của Nhóm Phát triển. Nhóm Phát triển có các đặc trưng sau:

• Đó là nhóm tự tổ chức. Không ai (kể cả Scrum Master) có quyền yêu cầu Nhóm Phát triển làm thế nào để chuyển Product Backlog thành các phần tăng trưởng có thể chuyển giao được
• Đó là nhóm liên chức năng, với tất cả các kĩ năng cần thiết để tạo ra phần tăng trưởng của sản phẩm
• Scrum không ghi nhận một chức danh nào trong Nhóm Phát triển ngoài Nhà phát triển (Developer), theo tính chất công việc của người này, không có ngoại lệ cho quy tắc này
• Các thành viên Nhóm phát triển có thể có các kĩ năng chuyên biệt và các chuyên môn đặc thù, nhưng họ phải chịu trách nhiệm dưới một thể thống nhất là Nhóm Phát triển
• Nhóm Phát triển không chứa các nhóm con nào khác với các chức năng đặc thù như ‘nhóm kiểm thử’ hay ‘phân tích nghiệp vụ’.

Độ lớn tối ưu của Nhóm Phát triển là đủ nhỏ để giữ được sự linh hoạt và đủ lớn để hoàn thành công việc. Ít hơn ba người có thể làm giảm sự tương tác và dẫn đến năng suất thấp. Các Nhóm Phát triển nhỏ hơn có thể phải đối mặt với các ràng buộc kĩ năng trong suốt Sprint, dẫn đến Nhóm Phát triển khó có thể chuyển giao gói tăng trưởng phát hành được. Một nhóm nhiều hơn chín người cần nhiều sự điều phối hơn. Các Nhóm Phát triển lớn phát sinh quá nhiều phức tạp để thực hiện việc kiểm soát tiến trình thực nghiệm. Các vai trò Product Owner và Scrum Master không được tính vào kích thước của Nhóm Phát triển, trừ khi họ cũng kiêm luôn vai trò là thành viên của Nhóm Phát triển.

Scrum Master:

• Scrum Master chịu trách nhiệm đảm bảo mọi người hiểu và dùng được Scrum. Scrum Master thực hiện việc này bằng cách đảm bảo Nhóm Scrum tuân thủ lý thuyết, các kĩ thuật thực hành và các quy tắc của Scrum.
• Scrum Master là một lãnh đạo, nhưng cũng là người phục vụ Nhóm Scrum. Scrum Master giúp đỡ những người ngoài Nhóm Scrum hiểu cách phải tương tác với nhóm sao cho hiệu quả nhất.
• Scrum Master giúp đỡ tất cả mọi người cải tiến các mối tương tác để tối đa hóa giá trị mà Nhóm Scrum tạo ra.
• Scrum Master phục vụ gì cho Product Owner?

Scrum Master phục vụ Product Ower theo nhiều cách, bao gồm:

1. Tìm kiếm các kĩ thuật để quản lý hiệu quả Product Backlog
2. Giao tiếp tích cực với Nhóm Phát triển về tầm nhìn, mục đích và các hạng mục của Product Backlog
3. Huấn luyện cho Nhóm Phát triển biết cách tạo ra các hạng mục Product Backlog thật rõ ràng và đơn giản
4. Hiểu rõ việc lập kế hoạch dài hạn sản phẩm trong một môi trường thực nghiệm
5. Hiểu rõ và thực hành sự linh hoạt (agility)
6. Thúc đẩy các sự kiện Scrum theo yêu cầu hoặc khi cần thiết.

Scrum Master phục vụ gì cho Nhóm Phát triển? Scrum Master phục vụ Nhóm Phát triển theo nhiều cách, bao gồm:

1. Huấn luyện Nhóm Phát triển cách tự tổ chức và làm việc liên chức năng
2. Giúp đỡ Nhóm Phát triển để tạo ra các sản phẩm có giá trị cao
3. Loại bỏ các trở lực trong quá trình tác nghiệp của Nhóm Phát triển
4. Thúc đẩy các sự kiện Scrum theo yêu cầu hoặc khi cần thiết
5. Huấn luyện Nhóm Phát triển trong trường hợp tổ chức chưa có hiểu biết và ứng dụng đầy đủ về Scrum.

Scrum Master phục vụ gì cho Tổ chức? Scrum Master phục vụ Tổ chức theo nhiều cách, bao gồm:

1. Lãnh đạo và huấn luyện tổ chức trong việc áp dụng Scrum
2. Lập kế hoạch triển khai Scrum trong phạm vi tổ chức
3. Giúp đỡ nhân viên và các bên hữu quan hiểu và sử dụng được Scrum cũng như quá trình phát triển sản phẩm thực nghiệm (emprical product development)
4. Tạo ra sự thay đổi làm tăng năng suất của Nhóm Scrum
5. Làm việc với các Scrum Master khác để gia tăng hiệu quả của việc áp dụng Scrum trong tổ chức của mình.

6.3 Bốn cuộc họp

Khi áp dụng Scrum, có 4 cuộc họp (Meetings or Ceremonies) quan trọng tạo nên cấu trúc trong mỗi Sprint như sau:

• Sprint planning: Cuộc họp lên kế hoạch của đội dự án, nhằm xác định những gì cần hoàn thành trong Spring sắp tới.
• Daily stand-up: Cũng được biết đến như “Daily Scrum”, một cuộc họp nhỏ 15 phút mỗi ngày để trao đổi công việc giữa đội phát triển.
• Sprint demo: Một cuộc họp chia sẻ, nơi mà các thành viên chỉ ra những gì họ đã làm được trong Sprint đó.
• Sprint retrospective: Sự đánh giá, nhìn lại những điều đã làm được và chưa làm được của Sprint hiện tại, và đưa ra giải pháp hành động cho Sprint tiếp theo được tốt và hoàn thiện hơn.

6.4 Các công cụ Scrum

Scrum sử dụng các công cụ rất đơn giản nhưng hiệu quả để trợ giúp công việc.

Product Backlog: Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án, có thể hiểu như là danh sách yêu cầu(requirement) của dự án. PO chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product backlog Item) trong Product backlog dựa trên các giá trị do PO định nghĩa (thường là các giá trị thương mại - business value).

Sprin Backlog: Đây là bản kế hoạch cho một sprint; là kết quả cho buổi họp lập kế hoạch (Sprint Planning). Với sự kết hợp của PO, nhóm sẽ phân tích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng danh sách các công việc (TODO list).

Burndown Chart: Đây là biểu đồ thể hiện xu hướng của dự án dựa trên lượng thời gian cần thiết còn lại để hoàn tất công việc. Burndown Chart có thể được dùng để theo dõi tiến độ của Sprint (được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart). Biểu đồ Burndown không phải là một thành tố tiêu chuẩn của Scrum theo định nghĩa mới, nhưng vẫn được sử dụng rộng rãi do tính hữu ích của nó.

Mình xin kết thúc phần Agile tại đây, hy vọng bài viết này mang lại nhiều lợi ích cho mọi người!

Tài liệu tham khảo:

https://www.scrum.org/resources/what-is-scrum