HƯỚNG DẪN Nexus - s3.amazonaws.com · Lập kế hoạch Nexus Sprint: Các đại diện...

HƯỚNG DẪN Nexus™

Hướng dẫn Nexus chính thức:

Khung Phát triển Scrum Mở rộng

Phát triển và bảo trì bởi Ken Schwaber và Scrum.org

Tháng 8 năm 2015

Hướng dẫn Nexus 1.1 – Bản dịch tiếng Việt

Copyright Scrum.org, 2015 All Rights Reserved Trang 1 (Phiên bản 1.1)

MỤC LỤC

Tổng quan về Nexus ...................................................................................................................... 2

Mục đích của Hướng dẫn Nexus ...................................................................................................2

Định nghĩa Nexus ..........................................................................................................................2

Nexus Background ........................................................................................................................2

Khung làm việc Nexus...................................................................................................................3

Luồng Xử lý Nexus........................................................................................................................4

Thực hành Phần mềm ...................................................................................................................4

Nexus .............................................................................................................................................. 4

Các vai trò của Nexus....................................................................................................................5

Nhóm Tích hợp Nexus .................................................................................................................5

Các sự kiện Nexus .........................................................................................................................6

Lập kế hoạch Nexus Sprint ..........................................................................................................6

Họp Nexus Scrum Hằng ngày ......................................................................................................7

Sơ kết Nexus Sprint .....................................................................................................................7

Cải tiến Nexus Sprint...................................................................................................................7

Làm mịn .....................................................................................................................................8

Các Tạo tác Nexus.........................................................................................................................9

Product Backlog ..........................................................................................................................9

Mục tiêu Nexus ...........................................................................................................................9

Nexus Sprint Backlog ..................................................................................................................9

Phần Tăng trưởng Tích hợp..........................................................................................................9

Minh bạch hóa Tạo tác..................................................................................................................9

Đinh nghĩa "Hoàn thành" ........................................................................................................... 10

Lời kết......................................................................................................................................... 10

Ghi nhận ..................................................................................................................................... 10

Về bản dịch Tiếng Việt ................................................................................................................ 11

Lịch sử phiên bản........................................................................................................................ 12

Bảng đối chiếu Thuật ngữ ........................................................................................................... 13

TRANSLATED BY:

Agile Vietnam Translation Team

Website

Facebook

mailto:[email protected]

http://www.agilevietnam.org/

http://www.agilevietnam.org/

https://www.facebook.com/groups/agilevietnam/



Tổng quan về Nexus

Mục đích của Hướng dẫn Nexus Nexus là một khung làm việc để phát triển bền vững và các sáng kiến phát triển phần mềm

có quy mô lớn. Nó dùng Scrum như đơn vị cấu thành. Tài liệu Hướng dẫn này chứa định

nghĩa về Nexus. Định nghĩa đó bao gồm các vai trò Nexus, các sự kiện, các tạo tác, và các

quy tắc gắn kết các yếu tố đó lại với nhau. Ken Schwaber và Scrum.org đã phát triển Nexus

và cũng chính là những người viết nên Tài liệu Hướng dẫn Nexus này.

Định nghĩa Nexus Nexus (danh từ): Đơn vị phát triển (dùng trong Scaled Professional Scrum)

Nexus là một khung làm việc chứa đựng các vai trò, các sự kiện, các tạo tác, và các kỹ

thuật để gắn kết và đan xen các công việc thích hợp của từ ba đến chín Nhóm Scrum làm

việc trên cùng một Product Backlog lại với nhau, với mục đích xây dựng nên một phần Tăng

trưởng Tích hợp thỏa mãn một mục tiêu.

Nexus Background Phát triển phần mềm là công việc phức tạp và việc tích hợp từng phần sản phẩm đó vào

phần mềm chạy được cần có sự điều phối nhiều hoạt động và tạo tác với nhau để tạo ra

một kết quả "Hoàn thành". Công việc phải được tổ chức, trình tự hóa, xử lý các sự phụ

thuộc, và tổ chức các đầu ra. Bản thân phần mềm có những phức tạp vì nó không được thể

hiện ở dạng vật lý.

Nhiều nhà phát triển phần mềm đã và đang dùng khung làm việc Scrum để cùng làm việc

như một nhóm nhằm phát triển Phần tăng trưởng cho các phần mềm chạy được. Tuy nhiên,

