Apa itu metodologi tangkas? Pembangunan perisian moden dijelaskan

Setiap organisasi teknologi hari ini nampaknya mengamalkan metodologi tangkas untuk pengembangan perisian, atau versi daripadanya. Atau sekurang-kurangnya mereka percaya bahawa mereka melakukannya. Sama ada anda baru dalam pengembangan aplikasi lincah atau anda mempelajari pengembangan perisian puluhan tahun yang lalu menggunakan metodologi pengembangan perisian waterfall, hari ini karya anda sekurang-kurangnya dipengaruhi oleh metodologi tangkas.

Tetapi apa itu metodologi tangkas, dan bagaimana cara itu harus dipraktikkan dalam pengembangan perisian? Bagaimana perkembangan tangkas berbeza dari air terjun dalam praktiknya? Apakah kitaran hidup pengembangan perisian tangkas, atau SDLC tangkas? Dan apa itu scrum agile berbanding Kanban dan model tangkas lain? 

Agile dilancarkan secara rasmi pada tahun 2001 ketika 17 ahli teknologi menyusun Manifesto Agile. Mereka menulis empat prinsip utama untuk pengurusan projek tangkas, dengan tujuan mengembangkan perisian yang lebih baik:

  • Individu dan interaksi terhadap proses dan alat
  • Perisian yang berfungsi melebihi dokumentasi yang komprehensif
  • Kerjasama pelanggan atas rundingan kontrak
  • Menanggapi perubahan mengikut rancangan

Sebelum tangkas: Era metodologi air terjun

Tangan lama seperti saya mengingati zaman ketika metodologi air terjun adalah standard emas untuk pengembangan perisian. Proses pengembangan perisian memerlukan banyak dokumentasi di hadapan sebelum pengekodan dimulakan. Seseorang, biasanya penganalisis perniagaan, pertama kali menulis dokumen keperluan perniagaan yang mencatat semua perniagaan yang diperlukan dalam aplikasi. Dokumen keperluan perniagaan ini panjang, memperincikan segalanya: strategi keseluruhan, spesifikasi fungsional yang komprehensif, dan reka bentuk antara muka pengguna visual.

Ahli teknologi mengambil dokumen keperluan perniagaan dan mengembangkan dokumen keperluan teknikal mereka sendiri. Dokumen ini menentukan arsitektur aplikasi, struktur data, reka bentuk fungsional berorientasi objek, antara muka pengguna, dan keperluan lain yang tidak berfungsi.

Proses pengembangan perisian air terjun ini akhirnya akan memulakan pengekodan, kemudian penyatuan, dan akhirnya pengujian sebelum aplikasi dianggap produksi siap. Seluruh proses boleh memakan masa beberapa tahun dengan mudah.

Kami para pemaju diharapkan dapat mengetahui "spesifikasi", seperti yang disebut dokumentasi lengkap, begitu juga dengan pengarang dokumen tersebut, dan kami sering dihukum sekiranya kami lupa untuk melaksanakan dengan betul perincian utama yang dijelaskan pada halaman 77 dari 200- dokumen halaman.

Pada masa itu, pembangunan perisian itu sendiri juga tidak mudah. Banyak alat pembangunan memerlukan latihan khusus, dan tidak ada tempat yang berdekatan dengan sumber terbuka atau komponen perisian komersial, API, dan perkhidmatan web yang ada sekarang. Kami harus mengembangkan perkara-perkara peringkat rendah seperti membuka sambungan pangkalan data dan memproses data kami dengan multithreading.

Untuk aplikasi asas sekalipun, pasukannya besar dan alat komunikasi terhad. Spesifikasi teknikal kami sesuai dengan kami, dan kami memanfaatkannya seperti Alkitab. Sekiranya keperluan berubah, kami akan meletakkan pemimpin perniagaan melalui proses tinjauan yang panjang dan berhenti kerana menyampaikan perubahan di seluruh pasukan dan memperbaiki kod itu mahal.

