Menyambut Perubahan Saat Berada di Bidang Pengembangan Perangkat Lunak Agile

Salah satu prinsip paling sulit dari Pengembangan Perangkat Lunak Agile untuk benar-benar diterapkan adalah prinsip menyambut perubahan. Dua pernyataan nilai dalam manifestasi Agile adalah:

  1. Kolaborasi pelanggan atas negosiasi kontrak
  2. Menanggapi perubahan setelah mengikuti rencana

Kedua pernyataan ini mengarah pada gagasan bahwa Pengembangan Perangkat Lunak Agile menyambut perubahan dari pelanggan dan pemangku kepentingan lainnya dalam proyek. Tim Pengembangan Perangkat Lunak bertujuan untuk mengumpulkan umpan balik dengan mengembangkan rilis yang sering melalui pengembangan panduan cepat perangkat lunak pengganti dalam serangkaian iterasi. Seorang pelanggan, berubah pikiran tentang persyaratan suatu proyek, tidak dipandang sebagai masalah, yang dapat sangat berbeda dengan bagaimana banyak metodologi mendekati topik perubahan persyaratan. Penggabungan umpan balik dan keterlibatan pelanggan ini merupakan kontribusi penting bagi keberhasilan metodologi Agile karena mengarah pada pengembangan perangkat lunak yang benar-benar diinginkan pelanggan. Mengikuti prinsip ini bukanlah tugas yang mudahkarena penerapan prinsip ini perlu dimulai pada awal proyek. Panduan untuk mengimplementasikan Pengembangan Perangkat Lunak Agile sering menyebutkan peran sponsor eksekutif, dan peran berorientasi bisnis lainnya dalam perusahaan yang perlu menerima dan mendukung inisiatif untuk memperkenalkan Pengembangan Perangkat Lunak Agile. Tetapi dalam perusahaan Pengembangan Perangkat Lunak yang mengembangkan perangkat lunak yang dipesan lebih dahulu secara langsung untuk pelanggan, para pelaku bisnis di perusahaan perlu memahami dan tetap berpegang pada prinsip-prinsip Pengembangan Perangkat Lunak Agile juga.

Mungkin ada dukungan untuk Pengembangan Perangkat Lunak Agile dalam proyek semua anggota tetapi persepsi umum di antara para pelaku bisnis adalah bahwa itu adalah salah satu bidang yang dilakukan pengembang, dan tidak secara langsung menjadi perhatian mereka. Karena banyak materi yang tersedia tentang Pengembangan Perangkat Lunak Agile secara khusus menyangkut tim Pengembangan Perangkat Lunak, itu adalah asumsi yang cukup dimengerti. Dalam sebuah perusahaan yang mengembangkan perangkat lunak yang dipesan lebih dahulu, klien harus dibuat sadar akan sifat dari proyek Pengembangan Perangkat Lunak Agile, dan kontrak perlu dinegosiasikan yang kompatibel dengan metodologi yang dipilih. Dan orang-orang bisnislah yang terkait dengan sebuah proyek yang biasanya memegang tanggung jawab untuk menetapkan harapan pelanggan untuk suatu proyek dan menegosiasikan kontrak.

Pelanggan yang tidak terlalu mengenal Pengembangan Perangkat Lunak berharap bahwa ketika menegosiasikan proyek baru dengan perusahaan Pengembangan Perangkat Lunak, prosesnya seperti membeli hampir setiap barang dan jasa lainnya. Klien menjelaskan apa yang mereka butuhkan, mereka menyetujui harga bersama dengan tanggal pengiriman, dan pelanggan kemudian menunggu untuk itu tercapai. Perusahaan Pengembangan Perangkat Lunak tidak akan mau menantang harapan ini karena takut membuat pelanggan tidak nyaman, dan berpotensi kehilangan bisnis mereka. Ini sering mengarah pada perjanjian yang mengikat yang mencerminkan harapan-harapan ini. Pelanggan terus berharap bahwa perangkat lunak, pada tanggal rilis, akan siap dan melakukan semua yang diinginkan pelanggan, dan mereka hanya perlu menunggu.

