Pengembangan Perangkat Lunak Adaptif - Praktik

Praktik Pengembangan Perangkat Lunak Adaptif didorong oleh keyakinan pada adaptasi berkelanjutan, dengan siklus hidup yang diperlengkapi untuk menerima perubahan berkelanjutan sebagai norma.

Siklus Hidup Pengembangan Perangkat Lunak Adaptif didedikasikan untuk -

  • Pembelajaran berkelanjutan
  • Ubah orientasi
  • Re-evaluation
  • Mengintip masa depan yang tidak pasti
  • Kolaborasi yang intens di antara pengembang, manajemen, dan pelanggan

SDLC adaptif

Pengembangan Perangkat Lunak Adaptif menggabungkan RAD dengan Praktik Terbaik Rekayasa Perangkat Lunak, seperti -

  • Inisiasi proyek.
  • Perencanaan siklus adaptif.
  • Rekayasa komponen serentak.
  • Ulasan kualitas.
  • QA akhir dan rilis.

Praktik Pengembangan Perangkat Lunak Adaptif dapat diilustrasikan sebagai berikut -

Seperti yang diilustrasikan di atas, praktik Pengembangan Perangkat Lunak Adaptif tersebar di tiga fase sebagai berikut -

  • Berspekulasi - Inisiasi dan perencanaan

    • Inisiasi Proyek

    • Menetapkan kotak waktu untuk keseluruhan proyek

    • Tentukan jumlah iterasi dan tetapkan kotak waktu untuk masing-masing

    • Kembangkan tema atau tujuan untuk setiap iterasi

    • Tetapkan fitur untuk setiap iterasi

  • Collaborate - Pengembangan fitur secara bersamaan

    • Kolaborasi untuk tim terdistribusi

    • Kolaborasi untuk proyek kecil

    • Kolaborasi untuk proyek yang lebih besar

  • Learn - Kualitas Review

    • Kualitas hasil dari perspektif pelanggan

    • Kualitas hasil dari perspektif teknis

    • Fungsi tim pengiriman dan anggota tim praktik memanfaatkan

    • Status proyek

Berspekulasi - Inisiasi dan Perencanaan

Dalam Pengembangan Perangkat Lunak Adaptif, fase spekulasi memiliki dua aktivitas -

  • Initiation
  • Planning

Spekulasi memiliki lima praktik yang dapat dijalankan secara berulang selama fase inisiasi dan perencanaan. Mereka adalah -

  • Inisiasi proyek
  • Menetapkan kotak waktu untuk keseluruhan proyek
  • Tentukan jumlah iterasi dan tetapkan kotak waktu untuk masing-masing
  • Kembangkan tema atau tujuan untuk setiap iterasi
  • Tetapkan fitur untuk setiap iterasi

Inisiasi Proyek

Inisiasi Proyek melibatkan -

  • Menetapkan misi dan tujuan proyek
  • Memahami kendala
  • Membentuk organisasi proyek
  • Mengidentifikasi dan menguraikan persyaratan
  • Membuat perkiraan ukuran dan cakupan awal
  • Mengidentifikasi risiko proyek utama

Data inisiasi proyek harus dikumpulkan dalam sesi JAD pendahuluan, dengan mempertimbangkan kecepatan sebagai aspek utama. Inisiasi dapat diselesaikan dalam upaya dua hingga lima hari terkonsentrasi untuk proyek berukuran kecil hingga menengah, atau upaya dua hingga tiga minggu untuk proyek yang lebih besar.

Selama sesi JAD, persyaratan dikumpulkan dengan cukup detail untuk mengidentifikasi fitur dan menetapkan gambaran umum tentang objek, data, atau model arsitektur lainnya.

Menetapkan Kotak Waktu untuk Keseluruhan Proyek

Kotak waktu untuk keseluruhan proyek harus ditetapkan, berdasarkan ruang lingkup, persyaratan set fitur, perkiraan, dan ketersediaan sumber daya yang dihasilkan dari pekerjaan inisiasi proyek.

