Mở rộng quy mô Scrum với khung thực hành Nexus

 Bắt đầu từ nhóm nhỏ, sau đó phát triển lên

• Kỹ thuật mở rộng quy mô nhóm bắt đầu từ một nhóm nhỏ. 
• Khi nhóm này phát triển, sẽ chia tách nhóm và các thành viên sẽ chuyển sang để bắt đầu các nhóm mới.

• Giúp một nhóm hoạt động hiệu suất cao trước tiên, sau đó là giúp đỡ nhóm khác.
• Tránh việc mở rộng ảnh hưởng đến hiệu suất nhóm.

 Mô hình thực tập

• Kỹ thuật mở rộng quy mô nhóm nhằm duy trì đội ban đầu. 
• Thêm những người mới vào nhóm có hiệu suất cao, sau đó những người mới sẽ chuyển sang thành lập nhóm của riêng họ.

• Để chia sẻ kiến thức giữa các nhóm và thấm nhuần văn hóa chung giữa các nhóm khi mở rộng số lượng các nhóm.

 Nhóm tính năng

• Phương pháp tiếp cận thành lập nhóm bao gồm một nhóm đầy đủ kỹ năng cần thiết có thể kéo, phân phối và hỗ trợ một tính năng end-to-end.

• Cung cấp cho các nhóm sự am hiểu chuyên sâu về nhu cầu của khách hàng và giảm lãng phí và thời gian chờ bằng cách giảm giao công việc cho những người bên ngoài nhóm.

 Microservices

• Một kỹ thuật trong phát triển phần mềm, tổ chức kiến trúc của các ứng dụng xung quanh phân tách  một ứng dụng thành các dịch vụ nhỏ hơn, và có thể triển khai độc lập.

• Để cải thiện tính mô-đun của mã, giúp cải thiện khả năng bảo trì của nó, giúp dễ dàng thay đổi các phần khác nhau của mã một cách độc lập với các phần khác.

 Tính năng giao diện người dùng

• Kỹ thuật thành lập nhóm sử dụng giao diện người dùng để xác định các khu vực có tính liên kết cao và liên kết thấp, sau đó thành lập các nhóm liên quan theo tính năng này.

• Để giảm sự phụ thuộc giữa các nhóm, dựa trên giả định rằng các phần khác nhau của giao diện người dùng phục vụ các nhu cầu khác nhau và có thể được tách biệt khỏi các phần khác.

 Persona Teams

• Phương pháp thành lập các nhóm dựa trên công cụ persona, là các mô tả trừu tượng được hư cấu hóa về chân dung người dùng sản phẩm.

• Cung cấp cho các nhóm thông tin chi tiết sâu hơn về người dùng ứng dụng, điều này có thể giúp họ cảm thấy được kết nối hơn với người dùng, giúp xây dựng các giải pháp tốt hơn.

 Feature Set Teams

• Phương pháp tiếp cận thành lập nhóm trong đó các nhóm hình thành xung quanh các khu vực sản phẩm hướng tới khách hàng, còn được gọi là khu vực giá trị.

• Để mở rộng quy mô các nhóm tính năng bằng cách tập trung vào sự nhất quán trong trải nghiệm khách hàng.

Team Self-Selection

• Kỹ thuật thành lập nhóm trong đó các thành viên trong nhóm lựa chọn nhóm mà họ tham gia dựa trên sở thích, sự ràng buộc, và nhu cầu của nhóm.

• Gia tăng sự nhận dạng của nhóm và giảm xung đột bằng cách trao quyền cho thành viên lựa chọn công việc họ làm và người họ làm việc cùng.

• Kỹ thuật lập kế hoạch sử dụng bản đồ trực quan để giúp giao tiếp và kết nối các mục tiêu kinh doanh, cá tính, kết quả, tác động và các hạng mục trong Product Backlog.

• Để hiểu mối liên hệ giữa Product Backlog với sản phẩm và mục tiêu kinh doanh mà team đáp ứng.

• Một kỹ thuật lập kế hoạch giúp các nhóm phân tách các user story thành các phần công việc có thể quản lý được bằng cách trực quan hóa user story theo hai chiều độc lập.

• Cung cấp một cách có cấu trúc để tinh chỉnh Product Backlog tạo ra phiên bản sản phẩm có thể sử dụng và sau đó là các chức năng bổ sung.

• Kỹ thuật lập kế hoạch giúp các nhóm theo dõi các sản phẩm/dịch vụ chủ đạo của doanh nghiệp khi phân tách Product Backlog.

• Để đảm bảo tính minh bạch và sự liên kết của công việc cần thực hiện để mang lại giá trị kinh doanh (ví dụ: phát triển, tiếp thị, hỗ trợ, v.v.)

• Kỹ thuật Sàng lọc được sử dụng bởi nhiều nhóm làm việc cùng nhau trên một Product Backlog để giảm bớt hoặc loại bỏ sự phụ thuộc giữa các mục trong Product Backlog.

• Để cải thiện quy trình công việc khi nhiều nhóm đang làm việc cùng nhau để xây dựng một Sản phẩm duy nhất.