nếu có nhiều hơn một Nhóm Scrum làm việc trên cùng một Product Backlog và trên cùng

một bộ mã nguồn, nhiều khó khăn sẽ xuất hiện. Nếu các nhà phát triển của một nhóm không

ở cùng một một nơi, họ sẽ trao đổi với nhau thế nào khi họ làm những việc sẽ ảnh hưởng

đến những người khác? Nếu họ làm việc ở các nhóm khác nhau, họ sẽ phối hợp công việc

và kiểm thử Phần tăng trưởng Tích hợp bằng cách nào? Các thử thách đó xuất hiện khi hai

nhóm phối hợp, và càng khó khăn hơn khi có từ ba nhóm trở lên.

Các phụ thuộc giữa công việc của nhiều nhóm sẽ phát sinh khi họ hợp tác để tạo ra và hoàn

thiện Phần tăng trưởng "Hoàn thành" của mỗi Sprint. Các phụ thuộc này liên quan đến:

1. Yêu cầu: Phạm vi của các yêu cầu có thể bị chồng chéo, và việc hiện thực hóa

chúng cũng có thể làm ảnh hưởng lẫn nhau. Vấn đề này cần được tính toán khi sắp

xếp Product Backlog và chọn lựa các yêu cầu.

2. Kiến thức nghiệp vụ: Con người trong các nhóm có những kiến thức khác nhau về

nghiệp vụ và các hệ thống tính toán. Những kiến thức đó cần được ánh xạ với các

Nhóm Scrum để đảm bảo tính thích hợp và cũng để giảm thiểu sự gián đoạn giữa

các nhóm trong mỗi Sprint.

3. Phần mềm và tạo tác kiểm thử: Các yêu cầu được hoặc sẽ được thể hiện trong mã

nguồn phần mềm và bộ kiểm thử.

Những yêu cầu, kiến thức của các thành viên, và các tạo tác mã nguồn/kiểm thử được ánh

xạ tương ứng cho các Nhóm Scrum để làm giảm sự phụ thuộc giữa các Nhóm.



Khi dùng Scrum để phát triển các phần mềm có quy mô, các phụ thuộc về yêu cầu, kiến

thức nghiệp vụ, và các tạo tác phần mềm/kiểm thử nên định hướng việc tổ chức nhóm. Sự

định hướng này diễn ra đến đâu, năng suất sẽ được tối ưu đến đó.

Khung làm việc Nexus Nexus là một bộ khung cấu thành bởi nhiều nhóm Scrum phối hợp với nhau để tạo ra các

Phần tăng trưởng Tích hợp. Nexus phù hợp với Scrum, các thành phần của nó quen thuộc

với những ai đã từng làm việc trong các dự án Scrum. Khác biệt ở đây là cần quan tâm

nhiều hơn đến sự phụ thuộc, sự liên kết hoạt động giữa các Nhóm Scrum, việc cung cấp ít

nhất một Phần tăng trưởng Tích hợp ở mỗi Sprint.

Như thể hiện trong hình vẽ dưới đây, Nexus bao gồm:

Các vai trò: Một vai trò mới, Nhóm Tích hợp Nexus, phối hợp, huấn luyện, và giám

sát việc áp dụng Nexus và các vận hành Scrum để đạt được kết quả tốt nhất. Nhóm

Tích hợp Nexus gồm có một Chủ sản phẩm, một Scrum Master, và các Thành viên

Tích hợp Nexus.

Các tạo tác: Tất cả các Scrum Team cùng dùng chung một Product Backlog. Khi các

mục của Product Backlog được làm mịn và sẵn sàng, các chỉ thị công việc của từng

nhóm trong mỗi Sprint cũng được thể hiện trực quan. Một tạo tác mới, Nexus Sprint

Backlog, làm tăng tính minh bạch trong Sprint. Mọi Nhóm Scrum duy trì Sprint

Backlog riêng của mình.

Các sự kiện: 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™ Framework, khung cơ bản cho mô hình Scrum mở rộng



Luồng Xử lý Nexus Tất cả công việc trong một Nexus có thể được hoàn thành bởi tất cả thành viên của các

Nhóm Scrum, đó là tính liên chức năng trong Nexus. Dựa vào sự phụ thuộc, các nhóm chọn

ra các thành viên phù hợp nhất để thực hiện những công việc cụ thể.

Tinh chỉnh Product Backlog: Product Backlog cần được phân tách sao cho các phụ