Seperti yang Anda ketahui, Berspekulasi tidak mengabaikan perkiraan, tetapi itu hanya berarti menerima perkiraan itu bisa salah.

Iterasi dan Time-box

Tentukan jumlah iterasi dan panjang iterasi individu berdasarkan cakupan proyek secara keseluruhan dan tingkat ketidakpastian.

Untuk aplikasi berukuran kecil hingga sedang -

  • Iterasi biasanya bervariasi dari empat hingga delapan minggu.
  • Beberapa proyek bekerja paling baik dengan iterasi dua minggu.
  • Beberapa proyek mungkin membutuhkan lebih dari delapan minggu.

Pilih waktu, berdasarkan apa yang cocok untuk Anda. Setelah Anda memutuskan jumlah dan panjang setiap iterasi, tetapkan jadwal untuk setiap iterasi.

Kembangkan Tema atau Tujuan

Anggota tim harus mengembangkan tema atau tujuan untuk setiap iterasi. Ini mirip dengan Sprint Goal di Scrum. Setiap iterasi harus memberikan sekumpulan fitur yang dapat mendemonstrasikan fungsionalitas produk yang membuat produk terlihat oleh pelanggan untuk memungkinkan tinjauan dan umpan balik.

Dalam iterasi, build harus memberikan fitur kerja setiap hari yang memungkinkan proses integrasi dan membuat produk terlihat oleh tim pengembangan. Pengujian harus menjadi bagian integral yang berkelanjutan dari pengembangan fitur. Ini tidak boleh ditunda sampai akhir proyek.

Tetapkan Fitur

Pengembang dan pelanggan harus bersama-sama menetapkan fitur untuk setiap iterasi. Kriteria yang paling penting untuk penetapan fitur ini adalah bahwa setiap iterasi harus memberikan sekumpulan fitur yang terlihat dengan fungsionalitas yang memadai kepada pelanggan.

Selama penugasan fitur ke iterasi -

  • Tim pengembang harus membuat perkiraan fitur, risiko, dan ketergantungan dan memberikannya kepada pelanggan.

  • Pelanggan harus memutuskan prioritas fitur, menggunakan informasi yang disediakan oleh tim pengembangan.

Dengan demikian, perencanaan iterasi berbasis fitur dan dilakukan sebagai tim dengan pengembang dan pelanggan. Pengalaman menunjukkan bahwa jenis perencanaan ini memberikan pemahaman yang lebih baik tentang proyek daripada perencanaan berbasis tugas oleh manajer proyek. Selanjutnya, perencanaan berbasis fitur mencerminkan keunikan setiap proyek.

Kolaborasi ─ Pengembangan Fitur Bersamaan

Selama fase Kolaborasi, fokusnya ada pada pengembangan. Fase Kolaborasi memiliki dua aktivitas -

  • Tim pengembangan berkolaborasi dan memberikan perangkat lunak yang berfungsi.

  • Manajer proyek memfasilitasi kolaborasi dan kegiatan pengembangan secara bersamaan.

Kolaborasi adalah tindakan kreasi bersama yang mencakup tim pengembangan, pelanggan, dan manajer. Kreasi bersama dipupuk oleh kepercayaan dan rasa hormat.

Tim harus berkolaborasi -

  • Masalah teknis
  • Persyaratan bisnis
  • Pengambilan keputusan yang cepat

Berikut adalah praktik yang relevan dengan fase Kolaborasi dalam Pengembangan Perangkat Lunak Adaptif -

  • Kolaborasi untuk tim terdistribusi
  • Kolaborasi untuk proyek kecil
  • Kolaborasi untuk proyek yang lebih besar

Kolaborasi untuk Tim Terdistribusi

Dalam proyek yang melibatkan tim terdistribusi, berikut ini harus dipertimbangkan -

  • Memvariasikan mitra aliansi
  • Pengetahuan berbasis luas
  • Cara orang berinteraksi
  • Cara mereka mengelola saling ketergantungan

