Tìm hiểu cách hoạt động của Large-scaled Scrum (LeSS)

Xin chào các bạn, tôi là Nguyễn Đặng Hiếu, thành viên của nhóm PSIRT VN tại Cy-PSIRT [1], nơi chúng tôi chuyên đối ứng với các vấn đề bảo mật sản phẩm. Trong quá trình nghiên cứu và áp dụng các phương pháp làm việc nhịp nhàng để nâng cao hiệu suất làm việc của nhóm, tôi đã tìm hiểu sâu về mô hình Scrum quy mô lớn, hay còn gọi là Large-scaled Scrum (LeSS). Hôm nay, tôi xin phép được chia sẻ một bài viết ngắn về LeSS, hi vọng sẽ mang lại cái nhìn tổng quan cho các bạn quan tâm đến việc áp dụng phương pháp linh hoạt trong quản lý dự án và phát triển sản phẩm.

1. LeSS là gì?

LeSS, được viết tắt từ Large Scale Scrum, là một framework tiên phong trong lĩnh vực phát triển phần mềm linh hoạt. Đây là một mô hình Scrum đa nhóm, phù hợp với các nhóm phát triển agile từ vài chục đến hàng trăm, thậm chí hàng ngàn thành viên, cùng hợp tác trên một sản phẩm hoặc dự án chung. LeSS cho phép bạn tạo ra các sản phẩm có quy mô từ nhỏ đến lớn.

LeSS là một framework đơn giản và tối giản, nơi có ít quy tắc, quy trình, và vai trò. Trong một môi trường LeSS, bạn chỉ thấy những vai trò cơ bản như Product Owner, Scrum Master và các thành viên trong team. Không có nhiều công cụ phức tạp hay quá nhiều quy trình rườm rà.

Trọng tâm của LeSS là khách hàng. Các thành viên trong nhóm phát triển có cơ hội trao đổi trực tiếp với khách hàng, trong khi đó Product Owner tập trung vào việc thiết lập lộ trình phát triển, ưu tiên và tầm nhìn dài hạn cho sản phẩm. Tuỳ thuộc vào bối cảnh cụ thể của từng tổ chức mà "khách hàng" có thể được hiểu và định nghĩa theo nhiều cách khác nhau.

2. Cấu trúc của LeSS

Nó bắt đầu với các nhóm phát triển agile liên chức năng (cross-function agile teams). Các nhóm này gồm có 8-12 thành viên có kinh nghiệm và dày dặn lập trình (coding), kiểm thử (testing), thiết kế (design), kiến trúc (architecture) và có kiến thức về lĩnh vực kinh doanh. Có thể có nhiều nhóm phát triển tùy thuộc vào cấu trúc công ty của bạn.

Bao gồm 02 loại LeSS:

• Basic (cơ bản): có từ 2 đến 8 thành viên trong nhóm.
• LeSS Huge (lớn): có hơn 8 thành viên trong nhóm.

Các nhóm này cùng phối hợp với các nhóm khác để tạo ra phần mềm chất lượng cao. Một Scrum Master có thể hỗ trợ cho 1-3 nhóm phát triển. Một Scrum Master sẽ hướng dẫn và dạy các nhóm về cách làm việc trong LeSS. Sau đó, Product Owner sẽ là người quản lý Product Backlog bao gồm danh sách các tính năng. Ngoài ra còn có một Bộ phận hoàn tác, đó là một danh sách các chức năng chưa được thực hiện trong một lần chạy trong một sprint. Những chức năng chưa xong có thể được chuyến sang sprint tiếp theo. Và cuối cùng, sẽ có một nhóm của Product Owner chịu trách nhiệm báo cáo cho người phụ trách nhóm Product Owner.

Trong LeSS Huge, sẽ có nhiều LeSS Basic được triển khai cùng một lúc. Điều đó có nghĩa là sẽ áp dụng cho các tổ chức lớn, nơi có hơn 08 nhóm. Sẽ có các Area Product Owner chịu trách nhiệm cho quản lý Product Backlog riêng từng nhóm. Một Area Product Owner sẽ quản lý tối đa ba nhóm. Một Product Owner chính sẽ quản lý các Area Product Owner và nắm toàn bộ sản phẩm.

Dưới đây là bảng so sánh giữa Scrum truyền thống và Large-Scale Scrum (LeSS) để giúp bạn hiểu rõ hơn về những điểm tương đồng và khác biệt chính giữa hai framework này:

Bảng so sánh này giúp bạn thấy rõ ràng sự khác biệt giữa Scrum truyền thống và LeSS, từ quy mô áp dụng đến cách thức tổ chức và lập kế hoạch. Mỗi mô hình đều có những ưu điểm riêng phù hợp với nhu cầu và điều kiện khác nhau của các tổ chức.

3. Xây dựng kế hoạch trong LeSS

Các sprint được lên kế hoạch, trong đó các nhóm sẽ được giao để thực hiện nhiệm vụ ở mỗi sprint. Các sprint này có thể kéo dài từ 1 đến 4 tuần. Quá trình thực hiện sẽ được lặp đi lặp lại và tăng dần.

Có 02 giai đoạn để lập kế hoạch trong LeSS:

• Giai đoạn đầu tiên của kế hoạch liên quan đến việc lựa chọn các task từ Product Backlog. Hai thành viên của mỗi nhóm, sẽ họp với Product Owner để đưa ra lựa chọn các task có độ ưu tiên cao trong Product Backlog.
• Ở giai đoạn thứ hai của kế hoạch, nhóm thảo luận về các task được chọn. Việc lập kế hoạch sẽ được thực hiện để đạt được các mục tiêu của sprint khi một nhóm đã chọn các task của mình từ Product Backlog.

Trong quá trình xây dựng kế hoạch cho các sprint tới, chúng ta có thể sử dụng các công cụ như bảng trắng và biểu đồ để trực quan hóa mục tiêu, tiến trình và các mốc quan trọng. Việc sử dụng những công cụ này không chỉ giúp đơn giản hóa thông tin mà còn tăng cường sự tương tác và hiểu biết chung giữa các thành viên trong team.

Bên cạnh đó, việc tổ chức các buổi họp để sàng lọc "Product Backlog" là một phần không thể thiếu trong quá trình lập kế hoạch. Trong buổi họp này, khách hàng và các team sẽ cùng nhau thảo luận về các yêu cầu hiện có, cân nhắc cách cải tiến hoặc thêm mới yêu cầu nếu cần. Buổi họp này cũng là dịp để xác định và phân bổ công việc cần thực hiện trong các sprint sắp tới, đảm bảo rằng mọi thứ đều được ưu tiên và lên kế hoạch một cách kỹ lưỡng.

Để duy trì và cải thiện chất lượng công việc, các team cần thường xuyên tổ chức các buổi "Sprint Review", nơi mà họ nhìn lại và đánh giá những gì đã được hoàn thành trong sprint vừa qua. Điều này không chỉ giúp nhận diện các thành tựu mà còn chỉ ra các vấn đề cần được giải quyết.

Ngoài ra, việc tổ chức buổi "Sprint Retrospective" cũng vô cùng quan trọng, trong đó tất cả các team, Product Owner, Scrum Master, và các nhà quản lý sẽ cùng nhau xem xét và thảo luận về các trở ngại có thể ảnh hưởng đến việc bàn giao sản phẩm. Buổi họp này là cơ hội để mọi người cùng nhìn nhận lại quá trình làm việc, từ đó tìm ra các giải pháp nhằm vượt qua các rào cản, nâng cao hiệu quả công việc, và thúc đẩy sự hợp tác giữa các bên liên quan.

4. Tóm lại các vấn đề của LeSS

LeSS (Large Scale Scrum) là một framework được thiết kế để quản lý và phát triển phần mềm ở quy mô lớn, nhưng cũng có những thách thức:

