Cetak Biru Manajemen Proyek Bagian 2: Perbandingan Komprehensif Waterfall, DAD, SAFe, LeSS, dan Scrum@Scale

Ringkasan

Di Bagian 1 dari Cetak Biru Manajemen Proyek, kami membahas metodologi pengembangan perangkat lunak Lean Software Development, Agile, Scrum, dan Kanban dan bagaimana semuanya melacak akarnya kembali ke Lean Manufacturing. Metodologi ini biasanya digunakan pada satu tingkat tim. Namun, kompleksitas tumbuh ketika proyek dan tim proyek menjadi lebih besar dan pendekatan baru diperlukan untuk gesit dalam skala.

Di Bagian 2, pertama-tama kita akan menyelami bagaimana manajer proyek menggunakan metodologi air terjun, yang merupakan kerangka kerja paling umum untuk pengembangan perangkat lunak di perusahaan tradisional. Disandingkan dengan itu, kami akan membahas kerangka kerja paling populer yang mencoba menggabungkan prinsip-prinsip tangkas pada skala–Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), dan Scrum@Scale.

Air terjun

Metodologi air terjun (juga dikenal sebagai model siklus hidup pengembangan perangkat lunak (SDLC)) adalah metodologi yang lebih tradisional di mana pengembangan perangkat lunak mengalir dari satu fase ke fase berikutnya seperti air terjun. Fase-fase tersebut tidak tumpang tindih dan memiliki kriteria masuk dan keluar yang spesifik untuk berpindah dari satu fase ke fase berikutnya.

Enam tahap siklus hidup model air terjun asli adalah:

1. Persyaratan: Pada fase ini, harapan dan tujuan proyek ditentukan, dan persyaratan dianalisis dan didokumentasikan secara ekstensif, biasanya oleh analis bisnis. Persyaratan ditinjau dan disetujui sebelum keluar dari fase ini.
2. Desain: Setelah persyaratan disetujui, pekerjaan dimulai pada arsitektur dan desain produk untuk memenuhi persyaratan yang disetujui. Arsitektur fisik, arsitektur komponen, desain database, komponen rinci, desain modul, dan aspek desain lainnya didokumentasikan oleh arsitek atau perancang perangkat lunak. Kemudian ditinjau dan disetujui sebelum memulai implementasi.
3. Implementasi: Setelah desain disetujui, implementasi atau pengkodean perangkat lunak sesuai dengan kebutuhan dan desain dilakukan oleh pengembang perangkat lunak.
4. Verifikasi: Setelah implementasi selesai, perangkat lunak diuji oleh tim pengujian atau QA untuk memastikan bahwa persyaratan dan desain terpenuhi dan tingkat kualitas yang diinginkan tercapai. Cacat ditemukan, dicatat, diurutkan, dan dalam banyak kasus, diperbaiki.
5. Rilis dan pemeliharaan: Setelah pengujian dan debugging selesai, produk dilepaskan ke klien dan diinstal. Seringkali, putaran pengujian terjadi untuk memastikan bahwa instalasi berhasil. Setelah produk dikirimkan, pemeliharaan dan dukungan berkelanjutan dilakukan untuk memastikan bahwa produk terus bekerja seperti yang dirancang.

Keunggulan Air Terjun

Ada beberapa keuntungan dari air terjun dan cocok untuk jenis proyek tertentu, tetapi ada juga beberapa kelemahan serius. Waterfall paling cocok untuk proyek yang lebih pendek di mana persyaratan, teknologi dipahami dengan baik dan tidak mungkin berubah secara signifikan.

Jika diterapkan pada jenis proyek yang tepat, beberapa kelebihan model air terjun:

• Kesederhanaan: Waterfall mudah diterapkan karena mengidentifikasi ruang lingkup di depan dan karena fase yang kaku dan transisi yang jelas dari satu fase ke fase berikutnya.
• Visibilitas: Kemajuan lebih mudah diukur dan dilihat oleh pemangku kepentingan karena cakupan penuh pekerjaan telah diketahui sebelumnya dan sebagai transisi proyek dari satu tahap ke tahap berikutnya.
• Dokumentasi: Cakupan, persyaratan, dan rencana dapat dipikirkan dengan matang dan didokumentasikan dengan baik, yang memudahkan tim yang kurang berpengalaman untuk mengerjakan proyek.
• Pekerjaan bertahap: Karena peran kaku dan transisi antar fase, sumber daya proyek dapat mengerjakan proyek lain saat fase utamanya tidak berlangsung.

