Pada Januari 2018,
dunia melihat cahaya kerangka kerja Nexus yang diperbarui - alat berbasis Scrum yang dirancang untuk kerja tim pada proyek-proyek besar. Para penulis metodologi mengoreksi sejumlah definisi istilah dan
mengubah prosedur perizinan. Sejak awal tahun, Panduan Nexus dilisensikan di bawah lisensi Creative Commons. Dan ini berarti bahwa perusahaan mana pun bebas menggunakan Nexus (seperti Scrum).
Mari kita bicara tentang fitur metodologi dan komponen utamanya.
/ foto oleh Sebastian Sikora CCSiapa dan mengapa menciptakan Nexus
Pada tahun 1996, pengembang Ken Schwaber dan Jeffrey Sutherland memperkenalkan komunitas pengembangan perangkat lunak tangkas
Scrum . Ini adalah seperangkat iterasi yang sangat terbatas dalam waktu (sprint), di mana pengembang harus mengimplementasikan fungsi-fungsi baru untuk program.
Seperti yang dicatat Jeff Sutherland, dalam bukunya
Scrum. Metode manajemen proyek yang revolusioner, "Scrum memungkinkan tim pengembangan untuk mencapai" efisiensi super "dan meningkatkan produktivitas tenaga kerja hingga 300%.
Namun, Scrum memiliki kekurangan - sangat cocok untuk bekerja dalam satu tim (dan jumlah anggotanya yang direkomendasikan hanya tujuh orang), tetapi Scrum tidak melampaui skala di luar perbatasannya - ketika Anda perlu mengoordinasikan pekerjaan sejumlah besar orang.
Untuk memperbaiki situasi dan membantu meningkatkan metodologi, Ken Schwaber
memperkenalkan kerangka kerja Nexus pada 2015. Nexus
membantu menghindari masalah yang sering terjadi pada pengembangan bersama: kesulitan saat menggunakan basis kode yang sama dan ketidakkonsistenan saat mengintegrasikan pencapaian berbagai tim.
Nexus menggunakan pendekatan berulang dan bertahap untuk meningkatkan skala proses pengembangan perangkat lunak. Setiap tim bekerja sebagai bagian dari sprint-nya, dan kemudian hasilnya digabungkan. Ini membuat pengembangan produk lebih mudah untuk dikoordinasikan.
Komponen Nexus
Kerangka kerja ini terdiri dari peran, acara, artefak, serta aturan yang akrab bagi setiap penganut Scrum, yang menyatukan semuanya. Di Nexus, komponen-komponen ini telah sedikit berubah sehingga metodologi dapat diterapkan dalam proyek-proyek skala besar.
Peran Dengan metodologi Scrum, semua peserta dalam proses pengembangan diberi peran khusus. Mereka dapat dibagi menjadi dua kelompok besar - "babi" dan "ayam". Yang pertama mencakup semua orang yang terlibat langsung dalam menciptakan aplikasi: Scrum Master, yang melakukan pertemuan dan memantau kepatuhan terhadap prinsip-prinsip scrum, pemilik produk (Pemilik Produk), mewakili kepentingan pengguna akhir, dan, bahkan, tim pengembangan (Tim Pengembangan).
Kelompok kedua - "ayam" - termasuk pengguna akhir, penjual, konsultan, dll.
Nexus memperkenalkan peran Tim Integrasi Nexus (NIT) untuk membantu meningkatkan metodologi. Ini adalah seluruh tim, yang meliputi Pemilik Produk, Scrum Master, dan perwakilan dari tim scrum. Tugas mereka adalah menilai dan mencegah potensi masalah pengembangan tim. Penting untuk
dicatat bahwa anggota NIT tidak terlibat langsung dalam pemrograman, tetapi memberikan rekomendasi tentang penerapan prinsip-prinsip Scrum dan Nexus ke semua peserta lainnya.
Secara umum, pengenalan NIT membantu meningkatkan koordinasi antar tim karena pembagian tugas yang kompeten. Namun, anggota komunitas TI
mengatakan bahwa peran baru ini juga berkontribusi pada penciptaan semacam “bottleneck” - ketika anggota NIT menyelesaikan masalah organisasi, tim pengembangan berdiri diam menunggu instruksi.
Artefak. Dalam Scrum, artefak dipahami sebagai seperangkat persyaratan untuk fungsionalitas produk yang membantu mengatur kegiatan pengembang. Persyaratan ini dijelaskan dalam dua majalah: backlog proyek dan backlog sprint.
Wishbook proyek mencantumkan persyaratan fungsionalitas umum - yang disebut
cerita pengguna , diurutkan dalam urutan kepentingan yang menurun. Mereka membantu untuk mendapatkan gambaran tentang bagaimana produk akhir seharusnya terlihat.
Sprint Wish Journal - Daftar fitur implementasi yang dipilih oleh pemilik produk. Berdasarkan daftar ini, pengembang melacak tugas yang harus diselesaikan sebelum satu sprint berakhir.
Di Nexus, tim menggunakan Product Backlog alih-alih buku harapan proyek. Untuk menyederhanakan interaksi sejumlah besar pengembang, majalah ini dibagi menjadi beberapa bagian. Setiap bagian “ditugaskan” ke salah satu tim. Jadi, semua pengembang mengerti tugas apa dari seluruh proyek yang mereka kerjakan. Pada saat yang sama, masing-masing tim masih menyimpan catatan keinginan sprint-nya.
Acara Semua anggota tim menghadiri pertemuan, kadang-kadang disebut sebagai istilah umum "peristiwa." "Babi" menghabiskannya setiap hari, dan "ayam" - di awal dan akhir proyek atau berlari. Rapat diperlukan untuk membahas proses pengembangan, memperkirakan rencana, mengidentifikasi kemacetan.
Untuk meningkatkan komunikasi antara tim yang berbeda, pengembang Nexus telah menambahkan empat jenis acara baru:
- Perencanaan Sprint Nexus - saat ini, tim memutuskan siapa yang lebih baik dalam menangani Sprint tertentu dari Product Backlog. Setelah itu, masing-masing tim merencanakan sprint sendiri, berkomunikasi dengan tim scrum lain sehingga tugas mereka tidak tumpang tindih.
- Nexus Daily Scrum - digunakan untuk membahas keadaan terkini. Memungkinkan Anda merencanakan hari ini atau menyelesaikan masalah integrasi.
- Review Nexus Sprint - di sini tim membagikan keberhasilan mereka di akhir setiap sprint.
- Nexus Retrospective - waktu ini dihabiskan untuk mengevaluasi pengalaman masa lalu dan membuat rencana untuk meningkatkan proses pengembangan di masa depan.
Pada
halaman panduan Nexus resmi, Anda dapat menemukan diagram interaksi dan urutan semua peristiwa ini.
Kapan harus menggunakan Nexus
Dalam proyek skala besar. Kerangka kerja ini membantu mengatur kerja beberapa tim scrum dengan mulus dalam proyek-proyek besar. Sebagai contoh, satu perusahaan India yang menciptakan perangkat lunak keamanan (penulis Scrum tidak menyebutkan namanya) menggunakan Scrum selama setahun untuk mengembangkan produk mereka. Pada awalnya, perusahaan memiliki satu tim scrum, tetapi segera jumlah mereka meningkat menjadi tiga, dan masalah dimulai dengan
integrasi solusi individu.
Kemudian perusahaan mengundang ahli Scrum, dan dia mengusulkan untuk memindahkan alur kerja Scrum ke tingkat multi-tim - mengimplementasikan Nexus. Sekarang, menurut metodologi Nexus, enam tim sudah bekerja, yang secara konsisten merilis rilis perangkat lunak baru setiap dua minggu.
Di perusahaan besar. Misalnya, departemen TI Terminales Portuarios Peruanos (TPP), sebuah perusahaan yang bergerak dalam pengiriman di salah satu pelabuhan ibukota Peru, membutuhkan sembilan bulan untuk merilis versi baru perangkat lunak khusus. Untuk memperbaiki situasi, perusahaan mencoba metodologi
Waterfall ,
RUP dan prinsip-prinsip
manajemen proyek tradisional . Namun, semuanya tidak memberikan perbaikan yang signifikan, dan dalam beberapa kasus bahkan menjadi lebih buruk.
Kemudian perusahaan memutuskan untuk mencoba Nexus. Teknik ini memungkinkan untuk mengurangi waktu rilis sebanyak tiga kali dan melepaskan produk setiap tiga bulan.
Nexus membantu membangun interaksi antar tim, "tersebar" di seluruh dunia. Sprint Harian mendukung komunikasi tingkat tinggi dan keterlibatan karyawan dalam proyek.
Perhatikan bahwa meskipun Nexus membantu mengoordinasikan kerja banyak tim pengembangan ketika mengerjakan proyek besar dan mempercepat pelepasan rilis (seperti halnya dengan TPP), Nexus masih
tidak mampu menyelesaikan masalah yang terkait dengan struktur internal organisasi. Misalnya, kerangka kerja tidak akan memiliki efek nyata jika tim tidak memiliki cukup spesialis untuk menyelesaikan semua masalah.
Dengan demikian, Nexus cocok untuk bekerja pada proyek-proyek besar (menurut pencipta metodologi, ini memungkinkan Anda untuk secara efektif mengelola sembilan tim scrum) dan, dengan aplikasi yang tepat, membantu mempercepat proses pengembangan hingga 3-4 kali. Namun, fokus utama metodologi ini adalah untuk menyelesaikan masalah integrasi, karena tidak
dapat membantu dalam memecahkan masalah organisasi lainnya di perusahaan.
NB Beberapa materi segar dari Blog Perusahaan Pertama IaaS:
PS Beberapa publikasi dari saluran Telegram kami: