Unlimited Wordpress themes, plugins, graphics & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Web Design
  2. Documentation
Webdesign

Cara Menghasilkan Reka Bentuk Anda Menggunakan Kisah Pengguna Didorong Kelakuan

by
Length:LongLanguages:

Malay (Melayu) translation by Ike purnaniwati (you can also view the original English article)

Isu umum ketika mendokumentasikan keperluan menonjol dari perspektif sistem untuk menerangkan apa yang diperlukan, melupakan bahawa ia adalah pengguna yang akan menjadi pusat interaksi. Cerita pengguna, yang diperkenalkan oleh Agile, menangani masalah ini dengan menjadikan pengguna sebagai pusat keperluan, dan Behavior Driven Development (BDD) mengambil langkah yang lebih jauh menyediakan rangka kerja di mana tingkah laku pengguna adalah yang mendorong pembangunan.

Menggunakan teknik BDD untuk mencipta cerita pengguna membuat keperluan mendokumentasikan lebih mudah untuk ditulis dan dibaca. Selain itu, ia menyediakan alat tambahan untuk menyampaikan pengalaman pengguna yang dimaksudkan mengenai reka bentuk, yang pereka, pemaju, dan jurutera QA boleh digunakan untuk pantas dan bahkan mengautomasikan sebahagian daripada kerja mereka. Dalam artikel ini saya akan meneroka pendekatan ini dan menunjukkan bagaimana anda boleh menggunakannya untuk mendokumentasikan reka bentuk anda sendiri, bermula dari cerita-cerita kecil untuk menganjurkan cerita-cerita untuk menyampaikan ciri-ciri berfungsi sepenuhnya.

Keperluan UI vs Syarat UX

Terdapat perbezaan penting untuk membuat antara keperluan UI (juga dikenali sebagai spesifikasi) dan keperluan UX. Di satu pihak, keperluan UI adalah dokumen teknikal yang menyenaraikan spesifik mengenai antara muka pengguna, termasuk jenis font, warna, dimensi dan susun atur elemen. Satu contoh yang baik mengenai dokumentasi jenis ini ialah Panduan Gaya Hidup.

Keperluan UX, sebaliknya, menggambarkan pengalaman yang seharusnya untuk pengguna tertentu, memandangkan pengguna ini berada dalam senario tertentu melakukan tindakan tertentu. Kisah pengguna boleh menangkap keperluan UX dengan cara yang sangat ringkas. Sebagai contoh:

  • Sebagai pengguna .. penerbit,
  • Saya mahu .. dapat meninjau artikel sebelum diterbitkan,
  • Jadi .. Saya boleh memberikan maklum balas dan memastikan kualiti tepat pada masanya.

Kisah ini menunjukkan peranan pengguna terlebih dahulu, apa yang pengguna ingin capai, dan kemudian menerangkan alasan di sebaliknya. Ini hebat kerana ia memberikan pemahaman kepada pemaju dan penguji mengenai matlamat utama adalah: untuk mencukupi keperluan pengguna. Perhatikan bahawa perkataan yang berani ialah templat yang digunakan untuk menulis cerita. Selalu ada pengguna, yang ingin melakukan sesuatu, supaya mereka dapat mencapai matlamat tertentu. Anda boleh mengikuti petua ini untuk menulis cerita pengguna yang baik.

Dengan kisah ini dalam fikiran, pasukan reka bentuk boleh memutuskan bahawa tindakan 'persetujuan' diperlukan untuk mencapai matlamat pengguna. Kemudian untuk memberikan spesifik tentang bagaimana ini sebenarnya akan berfungsi, anda boleh menggunakan sintaks Gherkin, yang merupakan alat BBD untuk menulis keperluan perniagaan yang boleh dibaca. Sintaks Gherkin adalah serupa dengan cerita pengguna yang tangkas kerana ia menyediakan cara menulis keperluan yang juga boleh digunakan sebagai templat. Kelebihannya ialah anda boleh mendapatkan lebih banyak spesifik, menyediakan senario dan tindakan yang akan diambil oleh pengguna tanpa mengambil kira pelaksanaannya. Mari kita lihat secara dekat.

