Bagaimana Agile IT Mengubah Industri TI?

Pengarang: Roger Morrison
Tanggal Pembuatan: 20 September 2021
Tanggal Pembaruan: 21 Juni 2024
Anonim
30 Pertanyaan Bodoh untuk Pelatih Agile [Karir TI]
Video: 30 Pertanyaan Bodoh untuk Pelatih Agile [Karir TI]

Isi



Sumber: Darkovujic / Dreamstime.com

Bawa pulang:

Bagi banyak orang, model air terjun pengembangan perangkat lunak telah menjadi standar selama beberapa dekade, tetapi ini sekarang digantikan oleh metodologi Agile yang jauh lebih fleksibel.

Metodologi Agile untuk pengembangan perangkat lunak dapat berdampak positif bagi industri TI. Hasil adopsi metodologi Agile dapat diukur dalam beberapa cara. Perputaran yang lebih cepat dari permintaan perubahan perangkat lunak, bug lebih sedikit, pengukuran kuantitatif kinerja tim dan kemacetan adalah refleksi dari keberhasilan implementasi Agile. Untuk berhasil mengukur dampak Agile, organisasi perlu membandingkan berbagai metrik yang terkait dengan pengembangan pra-Agile dan pasca-Agile. Dampak nyata Agile tidak dapat diukur hanya dengan peningkatan pendapatan atau dengan peningkatan jumlah bug yang diperbaiki. Beberapa parameter internal perlu dipertimbangkan untuk memahami dampak nyata. (Untuk lebih lanjut tentang pengembangan Agile, lihat Pengembangan Agile Software 101.)


Mengapa Agile IT?

Industri TI telah condong ke arah praktik Agile terutama karena kendala model air terjun pengembangan perangkat lunak. Secara umum, telah diamati bahwa perusahaan IT tidak dapat menanggapi permintaan pelanggan yang berubah atau situasi pasar atau mengurangi biaya dengan model air terjun pengembangan perangkat lunak. Bahkan jika kita mengimbangi kemiringan yang luar biasa ini terhadap metodologi Agile dan menganggap beberapa kegembiraan hanya menjadi sensasi, ada banyak umpan balik empiris terhadap model air terjun.

Sederhananya, model air terjun adalah model pengembangan perangkat lunak di mana pekerjaan dilakukan secara berurutan - satu tahap demi tahap. Ada lima fase model ini: persyaratan, desain, implementasi, verifikasi, dan pemeliharaan. Biasanya, setelah satu fase selesai, sulit, jika bukan tidak mungkin, untuk melakukan perubahan ke fase sebelumnya. Jadi, asumsinya adalah persyaratannya cukup banyak diperbaiki. Perbedaan utama dengan model Agile adalah dalam asumsi bahwa tidak akan ada perubahan dalam persyaratan. Agile berasumsi bahwa situasi bisnis akan berubah dan demikian pula persyaratan. Jadi, perangkat lunak dikirimkan dalam ukuran yang lebih kecil daripada ss, sedangkan dalam model air terjun, pengiriman atau rilis pertama dilakukan setelah waktu yang lama. (Untuk lebih lanjut tentang pengembangan, lihat Bagaimana Apache Spark Membantu Pengembangan Aplikasi Cepat.)


Kritik yang paling menonjol terhadap model air terjun adalah anggapannya bahwa tidak akan ada perubahan persyaratan. Asumsi itu cacat dan tidak realistis. Sebagai contoh, pada tahun 2001, sebuah studi pada 1.027 proyek TI di Inggris menunjukkan bahwa asumsi ini adalah satu-satunya alasan terbesar untuk kegagalan proyek-proyek TI.

Dalam contoh lain, Craig Larman, penulis buku "Agile and Iterative Development: A Manager's Guide," telah menunjukkan bagaimana sejumlah proyek yang dilaksanakan oleh Departemen Pertahanan (DoD) menggunakan model air terjun di AS telah gagal mencapai tujuan mereka. Sepanjang 1980-an dan 1990-an, DoD diminta untuk menggunakan model waterfall untuk proyek pengembangan perangkat lunaknya sesuai standar yang diterbitkan dalam DoD STD 2167. Statistik mengejutkan menunjukkan bahwa 75% dari proyek perangkat lunak ini tidak pernah digunakan. Setelah laporan ini, sebuah gugus tugas diluncurkan di bawah Dr. Frederick Brooks, seorang ahli rekayasa perangkat lunak yang terkenal. Gugus tugas keluar dengan laporan yang berkomentar “DoD STD 2167 juga membutuhkan perbaikan radikal untuk mencerminkan praktik terbaik modern. Perkembangan evolusi adalah yang terbaik secara teknis, menghemat waktu dan uang. "

Empat asumsi berikut tentang model air terjun telah gagal dalam skenario dunia nyata:

  • Persyaratan yang diberikan didefinisikan dengan cukup baik sehingga tidak akan berubah secara signifikan.
  • Bahkan jika persyaratan berubah selama fase pengembangan, mereka akan cukup kecil untuk ditampung dalam siklus pengembangan.
  • Integrasi sistem, yang terjadi setelah pengiriman perangkat lunak, akan berjalan sesuai rencana.
  • Inovasi perangkat lunak dan upaya yang diperlukan untuk berinovasi akan berjalan sesuai dengan jadwal yang direncanakan dan dapat diprediksi.

Bagaimana Metodologi Agile Mengatasi Masalah Model Air Terjun?

