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

Scrum là một khuôn khổ mà từ đó quy trình được cải tiến. Scrum team hoặc tổ chức sẽ xây dựng quy trình của chính họ bằng cách tập hợp các phương pháp thực hành phù hợp giúp mang lại thành công và Scrum là trọng tâm chính.
Nexus mở rộng Scrum để hướng dẫn nhiều Scrum team về cách họ cần làm việc cùng nhau để cung cấp sản phẩm hoạt động được trong mỗi Sprint. Đó là hành trình mà các nhóm này hoạt động cùng nhau, cách chia sẻ công việc giữa các nhóm, cách họ quản lý và giảm thiểu sự phụ thuộc. 
Mục đích của biểu đồ dưới đây là giới thiệu cho người đọc hiểu thêm về cách thực hành của Nexus

Hình thành Nexus - Tổ chức nhóm

 
Thực hànhTóm tắtTại sao áp dụng

 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.
 

Hình thành Nexus - Tổ chức công việc

 
Thực hànhTóm tắtTại sao áp dụng
 Biểu đồ tác động
Impact Mapping
  • 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.
 User Story Mapping
  • 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.
 Dựa trên Business-centric trong Product Backlog
  • 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.)
 Sàng lọc giữa các nhóm
  • 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.
 Tạo Product Backlog càng “mỏng” càng tố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.

Khởi chạy Nexus

 
Thực hànhTóm tắtTại sao áp dụng
 Trực quan công việ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.
 Bố cục lập kế hoạch
Nexus Sprint
  • 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.
 Sử dụng Nexus Sprint Backlog để quản lý luồng công việc
  • 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.
 Science Fair/Expo
  • 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.
 Sự kiện Sprint Review  offline
  • 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ự.
 Bảng Retrospective
  • 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.
 Xây dựng tính thử nghiệm vào trong sản phẩm
  • 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.
 Xây dựng phản hồi thủ công vào sản phẩm
  • 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.
 Xây dựng phản hồi tự động vào sản phẩm
  • 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.
 Mở rộng Product Ownership 
  • 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.
 Tích hợp liên tục
  • 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ó.
 Automated Acceptance Testing
  • 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.
 Tính năng chuyển đổi
  • 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.
 Phát triển cho vận hành
  • 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.
 Theo dõi công việc vận hành / Công việc hạ tầng trong Product Backlog
  • 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 đội ở các nhịp khác nhau
  • 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 đó.
 Cộng đồng thực hành
  • 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.
 Theo dõi công việc về kiến trúc của ứng dụng trong Product Backlog
  • 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.
 Tạo điều kiện thuận lợi để kiến trúc của ứng dụng được chia sẻ
  • 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.
 Nguồn mở nội bộ (hay còn gọi là "Nguồn bên trong")
  • 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ẻ.

Quản lý Nexus 

 
Thực hànhTóm tắtTại sao lại dùng
 Product Backlog Treemap
  • 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.
 Tính năng Burndown
  • 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.
 Health Check
  • 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ọ.
 World Café
  • 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.
 Open Spaces
  • 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ú.
 De-scaling
  • 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.
 Scrumble
  • 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ể).
 Distributed Teams Travel
  • 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.
 Distributed Tooling
  • 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.

 

Lược dịch: Duy Linh - Atoha

Nguồn: Scaled Professional Scrum with Nexus Practices 

Mục đích thật sự của Agile

Hệ tư duy của Disciplined Agile

Bản tuyên ngôn Agile - lịch sử hình thành Agile

Trong dự án Agile, công việc ước tính có thật sự cần thiết?

12 nguyên tắc của Agile

Quản lý dự án với Scrum

Scrum of Scrums

User stories - Công cụ lên kế hoạch của Agile

Story points - Công cụ ước lượng của Agile

Velocity là gì - Công cụ đo lường tốc độ hoàn thành công việc của nhóm Agile

Story Map - Lập kế hoạch tổng quát trong Agile

Agile Retrospectives - Nhìn lại và cải tiến hiệu quả công việc dự án

Kanban - phương pháp giúp cải tiến quy trình làm việc của dự án

PDCA - Chu trình cải tiến liên tục

Personas - Công cụ xây dựng hình tượng khách hàng trong Agile

Lean - Tinh gọn hóa quy trình một cách hiệu quả

Hướng Dẫn Scrum 2020 - The Scrum Guide 2020

Bóng đá có 3-5-2, Scrum có 3-5-3

Bắt đầu với Scrum từ đâu đây ta?

Một số cách chạy Daily scrum hiệu quả


Cũ hơn Mới hơn


Thông tin liên hệ

Thông tin chuyển khoản
Công ty Cổ phần ATOHA. Ngân hàng Á Châu (ACB). Số tài khoản: 6868 2468, PGD Tân Sơn Nhì, TPHCM.
Đăng ký khóa học
Chọn khóa học phù hợp bằng cách điền thông tin như link bên dưới. Tư vấn viên Atoha sẽ liên hệ anh/chị ngay.
Câu hỏi thường gặp

“Có. Atoha sẽ có chứng nhận hoàn thành chương trình đào tạo dành cho học viên và cung cấp 35 giờ đào tạo bắt buộc (1 trong 3 điều kiện thi lấy chứng chỉ PMP quốc tế)."

“Cả 2. Tài liệu có thể là tiếng Anh hoặc tiếng Việt tùy vào lớp. Atoha có thể đào tạo bằng cả tiếng Anh hoặc tiếng Việt."

“Chưa bao gồm. Học viên sẽ cần đóng phí thi trực tiếp cho viện PMI nếu muốn đăng ký thi, phí thi tham khảo như sau: 389 USD/non-member và 393 USD/member (trong đó phí thành viên PMI là 99 USD, phí admin là 10 USD, phí thi PMP là 284 USD). Chi phí này dành cho một số khu vực, trong đó có Việt Nam. Tham khảo thêm tại: www.pmi.org"

Liên hệ ngay với Atoha để được tư vấn về chương trình phù hợp