1
00:00:07,200 --> 00:00:12,000
Setelah menonton video ini, Anda akan dapat membuat daftar lima praktik kerja Agile,

2
00:00:12,000 --> 00:00:17,200
jelaskan bekerja dalam batch kecil, tentukan produk minimum yang layak, pahami perilaku

3
00:00:17,200 --> 00:00:22,720
pengembangan yang didorong, memahami pengembangan yang didorong oleh pengujian, menjelaskan cara kerja pemrograman berpasangan.

4
00:00:24,320 --> 00:00:31,200
Jadi mari kita lihat apa artinya bekerja dengan gaya Agile. Pertama, Anda ingin bekerja di

5
00:00:31,200 --> 00:00:36,800
batch kecil. Kami mendapatkan ini dari lean manufacturing. Anda tidak ingin membuat sesuatu dalam jumlah besar

6
00:00:36,800 --> 00:00:41,040
dan kemudian mengetahui bahwa Anda melakukannya salah karena itu banyak pemborosan harus kembali dan berubah

7
00:00:41,040 --> 00:00:47,280
dia. Selanjutnya, Anda ingin menggunakan produk minimum yang layak untuk mencari tahu apa yang disukai pelanggan, apa

8
00:00:47,280 --> 00:00:52,480
tidak disukai pelanggan. Dan kemudian Anda ingin menggunakan praktik seperti pengembangan yang didorong oleh perilaku

9
00:00:52,480 --> 00:00:58,400
dan pengembangan yang didorong oleh pengujian untuk meningkatkan pengujian sistem Anda dari luar ke dalam dan

10
00:00:58,400 --> 00:01:03,760
dari dalam keluar. Dan akhirnya Anda ingin memanfaatkan pemrograman berpasangan. Ini datang

11
00:01:03,760 --> 00:01:08,560
dari pemrograman ekstrim tetapi pemrograman pasangan sangat penting. Jadi kita akan melihat

12
00:01:08,560 --> 00:01:16,800
masing-masing secara bergantian. Bekerja dalam kelompok kecil-- misalkan saya perlu mengirimkan ribuan brosur.

13
00:01:17,600 --> 00:01:22,240
Dan langkah-langkahnya yaitu anda perlu melipat brosur kemudian memasukkan brosur tersebut ke dalam amplop,

14
00:01:22,240 --> 00:01:26,240
dan kemudian segel amplop dan akhirnya cap amplop dengan perangko.

15
00:01:27,200 --> 00:01:32,560
Jadi katakanlah kita akan melakukan ribuan ini dalam kelompok 50, benar, kelompok besar, 50 buah dan

16
00:01:32,560 --> 00:01:37,600
asumsikan bahwa setiap langkah membutuhkan waktu sekitar enam detik untuk diselesaikan. Jadi saya bisa melakukan sekitar 10 langkah per menit.

17
00:01:38,400 --> 00:01:44,080
Dan jadi kita melakukan langkah pertama melipat, kan? Dan pada jam 10 selama satu menit, saya membutuhkan waktu sekitar lima menit untuk

18
00:01:44,080 --> 00:01:50,160
lipat 50 dari mereka. Kemudian saya melanjutkan ke langkah berikutnya. Langkah selanjutnya adalah memasukkan semuanya dan lagi,

19
00:01:50,160 --> 00:01:55,440
jika saya bisa melakukan sekitar 10 dari mereka per menit, jadi saya butuh lima menit lagi, ditambah lima

20
00:01:55,440 --> 00:02:00,080
menit dari sebelumnya. Sekarang aku 10 menit ke dalamnya. Saya sudah melipat semuanya dan memasukkannya lalu saya

21
00:02:00,080 --> 00:02:05,520
lanjutkan ke langkah ketiga untuk menyegel semuanya, kan? Jadi sekarang lagi sekitar 10 per menit saya bisa melakukan yang lain

22
00:02:06,240 --> 00:02:12,160
50 dalam lima menit lagi. Jadi saya sampai 15 menit, kan? Waktu jam dinding. Lalu