thuộc được xác định và bị loại bỏ hoặc giảm thiểu. Các hạng mục trong Product

Backlog được tinh chỉnh thành các chức năng đủ nhỏ và rõ ràng, và xác định được

nhóm sẽ thực hiện cho từng hạng mục sớm nhất có thể.

Lập kế hoạch Nexus Sprint: Các đại diện thích hợp từ các Nhóm Scrum gặp nhau để

trao đổi và duyệt lại Product Backlog sau khi đã tinh chỉnh. Họ chọn ra các hạng mục

trong Product Backlog cho từng nhóm. Mỗi Nhóm Scrum sau đó sẽ lập kế hoạch cho

Sprint của mình, tương tác với các nhóm khác nếu cần thiết. Kết quả là một tập các

Mục tiêu Sprint phù hợp với mục tiêu chung, các Sprint Backlog cho từng nhóm và

một Nexus Sprint Backlog. Nexus Sprint Backlog làm cho sự phụ thuộc giữa các

hạng mục đã được chọn ra từ Product Backlog bởi các Nhóm Scrum trở nên minh

bạch.

Công việc phát triển: Các nhóm phát triển tích hợp thường xuyên các phần sản

phẩm của họ vào một môi trường chung có thể kiểm thử và đảm bảo việc tích hợp

hoàn thành.

Họp Nexus hằng ngày: Các đại diện thích hợp từ các Nhóm Phát triển Scrum gặp

nhau hằng ngày để xác định các vấn đề về tích hợp (nếu có). Nếu có vấn đề, thông

tin này sẽ được chuyển ngược lại vào cuộc họp Hằng ngày của từng Nhóm Scrum.

Sau đó, các Nhóm Scrum sẽ sử dụng cuộc họp Hằng ngày của họ để lập kế hoạch

cho ngày làm việc để đảm bảo rằng rằng các vấn đề về tích hợp đã đưa ra trong

cuộc họp Nexus Hằng ngày được đề cập.

Họp sơ kết Sprint Nexus: Các nhóm và Product Owner gặp nhau để đánh giá phần

Tăng trưởng Tích hợp. Có thể có một số hiệu chỉnh cho Product Backlog.

Họp Cải tiến Sprint Nexus: Các đại diện thích hợp từ các Nhóm Scrum gặp nhau để

xác định các thử thách cùng gặp phải. Sau đó, từng Nhóm Scrum tổ chức các cuộc

họp Cải tiến Sprint riêng. Các đại diện thích hợp từ các nhóm sẽ gặp nhau lại lần

nữa và thảo luận về các hành động cần thiết dựa trên các thử thách chung đó để

cung cấp tri thức (theo hướng tiếp cận) từ dưới lên.

Thực hành Phần mềm Các cách làm phát triển phần mềm là cần thiết để gắn kết công việc mà các Nhóm Scrum

hợp tác tạo ra phần Tăng trưởng Tích hợp. Hầu hết các cách làm đó đòi hỏi tự động hóa.

Việc tự động hóa giúp quản lý khối lượng và độ phức tạp của công việc và các tạo tác, đặc

biệt là trong các môi trường lớn.

Nexus Các vai trò, các sự kiện, và các tạo tác trong Nexus thừa hưởng về chức năng và ý nghĩa

tương ứng từ các vai trò, các sự kiện, và các tạo tác trong Scrum, được trình bày trong Tài

liệu Hướng Dẫn Scrum.



Các vai trò của Nexus Một Nexus bao gồm một Nhóm Tích hợp Nexus và từ ba đến chín Nhóm Scrum.

Nhóm Tích hợp Nexus

Nhóm Tích hợp Nexus chịu trách nhiệm đảm bảo rằng một phần Tăng trưởng Tích hợp

(phần sản phẩm đã kết hợp của một Nexus) phải được đưa ra tại mỗi Sprint. Các Nhóm

Scrum chịu trách nhiệm phát triển các phần Tăng trưởng của phần mềm có thể phát hành

được, như đã mô tả trong Scrum. Các vai trò trong các Nhóm Scrum đã được mô tả trong

Tài liệu Hướng Dẫn Scrum.

Nhóm Tích hợp Nexus là một Nhóm Scrum bao gồm:

Một Chủ sản phẩm

Một Scrum Master

Một hoặc nhiều Thành viên Tích hợp Nexus

Các thành viên của Nhóm Tích hợp Nexus cũng có thể làm việc trong các Nhóm Scrum của