Oleh kerana perisian ini dikembangkan berdasarkan seni bina teknikal, artifak peringkat rendah dikembangkan terlebih dahulu dan artifak bergantung sesudahnya. Tugas diberikan berdasarkan kemahiran, dan biasa bagi jurutera pangkalan data untuk membuat jadual dan artifak pangkalan data lain terlebih dahulu, diikuti oleh pembangun aplikasi yang mengkodkan fungsi dan logik perniagaan, dan akhirnya antara muka pengguna dilapisi. Ia mengambil masa berbulan-bulan sebelum ada yang melihat aplikasi itu berfungsi dan pada masa itu, pihak berkepentingan semakin gelisah dan sering menjadi lebih bijak mengenai apa yang mereka mahukan. Tidak hairanlah jika melaksanakan perubahan itu sangat mahal!

Tidak semua yang anda letakkan di depan pengguna berfungsi seperti yang diharapkan. Kadang kala, pengguna sama sekali tidak menggunakan ciri. Pada masa yang lain, kemampuan berjaya secara meluas tetapi memerlukan perancangan semula untuk menyokong skalabilitas dan prestasi yang diperlukan. Di dunia air terjun, anda hanya mengetahui perkara-perkara ini setelah perisian itu disebarkan, setelah kitaran pengembangan yang panjang.

Video berkaitan: Bagaimana metodologi tangkas berfungsi

Semua orang nampaknya berbicara mengenai pengembangan perisian yang tangkas, tetapi banyak organisasi tidak memiliki pemahaman yang tegas mengenai bagaimana proses itu berjalan. Tonton video lima minit ini untuk mendapatkan kelajuan yang pantas.

Penting untuk pembangunan perisian yang tangkas

Dicipta pada tahun 1970, metodologi air terjun itu revolusioner kerana membawa disiplin untuk pengembangan perisian untuk memastikan ada spesifikasi yang jelas untuk diikuti. Ini berdasarkan kaedah pembuatan air terjun yang berasal dari inovasi lini pemasangan Henry Ford pada tahun 1913, yang memberikan kepastian mengenai setiap langkah dalam proses pengeluaran untuk menjamin bahawa produk akhir sesuai dengan apa yang ditentukan.

Ketika metodologi waterfall datang ke dunia perisian, sistem pengkomputeran dan aplikasinya biasanya kompleks dan monolitik, memerlukan disiplin dan hasil yang jelas untuk disampaikan. Keperluan juga berubah perlahan berbanding hari ini, jadi usaha berskala besar kurang bermasalah. Sebenarnya, sistem dibangun dengan anggapan mereka tidak akan berubah tetapi akan menjadi kapal perang yang berterusan. Jangka masa bertahun-tahun biasa tidak hanya dalam pengembangan perisian tetapi juga dalam aktiviti pembuatan dan perusahaan lain. Tetapi ketegaran air terjun menjadi tumit Achilles di era internet, di mana kelajuan dan fleksibiliti diperlukan.

Metodologi pengembangan perisian mula berubah ketika pembangun mula mengerjakan aplikasi internet. Sebilangan besar kerja awal dilakukan pada permulaan di mana pasukan lebih kecil, berpasangan, dan sering tidak mempunyai latar belakang sains komputer tradisional. Terdapat tekanan kewangan dan persaingan untuk membawa laman web, aplikasi, dan kemampuan baru untuk memasarkan lebih cepat. Alat dan platform pembangunan berubah dengan pantas sebagai tindak balas.

Ini menyebabkan banyak dari kita bekerja di syarikat permulaan untuk mempersoalkan metodologi air terjun dan mencari jalan untuk menjadi lebih cekap. Kami tidak mampu melakukan semua dokumentasi terperinci di muka, dan kami memerlukan proses yang lebih berulang dan kolaboratif. Kami masih memperdebatkan perubahan pada syarat, tetapi kami lebih terbuka untuk bereksperimen dan menyesuaikan diri dengan keperluan pengguna akhir. Organisasi kami kurang tersusun dan aplikasi kami kurang kompleks daripada sistem warisan perusahaan, jadi kami lebih terbuka untuk membangun berbanding membeli aplikasi. Lebih penting lagi, kami berusaha mengembangkan perniagaan, jadi apabila pengguna kami memberitahu kami bahawa sesuatu tidak berfungsi, kami lebih kerap memilih untuk tidak mendengarkannya.