Menulis Cerita Pengguna Menggunakan Syntax Gherkin

Asas-asalan cerita yang menggunakan Gherkin Syntax dapat diringkaskan di bahagian-bahagian ini:

  • Ciri-ciri
  • Satu senario
  • Sebuah prasyarat
  • Tindakan
  • Hasilnya

Ciri ini merupakan tempat untuk menggambarkan nilai perniagaan keseluruhan pelaksanaannya. Ia juga boleh digunakan untuk memberikan maklumat tambahan, seperti peraturan perniagaan, atau apa-apa yang menjadikan ciri mudah difahami (seperti pautan ke prototaip atau keperluan UI).

Sen ario menggambarkan keadaan tertentu di mana pengguna berada. Dari perspektif reka bentuk pengguna, senario membolehkan berkomunikasi pelbagai pembolehubah reka bentuk, dan bagaimana UI harus mengendalikan mereka, menurut pengguna.

Prasyarat membantu membina senario dan membuang sebarang kekaburan. Sebagai contoh, dalam senario yang menggambarkan pengguna kali pertama mengakses skrin tertentu, prasyarat dapat menjelaskan bahawa pengguna telah log masuk.

Tindakan menunjukkan persis apa yang pengguna lakukan dalam antara muka, dan biasanya 'mencetuskan', seperti mengklik pada butang, menghantar borang, atau menavigasi ke tempat lain.

Hasilnya adalah akibat dari tindakan itu, dan harus selalu menjadi sesuatu yang dapat diuji.

Dengan bahagian ini dalam minda, mari kita tulis cerita pengguna untuk ciri yang kami nyatakan sebelum ini:

  • Sebagai pengguna .. penerbit,
  • Saya mahu .. dapat meninjau artikel sebelum diterbitkan,
  • Jadi .. Saya boleh memberikan maklum balas dan memastikan kualiti tepat pada masanya.

Menggunakan Gherkin Syntax cerita ini akan kelihatan seperti ini:

Feature
Benarkan penerbit untuk meninjau artikel sebelum penerbitan akhir dan menghalang kelulusan mereka.
Senario
Meluluskan artikel yang sedia untuk diterbitkan.
Precondition
  • Memandangkan penulis telah mengemukakan satu artikel untuk penerbitan.
  • dan penerbit telah mengakses paparan edit artikel
Tindakan
  • apabila penerbit memilih 'meluluskan'
Outcome
  • maka artikel itu diterbitkan menurut tanggal yang telah ditetapkan
  • dan penerbit melihat amaran kejayaan yang menunjukkan artikel itu berjaya diterbitkan
  • dan artikel itu ditandakan sebagai 'diluluskan'
  • dan pemberitahuan dihantar kepada penulis yang menunjukkan artikel mereka telah diluluskan.

Anda dapat melihat bagaimana kisah awal berubah menjadi aliran yang lebih terperinci yang pengguna boleh mengikuti dan oleh itu dapat diuji. Juga, perhatikan bahawa kata-kata yang berani ialah kata kunci yang digunakan perisian seperti timun untuk mengautomasikan pelaksanaan ujian. Saya akan menerangkan lebih lanjut tentang hal ini kemudian, tetapi untuk sekarang, saya ingin menunjukkan bahawa kata kunci ini sangat membantu dan juga untuk menulis cerita kerana mereka membantu membezakan bahagian-bahagian cerita yang berlainan.

