Giới thiệu về Nexus Framework

Nexus Framework là một khuôn khổ quản lý dự án phát triển phần mềm được tạo ra bởi Ken Schwaber, đồng sáng lập Scrum. Nexus tập trung vào việc giải quyết các vấn đề phát sinh khi quản lý nhiều nhóm Scrum cùng làm việc trong một dự án lớn.

Nexus Framework được xây dựng dựa trên nguyên tắc Scrum và bổ sung thêm một số thành phần để cung cấp cấu trúc và hướng dẫn cho việc quản lý nhiều nhóm Scrum. Trong Nexus, tất cả các nhóm Scrum cùng làm việc để tạo ra một “Sản phẩm tích hợp”, tức là một phiên bản hoàn thiện của sản phẩm sau mỗi Sprint.

Nexus giới hạn tối đa số lượng nhóm Scrum tham gia (từ 3 đến 9 nhóm). Mỗi nhóm trong Nexus có thể gồm tối đa 9 thành viên, giống như Scrum truyền thống.

Thành phần quan trọng nhất của Nexus là Nexus Integration Team. Đây là một nhóm gồm các thành viên đại diện từ các nhóm Scrum khác nhau, có trách nhiệm đảm bảo rằng công việc được phối hợp và sản phẩm được tích hợp một cách hiệu quả.

Trong Nexus, các nhóm vẫn sử dụng các công cụ và kỹ thuật Scrum truyền thống (như Sprint, Daily Scrum, Product Backlog, Sprint Planning, v.v.). Tuy nhiên, Nexus cũng bao gồm một số hoạt động và vai trò bổ sung để giải quyết các vấn đề phát sinh khi làm việc với nhiều nhóm.

Vai trò của Nexus Framework trong phát triển dự án

Nexus Framework giúp tổ chức, điều phối và quản lý công việc giữa các nhóm Scrum, giúp tăng cường giao tiếp và tương tác, đồng thời đảm bảo rằng mục tiêu chung của dự án được theo dõi và đạt được.

Nexus Framework đóng vai trò quan trọng trong việc tạo ra một cấu trúc làm việc rõ ràng giữa các nhóm Scrum trong một dự án lớn. Bằng cách cung cấp một hướng dẫn chi tiết về cách tổ chức và điều phối công việc, Nexus giúp đảm bảo rằng tất cả các nhóm đều hoạt động một cách hiệu quả và hợp lý. Nexus Framework cũng đóng vai trò quan trọng trong việc giải quyết các vấn đề phức tạp mà các nhóm Scrum có thể gặp phải khi làm việc cùng nhau, như việc đảm bảo rằng tất cả các nhóm đều hiểu và tuân theo mục tiêu chung của dự án. Cuối cùng, Nexus Framework cũng giúp tạo ra một môi trường làm việc trong đó sự giao tiếp và hợp tác giữa các nhóm được khuyến khích và thúc đẩy.

Nguyên tắc và quy tắc làm việc của Nexus Framework

Nexus Framework hoạt động dựa trên ba nguyên tắc chính: đơn giản hóa, tập trung vào sản phẩm và tạo ra một sản phẩm tích hợp. Đơn giản hóa có nghĩa là giảm bớt sự phức tạp bằng cách giới hạn số lượng nhóm tham gia. Tập trung vào sản phẩm đồng nghĩa với việc tất cả các nhóm đều làm việc với mục tiêu chung là tạo ra sản phẩm cuối cùng. Sản phẩm tích hợp là một phiên bản hoàn thiện của sản phẩm sau mỗi Sprint, được tạo ra bởi tất cả các nhóm cùng làm việc.

Các Role trong Nexus Framework

Nexus Integration Team

Đội Nexus Integration Team bao gồm một Product Owner, một Scrum Master và các thành viên chuyên môn cần thiết. Họ chịu trách nhiệm đảm bảo rằng tất cả các nhóm Scrum đều đồng nhất và sản phẩm được tích hợp một cách hiệu quả.

Product Owner in Integration Team

Product Owner là người đảm bảo rằng tất cả các yêu cầu của khách hàng và các bên liên quan được ghi nhận và xếp hạng đúng mức độ ưu tiên trong Product Backlog. Họ cũng là người chịu trách nhiệm đảm bảo rằng tất cả các nhóm Scrum đều hiểu rõ về mục tiêu và yêu cầu của sản phẩm.