Kekurangan Air Terjun

Waterfall tidak cocok untuk proyek yang lebih panjang di mana persyaratannya tidak dipahami dengan baik dan/atau kemungkinan besar akan berubah dan/atau jika ada risiko teknis yang signifikan. Di zaman sekarang ini di mana kondisi pasar terus berubah dan waktu ke pasar sangat penting, ini berlaku untuk sebagian besar proyek perangkat lunak.

Kekurangan model air terjun, yang sebagian besar berpusat pada ketidakmampuannya untuk beradaptasi dengan perubahan, meliputi:

• Ruang lingkup monolitik: Ini memberi penghargaan kepada pemangku kepentingan untuk memikirkan SEMUANYA ketika mendefinisikan ruang lingkup proyek, yang mengarah ke ruang lingkup monolitik.
• Umpan balik klien yang terlambat: Sulit bagi pemangku kepentingan dan terutama klien untuk membayangkan cakupan proyek yang terperinci secara penuh. Karena air terjun menghadapkan klien ke hasil proyek sebagian besar di tahap terakhir proyek, maka mau tidak mau menjadi sulit untuk memasukkan umpan balik klien ke dalam proyek
• Perubahan persyaratan: Dalam kondisi pasar proyek yang lebih panjang, dan oleh karena itu tujuan dan persyaratan proyek, berisiko sangat tinggi untuk berubah selama proyek berlangsung.
• Nilai yang dibuat di akhir: Waterfall membutuhkan banyak pekerjaan di depan, artinya nilai tidak akan dihasilkan sampai akhir proyek.
• Fase interdependensi: Memasukkan perubahan sering kali menghasilkan persyaratan dan/atau pengerjaan ulang desain yang dapat berdampak pada area lain dari proyek. Ketergantungan tahap selanjutnya pada tahap sebelumnya dapat membuat perubahan kecil dalam proyek menjadi sangat menantang.

Disiplin Agile Delivery (DAD)

Disiplin Agile Delivery (DAD) diformalkan oleh Scott Ambler di IBM dan Mark Lines dan memperluas kerangka kerja tangkas dan scrum, mengakui bahwa bagian non-gesit dari suatu organisasi biasanya terlibat dalam beberapa kapasitas dalam memberikan proyek perangkat lunak. Kerangka kerja ini secara eksplisit mencakup kegiatan dari operasi TI, arsitektur perusahaan, manajemen portofolio, keuangan, dan pengadaan ke dalam siklus hidup pengiriman penuh. DAD bertujuan untuk meningkatkan kelincahan bisnis secara keseluruhan dengan cara yang pragmatis.

Prinsip dan Komponen Utama

Peran

DAD memiliki peran yang jauh lebih banyak daripada scrum dan dipecah menjadi dua kategori peran tim. Peran utama diisi oleh orang-orang yang bekerja dengan proyek secara konstan. Peran sekunder biasanya diperkenalkan sementara untuk membantu tim dengan penskalaan atau masalah lainnya. DAD memiliki peran tambahan ini karena menangani seluruh siklus hidup pengiriman solusi dan karena mengenali berbagai jenis peran sementara dan pendukung yang dibutuhkan yang ditemukan di dunia nyata

Peran utama:

1. Stakeholder: Seseorang yang bergantung pada tim Anda dalam menyelesaikan proyek: klien, pengguna akhir, atau rekan internal.
2. Anggota tim: Orang-orang di dalam tim yang benar-benar melakukan pekerjaan yang direncanakan: pengembang, perancang, penguji, dll.
3. Pemimpin tim : Analog dengan master scrum, pemimpin tim bekerja sebagai pemimpin yang melayani tim dengan menghilangkan hambatan, memfasilitasi kohesi tim, dan menyebarkan nilai-nilai tangkas.
4. Pemilik produk: Kadang-kadang disebut sebagai "suara pelanggan." Pemilik produk mewakili pemangku kepentingan dan menyimpan daftar prioritas pekerjaan yang perlu dilakukan.
5. Pemilik arsitektur: Bertanggung jawab untuk mengurangi risiko arsitektur dalam skala besar. Peran ini biasanya diisi oleh pengembang senior dalam tim karena memerlukan latar belakang teknis yang mendalam dan pengetahuan domain bisnis yang solid.

Peran sekunder:

1. Spesialis: Orang yang bergabung dengan tim sementara untuk membantu dalam peran khusus. Misalnya, seorang analis data dapat bergabung untuk memberikan kemampuan penelitian pada tahap awal proyek.
2. Pakar domain: Konsultan pajak, penasihat hukum, dan orang lain yang memiliki keahlian domain dan membantu tim dalam tantangan terkait.
3. Pakar teknis: Administrator basis data, master pembuat pakar keamanan, dll. Orang-orang ini membantu anggota tim yang lebih umum pada poin-poin penting dalam siklus hidup.
4. Penguji independen: Meskipun penguji biasanya merupakan bagian dari tim utama, dalam beberapa kasus persyaratan peraturan kehidupan atau sistem yang sangat kompleks, penguji independen bekerja secara paralel untuk memvalidasi pekerjaan pengiriman.
5. Integrator: Pada skala, tim yang berbeda bekerja pada bagian yang berbeda dari keseluruhan sistem. Integrator membantu tim mengintegrasikan bagian mereka dengan keseluruhan sistem dan mengelola dependensi.

Dukungan Siklus Hidup

DAD mempromosikan siklus hidup pengiriman penuh, tidak hanya bagian pemrograman dan rilis yang dicakup oleh agile/scrum, tetapi juga fase awal di mana visi proyek ditentukan dan disetujui serta fase dukungan dan penghentian setelah rilis. Saat ini, DAD mendukung 6 siklus hidup yang berbeda:

• Siklus Hidup Agile: Siklus Hidup Proyek Berbasis Scrum
• Siklus Hidup Lean: Siklus Hidup Proyek berbasis Kanban
• Pengiriman Berkelanjutan: Siklus Hidup Agile
• Pengiriman Berkelanjutan: Siklus Hidup Lean
• Siklus Hidup Eksplorasi (Lan Startup)
• Siklus Hidup Program untuk Tim dari Tim

Siklus hidup ini menjelaskan gaya kerja yang berbeda, tingkat kelincahan perusahaan, dan situasi lain yang mungkin dihadapi tim. Poin utamanya adalah bahwa siklus hidup ini bertindak sebagai saran. DAD mempromosikan pragmatisme daripada purisme karena setiap situasi adalah unik dan praktisi tangkas yang disiplin harus mengadopsi proses tangkas sesuai kebutuhan mereka.

Tujuan Proses

DAD menggunakan pendekatan yang didorong oleh tujuan untuk menciptakan dan mengadaptasi proses yang gesit. Penulis metodologi ini menguraikan 21 proses paling penting dan umum yang akan dihadapi sebagian besar tim selama siklus hidup mereka.

Semua proses ini telah mendokumentasikan poin keputusan yang akan mengharuskan tim untuk memutuskan bagaimana mereka akan menyusun proses itu. Setiap titik keputusan menyediakan teknik atau praktik yang disarankan yang dapat digunakan untuk mengimplementasikan keputusan. Anda dapat melihat contohnya pada gambar di bawah ini. Sebuah proses “Mengembangkan Visi Bersama” memiliki 6 keputusan yang harus dibuat. Masing-masing keputusan tersebut memiliki 2 hingga 5 praktik yang disarankan. Panah menunjukkan bahwa penulis DAD telah memesan daftar dengan item teratas menjadi praktik terbaik dan item bawah menjadi praktik terburuk dalam daftar ini. Teks _ bold italic_ menandakan titik awal yang baik untuk tim baru, yang baru memulai dengan DAD.

Penskalaan DAD

Disiplin Agile Delivery mendekati penskalaan dari dua sudut berbeda:

• Kelincahan taktis dalam skala besar

• Kelincahan strategis dalam skala besar

Kelincahan taktis mencoba mengatasi faktor penskalaan tim individu seperti ukuran, distribusi geografis, kompleksitas proyek, dll, melalui penerapan situasional dari tujuan proses dan praktik yang disarankan.

Kelincahan strategis mencoba mengatasi penskalaan melalui penerapan strategi tangkas dan ramping secara luas di seluruh organisasi dengan memperluas kerangka kerja untuk menangani berbagai area organisasi:

• DevOps Disiplin: mencakup penggunaan DevOps untuk memberikan hasil yang lebih efektif bagi organisasi.

• Disiplin Agile IT (DAIT): mencakup bagaimana menerapkan strategi tangkas dan ramping untuk semua aspek TI.

• Perusahaan Agile yang Disiplin:. mencakup cara menerapkan lean dan agile di seluruh perusahaan.

Aman

Scaled Agile Framework (SAFe) adalah framework Agile berskala paling populer serta paling kompleks dan komprehensif saat ini. 29% responden di Laporan Tahunan State of Agile mengklaim bahwa mereka menggunakan kerangka kerja ini di organisasi mereka. Pada gilirannya, ada banyak manajer proyek SAFe di pasar.

