Kerangka Nexus: Menskalakan Scrum untuk 3 hingga 9 Pasukan

Oleh Tara Minh · Dikemas kini 10 Oktober 2026

Nexus ialah kerangka daripada Scrum.org untuk kira-kira tiga hingga sembilan Pasukan Scrum yang bekerja bersama pada satu produk. Ia mengekalkan peraturan Scrum dan hanya menambah apa yang diperlukan untuk mengurus kebergantungan: Nexus Integration Team, beberapa acara tambahan, dan satu Integrated Increment bersama yang disumbangkan oleh setiap pasukan pada setiap Sprint.

Kebanyakan kesakitan penskalaan bukan tentang menulis kod dengan lebih pantas. Ia tentang dua pasukan yang menyentuh modul yang sama, pasukan ketiga menunggu kedua-duanya, dan tiada siapa perasan sehingga akhir Sprint. Nexus dibina di sekitar masalah itu. Ia tidak meminta anda menyusun semula syarikat. Ia meminta anda menjadikan kebergantungan kelihatan lebih awal dan memberi seseorang tanggungjawab yang jelas untuk integrasi.

Fakta Utama

• Nexus dibangunkan oleh Ken Schwaber dan Scrum.org, dan Nexus Guide telah mempunyai edisi pada 2015, 2018 dan 2021.
• Nexus Guide semasa (Januari 2021) menghuraikan Nexus sebagai kira-kira tiga hingga sembilan Pasukan Scrum dengan seorang Product Owner dan satu Product Backlog.
• Nexus Integration Team terdiri daripada Product Owner, seorang Scrum Master, dan satu atau lebih Ahli Nexus Integration Team.
• Panduan ini tidak memberikan kotak masa tetap untuk acara Nexus. Tempohnya dipandu oleh acara Scrum yang sepadan.
• Edisi 2021 menamakan semula Refinement kepada Cross-Team Refinement.
• LeSS meliputi 2 hingga 8 pasukan, jadi kedua-dua kerangka bertindih banyak dari segi bilangan pasukan dan berbeza terutamanya pada tahap perubahan organisasi yang diminta.

Apakah kerangka Nexus?

Nexus ialah kerangka untuk membangunkan dan mengekalkan penghantaran produk berskala. Ia melanjutkan Scrum secara minimum. Pasukan masih menjalankan Sprint, mengekalkan seorang Product Owner dan satu Product Backlog, dan mematuhi nilai Scrum yang sama. Yang berubah ialah kumpulan itu menghasilkan satu Integrated Increment dan bukannya beberapa increment yang kurang berkaitan, dan kumpulan kecil memikul akauntabiliti untuk memastikan integrasi itu berlaku.

Perkataan "nexus" bermaksud titik sambungan, dan kerangka ini kebanyakannya tentang sambungan: antara item backlog, antara pasukan, dan antara kerja yang setiap pasukan panggil Done dengan apa yang sebenarnya dihantar bersama.

Tiga idea memikul sebahagian besar bebannya:

• Satu produk, satu backlog. Semua pasukan mengambil daripada Product Backlog yang sama, dimiliki oleh seorang Product Owner.
• Kebergantungan ialah musuh aliran. Hapuskannya melalui refinement sebelum Sprint, dan jejaki yang tinggal.
• Integrasi berlaku setiap Sprint. Nexus mesti menghasilkan Increment bersepadu yang berfungsi sekurang-kurangnya sekali setiap Sprint, bukan pada akhir fasa keluaran.

Peranan Nexus: Nexus Integration Team

Nexus tidak menambah lapisan pengurusan baharu. Ia menambah satu pasukan. Menurut Nexus Guide, Nexus Integration Team merangkumi:

Salah faham yang biasa ialah Integration Team yang melakukan integrasi. Bukan begitu. Setiap Pasukan Scrum masih melakukan kerja integrasinya sendiri. Integration Team menyelaras, membimbing, dan menghapuskan halangan, dan ia bertanggungjawab supaya Integrated Increment benar-benar wujud dan memenuhi Definition of Done. Ia juga memiliki Definition of Done bersama untuk Integrated Increment. Pasukan individu boleh mengenakan piawaian yang lebih ketat ke atas diri mereka, tetapi tidak yang lebih longgar.

