Bayangkan sebuah situasi - penguji menemukan bug, mulai mendiskusikannya dengan pengembang - dan dia bersikeras bahwa ini bukan bug, karena spesifikasi tidak membicarakan fungsi ini. Apakah itu familier?
Atau karena persyaratannya tidak jelas, dan dia salah paham. Atau mungkin sebaliknya, mereka memiliki begitu banyak informasi sehingga fokus hilang dan beberapa informasi hilang selama pengembangan.
Dan dalam situasi ini, pengembang bukanlah hama yang sengaja melakukan kesalahan. Dalam praktiknya, jika Anda memberikan persyaratan singkat, mudah dimengerti, dan yang paling penting, maka jumlah kesalahan yang akan ditemukan oleh penguji akan menjadi nol.
Anda juga mungkin terbiasa dengan perselisihan tentang masalah "bug atau fitur". Pelanggan telah menemukan kekurangan, dan pemilik produk datang ke tim dengan komentar. Dan penguji dan pengembang membela diri, menjelaskan hal ini dengan fakta bahwa dalam pengaturan asli tidak ada pembicaraan tentang implementasi fitur ini. Dan saat-saat seperti itu kemudian mulai di backlog.
Saya percaya bahwa semua tugas yang dilembagakan setelah rilis, dan yang merupakan hasil dari spesifikasi yang dikembangkan dengan buruk, juga bug. Bug yang menjadi ciri kualitas produk Anda.
Ternyata analis bisnis menentukan fitur apa yang perlu dibuat. Pengembang membuatnya. Penguji menemukan cacat dalam pekerjaan keduanya. Inilah cara pendekatan pembangunan tradisional bekerja. Tetapi Anda dapat mengajar ketiganya untuk bekerja sama untuk melakukan pekerjaan mereka dengan lebih baik dan segera, tanpa perubahan tambahan. Dan cara komunikasi ini disebut 3 Amigo. Juga disebut Story Kick Off Huddles atau Triad.
3 Amigo adalah ...
3 Amigo adalah praktik yang memberikan pemahaman universal tentang apa yang akan disampaikan kepada pelanggan. Ini membantu untuk menyampaikan suara tim, bukan menjalin pendapat yang tersebar.
Metode komunikasi dalam tim ini membantu:
- mencapai kesepakatan bersama tentang harapan sebelum pengembangan
- membentuk kesepakatan tentang cara melakukan hal yang benar segera
Ini juga membantu untuk memahami:
- masalah apa yang kita pecahkan
- apa solusinya
- apa yang perlu kita lakukan agar tugasnya siap
Pertemuan tiga amigo adalah cara berpikir bersama yang menjembatani kesenjangan dalam memahami spesifikasi bisnis. Dia membantu dalam pengembangan cerita pengguna yang keren.
Tujuannya adalah untuk melakukan pekerjaan tepat waktu, tetapi pada saat yang sama tidak merencanakan ke depan sehingga detail punya waktu untuk menjadi usang.
Mengapa 3? Siapa yang melamar?
Nama praktik tidak membatasi kita pada tiga konteks, tetapi hanya menciptakan kerangka kerja minimal. Untuk memastikan bahwa dalam pengembangan persyaratan semua nuansa teknis, kasus eksplisit dan implisit diperhitungkan, bahwa spesifikasi mencerminkan kebutuhan aktual klien - 3 pemikiran / konteks yang berbeda diperlukan: bisnis, pengembang, tester. Apalagi pertemuan itu tidak terbatas hanya untuk orang-orang ini saja. Ini melibatkan semua orang yang terlibat dalam implementasi persyaratan. Misalnya, jika tugas Anda tidak hanya memiliki web, tetapi juga seluler, maka Anda memerlukan konteks tambahan. Artinya, orang yang akan melakukan implementasi dalam aplikasi mobile. Dalam tim kami, paling sering 4 pengembang (1 ios, 1 android, 1 belakang, 1 depan), seorang penguji dan seorang analis bisnis berpartisipasi dalam pertemuan tersebut.
Analis Bisnis atau PO
Perwakilan bisnis tahu (hampir selalu) apa yang ingin ia dapatkan pada akhirnya dan nilai apa yang akan diterima klien dan bisnis dari hal ini. Penting untuk membicarakan tim ini.
Berpartisipasi dalam pertemuan Amigo 3, analis bisnis berbagi informasi dengan para peserta sehingga setiap orang dalam tim memiliki pemahaman dan harapan yang sama dari kisah pengguna. Juga, hanya dia yang dapat membatasi ruang lingkup kriteria penerimaan dimana penerimaan akan terjadi.
Pengembang
Pengembang tahu bagaimana menerapkan persyaratan dari bisnis, apa peluang untuk ini. Sebagai aturan, dia berpikir tentang perincian yang perlu dia ketahui untuk memulai implementasi. Dengan mengajukan pertanyaan berdasarkan pengalaman dan pengetahuannya tentang sistem, pengembang membantu untuk mengungkapkan berbagai nuansa bahkan pada tahap diskusi tentang persyaratan.
Penguji
Penguji, seperti anggota tim lainnya, membantu memperkaya persyaratan dengan berbagai kasus uji. Berdasarkan pengalamannya, ia semakin sering meragukan pernyataan yang dibuat oleh tim. Oleh karena itu, lebih baik untuk menemukan kasus ekstrim, skenario implisit, bertanya-tanya apa yang salah, apa yang harus diwaspadai.
Kapan praktik diterapkan?
Saya jarang melihat proses pengembangan di mana persyaratan disajikan secara eksplisit. Dalam kebanyakan kasus, persyaratan mulai dipelajari pada tahap pengembangan atau pengujian, dan baru kemudian beberapa ketidakkonsistenan terungkap.
Spesifikasi yang tidak diuji kemungkinan memiliki persyaratan yang ambigu, kontradiktif, tidak lengkap, digandakan, dan kadang-kadang bahkan ketinggalan jaman, karena semua orang memahami apa yang telah mereka baca dan dengar dengan cara mereka sendiri. Oleh karena itu, perbedaan interpretasi muncul.
Dan jika dokumentasinya besar dan terperinci, maka membacanya mungkin membutuhkan waktu lebih lama daripada proses pengujian atau pengembangan itu sendiri.
Dalam lini bisnis kami, kami memutuskan untuk menerapkan praktik ini ketika tugas mulai berlama-lama dalam pengujian. Kami mengidentifikasi 3 masalah utama:
- Pada tahap pengujian, banyak pengembalian terjadi karena klarifikasi persyaratan. Ini adalah jeda nyata dalam pengujian dan pengembangan, ketika seorang analis bisnis menentukan bagaimana itu seharusnya bekerja.
- Pengujian tugas tertunda karena spesifikasi yang terlalu rinci. Kasus sering terjadi, ketika tester dapat menghabiskan 3-6 jam hanya mempelajari persyaratan dan mengembangkan kasus uji, dan pengujian itu sendiri memakan waktu sekitar 30 menit Dan yang paling mengerikan adalah kasus ketika pengujian dimulai setelah 2 minggu mempelajari spesifikasi, itu sangat rumit dan terperinci.
- Nah, masalah yang paling umum adalah bahwa selama pengujian penerimaan ada banyak bug. Bug-bug itu bisa dihindari jika dipikirkan sebelum pengembangan.
Jadi ternyata meskipun pengembangan tangkas, masih ada tahap kerja dengan spesifikasi teknis. Dan jika Anda tidak mempertimbangkan beberapa kasus, karena pelanggan tidak mengatakan tentang mereka, atau Anda tidak melakukan apa yang sebenarnya ia maksudkan, setelah pergi ke prod, sekelompok tugas untuk revisi atau bahkan perubahan masuk ke dalam simpanan.
Dan akhirnya, ada baiknya menyuarakan masalah dengan penilaian.
Sulit untuk mengevaluasi tugas ketika Anda benar-benar tidak memahami seluruh jumlah pekerjaan yang masih harus dilakukan di sana. Berapa banyak tes untuk menulis, berapa banyak pengembalian akan disebabkan oleh bug atau perubahan karena ketidakakuratan dalam spesifikasi? Bahkan jika pengembang memberikan penilaian yang akurat tentang waktu pengembangan itu sendiri, Anda hampir tidak akan pernah menebak berapa banyak waktu yang dibutuhkan untuk tahap pengujian yang tidak terduga.
Langkah-langkah untuk berlatih AC
1. Kami merumuskan persyaratan sebagai Kisah Pengguna
Saya merekomendasikan melamar untuk mengembangkan persyaratan berdasarkan cerita pengguna. Dan sebagai dasar untuk mengambil satu cerita dan pada pertemuan 3 amigo untuk mempelajarinya saja.
Di sini, poin yang sangat penting adalah bahwa persyaratan dari bisnis benar-benar dirumuskan sebagai kisah pengguna. Artinya, itu terkandung dalam dirinya sendiri 3 bagian, yaitu:
Saya sebagai <role>, saya ingin <action>, sehingga <motivasi>
Ini sebenarnya templat penceritaan khusus paling populer yang disebut Connextra. Ada juga template lain, tapi saya sarankan menggunakan yang ini. Dan mengapa, sekarang saya akan jelaskan.
Secara tradisional, ada 2 masalah saat membentuk cerita pengguna:
- Saat merekam, jangan menunjukkan peran, meninggalkan aksi dan motivasi
- Atau mereka menunjukkan peran dan tindakan, dan mereka membuang motivasi.
Ini sebenarnya menyebabkan masalah, dan saya akan mencoba menjelaskan contoh mana dengan contoh sederhana.
- Mengetahui "peran", Anda, sebagai anggota tim, akan lebih memahami batas-batas kriteria penerimaan yang perlu Anda rumuskan. Jika Anda tidak sepenuhnya menyadari orang yang terlibat dalam cerita pengguna ini, Anda dapat melakukannya melebihi apa yang Anda butuhkan, atau sebaliknya, melakukan beberapa fungsi.
- Contoh : tim kurang memahami peran dalam cerita pengguna, dan ketika mengerjakan tugas, diputuskan bahwa ia akan melakukan 3 metode untuk api: menambah, mengedit, dan menghapus. Dan di bagian depan, mereka akan menambahkan tombol yang akan memanggil metode ini. Ketika mereka mempresentasikan keputusan mereka kepada bisnis, mereka menerima umpan balik bahwa klien mereka sebenarnya adalah analis bisnis tertentu yang membutuhkan metode penambahan. Dan dia tidak akan menghapus dan mengedit. Ya, dan dia bisa memanggil metode ini melalui tukang pos.
- Tim tidak memahami motivasi dari "peran" untuk siapa mereka membuat cerita pengguna. Karena kesalahpahaman, batas-batas kisah pengguna itu sendiri diuraikan dengan buruk. Dan di samping itu, kriteria penerimaan pada akhirnya mungkin tidak menyelesaikan masalah klien akhir, meskipun mereka akan sesuai dengan tindakan yang disuarakan dalam kisah pengguna.
- Contoh : tim menyewa cerita pengguna di mana analis bisnis tidak dapat dengan jelas mengartikulasikan motivasi. Di satu sisi, dia harus meninggalkan klien setia dan membuat perbaikan untuknya. Di sisi lain, pengurangan biaya untuk bank. Dalam hal ini, metode implementasi dan kriteria penerimaan berbeda secara radikal. Karena dalam kasus pertama, tim fokus pada kriteria penerimaan pengguna. Yang kedua - tim memperhatikan bagaimana membuat implementasi yang paling sederhana dan paling cepat menjadi mungkin.
Tetapi formulasi dalam format di atas bukanlah prasyarat. Saya tahu tim yang mengadakan pertemuan dalam format Amigo 3 dan tanpa cerita pengguna. Dan sebagai dasar gunakan TK. Dalam hal ini, ada jebakan, tetapi itu adalah pilihan sadar tim.
Pertemuan 3 Amigo dimulai dengan persiapan. Dalam persiapan untuk itu, persyaratan dirumuskan sehingga mereka dapat dimengerti oleh seluruh tim. Persyaratan ini divalidasi untuk kesiapan untuk bekerja.
Validasi termasuk mengevaluasi sejarah terhadap kriteria INVEST. Serta kualitas kata-kata dari cerita itu sendiri. Di sini, ambiguitas, verbositas dikecualikan, dan ketika dinilai oleh INVEST, perhatian khusus diberikan pada ukuran cerita. Jika tim memahami bahwa persyaratannya epik, maka dekomposisi terjadi.
Setelah persyaratan telah melewati tahap transformasi menjadi cerita pengguna dan validasi oleh tim (3 amigo), kita dapat melanjutkan dengan elaborasi kriteria penerimaan.
2. Kami melengkapi kriteria penerimaan untuk Kisah Pengguna pada pertemuan 3 Amigo
Pertama, Anda perlu memutuskan apa kriteria penerimaan semua sama.
Jadi, kriteria penerimaan adalah persyaratan dari pelanggan; spesifikasi dimana sistem cerita pengguna dapat diperiksa.
Mereka memiliki nama alternatif, kondisi kepuasan - kondisi untuk kepuasan harapan (penulis Mike Cohn).
Pada pertemuan 3 tim Amigo sudah siap. Mereka sudah memiliki kisah pengguna yang divalidasi, yang mungkin sudah memiliki beberapa kriteria penerimaan yang dirumuskan oleh perwakilan bisnis secara independen.
Selama pertemuan, tugas peserta adalah untuk menambah / memperkaya sejarah dengan sejumlah kriteria penerimaan untuk implementasi selanjutnya.
Kriteria penerimaan tidak boleh mencakup detail implementasi. Faktanya, kriteria penerimaan adalah aturan bisnis yang mengatur kisah pengguna yang sedang dikembangkan. Detail implementasi dicatat dalam tes penerimaan, tetapi setelah semua kriteria penerimaan telah dirumuskan.
Tidak ada gunanya membingungkan detail implementasi dengan kriteria penerimaan, jika hanya karena dengan batas waktu yang terbatas, Anda sebagai tim selalu dapat "membuang" beberapa ruang lingkup kriteria yang tidak begitu penting bagi bisnis dalam waktu dekat. Jika ada detail dengan implementasi teknis dalam kriteria, Anda berisiko kehilangan informasi penting dan waktu yang telah dihabiskan untuk membahas detail implementasi. Detail implementasi Anda secara langsung tergantung pada ruang lingkup kriteria yang perlu Anda lakukan.
Selain itu, hindari uraian skenario secara berurutan dengan serangkaian langkah (sistem manajemen kasus uji klasik). Setiap pernyataan Anda harus berupa atom. Lebih baik menggunakan gaya deskriptif dari perilaku yang diharapkan dari fungsi yang dibuat.
Sebagai contoh:
* , .*>
3. Kami menjaga waktu
AS yang terdekomposisi dengan baik biasanya tidak mengandung lebih dari 10 kriteria penerimaan. Jika dalam proses diskusi sejumlah besar kriteria penerimaan ditemukan dan semuanya tunduk pada implementasi, maka cerita ini harus diuraikan menjadi beberapa cerita dengan kumpulan kriteria penerimaan yang berbeda.
Jika ini tidak dilakukan, maka pertemuan 3 Amigo akan sangat tertunda.
Waktu optimal untuk mengadakan pertemuan 3 Amigo adalah dari 30 menit hingga 1 jam.
Peningkatan yang dapat diterima di awal jalan - ketika tim baru belajar berkomunikasi dan menerapkan praktik ini.
Jika sebuah tim mengambil cerita besar untuk bekerja, kecil kemungkinannya dalam satu sesi mereka akan dapat mengerjakan semua kriteria dan tes penerimaan. Karena fokus dan perhatian hilang. Dalam hal ini, Anda perlu membagi sesi menjadi beberapa pertemuan. Tetapi dalam kasus ini, ada risiko kehilangan konteks, dan perendaman tambahan mungkin diperlukan pada pertemuan kedua.
4. Untuk menyelesaikan studi kriteria, kami menggunakan heuristik USR
Ketika saya mengajarkan latihan ini kepada tim, saya sarankan menggunakan heuristik di awal jalan mereka untuk memuluskan kurangnya pengalaman. Dengan pengalaman, tim memiliki heuristik dan daftar periksa sendiri tentang apa yang harus dicari ketika mengembangkan kriteria.
Heuristik USR memungkinkan Anda untuk mempertimbangkan kriteria di semua tingkatan yang diperlukan untuk mendapatkan informasi paling banyak tentang apa yang diinginkan pelanggan.
Jadi
- PENGGUNA - Apa yang ingin dilakukan pengguna dengan sistem?
- SISTEM - Apa yang harus dilakukan sistem?
- RISIKO - Masalah apa yang mungkin timbul?
Penting untuk terlebih dahulu menyelesaikan semua kriteria grup USER, dan kemudian hanya beralih ke level sistem. Di sini, pengembang depan dan belakang disertakan, dan pada tingkat sistem mereka, mereka dapat merumuskan kriteria penerimaan untuk apa yang harus terjadi untuk menerapkan kriteria dari kelompok USER.
Dan akhirnya, band RISIKO. Paling sering, itu dilupakan tentang penjabaran persyaratan, meskipun tidak kalah penting. Ini mencakup berbagai kasus kompleks yang mungkin tidak dapat Anda implementasikan. Tetapi untuk berbicara dan menerima risiko sebagai suatu tim diperlukan.
Cara menerapkan praktik untuk mengembangkan kasus uji sebelum pengembangan
Cara yang disarankan untuk memformalkan persyaratan adalah kasus penggunaan, dalam IT Rusia kami menyebutnya kasus uji.
Ada alat yang mudah digunakan untuk mengerjakan kasus uji pada pertemuan 3 Amigo, yang disebut pemetaan contoh. Dalam artikel ini, saya menyentuhnya sebentar. Pada artikel selanjutnya, kami akan mempublikasikan informasi terperinci tentang alat ini dan bagaimana penggunaannya dalam kerangka pertemuan triad.
Kasus uji dapat diimplementasikan sebagai tes penerimaan otomatis untuk riwayat. Juga, saat Anda mengerjakan kasus uji, pastikan untuk mengelompokkannya. Membagi kasus uji menjadi kelompok adalah cara untuk membagi cerita menjadi beberapa yang lebih kecil.
Dalam kasus uji, dekomposisi aturan bisnis terjadi tepat pada tingkat sistem di mana mereka akan diimplementasikan, dan bukan oleh pengguna.
Semua detail implementasi harus dalam kasus pengujian Anda, sehingga mereka fokus pada pengembang dalam proses implementasi.
Bagaimana hal itu terlihat dalam proses umum (ketika Anda perlu mengadakan pertemuan ini)
Disarankan agar Anda mengerjakan persyaratan hanya untuk satu cerita pengguna dalam satu rapat. Lebih banyak yang diizinkan, asalkan cerita ini sangat kecil atau saling terkait artinya.
Karena dalam sprint Anda mengambil cerita siap-untuk-bekerja, maka pertemuan 3 cerita Amigo harus diadakan sebelum perencanaan. Jika tidak, Anda berisiko melakukan kesalahan besar dengan perkiraan awal. Dalam praktiknya, penilaian cerita setelah pertemuan 3 Amigo sangat berbeda dari aslinya.
Juga, masuk akal untuk menambahkan item baru ke DOD sebagai indikator kesiapan, bahwa cerita siap untuk mengerjakannya dalam sprint.
Misalnya, kami memiliki beberapa tim yang sudah mulai menerapkan praktik ini, sepakat bahwa mereka tidak akan mengambil sprint selama perencanaan jika tidak ada kriteria penerimaan dan tes penerimaan untuk tugas tersebut.
Dan dalam sprint review, penerimaan cerita disajikan sesuai dengan kriteria penerimaan.
Tetapi pada saat yang sama, pertemuan 3 Amigo juga cocok dengan proses, jika tim bekerja dan tidak scrum, tetapi misalnya menggunakan kanban. Dalam hal ini, tugas masuk ke pengembangan hanya setelah melewati pertemuan 3 Amigo.
Apa hasil pertemuan 3 Amigo?
- skrip / contoh (jawaban yang jelas)
- aturan / kriteria penerimaan yang ditentukan
- cerita baru / terurai
- pemahaman umum tentang area masalah
- empati (empati, partisipasi)
Hasil utama dari ketiga amigo adalah tes penerimaan yang ditulis dalam format " Given / When / Then" . Bahkan, menulisnya mungkin lebih lama dari yang kita inginkan, jadi memformalkan semua persyaratan pada rapat ketika semua orang bersama-sama tidak direkomendasikan. Biasanya, pengembang atau penguji akan mengerjakan ini di luar kotak. Dan segera setelah mereka mencatat semua kriteria dan kasus uji, 3 Amigos secara singkat melihat apa yang terjadi untuk memastikan bahwa semua orang setuju dengan apa yang dicatat.
Keuntungan menggunakan latihan 3 Amigo
Strategi Amigos 3 dapat memiliki dampak besar pada efektivitas seluruh tim, serta pada kualitas dan keberlanjutan proyek Anda, meningkatkan kemampuan manuver dan fleksibilitas untuk berubah.
Berikut adalah beberapa bonus lainnya:
- Saat merencanakan, kita tidak menghabiskan banyak waktu membenamkan diri dalam makna sejarah.
- Mendeteksi kebingungan dan kesalahpahaman pada tahap awal, yang memungkinkan pengiriman lebih cepat
- Pastikan bahwa tim akan membahas jumlah pekerjaan yang diperlukan
- Membantu menemukan semua kriteria penerimaan dan atribut kualitas lainnya.
- Pengembangan test case jauh lebih mudah.
- Kami memprovokasi pengembang untuk menutup kode dengan tes
- Kami dengan cepat sampai pada kesimpulan bahwa fitur ini tidak diperlukan
Tim kami, menggunakan latihan, mampu mengurangi pengembalian tugas karena spesifikasi yang tidak akurat. Tugas backend yang mereka pelajari untuk mengembangkan "pertama kali." Artinya, tanpa bug dan langsung di prod.
Perangkap
- Jangan membatasi diri hanya untuk tiga orang. Jika Anda membutuhkan lebih banyak - panggilan.
- Jangan memenuhi seluruh tim. Dalam pertemuan ini, harus ada jumlah minimum orang untuk mengimplementasikan fitur.
- Jangan menganggapnya sebagai pertemuan rutin - ritual. Jika tidak, tim akan mendapat hal negatif dari peningkatan jumlah pertemuan.
Kelas master di konferensi QualityConf
Pada tanggal 27-28 Mei, sebagai bagian dari festival RIT ++, pada konferensi QualityConf, saya akan mengadakan kelas master tentang pengembangan persyaratan menggunakan praktik 3 Amigo.
Jika Anda tertarik pada pendekatan dan Anda memiliki pertanyaan, Anda juga dapat menghubungi saya di telegram @Travieso_nastya.
Mendekati sejarah
Penulis pendekatan: George Dinwiddy, 2009.
Dia menggambarkan pendekatan ini dalam wawancaranya dan menyebutkan dalam sejumlah artikel, tautan yang saya lampirkan. Juga, sebagai bahan tambahan, saya melampirkan semua referensi ke sumber daya berbahasa Inggris, yang menurutnya saya pelajari dan pelajari untuk menerapkan praktik ini.
https://www.agilealliance.org/glossary/three-amigos/
https://www.infoq.com/interviews/george-dinwiddie-three-amigos
https://www.agileconnection.com/article/three-amigos-strategy-developing-user-stories
https://www.stickyminds.com/better-software-magazine/three-amigos