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.