Lahirnya SAFe adalah buku Dean Leffingwell "Scaling Software Agility: Best Practices for Large Enterprises," yang diterbitkan pada tahun 2007. Leffingwell sekarang adalah kepala metodologi SAFe, tetapi banyak orang lain juga berkontribusi pada kerangka kerja ini. Saat ini, dalam versi 4.6, kerangka kerja ini menyerupai produk perangkat lunak dengan versi, kompatibilitas mundur, dan berbagai komponen.

Prinsip dan Komponen Utama

Tujuan utama SAFe adalah untuk memfasilitasi penciptaan dan pertumbuhan Perusahaan Lean karena mengakui bahwa berbagai jenis perusahaan, sebagian, adalah perusahaan perangkat lunak yang perlu terus memberikan nilai dalam jangka waktu terpendek dan berkelanjutan.

SAFe for Lean Enterprises mencoba menciptakan Lean Enterprise dengan menyediakan basis pengetahuan tentang prinsip, kompetensi, dan praktik terbaik yang telah terbukti.

SAFe 4.6 mendefinisikan Lima Kompetensi Inti dari Perusahaan Lean. Setiap kompetensi adalah seperangkat pengetahuan, keterampilan, dan perilaku yang terkait, yang bersama-sama memungkinkan organisasi untuk unggul:

1. Kepemimpinan Lean-Agile : Menjelaskan bagaimana para pemimpin mendorong dan mempertahankan perubahan organisasi melalui pembelajaran, pengajaran, dan penerapan pola pikir Lean-Agile SAFe.

2. Kelincahan tim dan teknis : Menjelaskan keterampilan, prinsip, dan praktik yang diperlukan untuk membuat tim Agile berkinerja tinggi.

3. DevOps dan rilis sesuai permintaan : Menjelaskan bagaimana penerapan DevOps dan saluran pengiriman berkelanjutan memberi organisasi kemampuan untuk merilis peningkatan produk kapan saja diperlukan untuk memenuhi permintaan.

4. Solusi bisnis dan rekayasa sistem lean : Menjelaskan cara menerapkan prinsip dan praktik lean-agile pada spesifikasi, pengembangan, penerapan, dan evolusi aplikasi perangkat lunak yang besar dan kompleks

5. Manajemen portofolio ramping : Menyelaraskan strategi dan eksekusi dengan menerapkan pendekatan lean dan pemikiran sistem untuk strategi dan pendanaan investasi, operasi portofolio yang gesit, dan tata kelola.

Masing-masing kompetensi inti dipetakan langsung ke levelnya masing-masing dalam diagram proses SAFe kecuali Lean-Agile Leadership yang mencakup keseluruhan proses.

Kompetensi Kepemimpinan Lean-Agile

Tujuan utama dari Kompetensi Kepemimpinan Lean-Agile adalah untuk membantu mengubah organisasi menjadi perusahaan yang ramping-gesit. Hal ini dilakukan dengan mempelajari, mempraktikkan, dan mengajarkan pola pikir, nilai, prinsip, dan praktik Lean-Agile SAFe.

Nilai Inti SAFe memandu transformasi menuju perusahaan ramping. Di setiap kesempatan, perilaku seorang pemimpin memainkan peran penting dalam mempromosikan mereka. Nilai-nilai intinya adalah:

1. Alignment : Mengkomunikasikan misi, strategi portofolio, dan visi solusi. Melakukan pengarahan yang relevan, dan berpartisipasi dalam perencanaan program increment (PI) dan pemeliharaan backlog.

2. Transparansi : Visualisasikan semua pekerjaan yang relevan.

3. Kualitas bawaan : Terlibat dalam praktik untuk memberikan kualitas sepanjang siklus hidup. Menolak untuk menerima pekerjaan berkualitas rendah. Mendukung investasi dalam pemeliharaan dan mengurangi utang teknis.

4. Eksekusi program : Berpartisipasi sebagai pemilik bisnis dalam pelaksanaan PI dan membangun nilai bisnis. Pastikan bahwa cakupannya selaras dengan permintaan dan kapasitas. Singkirkan hambatan dan demotivasi secara agresif.

Nilai inti SAFe didukung dengan merangkul Pola Pikir Lean-Agile dan menerapkan Prinsip SAFe:

1. Ambil pandangan ekonomi

2. Terapkan pemikiran sistem

3. Asumsikan variabilitas; mempertahankan pilihan

