Nexus Framework là gì? Nexus và Scrum or Scrum

Nexus Framework là một khung quản lý được xây dựng bởi Scrum.org (Ken Schwaber - người đồng sáng lập Scrum), nhằm mục đích mở rộng Scrum cho các nhóm lớn (từ 3 đến 9 Scrum Team) cùng làm việc trên một Product Backlog duy nhất để tạo ra một Integrated Increment (Phần tăng trưởng tích hợp). Nói cách đơn giản: Nếu Scrum là cách một đội bóng thi đấu, thì Nexus là cách điều phối một giải đấu nơi nhiều đội phải phối hợp để đạt được một mục tiêu chung mà không dẫm chân lên nhau.

1. Các Vai trò trong Nexus (Roles)

Nexus không thay đổi các vai trò trong Scrum mà chỉ thêm một bộ phận điều phối cấp cao: Nexus Integration Team (NIT): Đây là vai trò quan trọng nhất. NIT chịu trách nhiệm đảm bảo rằng các phần việc của tất cả các đội được tích hợp thành công.
Thành phần gồm: Product Owner (duy nhất), Scrum Master, và một số thành viên từ các Scrum Team (thường là những người có chuyên môn kỹ thuật cao).
Lưu ý: Họ không trực tiếp làm hộ việc của các team, họ tập trung vào việc giải quyết các phụ thuộc (dependencies) về mặt kỹ thuật và kiến trúc.
Product Owner: Chỉ có duy nhất 1 PO cho toàn bộ Nexus để đảm bảo sự nhất quán về tầm nhìn sản phẩm. Scrum Master: Có thể là SM của NIT và đồng thời hỗ trợ một hoặc nhiều Scrum Team bên dưới.

2. Các Sự kiện trong Nexus (Events)

Nexus bổ sung thêm các "vỏ bọc" bên ngoài các sự kiện Scrum tiêu chuẩn để đồng bộ hóa:
A Sprint in Nexus is the same as in Scrum. The Scrum Teams in a Nexus produce a single Integrated Increment.
Nexus Sprint Planning: Các đại diện từ các team họp để xác định mục tiêu chung (Nexus Sprint Goal) và xem xét các phụ thuộc giữa các nhóm trước khi mỗi team về họp Sprint Planning riêng.
Nexus Daily Scrum: Đại diện các team họp nhanh (trước Daily Scrum của từng team) để chia sẻ về các vấn đề tích hợp phát sinh và các phụ thuộc mới xuất hiện.
Nexus Sprint Review: Thay thế các buổi Review riêng lẻ. Tất cả các team cùng trình diễn bản Integrated Increment (sản phẩm đã tích hợp) cho các bên liên quan.
Nexus Sprint Retrospective: Gồm 3 phần: (1) Đại diện họp để nhận diện vấn đề chung -> (2) Từng team về họp riêng -> (3) Đại diện họp lại để thống nhất kế hoạch cải tiến cho toàn bộ Nexus

3. Nexus khác gì so với Scrum of Scrums (SoS)?

Nhiều người nhầm lẫn hai khái niệm này, nhưng thực tế chúng có sự khác biệt rất lớn về cách tiếp cận:

Đặc điểm	Scrum of Scrums (SoS)	Nexus Framework
Nguồn gốc	Xuất phát từ Agile đời đầu (Jeff Sutherland)	Framework chính thức từ Scrum.org (Ken Schwaber)
Tính chất	Là một kỹ thuật điều phối (Meeting kỹ thuật).	Là một Framework hoàn chỉnh với các quy tắc và vai trò cụ thể.
Trọng tâm	Tập trung vào việc giao tiếp giữa các Scrum Master/Đại diện.	Tập trung vào việc Tích hợp sản phẩm (Integration) và quản lý phụ thuộc.
Cấu trúc	Thường mang tính tự phát, không có đội ngũ chịu trách nhiệm tích hợp riêng.	Có Nexus Integration Team chịu trách nhiệm cao nhất về việc ra lò sản phẩm tích hợp.
Nội dung	rả lời 4 câu hỏi: Nhóm tôi đã làm gì? Sẽ làm gì? Có rào cản gì? Có làm ảnh hưởng nhóm khác không?	Giải quyết các Phụ thuộc (Dependencies) về kỹ thuật, nghiệp vụ và nhân sự để đảm bảo bản build chung không lỗi.
Backlog	Có thể có nhiều Product Backlog hoặc cách quản lý linh hoạt tùy tổ chức.	Bắt buộc 1 Product Backlog duy nhất cho toàn bộ các nhóm.
Mục tiêu cuối	Đồng bộ thông tin. Sự thông suốt về thông tin và các giải pháp cho rào cản liên nhóm.	Đảm bảo mỗi Sprint ra được 1 Integrated Increment hoàn chỉnh. Integrated Increment: Một bản sản phẩm hoàn chỉnh, đã test và chạy được từ tất cả các nhóm
Vai trò then chốt	Đại diện các nhóm (thường là Scrum Master hoặc Tech Lead).	Nexus Integration Team (NIT): Nhóm chịu trách nhiệm cao nhất về việc tích hợp thành công.

