Anotasi
Buku ini merupakan narasi algoritma untuk melakukan proses pengembangan dari ide hingga implementasi dengan menggunakan teknik agile. Prosesnya diuraikan dalam langkah-langkah dan pada setiap langkah metode untuk langkah proses tersebut ditunjukkan. Penulis menunjukkan bahwa sebagian besar metode tidak orisinal, tanpa mengklaim orisinalitasnya. Namun gaya penulisan yang baik dan integritas prosesnya menjadikan buku ini sangat berguna.
Teknik utama pemetaan cerita pengguna adalah menyusun ide dan kinerja saat pengguna menjalani proses tersebut.
Pada saat yang sama, prosesnya dapat dijelaskan dengan cara yang berbeda. Anda dapat menyusun langkah-langkah saat Anda mencapai nilai kunci, atau Anda dapat mengambil dan membayangkan hari kerja pengguna saat mereka menggunakan sistem. Penulis berfokus pada fakta bahwa proses perlu diuraikan, diucapkan dalam bentuk cerita pengguna pada peta proses, itulah yang memberi kami nama peta cerita pengguna.
Siapa yang butuh itu?
Untuk analis TI dan manajer proyek. Harus dibaca. Mudah dan enak dibaca, buku ini berukuran sedang.
Tinjau
Dalam bentuk yang paling sederhana, beginilah cara kerjanya.
Seorang pengunjung datang ke kafe, memilih hidangan, memesan, menerima makanan, makan, dan membayar.
Kita dapat menulis persyaratan untuk apa yang kita inginkan dari sistem di setiap tahap.
Sistem harus menampilkan daftar hidangan, setiap hidangan memiliki komposisi, berat dan harga serta dapat ditambahkan ke troli. Mengapa kami yakin dengan persyaratan ini? Hal ini tidak dijelaskan dalam deskripsi persyaratan βstandarβ dan hal ini menimbulkan risiko.
Pelaku yang tidak mengerti mengapa hal ini perlu biasanya melakukan hal yang salah. Pelaku yang tidak terlibat dalam proses penciptaan ide tidak terlibat dalam hasil. Agile mengatakan, mari kita fokus bukan pada sistem, tetapi pada manusia, konsumen, tugas dan tujuan mereka.
Kami menciptakan persona, memberi mereka detail untuk empati, dan mulai menceritakan kisah dari sisi persona tersebut.
Pegawai kantor Zakhar pergi makan siang dan ingin makan sebentar. Apa yang dia butuhkan? Idenya adalah dia mungkin ingin makan siang bisnis. Ide lainnya adalah dia ingin sistem mengingat kesukaannya, karena dia sedang diet. Ide lain. Dia ingin kopi segera dibawakan karena dia terbiasa minum kopi sebelum makan siang.
Dan ada juga bisnis (karakter organisasi adalah karakter yang mewakili kepentingan suatu organisasi). Bisnis ingin meningkatkan rata-rata cek, meningkatkan frekuensi pembelian, dan meningkatkan keuntungan. Idenya adalah - mari kita tawarkan hidangan yang tidak biasa dari beberapa masakan. Ide lainnya - mari perkenalkan sarapan.
Ide dapat dan harus dikonkretkan, diubah, dan disajikan dalam bentuk cerita pengguna. Sebagai karyawan Zakhar Business Center, saya ingin sistem mengenali saya sehingga saya dapat menerima menu berdasarkan preferensi saya. Sebagai pelayan, saya ingin sistem memberi tahu saya kapan harus mendekati meja agar klien puas dengan pelayanan yang cepat. Dan seterusnya.
Puluhan cerita. Berikutnya adalah prioritas dan simpanan? Jeff menunjukkan masalah yang muncul: terjebak dalam detail kecil dan kehilangan pemahaman konseptual, ditambah memprioritaskan fungsionalitas menciptakan gambaran yang tidak jelas karena ketidakkonsistenan dengan tujuan.
Jalur penulis: Kami tidak memprioritaskan fungsionalitas, tetapi hasil = apa yang pengguna dapatkan pada akhirnya.
Hal yang jelas tidak jelas: sesi penentuan prioritas tidak dilakukan oleh seluruh tim, karena tidak efektif, melainkan oleh tiga orang. Yang pertama bertanggung jawab atas bisnis, yang kedua bertanggung jawab atas pengalaman pengguna, dan yang ketiga bertanggung jawab atas implementasi.
Mari kita pilih solusi minimum untuk satu masalah pengguna (solusi minimum yang layak).
Kami merinci ide prioritas pertama menggunakan cerita pengguna, sketsa desain, batasan, dan aturan bisnis pada peta cerita pengguna dengan memberi tahu dan berdiskusi dengan tim apa yang dibutuhkan masyarakat dan pemangku kepentingan di setiap langkah proses. Kami membiarkan ide-ide yang tersisa tidak teruji dalam simpanan peluang.
Prosesnya ditulis pada kartu dari kiri ke kanan, dengan ide pada kartu di bawah langkah-langkah proses. Sangat penting bahwa keseluruhan cerita didiskusikan bersama dengan anggota tim untuk memastikan saling pengertian.
Elaborasi dengan cara ini menciptakan integritas dalam kepatuhan terhadap proses.
Ide-ide yang diterima perlu diuji. Seorang yang bukan anggota tim mengenakan topi orang tersebut dan menjalani hari-hari orang tersebut di kepalanya, memecahkan masalahnya. Mungkin saja dia tidak melihat perkembangannya, membuat kartu lagi, dan tim menemukan alternatif untuk dirinya sendiri.
Lalu ada detail untuk evaluasi. Tiga orang sudah cukup untuk ini. Bertanggung jawab atas pengalaman pengguna, pengembang, penguji dengan pertanyaan favorit: βBagaimana jikaβ¦β.
Pada setiap tahap, diskusi mengikuti peta proses riwayat pengguna, yang memungkinkan mengingat tugas pengguna untuk menciptakan pemahaman yang koheren.
Apakah dokumentasi diperlukan menurut pendapat penulis? Ya, saya membutuhkannya. Namun sebagai catatan yang memungkinkan Anda mengingat apa yang telah Anda sepakati. Melibatkan pihak luar lagi-lagi memerlukan diskusi.
Penulis tidak mendalami topik kecukupan dokumentasi, hanya fokus pada perlunya pembahasan. (Ya, dokumentasi diperlukan, tidak peduli bagaimana orang yang tidak memiliki pemahaman mendalam tentang agile mengklaimnya). Selain itu, penjabaran hanya sebagian dari kemampuan dapat menyebabkan perlunya pengerjaan ulang keseluruhan sistem secara menyeluruh. Penulis menunjukkan risiko elaborasi berlebihan jika idenya salah.
Untuk menghilangkan risiko, perlu segera menerima umpan balik terhadap produk yang dibuat untuk meminimalkan kerugian akibat pembuatan produk yang βsalahβ. Kami membuat sketsa ide - memvalidasinya dengan pengguna, membuat sketsa prototipe antarmuka - memvalidasinya dengan pengguna, dll. (Secara terpisah, ada sedikit informasi tentang cara memvalidasi prototipe program). Tujuan pembuatan perangkat lunak terutama pada tahap awal adalah belajar melalui penerimaan umpan balik yang cepat, oleh karena itu produk pertama yang dibuat adalah sketsa yang mampu membuktikan atau menyangkal suatu hipotesis. (Penulis mengandalkan karya Eric Ries βStartup menggunakan metodologi Leanβ).
Peta cerita membantu meningkatkan komunikasi ketika implementasi dilakukan di beberapa tim. Apa yang seharusnya ada di peta? Apa yang Anda perlukan agar percakapan tetap berjalan. Bukan hanya cerita pengguna (siapa, apa, mengapa), tapi ide, fakta, sketsa antarmuka, dll...
Dengan membagi kartu di peta riwayat menjadi beberapa garis horizontal, Anda dapat membagi pekerjaan menjadi rilis - sorot minimum, lapisan fungsionalitas yang meningkat, dan busur.
Kami bercerita di peta proses.
Seorang karyawan datang untuk makan siang.
Apa yang dia mau? Kecepatan layanan. Sehingga makan siangnya sudah menunggunya di meja atau setidaknya di nampan. Ups - langkah terlewat: karyawan tersebut ingin makan. Dia masuk dan memilih opsi makan siang bisnis. Ia melihat kandungan kalori dan kandungan nutrisinya membantunya berdiet dan tidak menambah berat badan. Dia melihat gambar hidangan tersebut untuk memutuskan apakah dia akan makan di tempat itu atau tidak.
Selanjutnya, apakah dia akan pergi makan siang dan makan malam? Atau mungkin makan siang akan diantar ke kantornya? Kemudian tahapan prosesnya adalah memilih tempat makan. Dia ingin melihat kapan barang itu akan dikirimkan kepadanya dan berapa biayanya, sehingga dia dapat memilih di mana akan menghabiskan waktu dan tenaganya - turun ke bawah atau pergi bekerja. Ia ingin melihat betapa sibuknya kafe tersebut agar tidak berdesakan dalam antrian.
Kemudian karyawan itu datang ke kafe. Dia ingin melihat nampannya agar dia bisa mengambilnya dan langsung makan malam. Kafe ingin menerima uang untuk menghasilkan uang dari layanan. Karyawan tersebut ingin kehilangan waktu minimal dalam penyelesaian dengan kafe, agar tidak membuang waktu yang berharga dengan sia-sia. Bagaimana cara melakukannya? Bayar di muka atau sebaliknya setelah layanan jarak jauh. Atau bayar di tempat menggunakan kios. Apa hal terpenting tentang ini? Berapa banyak orang yang bersedia membayar makan siangnya dengan kartu bank? Berapa banyak orang yang mempercayai kantin ini untuk menyimpan nomor kartu mereka untuk pembayaran berulang? Tanpa penelitian lapangan tidak jelas, diperlukan pengujian.
Pada setiap langkah proses, Anda perlu menyediakan fungsionalitas; untuk ini Anda perlu mengambil seseorang sebagai dasar dan memilih apa yang lebih penting baginya (tiga pemilih yang sama). Ikuti ceritanya sampai akhir = membuat solusi yang layak.
Berikutnya adalah detailnya. Klien ingin melihat betapa sibuknya kafe tersebut, agar tidak berdesakan dalam antrian. Apa sebenarnya yang dia inginkan?
Lihat perkiraan berapa banyak orang yang akan hadir dalam 15 menit ketika dia sampai di sana
Lihat waktu layanan rata-rata di kafe dan dinamikanya setengah jam sebelumnya
Lihat situasi dan dinamika keterisian meja
Bagaimana jika sistem peramalan memberikan hasil yang tidak jelas atau berhenti bekerja?
Saksikan melalui video antrian di kafe, serta keterisian meja. Hmm, kenapa tidak dilakukan dulu?!
Penulis menunjukkan latihan kecil untuk dipraktikkan: coba bayangkan apa yang Anda lakukan di pagi hari setelah bangun tidur. Satu kartu = satu tindakan. Perbesar kartu (alih-alih menggiling kopi, minumlah minuman yang menyegarkan) untuk menghilangkan detail individual, dengan fokus bukan pada metode pelaksanaan, tetapi pada tujuan.
Untuk siapa buku ini: Analis TI dan manajer proyek. Harus dibaca.
Aplikasi
Diskusi dan pengambilan keputusan efektif dalam kelompok yang terdiri dari 3 sampai 5 orang.
Tulis di kartu pertama apa yang perlu dikembangkan, di kartu kedua - perbaiki apa yang Anda lakukan di kartu pertama, di kartu ketiga - perbaiki apa yang telah dilakukan di kartu pertama dan kedua.
Siapkan cerita seperti kue - bukan dengan menuliskan resepnya, namun dengan mencari tahu siapa, untuk acara apa, dan untuk berapa orang kue tersebut. Jika kita membagi penjualannya, maka penjualannya bukan menjadi produksi kue, krim, dll, tetapi menjadi produksi kue-kue kecil yang sudah jadi.
Pengembangan perangkat lunak mirip dengan pembuatan film, ketika Anda perlu mengembangkan dan memoles naskah dengan hati-hati, mengatur adegan, aktor, dll. sebelum pembuatan film dimulai.
Akan selalu ada kekurangan sumber daya.
20% upaya memberikan hasil yang nyata, 60% memberikan hasil yang tidak dapat dipahami, 20% upaya merugikan - itulah mengapa penting untuk fokus pada pembelajaran dan tidak putus asa jika terjadi hasil negatif.
Berkomunikasi langsung dengan pengguna, rasakan diri Anda pada posisinya. Fokus pada beberapa masalah.
Merinci dan mengembangkan cerita untuk evaluasi adalah bagian paling suram dari scrum, membuat diskusi stand-up dalam mode akuarium (3-4 orang berdiskusi di papan, jika ada yang ingin berpartisipasi, dia menggantikan seseorang).
Sumber: www.habr.com