Namun tidak dapat dihindari bahwa pelanggan perlu memberikan umpan balik pada perangkat lunak dan akan sangat tertarik untuk melakukan beberapa perubahan. Dalam skenario di atas, klien akan menemukan diri mereka sendiri memberikan umpan balik pada saat menjelang tanggal rilis ketika mereka benar-benar bisa melihat perangkat lunak.

Perubahan ini tidak mungkin disambut dengan baik oleh perusahaan Pengembangan Perangkat Lunak pada saat ini. Dalam praktiknya, permintaan untuk perubahan ini menghasilkan gesekan antara pelanggan dan perusahaan Pengembangan Perangkat Lunak, yang mungkin menimbulkan perdebatan antara perusahaan dan pelanggan. Perusahaan akan percaya bahwa persyaratan ini pada awalnya tidak ditentukan ketika kontrak ditandatangani dan meminta uang tunai tambahan untuk menerapkan perubahan ini. Jika pelanggan setuju, kontrak baru perlu dinegosiasikan. Di sisi lain perusahaan mungkin setuju untuk melakukan perubahan ini secara gratis mengingat pelanggan tanpa ragu cukup kesal karena perangkat lunak tidak melakukan apa yang diinginkan pelanggan. Semakin sering perubahan ini ditangani secara gratis; perusahaan semakin dekat dengan menghasilkan kerugian pada proyek. Dalam kedua skenario ini,

Jika tim pengembangan itu sendiri berusaha untuk menjadi Agile dan sedang mengembangkan proyek dalam iterasi, kasus ini sering diperbaiki dengan mendapatkan umpan balik dari pelanggan sebelumnya dalam proyek. Tetapi jika kontraknya tetap sama, perubahan ini masih tidak akan diterima oleh pebisnis yang terkait dengan proyek. Mereka akan dianggap sebagai biaya tambahan dan pengembang akan diperintahkan untuk memperpanjang waktu untuk melakukan perubahan ini sampai kontrak baru atau revisi dapat dinegosiasikan. Begitu para pelaku bisnis merasakan bahwa perubahan akan terjadi antara iterasi dan bahwa ini perlu ditangani, mereka harus menyadari bahwa pendekatan baru mungkin akan diperlukan di masa depan untuk membuat kontrak baru dengan pelanggan. Pilihan efektif yang mungkin mereka pilih adalah mencoba memecah ‘perkembangan’ proyek menjadi fase terpisah, siap direncanakan dan kemudian menjadikan ini substansi kontrak. Pendekatan ini tidak menantang harapan pelanggan untuk yakin akan hasil dari suatu proyek, dan karenanya itu tampak seperti pilihan yang aman. Pada awal proyek, seorang pelanggan seringkali cukup positif sehingga mereka tahu apa yang mereka inginkan. Dalam praktiknya, benar-benar melihat dan menggunakan perangkat lunak kemungkinan besar akan membuat pelanggan mempertimbangkan proyek secara keseluruhan jauh lebih dalam daripada sebelumnya.

Pendekatan bertahap untuk membuat kontrak tidak akan menyelesaikan masalah menyambut perubahan dan memperkenalkan masalah baru. Ketika fase pertama proyek selesai, pelanggan dapat menggunakan perangkat lunak untuk pertama kalinya dan mulai membuat permintaan untuk perubahan. Sebagai konsekuensinya, fase selanjutnya harus direncanakan lagi. Jika fase awal diperkirakan waktu maka fase berikutnya akan membutuhkan estimasi baru dari tim pengembangan. Dan para pebisnis harus membuat kontrak baru untuk fase berikutnya. Biasanya, pendekatan ini akan menuntut overhead administrasi besar untuk jumlah pekerjaan yang relatif kecil. Pelanggan juga mungkin cenderung tidak sabar atas lamanya waktu yang dibutuhkan hanya untuk menyelesaikan beberapa pekerjaan. Lebih banyak langkah perlu diambil untuk berkembang secara efektif dalam mode berulang.