ScrumMaster in Integration Team

ScrumMaster trong đội Nexus Integration Team đảm bảo rằng tất cả các nhóm Scrum tuân theo các nguyên tắc và quy tắc của Scrum và Nexus. Họ còn giải quyết các vấn đề phát sinh, giúp cải thiện quá trình làm việc và tạo điều kiện thuận lợi cho việc hợp tác giữa các nhóm.

Nexus Integration Team Member

Các thành viên khác của đội Nexus Integration Team có trách nhiệm cung cấp sự hỗ trợ kỹ thuật và chuyên môn cho việc tích hợp sản phẩm. Họ chịu trách nhiệm đảm bảo rằng công việc được thực hiện một cách mượt mà và các vấn đề phát sinh trong quá trình tích hợp sản phẩm được giải quyết kịp thời.

Nexus Events

Cross-team Refinement

Cross-team Refinement trong các sự kiện Nexus là quá trình các đội Scrum cùng làm việc để cải thiện chất lượng và phạm vi của các mục backlog sản phẩm. Đây là một phần quan trọng của khung Nexus, giúp đảm bảo sự hợp tác hiệu quả và giảm thiểu các vấn đề tích hợp khi nhiều đội làm việc trên cùng một sản phẩm. Dưới đây là các bước chính trong quy trình này:

1. Chuẩn bị cho Refinement

• Product Backlog: Product Owner đảm bảo rằng các mục backlog được chuẩn bị kỹ lưỡng, bao gồm việc làm rõ yêu cầu, tiêu chí chấp nhận và xác định mức độ ưu tiên.
• Lựa chọn Mục Backlog: Các đội xác định các mục cần refinement thêm, đặc biệt là những mục phức tạp hoặc có phụ thuộc giữa các đội.

2. Các Buổi Refinement Liên Nhóm

• Tham Gia Liên Nhóm: Đại diện từ mỗi đội Scrum (thường là các nhà phát triển, tester và Product Owner) tham gia vào các buổi refinement chung.
• Điều Phối: Một thành viên của Đội Tích Hợp Nexus (Nexus Integration Team – NIT) hoặc một người điều phối được chỉ định sẽ dẫn dắt buổi refinement để đảm bảo các cuộc thảo luận hiệu quả và giải quyết các phụ thuộc.

3. Thảo Luận và Làm Rõ

• Làm Rõ Yêu Cầu: Các đội thảo luận và làm rõ yêu cầu và tiêu chí chấp nhận cho các mục backlog. Điều này bao gồm việc hiểu rõ các phụ thuộc, rủi ro và thách thức kỹ thuật.
• Chia Nhỏ và Chi Tiết Hóa: Các mục backlog lớn có thể được chia nhỏ thành các phần nhỏ hơn, dễ quản lý hơn. Mỗi phần được chi tiết hóa đến mức độ mà các đội có thể tự tin lập kế hoạch cho việc triển khai.

4. Kết Quả và Cập Nhật

• Cập Nhật Backlog: Sau buổi refinement, các mục backlog được cập nhật với thông tin chi tiết, bao gồm các yêu cầu rõ ràng, tiêu chí chấp nhận, và sự phân chia công việc giữa các đội.
• Lập Kế Hoạch Tiếp Theo: Các đội sử dụng thông tin từ buổi refinement để lập kế hoạch cho các sprint tiếp theo, đảm bảo rằng công việc được thực hiện một cách liên kết và không gặp vấn đề về tích hợp.

Quá trình refinement liên nhóm trong Nexus là một bước quan trọng để đảm bảo rằng tất cả các đội làm việc một cách đồng bộ và hiệu quả, từ đó tạo ra sản phẩm chất lượng cao.

Nexus Sprint Planning

Nexus là một khung làm việc mở rộng của Scrum, được thiết kế để hỗ trợ nhiều đội Scrum làm việc cùng nhau trên một sản phẩm duy nhất. Quá trình lập kế hoạch Sprint trong Nexus có một số khác biệt so với Scrum truyền thống do sự phối hợp và tích hợp giữa nhiều đội. Dưới đây là các bước chính của quy trình này:

1. Chuẩn Bị Trước Sprint Planning

• Product Backlog Refinement: Trước khi lập kế hoạch Sprint, các mục backlog sản phẩm đã được refinement liên nhóm để đảm bảo chúng sẵn sàng cho việc lập kế hoạch chi tiết.
• Đánh Giá Phụ Thuộc: Xác định và làm rõ các phụ thuộc giữa các đội để chuẩn bị cho việc lập kế hoạch.

