Peran dan Kunci dalam Agile Software Development

Sebelumnya kita telah menyinggung sedikit soal pengertian dan tahapan-tahapan pada agile software development cycle. Nah, sekarang kita akan membahas soal Peran dan Kunci dalam Agile SDLC ini.

Peran-peran dalam Agile Software Development

Nah, di dalam Agile Software Development ini ada peran-peran yang harus dimiliki dalam pengembangan.

User

Setiap aplikasi pasti membutuhkan target, yaitu user atau klien dalam penerapan aplikasinya. Otomatis seluruh proses pada pengembangan bergantung kepada target user yang diinginkan. Dengan input, masukan, keinginan, dan ekspektasi customer barulah proses untuk tahap selanjutnya dimulai. Dalam metode SDLC ini, tim harus melakukan riset mendalam untuk memenuhi ekspektasi user. 

Product Owner

Dalam pembuatan sebuah produk software, tim harus memiliki satu orang atau satu tim lagi yang mewakilkan suara dari user. Mereka bisa datang dari tim internal ataupun stakeholders. Perwakilan ini akan menyampaikan ide, insight, dan juga feedback untuk menciptakan visi dari produk itu sendiri. Biasanya, visi dari sebuah produk itu sangat singkat. Isinya adalah gambaran dari ekspektasi masyarakat dan juga strategi apa saja untuk pembuatan produk itu sendiri.

Perwakilan dari suara kebanyakan orang disebut sebagai product owner. Mereka bertanggung jawab sepenuhnya untuk mendefinisikan kemauan pasar dan bekerjasama dengan tim developer untuk membawanya menjadi nyata. Product owner yang bekerja dengan tim akan memecah secara detail apa yang harus dilakukan dari pembuatan produk. 

Mulai dari tujuan, visi dari produk, solusi apa yang ingin diberikan, apa hal penting untuk para user, sampai apa saja yang mau diberikan kepada target user. Detail yang diberikan oleh product owner akan di-review terlebih dahulu oleh tim developer dan akan saling menanyakan satu sama lain apakah sudah sesuai apa belum.

Tim Pengembang Software

Dalam metode SDLC ini, tanggung jawab tim pengembangan dan tiap anggotanya berbeda dibandingkan dengan sistem pengembangan software yang masih tradisional. Mengapa? Karena dalam metode ini, fokusnya adalah kepada tenggat waktu atau deadline dalam penyelesaian produk tersebut. Hal ini membuat setiap anggota dalam tim harus disiplin dalam pengerjaannya bahkan mungkin memiliki tanggung jawab lebih dari satu.

Setiap tim harus saling berkolaborasi dan saling mengontrol pekerjaan anggota tim. Ini dilakukan untuk meminimalisir kesalahan di tengah jalan yang akan membuang waktu dalam proses pengerjaan.

Secara khusus, meeting juga perlu dilakukan secara berkala dan sering untuk mengetahui kemajuan masing-masing tim dalam pengerjaan produk.

Kunci dari Konsep Agile

1. User Stories

DEFINISI

Dalam konsultasi dengan pelanggan atau product owner, tim membagi pekerjaan yang harus diselesaikan menjadi peningkatan fungsional yang disebut "cerita pengguna" atau "user stories". Setiap cerita pengguna diharapkan menghasilkan, setelah diimplementasikan, kontribusi terhadap nilai keseluruhan produk, terlepas dari urutan penerapannya; ini dan asumsi lain mengenai sifat cerita pengguna ditangkap oleh rumus INVEST.

Untuk membuat asumsi ini nyata, cerita pengguna direifikasi ke dalam bentuk fisik: kartu indeks atau catatan tempel, di mana kalimat deskriptif singkat ditulis sebagai pengingat akan nilainya. Ini menekankan sifat "atomik" dari cerita pengguna dan mendorong manipulasi fisik langsung: misalnya, keputusan tentang penjadwalan dibuat dengan berpindah secara fisik di sekitar "kartu cerita" ini.

KESALAHAN UMUM

