Pendekatan Lean Agile dalam Tindakan

Contoh Portal Mahasiswa

Sebuah perguruan tinggi masyarakat ingin mengembangkan portal mahasiswa untuk menyediakan layanan daring bagi mahasiswa. Mereka mengundang perwakilan mahasiswa, staf dari departemen, dan anggota administrator portal untuk membentuk tim yang berpartisipasi dalam proyek pengembangan portal mahasiswa. Berikut adalah catatan dari rapat pertama.

Rapat pemangku kepentingan

Agenda

• Sarankan fitur untuk portal mahasiswa
• Bahas kelayakan daftar fitur yang diusulkan
• Tentukan prioritas fitur yang akan diimplementasikan sebagai inti, batch berikutnya, bagus jika ada…

Steve (Tim Pengembang): Selamat datang… Kami ingin membuat rapat ini lebih produktif dan bermanfaat. Saat kami mengusulkan fitur yang ingin Anda miliki, kami dapat menggunakan format berikut sebagai cara standar untuk menyampaikan: siapa (anda), fitur apa (yang Anda inginkan), dan (mengapa Anda menginginkannya)… Fitur-fitur ini akan direkam sebagai cerita pengguna sebagai alat komunikasi sepanjang proyek ini.

Kami kemudian melakukan brainstorming untuk membuat daftar cerita pengguna dari berbagai pemangku kepentingan:

Perwakilan mahasiswa: mendaftar mata kuliah, membayar biaya kuliah, melihat jadwal waktu, mengedit jadwal, melihat kartu nilai, menghapus mata kuliah…

Perwakilan Akademik: menambahkan informasi mata kuliah, mengedit informasi mata kuliah, menghapus informasi mata kuliah…

Admin Portal: cadangan informasi mata kuliah, mengedit status akun mahasiswa

Sekarang, kami memiliki sejumlah kartu yang dapat diatur menjadi baris dan kolom

Tentukan Prioritas Fitur yang Diusulkan

Perwakilan Pengembang: Kami memiliki daftar cerita pengguna yang telah diprioritaskan untuk diimplementasikan dalam iterasi mendatang. Untuk ini, kami perlu menggali lebih dalam setiap cerita pengguna untuk memahami dan mendapatkan informasi lebih lanjut. Mari kita bahas cerita pengguna fitur inti pertama ‘mendaftar mata kuliah’

Kami mendapatkan informasi tambahan berikut dari pengguna akhir untuk rapat:

• Akademik: mahasiswa harus merupakan mahasiswa penuh waktu yang terdaftar
• Admin: mahasiswa harus menyediakan kredensial akun yang benar untuk masuk
• Akademik: mata kuliah belum penuh
• Akademik: prasyarat mata kuliah harus dipenuhi
• Admin: mata kuliah yang dipilih untuk ditambahkan ke jadwal tidak boleh bertabrakan dengan slot waktu mata kuliah lain
• Pengembang: fitur lain apa yang ingin Anda kelompokkan bersama sebagai daftar dengan fitur ini dalam sistem target?
• Mahasiswa: menghapus mata kuliah, melihat jadwal, mengedit jadwal.

3C dari Cerita Pengguna

Cerita pengguna yang baik jauh lebih dari sekadar pernyataan. Sebuah cerita pengguna standar terdiri dari tiga bagian, yang biasanya disebut sebagai tiga C. C pertama dari setiap cerita pengguna harus mengikuti format standar sebagai Berdasarkan [peran], saya ingin [melakukan sesuatu], agar [manfaat], yang merupakan konten minimal dari cerita pengguna yang harus dimasukkan ke dalam kartu. Percakapan adalah isi dari C kedua dari cerita pengguna yang merepresentasikan diskusi antara pengguna akhir, pemilik proyek, dan tim pengembang. Dalam percakapan ini, mencatat diskusi lisan, atau berbagai informasi berguna lainnya seperti email, wireframe, atau konten terkait lainnya untuk proyek. C terakhir dari cerita pengguna adalah konfirmasi yang merupakan kriteria penerimaan yang digunakan untuk memastikan bahwa cerita pengguna telah diimplementasikan dengan benar dan berhasil dikirimkan.

Biarkan saya menjelaskan sedikit lebih lanjut tentang cara mengembangkan bagian konfirmasi dari sebuah cerita pengguna. Di sini kita menggunakan template yang paling terkenal, yaitu Gherkin, yang mengadopsi rumus Given-When-Then untuk membimbing penulisan tes penerimaan untuk sebuah Cerita Pengguna:

• (Diberikan.. dan) beberapa konteks
• (Ketika.. dan) beberapa tindakan dilakukan
• (Kemudian.. dan) Lakukan beberapa tindakan

Alat seperti Cucumber dan kerangka pengujian Jbehave mendorong penggunaan template Given/Then/Then untuk melakukan pengujian otomatis, meskipun juga dapat digunakan secara murni sebagai heuristik terlepas dari apakah alat akan digunakan atau tidak.

Mari kita kumpulkan semua informasi untuk cerita pengguna ‘daftar kursus’ dan masukkan ke dalam format 3Cs:

Sekarang, mari kita masukkan informasi tersebut ke dalam UeXceler yang mencakup konversi dan konfirmasi yang telah kita kembangkan sebelumnya.

Memecah Epik menjadi Cerita Pengguna

Jika kita menyelidiki cerita pengguna ‘daftar kursus’ lebih lanjut secara rinci, kita mungkin menemukan bahwa cerita tersebut terlalu besar untuk dimasukkan ke dalam satu sprint. Kita dapat menganggapnya sebagai Epik (cerita pengguna yang lebih besar), yang dapat dibagi menjadi sekelompok cerita pengguna kecil yang saling terkait. Kita dapat membagi epik menjadi tugas, yang saya sebut pemecahan horizontal, atau alternatifnya kita dapat membagi epik menjadi skenario dan disebut pemecahan vertikal.

Pemecahan Horizontal

Pendekatan tradisional dalam membangun fitur besar adalah dengan mendekomposisinya menjadi pekerjaan yang harus dilakukan pada lapisan arsitektur. Misalnya, model tampilan dan kontrol (MVC) atau arsitektur klien-server, sehingga kita menciptakan pemisahan tanggung jawab untuk arsitektur sistem, dan selanjutnya menyempurnakannya menjadi arsitektur n-lapisan seperti GUI, logika kontrol, model objek, pemetaan relasional objek, lapisan basis data, dan sebagainya. Ada cukup banyak komponen dalam arsitektur n-lapisan, dan saya di sini hanya akan mencantumkan beberapa di antaranya sebagai berikut:

• Memungkinkan kita mengembangkan keahlian tinggi di salah satu lapisan arsitektur
• Aplikasi lain akan dapat merekayasa fungsi yang diungkapkan oleh lapisan Anda.
• Anda akan dapat mendistribusikan lapisan Anda ke dalam beberapa tingkatan fisik. Ini dapat memberikan dampak yang sangat baik pada aplikasi Anda dengan meningkatkan kinerja (kadang-kadang), skalabilitas, dan ketahanan terhadap kesalahan.
• Pemeliharaan aplikasi Anda menjadi lebih mudah karena rendahnya keterikatan antar lapisan.
• Menambahkan lebih banyak fungsi ke dalam aplikasi Anda menjadi lebih mudah.
• Lapisan membuat aplikasi Anda lebih dapat diuji.

Ada sejumlah besar implementasi sukses berdasarkan arsitektur n-lapisan, seperti Ruby on Rails dan arsitektur berbasis layanan web.

Cerita Pengguna dan Pemecahan Horizontal

Meskipun memiliki atau mendapatkan manfaat dari arsitektur n-lapisan untuk sistem kita, hal ini memiliki beberapa kekurangan ketika kita menggunakannya dengan pendekatan cerita pengguna. Hal ini cenderung memiliki siklus umpan balik yang sangat lambat tergantung pada ukuran fitur, karena kita harus menunggu semua pihak selesai dengan bagian masing-masing untuk diintegrasikan dan memastikan semuanya berfungsi dengan baik. Istilah ‘pemotongan horizontal’ mengacu pada penggunaan pendekatan lapisan arsitektur ini sebagai metode utama dekomposisi fitur besar.

Pemecahan Vertikal

Untuk mempercepat siklus umpan balik, kita dapat mengambil sebuah epik dan membaginya menjadi beberapa skenario pengguna yang memotong setiap lapisan arsitektur. Kita dapat memecah hampir semua fitur menjadi potongan-potongan sehingga hanya membutuhkan waktu beberapa hari saja untuk membangun, mengintegrasikan, dan menguji semua bagian. Setiap potongan terdiri dari semua pekerjaan yang perlu dilakukan pada lapisan arsitektur serta pengujian dan integrasi yang mungkin perlu dilakukan agar siap dirilis.