4. Bangun secara bertahap dengan siklus pembelajaran terintegrasi yang cepat

5. Mendasarkan tonggak pencapaian pada evaluasi objektif sistem kerja

6. Visualisasikan dan batasi WIP, kurangi ukuran batch, dan kelola panjang antrian

   

7. Terapkan irama, sinkronkan dengan perencanaan lintas domain

8. Buka motivasi intrinsik pekerja pengetahuan

9. Desentralisasi pengambilan keputusan

Prinsip-prinsip ini mirip dengan prinsip Lean dan Agile. Terakhir, transformasi organisasi dilakukan dengan mengikuti Roadmap Implementasi SAFe.

Kompetensi Kelincahan Tim dan Teknis/Level Tim

Kompetensi Kelincahan Tim dan Teknis menjelaskan keterampilan, prinsip, dan praktik yang diperlukan untuk menciptakan tim gesit berkinerja tinggi yang menciptakan solusi berkualitas tinggi. Dua karakteristik utama sangat penting:

• Kelincahan tim: tim mengadopsi praktik dan prinsip Agile, yang memungkinkan mereka bekerja, belajar, dan beradaptasi dengan irama yang andal

• Kelincahan teknis : tim menerapkan praktik teknis Agile yang memastikan kualitas kode dan komponen, dan pemeliharaan kode yang mereka hasilkan\ Kualitas adalah fokus besar dalam tim dan kompetensi kelincahan teknis. Untuk mencapai hal ini, teknik rekayasa tangkas seperti Behavior Driven Development (BDD) dan Test-driven development (TDD) diterapkan untuk meningkatkan kualitas dan aliran. Aliran cepat bergantung pada kualitas bangunan di seluruh sistem karena kesalahan dapat sangat memengaruhi aliran dan menunda rilis.

Level Tim dari diagram SAFe menjelaskan bagaimana tim Agile individu beroperasi. Semua tim adalah bagian dari Agile Release Train yang bekerja untuk menghasilkan Peningkatan Produk. Sebagian besar aliran tangkas/scrum tradisional berlaku, di mana tim bekerja dalam iterasi untuk menghasilkan sistem kerja. Peran master scrum, pemilik produk, dan anggota tim digunakan di SAFe seperti halnya sebagian besar aktivitas dan artefak scrum. Tim juga didukung oleh peran tingkat program seperti Manajemen Produk, Arsitek Sistem, dan layanan bersama lainnya. Kanban digunakan untuk membantu memvisualisasikan aliran fitur melalui siklus hidup pengiriman dan interaksi serta penyerahan antar tim.

DevOps dan Rilis Sesuai Permintaan Tingkat Kompetensi/Program

Kompetensi DevOps dan Rilis sesuai Permintaan menjelaskan bagaimana “menerapkan DevOps dan saluran pengiriman berkelanjutan memberi perusahaan kemampuan untuk melepaskan nilai, secara keseluruhan atau sebagian, kapan pun diperlukan untuk memenuhi permintaan pasar dan pelanggan.”

DevOps bekerja untuk menyelaraskan pengembangan, operasi, bisnis, dan area lain untuk bekerja sama untuk memberikan hasil bisnis. Meskipun tidak setiap organisasi perlu merilis sesering beberapa pemimpin industri gerakan DevOps (Amazon rilis setiap beberapa detik), semua organisasi harus dapat merilis sesuai permintaan.

• DevOps menyediakan pendekatan budaya, otomatisasi, lean-flow, pengukuran, dan pemulihan (CALMR) yang memungkinkan pengiriman dan rilis berkelanjutan sesuai permintaan

• Kereta rilis tangkas (ART) adalah tim tim tangkas yang diatur untuk memberikan nilai sesuai permintaan melalui jalur pengiriman berkelanjutan

Tingkat Program dari diagram menggambarkan peran dan aktivitas yang diperlukan untuk terus disampaikan melalui Agile Release Train (ART) . Level ini bekerja dengan cara berulang yang mirip dengan level tim tetapi mengintegrasikan beberapa tim yang gesit dan mencakup lebih banyak siklus. ART adalah tim tangkas yang terdiri dari 5 hingga 12 tim (50 hingga 125 orang) termasuk peran tangkas tradisional serta peran program penting seperti Release Train Engineer (RTE) dan Manajemen Produk. ART memberikan Program Increments (PI) 8-12 minggu yang direncanakan melalui Perencanaan PI dan dipimpin oleh Manajer Produk .