Metodologi Agile secara fundamental berbeda dari model air terjun dan yang jelas dari asumsi:

  • Tidak seorang pun, bahkan pelanggan, dapat sepenuhnya mengetahui atau memahami persyaratan. Tidak ada jaminan bahwa persyaratan tidak akan berubah.
  • Perubahan persyaratan mungkin tidak kecil dan dapat dikelola. Bahkan, mereka akan datang dalam berbagai ukuran dan akan terus berdatangan. Jadi, perangkat lunak akan dikirimkan sedikit demi sedikit untuk melacak perubahan.

Bagaimana Agile Mempengaruhi Industri TI?

Agile diadopsi di banyak tempat, sementara banyak perusahaan membuat rencana untuk mengadopsi Agile. Meskipun Agile jelas telah membuat perubahan mendasar pada industri TI, fakta dan angka masih sedikit sulit diperoleh. Tetapi dampak Agile dapat dipahami dengan studi kasus British Telecom (BT) yang diberikan di bawah ini.

Tanpa Bug, Tanpa Stres - Panduan Langkah Demi Langkah Anda untuk Membuat Perangkat Lunak yang Mengubah Hidup Tanpa Menghancurkan Kehidupan Anda


Anda tidak dapat meningkatkan keterampilan pemrograman Anda ketika tidak ada yang peduli dengan kualitas perangkat lunak.

Alasan BT Beralih ke Praktek Agile

BT mulai mengalami sejumlah masalah dengan praktik pengembangan perangkat lunaknya pada tahun 2004. BT mengembangkan sejumlah proyek perangkat lunak, baik yang sederhana maupun yang kompleks. Banyak proyek perangkat lunak tidak dapat mengembangkan kualitas output dalam kerangka waktu yang disepakati. BT menemukan bahwa masalah berakar pada model air terjun. Jadi, memperkuat model air terjun tidak akan membantu. Penyebab utama masalah diberikan di bawah ini:

Manajemen Persyaratan yang Buruk

  • Terlalu banyak persyaratan yang harus dipenuhi dalam waktu yang terlalu terbatas.
  • Banyak persyaratan yang tidak relevan dengan kebutuhan bisnis.
  • Hampir semua, jika tidak semua persyaratan diberi status prioritas tinggi.
  • Persyaratan mewakili kebutuhan bisnis saat ini tanpa memperhatikan skenario masa depan. Itu membuka kemungkinan perubahan perangkat lunak di masa depan.

Desain Perangkat Lunak Buruk

  • Mengingat banyaknya persyaratan, desainer menghabiskan terlalu banyak waktu hanya mencoba mencari tahu apa arti persyaratan. Hanya sedikit waktu yang tersisa untuk desain yang sebenarnya.
  • Analis persyaratan pindah ke tugas lain, membawa serta pengetahuan diam-diam yang tidak tertulis itu.
  • Dua faktor di atas menghasilkan desain yang buruk. Desainer harus tetap memberikan sesuai dengan timeline aslinya.

Kendala Pembangunan

Pengkodean terburu-buru dan berkualitas buruk karena desain perangkat lunak yang cacat. Pengembang akan menyadari bahwa desain perangkat lunak yang buruk akan menghasilkan kode yang buruk, tetapi tetap harus memenuhi batas waktu yang disepakati. Banyak bug akan dilaporkan selama integrasi karena tes unit dan uji regresi tidak dijalankan.

Pada saat perangkat lunak digunakan, pelanggan mencatat bahwa persyaratannya telah berubah dan begitu pula skenario bisnisnya. Perangkat lunak ini juga memiliki banyak masalah. Secara efektif, seluruh upaya pengembangan perangkat lunak sekarang dianggap pemborosan.

Apa yang BT lakukan untuk mengatasi masalah di atas?

BT menyadari bahwa memperkuat model air terjun bukanlah jawaban untuk masalah. Itu membutuhkan pendekatan baru. Jadi, ia memutuskan untuk menerapkan pendekatan Agile. Di bawah pendekatan baru, hal-hal berikut diputuskan:

  • Alih-alih siklus pengembangan 12 bulan, BT sekarang akan memberikan perangkat lunak yang bisa diterapkan dalam siklus 90 hari. Idenya adalah untuk fokus pada satu atau dua masalah bisnis dan target untuk memberikan solusi perangkat lunak dalam waktu 90 hari. Awal siklus ini ditandai oleh diskusi yang intens antara berbagai pemangku kepentingan sehingga persyaratan diidentifikasi, dianalisis, dan diprioritaskan dengan jelas.
  • Targetnya adalah untuk memberikan nilai bisnis yang jelas dan nyata. Pelanggan internal berada di bawah tekanan untuk memberikan persyaratan yang jelas. Jadi, alih-alih tujuan yang tidak jelas, cerita pengguna diberikan dengan kriteria penerimaan yang jelas.
  • Perangkat lunak yang akan dikirim akan sepenuhnya diuji dan didokumentasikan. Perangkat lunak akan melalui tes integrasi yang sering untuk mengidentifikasi masalah sebelumnya.

Dengan pendekatan Agile, BT dapat beradaptasi dengan perubahan persyaratan atau situasi bisnis dengan lebih mudah. Kualitas kode ditingkatkan dan bug dasar menit terakhir diatasi.

Kesimpulan

Agile, untuk semua kelebihan dan hype di sekitarnya, masih pada tahap di mana potensinya belum sepenuhnya terwujud. Ini karena banyak organisasi mengkustomisasi pendekatan tersebut sejauh memodifikasi prinsip-prinsip aslinya. Akibatnya, model air terjun membuat comeback dalam beberapa kasus. Sementara kustomisasi akan terus berlanjut, penting untuk mempertahankan prinsip dasar Agiles. Banyak organisasi mengklaim sebagai Agile sepenuhnya, tetapi mereka masih memiliki beberapa cara untuk menjadi perusahaan Agile benar-benar.