Nexus đó nếu thích hợp và cần thiết. Trường hợp này nếu xảy ra, phải ưu tiên các công

việc của Nhóm Tích hợp Nexus. Cần ưu tiên vai trò thành viên trong Nhóm Tích hợp Nexus

hơn so với các Nhóm Scrum. Điều này đảm bảo rằng việc xử lý các vấn đề ảnh hưởng đến

nhiều nhóm được ưu tiên hơn.

Thành phần của Nhóm Tích Hợp Nexus có thể thay đổi theo thời gian để phản ánh đúng

yêu cầu thực tế của một Nexus. Các hoạt động mà Nhóm Tích hợp Nexus thường làm bao

gồm huấn luyện, tư vấn và nêu bật nhận thức về các phụ thuộc và các vấn đề liên nhóm. Họ

cũng có thể thực hiện công việc trong Product Backlog.

Nhóm Tích hợp Nexus giữ trách nhiệm về mọi vấn đề tích hợp. Đó là nhiệm vụ tích hợp

thành công tất cả các phần việc của tất cả các Nhóm Scrum trong một Nexus. Tích hợp bao

gồm việc xử lý các ràng buộc liên-nhóm về công nghệ, phi công nghệ có thể gây cản trở khả

năng chuyển giao một phần Tăng trưởng Tích hợp liên tục của Nexus. Họ nên dùng tri thức

(theo hướng tiếp cận) từ dưới lên trong Nexus để đạt được giải pháp.

Chủ sản phẩm trong Nhóm Tích hợp Nexus

Một Nexus làm việc trên một Product Backlog duy nhất, và như đã mô tả trong khung làm

việc Scrum, một Product Backlog có một Chủ sản phẩm người có quyền quyết định cuối

cùng về nội dung của nó. Chủ sản phẩm chịu trách nhiệm tối đa hóa giá trị của sản phẩm và

công việc được thực hiện và tích hợp bởi các Nhóm Scrum. Chủ sản phẩm thuộc Nhóm

Tích hợp Nexus.

Chủ sản phẩm chịu trách nhiệm sắp xếp và làm mịn Product Backlog, từ đó phần Tăng

Trưởng Tích hợp tạo ra bởi một Nexus mang lại giá trị tối đa. Điều này có thể đạt được

bằng nhiều cách khác nhau tùy thuộc vào các tổ chức, các Nexus, các Nhóm Scrum, và các

cá nhân.

Scrum Master trong Nhóm Tích hợp Nexus



Vai trò Scrum Master trong nhóm Tích hợp Nexus là đảm bảo khung làm việc Nexus được

hiểu và vận dụng. Scrum Master này cũng có thể là Scrum Master trong một hay nhiều

nhóm Scrum khác trong Nexus.

Thành viên Nhóm Tích hợp Nexus

Việc phát triển mở rộng đòi hỏi những công cụ và thực tiễn mà các Nhóm Scrum riêng lẻ có

thể không thường xuyên sử dụng. Nhóm Tích hợp Nexus bao gồm các chuyên gia phần

mềm có kỹ năng trong việc vận dụng thực tiễn, công cụ và kiến thức chung về xây dựng hệ

thống. Thành viên nhóm Tích hợp Nexus đảm bảo rằng các thực tiễn và công cụ được áp

dụng, hiểu đúng và được dùng để phát hiện các phụ thuộc tương quan, cũng như thường

xuyên tích hợp tất cả tạo tác lại với nhau cho việc định nghĩa của "Hoàn thành".

Thành viên nhóm Tích hợp Nexus có trách nhiệm hướng dẫn và huấn luyện các Nhóm

Scrum trong Nexus hiểu được, thực hành và học hỏi các công cụ và thực tiễn. Thêm nữa,

các thành viên này hướng dẫn các nhóm Scrum việc phát triển, cơ sở hạ tầng hoặc các tiêu

chuẩn kiến trúc theo yêu cầu của tổ chức để đảm bảo chất lượng các phần Tăng trưởng

Tích hợp của việc phát triển.

Khi trách nhiệm chính yếu của các thành viên nhóm Tích hợp Nexus hoàn thành, họ có thể

làm việc như thành viên của nhóm phát triển (Development Team) trong một hoặc nhiều

Nhóm Scrum.

Các sự kiện Nexus Thời lượng của các sự kiện Nexus được hướng dẫn bởi độ dài của các sự kiện tương ứng