Kemajuan fitur PI, epos, dll dilacak dan dikelola melalui papan Program Kanban. RTE bertindak sebagai Scrum Master pada ART. Rapat sinkronisasi harian mencakup Standup Harian tim, Scrum-of-Scrums (RTE & Scrum Masters), PO Sync (Manajemen Produk & Pemilik Produk), dan ART Sync (Scrum-of-Scrums dan PO Sync bersama-sama). Setiap PI memiliki Demo Sistem dan Retrospektif.

Solusi Bisnis dan Kompetensi Rekayasa Sistem Lean/Tingkat Solusi Besar

Solusi Bisnis dan Kompetensi Rekayasa Sistem Lean menjelaskan "bagaimana menerapkan prinsip dan praktik Lean-Agile ke spesifikasi, pengembangan, penerapan, dan evolusi aplikasi perangkat lunak yang besar dan kompleks serta sistem siber-fisik".

Selain prinsip SAFe, menerapkan 8 prinsip berikut saat mengerjakan solusi besar adalah kunci kompetensi ini:

Tingkat Solusi Besar berisi peran, artefak, dan proses yang diperlukan untuk membangun solusi besar dan kompleks. Beberapa ART bekerja sama di Solution Trains untuk memberikan Solusi . Tujuan utamanya adalah untuk:

• Kelola integrasi yang sering

• Terus menangani masalah kepatuhan

• Arsitek untuk skala, modularitas, releasability, dan serviceability

Manajemen Solusi mengontrol konten Solusi dan Solution Train Engineer (STE) memandu pekerjaan. Solution Architect bertanggung jawab untuk memelihara arsitektur yang baik untuk semua ART dalam Solusi. Perencanaan Pra dan Pasca PI digunakan untuk merencanakan Solusi yang disampaikan melalui beberapa Peningkatan Program. Solution Backlog berisi Kemampuan dan Solution Epics dan dilacak melalui papan Solution Kanban

Tingkat Portofolio/Kompetensi Manajemen Portofolio Ramping

Kompetensi Manajemen Portofolio Lean “menyelaraskan strategi dan eksekusi dengan menerapkan pendekatan Lean dan pemikiran sistem untuk strategi dan pendanaan investasi, operasi portofolio yang gesit, dan tata kelola.”

Manajemen Portofolio Lean berfokus pada bidang-bidang berikut:

1. Strategi dan pendanaan investasi: menghubungkan portofolio dengan strategi perusahaan, aliran nilai dana, dan menetapkan aliran portofolio

2. Operasi portofolio yang gesit: mengoordinasikan aliran nilai, mendukung pelaksanaan program, dan keunggulan operasional

3. Tata kelola yang ramping: memperkirakan anggaran, mengukur kinerja portofolio, dan menegakkan kepatuhan

Tingkat Portofolio berisi prinsip, praktik, dan peran yang diperlukan untuk memulai dan mengatur serangkaian Aliran Nilai pengembangan. Portofolio Backlog berisi Business Epics dan Enabler Epics dan dilacak melalui papan Portfolio Kanban*. **Lean Portfolio Management (LPM) memutuskan aliran nilai apa yang ada dalam portofolio dan mencakup pengambil keputusan tertinggi di perusahaan. Arsitek Perusahaan memandu pekerjaan dan berkoordinasi di seluruh Aliran Nilai.

Lebih sedikit

Kerangka scrum skala besar (LeSS) dibuat oleh Craig Larman dan Bas Vodde, yang mendasarkannya pada pengalaman mereka di industri keuangan dan telekomunikasi. Sesuai dengan namanya, LeSS mempromosikan proses dan prosedur sesedikit mungkin agar banyak tim Scrum dapat bekerja sama. Penskalaan sulit karena orang membuatnya rumit, jadi tujuannya di sini adalah membuatnya sesederhana mungkin.

Prinsip dan Komponen Utama

“LeSS adalah Scrum, diterapkan ke banyak tim, bekerja sama, pada satu produk”. LeSS didasarkan pada sepuluh prinsip yang akan tampak akrab bagi siapa saja yang akrab dengan prinsip-prinsip Lean-Agile:

1. Scrum Skala Besar adalah Scrum

2. Kontrol proses empiris

3. Transparansi

4. Lebih banyak dengan lebih sedikit

5. Fokus seluruh produk

6. Terpusat pada pelanggan

7. Perbaikan terus menerus menuju kesempurnaan

8. Sistem berpikir

9. Berpikir ramping

10. Teori antrian

LeSS hanya memiliki dua peran utama, keduanya dipinjam dari Scrum:

1. Pemilik produk: Bekerja dengan 2-8 tim.
2. Scrum master: Bekerja dengan 1-3 tim.

Semua tim bekerja dengan product backlog yang sama dalam sprint 1-4 minggu. Tim bekerja secara paralel, artinya mereka memulai dan mengakhiri sprint pada saat yang bersamaan. Di akhir sprint, tim secara kolektif memberikan peningkatan produk . Tampaknya hampir tidak mungkin bagi satu pemilik produk untuk bekerja dengan 8 tim. LeSS mempromosikan pemindahan tanggung jawab klarifikasi item backlog produk ke tim. Pada gilirannya, tim harus lintas fungsi dan tidak hanya berisi kompetensi pengkodean, desain, dan pengujian, tetapi juga pengetahuan domain bisnis. Lebih penting lagi, tim harus diberdayakan untuk dapat menjangkau pelanggan.

Perencanaan Sprint

Perencanaan dibagi menjadi dua bagian:

1. Perencanaan sprint 1: Di mana perwakilan tim bertemu dengan pemilik produk dan memutuskan item backlog mana yang akan mereka ambil dan mendiskusikan potensi kerjasama yang mungkin diperlukan antara tim selama sprint.
2. Perencanaan sprint 2: Sama seperti pada scrum tradisional, setiap tim berkumpul secara terpisah untuk membuat rencana bagaimana item-item backlog akan diselesaikan.

Penyempurnaan Backlog Produk

Product backlog refinement (PBR) dilakukan pada saat sprint untuk mempersiapkan item product backlog untuk perencanaan sprint. LeSS tidak menawarkan aturan bagaimana melakukan PBR dan menyerahkannya kepada perusahaan untuk mencari tahu sendiri proses yang paling efektif. PBR melibatkan tiga kegiatan utama:

1. Memisahkan barang-barang besar.
2. Merinci item sampai siap.
3. Memperkirakan.

Akhir Sprint

Di akhir setiap sprint, tiga hal terjadi:

1. Ulasan Sprint: Demo Sprint bersama, di mana tim dan pelanggan mengeksplorasi apa yang telah dilakukan selama Sprint dan apa yang harus dilakukan selanjutnya.
2. Retrospektif: Setiap tim mengadakan retrospeksi mereka sendiri untuk meningkatkan proses mereka.
3. Retrospektif keseluruhan: Tim, pemilik produk, dan master scrum berkumpul untuk memeriksa dan menyesuaikan praktik organisasi agar lebih efektif.

Scrum@Skala

Scrum at Scale dan Scrum@Scale digunakan secara bergantian. Metodologi ini diperkenalkan oleh Jeff Sutherland pada tahun 2014, yang menciptakan metodologi Scrum dan merupakan salah satu penandatangan Agile Manifesto.

Scrum@Scale menggunakan Scrum sebagai titik awalnya dan menawarkan kerangka kerja yang sederhana dan ringan untuk menskalakan Scrum dengan “birokrasi minimum yang layak”. Ini kurang preskriptif daripada metodologi tangkas skala lainnya dan dapat dianggap sebagai kerangka kerja meta. Ini menyoroti masalah dan area penskalaan dan menawarkan kerangka kerja mental tentang bagaimana mereka dapat ditangani.

Prinsip dan Komponen Utama

Scrum@Scale adalah kerangka kerja yang secara radikal menyederhanakan penskalaan dengan menggunakan Scrum untuk menskalakan Scrum. Di Scrum, "apa" (pemilik produk) jelas terpisah dari "bagaimana" (master scrum). Strategi yang sama digunakan di Scrum@Scale sehingga yurisdiksi dan akuntabilitas dipahami dengan baik, menghilangkan pemborosan dan konflik.

Scrum@Scale berisi dua siklus untuk memisahkan yurisdiksi dengan jelas: siklus Scrum Master dan siklus Pemilik Produk dengan dua titik kontak: Proses Tingkat Tim dan Umpan Balik Rilis Produk.

Siklus Master Scrum

Siklus master scrum bertanggung jawab atas bagaimana hal-hal yang diidentifikasi oleh siklus pemilik produk akan dibangun. Di Scrum@Scale, masing-masing tim Scrum memiliki peran, artefak, aktivitas, dan upacara yang sama dengan Scrum tradisional.

