Những điều bạn chưa biết về Scrum

Với những ai nghiêm túc với Scrum và muốn ứng dụng Scrum để hoàn thành dự án của mình, không thể không biết đến Scrum Guide - một giáo trình chỉ vẻn vẹn đúng 19 trang (kèm luôn mục lục, cuối sách) ngôn từ dễ hiểu và không khó để tiếp cận.

Nhưng chỉ những ai đi sâu tìm hiểu và vận dụng Scrum mới biết những "ngôn từ trông dễ hiểu" đó là những cánh cửa dẫn chúng ta vào những cái hang thăm thẳm phản ánh đúng như mệnh đề được viết ở đầu sách:

"Scrum is lightweight, simple to learn, and difficult to master."

Scrum nhẹ nhàng, dễ dàng tiếp thu và khó để đạt cảnh giới.

Các bạn nếu chú ý sẽ thấy Scrum Guide chỉ đưa ra rất nhiều khái niệm, nhiều khái niệm được giải thích cặn kẽ, nhưng có những khái niệm lớn lại bị bỏ ngỏ chưa được giải thích, như mách chúng ta hãy tự khám phá, để thực sự hiểu được "môn nghệ thuật" này.

Và trong bài viết lần này, mình sẽ giới thiệu một vài điểm bí ẩn đấy nhé.

Estimation

Nhiều Team phát triển xem Scrum như một bộ máy của stories, points và velocities. Nhưng bạn có biết? Scrum Guide không hề hướng dẫn bạn nên dùng method này hay method nào đó để hoàn thành số estimate đấy.

Scrum Guide chỉ phát biết estimate là việc sẽ xảy ra mà thôi. Còn chúng được hoàn thành thế nào thì dựa hoàn toàn vào Team Phát Triển. Phần "Product Backlog" thì liên quan đến estimation như sau:

Các item trong Product Backlog gồm các thuộc tính: description, order, estimate, và value.

Những item được ưu tiên cao hơn thường rõ ràng hơn và chi tiết về mặt specs hơn là những item được ưu tiên thấp hơn. Một estimate có tính chính xác càng cao, khi mà item đó có độ rõ ràng và chi tiết cao hơn.

Nhóm Phát Triển chịu toàn bộ trách nhiệm cho estimates, Product Owner có thể tạo ra ảnh hưởng của mình, nhưng con số estimates cuối cùng sẽ được chốt bởi Nhóm này.

Hãy nhớ rằng: velocity thậm chí còn không được nhắc đến dù chỉ 1 lần trong Scrum Guide. và User Stories cũng thế. Guide cho thấy Scrum không hề có mối bận tâm nào với các khái niệm này.

Thế cái Story Point mà trước giờ gần như khi nào chúng ta cũng đề cập, thậm chí có thành viên còn "nháo nhào" lên mỗi khi có ai đó dùng hours thay cho Point, vai trò thực sự của nó là gì?

Nếu các bạn biết về Extreme Programming (hay XP), XP gọi sử dụng một pattern có tên Yesterday's Weather, với hàm ý, đại lượng đo lường trong quá khứ được sử dụng như một sổ chỉ dẫn cho việc lên kế hoạch cho các công việc trong tương lai. Cái Story point mà chúng ta đang dùng đây chính là một công cụ thành công trong pattern này. Nhưng nó không phải là cách duy nhất. Ta có thể dùng đại lượng thời gian (hours) nếu nó hợp với team mình, không vấn đề gì! Quan trọng là làm sao chúng ta có estimated time và actual time để đối chiếu với nhau - một phương pháp rất mạnh để kiểm tra được quá trình.

People Leadership và Management

Scrum Guide mô tả một hình mẫu, cấu trúc của một team hoàn toàn không ăn khớp gì với mô hình "báo cáo" hay "sơ đồ cây" mà nhiều tổ chức đang nghĩ tới. "Nhóm Phát Triển" thậm chí không được yêu cầu phải báo cáo với Scrum Master hoặc Product Owner.

Và “Scrum cũng không phải là động lực". Động lực nên phải là thứ xuất phát từ nội tại của một người. (cuốn "Động Lực Chèo Lái Hành Vi" - Daniel H. Pink đã trình bày rất khoa học, sắc bén về chủ đề này, các bạn có thời gian hãy tìm đọc nhé!)

Những con "lừa" thì cần được động viên - bằng củ cà rốt... Con người chuyên nghiệp thì cần được ủy quyền.

Stakeholder Management

Đây là một chủ đề lớn trong Quản lý Dự án truyền thống, được chia làm 2 mục: Managing Expectations và Defending Scope.

Theo lỗi tư duy "truyền thống" stakeholder là nhân vật "có tiền" hay vị trí của ông ấy đơn giản là cao hơn mình nên ông ấy có thể "cà khịa" dự án nếu ông ấy không thích cái ông ấy đang thấy, ép buộc chúng ta làm việc trên ý tưởng của ông ấy, và vStakeholder Management ở đây cũng có nghĩa là "triệt để ngăn chặn ông ấy chõ mũi vào việc của chúng ta" - Một việc sống còn để dự án ko bị "bể kèo"

Scrum Guide thì không nói nhiều đến việc "đương đầu" với các vị stakeholder này như thế nào. Nhưng cũng có vài ý súc tích:

Scrum Team và Stakeholder đồng ý trong việc cơi mở về tất cả công việc và những thử thách trong quá trình tiến hành công việc.

Trong Sprint Review, 2 bên trao đổi vs nhau về những item đã hoàn thành trong Sprint vừa qua

Tại bất kì thời điểm nào, lượng item còn lại để đạt được goal có thể được tổng hợp lại, để phía Stakeholder cũng nắm được tình hình.

Sự khác biệt trong lối suy nghĩ về Stakeholder trong Agile được gợi ý trong Sprint Reivew - Nơi mà sự hợp tác, thảo luận, tham gia từ 2 phía được xem là quan trọng nhất.

Trong Agile, chúng ta không bị ra lệnh từ Stakeholder, chúng ta cùng với họ - cùng làm chủ những giá trị mà chúng ta sẽ tạo ra. Chúng ta nâng tầm cho những sáng kiến, góc nhìn, bản sắc của họ vào trong sản phẩm, vào thị trường bằng lợi thế cạnh tranh mà 2 bên cùng nhau tạo ra so với đối thủ khác. Việc của chúng ta là khoác vai với họ mang lại giá trị cho người dùng.

Tư liệu tham khảo: What the Scrum Guide Doesn’t Say - medium.com