Secara umum, pemecahan horizontal membagi fitur menjadi cerita pengguna atau tugas pada tingkat komponen arsitektur. Contoh: antarmuka pengguna depan, basis data, atau layanan backend. Sedangkan potongan vertikal menghasilkan perangkat lunak yang berfungsi dan dapat ditunjukkan, yang menambah nilai bisnis. Dengan demikian, pemecahan vertikal meningkatkan kemampuan tim untuk menghasilkan peningkatan produk yang dapat dikirimkan setiap sprint. Bayangkan memotong kue yang terdiri dari lapisan krim, cokelat, buah, dan kue. Jika Anda memotong kue secara horizontal, teman Anda hanya akan mendapatkan sepotong kue, cokelat, krim, atau buah. Saya yakin teman-teman Anda akan lebih memilih potongan yang mengandung sedikit dari semua lapisan. Mendapatkan hanya satu lapisan kue tidak memungkinkan mereka merasakan rasa sebenarnya dari seluruh kue. Pendekatan yang lebih ramah bagi teman-teman Anda adalah membuat potongan vertikal (nilai yang diinginkan).

Memecah Epik Secara Horizontal dengan Tujuan

Ingat bahwa konversi untuk cerita pengguna ‘daftar kursus’ yang kita miliki dalam pertemuan stakeholder, fitur tersebut pertama kali diusulkan oleh para mahasiswa (peran utama) dan didukung oleh stakeholder lainnya. Ketika kita menelusuri detail cerita pengguna, kita menemukan bahwa cukup banyak informasi disisihkan oleh stakeholder lain yang akan terlibat dalam cerita pengguna sebagai peran pendukung.

Dalam kenyataannya, beberapa mahasiswa mungkin tidak peduli atau bahkan tidak ingin mematuhi batasan yang ditetapkan oleh orang-orang dengan peran pendukung. Misalnya, seorang mahasiswa lupa kata sandi dan telah memasukkannya secara salah sebanyak tiga kali, ia/ia mungkin tidak ingin melalui proses reset kata sandi, tetapi masih memiliki kepercayaan diri untuk mencoba beberapa kali lagi, atau mahasiswa tidak ingin memiliki kuota untuk buku perpustakaan, atau periode pinjaman, dan sebagainya. Orang yang ingin menetapkan beberapa aturan bisnis dan batasan terhadap fitur yang diusulkan sebagai tujuan pengguna mereka adalah mereka yang terlibat sebagai peran pendukung dalam cerita pengguna. Fitur tersebut seharusnya tidak beroperasi sama sekali jika aturan bisnis dan tujuan kedua tidak diterapkan pada fitur yang diusulkan. Jika kita memecah epik secara horizontal berdasarkan tujuan (tujuan) para aktor sekunder menjadi sekelompok cerita pengguna, kita dapat memenuhi tujuan (tujuan) para aktor sekunder, membuat cerita pengguna dapat diuji, serta mendapatkan umpan balik langsung dari orang yang tepat.

Mari kita selidiki informasi dari bagian konversi dan konfirmasi untuk melihat bagaimana kita dapat memecah cerita besar ‘daftar kursus’ menjadi sekelompok cerita pengguna yang saling terkait.

1. Mahasiswa harus merupakan mahasiswa yang terdaftar, jika tidak maka ia tidak akan mendapatkan kredensial yang diberikan oleh pemberitahuan untuk mahasiswa baru. Jika ia telah menerima pemberitahuan tetapi akun belum diaktifkan, maka ia perlu mendaftar akun baru secara online (ditandai dengan lingkaran merah 1)
2. Jika kita menyelidiki proses login lebih dalam, kita tahu bahwa jika seorang mahasiswa memberikan kredensial secara salah sebanyak tiga kali, maka ia perlu memasuki proses ‘reset kata sandi’ (ditandai dengan lingkaran merah 2 & 3)

Ruang Cerita Pengguna Umum

Mari kita buat cerita pengguna ini di UeXceler:

Cerita pengguna Login Akun dibuat di bawah kompartemen cerita pengguna umum. Selain cerita pengguna login, ada dua cerita pengguna terkait lainnya yang juga sedang dibuat di bawah kompartemen cerita pengguna umum, yaitu “reset kata sandi” dan “Buat akun siswa baru” untuk alasan berikut:

• Jika kredensial akun yang dimasukkan oleh siswa salah sebanyak 3 kali, maka akan memicu cerita pengguna “reset kata sandi”;
• dan jika seorang siswa baru belum mendaftar akun siswa, ia dapat memicu cerita pengguna “Buat Akun Siswa Baru” di layar login.

