515 lines
18 KiB
Plaintext
515 lines
18 KiB
Plaintext
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. |