1
00:00:08,090 --> 00:00:12,110
Setelah menonton video ini, Anda akan dapat menjelaskan pendekatan Waterfall pada perangkat lunak

2
00:00:12,110 --> 00:00:13,560
perkembangan.

3
00:00:13,560 --> 00:00:18,860
Jelaskan masalah dengan pendekatan Waterfall, jelaskan pendekatan Extreme Programming, daftar

4
00:00:18,860 --> 00:00:22,430
nilai pendekatan XP, tentukan Kanban,

5
00:00:22,430 --> 00:00:25,310
dan daftar prinsip-prinsip intinya.

6
00:00:25,310 --> 00:00:28,360
Jadi, mari kita lihat pengembangan Air Terjun tradisional.

7
00:00:28,360 --> 00:00:32,820
Semuanya dimulai dengan fase persyaratan. Orang-orang mengumpulkan persyaratan, melihat

8
00:00:32,820 --> 00:00:35,820
apa yang diinginkan pelanggan, memastikan bahwa kami akan memberikan sesuatu yang

9
00:00:35,820 --> 00:00:38,780
keinginan pelanggan. Setidaknya untuk saat itu.

10
00:00:38,780 --> 00:00:43,960
Jadi ini adalah fase di mana semua yang Anda lakukan adalah mendokumentasikan semua persyaratan dari

11
00:00:43,960 --> 00:00:49,380
mungkin diinginkan pelanggan dalam sistem. Kemudian Anda beralih ke fase desain.

12
00:00:49,380 --> 00:00:51,329
Perhatikan saya menggunakan istilah fase di sini.

13
00:00:51,329 --> 00:00:56,880
Ini sangat penting, karena ada kriteria keluar dan kriteria masuk untuk pindah

14
00:00:56,880 --> 00:00:58,650
dari satu fase ke fase lainnya.

15
00:00:58,650 --> 00:01:03,670
Jadi setelah kami mendapatkan semua persyaratan, kami beralih ke desain, berharap kami memilikinya

16
00:01:03,670 --> 00:01:06,930
semua persyaratan yang sebenarnya kita butuhkan.

17
00:01:06,930 --> 00:01:10,840
Maka pada tahap desain, para arsitek sedang merancang. Mereka mencari tahu bagaimana caranya

18
00:01:10,840 --> 00:01:15,869
kami mengambil persyaratan itu, mengubahnya menjadi perangkat lunak yang berfungsi, dan mereka mendesain keseluruhannya

19
00:01:15,869 --> 00:01:16,869
sistem.

20
00:01:16,869 --> 00:01:20,270
Dan kemudian setelah fase itu selesai, kita beralih ke fase pengkodean.

21
00:01:20,270 --> 00:01:23,840
Jadi di sinilah para pengembang meretas hacking coding.

22
00:01:23,840 --> 00:01:29,039
Sekarang, Anda akan melihat ini disebut Air Terjun dan panah-panah itu mengalir ke bawah.

23
00:01:29,039 --> 00:01:32,599
karena sangat sulit untuk berenang ke atas air terjun.

24
00:01:32,599 --> 00:01:34,649
Ini adalah nama yang sesuai.

25
00:01:34,649 --> 00:01:38,870
Karena ketika Anda berada dalam fase pengkodean, dan Anda mengetahui, ini adalah desain yang buruk, tidak

26
00:01:38,870 --> 00:01:42,930
bekerja, sangat sulit untuk kembali dan mendesain ulang sesuatu.

27
00:01:42,930 --> 00:01:47,590
Faktanya, karena kami memperlakukan pengembangan perangkat lunak seperti proyek teknik sipil, terkadang

28
00:01:47,590 --> 00:01:52,310
beberapa dari desainer tersebut telah pindah ke proyek berikutnya, dan Anda harus menemukannya.

29
00:01:52,310 --> 00:01:56,220
Jadi sangat, sangat sulit untuk kembali dan berenang dengan air terjun.

30
00:01:56,220 --> 00:01:59,150
Kemudian setelah coding, akhirnya kita bisa mengintegrasikan.

