Apa itu metodologi tangkas? Pengembangan perangkat lunak modern menjelaskan

Setiap organisasi teknologi saat ini tampaknya mempraktikkan metodologi tangkas untuk pengembangan perangkat lunak, atau versinya. Atau setidaknya mereka percaya begitu. Apakah Anda baru dalam pengembangan aplikasi tangkas atau Anda mempelajari pengembangan perangkat lunak beberapa dekade yang lalu menggunakan metodologi pengembangan perangkat lunak air terjun, saat ini pekerjaan Anda setidaknya dipengaruhi oleh metodologi tangkas.

Tetapi apa itu metodologi tangkas, dan bagaimana seharusnya dipraktikkan dalam pengembangan perangkat lunak? Apa perbedaan pengembangan agile dengan waterfall dalam praktiknya? Apa siklus pengembangan perangkat lunak tangkas, atau SDLC tangkas? Dan apakah scrum agile versus Kanban dan model agile lainnya? 

Agile secara resmi diluncurkan pada tahun 2001 ketika 17 teknolog merancang Agile Manifesto. Mereka menulis empat prinsip utama untuk manajemen proyek yang gesit, dengan tujuan mengembangkan perangkat lunak yang lebih baik:

  • Individu dan interaksi atas proses dan alat
  • Bekerja perangkat lunak di atas dokumentasi yang komprehensif
  • Kolaborasi pelanggan melalui negosiasi kontrak
  • Menanggapi perubahan mengikuti rencana

Sebelum agile: Era metodologi air terjun

Tangan-tangan tua seperti saya mengingat hari-hari ketika metodologi air terjun menjadi standar emas untuk pengembangan perangkat lunak. Proses pengembangan perangkat lunak membutuhkan banyak dokumentasi di muka sebelum pengkodean dimulai. Seseorang, biasanya analis bisnis, pertama kali menulis dokumen persyaratan bisnis yang menangkap semua yang dibutuhkan bisnis dalam aplikasi. Dokumen persyaratan bisnis ini panjang, merinci semuanya: strategi keseluruhan, spesifikasi fungsional yang komprehensif, dan desain antarmuka pengguna visual.

Ahli teknologi mengambil dokumen persyaratan bisnis dan mengembangkan dokumen persyaratan teknis mereka sendiri. Dokumen ini menjelaskan arsitektur aplikasi, struktur data, desain fungsional berorientasi objek, antarmuka pengguna, dan persyaratan nonfungsional lainnya.

Proses pengembangan perangkat lunak air terjun ini akhirnya akan memulai pengkodean, kemudian integrasi, dan akhirnya pengujian sebelum aplikasi dianggap siap produksi. Seluruh proses bisa dengan mudah memakan waktu beberapa tahun.

Kami para pengembang diharapkan mengetahui "spesifikasi", sebutan untuk dokumentasi lengkapnya, seperti yang diketahui oleh penulis dokumen, dan kami sering dihukum jika kami lupa untuk menerapkan dengan benar detail kunci yang diuraikan pada halaman 77 dari 200- dokumen halaman.

Dulu, pengembangan perangkat lunak itu sendiri juga tidak mudah. Banyak alat pengembangan memerlukan pelatihan khusus, dan tidak ada yang dekat dengan sumber terbuka atau komponen perangkat lunak komersial, API, dan layanan web yang ada saat ini. Kami harus mengembangkan hal-hal tingkat rendah seperti membuka koneksi database dan melakukan multithreading pada pemrosesan data kami.

Bahkan untuk aplikasi dasar, tim besar dan alat komunikasi terbatas. Spesifikasi teknis kami adalah yang menyelaraskan kami, dan kami memanfaatkannya seperti Alkitab. Jika persyaratan berubah, kami akan membuat para pemimpin bisnis melalui proses peninjauan yang panjang dan keluar karena mengomunikasikan perubahan ke seluruh tim dan memperbaiki kode itu mahal.