• Kỹ thuật lập kế hoạch để phân tách và chia nhỏ các mục Product Backlog cùng với các tiêu chí chấp nhận của chúng.

• Để giảm vấn đề các đầu mục công việc trong Product backlog ở trạng thái “chưa hoàn thiện” khi kết thúc Sprint và để giảm thiểu sự phụ thuộc.

• Chiến lược để cập nhật trạng thái và tiến trình các đầu mục công việc trong Product Backlog được hiển thị và minh bạch.

• Giúp gia tăng giao tiếp và giảm sự hiểu lầm về tình trạng công việc của Product Backlog.

• Cách tiếp cận để tổ chức buổi Lập kế hoạch Nexus Sprint, bao gồm cả các nhóm làm việc từ xa.

• Giúp cải thiện khả năng cộng tác trong sự kiện (event) lập kế hoạch Nexus Sprint.

• Kỹ thuật sử dụng Nexus Sprint Backlog để trực quan hóa trạng thái và tiến trình của các Product Backlog trong Sprint dành cho Nexus.

• Loại bỏ nhu cầu sử dụng các tạo tác khác giúp công việc trở nên minh bạch bằng cách trực quan hóa trình tự và các yếu tố phụ thuộc của dự báo Product Backlog cho Sprint dành cho Nexus.

• Tập hợp các kỹ thuật liên quan có thể giúp cải thiện buổi Sprint Review trên quy mô lớn bằng cách cho phép các bên liên quan thấy những gì họ muốn / cần xem, theo yêu cầu, trong buổi Nexus Sprint Review.

• Để làm cho việc thực hiện các buổi Sprint Review quy mô lớn hiệu quả hơn và thu hút sự tham gia của Nhóm Phát triển và các bên liên quan.

• Tập hợp các kỹ thuật liên quan cho phép các nhóm tương tác tốt hơn với các bên liên quan khi các bên liên quan đó không thể tham sự kiện Sprint Review, trực tiếp hoặc từ xa.

• Để nâng cao hiệu quả của sự kiện Sprint Review khi các bên liên quan không thể tham dự.

• Tập hợp các kỹ thuật để giúp cho các đầu mục công việc trong buổi Sprint Retrospective minh bạch.

• Để đảm bảo các đầu mục công việc được liệt kê trong buổi Sprint Retrospective không bị bỏ sót hoặc lãng quên.

• Phương pháp xác nhận để đánh giá các lựa chọn thay thế bằng cách sử dụng sản phẩm đã phát hành.

• Để nhận được phản hồi về sản phẩm từ người dùng; để hiểu rõ hơn liệu sản phẩm có đáp ứng được nhu cầu của người dùng hay không.

• Các kỹ thuật xác thực để thu thập sự quan tâm và phản hồi từ sản phẩm đã phát hành.

• Để nhận được phản hồi về sản phẩm từ người dùng; để hiểu rõ hơn liệu sản phẩm có đáp ứng được nhu cầu của người dùng hay không.

• Phương pháp xác nhận sử dụng thiết bị đo lường trong ứng dụng để thu thập thông tin về việc sử dụng từ người dùng.

• Để nhận được phản hồi về sản phẩm từ người dùng; để hiểu rõ  hơn về việc Sản phẩm có đáp ứng được nhu cầu của người dùng hay không.

• Cách tiếp cận để mở rộng quyền sở hữu sản phẩm bằng cách ủy thác một số công việc của Product Ownership trong khi vẫn duy trì trách nhiệm của Product Owner. 

• Để mở rộng quyền sở hữu sản phẩm khi họ có quá nhiều việc phải làm và họ cần sự trợ giúp.

• Là bộ thực hành được tạo ra nhằm yêu cầu nhóm phát triển tích hợp mã vào một kho lưu trữ được chia sẻ nhiều lần trong ngày. 
• Mỗi lần thay đổi code sau đó được xác minh bằng quy trình kiểm tra tự động, cho phép các nhóm phát hiện vấn đề phát sinh sớm nhất có thể.

• Để phát hiện ra các vấn đề về coding và tích hợp mã càng sớm càng tốt, khi những gì vừa làm vẫn còn “mới” trong tư duy của người tạo ra nó.

• Cách tiếp cận để sử dụng sự tự động hóa kiểm tra nhằm xác minh rằng các yêu cầu được chấp nhận. 
• Để giảm mức độ nỗ lực thủ công cần thiết để xác minh rằng các yêu cầu đang được đáp ứng.

• Để giảm mức độ nỗ lực thủ công cần thiết để xác minh rằng các yêu cầu được đáp ứng.

• Kỹ thuật cho phép tất cả công việc được tích hợp bất kể sự sẵn sàng của tính năng.

• Để cho phép code được tích hợp mà không cần đề cập về tình trạng công việc đã hoàn thành một phần bằng cách giữ mã “tắt” cho đến khi mọi thứ sẵn sàng cho tính năng được sử dụng.

• Các kỹ thuật cải thiện khả năng triển khai và khả năng hỗ trợ của các ứng dụng.