23
00:02:12,160 --> 00:02:18,720
akhirnya saya sampai ke langkah empat dan saya butuh 16 menit untuk mendapatkan produk jadi pertama saya kan?

24
00:02:18,720 --> 00:02:23,840
Yang pertama di mana saya memiliki barang-barang yang benar-benar dapat saya periksa dan lihat kualitasnya.

25
00:02:23,840 --> 00:02:30,640
Jadi, bagaimana jika amplop tidak memiliki lem, kan? Itu akan menjadi 11 menit sebelum saya mengetahuinya

26
00:02:30,640 --> 00:02:34,400
ada yang salah. Bagaimana jika ada kesalahan ketik pada brosur? Aku harus pergi jauh-jauh kembali

27
00:02:34,400 --> 00:02:40,560
ke awal, kan? Jadi, ini sangat, sangat boros bekerja dalam batch besar seperti ini.

28
00:02:41,200 --> 00:02:45,920
Sekarang mari kita lihat contoh yang sama dengan aliran satu bagian. Dan lagi, asumsikan setiap langkah membutuhkan waktu

29
00:02:45,920 --> 00:02:51,840
enam detik untuk menyelesaikan. Dengan aliran sepotong tunggal, saya lipat, kan? Dan masukkan ke dalam amplop dan

30
00:02:51,840 --> 00:02:57,040
segel mereka dan beri cap pada mereka dan produk jadi pertama dalam waktu sekitar 24 detik. Sekarang saya

31
00:02:57,040 --> 00:03:02,800
dapat memeriksanya untuk melihat apakah itu berfungsi, melihat apakah itu yang saya pikirkan, dan kemudian biarkan sisanya mengalir

32
00:03:02,800 --> 00:03:09,680
meninggal dunia. Sekarang bagaimana jika amplop tidak memiliki lem? Yah aku akan mencari tahu setelah, eh, mungkin 18 detik, kan?

33
00:03:09,680 --> 00:03:15,280
Dan jika ada kesalahan ketik di brosur, setelah 24 detik, jadi sangat, sangat penting bahwa kita tidak

34
00:03:15,280 --> 00:03:20,640
bekerja dalam dua kelompok yang lebih besar sehingga kami bisa mendapatkan umpan balik yang cepat dan kami dapat berputar dan memahami,

35
00:03:20,640 --> 00:03:24,480
Anda tahu, apakah kita perlu melakukan sesuatu yang berbeda dan kemudian membuat perubahan yang perlu kita lakukan?

36
00:03:25,680 --> 00:03:31,520
Jadi mari kita bicara tentang produk yang layak minimum. Pertama, mari kita pahami apa yang bukan, karena ada

37
00:03:31,520 --> 00:03:36,800
kesalahpahaman bahwa produk yang layak minimum seperti fase pertama dari proyek atau, Anda tahu,

38
00:03:36,800 --> 00:03:42,000
beta pertama atau sesuatu seperti itu. Dan itu tidak. Ini bukan produk minimum yang layak.

39
00:03:42,000 --> 00:03:47,920
Produk minimum yang layak adalah hal minimal yang dapat Anda lakukan untuk membuktikan hipotesis dan keuntungan

40
00:03:47,920 --> 00:03:53,040
belajar dan mendapatkan pemahaman. Perbedaan antara keduanya adalah bahwa yang pertama adalah segalanya

41
00:03:53,040 --> 00:03:57,120
tentang pengiriman, kan? Apa yang akan saya sampaikan? Tapi yang kedua adalah tentang

42
00:03:57,120 --> 00:04:03,920
sedang belajar. Apa yang bisa saya pelajari? Apa yang bisa saya pelajari dari mengeluarkan MVP ini dan mendapatkan umpan balik

43
00:04:03,920 --> 00:04:10,000
dan kemudian mungkin membuat yang berikutnya lebih baik? Jadi, penting bahwa di akhir setiap MVP

