Agile vs Air Terjun

• Persyaratan dan dokumentasi produk yang terperinci memungkinkan pemrogram baru untuk melakukan orientasi dengan cepat dan mudah.
• Dokumentasi memberikan ruang lingkup yang jelas pada proyek, sehingga memungkinkan manajer proyek untuk mengomunikasikan anggaran, jadwal, dan tonggak penting kepada pihak-pihak yang berkepentingan.

• Klien dapat merasa kesulitan untuk menguraikan semua persyaratan mereka pada awal proyek, yang menyebabkan kesenjangan dalam dokumentasi.
• Kolaborasi pelanggan yang minim selama proses pengembangan dapat menyebabkan perubahan yang mahal jika produk tidak memenuhi harapan.
• Penguji melaporkan masalah dan bug pada kemudian hari selama proses, yang dapat menginformasikan arsitektur program alternatif.

Berbeda dengan pengembangan air terjun, tangkas didefinisikan oleh pendekatan berulang untuk manajemen proyek. Alih-alih menyusun persyaratan proyek yang panjang pada awalnya, tim Agile memecah produk menjadi beberapa fitur tertentu, dan mereka menangani tiap fitur di bawah batasan waktu tertentu, yang dikenal sebagai sprint.

Manajemen proyek Agile membutuhkan tim lintas fungsi dan pengaturan mandiri yang biasanya terdiri dari lima hingga sembilan anggota. Bersama-sama, mereka mengembangkan perangkat lunak yang dapat diterapkan selama setiap sprint, yang digabungkan dengan kode fungsional lain dari iterasi sebelumnya. Pada akhir kotak waktu sprint, tim mendemonstrasikan pekerjaan mereka kepada pemangku kepentingan untuk mendapatkan masukan, sehingga mereka dapat bekerja dengan fleksibel dalam pendekatan mereka terhadap pengembangan perangkat lunak. Karena tim memiliki akses ke masukan yang diberikan dengan sering, mereka dapat menyesuaikan peta jalan produk selama siklus pengembangan untuk memastikan bahwa fungsionalitas benar-benar memenuhi harapan pengguna. Dalam pendekatan air terjun, keterlibatan pelanggan biasanya bertepatan dengan pengiriman produk akhir, yang dapat menjadi mahal jika persyaratan disalahartikan atau didokumentasikan dengan tidak benar.

Ada 17 orang yang menganggap sistem manajemen proyek air terjun sangat tidak efektif, dan pada tahun 2001, ide-ide mereka seputar proses pengembangan perangkat lunak memuncak dalam sebuah karya yang dikenal sebagai "Agile Manifesto". Dokumen ini menyoroti nilai-nilai dan prinsip spesifik untuk diprioritaskan dalam alur kerja pengembangan perangkat lunak, dan telah menghasilkan sejumlah kerangka kerja Agile yang populer, seperti Scrum, Kanban, Pengembangan Fitur Terarah (FDD), dan Pemrograman Ekstrem. Sejak itu, pengembangan perangkat lunak tangkas semakin populer, terutama jika dibandingkan dengan model air terjun.

Terinspirasi oleh permainan rugby, Agile Scrum menekankan kerja tim untuk memenuhi hasil, mirip dengan cara para penyerang perlu bekerja sama dalam scrum untuk mendapatkan kepemilikan bola rugby. Keahlian tim Agile Scrum bervariasi, tetapi biasanya mencakup peran berikut:

• Pemilik produk: Anggota tim ini mewakili kebutuhan pelanggan dan bisnis. Dengan membuat cerita pengguna, tim dapat memahami bagaimana permintaan fitur dapat membantu menyelesaikan masalah tertentu, dan semua cerita ini merumuskan daftar tugas yang harus ditangani oleh tim. Individu ini juga memprioritaskan cerita berdasarkan nilainya bagi pelanggan, yang secara teoretis seharusnya diterjemahkan menjadi nilai bagi bisnis. Meskipun pemilik produk memimpin tim dengan cara ini, mereka tidak menetapkan tenggat waktu atau menginstruksikan tim tentang bagaimana pekerjaan harus diselesaikan.
• Scrum master: Anggota tim ini memfasilitasi proses pengembangan Agile secara keseluruhan. Mirip dengan manajer proyek, individu ini menjaga tim tetap melakukan tugasnya, memastikan bahwa tim tetap fokus selama proyek berlangsung. Mereka juga dapat bertindak sebagai pihak netral untuk menengahi ketidaksepakatan di antara anggota tim. Misalnya, anggota tim mungkin tidak setuju tentang berapa banyak yang harus dilakukan dalam sprint tertentu. Pemilik produk, khususnya, dapat menekan tim untuk berkomitmen lebih dari yang dapat mereka berikan dalam jangka waktu tertentu. Dalam kasus ini, master scrum dapat mengingatkan anggota tim tentang cakupan peran mereka dalam tim.