trong Hướng dẫn về Scrum. Các sự kiện này có thời lượng quy định, tương ứng với sự kiện

của Scrum.

Lập kế hoạch Nexus Sprint

Mục đích của việc lập kế hoạch Nexus Sprint là điều phối các hoạt động cho một Sprint của

các Scrum Teams trong Nexus. Chủ Sản Phẩm cung cấp kiến thức nghiệp vụ, thông tin chỉ

dẫn và quyết định độ ưu tiên công việc.

Để bắt đầu lập kế hoạch Nexus Sprint, các đại diện từ mỗi Nhóm Scrum sẽ kiểm nghiệm và

điều chỉnh trình tự công việc đã được tạo ra trong những sự kiện Làm mịn. Mọi thành viên

của Nhóm Scrum nên tham gia buổi lập kế hoạch để giảm thiểu những vấn đề do truyền đạt

thông tin.

Mục tiêu Nexus Sprint được định hình trong buổi lập kế hoạch Nexus Sprint. Mục tiêu đó mô

tả dự định sẽ đạt được bởi các nhóm Scrum trong suốt Sprint. Một khi toàn bộ công việc

của Nexus được hiểu rõ, mỗi Nhóm Scrum tiến hành lập kế hoạch Sprint cho riêng họ. Nếu

buổi họp này được triển khai theo trình tự tại một nơi, các nhóm có thể chia sẻ với nhau về

các phụ thuộc mới phát hiện. Việc lập kế hoạch Nexus Sprint được gọi là hoàn tất khi mỗi

Nhóm Scrum hoàn thành lập kế hoạch Sprint cho chính nhóm của mình.



Các phụ thuộc mới có thể được phát hiện ra trong buổi lập kế hoạch Nexus Sprint. Chúng

cần được trực quan hóa và tối thiểu hóa. Trình tự công việc giữa các nhóm cũng có thể

được điều chỉnh. Một Product Backlog được Làm mịn đầy đủ sẽ giảm thiểu sự phát sinh của

các phụ thuộc mới trong buổi lập kế hoạch Nexus Sprint. Mọi hạng mục trong Product

Backlog được chọn cho Sprint và các phần phụ thuộc của nó cần được làm rõ trong Nexus

Sprint Backlog.

Product Backlog nên được cải tiến/làm mịn một cách đúng đắn với các phụ thuộc được

nhận định và gỡ bỏ hoặc giảm thiểu trước buổi lập kế hoạch Nexus Sprint.

Họp Nexus Scrum Hằng ngày

Họp Nexus Scrum mỗi ngày là một sự kiện dành cho các đại diện từ Nhóm Phát Triển

Scrum để kiểm tra trạng thái hiện tại của việc Tăng Trưởng Tích Hợp cũng như để nhìn ra

các vấn đề liên quan đến tích hợp hoặc phát hiện mới về sự phụ thuộc giữa các nhóm.

Trong buổi họp Nexus Scrum hằng ngày, các thành viên tham gia sẽ tập trung vào sự ảnh

hưởng của từng nhóm trong việc Tăng Trưởng Tích Hợp và thảo luận về:

Công việc của ngày hôm trước được tích hợp thành công không? Nếu không thì tại

sao?

Có phát hiện sự phụ thuộc nào mới không?

Có thông tin nào cần chia sẻ với các nhóm trong Nexus?

Trong buổi họp Nexus Scrum hằng ngày, Backlog Nexus Sprint nên được sử dụng để trực

quan hóa và quản lý các phụ thuộc hiện có.

Những việc được nhận định trong buổi họp Nexus Scrum hằng ngày sẽ được truyền tải đến

từng thành viên Nhóm Scrum để lập kế hoạch nội bộ tại sự kiện họp Scrum hằng ngày của

họ.

Sơ kết Nexus Sprint

Buổi sơ kết Nexus Sprint được thực hiện vào cuối Sprint để cung cấp phản hồi cho phần

Tăng Trưởng Tích Hợp mà Nexus đã phát triển trong Sprint đó.

Buổi sơ kết Nexus Sprint thay cho sơ kết Sprint của từng Nhóm Scrum do toàn bộ phần

Tăng trưởng Tích hợp sẽ tập trung vào việc lấy ý kiến từ các bên liên quan. Điều này có thể

dẫn tới việc không thể trình bày tất cả công việc hoàn tất một cách chi tiết. Có thể sẽ cần

