Giới thiệu về Nexus Framework
Mục đích của Nexus guide Nexus là một khung làm việc để phát triển và duy trì các sản phẩm phần mềm quy mô lớn một cách chủ động. Nó sử dụng Scrum như các đơn vị tạo thành. Nexus guide chứa đựng định nghĩa về Nexus bao gồm : các vai trò Nexus, các sự kiện, tạo tác và các quy tắc gắn kết các yếu ...
Mục đích của Nexus guide
Nexus là một khung làm việc để phát triển và duy trì các sản phẩm phần mềm quy mô lớn một cách chủ động. Nó sử dụng Scrum như các đơn vị tạo thành. Nexus guide chứa đựng định nghĩa về Nexus bao gồm : các vai trò Nexus, các sự kiện, tạo tác và các quy tắc gắn kết các yếu tố trên. Ken Schwaber và Scrum.org phát triển Nexus và viết ra tài liệu này.
Định nghĩa Nexus
Nexus : đơn vị phát triển (trong Scaled Professional Scrum) Nexus là một khung làm việc bao gồm các vai trò, sự kiện, tạo tác và kỹ thuật được gắn kết và đan xen của từ 3 tới 9 nhóm Scrum cùng làm việc trên một Product Backlog để xây dựng một tăng trưởng tích hợp thỏa mãn mục tiêu.
Nexus Framework
Nexus là một bộ khung được cấu thành từ nhiều nhóm Scrum phối hợp với nhau để tạo ra các tích hợp tăng trưởng. Nexus thống nhất và phù hợp với Scrum, nó cũng quen thuộc với những người đã làm việc trong các dự án Scrum. Sự khác biệt ở đây là cần chú ý nhiều hơn tới sự phụ thuộc và liên kết giữa các nhóm Scrum để chuyển giao ít nhất một tích hợp tăng trưởng đã được hoàn thành vào cuối mỗi Sprint
- Roles: một vai trò mới, nhóm tích hợp Nexus , tồn tại để điều phối, hướng dẫn và giám sát việc ứng dụng Nexus và vận hành Scrum để đạt kết quả tốt nhất. Nhóm tích hợp Nexus bao gồm Product Owner, Scrum Master và các thành viên tích hợp Nexus
- Artifacts: tất cả các nhóm Scrum sử dụng chung một Product Backlog duy nhất. Một khi các Product Backlog item được làm mịn và sẵn sàng, chỉ thị về công việc của từng nhóm Scrum trong Sprint được thể hiện rõ ràng, trực quan. Một tạo tác mới , Nexus Sprint Backlog, tồn tại và giúp làm tăng tính minh bạch trong Sprint. Tất cả các nhóm Scrum sử dụng Sprint Backlog riêng của mình.
- Events: Các sự kiện cũng được bổ sung, bao lại, hoặc thay thế (trong trường hợp Sơ kết Sprint) các sự kiện Scrum thông thường để củng cố chúng. Khi được thay đổi, những sự kiện này phục vụ cả cho những nỗ lực chung của tất cả các nhóm Scrum trong Nexus, cũng như cho từng nhóm riêng.
Nexus Process Flow
Tất cả công việc trong Nexus có thể hoàn thành bởi mọi thành viên của các nhóm Scrum, như thành viên liên chức năng của Nexus. Dựa trên sự phụ thuộc, các nhóm có thể lựa chọn thành viên thích hợ nhất để làm một công việc cụ thể.
- Làm mịn Product Backlog: Product Backlog cần được chia nhỏ để các phụ thuộc được nhận dạng, loại bỏ hoặc làm nhỏ tới mức tối đa. Product Backlog item được làm mịn thành các chức năng tới mức đủ nhỏ và rõ ràng để có thể xác định được nhóm sẽ thực hiện công việc một cách sớm nhất
- Nexus Sprint Planning : các đại diện thích hợp từ các nhóm Scrum gặp gỡ để trao đổi và duyệt lại Product Backlog sau khi làm mịn. Họ lựa chọn các Product Backlog item cho mỗi nhóm. Sau đó , mỗi nhóm Scrum tự lập kế hoạch Sprint cho riêng mình và phối hợp với các nhóm khác nếu cần thiết. Kết ẩu là một nhóm các mục tiêu của Sprint phù hợp với mục tiêu chung của Nexus, Sprint Backlog của mỗi nhóm Scrum và một Nexus Sprint Backlog duy nhất. Nexus Sprint Backlog giúp cho sự lựa chọn Product Backlog Item của các nhóm và sự phụ thuộc trở lên minh bạch.
- Development work: tất cả các nhóm phát triển phần mềm, thường xuyên tích hợp công việc của mình vào một môi trường chung có thể kiểm thử để đảm bảo sụ tích hợp được hoàn thành.
- Nexus Daily Scrum: đại diện thích hợp của các nhóm Scrum họp hàng ngày để xác định các vấn đề tích hợp. Nếu có các vấn đề, thông tin này được chuyển lại trong các Daily Scrum của các nhóm Scrum. Các nhóm Scum sử dụng Daily Scum để lập kế hoạch hàng ngày,để đảm bảo rằng các vấn đề tích hợp đã đưa ra trong cuộc họp Nexus hàng ngày đã được đề cập.
- Nexus Sprint Review: Tất cả các nhóm họp với Product Owner để duyệt tích hợp tăng trưởng. Điều chỉnh có thể được thực hiện đối với Product Backlog.
- Nexus Sprint Retrospective: đại diện thích hợp của mỗi nhóm họp để chia sẻ các thách thức. Sau đó mỗi nhóm Scrum họp cải tiến Sprint riêng. Đại diện thích hợp của các nhóm họp lại lần nữa để trao đổi về những hành động cần thiết dựa trên những thách thức đã được chia sẻ.