Pengembangan Adaptif S / W - Panduan Cepat
Apa itu Agile?
Dalam istilah sastra, kata “agile” berarti seseorang yang dapat bergerak dengan cepat dan mudah atau seseorang yang dapat berpikir dan bertindak dengan cepat dan jelas. Dalam bisnis, “agile” digunakan untuk mendeskripsikan cara-cara merencanakan dan melakukan pekerjaan dimana dipahami bahwa membuat perubahan sesuai kebutuhan merupakan bagian penting dari pekerjaan. "Kelincahan" bisnis berarti bahwa perusahaan selalu berada dalam posisi untuk memperhitungkan perubahan pasar.
Dalam pengembangan perangkat lunak, istilah "tangkas" diadaptasi menjadi "kemampuan untuk menanggapi perubahan - perubahan dari Persyaratan, Teknologi, dan Orang".
Manifesto Agile
Agile Manifesto diterbitkan oleh tim pengembang perangkat lunak pada tahun 2001, menyoroti pentingnya tim pengembangan, mengakomodasi perubahan persyaratan dan keterlibatan pelanggan.
Manifesto Agile adalah -
Kami menemukan cara yang lebih baik untuk mengembangkan perangkat lunak dengan melakukannya dan membantu orang lain melakukannya. Melalui pekerjaan ini, kami menjadi menghargai -
- Individu dan interaksi atas proses dan alat.
- Bekerja perangkat lunak di atas dokumentasi yang komprehensif.
- Kolaborasi pelanggan melalui negosiasi kontrak.
- Menanggapi perubahan mengikuti rencana.
Artinya, meskipun ada nilai di item di sebelah kanan, kami lebih menghargai item di sebelah kiri.
Karakteristik Agility
Berikut adalah karakteristik Agility -
Agility in Agile Software Development berfokus pada budaya seluruh tim dengan tim multidisiplin lintas fungsi yang diberdayakan dan diatur sendiri.
Ini memupuk tanggung jawab dan akuntabilitas bersama.
Memfasilitasi komunikasi yang efektif dan kolaborasi berkelanjutan.
Pendekatan seluruh tim menghindari penundaan dan waktu tunggu.
Pengiriman yang sering dan berkelanjutan memastikan umpan balik cepat yang pada gilirannya memungkinkan tim menyelaraskan dengan persyaratan.
Kolaborasi memfasilitasi penggabungan berbagai perspektif tepat waktu dalam implementasi, perbaikan kerusakan, dan perubahan akomodatif.
Kemajuan konstan, berkelanjutan, dan dapat diprediksi dengan menekankan transparansi.
Metodologi Agile
Implementasi awal dari metode Agile termasuk Rational Unified Process, Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development, dan Dynamic Systems Development Method (DSDM). Ini sekarang secara kolektif disebut sebagai metodologi Agile, setelah manifesto Agile diterbitkan pada tahun 2001.
Dalam tutorial ini, kita akan mempelajari Metodologi Agile - Adaptive Software Development.
Apa itu Pengembangan Perangkat Lunak Adaptif?
Pengembangan Perangkat Lunak Adaptif adalah langkah menuju praktik adaptif, meninggalkan praktik deterministik dalam konteks sistem yang kompleks dan lingkungan yang kompleks. Pengembangan Perangkat Lunak Adaptif berfokus pada kolaborasi dan pembelajaran sebagai teknik untuk membangun sistem yang kompleks. Ini berevolusi dari praktik terbaik Pengembangan Aplikasi Cepat (RAD) dan Siklus Hidup Evolusioner. Pengembangan Perangkat Lunak Adaptif kemudian diperluas untuk memasukkan pendekatan adaptif untuk manajemen, dengan spekulasi menggantikan Perencanaan.
Jim Highsmith menerbitkan sebuah buku tentang Adaptive Software Development pada tahun 2000. Dalam kata-kata Highsmith -
“Pengembangan Perangkat Lunak Adaptif adalah siklus seperti model evolusi, dengan nama fase Berspekulasi, berkolaborasi, belajar mencerminkan dunia tak terduga dari sistem yang semakin kompleks. Perkembangan adaptif lebih jauh dari warisan evolusionernya dalam dua cara utama. Pertama, ia secara eksplisit menggantikan determinisme dengan kemunculan. Kedua, ini melampaui perubahan Siklus Hidup ke perubahan yang lebih dalam dalam gaya manajemen. "
Model Siklus Hidup Pengembangan Perangkat Lunak (SDLC) adalah kerangka kerja yang menggambarkan aktivitas yang dilakukan pada setiap tahap proyek pengembangan perangkat lunak.
Dalam Siklus Hidup Pengembangan Perangkat Lunak, aktivitas dilakukan dalam lima fase -
Requirements Gathering- Persyaratan perangkat lunak yang akan dikembangkan dikumpulkan. Persyaratan ini akan dibuat dalam bahasa yang dipahami oleh pelanggan / pengguna. Terminologi khusus domain direkomendasikan.
Analysis - Persyaratan yang dikumpulkan dianalisis dari sudut pandang implementasi dan spesifikasi perangkat lunak ditulis untuk mencakup keduanya, persyaratan fungsional dan persyaratan non-fungsional.
Design - Fase ini melibatkan sampai pada arsitektur perangkat lunak dan implementasi spesifik berdasarkan teknologi yang dipilih untuk pengembangan.
Construction - Dalam fase ini, kode dikembangkan, unit diuji, terintegrasi, integrasi diuji dan build diproduksi.
Testing- Pengujian fungsional perangkat lunak yang dibangun dilakukan pada tahap ini. Ini juga termasuk pengujian persyaratan non-fungsional.
Ada dua pendekatan untuk melakukan aktivitas ini -
Prescriptive - Model SDLC yang akan memberi Anda cara melakukan aktivitas dengan cara yang ditentukan sebagaimana ditentukan oleh kerangka kerja.
Adaptive- Model SDLC yang memberikan Anda keleluasaan dalam melakukan aktivitas, dengan aturan tertentu yang perlu dipatuhi. Metode agile sebagian besar mengikuti pendekatan ini, dengan masing-masing memiliki aturannya sendiri. Namun, mengikuti pendekatan adaptif atau tangkas tidak berarti bahwa perangkat lunak dikembangkan tanpa mengikuti disiplin apa pun. Ini akan menyebabkan kekacauan.
Anda perlu memahami bahwa kami tidak dapat mengatakan bahwa model SDLC tertentu baik atau buruk. Masing-masing memiliki kekuatan dan kelemahannya sendiri-sendiri dan karenanya cocok dalam konteks tertentu.
Saat Anda memilih model SDLC untuk proyek Anda, Anda perlu memahami -
- Konteks Organisasi Anda
- Konteks Teknologi Anda
- Komposisi Tim Anda
- Konteks Pelanggan Anda
Misalnya, jika pengembangan perangkat lunak dapat diprediksi, Anda dapat menggunakan pendekatan Preskriptif. Di sisi lain, jika pengembangan perangkat lunak tidak dapat diprediksi, yaitu persyaratan tidak sepenuhnya diketahui, atau tim pengembangan tidak memiliki eksposur sebelumnya ke domain atau teknologi saat ini, dll. Pendekatan Adaptif adalah pilihan terbaik.
Di bagian berikut, Anda akan memahami model SDLC paling umum yang berkembang selama pelaksanaan proyek pengembangan perangkat lunak di seluruh industri. Anda juga akan mengetahui kekuatan dan kelemahan masing-masing dan dalam konteks apa mereka cocok.
Model Waterfall adalah model SDLC klasik yang dikenal luas, dipahami dan umum digunakan. Ini diperkenalkan oleh Royce pada tahun 1970 dan masih diikuti sebagai pendekatan umum untuk pengembangan perangkat lunak di berbagai organisasi di seluruh industri.
Dalam model Waterfall, setiap fase siklus proses hanya dapat dimulai setelah fase siklus proses sebelumnya selesai. Jadi, ini adalah model linier tanpa loop umpan balik.
Model Air Terjun - Kekuatan
Kekuatan model Air Terjun adalah -
- Mudah dimengerti, mudah digunakan.
- Memberikan struktur kepada tim pengembangan yang tidak berpengalaman.
- Tonggak sejarah dipahami dengan baik.
- Menetapkan stabilitas persyaratan.
- Ideal untuk pengendalian manajemen (perencanaan, pemantauan, pelaporan).
- Bekerja dengan baik bila kualitas lebih penting daripada biaya atau jadwal.
Model Air Terjun - Kelemahan
Kelemahan atau kekurangan model Waterfall adalah -
Ideal - Itu tidak cocok dengan kenyataan dengan baik.
Tidak realistis - tidak dapat mengharapkan persyaratan yang akurat di awal proyek.
Tidak mencerminkan sifat iteratif dari pengembangan eksplorasi yang lebih umum.
Sulit dan mahal untuk melakukan perubahan.
Perangkat lunak dikirim hanya pada akhir proyek. Karena ini -
Menunda penemuan cacat serius.
Kemungkinan pengiriman persyaratan usang.
Overhead manajemen yang signifikan, yang dapat menjadi mahal untuk tim dan proyek kecil.
Membutuhkan sumber daya yang berpengalaman di setiap fase - analis, desainer, pengembang, penguji.
Pengujian dimulai hanya setelah pengembangan selesai dan penguji tidak terlibat dalam fase sebelumnya.
Keahlian tim lintas fungsi tidak dibagikan karena setiap fase dijalankan secara terpisah.
Kapan Menggunakan Model Air Terjun?
Anda dapat menggunakan model Waterfall jika -
Persyaratannya sangat terkenal.
Definisi produk stabil.
Teknologi dipahami dengan baik.
Versi baru dari produk yang sudah ada.
Porting produk yang sudah ada ke platform baru.
Organisasi besar dengan tim lintas fungsi terstruktur.
Saluran komunikasi dibangun dengan baik di dalam organisasi dan dengan pelanggan juga.
Model Pembuatan Prototipe Evolusioner
Dalam pengembangan perangkat lunak menggunakan model Evolutionary Prototyping, pengembang membangun prototipe selama tahap persyaratan. Pengguna akhir kemudian mengevaluasi prototipe dan memberikan umpan balik. Umpan balik dapat berupa koreksi prototipe atau fungsionalitas tambahan. Berdasarkan umpan balik tersebut, pengembang selanjutnya menyempurnakan prototipe tersebut.
Dengan demikian, produk berkembang melalui Prototipe → Umpan Balik → Siklus Prototipe Halus dan karenanya dinamai Evolutionary Prototyping. Ketika pengguna puas dengan fungsionalitas, dan kerja produk, kode prototipe dibawa ke standar yang diperlukan untuk pengiriman produk akhir.
Model Pembuatan Prototipe Evolusioner - Kekuatan
Kekuatan atau keunggulan model Evolutionary Prototyping adalah -
Pelanggan / pengguna akhir dapat memvisualisasikan persyaratan sistem saat mereka berkumpul melihat prototipe.
Pengembang belajar dari pelanggan dan karenanya tidak ada ambiguitas terkait domain atau lingkungan produksi.
Memungkinkan desain dan pengembangan yang fleksibel.
Interaksi dengan prototipe merangsang kesadaran akan fungsionalitas tambahan yang dibutuhkan.
Persyaratan yang tidak terduga dan perubahan persyaratan dapat dengan mudah diakomodasi.
Tanda-tanda kemajuan yang mantap dan terlihat dihasilkan.
Pengiriman produk akhir yang akurat dan dapat dipelihara.
Model Pembuatan Prototipe Evolusioner - Kelemahan
Kelemahan atau kekurangan model Evolutionary Prototyping adalah sebagai berikut -
Kecenderungan untuk meninggalkan pengembangan terstruktur dalam pengembangan kode dan perbaikan, meskipun bukan itu yang ditentukan oleh model.
Model ini menerima reputasi buruk untuk metode cepat-dan-kotor.
Pemeliharaan keseluruhan mungkin bisa diabaikan.
Pelanggan kemungkinan dapat meminta pengiriman prototipe sebagai final, tidak memberikan kesempatan kepada pengembang untuk melakukan langkah terakhir yaitu standarisasi produk akhir.
Proyek dapat berlanjut selamanya (dengan cakupan creep berkelanjutan) dan manajemen mungkin tidak menghargainya.
Kapan Menggunakan Model Evolutionary Prototyping?
Anda dapat menggunakan model Evolutionary Prototyping -
- Ketika persyaratan tidak stabil atau harus diklarifikasi
- Sebagai tahap klarifikasi kebutuhan model waterfall
- Untuk mengembangkan antarmuka pengguna
- Untuk demonstrasi berumur pendek
- Untuk pengembangan baru atau asli
- Untuk menerapkan teknologi baru
Dalam model Iterative Incremental, awalnya, implementasi parsial dari sistem total dibangun sehingga akan berada dalam status pengiriman. Fungsionalitas yang ditingkatkan ditambahkan. Cacat, jika ada, dari pengiriman sebelumnya diperbaiki dan produk yang berfungsi dikirim. Proses ini diulangi sampai seluruh pengembangan produk selesai. Pengulangan proses ini disebut iterasi. Di akhir setiap iterasi, kenaikan produk dikirimkan.
Model Inkremental Iteratif - Kekuatan
Kelebihan atau kelebihan model Iterative Incremental adalah -
Anda dapat mengembangkan persyaratan yang diprioritaskan terlebih dahulu.
Pengiriman produk awal lebih cepat.
Pelanggan mendapatkan fungsionalitas penting lebih awal.
Menurunkan biaya pengiriman awal.
Setiap rilis adalah peningkatan produk, sehingga pelanggan akan memiliki produk yang berfungsi di tangan setiap saat.
Pelanggan dapat memberikan umpan balik untuk setiap kenaikan produk, sehingga menghindari kejutan di akhir pengembangan.
Perubahan persyaratan dapat dengan mudah diakomodasi.
Model Inkremental Iteratif - Kelemahan
Kerugian dari model Iterative Incremental adalah -
Membutuhkan perencanaan iterasi yang efektif.
Memerlukan desain yang efisien untuk memastikan penyertaan fungsionalitas yang diperlukan dan penyediaan untuk perubahan nanti.
Membutuhkan definisi awal dari sistem yang lengkap dan berfungsi penuh untuk memungkinkan definisi kenaikan.
Diperlukan antarmuka modul yang terdefinisi dengan baik, karena beberapa telah dikembangkan jauh sebelum yang lain dikembangkan.
Total biaya sistem lengkap tidak lebih rendah.
Kapan Menggunakan Model Inkremental Iteratif?
Model Iterative Incremental dapat digunakan jika -
Sebagian besar persyaratan diketahui di awal, tetapi diharapkan berkembang seiring waktu.
Persyaratannya diprioritaskan.
Ada kebutuhan agar fungsionalitas dasar dikirimkan dengan cepat.
Sebuah proyek memiliki jadwal pengembangan yang panjang.
Sebuah proyek memiliki teknologi baru.
Domain baru bagi tim.
Model Rapid Application Development (RAD) memiliki tahapan sebagai berikut -
Requirements Planning phase - Pada tahap perencanaan kebutuhan, perlu diadakan workshop untuk membahas permasalahan bisnis secara terstruktur.
User Description phase - Dalam fase Deskripsi Pengguna, alat otomatis digunakan untuk menangkap informasi dari pengguna.
Construction phase - Dalam fase Konstruksi, alat produktivitas, seperti generator kode, generator layar, dll. Digunakan di dalam kotak waktu, dengan pendekatan "Lakukan hingga Selesai".
Cut Over phase - Pada fase Cut over, instalasi sistem, pengujian penerimaan pengguna dan pelatihan pengguna dilakukan.
Model Pengembangan Aplikasi Cepat - Kekuatan
Kelebihan atau kekuatan model Rapid Application Development adalah sebagai berikut -
Mengurangi waktu siklus dan meningkatkan produktivitas dengan anggota tim yang lebih sedikit berarti biaya yang lebih rendah.
Keterlibatan pelanggan sepanjang siklus lengkap meminimalkan risiko tidak mencapai kepuasan pelanggan dan nilai bisnis.
Fokus berpindah ke kode dalam mode apa-yang-anda-lihat-adalah-apa-yang-anda-dapatkan (WYSIWYG). Hal ini memberikan kejelasan bahwa yang dibangun adalah hal yang benar.
Menggunakan konsep pemodelan untuk menangkap informasi tentang bisnis, data, dan proses.
Model Pengembangan Aplikasi Cepat - Kelemahan
Kekurangan atau kelebihan model Rapid Application Development adalah sebagai berikut -
Proses pengembangan yang dipercepat harus memberikan tanggapan yang cepat kepada pengguna.
Risiko tidak pernah mencapai penutupan.
Sulit digunakan dengan sistem lama.
Pengembang dan pelanggan harus berkomitmen pada aktivitas cepat dalam kerangka waktu yang singkat.
Kapan Menggunakan Model Pengembangan Aplikasi Cepat?
Model Rapid Application Development dapat digunakan jika -
- Pengguna dapat dilibatkan sepanjang siklus hidup.
- Proyek dapat dibatasi waktu.
- Fungsionalitas dapat diberikan secara bertahap.
Meskipun kekuatan model Rapid Application Development dihargai, model ini jarang digunakan di industri.
Model spiral menambahkan Analisis Risiko dan prototipe RAD ke model Waterfall. Setiap siklus melibatkan urutan langkah yang sama seperti model Waterfall.
Model spiral memiliki empat kuadran. Mari kita bahas secara detail.
Kuadran 1 - Tentukan tujuan, alternatif dan kendala
Objectives - Fungsionalitas, kinerja, antarmuka perangkat keras / perangkat lunak, faktor penentu keberhasilan, dll.
Alternatives - Bangun, gunakan kembali, beli, sub-kontrak, dll.
Constraints - Biaya, jadwal, antarmuka, dll.
Kuadran 2 - Evaluasi alternatif, identifikasi dan selesaikan risiko
Pelajari alternatif-alternatif yang berhubungan dengan tujuan dan batasan yang ditentukan.
Identifikasi risiko seperti kurangnya pengalaman, teknologi baru, jadwal ketat, dll.
Selesaikan risiko yang teridentifikasi dengan mengevaluasi dampaknya pada proyek, mengidentifikasi rencana mitigasi dan kontingensi yang diperlukan, dan menerapkannya. Risiko selalu perlu dipantau.
Kuadran 3 - Kembangkan produk tingkat berikutnya
Kegiatan khas meliputi -
- Buat desain
- Tinjau desain
- Kembangkan kode
- Periksa kode
- Uji produk
Kuadran 4 - Rencanakan fase berikutnya
Kegiatan khas meliputi -
- Mengembangkan rencana proyek
- Kembangkan rencana manajemen konfigurasi
- Kembangkan rencana pengujian
- Kembangkan rencana instalasi
Model Spiral - Kekuatan
Kelebihan atau kelebihan dari metode Spiral adalah -
- Memberikan indikasi awal risiko, tanpa memerlukan banyak biaya.
- Pengguna dapat melihat sistem lebih awal karena alat pembuatan prototipe yang cepat.
- Fungsi kritis berisiko tinggi dikembangkan terlebih dahulu.
- Desainnya tidak harus sempurna.
- Pengguna dapat terlibat dalam semua langkah siklus proses.
- Umpan balik awal dan sering dari pengguna.
- Biaya kumulatif sering dinilai.
Model Spiral - Kelemahan
Kerugian atau kelemahan dari metode Spiral adalah -
Mungkin sulit untuk menentukan tujuan, pencapaian yang dapat diverifikasi yang menunjukkan kesiapan untuk melanjutkan melalui iterasi berikutnya.
Waktu yang dihabiskan dalam perencanaan, pengaturan ulang tujuan, melakukan analisis risiko dan pembuatan prototipe mungkin merupakan overhead.
Waktu yang dihabiskan untuk mengevaluasi risiko bisa jadi terlalu besar untuk proyek kecil atau berisiko rendah.
Model spiral rumit untuk dipahami oleh anggota tim baru.
Keahlian penilaian risiko diperlukan.
Spiral dapat berlanjut tanpa batas.
Pengembang harus dipindahkan selama kegiatan fase non-pengembangan.
Kapan Menggunakan Model Spiral?
Model Spiral dapat digunakan jika -
- Pembuatan prototipe sesuai.
- Evaluasi risiko itu penting.
- Sebuah proyek berisiko menengah hingga tinggi.
- Pengguna tidak yakin dengan kebutuhan mereka.
- Persyaratannya rumit.
- Lini produk baru.
- Perubahan signifikan diharapkan terjadi selama eksplorasi.
- Komitmen proyek jangka panjang tidak bijaksana karena potensi perubahan bisnis.
Metode Agile didasarkan pada manifesto Agile dan bersifat adaptif. Metode tangkas memastikan -
- Kolaborasi tim.
- Kolaborasi pelanggan.
- Komunikasi yang konstan dan berkelanjutan.
- Respon terhadap perubahan.
- Kesiapan produk yang berfungsi.
Beberapa metode Agile muncul, mempromosikan pengembangan berulang dan bertahap dengan iterasi waktu terbatas. Meskipun metode Agile bersifat adaptif, aturan metode tertentu tidak dapat diabaikan dan karenanya membutuhkan implementasi yang disiplin.
Metode Tangkas - Kekuatan
Kelebihan atau kelebihan metode Agile adalah -
- Rilis awal dan sering.
- Akomodasi persyaratan yang berubah.
- Komunikasi harian antara pelanggan dan pengembang.
- Proyek yang dibangun di sekitar individu yang termotivasi.
- Tim yang mengatur diri sendiri.
- Kesederhanaan, berfokus pada apa yang dibutuhkan segera.
- Tidak ada bangunan untuk masa depan atau membebani kode.
- Refleksi rutin untuk menyesuaikan perilaku untuk meningkatkan efektivitas.
Metode Agile - Kelemahan
Kerugian atau kelemahan metode Spiral adalah -
Ketersediaan pelanggan mungkin tidak memungkinkan.
Tim harus berpengalaman untuk mengikuti aturan metode.
Perencanaan yang tepat diperlukan untuk segera memutuskan fungsionalitas yang perlu disampaikan dalam sebuah iterasi.
Tim diharapkan memiliki keterampilan estimasi dan keterampilan negosiasi.
Tim harus memiliki keterampilan komunikasi yang efektif.
Tim baru mungkin tidak dapat mengatur dirinya sendiri.
Membutuhkan disiplin untuk mengembangkan dan mewujudkan iterasi yang dibatasi waktu.
Desain harus dibuat sederhana dan dapat dipelihara, sehingga membutuhkan keterampilan desain yang efektif.
Kapan Menggunakan Metode Agile?
Metode Agile dapat digunakan ketika -
Penerapannya sangat membutuhkan waktu.
Cakupannya terbatas dan kurang formal (penskalaan metode tangkas untuk proyek yang lebih besar sedang dilakukan, dengan perluasan tertentu ke beberapa metode tangkas).
Organisasi menggunakan metode disiplin.
Model SDLC sebelumnya lebih berorientasi pada praktik stabilitas, prediktabilitas, dan penurunan hasil. Industri, seperti Platform Internet telah bergerak untuk meningkatkan lingkungan pengembalian, pendekatan yang tidak dapat diprediksi, nonlinier, dan cepat.
Adaptive Software Development (ASD) telah berkembang untuk mengatasi masalah ini. Ini berfokus pada kemunculan sebagai faktor terpenting dari perspektif manajemen, untuk meningkatkan kemampuan mengelola pengembangan produk.
Dalam kata-kata Jim Highsmith, "Kerangka Pengembangan Perangkat Lunak Adaptif didasarkan pada pengalaman bertahun-tahun dengan metodologi Pengembangan Perangkat Lunak tradisional, konsultasi tentang, praktik, dan penulisan tentang teknik Pengembangan Aplikasi Cepat (RAD) dan bekerja dengan perusahaan perangkat lunak berteknologi tinggi dalam mengelola pengembangan produk mereka praktek ”.
Model air terjun dikarakterisasi oleh linieritas dan prediktabilitas, dengan sedikit umpan balik. Ini dapat dilihat sebagai urutanPlan → Build → Implement.
Model Siklus Hidup Evolusioner seperti model Spiral memindahkan pendekatan Deterministik ke model Adaptif, dengan Plan → Build → Revise Cycles.
Namun, pola pikir praktisi tetap deterministik dengan prediktabilitas jangka panjang beralih ke prediktabilitas jangka pendek. Praktik model Siklus Hidup Evolusioner seperti RAD ternyata kurang deterministik.
Siklus Hidup Adaptif
Model Adaptif dibuat dari sudut pandang yang berbeda. Meskipun bersiklus seperti model Evolusi, nama-nama fase mencerminkan sifat tak terduga dari sistem yang semakin kompleks.
Perkembangan Adaptif melangkah lebih jauh dari warisan evolusionernya dalam dua cara utama -
Ini secara eksplisit menggantikan Determinisme dengan Munculnya.
Ini melampaui perubahan dalam siklus hidup ke perubahan yang lebih dalam dalam gaya manajemen.
Tiga fase dalam Siklus Hidup Pengembangan Perangkat Lunak Adaptif adalah -
Speculate - Spekulasi menggantikan perencanaan kata deterministik, perencanaan spesifikasi produk atau perencanaan tugas manajemen proyek.
Collaborate - Kolaborasi mewakili keseimbangan antara
Mengelola dalam pengertian manajemen proyek tradisional, dan
Menciptakan dan memelihara lingkungan kolaboratif yang dibutuhkan untuk kemunculan.
Learn - Belajar bertujuan, pengembang dan pelanggan, untuk menggunakan hasil dari setiap siklus pengembangan untuk mempelajari arah selanjutnya.
Aktivitas Kolaboratif membangun produk, mengikuti laju perubahan lingkungan.
Pada bab ini, kita akan memahami berbagai konsep Pengembangan Perangkat Lunak Adaptif.
Teori Sistem Adaptif Kompleks (CAS)
Brian Arthur dan rekan-rekannya, di institut Santa Fe, menggunakan teori Sistem Adaptif Kompleks (CAS) untuk merevolusi pemahaman Fisika, Biologi, Evolusi, dan Ekonomi.
Brian Arthur memuncak selama lebih dari dua dekade mencoba meyakinkan ekonom arus utama bahwa pandangan mereka, yang didominasi oleh asumsi fundamental tentang pengembalian yang menurun, ekuilibrium, dan dinamika deterministik, tidak lagi cukup untuk memahami kenyataan. Dunia baru adalah salah satu dari hasil yang meningkat, ketidakstabilan, dan ketidakmampuan untuk menentukan sebab dan akibat.
Kedua dunia itu berbeda dalam perilaku, gaya, dan budaya. Mereka menyerukan -
- Teknik Manajemen yang Berbeda
- Strategi Berbeda
- Pemahaman yang Berbeda
Pengembangan Perangkat Lunak Kompleks
Dengan cakupan Aplikasi Perangkat Lunak yang meledak, bahkan organisasi pengembangan perangkat lunak mengalami kontradiksi serupa seperti yang disebutkan di atas.
One World diwakili oleh perkembangan Deterministik, yang berasal dari praktik manajemen yang berakar pada dasar-dasar stabilitas dan prediktabilitas (yang dalam istilah Arthur berarti pengembalian yang menurun)
Dunia Kedua diwakili oleh industri yang bergerak dari penurunan ke lingkungan pengembalian yang meningkat yang tidak dapat diprediksi, nonlinier, dan cepat.
Untuk mengatasi masalah dunia kedua ini, Jig Highsmith menawarkan kerangka kerja, Pengembangan Perangkat Lunak Adaptif yang berbeda dari Pengembangan Perangkat Lunak Penentu.
Pengembangan Perangkat Lunak Adaptif berfokus pada penanganan sistem yang kompleks -
Pengembangan Perangkat Lunak Adaptif untuk siklus hidup pengembangan.
Teknik Manajemen Adaptif membutuhkan pola pikir yang berbeda dari praktik manajemen proyek tradisional.
Dalam tutorial ini, Anda dapat memahami kedua implementasi ini.
Adaptive Software Development (ASD) didasarkan pada dua perspektif -
Perspektif konseptual berdasarkan teori Complex Adaptive Systems (CAS), seperti yang diberikan di bagian pertama bab ini.
Perspektif Praktis berdasarkan
Pengalaman bertahun-tahun dengan metodologi pengembangan perangkat lunak deterministik.
Konsultasi, praktik, dan penulisan tentang teknik Rapid Application Development (RAD); dan bekerja dengan perusahaan perangkat lunak berteknologi tinggi dalam mengelola pengembangan produk mereka.
Dalam bab ini, Anda akan memahami perspektif konseptual Pengembangan Perangkat Lunak Adaptif.
Konsep Sistem Adaptif Kompleks (CAS)
Teori Complex Adaptive Systems (CAS) memiliki banyak konsep. Pengembangan Perangkat Lunak Adaptif didasarkan pada dua konsep berikut -
- Emergence
- Complexity
Munculnya
Dalam proyek pengembangan produk perangkat lunak yang kompleks, hasilnya secara inheren tidak dapat diprediksi. Namun, produk yang sukses muncul dari lingkungan seperti itu setiap saat.
Hal ini dapat terjadi dengan Munculnya, seperti yang diilustrasikan dalam teori Sistem Adaptif Kompleks (CAS). Ini bisa dipahami dengan contoh sederhana, perilaku berkelompok burung.
Ketika Anda mengamati sekawanan burung, Anda memperhatikan bahwa -
Setiap burung mencoba melakukannya
Pertahankan jarak minimum dari objek lain di lingkungan, termasuk burung lain.
Cocokkan kecepatan dengan burung di lingkungannya.
Bergerak menuju pusat massa burung yang terlihat di lingkungannya.
Tidak ada aturan perilaku untuk grup. Satu-satunya aturan adalah tentang perilaku burung.
Namun, ada perilaku yang muncul, berkelompok burung. Ketika burung yang nakal bergegas mengejar, kawanannya terbagi di sekitar rintangan dan membentuk kembali di sisi lain.
Ini menunjukkan kebutuhan perubahan model mental yang paling sulit dalam Perkembangan Adaptif - Dari cara mengelola dan mengatur kebebasan individu hingga gagasan bahwa tatanan baru yang kreatif muncul secara tidak terduga dari organisasi mandiri yang spontan.
Selain pengembangan, kemunculan merupakan konsep terpenting dari perspektif manajemen juga.
Kompleksitas
Dalam konteks Pengembangan Perangkat Lunak, Kompleksitas adalah tentang -
Individu dari tim seperti pengembang, pelanggan, vendor, pesaing, dan pemegang saham, jumlah dan kecepatan mereka.
Ukuran dan kompleksitas teknologi.
Praktik Pengembangan Perangkat Lunak Adaptif
Pengembangan Perangkat Lunak Adaptif menawarkan perspektif berbeda tentang praktik manajemen perangkat lunak. Pada bagian di bawah ini, Anda dapat memahami dua praktik penting - Kualitas dan RAD, keduanya memiliki konsekuensi untuk persyaratan pengumpulan.
Anda dapat menemukan detail semua praktik di bab, Praktik Pengembangan Perangkat Lunak Adaptif dalam tutorial ini.
Kualitas
Dalam lingkungan yang kompleks, praktik kuno "Lakukan dengan benar pada kali pertama" tidak berhasil karena Anda tidak dapat memprediksi apa yang benar di awal. Anda harus memiliki tujuan untuk menghasilkan nilai yang tepat. Namun, dalam lingkungan yang kompleks, kombinasi dan permutasi komponen nilai seperti cakupan (fitur, kinerja, tingkat cacat), jadwal, dan sumber daya sangat luas sehingga tidak akan pernah ada nilai yang optimal. Oleh karena itu, fokusnya adalah bergeser untuk memberikan nilai terbaik di pasar yang kompetitif.
Praktek RAD
Praktik RAD umumnya melibatkan kombinasi dari berikut ini -
- Siklus Hidup Evolusioner
- Grup Fokus Pelanggan, Sesi JAD, Tinjauan Teknis
- Manajemen Proyek dengan Waktu Terbatas
- Rekayasa Perangkat Lunak Berkelanjutan
- Tim yang berdedikasi dengan ruang perang
Proyek RAD memiliki rasa adaptif yang melekat dan muncul. Banyak organisasi TI yang menentang RAD. Namun, Microsoft dan lainnya telah menghasilkan perangkat lunak yang sangat besar dan kompleks menggunakan teknik yang sebanding dengan RAD karena hal itu menimbulkan pertanyaan tentang pandangan dunia fundamental mereka.
Praktik RAD dan proses Microsoft adalah contoh dari Adaptive Development yang sedang beraksi. Memberi mereka label (yaitu, Perkembangan Adaptif) dan menyadari bahwa ada ilmu pengetahuan ilmiah yang berkembang (yaitu, teori CAS) menjelaskan mengapa mereka bekerja. Ini harus memberikan dasar untuk penggunaan yang lebih luas dari praktik-praktik ini.
Pengembangan Perangkat Lunak Adaptif telah berevolusi dari praktik RAD. Aspek tim juga ditambahkan ke praktik ini. Perusahaan dari Selandia Baru hingga Kanada, untuk berbagai jenis proyek dan produk, telah menggunakan Pengembangan Perangkat Lunak adaptif.
Jim Highsmith menerbitkan Adaptive Software Development pada tahun 2000.
Praktik Pengembangan Perangkat Lunak Adaptif memberikan kemampuan untuk mengakomodasi perubahan dan dapat beradaptasi dalam lingkungan yang bergejolak dengan produk yang berkembang dengan sedikit perencanaan dan pembelajaran.
Tahapan Siklus Hidup ASD
Pengembangan Perangkat Lunak Adaptif adalah siklus seperti model Evolusioner, dengan nama fase yang mencerminkan ketidakpastian dalam sistem yang kompleks. Fase dalam siklus hidup pengembangan Adaptif adalah -
- Speculate
- Collaborate
- Learn
Ketiga fase ini mencerminkan sifat dinamis Pengembangan Perangkat Lunak Adaptif. Perkembangan Adaptif secara eksplisit menggantikan Determinisme dengan Kemunculan. Ini lebih dari sekadar perubahan dalam siklus hidup ke perubahan yang lebih dalam dalam gaya manajemen. Pengembangan Perangkat Lunak Adaptif memiliki Siklus Hidup Spekulasi-Kolaborasi-Belajar yang dinamis.
Siklus Hidup Pengembangan Perangkat Lunak Adaptif berfokus pada hasil, bukan tugas, dan hasilnya diidentifikasi sebagai fitur aplikasi.
Berspekulasi
Istilah rencana terlalu deterministik dan menunjukkan tingkat kepastian yang cukup tinggi tentang hasil yang diinginkan. Sasaran implisit dan eksplisit dari kesesuaian dengan rencana, membatasi kemampuan manajer untuk mengarahkan proyek ke arah yang inovatif.
Dalam Pengembangan Perangkat Lunak Adaptif, istilah rencana diganti dengan istilah spekulasi. Saat berspekulasi, tim tidak meninggalkan perencanaan, tetapi mengakui realitas ketidakpastian dalam masalah yang kompleks. Berspekulasi mendorong eksplorasi dan eksperimen. Iterasi dengan siklus pendek dianjurkan.
Berkolaborasi
Aplikasi yang kompleks tidak dibangun, mereka berkembang. Aplikasi yang kompleks membutuhkan sejumlah besar informasi yang dikumpulkan, dianalisis, dan diterapkan pada masalah. Lingkungan yang bergejolak memiliki laju aliran informasi yang tinggi. Oleh karena itu, aplikasi yang kompleks memerlukan sejumlah besar informasi yang dikumpulkan, dianalisis, dan diterapkan pada masalah tersebut. Ini menghasilkan persyaratan Pengetahuan yang beragam yang hanya dapat ditangani oleh kolaborasi tim.
Berkolaborasi akan membutuhkan kemampuan untuk bekerja sama untuk menghasilkan hasil, berbagi pengetahuan, atau membuat keputusan.
Dalam konteks manajemen proyek, Kolaborasi menggambarkan keseimbangan antara mengelola dengan teknik manajemen tradisional dan menciptakan serta memelihara lingkungan kolaboratif yang diperlukan untuk kemunculan.
Belajar
Bagian Belajar dari Siklus Hidup sangat penting untuk keberhasilan proyek. Tim harus terus meningkatkan pengetahuan mereka, menggunakan praktik seperti -
- Tinjauan Teknis
- Retrospektif Proyek
- Grup Fokus Pelanggan
Review harus dilakukan setelah setiap iterasi. Baik pengembang maupun pelanggan memeriksa asumsi mereka dan menggunakan hasil dari setiap siklus pengembangan untuk mempelajari arah siklus pengembangan berikutnya. Tim belajar -
Tentang perubahan produk
Perubahan yang lebih mendasar dalam asumsi yang mendasari tentang bagaimana produk dikembangkan
Pengulangan harus singkat, sehingga tim dapat belajar dari kesalahan kecil daripada kesalahan besar.
Berspekulasi - Berkolaborasi - Pelajari Siklus secara Menyeluruh
Seperti yang Anda amati dari siklus Spekulasi-Kolaborasi-Belajar, yang diberikan di atas, jelas bahwa ketiga fase tersebut nonlinier dan tumpang tindih.
Kami mengamati hal-hal berikut dari kerangka Adaptive.
Sulit untuk Berkolaborasi tanpa Belajar atau Belajar tanpa Kolaborasi.
Sulit untuk Berspekulasi tanpa Belajar atau Belajar tanpa Berspekulasi.
Sulit untuk Berspekulasi tanpa Berkolaborasi atau Berkolaborasi tanpa Berspekulasi.
Siklus Hidup Pengembangan Perangkat Lunak Adaptif memiliki enam karakteristik dasar -
- Fokus misi
- Berbasis fitur
- Iterative
- Time-boxed
- Didorong oleh resiko
- Ubah toleransi
Dalam bab ini, Anda akan memahami enam karakteristik Pengembangan Perangkat Lunak Adaptif ini.
Berfokus pada misi
Untuk banyak proyek, keseluruhan misi yang memandu tim diartikulasikan dengan baik, meskipun persyaratannya mungkin tidak pasti di awal proyek. Pernyataan misi bertindak sebagai panduan yang mendorong eksplorasi di awal tetapi memiliki fokus sempit selama proyek. Misi memberikan batasan, bukan tujuan tetap. Pernyataan misi dan diskusi yang menghasilkan pernyataan tersebut memberikan arahan dan kriteria untuk membuat keputusan tradeoff proyek yang kritis.
Tanpa misi yang jelas dan praktik penyempurnaan misi yang konstan, siklus hidup berulang menjadi siklus hidup yang berosilasi, berayun bolak-balik tanpa kemajuan dalam pengembangan.
Berbasis fitur
Siklus Hidup Pengembangan Perangkat Lunak Adaptif didasarkan pada fitur aplikasi dan bukan pada tugas. Fitur adalah fungsionalitas yang dikembangkan selama iterasi berdasarkan prioritas pelanggan.
Fitur dapat berkembang selama beberapa iterasi ketika pelanggan memberikan umpan balik.
Fitur aplikasi yang memberikan hasil langsung kepada pelanggan setelah implementasi adalah yang utama. Dokumen berorientasi pelanggan seperti manual pengguna juga dianggap sebagai fitur. Dokumen lain seperti model data, meskipun didefinisikan sebagai kiriman selalu bersifat sekunder.
Iteratif
Siklus Hidup Pengembangan Perangkat Lunak Adaptif bersifat berulang dan berfokus pada rilis yang sering dilakukan untuk mendapatkan umpan balik, mengasimilasi pembelajaran yang dihasilkan, dan menetapkan arah yang tepat untuk pengembangan lebih lanjut.
Dibatasi waktu
Dalam Siklus Hidup Pengembangan Perangkat Lunak Adaptif, iterasi dibatasi waktu. Namun, orang harus ingat bahwa pengaturan waktu dalam Pengembangan Perangkat Lunak Adaptif bukanlah tentang tenggat waktu. Ini tidak boleh digunakan untuk membuat tim bekerja berjam-jam menantang lingkungan kolaboratif atau untuk mengorbankan kualitas kiriman.
Dalam Pengembangan Perangkat Lunak Adaptif, pengaturan waktu dianggap sebagai arah untuk memfokuskan dan memaksa keputusan pertukaran yang sulit jika dan bila diperlukan. Dalam lingkungan yang tidak pasti, di mana tingkat perubahan tinggi, perlu ada fungsi pemaksaan berkala seperti kotak waktu untuk menyelesaikan pekerjaan.
Didorong oleh resiko
Dalam Pengembangan Perangkat Lunak Adaptif, iterasi didorong dengan mengidentifikasi dan mengevaluasi risiko kritis.
Toleransi terhadap perubahan
Pengembangan Perangkat Lunak Adaptif toleran terhadap perubahan, memandang perubahan sebagai kemampuan untuk menggabungkan keunggulan kompetitif, tetapi bukan sebagai masalah pengembangan.
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 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.
Jadi perencanaan iterasi berbasis fitur dan dilakukan sebagai tim dengan pengembang dan pelanggan. Pengalaman telah 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, hal berikut 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 terbukti efektif.
Kolaborasi untuk Proyek yang Lebih Besar
Proyek yang lebih besar memerlukan 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
- Belajarlah 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 grup fokus pelanggan adalah sesi yang difasilitasi, mirip dengan sesi jad, tetapi daripada menghasilkan persyaratan atau menentukan rencana proyek, sesi ini 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 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-sama 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 telah 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?"
Diagram alur manajemen perangkat lunak tradisional ditampilkan di bawah ini.
Manajemen perangkat lunak tradisional telah dicirikan dengan istilah kontrol-perintah.
Banyak organisasi mendalami tradisi pengoptimalan, efisiensi, prediktabilitas, kontrol, ketelitian, dan peningkatan proses. Namun, ekonomi era informasi yang sedang berkembang membutuhkan kemampuan beradaptasi, kecepatan, kolaborasi, improvisasi, fleksibilitas, inovasi, dan keluwesan.
Review bisnis Harvard dan buku manajemen telah menghasilkan istilah-istilah seperti pemberdayaan, manajemen partisipatif, organisasi pembelajaran, manajemen yang berpusat pada manusia, dll, tetapi tidak satupun dari ini dimasukkan ke dalam mengelola organisasi modern.
Dalam konteks Pengembangan Perangkat Lunak Adaptif, gap tersebut terlihat jauh lebih lebar dan ada kebutuhan untuk mempertimbangkan teknik pengelolaan Adaptif yang telah terbukti berhasil di bidang lain.
Manajemen Adaptif
Manajemen adaptif telah terbukti berhasil dalam lingkungan di mana manajer sumber daya bekerja sama dengan pemangku kepentingan dan ilmuwan sebagai satu tim, dengan tujuan berikut -
Untuk mempelajari bagaimana sistem yang dikelola menanggapi intervensi manusia.
Untuk meningkatkan kebijakan dan praktik sumber daya di masa depan.
Prinsip di balik pengelolaan adaptif adalah bahwa banyak kegiatan pengelolaan sumber daya merupakan eksperimen karena hasilnya tidak dapat diprediksi dengan andal sebelumnya. Eksperimen ini kemudian dijadikan peluang pembelajaran untuk perbaikan di masa mendatang.
Manajemen adaptif dimaksudkan untuk meningkatkan kemampuan merespons tepat waktu dalam menghadapi informasi baru dan dalam pengaturan berbagai tujuan dan preferensi pemangku kepentingan. Hal ini mendorong para pemangku kepentingan untuk mengikat perselisihan dan mendiskusikannya secara tertib sementara ketidakpastian lingkungan sedang diselidiki dan dipahami dengan lebih baik.
Manajemen adaptif membantu pemangku kepentingan, manajer dan pembuat keputusan lainnya mengenali batasan pengetahuan dan kebutuhan untuk bertindak berdasarkan informasi yang tidak sempurna.
Manajemen adaptif membantu mengubah keputusan yang dibuat dengan memperjelas bahwa -
- Keputusan bersifat sementara.
- Keputusan manajemen tidak selalu tepat.
- Modifikasi diharapkan.
Ada dua jenis pendekatan manajemen Adaptif -
- Manajemen Adaptif Pasif.
- Manajemen Adaptif Aktif.
Manajemen Adaptif Pasif
Manajemen adaptif bertujuan untuk meningkatkan pengetahuan ilmiah dan dengan demikian mengurangi ketidakpastian.
Dalam manajemen Adaptif Pasif, satu tindakan pilihan, berdasarkan informasi dan pemahaman yang ada, dipilih. Hasil dari tindakan manajemen dipantau, dan keputusan selanjutnya disesuaikan berdasarkan hasil.
Pendekatan ini berkontribusi pada pembelajaran dan manajemen yang efektif. Namun, kemampuannya terbatas untuk meningkatkan kemampuan ilmiah dan manajemen untuk kondisi yang melampaui tindakan yang dipilih.
Manajemen Adaptif Aktif
Pendekatan manajemen Adaptif Aktif meninjau informasi sebelum tindakan manajemen diambil.
Serangkaian model sistem alternatif yang bersaing dari ekosistem dan tanggapan terkait (misalnya perubahan demografis; penggunaan rekreasi), daripada satu model, kemudian dikembangkan. Pilihan pengelolaan dipilih berdasarkan evaluasi model alternatif ini.
Manajemen Kepemimpinan-Kolaborasi
Manajemen adaptif adalah yang paling cocok untuk Pengembangan Perangkat Lunak Adaptif. Pendekatan tersebut memerlukan manajer sumber daya, yaitu manajer yang dapat bekerja dengan orang, mengizinkan intervensi manusia, dan menciptakan lingkungan yang bersahabat.
Dalam pengembangan perangkat lunak, para pemimpin sering mengambil tanggung jawab ini. Kami membutuhkan pemimpin lebih dari komandan. Para pemimpin adalah kolaborator dan bekerja bersama dengan tim. Collaborative-Leadership adalah praktik yang paling dicari dalam pengembangan Adaptif.
Para pemimpin memiliki kualitas berikut -
Pegang dan atur arahnya.
Mempengaruhi orang yang terlibat dan memberikan bimbingan.
Berkolaborasi, memfasilitasi, dan mengelola tim secara makro.
Berikan arahan.
Ciptakan lingkungan di mana orang-orang berbakat dapat menjadi inovatif, kreatif, dan membuat keputusan yang efektif.
Pahami bahwa kadang-kadang mereka perlu memerintah, tetapi itu bukanlah gaya utama mereka.