**Lời khuyên cho bạn (PM) **
Thay vì chỉ họp "Scrum of Scrums" để báo cáo trạng thái, bạn nên tập trung vào việc thành lập một nhóm Integration (gồm các Lead/Senior) để xử lý việc "ghép code" giữa các Sprint. Điều này sẽ giúp bạn tránh được lỗi "demo vẫn xuất hiện lỗi/SIT chưa đầy đủ" như bạn đã nêu trong báo cáo lãnh đạo.

Nên áp dụng Scrum of Scrums (SoS) khi:
Phạm vi: Dự án có từ 2-3 nhóm.
Đặc điểm công việc: Các nhóm làm việc trên các module khá độc lập, ít đụng chạm mã nguồn (codebase) của nhau.
Mục tiêu: Bạn chỉ cần một kênh để các Lead cập nhật tình hình và hỗ trợ nhau xử lý rào cản (Impediments).
Trạng thái: Dự án đang chạy ổn định, ít rủi ro về mặt tích hợp hệ thống.

Nên áp dụng Nexus Framework khi:
Phạm vi: Dự án lớn (3-9 nhóm) làm việc trên CÙNG một Product Backlog.
Đặc điểm công việc: Các nhóm thường xuyên sửa đổi cùng một vùng dữ liệu, logic nghiệp vụ đan xen chặt chẽ .
Mục tiêu: Bạn cần một quy trình nghiêm ngặt để kiểm soát việc ghép nối (Integration). Nếu không có Nexus, rủi ro "ghép code lỗi" hoặc "SIT thất bại" là cực cao.
Trạng thái: Dự án đang ở giai đoạn nước rút , cần sự kỷ luật cao để đảm bảo ngày ra được sản phẩm chạy được.

Trong Nexus, các sự kiện Scrum truyền thống vẫn tồn tại ở cấp độ từng Team, nhưng sẽ có thêm các "vỏ bọc" Nexus để điều phối chung.

Dưới đây là template chi tiết cho các sự kiện theo Nexus Guide:

1. Cross-Team Refinement (Tỉa tót Backlog chung)
Sự kiện này cực kỳ quan trọng để phát hiện sớm các phần code/tính năng mà Squad 1 và Squad 2 dễ đụng chạm nhau.

Người tham gia: Duy nhất 1 PO, đại diện từ các Squad (thường là Tech Lead/BA).

Thời gian: Diễn ra liên tục hoặc nhiều lần trong Sprint.

Đầu vào: Product Backlog chung cho cả dự án.

Mục tiêu: * Xác định các phụ thuộc (dependencies) giữa các Squad.

Chia nhỏ các User Story lớn thành các phần mà các Squad có thể làm độc lập.

Đảm bảo các US đạt chuẩn DOR.

2. Nexus Sprint Planning (Lập kế hoạch Sprint tổng thể)

Người tham gia: Nexus Integration Team (NIT), PO, và đại diện từ các Squad.

Thời gian: Trước khi từng Squad họp Planning riêng (Khoảng 1-2h).

Đầu vào: Product Backlog đã được tỉa tót và ưu tiên.

Mục tiêu: * Xác định Nexus Sprint Goal (Mục tiêu chung cho cả dự án trong 2 tuần tới).

Phân chia các US cho từng Squad sao cho giảm thiểu sự chồng chéo.

Kết quả: Một bản kế hoạch tích hợp sơ bộ.

3. Nexus Daily Scrum (Họp đứng tổng thể)

Sự kiện này giúp bạn giải quyết vấn đề "UI chậm" hoặc "SIT chưa đầy đủ" mà bạn đã báo cáo.

Người tham gia: Đại diện từ mỗi Squad (thường là người đang gặp vướng mắc kỹ thuật).

Thời gian: 15 phút (Trước khi từng Squad họp Daily riêng).

Đầu vào: Trạng thái tích hợp hiện tại trên Jira (Dashboard chung).

Mục tiêu: * Tập trung vào Vấn đề Tích hợp: "Squad 1 làm xong module này thì Squad 2 có test được không?".

Chia sẻ các khó khăn chung (ví dụ: Môi trường UAT/PPE đang bị lỗi).

4. Nexus Sprint Review (Sơ kết tổng thể)