Sesuatu yang lain menunjukkan bahawa walaupun cerita memberikan lebih banyak maklumat mengenai aliran pengguna, antara muka tidak diterangkan. Alasannya ialah menerangkan UI dengan cepat boleh mengubah cerita menjadi keperluan UI, yang memberikan masalah besar kerana mereka boleh menjadi ketinggalan zaman dengan cepat. Contohnya, jika kisah ini menerangkan bagaimana amaran kejayaan itu kelihatan dan apa yang harus dituturkan oleh mesej tertentu, maka cerita itu boleh keluar dari segerak jika mana-mana perubahan ini, mewujudkan potensi ujian yang gagal.

Oleh itu, silap mata adalah untuk memberikan maklumat yang cukup, tanpa melakukan kerja alat yang lebih mencukupi, seperti rancangan mockup, prototaip, dan panduan gaya. Dalam hal ini, anda akan melihat bahawa tindakan itu menunjukkan 'memilih meluluskan' berbanding hanya menggunakan 'meluluskan'. 'Memilih meluluskan' tidak khusus tentang apa yang kelihatan seperti kawalan ini (ia boleh menjadi butang, butang yang kelihatan seperti pautan, atau kotak yang boleh diklik), tetapi ia menyiratkan bahawa elemen dalam UI dicetuskan. Ia juga menunjukkan bahawa elemen ini telah menulis di dalamnya 'meluluskan'. Ini adalah kawasan kelabu di mana anda perlu menggunakan akal fikiran, seperti dalam beberapa kes anda akan mahu menjadi spesifik ini supaya tindakan dapat dibezakan dari orang lain. Sebagai contoh, jika ada cara lain untuk meluluskan artikel pada halaman yang sama, menunjukkan bahawa dalam senario ini pengguna harus 'memilih', membenarkan membuat pembezaan.

Kepentingan Skenario

Selain daripada sintaks yang bijak yang diberikan oleh Gherkin, salah satu perkara yang saya dapati paling berguna adalah menggunakan bahagian 'senario'. Senario adalah kuat kerana ia boleh digunakan untuk menguji reka bentuk dan memastikan semua asas dilindungi.

Biasanya, reka bentuk apa-apa jenis bermula dengan 'jalan bahagia', yang bermaksud apa yang berlaku apabila semuanya berjalan lancar di antara muka, dan bagaimana ia digunakan untuk majoriti pengguna. Dalam contoh terdahulu kami, kami mempunyai:

Senario
Meluluskan artikel yang sedia untuk diterbitkan.

Juga, kerana kita tahu bahawa artikel mempunyai tarikh penerbitan, kita juga boleh menyatakan: Ini adalah senario pertama kita kerana dalam kebanyakan kes artikel yang perlu diluluskan harus siap untuk penerbitan. Tetapi ini membawa soalan: apa yang berlaku apabila artikel tidak siap untuk penerbitan dan penerbit mengaksesnya? Sekiranya mereka dapat mengakses artikel tersebut?

  • Apa yang akan berlaku jika artikel yang diluluskan mempunyai tarikh penerbitan pada masa lalu? Sekiranya artikel diterbitkan dengan serta-merta, atau adakah mereka akan beratur?
  • Dan langkah seterusnya, bagaimana jika penerbit meluluskan sesuatu artikel secara tidak sengaja? Apakah prosedur untuk membatalkan tindakan ini? Siapa yang patut diberitahu?

Semua soalan ini adalah sebahagian daripada proses reka bentuk dan kemungkinan besar apabila anda melompat ke keperluan dokumentasi, anda akan tahu jawapannya. Berita baiknya ialah menggunakan senario dalam dokumentasi cerita anda akan membantu anda menyusunnya dan dalam banyak kes akan membantu anda membuat reka bentuk anda sendiri, memastikan terdapat reka bentuk dan aliran yang ditujukan untuk setiap mereka.

Mari kita lihat bagaimana kisah kita akan terbentuk dengan senario tambahan:

Feature Benarkan penerbit untuk meninjau artikel sebelum penerbitan akhir dan menghalang kelulusan mereka.
Scenario 1 Meluluskan artikel yang sedia untuk diterbitkan.
  • Memandangkan penulis telah mengemukakan satu artikel untuk penerbitan
  • dan penerbit telah mengakses paparan artikel edit
  • apabila penerbit mengklik 'meluluskan'
  • maka artikel itu diterbitkan menurut tanggal yang telah ditetapkan
  • dan penerbit melihat amaran kejayaan yang menunjukkan artikel itu berjaya diterbitkan
  • dan artikel itu ditandakan sebagai 'diluluskan'
  • dan pemberitahuan dihantar kepada penulis yang menyatakan bahawa mereka telah diluluskan telah diluluskan.
Scenario 2

Mengakses artikel yang belum siap untuk diterbitkan.

  • Bila ...
Scenario 3

Meluluskan artikel yang mempunyai tarikh akhir yang telah ditetapkan

  • Bila ...
Scenario 4

Tidak bersetuju dengan artikel yang mempunyai tarikh penerbitan di masa depan

  • Bila ...
Scenario 5

Tidak bersetuju dengan artikel yang telah diterbitkan

  • Bila ...

Bergantung pada ciri ini, terdapat banyak senario yang perlu dipertimbangkan. Kunci mereka adalah untuk menjadikannya pendek, supaya anda dapat menerangkan dan menguji mereka dengan mudah. Anda juga boleh cuba mengelompokkannya, menggunakan penyebut biasa. Contohnya, jika beberapa senario berkongsi prasyarat yang sama, anda boleh mengemas ini ke dalam 'Latar Belakang' yang boleh digunakan oleh berbilang senario. Sebagai contoh:

Background
Penulis telah menyerahkan artikel untuk penerbitan dan penerbit telah mengakses paparan artikel edit.
Scenario 1
Meluluskan artikel yang sedia untuk diterbitkan.
  • Memandangkan latar belakang dipenuhi
  • bila ...
Scenario 2
Meluluskan artikel yang mempunyai tarikh akhir yang telah ditetapkan.
  • Memandangkan latar belakang dipenuhi
  • bila ...
Scenario 3
Tidak bersetuju dengan artikel yang mempunyai tarikh penerbitan di masa depan.
  • Memandangkan latar belakang dipenuhi
  • bila...

Menyusun Cerita untuk Menyampaikan Ciri

Cabaran umum yang timbul ketika mendokumentasikan keperluan adalah menentukan cara untuk melakukannya. Alasannya adalah bahawa dalam kebanyakan kes segala sesuatu sedang dalam pembinaan, yang membuat sukar untuk menguji interaksi apabila bahagian-bahagian interaksi itu belum dibina. Sebagai contoh, dalam interaksi sederhana 'meluluskan' artikel, banyak perkara yang perlu disediakan:

  1. UI mestilah dapat memulangkan mesej kejayaan jika kelulusan berjaya dan mesej kegagalan sekiranya terdapat masalah sistem.
  2. UI harus dapat 'menandai' artikel sebagai diluluskan.
  3. UI harus dapat memaparkan artikel mengikut logika perniagaan yang diterbitkan.
  4. Pemberitahuan sistem perlu diaktifkan, jadi penulis dapat dimaklumkan apabila kelulusan berlaku.

Pendekatan mendokumentasikan keperluan bagi setiap kebergantungan ini untuk merekodkannya sebagai ciri yang berbeza yang kemudiannya boleh diprioritaskan mengikut nilai perniagaan mereka.

Feature
Penghuraian
Keutamaan
Sistem Peringatan
UI harus dapat kembali mesej sukses, serta pesan gagal, jika ada masalah sistem
2
Sistem Penandaan
UI harus dapat 'menandai' artikel sebagai diluluskan
4
Sistem Penerbitan
UI harus dapat memaparkan artikel mengikut logika perniagaan yang diterbitkan
1
Sistem Pemberitahuan
Pemberitahuan sistem perlu diaktifkan, jadi penulis dapat dimaklumkan apabila kelulusan berlaku
3

