Skip to main content

Agile Development Menurut Roger S. Pressman

Pada tahun 2001, terjadi penandatanganan "Manifesto for Agile Software Development" oleh Kent Beck dan 16 tokoh penting lainnya dalam pengembangan, penulisan, dan konsultasi perangkat lunak yang dikenal sebagai "Agile Alliance". Manifesto tersebut berisi pernyataan sebagai berikut: 

Kami berhasil menemukan suatu metode yang lebih baik dalam pengembangan perangkat lunak, yakni dengan menerapkannya secara langsung dan membantu orang lain untuk menerapkannya juga. Melalui upaya ini, kami berhasil mencapai nilai-nilai sebagai berikut:

Lebih diutamakan individu dan interaksi ketimbang proses dan alat.

Dokumentasi yang komprehensif diperlukan agar perangkat lunak dapat beroperasi dengan baik.

Pelanggan terlibat secara langsung dalam proses kolaborasi melalui negosiasi kontrak.

Lebih diutamakan merespon perubahan ketimbang mengikuti rencana secara kaku.

Hal ini berarti, meskipun terdapat nilai pada item yang terletak di sebelah kanan, kami memandang item yang terletak di sebelah kiri lebih penting.

Manifesto sering kali dikaitkan dengan gerakan politik yang muncul dan mendorong perubahan revolusioner untuk menggantikan keadaan lama dengan yang lebih baik. Dalam beberapa hal, inilah yang dimaksudkan dengan pengembangan yang tangkas.

Meskipun ide-ide dasar yang mendasari pengembangan tangkas telah ada selama bertahun-tahun, baru kurang dari dua dekade yang lalu ide-ide tersebut mengkristal menjadi sebuah "movement". Metode tangkas dikembangkan untuk mengatasi kelemahan dalam rekayasa perangkat lunak konvensional yang dianggap aktual. Meskipun pengembangan tangkas dapat memberikan manfaat penting, namun tidak berlaku untuk semua proyek, produk, orang, dan situasi. Filosofi pengembangan tangkas tidak bertentangan dengan praktik rekayasa perangkat lunak yang solid dan dapat diterapkan pada semua pekerjaan perangkat lunak.

Dalam ekonomi modern, sulit atau bahkan tidak mungkin untuk meramalkan perkembangan sistem komputer berbasis web seiring berjalannya waktu. Kondisi pasar yang berubah-ubah dengan cepat, perkembangan kebutuhan pengguna akhir, serta munculnya ancaman persaingan baru tanpa peringatan, semuanya membuat situasi ini semakin rumit. Dalam banyak kasus, persyaratan proyek tidak bisa ditentukan sepenuhnya sebelum dimulai, dan kegesitan dalam merespons perubahan lingkungan bisnis menjadi sangat penting.

Fluiditas berarti adanya perubahan, dan perubahan seringkali membutuhkan biaya yang mahal terutama jika tidak terkendali atau dikelola dengan buruk. Salah satu fitur yang paling menarik dari metode Agile adalah kemampuannya untuk mengurangi biaya perubahan selama proses pengembangan perangkat lunak.

Apakah ini berarti bahwa pengakuan terhadap tantangan yang ditimbulkan oleh realitas modern akan mengarah pada pengabaian terhadap prinsip, konsep, metode, dan alat dalam rekayasa perangkat lunak yang berharga? Tentu tidak! Seperti disiplin teknik lainnya, rekayasa perangkat lunak terus berkembang dan dapat dengan mudah beradaptasi untuk memenuhi tuntutan kelincahan yang semakin tinggi.

Dalam sebuah buku tentang pengembangan perangkat lunak tangkas, Alistair Cockburn mengkritik model proses preskriptif yang dijelaskan di Bab 2. Cockburn menekankan bahwa para insinyur perangkat lunak tidaklah sama dan memiliki variasi besar dalam gaya kerja, keterampilan, kreativitas, dan konsistensi. Beberapa insinyur dapat berkomunikasi dengan baik secara tertulis, sementara yang lain tidak. Cockburn menganggap bahwa model proses dapat membantu mengatasi kelemahan umum dalam diri manusia, baik melalui disiplin atau toleransi. Namun, dia percaya bahwa model proses preskriptif yang sangat disiplin sering kali rapuh karena kelemahan manusia dalam konsistensi tindakan.