Keahlian boleh bertukar ganti apabila kerja berubah. Panduan ini menyatakan bahawa tempat seseorang dalam Integration Team mengatasi keahliannya dalam pasukan selagi tanggungjawab Integration Team dipenuhi, yang merupakan cara sopan untuk mengatakan peranan itu didahulukan apabila keduanya bercanggah.

Acara Nexus

Nexus mengekalkan acara Scrum piawai dan membungkusnya dengan versi merentas pasukan. Berikut ialah cara setiap satu berfungsi menurut Nexus Guide.

Beberapa nota praktikal tentang cara ia berlangsung:

Cross-Team Refinement ialah acara yang berbaloi dengan masa yang diperuntukkan. Jika pasukan anda menghabiskan Sprint Planning untuk mendapati bahawa Pasukan B memerlukan perubahan skema daripada Pasukan A, refinement telah gagal. Layan ia sebagai kerja berterusan, berkait rapat dengan refinement backlog biasa tetapi dengan tugas khusus mengesan dan mengecilkan kebergantungan merentas pasukan.

Nexus Sprint Planning ialah tempat wakil daripada pasukan bertemu untuk mengesahkan susunan kerja dan tugasan pasukan, kemudian setiap pasukan melakukan perancangan sprint biasanya sendiri pada bahagiannya. Nexus Sprint Backlog yang terhasil ialah pandangan bersama terhadap segala yang sedang berlangsung.

Nexus Daily Scrum adalah untuk wakil, bukan semua orang. Ia pendek, ia tentang integrasi, dan outputnya ialah pelarasan kepada Nexus Sprint Backlog dan pelan pasukan sendiri.

Artifak Nexus

Nexus menggunakan artifak Scrum dan menambah beberapa versi bersama:

Panduan ini menggunakan istilah "Nexus Goal" dalam edisi terdahulu dan menamakannya semula sebagai Nexus Sprint Goal pada 2018, untuk menyamai perkataan Scrum. Jika anda membaca catatan blog lama, jangkakan istilah yang lebih lama.

Nexus berbanding SAFe, LeSS, Scrum of Scrums dan Disciplined Agile

Nexus terletak di separuh lebih ringan spektrum penskalaan. Berikut ialah perbandingannya dengan pilihan yang lazimnya ditimbang orang berbanding Nexus.

Dua perbandingan wajar disebut dalam satu ayat setiap satu. Berbanding SAFe, Nexus ialah komitmen yang lebih kecil: anda tidak menerima pakai rentak perancangan untuk seluruh perusahaan, anda menambah satu pasukan koordinasi kepada pasukan yang sudah berkongsi satu produk. Berbanding LeSS, perbezaannya ialah sejauh mana anda sanggup menyusun semula. LeSS meminta pasukan ciri dan seorang Product Owner tunggal dengan kuasa sebenar merentas segala-galanya, manakala Nexus menganggap anda sudah mempunyai asas itu dan memerlukan bantuan pada jahitan integrasi.

Scrum of Scrums ialah pilihan paling ringan. Ia mesyuarat berulang di mana wakil pasukan berkongsi kebergantungan, dan selalunya itulah yang dilakukan pasukan sebelum menerima pakai sesuatu yang rasmi. Nexus boleh dibaca sebagai versi lebih berstruktur bagi idea itu, dengan acara, artifak dan kumpulan yang bertanggungjawab di belakangnya.

Cara mula menggunakan Nexus

Berikut ialah urutan yang sesuai dengan cara pasukan lazimnya menerima pakainya.