2. Sprint Planning Tổng Thể (Nexus Sprint Planning)

• Tham Gia: Đại diện của tất cả các đội Scrum trong Nexus tham gia buổi lập kế hoạch tổng thể, thường bao gồm các Scrum Master, Product Owner, và các thành viên phát triển.
• Mục Tiêu Sprint Nexus: Xác định mục tiêu Sprint chung cho toàn bộ Nexus dựa trên các mục backlog sản phẩm ưu tiên cao nhất.
• Chia Công Việc: Thảo luận và phân chia công việc giữa các đội, đảm bảo rằng tất cả các đội hiểu rõ về mục tiêu chung và sự phân công cụ thể.

3. Sprint Planning Từng Đội

• Lập Kế Hoạch Chi Tiết: Sau buổi lập kế hoạch tổng thể, từng đội Scrum sẽ tổ chức buổi Sprint Planning riêng của mình để lập kế hoạch chi tiết cho các công việc được phân công.
• Đảm Bảo Phụ Thuộc: Các đội đảm bảo rằng tất cả các phụ thuộc đã được làm rõ và có kế hoạch để giải quyết trong Sprint.

4. Kết Quả và Cập Nhật

• Sprint Backlog: Mỗi đội cập nhật Sprint Backlog của mình với các mục công việc cụ thể và chi tiết.
• Lập Kế Hoạch Tích Hợp: Đội Tích Hợp Nexus (Nexus Integration Team – NIT) lập kế hoạch tích hợp để đảm bảo rằng các sản phẩm của các đội sẽ được tích hợp một cách liên tục và hiệu quả.

Nexus Daily Scrum

Nexus Daily Scrum là một sự kiện trong khung Nexus, được thiết kế để hỗ trợ nhiều đội Scrum làm việc cùng nhau một cách hiệu quả. Mục tiêu chính của Nexus Daily Scrum là phối hợp giữa các đội, giải quyết các vấn đề và đảm bảo tiến độ chung của Nexus Sprint. Dưới đây là các đặc điểm và bước chính của Nexus Daily Scrum:

1. Mục Đích

• Phối Hợp Liên Đội: Đảm bảo sự phối hợp và giao tiếp hiệu quả giữa các đội Scrum trong Nexus.
• Giải Quyết Vấn Đề: Nhận diện và giải quyết các vấn đề và phụ thuộc giữa các đội một cách nhanh chóng.
• Tiến Độ Chung: Theo dõi tiến độ của Nexus Sprint và điều chỉnh kế hoạch nếu cần thiết để đảm bảo đạt được mục tiêu chung.

2. Tham Gia

• Đại Diện Đội: Mỗi đội Scrum trong Nexus cử ra một đại diện (thường là một thành viên phát triển) tham gia Nexus Daily Scrum.
• Scrum Master: Scrum Master của các đội có thể tham gia để hỗ trợ và hướng dẫn, nhưng không phải là người chủ trì.

3. Nội Dung và Cấu Trúc

• Thời Gian Ngắn Gọn: Nexus Daily Scrum diễn ra ngắn gọn, thường không quá 15 phút.
• Thông Tin Chia Sẻ: Các đại diện chia sẻ thông tin về tiến độ, những gì đã hoàn thành, các vấn đề gặp phải và kế hoạch cho ngày tiếp theo.
• Tập Trung vào Phụ Thuộc: Đặc biệt tập trung vào việc nhận diện và giải quyết các phụ thuộc giữa các đội.
• Điều Chỉnh Kế Hoạch: Nếu có vấn đề nghiêm trọng hoặc cần điều chỉnh kế hoạch, các đại diện sẽ thông báo và cùng nhau tìm giải pháp.

4. Kết Quả

• Cập Nhật Tiến Độ: Thông tin về tiến độ của Nexus Sprint được cập nhật và chia sẻ giữa các đội.
• Giải Quyết Nhanh Chóng: Các vấn đề và phụ thuộc được nhận diện và giải quyết nhanh chóng để không làm chậm tiến độ chung.
• Tăng Cường Hợp Tác: Nâng cao sự hợp tác và giao tiếp giữa các đội, giúp tất cả cùng làm việc hướng tới mục tiêu chung.