44
00:04:10,000 --> 00:04:17,600
Anda memutuskan apakah akan berputar atau bertahan. Mari kita lihat sebuah contoh. Inilah tim yang sedang berkembang

45
00:04:17,600 --> 00:04:22,800
produk minimum yang layak untuk pelanggan yang menginginkan mobil. Jadi, pada iterasi pertama, mereka memberikan

46
00:04:22,800 --> 00:04:27,280
roda. Pelanggan seperti, "Apa yang akan saya lakukan dengan roda? Saya tidak dapat melakukan apa pun dengan ini?" Suka,

47
00:04:27,280 --> 00:04:31,920
baik, kami sedang mengerjakan iterasi, kami mencoba untuk gesit di sini, bukan? Dan pada iterasi berikutnya, kita akan

48
00:04:31,920 --> 00:04:36,640
memberi Anda beberapa lagi. Dan mereka memberi mereka sasis dan itu seperti, oke, "Saya benar-benar tidak bisa melakukan apa-apa

49
00:04:36,640 --> 00:04:40,640
dengan ini." Dan akhirnya, Anda tahu, mereka memberi mereka mobil tanpa roda kemudi dan kemudian

50
00:04:41,360 --> 00:04:48,080
akhirnya mereka mendapatkan mobil, kan? Dan mereka mendapatkan coupe ini. Tim itu tidak mengerti

51
00:04:48,080 --> 00:04:51,520
bagaimana membuat produk yang layak minimum. Mereka hanya melakukan pengembangan berulang.

52
00:04:52,240 --> 00:04:58,560
Tim kedua memahami nilai dari pembuatan MVP. Pada awalnya, mereka memberi mereka

53
00:04:58,560 --> 00:05:03,200
skateboard dan pelanggan seperti, "Saya meminta mobil dan Anda memberi saya skateboard."

54
00:05:03,200 --> 00:05:09,360
Whoa, whoa kita sedang menguji warnanya. Bagaimana Anda menyukai warna merah itu? Apakah itu warna yang Anda inginkan? "Oh ya,

55
00:05:09,360 --> 00:05:15,280
merah agak keren tapi Anda tahu itu sangat sulit untuk dikemudikan." Tidak, kami akan memperbaikinya di MVP berikutnya dan

56
00:05:15,280 --> 00:05:20,160
kemudian mereka menambahkan cara untuk mengarahkannya dan pelanggan seperti, "Baiklah, Anda memang memberi saya cara untuk mengarahkannya

57
00:05:20,160 --> 00:05:25,120
tapi aku tidak bisa pergi terlalu cepat. Saya membutuhkan bentuk penggerak yang lebih baik." Dan kemudian kita akan mengatasinya dalam

58
00:05:25,120 --> 00:05:30,800
MVP berikutnya. Pada iterasi berikutnya, mereka memberi mereka pedal. Di suatu tempat di sepanjang jalan sementara pelanggan

59
00:05:30,800 --> 00:05:38,560
sedang mengendarai sepeda motor itu merasakan angin menerpa rambut mereka, mereka memutuskan, "Saya ingin sebuah mobil konvertibel." Dalam

60
00:05:38,560 --> 00:05:43,120
contoh pertama, pelanggan mendapatkan persis apa yang mereka minta berbulan-bulan sebelumnya karena mereka hanya

61
00:05:43,120 --> 00:05:49,440
mengikuti rencana tetapi dalam contoh kedua pelanggan mendapatkan apa yang mereka inginkan

62
00:05:49,440 --> 00:05:55,200
karena mereka bekerja secara interaktif dengan tim pengembangan dan pada akhirnya, Anda berkembang

63
00:05:55,200 --> 00:05:59,440
sesuatu yang sedikit berbeda tetapi lebih dekat dengan apa yang benar-benar diinginkan pelanggan.

64
00:06:01,280 --> 00:06:07,680
Perkembangan yang didorong oleh perilaku adalah ketika kita menggambarkan sistem dari luar ke dalam. Ini biasanya

65
00:06:07,680 --> 00:06:13,360
dilakukan pada tingkat pengujian integrasi, bukan? Jadi, di sinilah kami mengambil pelanggan