một số kỹ thuật để lấy được tối đa ý kiến từ những người liên quan.

Cải tiến Nexus Sprint

Cải tiến Nexus Sprint là một cơ hội chính thức dành cho Nexus để tập trung vào việc đánh

giá và sự thích nghi. Bao gồm ba phần:

1. Phần đầu tiên là cơ hội cho các đại diện từ các nhóm trong Nexus gặp nhau và chỉ

ra những vấn đề có thể gây ảnh hưởng đến nhiều hơn một nhóm. Mục đích là làm

minh bạch các vấn đề chung của tất cả các Nhóm Scrum.



2. Phần thứ hai bao gồm việc từng Nhóm Scrum tổ chức buổi họp Cải tiến Sprint như

mô tả trong khung Scrum. Họ có thể dùng những vấn đề được bàn luận từ phần đầu

của buổi họp Cải tiến Nexus như chủ đề để thảo luận cho nhóm của họ. Mỗi Nhóm

Scrum này nên có những hành động cho các vấn đề được nêu ra trong thời gian họp

Cải tiến Sprint.

3. Cuối cùng, phần thứ ba là cơ hội cho đại diện từ các Nhóm Scrum gặp nhau lần nữa

và thống nhất về việc trực quan hóa và lần vết các hành động đã vạch ra như thế

nào. Điều này cho phép Nexus là một tổng thể thích nghi.

Do cuộc họp Cải tiến hay đi lạc hướng, mỗi buổi họp Cải tiến nên theo các chủ đề như sau:

Có công việc nào chưa làm xong? Nexus có gây ra món nợ kỹ thuật không?

Tất cả tạo tác, mã nguồn có được tích hợp thường xuyên (thường là mỗi ngày) một

cách thành công không?

Phần mềm có được biên dịch, kiểm thử và triển khai thường xuyên để ngăn ngừa

việc có quá nhiều phụ thuộc chưa được giải quyết không?

Với những câu hỏi trên, khi cần thiết, cần làm rõ:

Vì sao điều này lại xảy ra?

Nợ kỹ thuật được xử lý như thế nào?

Ngăn ngừa sự tái diễn như thế nào?

Làm mịn

Với quy mô của Nexus, có nhiều mức độ làm mịn. Khi và chỉ khi các hạng mục của Product

Backlog độc lập vừa đủ, chúng mới có thể được chọn và tiến hành làm việc trên đó mà

không phát sinh ra mâu thuẫn giữa các Nhóm Scrum trong Nexus.

Số lượng, tần suất, thời lượng và thành viên tham gia buổi họp Làm mịn dựa trên các phụ

thuộc trong Product Backlog. Với độ phức tạp và sự phụ thuộc càng lớn, càng nhiều hạng

mục của Product Backlog cần được làm mịn để gỡ bỏ các phụ thuộc. Các hạng mục của

Product Backlog được phân tích qua nhiều mức độ, từ những yêu cầu rất lớn và chưa rõ

ràng đến công việc mà một Nhóm Scrum đơn có thể hoàn tất trong một Sprint.

Việc làm mịn Product Backlog có quy mô lớn phục vụ mục đích kép. Nó tiên đoán nhóm nào

sẽ làm được những hạng mục nào của Product Backlog, và nó cũng chỉ ra các phụ thuộc

giữa các nhóm. Sự trực quan hóa cho phép các nhóm theo dõi và giảm thiểu các phụ thuộc.

Phần đầu của việc Làm mịn liên nhóm nên dành cho sự phân tách các hạng mục của

Product Backlog đủ chi tiết để nhóm có thể bàn giao và theo thứ tự ra sao trong các Sprint

tiếp theo.

Phần thứ hai của việc Làm mịn nên tập trung vào các phụ thuộc. Các phụ thuộc nên được

chỉ ra và trực quan hóa giữa các nhóm và Sprint. Nhóm sẽ cần thông tin này để sắp xếp lại

trình tự và phân công công việc của họ để giảm thiểu số lượng phụ thuộc liên nhóm.



Buổi họp Làm mịn được tiến hành với số lần vừa đủ trong một Sprint để hạng mục của

Product Backlog sẵn sàng và có thể chọn được với ít sự phụ thuộc nhất trong buổi họp lập

kế hoạch Sprint.

Các Tạo tác Nexus Các tạo tác thể hiện các công việc hoặc các giá trị của tính minh bạch cũng như các cơ hội