Nexus Sprint Review

Nexus Sprint Review là một sự kiện trong khung Nexus nhằm đánh giá kết quả của một Sprint, nhận phản hồi từ các bên liên quan, và lập kế hoạch cho các công việc tương lai. Sự kiện này là cơ hội để toàn bộ Nexus và các bên liên quan cùng nhau xem xét tiến độ, thành tựu, và điều chỉnh hướng đi nếu cần thiết.

1. Mục Đích

• Đánh Giá Kết Quả Sprint: Xem xét các mục tiêu đã hoàn thành trong Sprint và những gì chưa hoàn thành.
• Nhận Phản Hồi: Thu thập phản hồi từ các bên liên quan để cải thiện sản phẩm.
• Lập Kế Hoạch Tương Lai: Điều chỉnh và lập kế hoạch cho các Sprint tiếp theo dựa trên kết quả và phản hồi nhận được.

2. Tham Gia

• Các Đội Scrum: Tất cả các đội Scrum trong Nexus tham gia để trình bày và thảo luận về kết quả công việc của họ.
• Product Owner: Tham gia để giải thích các mục tiêu và tiến độ của sản phẩm.
• Bên Liên Quan: Các bên liên quan như khách hàng, người dùng, và quản lý tham gia để cung cấp phản hồi và đặt câu hỏi.
• Nexus Integration Team (NIT): Đảm bảo rằng buổi review diễn ra suôn sẻ và tất cả các phần công việc được trình bày đầy đủ.

3. Nội Dung và Cấu Trúc

• Trình Bày Kết Quả: Mỗi đội Scrum trình bày những gì họ đã hoàn thành trong Sprint, bao gồm các tính năng và sản phẩm tăng trưởng.
• Thảo Luận và Phản Hồi: Các bên liên quan thảo luận về những gì đã được trình bày, đưa ra phản hồi và đề xuất cải tiến.
• Xem Xét Tiến Độ: Đánh giá tiến độ so với mục tiêu Sprint Nexus đã đề ra.
• Cập Nhật Product Backlog: Product Owner cập nhật Product Backlog dựa trên phản hồi và các thay đổi về yêu cầu.

4. Kết Quả

• Sản Phẩm Tăng Trưởng: Sản phẩm tăng trưởng hoàn thành được trình bày và đánh giá.
• Phản Hồi và Điều Chỉnh: Nhận được phản hồi từ các bên liên quan và thực hiện điều chỉnh cần thiết cho Product Backlog.
• Kế Hoạch Tiếp Theo: Thông tin và phản hồi thu thập được sẽ ảnh hưởng đến kế hoạch cho các Sprint tiếp theo.

Nexus Sprint Retrospective

Nexus Sprint Retrospective là một sự kiện quan trọng trong khung Nexus, nhằm mục đích cải tiến quy trình làm việc và tăng cường sự phối hợp giữa các đội Scrum làm việc cùng nhau. Dưới đây là các bước chính và đặc điểm của Nexus Sprint Retrospective:

1. Mục Đích

• Cải Tiến Liên Tục: Xem xét những gì đã diễn ra tốt, những gì chưa tốt và tìm cách cải thiện cho Sprint tiếp theo.
• Tăng Cường Sự Phối Hợp: Đảm bảo các đội làm việc cùng nhau hiệu quả hơn, giảm thiểu các vấn đề và xung đột.
• Chia Sẻ Học Hỏi: Chia sẻ những kinh nghiệm và bài học từ Sprint vừa qua để các đội cùng học hỏi và cải thiện.

2. Tham Gia

• Các Đội Scrum: Tất cả các thành viên của các đội Scrum trong Nexus đều tham gia.
• Scrum Master: Scrum Master của các đội tham gia để hỗ trợ và hướng dẫn quy trình retrospective.

3. Nội Dung và Cấu Trúc

Nexus Sprint Retrospective thường được chia thành hai phần: Retrospective tổng thể của Nexus và Retrospective của từng đội Scrum.

Phần 1: Nexus Sprint Retrospective Tổng Thể

• Xem Xét Toàn Bộ Nexus: Xem xét và thảo luận về cách thức các đội phối hợp với nhau trong Nexus. Đánh giá những gì đã diễn ra tốt, những gì gặp khó khăn và nguyên nhân.
• Xác Định Cải Tiến: Đề xuất các biện pháp cải tiến để tăng cường sự phối hợp và giảm thiểu xung đột giữa các đội.
• Lập Kế Hoạch Hành Động: Xác định các hành động cụ thể sẽ được thực hiện để cải thiện quy trình làm việc liên nhóm.