Dalam skenario yang ideal, orang-orang yang menetapkan harapan pelanggan untuk proyek akan menyetujui konsep Pengembangan Perangkat Lunak Agile dan memahami prinsip-prinsip yang terlibat. Mereka akan memiliki tanggung jawab untuk juga meyakinkan pelanggan tentang manfaat ini dan menegosiasikan kontrak yang bekerja dengan baik dengan metodologi yang mereka pilih. Tiga harapan khas pelanggan akan ditantang selama proses ini:

  1. bahwa mereka sudah tahu persis apa yang mereka inginkan
  2. bahwa mereka dapat yakin dengan apa yang diharapkan pada akhir proyek
  3. bahwa perusahaan Pengembangan Perangkat Lunak secara eksklusif bertanggung jawab atas keberhasilan proyek

Untuk meyakinkan pelanggan bahwa mengembangkan proyek dengan cara Agile adalah ide yang bagus; manfaatnya perlu ditekankan:

  • Bahwa mereka dapat mengubah pikiran mereka jika mereka mau, ketika mereka mau
  • Perubahan mereka akan dimasukkan ke dalam aplikasi mereka dengan cepat dengan overhead administrasi minimal
  • Mereka tidak perlu menunggu lama untuk melihat perubahan mereka dalam perangkat lunak
  • Aplikasi yang dikembangkan akan menjadi apa yang mereka inginkan bukan sekarang tetapi apa yang mereka inginkan pada tanggal rilis
  • Mereka akan memiliki peran penting dalam memandu pengembangan proyek selama pengembangannya

Tentu saja ada trade-off untuk manfaat ini:

  • Pelanggan tidak dapat memastikan apa yang mereka yakini pada akhir proyek saat menandatangani kontrak
  • Kriteria untuk keberhasilan proyek akan berubah seiring waktu dan tidak akan dinyatakan secara eksplisit dalam kontrak sebagai spesifikasi terperinci
  • Pelanggan harus mengambil peran yang antusias untuk berpartisipasi dalam proyek. Kesuksesan proyek semuanya tergantung pada efektivitas kolaborasi antara pelanggan dan tim Pengembangan Perangkat Lunak.
  • Pelanggan harus memprioritaskan perubahan mereka, memilih yang mana yang dikembangkan terlebih dahulu dan mana yang harus dibuang jika diperlukan

Kontrak yang kompatibel kemungkinan tidak akan menyatakan rencana proyek terperinci, dan menjadikan rencana itu perjanjian yang mengikat untuk perusahaan Pengembangan jasa pembuatan software yogyakarta. Umum, persyaratan tingkat lanjut akan digunakan sebagai kriteria keberhasilan untuk proyek.

Sebagai imbalannya, kontrak akan memungkinkan pelanggan untuk meminta perubahan pada proyek ketika pelanggan menginginkannya. Definisi formal tentang bagaimana perubahan ditangani akan dimasukkan dalam kontrak. Definisi ini akan cocok dengan metodologi yang digunakan oleh tim Pengembangan Perangkat Lunak. Dengan sebagian besar metodologi Agile, ini berarti bahwa tim pengembangan akan memasukkan perubahan-perubahan ini dalam iterasi berikutnya mengikuti permintaan perubahan dari pelanggan. Kontrak juga tidak akan memuat estimasi waktu spesifik untuk persyaratan tingkat tinggi. Alih-alih itu akan berisi jadwal iterasi. Kontrak yang menerima perubahan adalah kontrak yang tidak harus diubah.

Sementara proses yang dijelaskan dikenal sebagai perubahan, istilah ini tidak secara akurat menggambarkan semua yang terjadi. Lingkungan bisnis yang berubah dapat memotivasi perubahan dalam persyaratan, tetapi yang paling sering terjadi adalah penciptaan ide-ide baru untuk perangkat lunak baik dari pelanggan dan tim pengembangan. Ini adalah bagian dari proses kreatif yang membuat perangkat lunak dan itu pasti sesuatu yang harus disambut.