Setelah menonton video ini, Anda akan dapat menjelaskan pendekatan Waterfall pada perangkat lunak
perkembangan.
Jelaskan masalah dengan pendekatan Waterfall, jelaskan pendekatan Extreme Programming, daftar
nilai pendekatan XP, tentukan Kanban,
dan daftar prinsip-prinsip intinya.
Jadi, mari kita lihat pengembangan Air Terjun tradisional.
Semuanya dimulai dengan fase persyaratan. Orang-orang mengumpulkan persyaratan, melihat
apa yang diinginkan pelanggan, memastikan bahwa kami akan memberikan sesuatu yang
keinginan pelanggan. Setidaknya untuk saat itu.
Jadi ini adalah fase di mana semua yang Anda lakukan adalah mendokumentasikan semua persyaratan dari
mungkin diinginkan pelanggan dalam sistem. Kemudian Anda beralih ke fase desain.
Perhatikan saya menggunakan istilah fase di sini.
Ini sangat penting, karena ada kriteria keluar dan kriteria masuk untuk pindah
dari satu fase ke fase lainnya.
Jadi setelah kami mendapatkan semua persyaratan, kami beralih ke desain, berharap kami memilikinya
semua persyaratan yang sebenarnya kita butuhkan.
Maka pada tahap desain, para arsitek sedang merancang. Mereka mencari tahu bagaimana caranya
kami mengambil persyaratan itu, mengubahnya menjadi perangkat lunak yang berfungsi, dan mereka mendesain keseluruhannya
sistem.
Dan kemudian setelah fase itu selesai, kita beralih ke fase pengkodean.
Jadi di sinilah para pengembang meretas hacking coding.
Sekarang, Anda akan melihat ini disebut Air Terjun dan panah-panah itu mengalir ke bawah.
karena sangat sulit untuk berenang ke atas air terjun.
Ini adalah nama yang sesuai.
Karena ketika Anda berada dalam fase pengkodean, dan Anda mengetahui, ini adalah desain yang buruk, tidak
bekerja, sangat sulit untuk kembali dan mendesain ulang sesuatu.
Faktanya, karena kami memperlakukan pengembangan perangkat lunak seperti proyek teknik sipil, terkadang
beberapa dari desainer tersebut telah pindah ke proyek berikutnya, dan Anda harus menemukannya.
Jadi sangat, sangat sulit untuk kembali dan berenang dengan air terjun.
Kemudian setelah coding, akhirnya kita bisa mengintegrasikan.
Jadi selama ini, kami mengkode secara terpisah, kami tidak mengintegrasikan modul saya dengan modul orang berikutnya
modul. Anda tahu, ada saatnya semua modul itu bersatu. Pertama kali
kami menyadari, apakah semua potongan kode ini bekerja bersama?
Dan kemudian kami beralih ke fase pengujian, karena sekarang kami memiliki sistem yang membuat orang
dapat menguji.
Dan ketika mereka menemukan serangga, mereka harus kembali, berenang ke air terjun, dan membuka beberapa serangga
dalam tahap coding dan melakukan beberapa recoding.
Dan kemudian jika salah satu bug yang mereka uji ternyata, Anda benar-benar perlu mengubahnya
desain karena hal-hal ini tidak berinteraksi dengan baik, jalan, naik ke air terjun, sangat mahal
untuk kembali ke tahap desain.
Dan akhirnya, setelah semua pengujian selesai, kami menerapkan perangkat lunak.
Jadi apa yang salah dengan pendekatan ini?
Yah, tidak ada ketentuan untuk perubahan.
Setiap fase memiliki kriteria masuk dan keluar.
Dan ketika satu berakhir, Anda tahu, yang berikutnya dimulai.
Dan tidak ada ketentuan untuk kembali dan mengubah desain atau mengubah persyaratan
atau apa pun seperti itu.
Jadi masalah lainnya adalah, Anda tidak tahu apakah itu berhasil sampai akhir, kan, tidak ada perantara
pengiriman. Tidak ada yang dikirim, sampai langkah terakhir itu, ketika kami memberikannya ke operasi
tim dan katakan, kirim barang ini ke produksi.
Yang lainnya adalah bahwa setiap langkah berakhir ketika langkah berikutnya dimulai, di situlah ia mendapatkan ini
nama air terjun, di mana hal-hal baru saja diturunkan.
Dan tentu saja, semua ini adalah kesempatan untuk kehilangan informasi, Anda tahu, dan untuk memiliki
kecelakaan terjadi atau orang diblokir, karena mereka tidak dapat menerima, Anda tahu, pekerjaan itu
dari fase sebelumnya.
Dan sekarang Anda sedang menunggu untuk memulai fase berikutnya.
Yang lainnya adalah bahwa kesalahan yang ditemukan di kemudian hari sangat, sangat mahal, sangat mahal untuk ditemukan
sesuatu yang dirancang salah dan menguji dan kembali dan mendesain ulang.
Dan akhirnya, ada waktu tunggu yang lama, tepat di antara mendapatkan perangkat lunak itu
terkirim. Sejak pertama kali Anda menginginkan perangkat lunak, dan Anda merancang perangkat lunak dan
mengkodekannya dan mengujinya.
Dan pada saat Anda akhirnya mengirimkannya dengan waktu yang sangat lama.
Jadi masalahnya di sini adalah tim bekerja secara terpisah, mereka tidak menyadari dampaknya satu sama lain.
Benar, desainer tidak menyadari dampak kode, pembuat kode tidak menyadarinya
dampak untuk mengintegrasikan semua kode bersama-sama.
Di sana semua orang bekerja di silo kecil mereka untuk fase kecil mereka.
Dan kemudian ini harus menjadi pemikiran yang menakutkan.
Orang-orang yang terjauh dari kode, tim operasi yang buruk, harus menjalankan ini
dan mengelola ini dalam produksi, kan?
Mereka tahu sedikit tentang kodenya, dan merekalah yang diharapkan untuk menjalankannya.
Tidak terlalu efisien.
Mari kita bicara tentang metodologi lain, pemrograman ekstrim.
Ini diperkenalkan kembali pada tahun 96.
Kent Beck memperkenalkan ini dan jika Anda melihat grafik di sebelah kanan, Anda akan melihatnya
itu sangat berulang dan berbicara tentang loop.
Anda memiliki rencana rilis utama ini di loop luar.
Dan kemudian Anda punya rencana iterasi.
Jadi rilis mungkin berbulan-bulan, iterasi mungkin berminggu-minggu,
penerimaan mungkin berhari-hari, berdiri rapat sekali sehari, benar, negosiasi pasangan dalam hitungan jam,
unit testing dalam hitungan menit, pasangkan prpgramming dalam hitungan detik.
Anda tahu, ini adalah putaran yang semakin ketat dalam melakukan pekerjaan dan kemudian mendapatkan umpan balik yang cepat.
Ini didasarkan pada pendekatan berulang untuk pengembangan perangkat lunak.
Dan faktanya, dari sinilah Agile mendapatkannya.
Dan maksud di sini adalah untuk meningkatkan kualitas perangkat lunak, bukan? Jadilah responsif terhadap perubahan, jadilah
responsif terhadap kebutuhan pelanggan, melakukan hal-hal sedikit demi sedikit.
Dan begitu banyak orang mengenali Extreme Program sebagai salah satu metode Agile pertama.
Jadi mari kita bicara tentang nilai Extreme Programming.
Pertama adalah kesederhanaan, bukan?
Lakukan apa yang Anda butuhkan
dan tidak lebih, jangan over-engineer, jangan over code, jangan memberikan kode lebih dari pelanggan
diminta.
Tetap sederhana, sangat penting.
Selanjutnya adalah komunikasi.
Semua orang di tim harus berkomunikasi, tahu apa yang dilakukan orang lain, itu mendorong
banyak, banyak komunikasi, dan orang-orang berinteraksi. Sangat penting juga.
Dan kemudian umpan balik, Anda tidak tahu apa yang Anda lakukan kecuali Anda mendapatkan umpan balik.
Jadi memiliki loop umpan balik itu sangat penting untuk pemrograman ekstrem, dan penting untuk Agile
secara umum.
Dan kemudian rasa hormat, semua orang merasa bahwa mereka dihormati di tim, yang dapat mereka tawarkan
saran bahwa mereka dapat membuat saran, dan saran mereka sama berharganya
sebagai saran orang lain di tim.
Tidak ada hierarki, setiap orang memiliki rekan kerja di tim, dan dihormati karena ide-ide mereka.
Dan akhirnya, keberanian, benar, kami tidak menghitung perkiraan kami, kami hanya sangat jujur
tentang kami pikir kami bisa melakukan ini
Dan kami tidak berpikir kami bisa melakukan itu.
Dan kami tidak akan berbohong kepada Anda bahwa kami tahu, kami bisa menyelesaikan ini, ini selesai dalam hal ini
jumlah waktu.
Kami sangat terbuka dan jujur ​​dalam Extreme Programming, ini perkiraannya, ini yang akan kami komit
ke.
Selanjutnya, ada Kanban.
Ini berasal dari sistem manufaktur Jepang.
Dan kanban secara harfiah berarti tanda papan reklame, dan ini semua tentang aliran terus menerus di
lantai manufaktur, di mana kartu atau catatan ini akan mengalir dengan produk dari stasiun
ke stasiun, turun jalur.
Jadi prinsip inti dengan Kanban adalah memvisualisasikan alur kerja.
Jika Anda tidak dapat melihat pekerjaan tersebut, Anda tidak dapat mengelola pekerjaan tersebut.
Dan ini adalah sesuatu yang kita ambil ke Agile juga. Anda akan mengetahui bahwa kami akan pergi
untuk menggunakan papan Kanban dan Agile.
Dan ini semua tentang memvisualisasikan pekerjaan, sangat penting bahwa Anda dapat memahami pekerjaan itu
yang perlu dilakukan, dan semuanya dipertanggungjawabkan. Kanban juga menekankan batasi pekerjaan di
kemajuan. Anda tidak ingin, ketika Anda berada di lantai produksi, Anda tidak ingin pekerjaan dicadangkan di satu tempat
dari stasiun.
Tetapi bahkan ketika Anda sedang mengembangkan perangkat lunak, Anda tidak ingin orang lain mengerjakannya juga
banyak hal sekaligus.
Karena, Anda tahu, Anda hanya dapat mengirimkan 100% dari satu hal yang berfungsi, Anda tidak dapat mengirim
50% dari dua hal.
Jadi jika Anda membuat satu orang mengerjakan dua hal, itu tidak baik.
Dan itu berasal dari Kanban untuk membatasi pekerjaan yang sedang berlangsung.
Lalu ada mengelola dan meningkatkan aliran. Di Kanban, mereka selalu ingin berkembang.
Mereka selalu ingin berubah dan mengerti bagaimana kita bisa mendapatkan aliran yang lebih baik, aliran yang lebih cepat
di lantai produksi, dan kemudian membuat kebijakan eksplisit, sehingga semua orang mengerti
bagaimana hal-hal bekerja.
Dan semua orang mengerti definisi "selesai", apa artinya memiliki sesuatu?
"selesai." Kami mengambil itu juga dari Kanban dalam perencanaan Agile kami untuk memahami apa definisinya
dari "selesai" adalah.
Dan kemudian terus ditingkatkan, sangat, sangat penting untuk mendapatkan umpan balik dan terus menerus
meningkatkan apa yang Anda lakukan.
Jadi Kanban adalah tentang membuat alur bekerja lebih baik, memahaminya, melihatnya,
mampu mengukurnya, dan kemudian terus meningkatkan bagaimana kita bisa mengalir lebih cepat.
Dalam video ini, Anda mempelajari bahwa pendekatan Waterfall tradisional Anda untuk pengembangan perangkat lunak
adalah proses langkah-demi-langkah yang terstruktur yang dapat menyebabkan masalah yang tidak muncul sampai nanti
dalam pengembangan.
Pemrograman ekstrim dikembangkan untuk meningkatkan kualitas perangkat lunak dan responsif terhadap perubahan
persyaratan.
Nilai XP meliputi kesederhanaan, komunikasi, umpan balik, rasa hormat, dan keberanian.
Kanban adalah sistem yang dicirikan dengan memvisualisasikan alur kerja, membatasi pekerjaan yang sedang berjalan, mengelola
dan meningkatkan aliran, membuat kebijakan proses eksplisit dan terus meningkatkan proses.