Thay vì từng Squad demo riêng, lãnh đạo sẽ chỉ xem một sản phẩm đã tích hợp.

Người tham gia: PO, NIT, tất cả các Squad, Stakeholders (Lãnh đạo/Chủ đầu tư).

Thời gian: Cuối Sprint (2-3h).

Đầu vào: Integrated Increment (Phần tăng trưởng đã được tích hợp và kiểm thử xong).

Mục tiêu: * Chứng minh giá trị sản phẩm đã hoàn thiện (không phải từng mảnh rời rạc).

Nhận phản hồi từ lãnh đạo dựa trên toàn bộ tiến độ dự án.

5. Nexus Sprint Retrospective (Cải tiến tổng thể)

Đây là nơi bạn xử lý triệt để việc "Squad 2 chậm, Squad 1 mới start" làm sao để phối hợp.

Người tham gia: Nexus Integration Team (NIT) và đại diện các Squad.

Thời gian: Cuối Sprint (Chia làm 3 giai đoạn).

Đầu vào: Các vấn đề phát sinh gây cản trở việc tích hợp và hoàn thành DOD chung.

Mục tiêu: * Tìm ra các vấn đề mang tính hệ thống (ví dụ: Quy trình bàn giao UI từ Squad này sang Squad kia đang bị hỏng).

Đề ra hành động cải tiến cho toàn bộ Nexus.

Sự kiện Nexus	Ai chủ trì	Mục tiêu cốt lõi	Output chính
Refinement	PO / BA	Phát hiện phụ thuộc (Dependencies)	Product Backlog sẵn sàng (Ready)
Planning	NIT	Thống nhất mục tiêu chung	Nexus Sprint Goal & Phân bổ Squad
Daily Scrum	Đại diện Squad	Giải quyết rào cản tích hợp	Kế hoạch tích hợp trong ngày
Review	PO	Demo sản phẩm đã tích hợp	Phản hồi từ Stakeholders
Retrospective	NIT	Cải tiến quy trình phối hợp	Action Plan cho toàn bộ Nexus

CHECKLIST CHO BUỔI NEXUS DAILY SCRUM (15 PHÚT)

1. Kiểm soát Sự phụ thuộc (Dependencies) - "Mắt xích quan trọng"

[ ] Sự chồng chéo mã nguồn: Có Squad nào đang can thiệp vào cùng một module/database mà Squad kia đang fix lỗi không?

[ ] Thứ tự bàn giao: Squad 1 có đang chờ kết quả cấu hình hệ thống từ Squad 2 để bắt đầu code không?

[ ] Tắc nghẽn UI/Logic: Squad 2 đang chậm bàn giao UI, liệu việc này có kéo theo Squad 1 bị "đóng băng" thiết kế không?

2. Kiểm soát Tích hợp (Integration) - "Phần lõi của Nexus"

[ ] Trạng thái Build/Deploy: Bản build tích hợp (Integrated Increment) cuối ngày hôm qua có thành công không? Nếu lỗi, Squad nào sẽ chịu trách nhiệm chính để fix ngay?

[ ] Dữ liệu dùng chung: Việc đổ dữ liệu test cho Squad 1 có làm ảnh hưởng đến môi trường UAT mà Squad 2 đang chạy không?

[ ] Định nghĩa Hoàn thành (DOD): Các task "Done" của từng Squad đã thực sự được ghép lại và chạy ổn định trên môi trường tích hợp chưa?

3. Kiểm soát Rủi ro & Rào cản (Impediments) - "Xử lý At Risk"

[ ] Nguồn lực Tester: 01 nhân sự OS mới join có bị quá tải khi phải test cho cả 2 Squad không? Ưu tiên đổ quân vào Squad nào trong hôm nay?

[ ] Phát sinh ngoài kế hoạch: Có thay đổi nào từ PO/Lãnh đạo làm xáo trộn Backlog của một trong hai Squad không?

[ ] Môi trường (Environment): Môi trường UAT/PPE có đang ổn định cho lộ trình ngày 06/04 không?

CÂU HỎI CHIẾN THUẬT (Dành cho đại diện mỗi Squad)

Để buổi họp nhanh gọn và hiệu quả, bạn hãy yêu cầu đại diện Squad trả lời đúng 3 câu này:

Vấn đề tích hợp: "Hôm qua có vấn đề gì phát sinh khi tích hợp phần việc của Squad mình vào sản phẩm chung không?"

Rào cản liên nhóm: "Có công việc nào của Squad khác đang làm chậm tiến độ của Squad mình không?"

Cảnh báo sớm: "Trong 24h tới, Squad mình có kế hoạch làm gì mà có nguy cơ gây ảnh hưởng đến Squad khác không?"