"Jadi, saya ingin memberi tahu Anda tentang Agile dan Scrum ."
"Pada awal abad ke-21, cara berpikir orang tentang pemrograman terbalik."
"Semua orang yakin bahwa perencanaan jangka panjang tidak berhasil, jadi mereka memutuskan untuk mengabaikannya sama sekali."
"Bagaimana mereka melakukannya?"
"Begini caranya."
"Mereka menemukan pendekatan manajemen proyek yang paling fleksibel."
Inilah ide utama di balik pengembangan tangkas :"
- orang dan komunikasi lebih penting daripada proses dan alat;
- produk yang berfungsi lebih penting daripada dokumentasi lengkap;
- berkolaborasi dengan pelanggan lebih penting daripada memenuhi persyaratan kontrak;
- kesediaan untuk berubah lebih penting daripada berpegang teguh pada rencana awal.
Berikut adalah prinsip perkembangan pesat:
- memuaskan pelanggan dengan menyediakan perangkat lunak yang berharga sejak awal dan terus menerus;
- menyambut baik perubahan persyaratan bahkan di akhir pengembangan (ini dapat meningkatkan daya saing produk akhir);
- sering mengirimkan perangkat lunak yang berfungsi (setiap bulan atau minggu atau lebih sering);
- tutup komunikasi harian antara pelanggan dan pengembang di seluruh proyek;
- proyek dikerjakan oleh individu-individu termotivasi yang diberikan kondisi kerja, dukungan, dan kepercayaan yang diperlukan;
- metode yang disukai untuk mengomunikasikan informasi adalah percakapan pribadi (tatap muka);
- perangkat lunak yang berfungsi adalah ukuran kemajuan terbaik;
- sponsor, pengembang, dan pengguna harus dapat mempertahankan kecepatan konstan untuk waktu yang tidak terbatas;
- fokus konstan pada peningkatan keunggulan teknis dan desain yang ramah pengguna;
- kesederhanaan adalah seni untuk tidak melakukan pekerjaan yang berlebihan;
- persyaratan teknis, desain, dan arsitektur terbaik berasal dari tim yang mengatur dirinya sendiri;
- adaptasi terus-menerus terhadap keadaan yang berubah.
"Masalah utama dengan pengembangan perangkat lunak adalah bahwa pada setiap tahap tidak ada peserta yang memiliki informasi lengkap tentang apa yang harus dilakukan."
"Pelanggan dapat memberi tahu Anda bagaimana dia membayangkan program tersebut, tetapi dia akan meninggalkan sesuatu atau menerima sesuatu begitu saja."
"Manajer umumnya harus menerjemahkan persyaratan dari jargon pemrograman ke bahasa pelanggan dan kembali lagi."
"Terlalu banyak ketidakpastian."
"Seringkali persyaratan pelanggan seperti ini: lakukan dengan cara tertentu, lalu tunjukkan kepada saya - jika saya tidak menyukainya, Anda dapat mengulanginya."
"Eh ... itu mengerikan."
"Menurut paradigma baru, pemrogram tidak lagi mengembangkan produk atau program. Sebaliknya, mereka mengimplementasikan fungsionalitas yang dibutuhkan pelanggan."
"Apa bedanya?"
"Nah, misalkan dulu pengembangan program memakan waktu satu tahun. Dan enam bulan harus berlalu sebelum ada sesuatu untuk dilihat. Ini seperti membangun sebuah rumah besar: pertama, Anda menggali lubang untuk pondasi, kemudian menuangkan pondasi, membangun dinding, atap, trim, dll."
"Tapi sekarang pemrogram mencoba merilis fungsionalitas yang dibutuhkan sesegera mungkin. Ini seperti pertama membangun gubuk, lalu rumah mobil, lalu rumah kecil, dan baru kemudian rumah besar — dengan mencicil."
"Mengingat pelanggan mungkin tidak tahu persis apa yang diinginkannya, maka ini adalah pendekatan yang sangat masuk akal."
"Misalkan pelanggan menginginkan pondok berburu yang besar."
"Para pengembang membangunnya yang kecil. Dia tinggal di dalamnya selama musim dingin. Kemudian dia memutuskan bahwa dia tidak menyukai rumah kayu. Mari kita buat yang terbuat dari batu bata."
"Dia tinggal di dekat danau selama musim panas, tetapi nyamuk memakannya hidup-hidup. Dia pernah mendengar di suatu tempat bahwa danau itu sejuk, jadi dia ingin memilikinya. Tapi sekarang dia tidak menginginkan danau. Dan akan lebih mudah untuk membangunnya." rumah seperti ini: tidak ada danau berarti tidak ada ancaman banjir, dan Anda dapat membangun rumah di atas tanah daripada di atas panggung, yang akan 25% lebih cepat."
"Sebuah analogi yang menarik. Apakah pelanggan benar-benar sering mengubah kebutuhan mereka?"
"Ya, tapi masalahnya bukan pada pelanggan."
"Pertama, sangat sulit untuk membayangkan bagaimana hal-hal yang akan terjadi di masa depan. Manajer, penguji, dan pemrogram juga melakukan hal ini. Mereka juga berubah pikiran bergantung pada bagaimana keadaan berjalan."
"Kedua, bukankah kebutuhan pelanggan adalah hal yang paling penting? Lagi pula , tujuan dari semua pekerjaan ini adalah untuk menciptakan apa yang dibutuhkan pelanggan , bukan apa yang awalnya dia katakan untuk diciptakan ."
"Memang, dulu bekerja seperti ini: analis bisnis akan membuat daftar semua persyaratan. Mereka akan memasukkan daftar ini ke dalam kontrak, menandatanganinya, dan bekerja hanya sesuai dengan daftar."
"Jika daftar itu kehilangan sesuatu yang benar-benar dibutuhkan pelanggan tetapi telah dilupakan, tidak ada yang akan melakukan apa-apa."
"Begitu. Lebih mudah mengikuti rencana, tapi tidak semuanya bisa dilakukan sesuai rencana!"
"Tepat."
"Itulah mengapa metode pengembangan tangkas diciptakan."
"Dan hari ini saya akan memberi tahu Anda tentang Scrum — yang paling populer di antara mereka.
"Fitur utama Scrum adalah pembagian pengembangan proyek menjadi iterasi kecil — biasanya selama 2-4 minggu. Setiap iterasi disebut sprint."
"Di awal sprint, diadakan rapat perencanaan sprint. Berlangsung 3-4 jam."
"Pada akhirnya, ada demonstrasi dari semua tugas yang sudah selesai."
"Begini biasanya semuanya bekerja:"
"Sebelum sprint pertama, pelanggan (atau perwakilan pelanggan) membuat daftar persyaratan, yaitu kumpulan hal-hal yang harus dapat dilakukan oleh program. Persyaratan ini biasanya disebut cerita pengguna, dan pelanggan biasanya disebut pemilik produk ."
"Dia disebut pemilik produk , karena produk itu ditulis untuknya. Dia, dan dia sendiri, yang menentukan daftar persyaratan - apa, kapan, dan dalam urutan apa."
"Selain itu, pemilik produk biasanya menetapkan prioritas tugas. Tugas dengan prioritas tertinggi akan diimplementasikan terlebih dahulu. Seluruh daftar persyaratan disebut juga product backlog ."
"Saat sprint dimulai, semua orang berkumpul untuk rapat. Scrum master , biasanya anggota tim, biasanya memimpin rapat. Tujuan rapat adalah memilih tugas ( cerita pengguna ) untuk sprint saat ini (iterasi pengembangan). "
"Pertama, tim menetapkan perkiraan kasar untuk setiap tugas dalam hari kerja abstrak, juga dikenal sebagai poin cerita. Kemudian tim memutuskan berapa banyak tugas yang akan mereka selesaikan selama sprint."
"Sekali lagi, tim itu sendiri yang memutuskan berapa banyak tugas yang akan mereka selesaikan selama sprint."
Katakanlah pemilik produk mengharapkan tim untuk memilih 7 tugas pertama tetapi hanya memilih 5, lalu tugas 6 dan 7 ditunda ke sprint berikutnya. Jika itu tidak sesuai dengan pemilik produk , dia dapat menaikkan prioritas tugas 6 dan 7 untuk memastikan bahwa mereka dipilih, tetapi kemudian beberapa tugas lainnya akan dikeluarkan dari sprint."
" Scrum master juga dapat mengusulkan untuk memecah beberapa tugas menjadi tugas yang lebih kecil dan menetapkan prioritas yang berbeda untuk membuat pemilik produk sebahagia mungkin."
"Itulah inti dari pertemuan itu: tugas dapat diubah dan dibagi, prioritas dapat diubah, dll. Ini adalah pekerjaan yang tidak terlihat pada awalnya, tetapi membawa banyak nilai."
"Mengerti. Ini seperti mengendarai mobil. Bahkan jika awalnya Anda percaya bahwa Anda hanya perlu jalan lurus, kenyataannya adalah Anda harus terus-menerus menghindari lubang, menyetir ke kanan dan kiri, dan melewati orang lain atau membiarkan mereka melewati Anda."
"Ya, sesuatu seperti itu."
"Daftar tugas yang dipilih untuk sprint disebut sprint backlog ."
"Para programmer memutuskan siapa yang akan melakukan apa, dan baru setelah itu mereka mulai bekerja." akan dilakukan hari ini."
"Kerja tim. Saya bisa menghargai itu!"
"Agar lebih mudah divisualisasikan, biasanya disarankan untuk menampilkan status sprint saat ini di papan khusus:"
"Perhatikan tiga kolom di sebelah kiri."
"Nama tugas yang disingkat ditulis pada catatan tempel. Dan catatan tempel ditempatkan di kolom yang berbeda tergantung pada statusnya (direncanakan, sedang berlangsung, selesai)."
"Di sebelah kanan, Anda dapat melihat bagan burndown . Untuk setiap hari, bagan ini mencantumkan tugas yang masih belum diselesaikan. Idealnya, jumlah tugas yang belum diselesaikan turun menjadi nol selama sprint."
"Saat sprint selesai, scrum-master memberikan demo untuk menunjukkan daftar semua yang telah diselesaikan sepenuhnya."
"Kemudian dia mengadakan pertemuan sprint retrospective , yang juga berlangsung beberapa jam. Selama pertemuan ini, para peserta biasanya mencoba mencari tahu apa yang berjalan dengan baik dan apa (dan bagaimana) hal-hal yang bisa dilakukan dengan lebih baik."
"Biasanya setelah 2-3 sprint, Anda dapat mengidentifikasi dan menghilangkan masalah utama yang membuat tim tidak bekerja lebih efisien. Hal ini menghasilkan produktivitas yang lebih besar tanpa menambah beban kerja tim. Ini tidak mungkin dilakukan sebelum era metodologi tangkas. "
“Terkadang juga diadakan grooming meeting selama sprint. Tujuannya adalah untuk merencanakan sprint berikutnya. Peserta biasanya mengklarifikasi prioritas tugas dalam rapat ini. Mereka juga dapat membagi beberapa tugas menjadi beberapa bagian dan/atau menambahkan tugas baru ke product backlog . ”
"Yah, pada dasarnya hanya itu yang saya miliki. Ini hanya gambaran umum. Tidak mungkin menjelaskan semuanya hanya dalam beberapa kata, tetapi Anda dapat membaca artikel bagus tentang masalah ini di sini:"
https://en.wikipedia.org/wiki/Scrum_(pengembangan perangkat lunak)
GO TO FULL VERSION