Anggota tim lain dari tim Agile dapat bervariasi, tetapi biasanya mencakup pengguna dari berbagai disiplin ilmu, seperti desain, analitik, QA, dan pengembangan. Mereka berkolaborasi bersama untuk memutuskan berapa banyak pekerjaan yang harus dilakukan dan bagaimana mereka akan menyelesaikannya.

Metodologi Agile juga ditentukan dengan cara bagaimana tim berkumpul bersama. Ada pertemuan khusus yang membantu memfasilitasi alur kerja di seluruh tim. Beberapa di antaranya termasuk yang berikut:

• Perencanaan sprint: Dalam pertemuan ini, tim berkumpul untuk menentukan cerita mana yang akan menjadi bagian dari sprint saat ini. Pemilik produk akan memprioritaskan cerita pengguna, tetapi anggota tim lainnya perlu menyetujui berapa banyak dan cerita pengguna mana yang dapat mereka selesaikan selama periode waktu yang ditetapkan.
• Rapat harian: Pertemuan singkat ini juga dikenal sebagai Scrum harian. Selama pertemuan ini, setiap anggota tim mengomunikasikan kemajuan masing-masing, seperti tugas yang diselesaikan, tugas yang akan datang, dan penghalang atau dependensi apa pun yang dapat mengakibatkan penundaan.
• Demo: Pertemuan ini menampilkan perangkat lunak yang telah diselesaikan oleh tim selama masa sprint, yang dapat berkisar antara dua hingga empat minggu. Pemilik produk akan menentukan apakah cerita pengguna telah memenuhi definisi “selesai.” Jika tidak, backlog produk dapat dipersiapkan untuk memperhitungkan apa pun yang belum tercapai. Ini juga merupakan kesempatan bagi tim untuk mempresentasikan masukan kepada pemangku kepentingan.
• Retrospektif: Waktu ini disediakan untuk introspeksi tim, di mana tim mengidentifikasi bagaimana mereka dapat meningkatkan alur kerja mereka untuk mencapai hasil yang lebih baik pada masa depan

• Desain tim memfasilitasi lebih banyak kolaborasi.
• Pengembangan produk mengambil pendekatan desain adaptif.
• Karena kode diuji dengan setiap iterasi dalam tahap pengembangan, kelemahan kode dapat menginformasikan desain perangkat lunak pada masa mendatang.
• Cenderung menghasilkan kepuasan pelanggan yang lebih tinggi karena masukan yang sering diberikan akan meningkatkan prioritas kebutuhan pelanggan.
• Memungkinkan integrasi berkelanjutan karena setiap fitur adalah bagian perangkat lunak itu sendiri yang dapat dikerjakan.
• Jenis pengembangan perangkat lunak yang ramping ini dapat menghasilkan biaya yang lebih rendah karena risiko ketidaksesuaian antara pelanggan dan produk lebih kecil.

• Pendekatan Agile bisa tidak memiliki dokumentasi yang komprehensif. Hal ini menyulitkan dalam proses penerimaan pengembang baru, jadwal proyek kepada pemangku kepentingan, dan memberikan perkiraan biaya yang akurat.
• Bisa jadi sulit untuk menskalakan.

Meskipun tim pengembangan telah berhasil dalam pendekatan manajemen proyek, tentu saja ada lebih banyak momentum di sekitar proses Agile. Tidak sulit untuk melihat alasannya ketika kita mengamati manfaat yang dapat ditawarkannya kepada perusahaan saat ini. Meskipun tersedia sejumlah alat manajemen proyek yang dapat membantu tim melacak kemajuan, IBM juga dapat menyediakan sistem untuk memungkinkan pengembang membuat kode dengan cara yang lebih mendekati agile.