Kemahiran dan kemampuan kita untuk berinovasi menjadi penting secara strategik. Anda boleh mengumpulkan semua wang yang anda mahukan, tetapi anda tidak dapat menarik pembangun perisian berbakat yang dapat bekerjasama dengan teknologi internet yang berubah dengan cepat jika anda akan memperlakukan mereka sebagai pengekod pelanggan yang patuh mengikuti "spesifikasi." Kami menolak pengurus projek yang datang dengan jadual akhir-ke-akhir yang menerangkan apa yang harus kita kembangkan, kapan aplikasi harus dihantar, dan kadang-kadang bahkan bagaimana struktur kodnya. Kami sangat teruk apabila berjaya menjadualkan jadual tiga bulan dan enam bulan yang digubal dan dikemas kini oleh pengurus projek air terjun.

Sebagai gantinya, kami mula memberitahu mereka bagaimana aplikasi internet perlu direkayasa, dan kami memberikan hasil mengikut jadual yang kami buat secara berulang-ulang. Ternyata kami tidak terlalu buruk dalam menyampaikan apa yang kami katakan ketika kami berkomitmen untuk melakukannya dalam selang waktu satu minggu hingga empat minggu.

Pada tahun 2001, sekumpulan pembangun perisian yang berpengalaman berkumpul dan menyedari bahawa mereka secara kolektif mempraktikkan pengembangan perisian secara berbeza daripada metodologi air terjun klasik. Dan mereka tidak semua dalam permulaan. Kumpulan ini, yang merangkumi pencahayaan teknologi Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber, dan Jeff Sutherland, datang dengan Manifesto Agile yang mendokumentasikan kepercayaan bersama mereka tentang bagaimana proses pengembangan perisian moden harus beroperasi. Mereka menekankan kolaborasi mengenai dokumentasi, organisasi diri daripada amalan pengurusan yang kaku, dan kemampuan untuk mengurus perubahan berterusan daripada mengunci diri anda dalam proses pembangunan air terjun yang tegar.

Dari prinsip-prinsip tersebut lahirlah metodologi tangkas untuk pengembangan perisian.

Peranan dalam metodologi tangkas

Proses pengembangan perisian yang tangkas selalu dimulakan dengan menentukan pengguna dan mendokumentasikan pernyataan visi mengenai skop masalah, peluang, dan nilai yang harus ditangani. Pemilik produk menangkap visi ini dan bekerjasama dengan pasukan (atau pasukan) pelbagai disiplin untuk mewujudkan visi ini. Berikut adalah peranan dalam proses tersebut.

Pengguna

Proses lincah selalu dimulakan dengan mempertimbangkan pengguna atau pelanggan. Hari ini, kita sering menentukannya dengan personaliti pengguna untuk menggambarkan peranan yang berbeza dalam aliran kerja yang disokong oleh perisian atau pelbagai jenis keperluan dan tingkah laku pelanggan.

Pemilik produk

Proses pengembangan lincah itu sendiri bermula dengan seseorang yang harus menjadi suara pelanggan, termasuk mana-mana pihak berkepentingan dalaman. Orang itu menyusun semua pandangan, idea, dan maklum balas untuk mewujudkan visi produk. Penglihatan produk ini sering pendek dan mudah, tetapi mereka melukis gambaran tentang siapa pelanggan, nilai apa yang ditangani, dan strategi bagaimana mengatasinya. Saya dapat membayangkan visi asal Google kelihatan seperti "Mari kita mempermudah sesiapa sahaja yang mempunyai akses internet untuk mencari laman web dan laman web yang relevan dengan antara muka yang mudah didorong oleh kata kunci dan algoritma yang menempatkan sumber yang bereputasi lebih tinggi dalam hasil carian."

Kami memanggil orang ini sebagai pemilik produk . Tanggungjawabnya adalah untuk menentukan visi ini dan kemudian bekerjasama dengan pasukan pembangunan untuk mewujudkannya.