66
00:06:13,360 --> 00:06:18,880
tampilan sistem biasanya saat Anda melakukan pengujian BDD, Anda melakukannya terhadap antarmuka pengguna,

67
00:06:18,880 --> 00:06:24,800
Baik? Anda melakukannya terhadap hal yang dilihat pelanggan untuk melihat apakah sistem berperilaku

68
00:06:24,800 --> 00:06:28,640
cara yang seharusnya. Jadi, jika itu adalah sistem e-commerce, ketika saya memasukkan sesuatu ke keranjang saya, apakah itu?

69
00:06:28,640 --> 00:06:33,040
berperilaku seperti yang saya inginkan? Ketika saya mentransfer keranjang ke pesanan, apakah itu berperilaku seperti yang saya inginkan? Dia

70
00:06:33,040 --> 00:06:37,920
benar-benar mengambil pendekatan luar-dalam. Itu tidak terlalu peduli dengan hal-hal yang terjadi di bawahnya.

71
00:06:39,040 --> 00:06:44,720
Yang keren adalah ia menggunakan satu sintaks yang dapat digunakan oleh pengembang dan pemangku kepentingan

72
00:06:44,720 --> 00:06:50,160
digunakan untuk menggambarkan sistem dan menyepakati perilaku sistem, tentang apa yang dilakukan sistem.

73
00:06:50,160 --> 00:06:57,200
Jadi, mari kita lihat sintaks itu. Ini dimulai dengan skenario fitur BDD ini. Dimana saya katakan,

74
00:06:57,200 --> 00:07:03,680
"Sebagai jumlah peran, jadi, saya ingin tahu untuk siapa ini. Saya perlu beberapa fungsi, kan? Jadi apa itu

75
00:07:03,680 --> 00:07:09,600
itu fungsi yang sebenarnya kita butuhkan agar saya mendapatkan nilai bisnis?" Jadi, sekarang Anda tahu

76
00:07:09,600 --> 00:07:14,240
Untuk siapa ini. Apakah untuk pelanggan? Untuk administrator sistem, bukan? Siapa yang mendapatkan

77
00:07:14,240 --> 00:07:19,840
nilai dari ini apa yang mereka butuhkan dan mengapa mereka membutuhkannya? Dan itulah awal dari Anda

78
00:07:19,840 --> 00:07:25,440
file fitur. Dan kemudian Anda mulai menjalankan skenario dan di sinilah kami menggunakan hal umum ini

79
00:07:25,440 --> 00:07:32,560
sintaksis. Ini dikenal sebagai sintaks Gherkin setelah acar Gherkin. Dan itu berjalan seperti ini:

80
00:07:32,560 --> 00:07:37,760
Diberi serangkaian prasyarat, bukan? Jadi, skenario seperti itu-- mengingat ini benar.

81
00:07:37,760 --> 00:07:43,920
Saya punya dua item di keranjang saya. Saya mendapat tiga item yang saya pesan, terserah. Ketika suatu peristiwa terjadi,

82
00:07:43,920 --> 00:07:50,320
Baik? Jadi, itulah hal yang sedang diuji. Maka saya harus melihat beberapa hasil yang dapat diamati. Jadi, menggunakan ini

83
00:07:50,320 --> 00:07:56,560
diberikan sintaks kapan-maka, pengembang dapat memahaminya, pemangku kepentingan dapat memahaminya, semua orang dapat

84
00:07:56,560 --> 00:08:02,800
pahami sintaks umum ini bahwa ketika saya memiliki sesuatu di troli saya dan kemudian saya menghapus troli saya, Anda

85
00:08:02,800 --> 00:08:08,400
tahu, saya seharusnya tidak melihat apa pun di keranjang saya. Jadi sangat, sangat penting untuk memiliki sintaks dalam BDD ini

86
00:08:08,400 --> 00:08:17,600
skenario. Pengembangan yang didorong oleh pengujian adalah pengujian sistem dari dalam ke luar. Tidak seperti yang didorong oleh perilaku