1. Sebagai siswa, saya ingin masuk ke portal siswa, agar…
2. Sebagai administrator portal, saya ingin memverifikasi bahwa orang yang masuk adalah siswa terdaftar, agar…
3. Sebagai kepala kursus, saya ingin memverifikasi kelayakan sebelum mengizinkan kursus yang dipilih ditambahkan ke jadwal siswa, agar…

Kita dapat menganggap ketiga cerita pengguna ini dipisah secara horizontal dari epik – “daftar kursus”, tetapi cerita-cerita pengguna ini akan memenuhi tujuan dari beberapa aktor pendukung yang dapat Anda dapatkan umpan balik dan konfirmasi dari. Jika prasyarat tidak terpenuhi, cerita pengguna utama tidak akan lagi bermakna sama sekali.

Anda dapat melihat bahwa kami menempatkan semua cerita pengguna ini di bawah kompartemen cerita pengguna umum dan alasannya adalah mereka kemungkinan besar berbagi prasyarat yang sama bersama fitur (cerita pengguna) terkait lainnya di halaman pemanggil yang sama, seperti, “lihat jadwal”, “edit jadwal”, “hapus kursus”, dan sebagainya.

Kompartemen Kasus Pengguna

Ada tiga sisa yang dilingkari merah bernomor 4, 5, dan 6 pada Gambar di atas. Mereka adalah skenario alternatif dari epik “daftar kursus”. Jika salah satu dari tiga kondisi ini tidak terpenuhi, maka akan ada skenario alternatif untuk itu dan dapat direpresentasikan sebagai cerita pengguna yang terpisah. Mungkin kita bisa membaginya secara horizontal atau vertikal, tetapi bukankah pemisahan vertikal selalu lebih disukai? Tidak selalu, sangat tergantung pada situasinya. Tidak ada solusi satu ukuran untuk semua di dunia ini, kita perlu mempertimbangkan pendekatan mana yang lebih sesuai untuk kasus Anda. Biarkan saya jelaskan lebih lanjut.

Sebagai contoh, jika Anda akan menugaskan cerita pengguna utama untuk satu pengembang dan tiga cerita pengguna login, daftar akun baru, dan reset kata sandi untuk pengembang lainnya. Anda mungkin lebih memilih pengembang yang bertanggung jawab atas cerita pengguna utama untuk mengembangkan skenario yang menyenangkan terlebih dahulu dalam sprint saat ini, lalu secara bertahap mengembangkan skenario alternatif pada sprint berikutnya oleh pengembang yang sama (jika waktu yang tersedia memungkinkan). Namun jika waktu yang tersedia singkat dan pada saat yang sama Anda merasa terlalu berat bagi satu pengembang untuk mengelola seluruh epik, maka Anda bisa membaginya secara horizontal ke dalam tugas-tugas untuk ditugaskan kepada beberapa pengembang secara paralel.

Pemisahan Epik menjadi Skenario

Jika kita mempertimbangkan rincian skenario yang dijelaskan dalam bagian konfirmasi epik, kita dapat dengan mudah menemukan potongan vertikal untuk sekelompok cerita pengguna yang terkait.

1. Sebagai kepala kursus, saya ingin memverifikasi persyaratan prasyarat sebelum mengizinkan kursus yang dipilih ditambahkan ke jadwal siswa, agar…
2. Sebagai kepala kursus, saya ingin memeriksa ketersediaan kursus sebelum mengizinkan kursus ditambahkan ke jadwal siswa, agar…
3. Sebagai kepala kursus, saya ingin memverifikasi ketersediaan slot waktu siswa sebelum mengizinkan kursus yang dipilih ditambahkan ke jadwal siswa, agar…

Pemisahan Epik menjadi Tugas

Jika kita ingin epik diuraikan menjadi tugas-tugas kecil untuk pengembangan paralel dalam sprint yang sama seperti berikut:

1. Periksa status kuota kursus
2. Periksa prasyarat kursus
3. Periksa slot waktu

Sekarang, terserah Anda untuk memilih bagaimana epik dipisah menjadi cerita-cerita pengguna dalam proses pengembangan agil. Anda dapat melihat cerita pengguna “Daftar Kursus” dan cerita-cerita pengguna terkait ditempatkan di bawah kompartemen kasus pengguna (epik Anda), juga disebut Daftar Kursus, yang digunakan sebagai tempat sementara untuk menampung semua cerita pengguna utama dan cerita-cerita pengguna yang dipisah dari cerita utama tersebut.