cho việc thanh tra và thích nghi, như mô tả trong Hướng dẫn Scrum.

Product Backlog

Chỉ có duy nhất một Product Backlog cho toàn thể Nexus và các Nhóm Scrum của nó.

Người Chủ sản phẩm chịu trách nhiệm đối với Product Backlog về nội dung, tính sẳn sàng

và thứ tự các hạng mục.

Với quy mô lớn, Product Backlog phải được hiểu rõ tới mức mà các phụ thuộc có thể được

phát hiện và tối thiểu hóa. Về mặt giải pháp, các hạng mục của Product Backlog cần được

thường xuyên phân tách thành các phần nhỏ gọi là "lát cắt" chức năng. Các hạng mục của

Product Backlog được xem là "sẵn sàng" cho buổi họp lập kế hoạch Nexus Sprint khi chúng

có thể được các Nhóm Scrum chọn để làm với sự phụ thuộc là ít nhất hoặc không có phụ

thuộc với các Nhóm Scrum khác.

Mục tiêu Nexus

Trong suốt buổi họp lập kế hoạch Nexus Sprint, mục tiêu của toàn Sprint được đề ra. Mục

tiêu này được gọi là Mục tiêu Nexus. Mục tiêu gồm tất cả các công việc và các Mục tiêu

Sprint từ các Nhóm Scrum trong Nexus. Nexus cần diễn giải các chức năng mà họ đã phát

triển để đạt được Mục tiêu Nexus tại buổi Sơ kết Nexus Sprint.

Nexus Sprint Backlog

Một Nexus Sprint Backlog là tổng hợp tất cả hạng mục Product Backlog từ Sprint Backlog

của các Nhóm Scrum. Nó được dùng để làm nổi bật các phụ thuộc và luồng công việc trong

một Sprint. Nexus Sprint Backlog được cập nhật ít nhất là mỗi ngày, thường xuyên như một

phần hoạt động của Nexus Scrum Hằng ngày.

Phần Tăng trưởng Tích hợp

Phần Tăng trưởng Tích hợp đại diện cho tổng những công việc tích hợp hoàn tất bởi một

Nexus. Phần Tăng trưởng Tích hợp phải là dùng-được và có thể phát hành, nghĩa là nó

phải thỏa mãn định nghĩa "Hoàn thành". Phần Tăng trưởng Tích hợp được thanh tra tại buổi

Sơ kết Nexus Sprint.

Minh bạch hóa Tạo tác

Giống như các khối cấu thành nó, Scrum, Nexus dựa trên tính minh bạch. Một Nhóm Tích

Hợp Nexus làm việc với các Nhóm Scrum trong một Nexus và tổ chức để đảm bảo việc



minh bạch hóa là việc tất cả Tạo tác được rõ ràng và tình trạng tích hợp của Phần tăng

trưởng được hiểu trong phạm vi rộng lớn.

Các quyết định được đưa ra dựa vào trạng thái các tạo tác Nexus chỉ bị ảnh hưởng bởi mức

độ của việc minh bạch tạo tác. Thông tin không đầy đủ sẽ dẫn đến các quyết định không

chính xác hoặc sai lầm. Sự ảnh hưởng từ các quyết địch đó sẽ được khuyếch đại theo quy

mô của Nexus. Việc không đủ minh bạch sẽ dẫn đến việc không thể hướng dẫn nhóm

Nexus giảm thiểu rủi ro, tối đa giá trị một cách hiệu quả.

Phần mềm phải được phát triển sao cho các phụ thuộc được phát hiện và giải quyết trước

khi nợ kỹ thuật trở nên không thể chấp nhận được. Sự kiểm chứng những nợ kĩ thuật không

chấp nhận được chính là lúc việc tích hợp diễn ra, và không có gì rõ ràng là tất cả phụ thuộc

đã được giải quyết hết. Trong những trường hợp này, các phụ thuộc chưa được giải quyết

ẩn trong mã nguồn và đơn vị kiểm thử (test base), làm giảm đi giá trị tổng thể của phần

mềm.

Đinh nghĩa "Hoàn thành"

Nhóm Tích hợp Nexus chịu trách nhiệm đảm bảo định nghĩa "Hoàn thành" được áp dụng

vào phần Tăng trưởng Tích hợp ở mỗi Sprint. Tất cả các Nhóm Scrum của Nexus bám sát