87
00:08:17,600 --> 00:08:22,720
perkembangan. Hal ini berkaitan dengan internal sistem, modul tunggal. Biasanya ini

88
00:08:22,720 --> 00:08:27,680
disebut pengujian unit, bukan? Dan ini adalah sesuatu yang didorong oleh kasus uji unit dan kami ingin membuatnya

89
00:08:27,680 --> 00:08:33,280
yakin bahwa dengan input ini saya mendapatkan output ini pada level modul kecil. Saya tidak tahu apakah ketika saya menempatkan

90
00:08:33,280 --> 00:08:37,920
mereka semua bersama-sama saya akan mendapatkan perilaku yang saya inginkan. Itu semacam BDD tapi untuk TDD, test drive

91
00:08:37,920 --> 00:08:43,520
pengembangan, saya hanya menguji sistem di tingkat unit dan Anda menulis tes

92
00:08:43,520 --> 00:08:48,720
kasus pertama untuk kode yang Anda inginkan dan kemudian Anda menulis kode yang cukup untuk membuat kasus uji itu lulus

93
00:08:48,720 --> 00:08:53,280
dan kemudian Anda mulai dari awal lagi dan refactor. Jadi alur kerjanya berjalan seperti ini:

94
00:08:53,280 --> 00:08:58,960
Saya menulis kasus uji. Anda mungkin berkata, "Anda menulis kasus uji sebelum Anda menulis kode?" Ya ini membuat saya

95
00:08:59,760 --> 00:09:04,640
ditampilkan pada apa yang seharusnya dilakukan kode. Ketika saya memanggil ini, bagaimana saya ingin memanggil ini? apa itu?

96
00:09:04,640 --> 00:09:09,920
parameter yang saya pikir ingin saya sampaikan dan lalu apa fungsinya untuk saya? Jadi, Anda menulis test case terlebih dahulu

97
00:09:09,920 --> 00:09:16,080
kemudian Anda menulis kode yang cukup untuk membuat kasus uji itu lulus dan kemudian setelah lulus maka Anda dapat melakukan refactor

98
00:09:16,080 --> 00:09:21,120
kode karena sekarang Anda memiliki kasus uji untuk membuat Anda jujur, Anda akan tahu jika Anda melanggar sesuatu.

99
00:09:21,120 --> 00:09:26,960
Sekarang, karena ketika test case berjalan dan gagal biasanya berubah menjadi merah dan kemudian ketika berhasil

100
00:09:26,960 --> 00:09:33,360
benar berubah menjadi hijau; kita cenderung menyebutnya Merah, Hijau, Refactor. Tonton test case, tulis test case

101
00:09:33,360 --> 00:09:38,800
menontonnya gagal, buat saja cukup tulis kode untuk membuatnya lulus, dan kemudian refactor membuatnya-- Anda mungkin tidak

102
00:09:38,800 --> 00:09:42,560
telah membuatnya sangat elegan hanya untuk membuatnya lulus-- sekarang Anda dapat kembali dan Anda dapat menambahkan segala macam

103
00:09:42,560 --> 00:09:47,520
pemeriksaan kesalahan dan yang lainnya membuatnya sedikit lebih, eh, kuat dan kemudian jalankan kasus uji. Memastikan

104
00:09:47,520 --> 00:09:55,280
Anda tidak merusak apa pun. Pemrograman berpasangan. Pemrograman pasangan, Anda mungkin mengatakan dua pemrogram bekerja

105
00:09:55,280 --> 00:10:00,960
bersama-sama pada hal yang sama, eh, dan hal pertama adalah: Saya membayar dua orang untuk melakukan satu pekerjaan?

106
00:10:01,600 --> 00:10:06,400
Tetapi sebenarnya itu berhasil dengan sangat baik karena apa yang Anda lakukan adalah Anda memilikinya

107
00:10:06,400 --> 00:10:11,360
orang yang menulis kode dan kemudian Anda memiliki orang lain yang memperhatikan kode tersebut.

