Chúc mừng năm mới.

Mình đợt này văn vẻ đang không còn được chau chuốt nữa nên xin phép ngắn gọn thế và vào bài luôn.

Tại sao?

Scrum là framework phát triển phần mềm hiện đại, mới và triết lý Agile cũng rất mới và năng động! Đây là cái mình công nhận. Nhưng trong tất cả các lý thuyết Scrum thì đều chung 1 điểm: team từ 3 đến 9 người

Ủa, vậy giờ trong cty có 3 đến 9 ông/bà ngồi code thì chúng ta cần nhiều lập trình viên để làm gì? Và tại sao thực tế chúng ta lại đang khát lập trình viên(bỏ qua layoff đi vì thực sự tuy là layoff nhưng không phải họ không khát nhân lực) ?

Câu trả lời là ở hình ảnh sau:

Với 1-2 team làm với 1 sản phẩm thì chúng ta chỉ cần dùng Scrum.

Với 1 team phải lo 2 sản phẩm trở lên thì…. Ai khóc nỗi đau này? (nhạc sàn xập xình nổi lên)

Với nhiều team làm nhiều sản phẩm thì chúng ta sẽ phải tìm hiểu quản lý danh mục dự án.

Còn với nhiều team làm cùng 1 sản phẩm thì chúng ta phải áp dụng Scaled Scrum.

Vậy Scaled Scrum là gì?

Scaled Scrum

Scaled Scrum là việc điều phối, cân đối các team Scrum cùng làm 1 product sao cho hiệu quả.

Thật vậy, đây là hình ảnh 1 team Scrum khi làm 1 sản phẩm

Đám mây đen thể hiện các khó khăn, vướng mắc của team. Ta có thể thấy hiện đám mây chỉ che 1 phần của dự án

Và sau 1 thời gian, sản phẩm phình to, các thành viên team Scrum đã chạy 100% công suất. Vì vậy cty tuyển thêm người để có thể có thêm nguồn lực phát triển. Khi đó, có 3 team Scrum và mọi chuyện trở thành như này:

Ơ, tăng người thì sao khó khăn lại nhiều hơn? Lý do là sẽ phải mất công chuyển giao, đào tạo cũng như liên lạc giữa các team. Nếu vẫn mỗi team Scrum làm 1 kiểu không có điều phối thì impendiment sẽ tăng lên.

Thấy khó khăn tăng lên, thay vì tìm ra nguyên nhân, cty đó quyết định tăng lên 9 Scrum Team cho thừa thãi nhân lực. Và thảm họa đã xảy ra:

Mây đã che đen kịt cả dự án vì theo đúng nghĩa đen, các team dành phần lớn thời gian để cãi nhau.

Do đó, Scrum gốc đã không còn phù hợp nữa. Chúng ta cần các mô hình/framework Scrum-based để phát triển.

Các mô hình/framework Scaled Scrum điển hình

Trên đây là 4 mô hình Scaled Scrum mà mình muốn giới thiệu cho các bạn: Scrum of Scrums, Nexus Framework, LeSS(Large Scaled Scrum) và SAFe(Scale Agile Framework)

Scrum of Scrums

Scrum of Scrums là mô hình scale nhân lực áp dụng Scrum đơn giản nhất. Cách triển khai như hình là ghép 5 team Scrum với nhau, mỗi Scrum Team được phụ trách bởi 1 Product Owner. Và các Product Owner sẽ gom với nhau thành 1 Hội đồng Product Owner và được quản lý bởi 1 Chief Product Owner. Chief Product Owner sẽ phụ trách như 1 cầu nối giữa các Stakeholders và các Product Owner còn lại.
Ngoài ra chúng ta còn có 1 role nữa là Scrum of Scrums Master để đảm bảo mô hình sẽ chạy được đúng.

Vè event thì mọi event như Scrum, trừ việc chúng ta sẽ có thêm Daily Scrum of Scrums sau khi các Daily Scrums đơn lẻ.

Mô hình được cho là lý tưởng cho 4-6 team Scrum.

Về cá nhân mình thì mình thấy đây là mô hình đáng tham khảo cho các product micro-service, nhưng giữa các service với nhau phải break thật nhỏ và càng ít sự phụ thuộc lẫn nhau giữa các team càng tốt, và việc giao tiếp có vẻ hơi phân tầng, dẫn tới hơi mất linh hoạt.

1 điểm nữa mình cũng thấy không ổn là ở Scrum chung ở sau Scrum riêng. Như vậy các Scrum riêng có thể kết thúc thời gian khác nhau, dẫn tới Scrum chung chỉ có thể bắt đầu khi Scrum riêng muộn nhất kết thúc, và các khó khăn gặp phải của các team khác nhau có thể sẽ được nhắc lại nhiều lần ở trong cuộc họp Scrum chung. Như vậy, đây sẽ tốn 1 lượng thời gian đáng kể.

Nexus Framework

Mô hình Nexus như các bạn thấy ở trên, chúng ta sẽ có 1 mô hình gần giống Scrum. Điểm khác biệt có thể kể đến:

• Backlog Refinement: Hoạt động phân tích các Product Backlog Item, làm rõ các sự phụ thuộc lẫn nhau của chúng và cung cấp 1 phương hướng dự đoán team Scrum nào sẽ làm PBI nào
• Nexus Daily Scrum: Là hoạt động nhằm tìm ra những gì là sự phụ thuộc giữa các PBI với nhau, hoặc giữa các team giao tiếp với nhau có gặp vấn đề gì không. Kết quả của nó chính là input cho các Daily Scrum đơn lẻ của các team.
• Nexus Integration Team: Là team phụ trách việc đảm bảo mỗi Sprint sẽ có 1 done Integrated Increment được chuyển giao ở cuối Sprint. Tức đóng vai trò thanh tra chứ không phải người trực tiếp thực hiện việc tích hợp nhé các bạn. Team sẽ gồm có:
  • Product Owner: Tất nhiên rồi
  • Nexus Scrum Master: Được chọn bởi 1 Scrum Master của 1 trong các team thành viên(có thể bố trí mỗi team 1 Scrum Master hoặc tất cả các team 1 Scrum Master đều được). Có vai trò đảm bảo Nexus được chạy đúng trong quá trình phát triển phần mềm. Và đây cũng là Scrum Master có cấp bậc cao nhất của team
  • Các thành viên Developer: Có thể lấy luôn từ các team Scrum hoặc làm 1 đội riêng. Ưu tiên cao nhất cho việc đảm bảo phần việc tích hợp được hoàn thành. Tiêu chí tuyển chọn là có kinh nghiệm, kĩ năng trong việc tích hợp và hiểu know-how của Sản phẩm. Các developer này có thể thay đổi tuỳ từng Sprint.

Quy trình của 1 Sprint sẽ diễn ra như sau:

• Các item của Product backlog sẽ được làm gọn lại, phân tích ra để làm rõ các phụ thuộc giữa chúng
• Nexus Sprint Planning diễn ra với sự tham gia của tất cả các bên. Trong quá trình đó các Sprint Planning của các Sprint riêng lẻ cũng diễn ra.
• Kết quả sau đó là 1 Nexus Sprint Backlog gồm các Sprint Backlog của các team thành viên, cũng như các phụ thuộc của PBI của các team.
• Sau đó là 3 đến 9 team làm việc dưới sự điều phối của Nexus Integration Team.
• Trong quá trình diễn ra Sprint, Nexus Daily Scrum diễn ra trước và Daily Scrum lẻ diễn ra sau.
• Cuối Sprint, khi tất cả các PBI nằm trong Increment tích hợp của Sprint, PBI sẽ được tích hợp lại và kiểm tra để chắc chắn là done.
• Nexus Sprint Review sẽ diễn ra ngay sau đó. Đây là event sẽ thay thế toàn bộ các Sprint Review đơn của các team
• Sau khi review, Nexus Retrospective sẽ diễn ra. Trong quá trình đó Retrospective của các team đơn lẻ cũng diễn ra song song.

Có thể thấy, về sơ đồ cũng như cách triển khai, Nexus giống Scrum hơn Scrum of Scrums rất nhiều. Nexus cũng có điểm lợi khi tập trung knowhow của sản phẩm hơn và chú trọng tới việc khó khăn giao tiếp giữa các team cũng như các phụ thuộc lẫn nhau giữa các task hơn. Nhưng nhược điểm thì Nexus vẫn hơi lý tưởng quá và Product Owner chỉ có 1 người. Mặc dù có thể để assign 1 số người để thực hiện 1 số việc của PO giúp, nhưng khi PO vì lý do gì đó không có mặt được thì đó lại chính là khó khăn cũng như sự phụ thuộc lẫn nhau lớn nhất.

LeSS(Large Scaled Scrum)

Chúng ta thấy rằng LeSS theo mô hình trên trông cũng giống giống Scrum. Nhưng có 1 số điểm khác biệt:

• Tuỳ vào dự án có 8 team hay nhiều hơn, sẽ có 1 Product Owner hoặc 1 hội đồng Product Owner.
• Sprint Planning chia làm 2. Planning 1 sẽ gồm PO và đại diện các team. Planning 2 tất cả cùng tham gia.
• Daily Scrum: trong trường hợp cần chia sẻ thông tin, người trong team này có thể ngồi trong Daily Scrum của team khác. Và có 1 cuộc họp khác nếu cần thiết được gọi là “open space town hall meeting”
• Product Backlog Refinement: Nghe rất Nexus nhưng lại không phải Nexus =))) Cuộc họp này ở LeSS là optional và chỉ nhằm mục đích kiểm tra output của các team.
• Sprint Review: Ở cuộc họp này, các team sẽ trình bày ra output của mình trong Sprint vừa rồi và nhận feedback từ PO cũng như stakeholders.
• Overall Retrospective: Diễn ra sau Sprint Retrospective đơn lẻ của từng team. Cũng bao gồm các Product Owner, các Scrum Master và đại diện từ từng team developer

SAFe(Scale Agile Framework)

Đây là framework áp dụng ở level công ty. Các bạn có thể thấy mô hình này được chia làm nhiều level khác nhau, sử dụng Lean, Kanban, XP,… rất nhiều các practice và framework của Agile. Level giống với Scrum nhất là Program và Team.

Các bạn có thể đọc thêm tóm tắt về SAFe ở link này:

https://www.agilest.org/scaled-agile/safe-framework/

Tổng kết

Các bạn có thể thấy chúng ta đã và đang có những giải pháp khác nhau để có thể áp dụng Agile vào 1 dự án nhiều người tham gia phát triển. Mỗi mô hình/framework có ưu – nhược điểm riêng. Các bạn hãy xem xét và áp dụng mô hình hợp lý.

Cảm ơn các bạn đã đọc bài. Chúc các bạn năm Quý Mão 2023 mạnh khoẻ và thành công.