Setelah menonton video ini, Anda akan dapat membuat daftar lima praktik kerja Agile,
jelaskan bekerja dalam batch kecil, tentukan produk minimum yang layak, pahami perilaku
pengembangan yang didorong, memahami pengembangan yang didorong oleh pengujian, menjelaskan cara kerja pemrograman berpasangan.
Jadi mari kita lihat apa artinya bekerja dengan gaya Agile. Pertama, Anda ingin bekerja di
batch kecil. Kami mendapatkan ini dari lean manufacturing. Anda tidak ingin membuat sesuatu dalam jumlah besar
dan kemudian mengetahui bahwa Anda melakukannya salah karena itu banyak pemborosan harus kembali dan berubah
dia. Selanjutnya, Anda ingin menggunakan produk minimum yang layak untuk mencari tahu apa yang disukai pelanggan, apa
tidak disukai pelanggan. Dan kemudian Anda ingin menggunakan praktik seperti pengembangan yang didorong oleh perilaku
dan pengembangan yang didorong oleh pengujian untuk meningkatkan pengujian sistem Anda dari luar ke dalam dan
dari dalam keluar. Dan akhirnya Anda ingin memanfaatkan pemrograman berpasangan. Ini datang
dari pemrograman ekstrim tetapi pemrograman pasangan sangat penting. Jadi kita akan melihat
masing-masing secara bergantian. Bekerja dalam kelompok kecil-- misalkan saya perlu mengirimkan ribuan brosur.
Dan langkah-langkahnya yaitu anda perlu melipat brosur kemudian memasukkan brosur tersebut ke dalam amplop,
dan kemudian segel amplop dan akhirnya cap amplop dengan perangko.
Jadi katakanlah kita akan melakukan ribuan ini dalam kelompok 50, benar, kelompok besar, 50 buah dan
asumsikan bahwa setiap langkah membutuhkan waktu sekitar enam detik untuk diselesaikan. Jadi saya bisa melakukan sekitar 10 langkah per menit.
Dan jadi kita melakukan langkah pertama melipat, kan? Dan pada jam 10 selama satu menit, saya membutuhkan waktu sekitar lima menit untuk
lipat 50 dari mereka. Kemudian saya melanjutkan ke langkah berikutnya. Langkah selanjutnya adalah memasukkan semuanya dan lagi,
jika saya bisa melakukan sekitar 10 dari mereka per menit, jadi saya butuh lima menit lagi, ditambah lima
menit dari sebelumnya. Sekarang aku 10 menit ke dalamnya. Saya sudah melipat semuanya dan memasukkannya lalu saya
lanjutkan ke langkah ketiga untuk menyegel semuanya, kan? Jadi sekarang lagi sekitar 10 per menit saya bisa melakukan yang lain
50 dalam lima menit lagi. Jadi saya sampai 15 menit, kan? Waktu jam dinding. Lalu
akhirnya saya sampai ke langkah empat dan saya butuh 16 menit untuk mendapatkan produk jadi pertama saya kan?
Yang pertama di mana saya memiliki barang-barang yang benar-benar dapat saya periksa dan lihat kualitasnya.
Jadi, bagaimana jika amplop tidak memiliki lem, kan? Itu akan menjadi 11 menit sebelum saya mengetahuinya
ada yang salah. Bagaimana jika ada kesalahan ketik pada brosur? Aku harus pergi jauh-jauh kembali
ke awal, kan? Jadi, ini sangat, sangat boros bekerja dalam batch besar seperti ini.
Sekarang mari kita lihat contoh yang sama dengan aliran satu bagian. Dan lagi, asumsikan setiap langkah membutuhkan waktu
enam detik untuk menyelesaikan. Dengan aliran sepotong tunggal, saya lipat, kan? Dan masukkan ke dalam amplop dan
segel mereka dan beri cap pada mereka dan produk jadi pertama dalam waktu sekitar 24 detik. Sekarang saya
dapat memeriksanya untuk melihat apakah itu berfungsi, melihat apakah itu yang saya pikirkan, dan kemudian biarkan sisanya mengalir
meninggal dunia. Sekarang bagaimana jika amplop tidak memiliki lem? Yah aku akan mencari tahu setelah, eh, mungkin 18 detik, kan?
Dan jika ada kesalahan ketik di brosur, setelah 24 detik, jadi sangat, sangat penting bahwa kita tidak
bekerja dalam dua kelompok yang lebih besar sehingga kami bisa mendapatkan umpan balik yang cepat dan kami dapat berputar dan memahami,
Anda tahu, apakah kita perlu melakukan sesuatu yang berbeda dan kemudian membuat perubahan yang perlu kita lakukan?
Jadi mari kita bicara tentang produk yang layak minimum. Pertama, mari kita pahami apa yang bukan, karena ada
kesalahpahaman bahwa produk yang layak minimum seperti fase pertama dari proyek atau, Anda tahu,
beta pertama atau sesuatu seperti itu. Dan itu tidak. Ini bukan produk minimum yang layak.
Produk minimum yang layak adalah hal minimal yang dapat Anda lakukan untuk membuktikan hipotesis dan keuntungan
belajar dan mendapatkan pemahaman. Perbedaan antara keduanya adalah bahwa yang pertama adalah segalanya
tentang pengiriman, kan? Apa yang akan saya sampaikan? Tapi yang kedua adalah tentang
sedang belajar. Apa yang bisa saya pelajari? Apa yang bisa saya pelajari dari mengeluarkan MVP ini dan mendapatkan umpan balik
dan kemudian mungkin membuat yang berikutnya lebih baik? Jadi, penting bahwa di akhir setiap MVP
Anda memutuskan apakah akan berputar atau bertahan. Mari kita lihat sebuah contoh. Inilah tim yang sedang berkembang
produk minimum yang layak untuk pelanggan yang menginginkan mobil. Jadi, pada iterasi pertama, mereka memberikan
roda. Pelanggan seperti, "Apa yang akan saya lakukan dengan roda? Saya tidak dapat melakukan apa pun dengan ini?" Suka,
baik, kami sedang mengerjakan iterasi, kami mencoba untuk gesit di sini, bukan? Dan pada iterasi berikutnya, kita akan
memberi Anda beberapa lagi. Dan mereka memberi mereka sasis dan itu seperti, oke, "Saya benar-benar tidak bisa melakukan apa-apa
dengan ini." Dan akhirnya, Anda tahu, mereka memberi mereka mobil tanpa roda kemudi dan kemudian
akhirnya mereka mendapatkan mobil, kan? Dan mereka mendapatkan coupe ini. Tim itu tidak mengerti
bagaimana membuat produk yang layak minimum. Mereka hanya melakukan pengembangan berulang.
Tim kedua memahami nilai dari pembuatan MVP. Pada awalnya, mereka memberi mereka
skateboard dan pelanggan seperti, "Saya meminta mobil dan Anda memberi saya skateboard."
Whoa, whoa kita sedang menguji warnanya. Bagaimana Anda menyukai warna merah itu? Apakah itu warna yang Anda inginkan? "Oh ya,
merah agak keren tapi Anda tahu itu sangat sulit untuk dikemudikan." Tidak, kami akan memperbaikinya di MVP berikutnya dan
kemudian mereka menambahkan cara untuk mengarahkannya dan pelanggan seperti, "Baiklah, Anda memang memberi saya cara untuk mengarahkannya
tapi aku tidak bisa pergi terlalu cepat. Saya membutuhkan bentuk penggerak yang lebih baik." Dan kemudian kita akan mengatasinya dalam
MVP berikutnya. Pada iterasi berikutnya, mereka memberi mereka pedal. Di suatu tempat di sepanjang jalan sementara pelanggan
sedang mengendarai sepeda motor itu merasakan angin menerpa rambut mereka, mereka memutuskan, "Saya ingin sebuah mobil konvertibel." Dalam
contoh pertama, pelanggan mendapatkan persis apa yang mereka minta berbulan-bulan sebelumnya karena mereka hanya
mengikuti rencana tetapi dalam contoh kedua pelanggan mendapatkan apa yang mereka inginkan
karena mereka bekerja secara interaktif dengan tim pengembangan dan pada akhirnya, Anda berkembang
sesuatu yang sedikit berbeda tetapi lebih dekat dengan apa yang benar-benar diinginkan pelanggan.
Perkembangan yang didorong oleh perilaku adalah ketika kita menggambarkan sistem dari luar ke dalam. Ini biasanya
dilakukan pada tingkat pengujian integrasi, bukan? Jadi, di sinilah kami mengambil pelanggan
tampilan sistem biasanya saat Anda melakukan pengujian BDD, Anda melakukannya terhadap antarmuka pengguna,
Baik? Anda melakukannya terhadap hal yang dilihat pelanggan untuk melihat apakah sistem berperilaku
cara yang seharusnya. Jadi, jika itu adalah sistem e-commerce, ketika saya memasukkan sesuatu ke keranjang saya, apakah itu?
berperilaku seperti yang saya inginkan? Ketika saya mentransfer keranjang ke pesanan, apakah itu berperilaku seperti yang saya inginkan? Dia
benar-benar mengambil pendekatan luar-dalam. Itu tidak terlalu peduli dengan hal-hal yang terjadi di bawahnya.
Yang keren adalah ia menggunakan satu sintaks yang dapat digunakan oleh pengembang dan pemangku kepentingan
digunakan untuk menggambarkan sistem dan menyepakati perilaku sistem, tentang apa yang dilakukan sistem.
Jadi, mari kita lihat sintaks itu. Ini dimulai dengan skenario fitur BDD ini. Dimana saya katakan,
"Sebagai jumlah peran, jadi, saya ingin tahu untuk siapa ini. Saya perlu beberapa fungsi, kan? Jadi apa itu
itu fungsi yang sebenarnya kita butuhkan agar saya mendapatkan nilai bisnis?" Jadi, sekarang Anda tahu
Untuk siapa ini. Apakah untuk pelanggan? Untuk administrator sistem, bukan? Siapa yang mendapatkan
nilai dari ini apa yang mereka butuhkan dan mengapa mereka membutuhkannya? Dan itulah awal dari Anda
file fitur. Dan kemudian Anda mulai menjalankan skenario dan di sinilah kami menggunakan hal umum ini
sintaksis. Ini dikenal sebagai sintaks Gherkin setelah acar Gherkin. Dan itu berjalan seperti ini:
Diberi serangkaian prasyarat, bukan? Jadi, skenario seperti itu-- mengingat ini benar.
Saya punya dua item di keranjang saya. Saya mendapat tiga item yang saya pesan, terserah. Ketika suatu peristiwa terjadi,
Baik? Jadi, itulah hal yang sedang diuji. Maka saya harus melihat beberapa hasil yang dapat diamati. Jadi, menggunakan ini
diberikan sintaks kapan-maka, pengembang dapat memahaminya, pemangku kepentingan dapat memahaminya, semua orang dapat
pahami sintaks umum ini bahwa ketika saya memiliki sesuatu di troli saya dan kemudian saya menghapus troli saya, Anda
tahu, saya seharusnya tidak melihat apa pun di keranjang saya. Jadi sangat, sangat penting untuk memiliki sintaks dalam BDD ini
skenario. Pengembangan yang didorong oleh pengujian adalah pengujian sistem dari dalam ke luar. Tidak seperti yang didorong oleh perilaku
perkembangan. Hal ini berkaitan dengan internal sistem, modul tunggal. Biasanya ini
disebut pengujian unit, bukan? Dan ini adalah sesuatu yang didorong oleh kasus uji unit dan kami ingin membuatnya
yakin bahwa dengan input ini saya mendapatkan output ini pada level modul kecil. Saya tidak tahu apakah ketika saya menempatkan
mereka semua bersama-sama saya akan mendapatkan perilaku yang saya inginkan. Itu semacam BDD tapi untuk TDD, test drive
pengembangan, saya hanya menguji sistem di tingkat unit dan Anda menulis tes
kasus pertama untuk kode yang Anda inginkan dan kemudian Anda menulis kode yang cukup untuk membuat kasus uji itu lulus
dan kemudian Anda mulai dari awal lagi dan refactor. Jadi alur kerjanya berjalan seperti ini:
Saya menulis kasus uji. Anda mungkin berkata, "Anda menulis kasus uji sebelum Anda menulis kode?" Ya ini membuat saya
ditampilkan pada apa yang seharusnya dilakukan kode. Ketika saya memanggil ini, bagaimana saya ingin memanggil ini? apa itu?
parameter yang saya pikir ingin saya sampaikan dan lalu apa fungsinya untuk saya? Jadi, Anda menulis test case terlebih dahulu
kemudian Anda menulis kode yang cukup untuk membuat kasus uji itu lulus dan kemudian setelah lulus maka Anda dapat melakukan refactor
kode karena sekarang Anda memiliki kasus uji untuk membuat Anda jujur, Anda akan tahu jika Anda melanggar sesuatu.
Sekarang, karena ketika test case berjalan dan gagal biasanya berubah menjadi merah dan kemudian ketika berhasil
benar berubah menjadi hijau; kita cenderung menyebutnya Merah, Hijau, Refactor. Tonton test case, tulis test case
menontonnya gagal, buat saja cukup tulis kode untuk membuatnya lulus, dan kemudian refactor membuatnya-- Anda mungkin tidak
telah membuatnya sangat elegan hanya untuk membuatnya lulus-- sekarang Anda dapat kembali dan Anda dapat menambahkan segala macam
pemeriksaan kesalahan dan yang lainnya membuatnya sedikit lebih, eh, kuat dan kemudian jalankan kasus uji. Memastikan
Anda tidak merusak apa pun. Pemrograman berpasangan. Pemrograman pasangan, Anda mungkin mengatakan dua pemrogram bekerja
bersama-sama pada hal yang sama, eh, dan hal pertama adalah: Saya membayar dua orang untuk melakukan satu pekerjaan?
Tetapi sebenarnya itu berhasil dengan sangat baik karena apa yang Anda lakukan adalah Anda memilikinya
orang yang menulis kode dan kemudian Anda memiliki orang lain yang memperhatikan kode tersebut.
Jadi pertanyaannya adalah, apakah Anda lebih suka menemukan bug dalam produksi? Apakah Anda lebih suka menemukan bug saat Anda?
menulis kode? Jauh lebih murah untuk menemukannya saat Anda sedang menulis kode, jadi miliki dua set
mata, mereka memeriksa satu sama lain dan mereka bolak-balik. Bukan hanya satu dan kemudian yang lain.
Biasanya dalam 20 menit bertahap, kan? Seseorang menulis kode, yang lain sedang menonton dan mereka
tidak hanya menonton. Terkadang mereka mencari sesuatu, terkadang mereka berdiskusi. "Bagaimana menurutmu
Saya harus memanggil variabel ini? Menurut Anda apa yang harus saya sebut fungsi ini?" Benar? Ini dua set
pikiran bekerja di sekitar kode ini dan apa yang terjadi adalah Anda benar-benar mendapatkan kode kualitas yang lebih tinggi di akhir
hari, kan? Kualitas kode naik karena dua orang sudah memeriksanya dan kapan
Anda berkata, "Saya tidak mampu membayar dua orang untuk menulis satu kode." Anda tidak mampu untuk tidak membayar dua
orang untuk menulisnya karena menulis kode adalah bagian yang murah. Debugging itu, mempertahankan dalam produksi,
itu bagian yang mahal dan jadi jika Anda ingin bagian yang mahal menjadi lebih murah, Anda ingin memilikinya
programmer Anda melakukan pemrograman berpasangan. Ini juga sangat bagus untuk menempatkan programmer senior dengan junior
programmer. Sekarang programmer junior dapat melihat: Bagaimana programmer senior mendekati masalah?
Jadi mereka belajar, mereka mendapatkan bimbingan, dan kemudian program senior dapat melihat bagaimana orang junior
sedang bermesraan. Atau Anda mendapatkan orang yang tidak terbiasa dengan kode yang bekerja dengan seseorang yang. Kamu sekarang
buat lebih banyak orang mempelajari kode karena mereka dan mereka mendapatkan seperti tutorial dari
orang lain. Jadi pemrograman berpasangan adalah cara yang sangat, sangat bagus untuk membawa semua orang Anda aktif
tim Anda hingga level tertentu. Dalam video ini Anda belajar bahwa bekerja dalam kelompok kecil berarti
memberikan sesuatu yang berguna dengan cepat, MVP adalah hal termurah dan termudah yang dapat Anda lakukan untuk menguji
hipotesis dan belajar. Pengembangan yang didorong oleh perilaku memastikan Anda membangun hal yang benar.
Dan pengembangan yang didorong oleh pengujian memastikan Anda membangunnya dengan benar.
Sementara pemrograman berpasangan memungkinkan Anda untuk menemukan cacat lebih awal dan meningkatkan kualitas kode Anda.