Phần 2: Retrospective Từng Đội Scrum

• Xem Xét Từng Đội: Mỗi đội Scrum tổ chức buổi retrospective riêng để đánh giá các khía cạnh cụ thể của họ.
• Cải Tiến Từng Đội: Đề xuất và lập kế hoạch hành động cho các cải tiến trong nội bộ đội.
• Chia Sẻ Kết Quả: Các đội có thể chia sẻ các bài học và cải tiến với các đội khác để cùng học hỏi và nâng cao hiệu quả chung.

4. Kết Quả

• Hành Động Cải Tiến: Xác định và lập kế hoạch các hành động cải tiến cụ thể cho cả Nexus và từng đội.
• Tăng Cường Phối Hợp: Nâng cao sự phối hợp và giao tiếp giữa các đội, giúp cải thiện quy trình làm việc chung.
• Liên Tục Cải Tiến: Đảm bảo rằng các đội và Nexus luôn cải thiện liên tục và nâng cao chất lượng công việc.

Nexus Artifacts

Nexus Product Backlog

Trong khung Nexus, Product Backlog vẫn đóng vai trò là danh sách các mục cần làm để phát triển sản phẩm, nhưng nó phải được quản lý và phối hợp để hỗ trợ nhiều đội Scrum làm việc cùng nhau một cách hiệu quả. Dưới đây là các đặc điểm và quy trình quản lý Nexus Product Backlog:

1. Đặc Điểm Của Nexus Product Backlog

• Duy Nhất và Trung Tâm: Chỉ có một Product Backlog duy nhất cho toàn bộ Nexus, bao gồm tất cả các mục công việc mà các đội Scrum cần hoàn thành.
• Ưu Tiên Rõ Ràng: Product Owner chịu trách nhiệm ưu tiên các mục backlog để đảm bảo rằng các mục có giá trị cao nhất được thực hiện trước.
• Chi Tiết Phù Hợp: Các mục trong Product Backlog phải đủ chi tiết để các đội có thể lập kế hoạch và thực hiện, nhưng cũng phải linh hoạt để điều chỉnh khi cần thiết.

2. Quản Lý Nexus Product Backlog

• Product Owner: Product Owner của Nexus chịu trách nhiệm chính trong việc quản lý và duy trì Product Backlog. Họ làm việc với các bên liên quan để thu thập yêu cầu và ưu tiên công việc.
• Product Backlog Refinement: Các buổi refinement được tổ chức thường xuyên để đảm bảo các mục backlog được làm rõ và chi tiết hóa. Điều này bao gồm việc xác định và giải quyết các phụ thuộc giữa các đội.
• Sự Tham Gia Của Các Đội: Các đội Scrum tham gia vào quá trình refinement để đóng góp ý kiến và hiểu rõ các mục backlog. Điều này giúp đảm bảo rằng mọi người đều đồng thuận và hiểu rõ công việc cần làm.

3. Quy Trình Quản Lý Nexus Product Backlog

• Thu Thập Yêu Cầu: Product Owner thu thập yêu cầu từ các bên liên quan và thêm vào Product Backlog.
• Ưu Tiên Mục Backlog: Product Owner xác định ưu tiên các mục backlog dựa trên giá trị kinh doanh, rủi ro và phụ thuộc.
• Refinement Liên Nhóm: Các buổi refinement được tổ chức với sự tham gia của các đội Scrum để làm rõ và chi tiết hóa các mục backlog, cũng như giải quyết các phụ thuộc.
• Lập Kế Hoạch Sprint: Các mục backlog được chọn vào các Sprint Backlog của từng đội trong buổi Nexus Sprint Planning, dựa trên ưu tiên và khả năng thực hiện của các đội.

4. Cải Tiến và Điều Chỉnh

• Phản Hồi Từ Sprint Review: Sau mỗi buổi Sprint Review, Product Owner cập nhật Product Backlog dựa trên phản hồi từ các bên liên quan và các thay đổi về yêu cầu.
• Điều Chỉnh Liên Tục: Product Backlog là một danh sách động, được cập nhật liên tục để phản ánh các thay đổi về yêu cầu, ưu tiên và tình hình thực hiện.