• Kesalahan klasik terdiri dari, dalam tim di mana pendekatan Agile terbatas pada tim pengembangan atau diadopsi setelah fase persyaratan non-Agile, untuk memulai dari dokumen persyaratan dalam format naratif dan mendapatkan cerita pengguna langsung berdasarkan strukturnya: misalnya satu cerita untuk setiap bagian dokumen.
• Seperti yang ditekankan oleh model 3 C, cerita pengguna bukanlah sebuah dokumen; istilah tersebut mencakup semua pengetahuan yang diperlukan untuk mengubah versi V dari produk menjadi versi V’ yang lebih bernilai sehubungan dengan tujuan tertentu.
• Tingkat detail yang sesuai dengan cerita pengguna tidak konstan, ini berkembang seiring waktu sebagai fungsi dari "lapisan perencanaan"; misalnya cerita pengguna yang dijadwalkan untuk iterasi berikutnya harus lebih dipahami daripada cerita yang tidak akan diimplementasikan hingga rilis berikutnya.
• Cerita pengguna bukanlah sebuah Use Case; meskipun seringkali bermanfaat untuk membandingkan dan mengontraskan kedua gagasan tersebut, keduanya tidak setara dan tidak mengakui pemetaan satu-ke-satu.
• Cerita pengguna pada umumnya tidak sesuai dengan komponen teknis atau antarmuka pengguna: meskipun terkadang itu bisa menjadi jalan pintas yang berguna untuk dibicarakan, misalnya “cerita dialog pencarian”, layar, kotak dialog, dan tombol bukanlah cerita pengguna.

MANFAAT YANG DIHARAPKAN

Bagi sebagian besar tim Agile, cerita pengguna atau user stories adalah kendaraan utama pengiriman perangkat lunak tambahan, dan menawarkan manfaat berikut:

• Mengurangi risiko umpan balik yang tertunda
• Jika kenaikannya kecil
• Jika perangkat lunak sering dirilis ke produksi
• Untuk pelanggan atau product owner, opsi untuk berubah pikiran tentang detail atau prioritas jadwal dari setiap cerita pengguna yang belum diterapkan
• Mempromosikan pemisahan tanggung jawab yang jelas antara mendefinisikan "apa" (bagian pelanggan atau product owner) dan "bagaimana" (bagian tim teknis), meningkatkan keterampilan dan kreativitas masing-masing

PENGGUNAAN

• Tim menggunakan alat perencanaan visual (rencana rilis, peta cerita, papan tugas) dan kartu indeks atau sticky pada tampilan ini mencerminkan fitur produk.
• Label pada kartu yang mewakili cerita pengguna berisi sedikit atau tidak ada referensi ke elemen teknis (“database”, “layar”, atau “dialog”), tetapi umumnya mengacu pada tujuan end user.

2. Daily Meeting

DEFINISI

Setiap hari pada waktu yang sama, tim bertemu untuk memberi informasi terbaru kepada semua orang tentang informasi penting untuk koordinasi: setiap anggota tim secara singkat menjelaskan setiap kontribusi yang “selesai” dan hambatan apa pun yang menghalangi mereka. Biasanya, Tiga Pertanyaan Scrum digunakan untuk membuat struktur diskusi. Rapat tersebut biasanya diadakan di depan papan tugas.

Rapat ini biasanya diatur waktunya hingga durasi maksimal 15 menit, meskipun ini mungkin perlu disesuaikan untuk tim yang lebih besar. Agar rapat tetap singkat, topik apa pun yang memulai diskusi akan dipersingkat, ditambahkan ke daftar "tempat pemberhentian”, dan didiskusikan secara lebih mendalam setelah rapat, antara orang-orang yang terkena dampak masalah tersebut.

KESALAHAN UMUM

• Mungkin kesalahan yang paling umum adalah mengubah rapat harian menjadi “laporan status” dengan setiap anggota melaporkan kemajuan kepada orang yang sama (manajer tim, atau Scrum Master yang ditunjuk) – pertukaran dalam rapat harian harus dilakukan secara peer-to-peer.
• Kesalahan umum kedua adalah pertemuan harian yang berlarut-larut; ini mudah diatasi dengan sedikit keterampilan fasilitasi.
• Masalah umum ketiga adalah tim menemukan sedikit nilai dalam rapat harian, sampai pada titik di mana orang akan “lupa” untuk memilikinya kecuali jika Scrum Master atau manajer proyek mengambil inisiatif.
• Yang terakhir: rapat dengan mengatakan bahwa "tidak ada masalah atau tidak ada hambatan", di mana tidak ada anggota tim yang pernah menimbulkan hambatan ("hambatan" dalam bahasa Scrum), meskipun tim tersebut secara nyata tidak memberikan kinerja puncak; ini terkadang merupakan indikasi bahwa budaya perusahaan membuat orang tidak nyaman mendiskusikan kesulitan dalam pengaturan kelompok.