1. Sahkan prasyarat. Anda patut mempunyai tiga atau lebih pasukan yang membina satu produk, seorang Product Owner, dan pasukan yang sudah boleh menjalankan Sprint yang baik sendiri. Nexus tidak akan membetulkan pasukan yang belum melakukan Scrum.
2. Bentuk Nexus Integration Team. Namakan Product Owner, pilih Scrum Master, dan pilih satu atau dua orang berpengalaman daripada pasukan sebagai Ahli Integration Team. Persetujui apa yang anda harapkan daripada mereka dalam perjanjian kerja yang ringkas.
3. Tulis satu Definition of Done bersama. Pastikan ia meliputi integrasi, bukan sekadar penyiapan peringkat pasukan, supaya "Done" bermaksud ia berfungsi dengan segala yang lain.
4. Mulakan Cross-Team Refinement. Pilih slot tetap setiap minggu. Teliti bahagian atas backlog, tandakan kebergantungan, dan hiris item sehingga kebanyakannya boleh disiapkan oleh satu pasukan.
5. Jalankan Nexus Sprint Planning. Pilih Nexus Sprint Goal, tugaskan item kepada pasukan, dan bina Nexus Sprint Backlog dengan kebergantungan yang tinggal kelihatan.
6. Simpan papan kebergantungan. Gunakan templat di bawah dan semaknya dalam Nexus Daily Scrum.
7. Adakan satu Nexus Sprint Review dan Retrospective. Tunjukkan satu Integrated Increment, bukan lima demo, dan perbaiki cara pasukan bekerja bersama.
8. Periksa dan laraskan. Jika masalah integrasi terus muncul lewat, baiki refinement dahulu, kemudian komposisi pasukan.

Templat: papan kebergantungan merentas pasukan

Salin ini ke dalam penjejak anda dan kemas kini setiap hari. Ia artifak yang paling banyak diminta orang apabila mereka bermula dengan Nexus.

Nota lajur:

• Perlukan daripada / Diperlukan oleh mengekalkan arah kebergantungan secara eksplisit. Tanpanya, papan bertukar menjadi senarai kebimbangan.
• Tarikh diperlukan patut berupa hari Sprint, bukan "tidak lama lagi" yang kabur. Inilah yang disemak dalam Nexus Daily Scrum.
• Status hanya memerlukan empat nilai: Belum bermula, Sedang dijalankan, Tersekat, Selesai.
• Risiko jika lewat memberi Integration Team kedudukan pantas untuk apa yang perlu dikejar dahulu.

Tabiat yang baik ialah mengira baris terbuka pada Nexus Sprint Planning dan sekali lagi selepas Cross-Team Refinement. Jika bilangannya tidak menurun dari Sprint ke Sprint, refinement tidak menghapuskan kebergantungan dan struktur pasukan ialah suspek seterusnya.

Contoh mengikut fungsi

Nexus lahir daripada perisian, tetapi mekanismenya terpakai pada mana-mana produk yang dibuat oleh beberapa pasukan yang bekerja dalam Sprint.

Perkara yang patut dan tidak patut dilakukan

Bila Nexus ialah pilihan yang salah

Nexus tidak sesuai jika anda mempunyai kurang daripada tiga pasukan, kerana Scrum ditambah penyelarasan ringan sudah mencukupi. Ia juga tidak sesuai jika anda menyelaras banyak produk yang tidak berkaitan dan bukannya satu, atau jika pasukan anda belum berjaya menjalankan Scrum satu pasukan. Dan jika anda memerlukan pembiayaan portfolio, perancangan perusahaan dan tadbir urus yang berat, kerangka seperti SAFe meliputi lebih banyak bidang. Nexus membawa anda dari tiga pasukan hingga sembilan. Ia tidak berpura-pura menjadi model operasi untuk seluruh syarikat.

Jika pasukan anda sudah menjalankan Scrum dan terus berlanggar menjelang akhir Sprint, Nexus ialah perubahan kecil yang berisiko rendah: namakan Integration Team, mula melakukan refinement untuk kebergantungan, dan semak satu Integrated Increment bersama. Mulakan di situ, dan tambah struktur hanya apabila papan memberitahu anda ia diperlukan.