Nexus Sprint Backlog

Nexus Sprint Backlog là sự tổng hợp của các Sprint Backlog của từng nhóm Scrum thành viên trong Nexus. Đây là một khái niệm quan trọng để quản lý và điều phối các công việc giữa các nhóm để đảm bảo họ đạt được Mục tiêu Sprint chung.

Đặc điểm chính của Nexus Sprint Backlog:

• Sprint Backlog của từng nhóm:
  • Mỗi nhóm Scrum trong Nexus có Sprint Backlog riêng, bao gồm các mục công việc mà nhóm cam kết sẽ hoàn thành trong một Sprint. Các mục này được lựa chọn từ Product Backlog và được quản lý bởi nhóm để đảm bảo tiến độ và hoàn thành đúng hạn.
• Tích hợp và điều phối:
  • Nexus Sprint Backlog là sự tổng hợp của các Sprint Backlog này. Nó giúp đảm bảo rằng các công việc từ các nhóm khác nhau được tích hợp một cách hài hòa và phù hợp với Mục tiêu Sprint của Nexus.
  • Nhóm tích hợp Nexus (Nexus Integration Team – NIT) có trách nhiệm phối hợp quá trình này, đảm bảo rằng các phụ thuộc giữa các nhóm được quản lý và giải quyết hiệu quả.
• Sự phối hợp hàng ngày:
  • Cuộc họp hàng ngày Nexus Daily Scrum là nơi các đại diện từ các nhóm Scrum thảo luận về tiến độ và các vấn đề gặp phải trong quá trình thực hiện Sprint Backlog. Điều này giúp đảm bảo sự điều phối và sự thích ứng nhanh chóng trong quá trình phát triển sản phẩm.
• Lợi ích của Nexus Sprint Backlog:
  • Minh bạch: Cung cấp minh bạch về tiến độ và cam kết công việc giữa các nhóm.
  • Tăng cường hiệu quả: Hỗ trợ quản lý các phụ thuộc giữa các nhóm, giảm thiểu lãng phí và tối ưu hóa nguồn lực.
  • Tích hợp và linh hoạt: Cho phép Nexus linh hoạt và hiệu quả trong việc phát triển sản phẩm, đáp ứng nhu cầu thay đổi của thị trường và khách hàng.

Integrated Increment

Integrated Increment trong Scrum và khung Nexus đề cập đến sản phẩm hoàn thiện sau mỗi Sprint hoặc Nexus Sprint, khi các mục công việc đã được tích hợp và kiểm tra đúng chất lượng. Đây là bản hoàn chỉnh có thể triển khai cho khách hàng hoặc cuối người dùng. Điều này bao gồm:

1. Sản phẩm hoàn thiện: Đây là phiên bản của sản phẩm đã qua quá trình phát triển, đã tích hợp các tính năng và sửa lỗi, có thể sử dụng hoặc triển khai.
2. Kiểm tra chất lượng: Đảm bảo rằng sản phẩm đã qua các bước kiểm tra và thử nghiệm để đảm bảo tính đúng đắn và chất lượng cao.
3. Triển khai có thể: Các bản cập nhật có thể được triển khai mà không gặp phải vấn đề lớn và phù hợp với mục tiêu của dự án.

Tổng quát lại, Integrated Increment là phiên bản hoàn thiện và tích hợp của sản phẩm sau mỗi Sprint hoặc Nexus Sprint, đã sẵn sàng cho việc sử dụng hoặc triển khai.

TỔNG KẾT

Nexus Framework mở rộng Scrum để quản lý hiệu quả các dự án lớn với nhiều nhóm làm việc đồng thời. Bằng cách tập trung vào tích hợp liên tục và sự phối hợp chặt chẽ giữa các nhóm, Nexus giúp tăng cường hiệu quả, giảm thiểu rủi ro và cải thiện chất lượng sản phẩm. Thông qua các sự kiện và tài sản đặc thù của Nexus, các nhóm có thể làm việc một cách nhất quán và đồng bộ để đạt được mục tiêu chung của dự án.

Nếu bạn muốn tìm hiểu thêm các kiến thức về Quản lý dự án, Scrum, Waterfall,… bạn có thể tham khảo tại:
Fanpage: https://www.facebook.com/scrumpassvn
Group cộng đồng học tập:https://www.facebook.com/groups/270691597973187
Trang chủ Scrumpass: https://scrumpass.com/