MANFAAT YANG DIHARAPKAN

• Pertemuan harian mencegah mode kegagalan umum tim, di mana dengan tidak adanya kesempatan eksplisit untuk berbagi informasi terkini, beberapa pengetahuan kritis kadang-kadang "jatuh melalui celah".
• Berbagi informasi peer-to-peer secara teratur dalam pertemuan singkat, fokus, dan energik juga berkontribusi pada kekompakam tim.
• Rapat stand-up lebih singkat, lebih menyenangkan, dan lebih efektif daripada rapat sambil duduk.

PENGGUNAAN

Duduklah dalam rapat harian sebagai pengamat. Ini adalah cara terbaik untuk belajar banyak dengan sangat cepat tentang keakraban tim dengan praktik Agile.

3. Persona

DEFINISI

Ketika proyek membutuhkannya - misalnya ketika pengalaman pengguna merupakan faktor utama dalam hasil proyek - tim membuat biografi sintetik yang mendetail dari pengguna fiktif dari produk masa depan: ini disebut "persona".

Persona bersifat ringkas dan visual; tata letak yang umum adalah satu halaman termasuk foto (dari stock shot atau guntingan majalah), nama dan detail sosial atau profesional: "Amanda Jones, 34, petugas pers di organisasi pengecer makanan besar, dll."

Karena produk perangkat lunak umumnya dimaksudkan untuk digunakan oleh lebih dari satu kategori orang, dengan kemungkinan preferensi dan ekspektasi produk yang berbeda, tim menciptakan satu persona untuk setiap kategori yang dianggap penting untuk dilayani dengan baik. Biografi tersebut dipajang di ruang tim.

KESALAHAN UMUM

Persona tidak boleh disamakan dengan alat konseptual lain yang digunakan dalam mendefinisikan persyaratan perangkat lunak atau dalam pemasaran produk:

• Mereka bukanlah “peran pengguna” (seperti staf penjualan, administrator, dll.) yang terutama ditentukan dalam istilah tugas atau deskripsi pekerjaan; persona menekankan tujuan dan perilaku.
• Mereka bukanlah “segmen pasar” yang terutama didefinisikan dalam istilah atribut demografis; persona adalah pengguna, bukan pembeli.

MANFAAT YANG DIHARAPKAN

Singkatnya, persona adalah jawaban atas pengamatan bahwa seorang desainer yang mencoba menyenangkan semua orang akhirnya tidak menyenangkan siapa pun, karena terlalu banyak kompromi integritas produk.

Sebaliknya, persona memberi desainer dan pengembang jangkar untuk membenarkan pilihan desain: alih-alih menarik gagasan samar tentang "kemudahan penggunaan", mereka menyarankan pertanyaan tentang "apa yang akan dilakukan Amanda" atau "apakah Bob akan memahami" fitur tertentu, interaksi , atau isyarat visual.

Karena persona adalah bagian dari asumsi bersama tim, setiap anggota tim disadarkan akan konsekuensi dari pilihan desain. Mengetahui bahwa produk tersebut akan digunakan oleh "Eileen, 72, pensiunan", pengembang akan mempertimbangkan dengan lebih akurat konsekuensi dari mengisi dialog modal dengan 50 panggilan kecil dan pengaturan, yang belum tentu terjadi jika mereka memikirkannya sebagai “pengguna”.

4. Team

DEFINISI

Sebuah "tim" dalam pengertian Agile adalah sekelompok kecil orang, ditugaskan untuk proyek atau upaya yang sama, hampir semuanya secara penuh waktu. Sebagian kecil anggota tim mungkin merupakan kontributor paruh waktu, atau mungkin memiliki tanggung jawab yang bersaing.

Gagasan tim memerlukan tanggung jawab bersama: baik atau buruk, hasilnya harus dikaitkan dengan seluruh tim daripada individu mana pun.

Tim diharapkan memiliki semua kompetensi yang diperlukan, baik teknis (pemrograman, perancangan, pengujian) atau bisnis (pengetahuan domain, kemampuan pengambilan keputusan).

Peran dan tanggung jawab tidak sepenting hasil: pengembang dapat menguji, melakukan analisis, atau memikirkan persyaratan; seorang analis atau pakar domain dapat menyarankan ide tentang implementasi, dan seterusnya.

KESALAHAN UMUM