Karena perangkat lunak dikembangkan berdasarkan arsitektur teknis, artefak tingkat rendah dikembangkan pertama kali dan artefak dependen sesudahnya. Tugas diberikan oleh keahlian, dan itu umum bagi insinyur database untuk membangun tabel dan artefak database lainnya terlebih dahulu, diikuti oleh pengembang aplikasi yang mengkodekan fungsionalitas dan logika bisnis, dan akhirnya antarmuka pengguna dilapisi. Butuh waktu berbulan-bulan sebelum ada yang melihat aplikasi tersebut berfungsi dan saat itu, para pemangku kepentingan menjadi gelisah dan seringkali lebih pintar tentang apa yang sebenarnya mereka inginkan. Tidak heran jika menerapkan perubahan sangat mahal!

Tidak semua yang Anda tunjukkan kepada pengguna berfungsi seperti yang diharapkan. Terkadang, pengguna tidak akan menggunakan fitur sama sekali. Di lain waktu, kapabilitas berhasil secara luas tetapi memerlukan rekayasa ulang untuk mendukung skalabilitas dan kinerja yang diperlukan. Di dunia air terjun, Anda hanya mempelajari hal-hal ini setelah perangkat lunak diterapkan, setelah siklus pengembangan yang panjang.

Video terkait: Cara kerja metodologi tangkas

Semua orang tampaknya berbicara tentang pengembangan perangkat lunak yang gesit, tetapi banyak organisasi tidak memiliki pemahaman yang kuat tentang cara kerja prosesnya. Tonton video lima menit ini untuk mendapatkan informasi terbaru dengan cepat.

Pivot untuk pengembangan perangkat lunak yang gesit

Diciptakan pada tahun 1970, metodologi air terjun adalah revolusioner karena mendisiplinkan pengembangan perangkat lunak untuk memastikan bahwa ada spesifikasi yang jelas untuk diikuti. Ini didasarkan pada metode produksi air terjun yang berasal dari inovasi lini perakitan Henry Ford tahun 1913, yang memberikan kepastian pada setiap langkah dalam proses produksi untuk menjamin bahwa produk akhir sesuai dengan spesifikasi di tempat pertama.

Ketika metodologi air terjun masuk ke dunia perangkat lunak, sistem komputasi dan aplikasinya biasanya kompleks dan monolitik, membutuhkan disiplin dan hasil yang jelas untuk menyampaikannya. Persyaratan juga berubah perlahan dibandingkan saat ini, sehingga upaya skala besar tidak terlalu bermasalah. Faktanya, sistem dibangun dengan asumsi sistem tidak akan berubah tetapi akan menjadi kapal perang abadi. Kerangka waktu multiyear umum tidak hanya dalam pengembangan perangkat lunak tetapi juga dalam kegiatan manufaktur dan perusahaan lainnya. Tapi kekakuan air terjun menjadi kelemahan di era internet, di mana kecepatan dan fleksibilitas diperlukan.

Metodologi pengembangan perangkat lunak mulai berubah ketika pengembang mulai mengerjakan aplikasi internet. Banyak pekerjaan awal dilakukan di perusahaan rintisan di mana tim lebih kecil, ditempatkan secara terpisah, dan seringkali tidak memiliki latar belakang ilmu komputer tradisional. Ada tekanan keuangan dan persaingan untuk menghadirkan situs web, aplikasi, dan kemampuan baru ke pasar lebih cepat. Sebagai tanggapan, alat dan platform pengembangan berubah dengan cepat.

Hal ini membuat banyak dari kita yang bekerja di perusahaan rintisan mempertanyakan metodologi air terjun dan mencari cara agar lebih efisien. Kami tidak mampu melakukan semua dokumentasi mendetail di muka, dan kami membutuhkan proses yang lebih berulang dan kolaboratif. Kami masih memperdebatkan perubahan pada persyaratan, tetapi kami lebih terbuka untuk eksperimen dan beradaptasi dengan kebutuhan pengguna akhir. Organisasi kami kurang terstruktur dan aplikasi kami tidak sekompleks sistem lama perusahaan, jadi kami jauh lebih terbuka untuk membuat dibandingkan membeli aplikasi. Lebih penting lagi, kami mencoba mengembangkan bisnis, jadi ketika pengguna kami memberi tahu kami bahwa ada sesuatu yang tidak berfungsi, kami lebih sering memilih untuk mendengarkan mereka.