108
00:10:11,360 --> 00:10:15,920
Jadi pertanyaannya adalah, apakah Anda lebih suka menemukan bug dalam produksi? Apakah Anda lebih suka menemukan bug saat Anda?

109
00:10:15,920 --> 00:10:20,320
menulis kode? Jauh lebih murah untuk menemukannya saat Anda sedang menulis kode, jadi miliki dua set

110
00:10:20,320 --> 00:10:25,120
mata, mereka memeriksa satu sama lain dan mereka bolak-balik. Bukan hanya satu dan kemudian yang lain.

111
00:10:25,120 --> 00:10:29,840
Biasanya dalam 20 menit bertahap, kan? Seseorang menulis kode, yang lain sedang menonton dan mereka

112
00:10:29,840 --> 00:10:33,760
tidak hanya menonton. Terkadang mereka mencari sesuatu, terkadang mereka berdiskusi. "Bagaimana menurutmu

113
00:10:33,760 --> 00:10:38,000
Saya harus memanggil variabel ini? Menurut Anda apa yang harus saya sebut fungsi ini?" Benar? Ini dua set

114
00:10:38,000 --> 00:10:44,080
pikiran bekerja di sekitar kode ini dan apa yang terjadi adalah Anda benar-benar mendapatkan kode kualitas yang lebih tinggi di akhir

115
00:10:44,080 --> 00:10:49,360
hari, kan? Kualitas kode naik karena dua orang sudah memeriksanya dan kapan

116
00:10:49,360 --> 00:10:54,560
Anda berkata, "Saya tidak mampu membayar dua orang untuk menulis satu kode." Anda tidak mampu untuk tidak membayar dua

117
00:10:54,560 --> 00:10:59,280
orang untuk menulisnya karena menulis kode adalah bagian yang murah. Debugging itu, mempertahankan dalam produksi,

118
00:10:59,280 --> 00:11:04,000
itu bagian yang mahal dan jadi jika Anda ingin bagian yang mahal menjadi lebih murah, Anda ingin memilikinya

119
00:11:04,000 --> 00:11:09,040
programmer Anda melakukan pemrograman berpasangan. Ini juga sangat bagus untuk menempatkan programmer senior dengan junior

120
00:11:09,040 --> 00:11:13,760
programmer. Sekarang programmer junior dapat melihat: Bagaimana programmer senior mendekati masalah?

121
00:11:13,760 --> 00:11:18,480
Jadi mereka belajar, mereka mendapatkan bimbingan, dan kemudian program senior dapat melihat bagaimana orang junior

122
00:11:18,480 --> 00:11:23,600
sedang bermesraan. Atau Anda mendapatkan orang yang tidak terbiasa dengan kode yang bekerja dengan seseorang yang. Kamu sekarang

123
00:11:23,600 --> 00:11:27,760
buat lebih banyak orang mempelajari kode karena mereka dan mereka mendapatkan seperti tutorial dari

124
00:11:27,760 --> 00:11:33,200
orang lain. Jadi pemrograman berpasangan adalah cara yang sangat, sangat bagus untuk membawa semua orang Anda aktif

125
00:11:33,200 --> 00:11:39,440
tim Anda hingga level tertentu. Dalam video ini Anda belajar bahwa bekerja dalam kelompok kecil berarti

126
00:11:39,440 --> 00:11:45,840
memberikan sesuatu yang berguna dengan cepat, MVP adalah hal termurah dan termudah yang dapat Anda lakukan untuk menguji

127
00:11:45,840 --> 00:11:50,640
hipotesis dan belajar. Pengembangan yang didorong oleh perilaku memastikan Anda membangun hal yang benar.

128
00:11:51,520 --> 00:11:54,240
Dan pengembangan yang didorong oleh pengujian memastikan Anda membangunnya dengan benar.

129
00:11:55,360 --> 00:12:05,600
Sementara pemrograman berpasangan memungkinkan Anda untuk menemukan cacat lebih awal dan meningkatkan kualitas kode Anda.