Anotasi
Buku ini adalah narasi algoritma untuk melakukan proses pengembangan dari ide ke implementasi menggunakan teknik gesit. Proses ditata dalam langkah-langkah dan pada setiap langkah metode untuk langkah proses ditunjukkan. Penulis menunjukkan bahwa sebagian besar metode tidak asli, tanpa mengklaim sebagai asli. Tetapi gaya presentasi yang baik dan integritas proses membuat buku ini sangat berguna.
Teknik kunci dari peta cerita pengguna adalah penataan ide dan pernyataan saat pengguna melewati proses.
Pada saat yang sama, prosesnya dapat dijelaskan dengan berbagai cara. Anda dapat membangun langkah-langkah saat Anda mencapai nilai kunci, atau Anda bisa mengambil dan membayangkan hari kerja pengguna, bagaimana cara kerjanya menggunakan sistem. Penulis fokus pada fakta bahwa proses perlu dinyatakan, diucapkan dalam bentuk riwayat pengguna pada peta proses, yang merupakan nama peta cerita pengguna.
Siapa yang butuh itu?
Untuk analis TI dan manajer proyek. Bacaan wajib. Bunyinya mudah dan menyenangkan, bukunya berukuran sedang.
Umpan balik
Dalam bentuknya yang paling sederhana, cara kerjanya.
Seorang pengunjung datang ke sebuah kafe, memilih hidangan, memesan, menerima makanan, makan, membayar.
Anda dapat menulis persyaratan yang kami inginkan dari sistem di setiap tahap.
Sistem harus menunjukkan daftar hidangan, masing-masing komposisi hidangan, berat dan harga dan dapat ditambahkan ke keranjang. Mengapa kami yakin dengan persyaratan ini? Ini tidak dijelaskan dalam deskripsi "standar" persyaratan dan ini menimbulkan risiko.
Seniman yang tidak mengerti mengapa ini perlu biasanya tidak melakukan apa yang diperlukan. Pelaku yang tidak terlibat dalam proses menciptakan ide tidak terlibat dalam hasilnya. Agile berkata, jadi mari kita fokus terutama bukan pada sistem, tetapi pada orang, pada konsumen, tugas dan tujuan mereka.
Kami membuat orang, untuk empati kami memberi mereka detail dan di pihak orang-orang kami mulai membuat cerita.
Pegawai kantor Zahar pergi makan siang dan ingin makan cepat-cepat. Apa yang dia butuhkan? Idenya adalah dia mungkin ingin makan siang bisnis. Gagasan lain yang dia ingin agar sistem ingat adalah kesukaannya, karena dia sedang diet. Ide lain. Dia ingin mendapatkan kopi segera, karena dia terbiasa minum kopi sebelum makan malam.
Dan masih ada bisnis (karakter organisasi adalah karakter yang mewakili kepentingan beberapa organisasi). Bisnis ingin meningkatkan tagihan rata-rata, meningkatkan frekuensi pembelian, meningkatkan laba. Idenya adalah, mari kita menawarkan hidangan yang tidak biasa dari beberapa jenis masakan. Gagasan lain - mari kita perkenalkan sarapan.
Gagasan dapat dan harus dikonkretkan, diubah, dan dirancang sebagai kisah pengguna. Sebagai karyawan pusat bisnis Zakhar, saya ingin sistem mengenali saya, sehingga saya menerima menu berdasarkan preferensi saya. Sebagai pelayan, saya ingin sistem memberi tahu saya kapan harus mendekati meja agar klien puas dengan layanan cepat. Dan sebagainya.
Puluhan cerita. Prioritas lebih lanjut dan jaminan simpanan? Jeff menunjukkan masalah yang muncul: keterkaitan dalam detail kecil dan hilangnya pemahaman konseptual ditambah prioritas fungsional menciptakan gambaran yang sobek karena inkonsistensi dengan tujuan.
Jalur penulis: Kami memprioritaskan bukan fungsional, tetapi hasilnya = apa yang pengguna dapatkan sebagai hasilnya.
Poin yang tidak jelas: sesi prioritas tidak diadakan oleh seluruh tim, karena tidak efektif, tetapi oleh tiga orang. Yang pertama bertanggung jawab untuk bisnis, yang kedua untuk pengalaman pengguna dan yang ketiga untuk implementasi.
Kami memilih minimum untuk menyelesaikan satu masalah pengguna (solusi minimum yang layak).
Kami merinci ide-ide prioritas pertama dengan bantuan cerita pengguna, garis besar desain, batasan dan aturan bisnis pada peta cerita pengguna dengan menceritakan dan berdiskusi dengan tim apa yang dibutuhkan orang dan pemangku kepentingan di setiap langkah proses. Ide-ide yang tersisa dibiarkan tak tergabung, dalam tumpukan peluang.
Proses ini ditulis dalam bentuk kartu dari kiri ke kanan, dan ide pada kartu di bawah langkah-langkah proses. Seharusnya jalan seluruh sejarah harus diucapkan bersama dengan tim untuk penampilan saling pengertian.
Paparan dengan cara ini menciptakan integritas untuk pencocokan proses.
Ide-ide yang perlu Anda periksa. Tidak ada anggota tim yang mengenakan topi seseorang dan hidup di kepala orang tersebut, menyelesaikan masalahnya. Varian mungkin terjadi ketika dia tidak melihat perkembangan, membuat kartu baru, dan tim menemukan alternatif.
Kemudian telusuri evaluasi. Tiga orang sudah cukup untuk ini. Bertanggung jawab atas pengalaman pengguna, pengembang, penguji dengan pertanyaan favorit: "Bagaimana jika ...".
Pada setiap tahap, diskusi berlangsung pada peta proses sejarah pengguna, yang memungkinkan menjaga tugas pengguna dalam pikiran untuk menciptakan integritas pemahaman.
Apakah saya memerlukan dokumentasi menurut penulis? Ya saya membutuhkannya. Tetapi sebagai catatan, memungkinkan kita untuk mengingat apa yang kita sepakati. Keterlibatan seseorang dari luar lagi membutuhkan diskusi.
Penulis tidak mempelajari topik kecukupan dokumentasi, dengan fokus pada kebutuhan untuk diskusi. (Ya, dokumentasi diperlukan, tidak peduli bagaimana orang yang tidak dalam memahami gesit). Juga, studi tentang hanya sebagian dari kemampuan dapat menyebabkan kebutuhan untuk perubahan lengkap dari keseluruhan sistem. Penulis menunjukkan risiko elaborasi yang berlebihan dalam kasus ketika mereka belum dapat menebaknya.
Untuk menghilangkan risiko, perlu segera menerima umpan balik tentang produk yang dibuat untuk meminimalkan kerusakan pada penciptaan produk yang "salah". Mereka membuat sketsa ide - divalidasi oleh pengguna, sketsa prototipe antarmuka - divalidasi oleh pengguna, dll. (Secara terpisah, sedikit ditunjukkan bagaimana memvalidasi prototipe program). Tujuan pembuatan perangkat lunak, terutama pada tahap awal, adalah pelatihan melalui umpan balik cepat, sehingga, produk pertama yang dibuat adalah garis besar yang dapat membuktikan atau menyangkal hipotesis. (Penulis mengandalkan karya Eric Rice, "Startup oleh Lean Methodology").
Peta cerita membantu membangun komunikasi jika implementasinya disediakan oleh beberapa tim. Apa yang seharusnya ada di peta? Apa yang Anda butuhkan untuk mendukung percakapan. Tidak hanya cerita pengguna (siapa, apa, mengapa), tetapi ide, fakta, garis besar antarmuka, dll.
Membagi kartu pada peta sejarah menjadi beberapa garis horizontal, Anda dapat membagi pekerjaan menjadi rilis - pilih yang paling minimum, lapisan fungsional dan haluan bangunan.
Kami menceritakan kisah di peta proses.
Karyawan itu datang untuk makan siang.
Apa yang dia inginkan? Kecepatan layanan. Sehingga makan malamnya sudah menunggunya di atas meja atau setidaknya di atas nampan. Opa - langkah yang terlewatkan: karyawan ingin makan. Dia masuk ke sistem dan memilih opsi makan siang bisnis. Dia melihat kandungan kalori dan nilai gizi untuk mempertahankan diet dan tidak menjadi gemuk. Dia melihat foto-foto hidangan untuk memutuskan apakah dia akan makan di tempat ini atau tidak.
Selanjutnya, dia akan pergi makan siang dan makan siang? Atau mungkin dia akan makan siang di kantor? Maka langkah prosesnya adalah memilih tempat makan. Dia ingin melihat waktu kapan dia akan dikirim dan berapa biayanya untuk memilih tempat untuk menghabiskan waktu dan usaha - untuk turun atau bekerja. Dia ingin melihat kafe itu sibuk agar tidak berdesakan dalam antrean.
Selanjutnya, karyawan datang ke kafe. Dia ingin melihat nampannya, mengambilnya dan segera pergi makan malam. Kafe ingin menerima uang untuk mendapatkan uang pemeliharaan. Seorang karyawan ingin kehilangan waktu minimum di pemukiman dengan kafe, agar tidak membuang waktu yang berharga tanpa keuntungan. Bagaimana cara melakukannya? Bayar di muka atau sebaliknya setelah melakukan servis jarak jauh. Atau bayar saat ini menggunakan kios. Manakah dari ini yang paling mendasar? Berapa banyak orang yang mau membayar dengan kartu kredit untuk makan siang? Berapa banyak orang yang mempercayai penyimpanan nomor kartu untuk pembayaran berulang di ruang makan ini? Tanpa penelitian lapangan, tidak jelas apakah pengujian diperlukan.
Pada setiap langkah proses, Anda perlu setidaknya menyediakan fungsionalitas, untuk ini Anda perlu mengambil dasar beberapa jenis orang dan memilih apa yang lebih penting baginya (tiga pemilih yang sama). Melewati cerita sampai akhir = membuat keputusan yang layak.
Berikutnya adalah detailnya. Klien ingin melihat beban kerja kafe agar tidak berdesakan dalam antrian. Apa sebenarnya yang dia inginkan?
Perhatikan ramalan berapa banyak orang dalam 15 menit, ketika dia akan pergi ke sana
Tonton waktu servis rata-rata di sebuah kafe dan dinamika selama setengah jam ke depan
Perhatikan situasi dan dinamika penggunaan tabel
Tetapi bagaimana jika sistem peramalan memberikan hasil yang tidak dapat dipahami atau berhenti bekerja?
Tonton melalui garis video di kafe, serta penggunaan meja. Hmm, kenapa tidak melakukannya dulu?
Penulis menunjukkan latihan kecil untuk berlatih: coba bayangkan apa yang Anda lakukan di pagi hari setelah bangun tidur. Satu kartu = satu tindakan. Perbesar kartu (alih-alih menggiling kopi - minum minuman yang menyegarkan) untuk menghilangkan detail individu, dengan fokus bukan pada cara implementasi, tetapi pada tujuan.
Untuk siapa buku ini ditujukan untuk analis dan manajer proyek TI. Bacaan wajib.
Aplikasi
Diskusi dan pengambilan keputusan efektif dalam kelompok yang terdiri dari 3 hingga 5 orang.
Tulis pada kartu pertama apa yang perlu dikembangkan, pada kartu kedua - untuk memperbaiki apa yang dilakukan pada kartu pertama, kartu ketiga - untuk memperbaiki apa yang dilakukan pada kartu pertama dan kedua.
Siapkan cerita seperti kue - bukan menulis resep untuk membuat, tetapi mencari tahu kepada siapa, untuk alasan apa, berapa banyak orang yang memiliki kue. Jika Anda memecah implementasi, maka bukan pada pembuatan kue, krim, dll, tetapi pada pembuatan kue jadi kecil.
Pengembangan perangkat lunak mirip dengan membuat film ketika Anda perlu mengembangkan dan menjilat naskah, mengatur adegan, aktor, dll., Sebelum pembuatan film dimulai.
Sumber daya akan selalu langka.
20% dari upaya memberikan hasil nyata, 60% memberikan tidak jelas bahwa, 20% dari upaya itu merugikan - itu sebabnya penting untuk fokus pada pembelajaran dan tidak putus asa jika hasil negatif.
Berkomunikasi dengan pengguna secara langsung, rasakan sepatunya. Fokus pada beberapa masalah.
Merinci dan menyusun sejarah untuk evaluasi adalah bagian yang paling suram dari scrum, membuat diskusi berdiri dalam mode akuarium (3-4 orang berdiskusi di papan, jika seseorang ingin berpartisipasi, ia menggantikan seseorang).