31
00:01:59,150 --> 00:02:04,470
Jadi selama ini, kami mengkode secara terpisah, kami tidak mengintegrasikan modul saya dengan modul orang berikutnya

32
00:02:04,470 --> 00:02:07,820
modul. Anda tahu, ada saatnya semua modul itu bersatu. Pertama kali

33
00:02:07,820 --> 00:02:11,849
kami menyadari, apakah semua potongan kode ini bekerja bersama?

34
00:02:11,849 --> 00:02:15,459
Dan kemudian kami beralih ke fase pengujian, karena sekarang kami memiliki sistem yang membuat orang

35
00:02:15,459 --> 00:02:16,730
dapat menguji.

36
00:02:16,730 --> 00:02:21,760
Dan ketika mereka menemukan serangga, mereka harus kembali, berenang ke air terjun, dan membuka beberapa serangga

37
00:02:21,760 --> 00:02:23,989
dalam tahap coding dan melakukan beberapa recoding.

38
00:02:23,989 --> 00:02:28,370
Dan kemudian jika salah satu bug yang mereka uji ternyata, Anda benar-benar perlu mengubahnya

39
00:02:28,370 --> 00:02:33,980
desain karena hal-hal ini tidak berinteraksi dengan baik, jalan, naik ke air terjun, sangat mahal

40
00:02:33,980 --> 00:02:36,569
untuk kembali ke tahap desain.

41
00:02:36,569 --> 00:02:41,580
Dan akhirnya, setelah semua pengujian selesai, kami menerapkan perangkat lunak.

42
00:02:41,580 --> 00:02:43,879
Jadi apa yang salah dengan pendekatan ini?

43
00:02:43,879 --> 00:02:46,490
Yah, tidak ada ketentuan untuk perubahan.

44
00:02:46,490 --> 00:02:48,840
Setiap fase memiliki kriteria masuk dan keluar.

45
00:02:48,840 --> 00:02:51,750
Dan ketika satu berakhir, Anda tahu, yang berikutnya dimulai.

46
00:02:51,750 --> 00:02:55,640
Dan tidak ada ketentuan untuk kembali dan mengubah desain atau mengubah persyaratan

47
00:02:55,640 --> 00:02:57,840
atau apa pun seperti itu.

48
00:02:57,840 --> 00:03:01,940
Jadi masalah lainnya adalah, Anda tidak tahu apakah itu berhasil sampai akhir, kan, tidak ada perantara

49
00:03:01,940 --> 00:03:06,299
pengiriman. Tidak ada yang dikirim, sampai langkah terakhir itu, ketika kami memberikannya ke operasi

50
00:03:06,299 --> 00:03:10,640
tim dan katakan, kirim barang ini ke produksi.

51
00:03:10,640 --> 00:03:14,390
Yang lainnya adalah bahwa setiap langkah berakhir ketika langkah berikutnya dimulai, di situlah ia mendapatkan ini

52
00:03:14,390 --> 00:03:17,590
nama air terjun, di mana hal-hal baru saja diturunkan.

53
00:03:17,590 --> 00:03:22,689
Dan tentu saja, semua ini adalah kesempatan untuk kehilangan informasi, Anda tahu, dan untuk memiliki

54
00:03:22,689 --> 00:03:28,109
kecelakaan terjadi atau orang diblokir, karena mereka tidak dapat menerima, Anda tahu, pekerjaan itu

55
00:03:28,109 --> 00:03:29,400
dari fase sebelumnya.

56
00:03:29,400 --> 00:03:33,080
Dan sekarang Anda sedang menunggu untuk memulai fase berikutnya.

57
00:03:33,080 --> 00:03:38,060
Yang lainnya adalah bahwa kesalahan yang ditemukan di kemudian hari sangat, sangat mahal, sangat mahal untuk ditemukan

58
00:03:38,060 --> 00:03:42,439
sesuatu yang dirancang salah dan menguji dan kembali dan mendesain ulang.

59
00:03:42,439 --> 00:03:46,579
Dan akhirnya, ada waktu tunggu yang lama, tepat di antara mendapatkan perangkat lunak itu