Keterampilan dan kemampuan kita untuk berinovasi menjadi penting secara strategis. Anda dapat mengumpulkan semua uang yang Anda inginkan, tetapi Anda tidak dapat menarik pengembang perangkat lunak berbakat yang dapat bekerja dengan teknologi internet yang berubah dengan cepat jika Anda akan memperlakukan mereka sebagai pembuat kode yang patuh mengikuti "spesifikasi". Kami menolak manajer proyek yang datang dengan jadwal ujung ke ujung yang menjelaskan apa yang harus kami kembangkan, kapan aplikasi harus dikirimkan, dan terkadang bahkan bagaimana menyusun kode. Kami sangat buruk dalam mencapai jadwal tiga bulan dan enam bulan yang disusun oleh manajer proyek air terjun dan terus diperbarui.

Sebaliknya, kami mulai memberi tahu mereka bagaimana aplikasi internet perlu direkayasa, dan kami memberikan hasil sesuai jadwal yang kami susun secara berulang. Ternyata kami tidak seburuk itu dalam menyampaikan apa yang kami katakan ketika kami berkomitmen untuk itu dalam interval kecil, satu minggu sampai empat minggu.

Pada tahun 2001, sekelompok pengembang perangkat lunak yang berpengalaman berkumpul dan menyadari bahwa mereka secara kolektif mempraktikkan pengembangan perangkat lunak secara berbeda dari metodologi air terjun klasik. Dan mereka tidak semuanya di startup. Grup ini, yang mencakup tokoh teknologi Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber, dan Jeff Sutherland, muncul dengan Agile Manifesto yang mendokumentasikan keyakinan bersama mereka tentang bagaimana seharusnya proses pengembangan perangkat lunak modern beroperasi. Mereka menekankan kolaborasi atas dokumentasi, pengorganisasian diri daripada praktik manajemen yang kaku, dan kemampuan untuk mengelola perubahan konstan daripada mengunci diri Anda pada proses pengembangan air terjun yang kaku.

Dari prinsip-prinsip tersebut lahir metodologi tangkas untuk pengembangan perangkat lunak.

Peran dalam metodologi tangkas

Proses pengembangan perangkat lunak tangkas selalu dimulai dengan mendefinisikan pengguna dan mendokumentasikan pernyataan visi tentang ruang lingkup masalah, peluang, dan nilai yang akan ditangani. Pemilik produk menangkap visi ini dan bekerja dengan tim multidisiplin (atau tim) untuk mewujudkan visi ini. Inilah peran-peran dalam proses itu.

Pengguna

Proses tangkas selalu dimulai dengan memikirkan pengguna atau pelanggan. Saat ini, kami sering mendefinisikannya dengan persona pengguna untuk mengilustrasikan peran berbeda dalam alur kerja yang didukung perangkat lunak atau berbagai jenis kebutuhan dan perilaku pelanggan.

Pemilik produk

Proses pengembangan agile sendiri dimulai dengan seseorang yang dituntut untuk menjadi suara pelanggan, termasuk pemangku kepentingan internal. Orang itu menyaring semua wawasan, ide, dan umpan balik untuk menciptakan visi produk. Visi produk ini sering kali singkat dan lugas, tetapi tetap memberikan gambaran tentang siapa pelanggan itu, nilai apa yang sedang ditangani, dan strategi bagaimana mengatasinya. Saya dapat membayangkan visi asli Google tampak seperti "Mari kita permudah siapa saja yang memiliki akses internet untuk menemukan situs web dan halaman web yang relevan dengan antarmuka sederhana yang digerakkan oleh kata kunci dan algoritme yang memberi peringkat sumber tepercaya lebih tinggi dalam hasil penelusuran."

Kami menyebut orang ini sebagai pemilik produk . Tanggung jawabnya adalah untuk menentukan visi ini dan kemudian bekerja dengan tim pengembangan untuk mewujudkannya.

Untuk bekerja dengan tim pengembangan, pemilik produk memecah visi produk menjadi serangkaian cerita pengguna yang menjelaskan secara lebih rinci siapa pengguna target, masalah apa yang sedang dipecahkan untuk mereka, mengapa solusi itu penting bagi mereka, dan batasan dan kriteria penerimaan apa yang menentukan solusinya. Kisah pengguna ini diprioritaskan oleh pemilik produk, ditinjau oleh tim untuk memastikan mereka memiliki pemahaman bersama tentang apa yang diminta dari mereka.