vào định nghĩa "Hoàn thành" này. Phần Tăng trưởng là "Hoàn thành" chỉ khi nó sử dụng

được và có thể phát hành bởi Chủ Sản phẩm.

Một hạng mục của Product Backlog được xem là "Hoàn thành" khi chức năng được thêm

vào sản phẩm thành công và được tích hợp vào phần Tăng trưởng. Tất cả các Nhóm Scrum

có trách nhiệm phát triển và tích hợp công việc của họ vào phần Tăng trưởng sao cho thỏa

mãn các yêu cầu của hạng mục này.

Từng Nhóm Scrum có thể chọn áp dụng một định nghĩa của "Hoàn thành" chặc chẽ hơn

trong nội bộ nhóm, nhưng không thể áp dụng những tiêu chí ít nghiêm ngặt hơn đã nhất trí

cho phần Tăng trưởng.

Lời kết

Nexus là miễn phí1 và được cung cấp thông qua tài liệu hướng dẫn này. Cũng như khung

làm việc Scrum, các vai trò, tạo tác, sự kiện, và quy định trong Nexus là bất biến. Dù chúng

ta có thể thực thi vài phần của Nexus nhưng khi đó kết quả thì không phải là Nexus.

Ghi nhận

Nexus và Scaled Professional Scrum2 được phát triển bởi Ken Schwaber, David Dame,

Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber và

Gunther Verheyen.

1 free 2 Scrum chuyên nghiệp quy mô lớn



Về bản dịch Tiếng Việt

Tài liệu Hướng dẫn này được được dịch từ bản gốc Anh được cung cấp bởi Scrum.org.

Những cá nhân sau đã đóng góp (dịch hoặc/và review) cho bản dịch Hướng dẫn Nexus này:

1. Đỗ Trọng An 2. Nguyễn Thị Hòa Bình 3. Trần Sơn Hải 4. Nguyễn Vũ Hưng 5. Bùi Tuấn Ninh 6. Nguyễn Thị Quế Phương 7. Tô Hồng Quân



Lịch sử phiên bản

Phiên bản Nội dung thay đổi Ngày thay đổi Tác giả

1.0.2 Dịch lại một số từ trong hình ở trang 1 và 3

2015/12/08 Nguyễn Vũ Hưng

1.0.1 Thay đổi hình trang 1 và 3 2015/12/04 Nguyễn Vũ Hưng

1.0 Hoàn thiện dịch và review phiên bản Nexus Guide 1.1 tiếng Việt

2015/11/26 Nhóm dịch Nexus Guide tiếng Việt (xem trang trên)



Bảng đối chiếu Thuật ngữ

English Vietnamese/Tiếng Việt và giải thích

Scrum (Không dịch)

Product Owner (PO) Chủ sản phẩm

Development Team Nhóm Phát Triển

Scrum Master (Không dịch)

Daily Scrum Meeting Họp Scrum hàng ngày

Sprint Planning (Lên) Kế hoạch Sprint

Sprint Review Sơ kết Sprint (hoặc không dịch)

Sprint Retrospective Cải tiến Sprint (hoặc không dịch)

Scrum Artifact Tạo tác, artifact

Transparency Tính minh bạch

Definition of "Done" (DoD) Định nghĩa “Hoàn thành”

Product Backlog (PB) Backlog (của) Sản phẩm

Sprint Backlog Không dịch

Increment Phần tăng trưởng; Phần cải tiến

Sprint Event Sự kiện (trong) Sprint

Inspection Thanh tra

Adaption Thích nghi

Framework Khung làm việc

Potentially releasable functionality Chức năng có thể bàn giao

Cross-functional Liên chức năng

Self-organizing Tự quản

Nexus Integration Team Nhóm Tích hợp Nexus

Scaled Professional Scrum Scrum chuyên nghiệp có quy mô

Nexus Integration Tích hợp Nexus

Nexus Integration Team Nhóm Tích hợp Nexus

Cross-team Liên nhóm

Refinement Sự làm mịn/cải tiến

Technical debt Nợ kỹ thuật

Scrum Guide Tài liệu hướng dẫn Scrum

HƯỚNG DẪN Nexus - s3.amazonaws.com · Lập kế hoạch Nexus Sprint: Các đại diện...

Documents

Transcript of HƯỚNG DẪN Nexus - s3.amazonaws.com · Lập kế hoạch Nexus Sprint: Các đại diện...