60
00:03:46,579 --> 00:03:51,740
terkirim. Sejak pertama kali Anda menginginkan perangkat lunak, dan Anda merancang perangkat lunak dan

61
00:03:51,740 --> 00:03:52,760
mengkodekannya dan mengujinya.

62
00:03:52,760 --> 00:03:56,569
Dan pada saat Anda akhirnya mengirimkannya dengan waktu yang sangat lama.

63
00:03:56,569 --> 00:04:01,620
Jadi masalahnya di sini adalah tim bekerja secara terpisah, mereka tidak menyadari dampaknya satu sama lain.

64
00:04:01,620 --> 00:04:05,579
Benar, desainer tidak menyadari dampak kode, pembuat kode tidak menyadarinya

65
00:04:05,579 --> 00:04:07,720
dampak untuk mengintegrasikan semua kode bersama-sama.

66
00:04:07,720 --> 00:04:11,139
Di sana semua orang bekerja di silo kecil mereka untuk fase kecil mereka.

67
00:04:11,139 --> 00:04:13,609
Dan kemudian ini harus menjadi pemikiran yang menakutkan.

68
00:04:13,609 --> 00:04:19,470
Orang-orang yang terjauh dari kode, tim operasi yang buruk, harus menjalankan ini

69
00:04:19,470 --> 00:04:21,700
dan mengelola ini dalam produksi, kan?

70
00:04:21,700 --> 00:04:26,750
Mereka tahu sedikit tentang kodenya, dan merekalah yang diharapkan untuk menjalankannya.

71
00:04:26,750 --> 00:04:28,340
Tidak terlalu efisien.

72
00:04:28,340 --> 00:04:31,600
Mari kita bicara tentang metodologi lain, pemrograman ekstrim.

73
00:04:31,600 --> 00:04:33,610
Ini diperkenalkan kembali pada tahun 96.

74
00:04:33,610 --> 00:04:38,140
Kent Beck memperkenalkan ini dan jika Anda melihat grafik di sebelah kanan, Anda akan melihatnya

75
00:04:38,140 --> 00:04:41,490
itu sangat berulang dan berbicara tentang loop.

76
00:04:41,490 --> 00:04:44,680
Anda memiliki rencana rilis utama ini di loop luar.

77
00:04:44,680 --> 00:04:46,400
Dan kemudian Anda punya rencana iterasi.

78
00:04:46,400 --> 00:04:49,280
Jadi rilis mungkin berbulan-bulan, iterasi mungkin berminggu-minggu,

79
00:04:49,280 --> 00:04:54,340
penerimaan mungkin berhari-hari, berdiri rapat sekali sehari, benar, negosiasi pasangan dalam hitungan jam,

80
00:04:54,340 --> 00:04:58,180
unit testing dalam hitungan menit, pasangkan prpgramming dalam hitungan detik.

81
00:04:58,180 --> 00:05:04,690
Anda tahu, ini adalah putaran yang semakin ketat dalam melakukan pekerjaan dan kemudian mendapatkan umpan balik yang cepat.

82
00:05:04,690 --> 00:05:08,160
Ini didasarkan pada pendekatan berulang untuk pengembangan perangkat lunak.

83
00:05:08,160 --> 00:05:10,580
Dan faktanya, dari sinilah Agile mendapatkannya.

84
00:05:10,580 --> 00:05:15,131
Dan maksud di sini adalah untuk meningkatkan kualitas perangkat lunak, bukan? Jadilah responsif terhadap perubahan, jadilah

85
00:05:15,131 --> 00:05:18,930
responsif terhadap kebutuhan pelanggan, melakukan hal-hal sedikit demi sedikit.

86
00:05:18,930 --> 00:05:25,180
Dan begitu banyak orang mengenali Extreme Program sebagai salah satu metode Agile pertama.

87
00:05:25,180 --> 00:05:28,009
Jadi mari kita bicara tentang nilai Extreme Programming.

88
00:05:28,009 --> 00:05:29,620
Pertama adalah kesederhanaan, bukan?

89
00:05:29,620 --> 00:05:30,820
Lakukan apa yang Anda butuhkan