1. Product Overview: LeSS cung cấp một cái nhìn tổng quát về sản phẩm, nhằm đảm bảo tính minh bạch trong tất cả các công việc được thực hiện. Sự minh bạch này giúp tăng cường hiểu biết và phối hợp giữa các team.
2. Direct Customer Interaction: Các team sẽ có cơ hội làm việc trực tiếp với khách hàng, điều này cho phép họ hiểu rõ hơn về nhu cầu thực tế và kỳ vọng của khách hàng, từ đó phát triển sản phẩm phù hợp hơn.
3. Lean Thinking: Với nguyên lý "Lean Thinking", LeSS nhấn mạnh việc giảm thiểu lãng phí, đảm bảo các team tập trung vào những công việc thực sự cần thiết. Điều này cũng tạo điều kiện cho các team học hỏi và phát triển một cách liên tục.
4. Multi-Component Approach: Các team sẽ được hướng dẫn về các công việc cần thực hiện, với khách hàng là trung tâm, và tiếp cận dựa trên đa thành phần.
5. Dependency Management: Sự phụ thuộc giữa các team được xử lý ở cấp độ tích hợp, thông qua việc chia sẻ code giữa các team. Việc tích hợp thường xuyên các đoạn code giúp giải quyết các vấn đề phức tạp.
6. Management and Training: Vai trò của việc quản lý được tập trung vào việc xác định tầm nhìn và đào tạo các thành viên trong team. Product Owner sẽ xác định và ưu tiên các yêu cầu cho các team.
7. Collaboration and Code Sharing: Các team phối hợp chặt chẽ với nhau và thường xuyên chia sẻ các đoạn code cơ bản để thúc đẩy sự đồng nhất và hiệu quả trong phát triển.
8. Design and Architecture: Có các team thiết kế và kiến trúc để phân bổ nguồn lực và sức mạnh tổng hợp cho tất cả các team, nhằm tập trung vào việc phát triển sản phẩm cuối cùng.
9. Backlog Sharing: Các team có thể chia sẻ các backlog đã được sàng lọc ở mỗi sprint với nhau, tạo điều kiện cho việc đồng bộ hóa và thích ứng công việc.
10. DevOps and Continuous Integration: Là chìa khóa để bàn giao sản phẩm cho khách hàng một cách thuận lợi. Mỗi sprint sẽ kết thúc bằng việc một team bàn giao chức năng sản phẩm đã hoàn thiện.
11. Regular Reviews and Adjustments: Việc thường xuyên tổ chức các cuộc họp để rà soát, kiểm tra và điều chỉnh giúp đảm bảo việc cải tiến liên tục, từ đó nâng cao chất lượng sản phẩm và hiệu quả làm việc của các team.

Những điểm này tóm tắt các vấn đề chính mà LeSS hướng đến giải quyết, đồng thời cũng phản ánh các thách thức mà các tổ chức có thể gặp phải khi triển khai framework này.

5. Các định hướng khi áp dụng LeSS

LeSS là một framework nâng cao hiệu quả làm việc của team bằng cách nhấn mạnh vào việc học thông qua thực hành (Learning by doing). Framework này khuyến khích các team phát triển tự do sáng tạo và tự chủ trong công việc của họ, dựa trên năng lực và kinh nghiệm của từng thành viên. Khi áp dụng LeSS cho nhiều team cùng làm việc, việc tạo ra sự phối hợp và minh bạch giữa các team và khách hàng là điều cần thiết, có thể thông qua việc thiết lập một số quy tắc cụ thể.

LeSS được mô tả là một framework không hoàn chỉnh, nó mở ra không gian rộng lớn cho việc học hỏi và thích ứng theo từng tình huống cụ thể. Như Craig Larman và Bas Vodde đã chỉ ra trong cuốn sách "Large-Scale Scrum: More with LeSS"[2], LeSS cung cấp một khung sườn để mở rộng nhưng không chi tiết tới mức cứng nhắc, cho phép các tổ chức thích ứng với điều kiện và thực tế riêng của họ.

Khi áp dụng LeSS, tổ chức của bạn có thể cần phải từ bỏ cấu trúc tổ chức truyền thống và thay đổi mạnh mẽ các kỹ thuật phát triển hiện tại để có thể hoàn toàn áp dụng LeSS. Điều này bao gồm sự thay đổi từ cách tiếp cận quản lý chương trình truyền thống sang một cấu trúc tổ chức linh hoạt hơn, thích ứng với sự nhanh nhẹn và liên tục cải tiến. LeSS khuyến nghị rằng các tổ chức nên bắt đầu áp dụng các nguyên tắc của LeSS từ một team scrum duy nhất và từ từ mở rộng, điều chỉnh dần dần qua từng bước để phù hợp với môi trường và yêu cầu cụ thể của tổ chức.

Tài liệu/Link tham khảo:

[1] https://tech.cybozu.vn/team-cy-psirt-doi-ung-bao-mat-tai-cybozu-vietnam-31060/

[2] https://www.amazon.co.jp/-/en/Craig-Larman/dp/0321985710

[3] https://less.works/less/framework