Kemudian anda boleh membuat kisah 'integrasi' untuk membawanya bersama. Sebagai contoh, kisah pengguna untuk sistem penandaan ingin ini:

Feature
Benarkan pengguna dan sistem menanda artikel mengikut keadaan tertentu (tidak diterbitkan, diluluskan, diterbitkan, atau diarkibkan).
Scenario 1
Penandaan artikel yang tidak diterbitkan.
  • (butiran ...)
Scenario 2
Menandai artikel sebagai diluluskan.
  • (butiran ...)
Scenario 3
Penandaan artikel seperti yang diterbitkan.
  • (butiran ...)
Scenario 4
Penandaan artikel yang diarkibkan.
  • (butiran ...)

Dalam kisah integrasi, anda boleh merujuk cerita penandaan, dalam hal butiran untuk senario itu perlu disahkan semula atau jika anda hanya ingin tahu apakah kes-kes tersebut sudah diverifikasi.

Feature
Benarkan penerbit untuk mengkaji semula artikel sebelum penerbitan akhir dan capai kelulusan mereka.
Scenario 1
Meluluskan artikel yang sedia untuk diterbitkan.
  • Memandangkan penulis telah mengemukakan satu artikel untuk penerbitan
  • dan penerbit telah mengakses paparan artikel edit
  • apabila penerbit mengklik 'meluluskan'
  • maka artikel itu diterbitkan menurut tanggal yang telah ditetapkan
  • dan penerbit melihat amaran kejayaan yang menunjukkan artikel itu berjaya diterbitkan
  • dan artikel itu ditandakan sebagai 'diluluskan' (senario rujukan 2 dari cerita penandaan)
  • dan pemberitahuan dihantar kepada penulis yang menunjukkan artikel mereka telah diluluskan.

Maksudnya adalah untuk mengelakkan mengulang dokumentasi yang bukan sahaja menggunakan masa yang tidak perlu, tetapi juga yang tidak dapat disegerakkan.

Mengubah Cerita Pengguna Ke Kes Ujian

Kami telah melihat betapa bergunanya Cerita Pengguna Teropong yang berguna untuk keperluan penulisan yang terfokus, ringkas, tetapi juga teliti dan deskriptif. Bermula dari fasa reka bentuk, alat ini boleh meminjamkan buku asas yang baik untuk jurutera QA untuk menulis kes ujian sebenar.

Di samping kelebihan yang hebat ini, Kisah Pengguna Didorong Kelakuan sebenarnya boleh diubah menjadi ujian berfungsi dengan bantuan perisian, seperti Timun atau Lettuce. Idea asas ialah apabila cerita ditulis dengan menggunakan sintaks Gherkin, anda boleh meletakkannya dalam fail .feature di dalam apl anda, dan kemudian menjalankannya sebagai ujian untuk menunjukkan sama ada ia berjaya atau tidak. Untuk tutorial mendalam tentang cara menggunakan Lettuce untuk pelaksanaan Python semak tutorial David Sale:

Kesimpulan

Menulis cerita pengguna dengan menggunakan prinsip BDD boleh berkomunikasi dengan mendalam secara terperinci keperluan perniagaan dan reka bentuk, dengan pendekatan yang berpusatkan pengguna, sambil menggunakan bahasa yang boleh dibaca manusia tetapi boleh dipanjangkan untuk tafsiran perisian. Selain itu ia boleh digunakan untuk menguji:

  • reka bentuk anda sendiri semasa anda membuat dokumen keperluan
  • aplikasi sebenar secara manual, sekali berubah menjadi kes ujian oleh jurutera QA
  • aplikasi sebenar secara automatik, apabila bertukar menjadi ujian berfungsi menggunakan perisian BDD.

Ini bermakna lebih banyak lapisan untuk bug yang dapat dilalui, menghalang jurang dalam reka bentuk dan pelepasan lanjut aplikasi anda dari kegagalan pepijat.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.