90
00:05:30,820 --> 00:05:36,050
dan tidak lebih, jangan over-engineer, jangan over code, jangan memberikan kode lebih dari pelanggan

91
00:05:36,050 --> 00:05:37,050
diminta.

92
00:05:37,050 --> 00:05:39,069
Tetap sederhana, sangat penting.

93
00:05:39,069 --> 00:05:41,020
Selanjutnya adalah komunikasi.

94
00:05:41,020 --> 00:05:44,830
Semua orang di tim harus berkomunikasi, tahu apa yang dilakukan orang lain, itu mendorong

95
00:05:44,830 --> 00:05:49,639
banyak, banyak komunikasi, dan orang-orang berinteraksi. Sangat penting juga.

96
00:05:49,639 --> 00:05:53,830
Dan kemudian umpan balik, Anda tidak tahu apa yang Anda lakukan kecuali Anda mendapatkan umpan balik.

97
00:05:53,830 --> 00:05:58,540
Jadi memiliki loop umpan balik itu sangat penting untuk pemrograman ekstrem, dan penting untuk Agile

98
00:05:58,540 --> 00:06:00,070
secara umum.

99
00:06:00,070 --> 00:06:04,580
Dan kemudian rasa hormat, semua orang merasa bahwa mereka dihormati di tim, yang dapat mereka tawarkan

100
00:06:04,580 --> 00:06:09,440
saran bahwa mereka dapat membuat saran, dan saran mereka sama berharganya

101
00:06:09,440 --> 00:06:11,270
sebagai saran orang lain di tim.

102
00:06:11,270 --> 00:06:16,520
Tidak ada hierarki, setiap orang memiliki rekan kerja di tim, dan dihormati karena ide-ide mereka.

103
00:06:16,520 --> 00:06:21,020
Dan akhirnya, keberanian, benar, kami tidak menghitung perkiraan kami, kami hanya sangat jujur

104
00:06:21,020 --> 00:06:22,690
tentang kami pikir kami bisa melakukan ini

105
00:06:22,690 --> 00:06:24,130
Dan kami tidak berpikir kami bisa melakukan itu.

106
00:06:24,130 --> 00:06:27,199
Dan kami tidak akan berbohong kepada Anda bahwa kami tahu, kami bisa menyelesaikan ini, ini selesai dalam hal ini

107
00:06:27,199 --> 00:06:28,280
jumlah waktu.

108
00:06:28,280 --> 00:06:32,750
Kami sangat terbuka dan jujur ​​dalam Extreme Programming, ini perkiraannya, ini yang akan kami komit

109
00:06:32,750 --> 00:06:33,750
ke.

110
00:06:33,750 --> 00:06:35,639
Selanjutnya, ada Kanban.

111
00:06:35,639 --> 00:06:38,520
Ini berasal dari sistem manufaktur Jepang.

112
00:06:38,520 --> 00:06:43,221
Dan kanban secara harfiah berarti tanda papan reklame, dan ini semua tentang aliran terus menerus di

113
00:06:43,221 --> 00:06:48,569
lantai manufaktur, di mana kartu atau catatan ini akan mengalir dengan produk dari stasiun

114
00:06:48,569 --> 00:06:52,050
ke stasiun, turun jalur.

115
00:06:52,050 --> 00:06:55,550
Jadi prinsip inti dengan Kanban adalah memvisualisasikan alur kerja.

116
00:06:55,550 --> 00:06:58,450
Jika Anda tidak dapat melihat pekerjaan tersebut, Anda tidak dapat mengelola pekerjaan tersebut.

117
00:06:58,450 --> 00:07:02,080
Dan ini adalah sesuatu yang kita ambil ke Agile juga. Anda akan mengetahui bahwa kami akan pergi

118
00:07:02,080 --> 00:07:03,580
untuk menggunakan papan Kanban dan Agile.

119
00:07:03,580 --> 00:07:08,039
Dan ini semua tentang memvisualisasikan pekerjaan, sangat penting bahwa Anda dapat memahami pekerjaan itu