• Để cải thiện sự sẵn sàng phát hành của một sản phẩm bằng cách đảm bảo rằng tất cả các công việc cần thiết để triển khai và hỗ trợ Product Backlog được hoàn thành trong cùng một Sprint.

• Các kỹ thuật cải thiện khả năng triển khai và khả năng hỗ trợ của các ứng dụng.

• Để cải thiện sự sẵn sàng phát hành của một sản phẩm bằng cách đảm bảo rằng tất cả các công việc cần thiết để triển khai mã liên quan đến Product Backlog được hoàn thành trong cùng một Sprint.

• Các kỹ thuật để đồng bộ hóa công việc của nhiều nhóm trong Nexus khi độ dài Sprint của họ khác nhau.

• Để xử lý tình huống khi các đội trong Nexus không ở cùng một tốc độ. Đặc biệt trong các sản phẩm phần cứng / phần mềm liên quan nhau và các sản phẩm yêu cầu một số công việc được thực hiện trên mã kế thừa trước đó.

• Kỹ thuật để hình thành và hỗ trợ các nhóm người có chung sở thích, nhằm mục đích chia sẻ kiến thức và nâng cao kỹ năng.

• Để chia sẻ thông tin giữa các nhóm; để nâng cao tính chuyên nghiệp giữa các nhóm.

• Kỹ thuật cải thiện khả năng phục hồi và giảm tổng chi phí vòng đời của các ứng dụng.

• Để cải thiện khả năng phục hồi và giảm tổng chi phí vòng đời của các ứng dụng.

• Một kỹ thuật để tái cấu trúc và chia sẻ các thành phần giữa các ứng dụng và nhóm.

• Để cải thiện khả năng phục hồi và giảm tổng chi phí vòng đời của các ứng dụng.

• Một kỹ thuật cho phép nhiều nhóm thực hiện các thay đổi đối với cùng một mã cùng một lúc.

• Để chuyển từ nhóm sở hữu thành phần sang quyền sở hữu thành phần được chia sẻ.

• Một kỹ thuật để hình dung kích thước và tính hoàn chỉnh của Product Backlog.

• Để cung cấp một cách hình dung kích thước / độ phức tạp của Product Backlog. Cũng được sử dụng để làm cho tình trạng của công việc được minh bạch.

• Một kỹ thuật để hình dung sự hoàn chỉnh của công việc ở cấp độ tính năng.

• Để cung cấp một cách trực quan hóa tình trạng công việc hoàn thành và chưa hoàn thành cho một Sprint hoặc cho một bản phát hành.

• Một kỹ thuật để giúp các nhóm đánh giá hiệu suất làm việc của chính mình.

• Cung cấp một cách đơn giản giúp nhóm “tự chẩn đoán” những thách thức để tập trung vào việc cải thiện điều sẽ giúp ích nhất cho họ.

• Một kỹ thuật tạo điều kiện để chia sẻ kiến thức trong nhóm lớn bằng cách chia nhỏ các nhóm, dựa trên các chủ đề phụ và luân phiên mọi người qua các nhóm với nhau.

• Cung cấp cách chia sẻ và thảo luận các ý tưởng trong môi trường tập hợp nhiều nhóm với nhau.

• Kỹ thuật chia nhỏ các nhóm thông qua hình thức tự tổ chức nhằm thảo luận và tập trung vào chủ đề mà nhóm quan tâm.

• Cách chia nhỏ các nhóm ra để cùng thảo luận các ý tưởng hoặc vấn đề cụ thể mà các nhóm còn lại không muốn quá hứng thú.

• Một kỹ thuật để khôi phục trật tự cho một Nexus đang gặp sự cố mở rộng quy mô bằng cách giảm số lượng nhóm.

• Cung cấp các cách để đơn giản hóa các vấn đề phát sinh do mở rộng quy mô kém hoặc không cần thiết, đặc biệt là các tình huống trong đó số lượng tuyệt đối những người có liên quan trở nên mất ổn định.

• Là kỹ thuật được ví như “kéo còi cảnh báo”; dừng công việc và điều chỉnh cho đến khi có thể khôi phục lại sự ổn định trong một chu trình của Nexus.

• Để đối phó với tình huống Nexus không có khả năng thực hiện công việc hữu ích và tất cả công việc cần phải dừng lại cho đến khi có thể khôi phục lại trật tự và thông suốt (nếu có thể).

• Cách tiếp cận để cải thiện sự gắn kết và xây dựng mối quan hệ làm việc bền chặt hơn với các nhóm phân tán.

• Để cải thiện và tăng cường sự hợp tác giữa các nhóm bằng cách xây dựng các mối quan hệ cá nhân và tạo ra một nền văn hóa chia sẻ giữa các nhóm phân tán.

• Kỹ thuật sử dụng công nghệ để cải thiện khả năng cho các nhóm phân tán làm việc cùng nhau.

• Để giúp việc cộng tác hiệu quả hơn thông qua việc sử dụng thích hợp công nghệ cộng tác phân tán.