• Kesalahan paling mendasar adalah menyamakan "grup" dan "tim", untuk berpikir bahwa tim dihasilkan secara otomatis dari orang-orang yang bekerja sama.
• Sebuah tim harus memiliki setidaknya tiga orang (dua adalah sepasang), dan umumnya tidak akan melebihi sepuluh orang.
• Satu orang mungkin menjadi kontributor untuk lebih dari satu "proyek" secara bersamaan, tetapi sangat tidak mungkin bahwa mereka akan menganggap diri mereka sebagai bagian dari lebih dari satu "tim" pada waktu yang sama.

5. Incremental Development

DEFINISI

Hampir semua tim Agile menyukai strategi pengembangan bertahap; dalam konteks Agile, ini berarti bahwa setiap versi produk yang berurutan dapat digunakan, dan masing-masing dibuat berdasarkan versi sebelumnya dengan menambahkan fungsionalitas yang terlihat oleh pengguna. Ini disebut peningkatan "vertikal" (yaitu, perbedaan antara versi produk yang berurutan), berlawanan dengan strategi berlawanan yang secara berturut-turut memberikan komponen teknis yang lengkap: misalnya, membuat skema database, kemudian membangun aturan bisnis di atasnya, dan hanya lalu mengimplementasikan UI. (Artikel ini menawarkan ilustrasi tipikal tentang perbedaan. Ini menggemakan metafora "kue berlapis" arsitektur perangkat lunak: seseorang dapat memotong sepanjang lapisan horizontal, atau secara vertikal melintasinya.) Sulit untuk membayangkan pendekatan inkremental dalam pengertian Agile yang tidak juga berulang, setidaknya sampai batas tertentu, tetapi kedua konsep tersebut tidak identik.

6. Iterative Development

DEFINISI

Proyek Agile adalah iteratif sejauh mereka dengan sengaja memungkinkan untuk "mengulangi" kegiatan pengembangan perangkat lunak, dan berpotensi "meninjau kembali" produk kerja yang sama (frasa "pengerjaan ulang yang direncanakan" terkadang digunakan; refactoring adalah contoh yang baik).

Mereka iteratif dalam arti ketiga, kurang esensial, karena paling sering disusun berdasarkan serangkaian iterasi dengan panjang kalender tetap. Namun, beberapa pendekatan Agile untuk penjadwalan, seperti Kanban menghilangkan iterasi dalam pengertian selanjutnya, tetapi tetap mempertahankan aspek lain dari beberapa pengulangan dan pengerjaan ulang yang direncanakan.

Hampir semua proyek Agile bersifat inkremental dan iteratif. Namun, dimungkinkan untuk menggunakan strategi iteratif yang tidak juga inkremental; misalnya, strategi "bangun dua kali" di mana yang pertama membuat prototipe sekali pakai untuk mengumpulkan umpan balik pengguna, kemudian menggunakan wawasan dari pengalaman itu untuk membangun "hal yang nyata". Prototyping tentu saja merupakan strategi iteratif, dan mungkin merupakan pendahulu untuk pengembangan ide pengembangan perangkat lunak iteratif.

7. Milestone Retrospective

DEFINISI

Setelah proyek berjalan selama beberapa waktu, atau di akhir proyek (dalam hal ini, terutama ketika tim kemungkinan besar akan bekerja sama lagi), semua anggota tetap tim (bukan hanya pengembang) harus berinvestasi waktu dari satu hingga tiga hari dalam analisis rinci peristiwa penting proyek.

Bahkan lebih dari iterasi retrospektif, ini harus menjadi pertemuan yang difasilitasi, mengikuti format terstruktur yang berbeda-beda sesuai dengan tujuan tetapi akan ditentukan sebelumnya.

KESALAHAN UMUM

• Retrospektif umumnya harus difasilitasi oleh seseorang di luar tim, bukan oleh salah satu anggota, manajer, atau pemangku kepentingan; seseorang dengan kepentingan pribadi pada hasil proyek akan merasa sulit untuk memfasilitasi diskusi secara tidak memihak dan mengambil bagian di dalamnya.
• Kekhawatiran utama dalam retrospektif tonggak sejarah berbeda dari retrospektif iterasi, dan mungkin memiliki dampak yang lebih luas: termasuk kelangsungan proyek jangka panjang atau strategis, hubungan kerja yang sehat di antara anggota tim, atau masalah tata kelola, sementara retrospektif iterasi cenderung fokus pada hal-hal konkrit dan taktis.