Untuk bekerjasama dengan pasukan pengembangan, pemilik produk menguraikan visi produk menjadi rangkaian cerita pengguna yang menjelaskan dengan lebih terperinci siapa pengguna sasaran, masalah apa yang diselesaikan untuk mereka, mengapa penyelesaiannya penting bagi mereka, dan apa kekangan dan kriteria penerimaan yang menentukan penyelesaiannya. Cerita pengguna ini diutamakan oleh pemilik produk, ditinjau oleh pasukan untuk memastikan mereka mempunyai pemahaman bersama mengenai apa yang diminta dari mereka.

Pasukan pembangunan perisian

Secara tangkas, pasukan pengembangan dan tanggungjawab anggotanya berbeza daripada yang ada dalam pembangunan perisian tradisional.

Pasukan terdiri daripada pelbagai bidang, terdiri daripada sekumpulan orang yang mempunyai kemahiran untuk menyelesaikan tugas. Kerana fokusnya adalah pada penyampaian perisian yang berfungsi, pasukan harus menyelesaikan aplikasi yang berfungsi dari ujung ke ujung. Oleh itu, pangkalan data, logik perniagaan, dan antara muka pengguna dari sebahagian aplikasi dikembangkan dan kemudian ditunjuk - bukan keseluruhan aplikasi. Untuk melakukan ini, ahli pasukan harus bekerjasama. Mereka sering bertemu untuk memastikan semua orang selaras dengan apa yang mereka buat, siapa yang melakukan apa, dan bagaimana perisian itu dikembangkan.

Sebagai tambahan kepada pembangun, pasukan pengembangan perisian boleh merangkumi jurutera jaminan kualiti (QA), jurutera lain (seperti untuk pangkalan data dan sistem back-end), pereka, dan penganalisis, bergantung pada jenis projek perisian.

Scrum, Kanban, dan kerangka tangkas lain

Banyak kerangka kerja tangkas yang memberikan spesifik mengenai proses pembangunan dan amalan pengembangan tangkas, selaras dengan kitaran hidup pengembangan perisian.

Kerangka tangkas yang paling popular dipanggil scrum . Ia memfokuskan pada irama penghantaran yang disebut struktur pecut dan pertemuan yang merangkumi yang berikut:

  • Perancangan - di mana keutamaan pecut dikenal pasti
  • Komitmen - di mana pasukan mengkaji senarai atau backlog cerita pengguna dan memutuskan berapa banyak kerja yang dapat dilakukan dalam jangka masa pecut 
  • Mesyuarat berdiri setiap hari - supaya pasukan dapat menyampaikan kemas kini mengenai status dan strategi pengembangan mereka)

Sprint diakhiri dengan pertemuan demo di mana fungsi ditunjukkan kepada pemilik produk, diikuti dengan pertemuan retrospektif di mana pasukan membincangkan apa yang berjalan dengan baik dan apa yang perlu diperbaiki dalam proses mereka.

Banyak organisasi menggunakan master scrum atau jurulatih untuk membantu pasukan menguruskan proses scrum.

Walaupun scrum mendominasi, ada kerangka tangkas lain:

  • Kanban berfungsi sebagai proses fan-in dan fan-out di mana pasukan menarik kisah pengguna dari papan pengambilan dan menyalurkannya melalui proses pembangunan berperingkat sehingga selesai.
  • Sebilangan organisasi menggunakan pendekatan tangkas hibrid dan air terjun, menggunakan proses tangkas untuk aplikasi baru dan air terjun untuk yang lama.
  • Terdapat juga beberapa kerangka kerja untuk membolehkan organisasi memperluas latihan kepada beberapa pasukan.

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

Jadi, sebagai contoh:

  • Beberapa pasukan menggunakan pengaturcaraan pasangan, di mana dua pembangun membuat kod bersama-sama untuk memacu kod berkualiti tinggi dan untuk membolehkan lebih banyak pembangun senior mentor yang lebih muda.
  • Pasukan yang lebih maju menggunakan pembangunan dan automasi berdasarkan ujian untuk memastikan fungsi yang mendasari memberikan hasil yang diharapkan.
  • Banyak pasukan juga mengadopsi standard teknikal sehingga tafsiran pemaju mengenai kisah pengguna tidak hanya membawa kepada fungsi yang diinginkan tetapi juga memenuhi keselamatan, kualiti kod, konvensyen penamaan, dan standard teknikal lain.

Mengapa metodologi tangkas lebih baik