Kolaborasi untuk Proyek yang Lebih Kecil

Dalam proyek yang lebih kecil, ketika anggota tim bekerja dalam jarak dekat, Kolaborasi dengan obrolan informal di lorong dan coretan papan tulis harus didorong, karena ini terbukti efektif.

Kolaborasi untuk Proyek yang Lebih Besar

Proyek yang lebih besar membutuhkan praktik tambahan, alat kolaborasi, dan interaksi manajer proyek dan harus diatur berdasarkan kontekstual.

Learn - Review Kualitas

Pengembangan Perangkat Lunak Adaptif mendorong konsep 'Eksperimen dan Belajar'.

Belajar dari kesalahan dan eksperimen mengharuskan anggota tim berbagi kode dan artefak yang telah selesai sebagian lebih awal, untuk -

  • Temukan kesalahan
  • Belajar dari mereka
  • Kurangi pengerjaan ulang dengan menemukan masalah kecil sebelum menjadi masalah besar

Di akhir setiap iterasi pengembangan, ada empat kategori umum untuk dipelajari -

  • Kualitas hasil dari perspektif pelanggan
  • Kualitas hasil dari perspektif teknis
  • Fungsi tim pengiriman dan tim praktik
  • Status proyek

Kualitas Hasil dari Perspektif Pelanggan

Dalam proyek Pengembangan Perangkat Lunak Adaptif, mendapatkan umpan balik dari pelanggan adalah prioritas pertama. Praktik yang direkomendasikan untuk ini adalah grup fokus pelanggan. Sesi ini dirancang untuk mengeksplorasi model kerja aplikasi dan mencatat permintaan perubahan pelanggan.

Sesi kelompok fokus pelanggan adalah sesi yang difasilitasi, mirip dengan sesi jad, tetapi daripada menghasilkan persyaratan atau menentukan rencana proyek, mereka dirancang untuk meninjau aplikasi itu sendiri. Pelanggan memberikan umpan balik tentang perangkat lunak yang berfungsi yang dihasilkan dari sebuah iterasi.

Kualitas Hasil dari Perspektif Teknis

Dalam proyek Pengembangan Perangkat Lunak Adaptif, tinjauan berkala dari artefak teknis harus dianggap penting. Tinjauan Kode harus dilakukan secara terus menerus. Tinjauan artefak teknis lainnya, seperti arsitektur teknis dapat dilakukan setiap minggu atau di akhir iterasi.

Dalam proyek Pengembangan Perangkat Lunak Adaptif, tim harus memantau kinerjanya sendiri secara berkala. Retrospektif mendorong tim untuk belajar tentang diri mereka sendiri dan pekerjaan mereka, bersama sebagai sebuah tim.

Retrospektif akhir pengulangan memfasilitasi peninjauan mandiri kinerja tim secara berkala seperti -

  • Tentukan apa yang tidak berhasil.
  • Apa yang Tim perlu lakukan lebih banyak.
  • Apa yang Tim perlu lakukan lebih sedikit.

Status Proyek

Tinjauan status proyek membantu dalam merencanakan pekerjaan lebih lanjut. Dalam proyek pengembangan perangkat lunak adaptif, penentuan status proyek adalah pendekatan berbasis fitur, akhir setiap iterasi ditandai dengan fitur yang selesai sehingga perangkat lunak berfungsi.

Tinjauan Status Proyek harus mencakup -

  • Dimana proyeknya?
  • Di mana proyek versus rencana?
  • Dimana proyeknya?

Karena rencana dalam proyek Pengembangan Perangkat Lunak Adaptif bersifat spekulatif, lebih dari pertanyaan 2 di atas, pertanyaan 3 adalah penting. Artinya, tim proyek dan pelanggan perlu terus bertanya pada diri sendiri, "Apa yang telah kita pelajari sejauh ini, dan apakah hal itu mengubah perspektif kita tentang ke mana kita harus pergi?"