Tim Scrum dikelompokkan ke dalam Scrum of Scrums (SoS) yang bersama-sama bertanggung jawab untuk menghasilkan peningkatan produk bersama. Mereka berpartisipasi dalam perawatan dan penentuan prioritas backlog bersama, mengadakan retrospektif, mempertahankan backlog hambatan, dan mereka mengadakan Scaled Daily Scrum (SDS) (mirip formatnya dengan scrum harian) untuk mengoordinasikan tim dan menghilangkan hambatan. SDS dihadiri oleh setidaknya satu perwakilan (biasanya scrum master tim) dari masing-masing tim yang berpartisipasi dan dipimpin oleh Scrum of Scrums master (SoSM) yang bertanggung jawab untuk berkoordinasi dengan tim scrum dan pemilik produk.

Jika penskalaan lebih lanjut diperlukan, ada scrum of scrum of scrums (SoSoS) yang dibuat dari beberapa SoS yang juga akan bertemu setiap hari, dan seterusnya. Pemimpin keseluruhan adalah Executive Action Team (EAT) yang bertanggung jawab untuk mempromosikan Agile dalam organisasi, mengoordinasikan tim Scrum sesuai kebutuhan, dan menjadi pemberhentian terakhir untuk menghilangkan hambatan.

Siklus Pemilik Produk

Siklus Pemilik Produk bertanggung jawab atas produk atau layanan apa yang akan dibuat dan semua aktivitas yang diperlukan untuk mendukungnya. Pemilik Produk ditugaskan ke tim Scrum dan menjalankan semua aktivitas peran mereka seperti yang didefinisikan dalam Scrum. Pemilik produk dikelompokkan ke dalam Tim Pemilik Produk yang dipetakan ke tim SoS. Tim Pemilik Produk bertemu setiap hari di Meta Scrum untuk membahas strategi tingkat tinggi untuk tim, dan berkoordinasi sesuai kebutuhan dengan SoSM terkait dan pemilik produk serta pemangku kepentingan lainnya. Meta Scrum dipimpin oleh Chief Product Owner (CPO) .

Pemilik Produk menskalakan dengan cara yang mirip dengan siklus master scrum, tergantung pada ukuran organisasi dan memuncak dalam Executive Meta Scrum (EMT) , yang bertanggung jawab atas pengaturan prioritas di seluruh perusahaan.

Menerapkan Scrum@Scale

Implementasi Scrum@Scale dimulai dengan membuat model referensi yang dapat diskalakan, yaitu sekumpulan kecil tim yang menggunakan scrum dalam skala kecil. Hal ini dilakukan untuk menyelesaikan setiap kebijakan organisasi dan praktik pengembangan yang menghambat kelincahan. Scrum@Scale menyarankan untuk menyelesaikan ini lebih awal karena semua tim kemungkinan akan menghadapi masalah besar organisasi ini dan frustrasi yang diakibatkannya dapat menghambat penerapan agile. Model referensi kemudian digunakan sebagai pola untuk menskalakan scrum ke tim dan departemen lain.

Tim tindakan eksekutif (EAT) harus dibuat pada awalnya untuk mengimplementasikan model referensi. EAT terdiri dari individu-individu yang secara politik dan finansial diberdayakan dalam organisasi, karena mereka akan mampu menerapkan perubahan kebijakan organisasi.

Kesimpulan

Di bagian kedua dari cetak biru manajemen proyek ini, kami telah membahas beberapa kerangka kerja paling populer yang digunakan pada proyek atau program yang lebih besar. Waterfall masih banyak digunakan di banyak organisasi, dan meskipun memiliki banyak kelemahan karena prosesnya yang tidak fleksibel, terkadang masuk akal untuk menggunakan kerangka kerja ini ketika proyeknya kecil dan ruang lingkupnya terdefinisi dengan baik dan tidak mungkin berubah.

Ketika perusahaan menghadapi proyek yang lebih besar dan lebih kompleks dengan persyaratan atau tujuan yang terus berubah, mereka mencari pendekatan yang lebih Agile. Karena Agile awalnya ditujukan untuk tim kecil yang terdiri dari 5-9 orang, berbagai praktisi Agile telah hadir dengan berbagai cara untuk meningkatkan kelincahan dari tim tunggal, ke beberapa tim, hingga seluruh perusahaan. Dalam artikel ini, kami membahas Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), dan Scrum@Scale.

Di bagian akhir cetak biru manajemen proyek, kami akan membahas beberapa kerangka kerja khusus manajemen proyek seperti PMP (PMBOK) dan PRINCE2. Kami juga akan membahas beberapa proses dan kerangka kerja inovasi seperti "pekerjaan yang harus diselesaikan" (JTBD) dan "pemikiran desain".