Jika proses model berhasil, maka mereka harus menawarkan cara yang realistis untuk mendorong disiplin yang diperlukan atau mencirikan dengan cara yang menunjukkan toleransi untuk orang yang terlibat dalam rekayasa perangkat lunak. Praktik toleran sering lebih mudah diterapkan dan dipertahankan oleh para insinyur perangkat lunak, tetapi bisa kurang produktif seperti yang diakui oleh Cockburn. Seperti halnya dalam banyak aspek kehidupan, pertukaran harus dipertimbangkan.



Source: Pressman, Roger S. 2010. Software engineering : A Practitioner’s Approach (7th. Edition). New York: McGraw-Hill Higher Education.

Comments

Popular posts from this blog

Proses Perangkat Lunak Menurut Roger S. Pressman

Suatu proses adalah gabungan dari beberapa kegiatan, aksi, dan pekerjaan yang dikerjakan saat akan membuat beberapa produk. Setiap kegiatan memiliki tujuan yang luas (seperti komunikasi dengan pemangku kepentingan) dan diterapkan secara universal, tidak peduli pada domain aplikasi, ukuran proyek, kompleksitas usaha, atau tingkat ketelitian rekayasa perangkat lunak yang digunakan. Aksi (contohnya, desain arsitektur) mencakup rangkaian tugas yang menghasilkan produk utama (sebagai contoh, model desain arsitektural). Sebuah tugas berfokus pada tujuan yang kecil namun terdefinisi dengan baik (seperti melakukan pengujian unit) yang menghasilkan hasil yang konkret. Dalam dunia rekayasa perangkat lunak, suatu proses tidaklah berarti resep yang kaku untuk membuat perangkat lunak. Sebaliknya, proses ini merupakan pendekatan yang dapat disesuaikan yang memungkinkan tim pengembang perangkat lunak untuk memilih dan mengeksekusi serangkaian tindakan dan tugas yang sesuai. Tujuannya adalah untuk sel...

Personal And Team Process Models Menurut Roger S. Pressman

 Menurut penulis, sebuah proses perangkat lunak yang optimal adalah yang dapat disesuaikan dengan kebutuhan tim yang akan melaksanakan pekerjaan tersebut. Meskipun model proses perangkat lunak telah dibuat di tingkat perusahaan atau organisasi, namun untuk efektifitasnya hanya akan tercapai apabila dapat diadaptasi dengan signifikan untuk memenuhi kebutuhan tim proyek yang sebenarnya melaksanakan rekayasa perangkat lunak. Sebaiknya, proses yang dibuat haruslah yang paling cocok dengan kebutuhan tim dan organisasi secara menyeluruh. Atau, tim itu sendiri dapat membuat proses sesuai dengan kebutuhan individu mereka, namun tetap memenuhi kebutuhan organisasi secara keseluruhan. Watts Humphrey berpendapat bahwa membangun "personal software process" maupun "team software process" dapat dilakukan, meskipun memerlukan usaha, pelatihan, dan koordinasi yang sungguh-sungguh. 1.1 Personal Software Process (PSP) Semua pengembang perangkat lunak menggunakan suatu proses, meskipu...

Other Agile Process Models (Model Process Agile Lainnya) Menurut Roger S. Pressman

 Sejarah pengembangan perangkat lunak telah dicatat dengan banyak deskripsi dan metodologi proses yang telah usang, alat-alat, dan teknologi, serta notasi pemodelan. Semua hal tersebut telah mencapai popularitasnya masing-masing sebelum akhirnya digantikan oleh yang baru dan lebih baik. Dalam upaya mencapai penerimaan di komunitas pengembangan perangkat lunak, berbagai agile process model telah diperkenalkan dan bersaing satu sama lain, mengikuti pola yang sama dengan gerakan sebelumnya. Sudah saya sampaikan pada bagian terakhir bahwa Extreme Programming (XP) merupakan agile process models yang paling sering digunakan. Meskipun demikian, terdapat banyak agile process models lain yang telah diusulkan dan diterapkan dalam berbagai industri. Beberapa model yang paling umum meliputi: Adaptive Software Development (ASD) Scrum Dynamic Systems Development Method (DSDM) Crystal Feature Drive Development (FDD) Lean Software Development (LSD) Agile Modeling (AM) Agile Unified Process (AUP) P...