Tim pengembangan perangkat lunak

Dalam agile, tanggung jawab tim pengembangan dan anggotanya berbeda dengan tanggung jawab pengembangan perangkat lunak tradisional.

Timnya multidisiplin, terdiri dari berbagai kelompok orang dengan keterampilan untuk menyelesaikan pekerjaan. Karena fokusnya adalah memberikan perangkat lunak yang berfungsi, tim harus menyelesaikan aplikasi yang berfungsi dari ujung ke ujung. Jadi database, logika bisnis, dan antarmuka pengguna dari bagian aplikasi dikembangkan dan kemudian didemonstrasikan — bukan keseluruhan aplikasi. Untuk melakukan ini, anggota tim harus berkolaborasi. Mereka sering bertemu untuk memastikan semua orang memahami apa yang mereka bangun, tentang siapa yang melakukan apa, dan tentang bagaimana tepatnya perangkat lunak itu dikembangkan.

Selain pengembang, tim pengembangan perangkat lunak dapat mencakup insinyur jaminan kualitas (QA), insinyur lain (seperti untuk database dan sistem back-end), desainer, dan analis, tergantung pada jenis proyek perangkat lunak.

Scrum, Kanban, dan kerangka kerja tangkas lainnya

Banyak kerangka kerja tangkas yang memberikan spesifik tentang proses pengembangan dan praktik pengembangan tangkas, selaras dengan siklus hidup pengembangan perangkat lunak.

Kerangka tangkas yang paling populer disebut scrum . Ini berfokus pada irama pengiriman yang disebut sprint dan struktur rapat yang mencakup berikut ini:

  • Perencanaan - di mana prioritas sprint diidentifikasi
  • Komitmen - di mana tim meninjau daftar atau simpanan cerita pengguna dan memutuskan berapa banyak pekerjaan yang dapat dilakukan dalam durasi sprint 
  • Rapat standup harian - sehingga tim dapat mengkomunikasikan pembaruan tentang status dan strategi pengembangan mereka)

Sprint diakhiri dengan rapat demo yang fungsinya diperlihatkan kepada pemilik produk, diikuti dengan rapat retrospektif di mana tim membahas apa yang berjalan dengan baik dan apa yang perlu ditingkatkan dalam prosesnya.

Banyak organisasi mempekerjakan master atau pelatih scrum untuk membantu tim mengelola proses scrum.

Meskipun scrum mendominasi, ada kerangka kerja tangkas lainnya:

  • Kanban bekerja sebagai proses fan-in dan fan-out di mana tim menarik cerita pengguna dari papan masukan dan menyalurkannya melalui proses pengembangan bertahap hingga selesai.
  • Beberapa organisasi mengadopsi pendekatan agile dan waterfall hybrid, menggunakan proses agile untuk aplikasi baru dan waterfall untuk aplikasi lama.
  • Ada juga beberapa kerangka kerja untuk memungkinkan organisasi meningkatkan skala praktik ke beberapa tim.

Sementara kerangka kerja tangkas menentukan proses dan kolaborasi, praktik pengembangan tangkas khusus untuk menangani tugas pengembangan perangkat lunak yang dilakukan selaras dengan kerangka kerja tangkas.

Jadi, misalnya:

  • Beberapa tim mengadopsi pemrograman berpasangan, di mana dua pengembang membuat kode bersama untuk mendorong kode berkualitas lebih tinggi dan untuk memungkinkan lebih banyak pengembang senior untuk membimbing yang lebih muda.
  • Tim yang lebih mahir mengadopsi pengembangan dan otomatisasi yang digerakkan oleh pengujian untuk memastikan fungsionalitas yang mendasari memberikan hasil yang diharapkan.
  • Banyak tim juga mengadopsi standar teknis sehingga interpretasi developer atas cerita pengguna tidak hanya mengarah pada fungsionalitas yang diinginkan tetapi juga memenuhi keamanan, kualitas kode, konvensi penamaan, dan standar teknis lainnya.

Mengapa metodologi tangkas lebih baik