120
00:07:08,039 --> 00:07:14,660
yang perlu dilakukan, dan semuanya dipertanggungjawabkan. Kanban juga menekankan batasi pekerjaan di

121
00:07:14,660 --> 00:07:19,300
kemajuan. Anda tidak ingin, ketika Anda berada di lantai produksi, Anda tidak ingin pekerjaan dicadangkan di satu tempat

122
00:07:19,300 --> 00:07:20,300
dari stasiun.

123
00:07:20,300 --> 00:07:23,470
Tetapi bahkan ketika Anda sedang mengembangkan perangkat lunak, Anda tidak ingin orang lain mengerjakannya juga

124
00:07:23,470 --> 00:07:25,040
banyak hal sekaligus.

125
00:07:25,040 --> 00:07:29,080
Karena, Anda tahu, Anda hanya dapat mengirimkan 100% dari satu hal yang berfungsi, Anda tidak dapat mengirim

126
00:07:29,080 --> 00:07:30,080
50% dari dua hal.

127
00:07:30,080 --> 00:07:33,180
Jadi jika Anda membuat satu orang mengerjakan dua hal, itu tidak baik.

128
00:07:33,180 --> 00:07:37,300
Dan itu berasal dari Kanban untuk membatasi pekerjaan yang sedang berlangsung.

129
00:07:37,300 --> 00:07:41,860
Lalu ada mengelola dan meningkatkan aliran. Di Kanban, mereka selalu ingin berkembang.

130
00:07:41,860 --> 00:07:46,479
Mereka selalu ingin berubah dan mengerti bagaimana kita bisa mendapatkan aliran yang lebih baik, aliran yang lebih cepat

131
00:07:46,479 --> 00:07:52,889
di lantai produksi, dan kemudian membuat kebijakan eksplisit, sehingga semua orang mengerti

132
00:07:52,889 --> 00:07:54,189
bagaimana hal-hal bekerja.

133
00:07:54,189 --> 00:07:58,659
Dan semua orang mengerti definisi "selesai", apa artinya memiliki sesuatu?

134
00:07:58,659 --> 00:08:04,840
"selesai." Kami mengambil itu juga dari Kanban dalam perencanaan Agile kami untuk memahami apa definisinya

135
00:08:04,840 --> 00:08:06,300
dari "selesai" adalah.

136
00:08:06,300 --> 00:08:11,520
Dan kemudian terus ditingkatkan, sangat, sangat penting untuk mendapatkan umpan balik dan terus menerus

137
00:08:11,520 --> 00:08:12,520
meningkatkan apa yang Anda lakukan.

138
00:08:12,520 --> 00:08:17,850
Jadi Kanban adalah tentang membuat alur bekerja lebih baik, memahaminya, melihatnya,

139
00:08:17,850 --> 00:08:22,530
mampu mengukurnya, dan kemudian terus meningkatkan bagaimana kita bisa mengalir lebih cepat.

140
00:08:22,530 --> 00:08:27,500
Dalam video ini, Anda mempelajari bahwa pendekatan Waterfall tradisional Anda untuk pengembangan perangkat lunak

141
00:08:27,500 --> 00:08:32,520
adalah proses langkah-demi-langkah yang terstruktur yang dapat menyebabkan masalah yang tidak muncul sampai nanti

142
00:08:32,520 --> 00:08:33,980
dalam pengembangan.

143
00:08:33,980 --> 00:08:38,820
Pemrograman ekstrim dikembangkan untuk meningkatkan kualitas perangkat lunak dan responsif terhadap perubahan

144
00:08:38,820 --> 00:08:40,540
persyaratan.

145
00:08:40,540 --> 00:08:46,150
Nilai XP meliputi kesederhanaan, komunikasi, umpan balik, rasa hormat, dan keberanian.

146
00:08:46,150 --> 00:08:52,270
Kanban adalah sistem yang dicirikan dengan memvisualisasikan alur kerja, membatasi pekerjaan yang sedang berjalan, mengelola

147
00:08:52,270 --> 00:08:58,053
dan meningkatkan aliran, membuat kebijakan proses eksplisit dan terus meningkatkan proses.