Get best of the week

5 aturan untuk mengintegrasikan UX dalam Agile dan Scrum

Terjemahan artikel disiapkan sebelum peluncuran Manajer Proyek Agile dalam kursus TI .



Ketika saya baru memulai karir saya, perangkat lunak datang dalam kotak. Jika ini kedengarannya aneh bagi Anda, ketahuilah bahwa ketika saya masih kecil, ayah saya membawa pulang kartu-kartu berlubang yang program-programnya direkam pada tahun 1970-an. Perangkat lunak semacam itu memiliki status akhir. Setelah 20 tahun sejak saat itu, rasanya sudah konyol. Hari ini kami menciptakan sistem yang dapat ditingkatkan tanpa henti. Ini menimbulkan pertanyaan: "Kapan pekerjaan berakhir?" - dan pertanyaan ini sulit dijawab. Kami mencari jawaban untuk pertanyaan ini, karena itu akan membantu kami menjawab pertanyaan lain yang bahkan lebih penting. Akankah tim mendapatkan hadiah mereka atau mereka akan melaporkannya? Apakah tim akan melakukan sesuatu yang baru? Apakah pemangku kepentingan akan mendapat manfaat?

Tim pengembang yang menggunakan Scrum (atau variasi metodologi Agile lainnya) memiliki gagasan yang jelas tentang kapan pengembangan berakhir. Seringkali ini berarti "seperangkat kriteria minimum yang harus dimiliki suatu produk / layanan untuk memenuhi kebutuhan bisnis." Akibatnya, ia turun ke daftar fungsi, yang disetujui oleh pemangku kepentingan (atau pemilik produk) dan pada saat penyelesaian proyek harus dilaksanakan sepenuhnya. Pengembang menyebutnya "berfungsi sebagaimana dimaksud."

Tetapi "bekerja sebagaimana dimaksud" hanya berarti bahwa perangkat lunak melakukan apa yang mereka inginkan darinya. Sayangnya, terkadang ini tidak cukup. Faktanya, ini hanyalah awal dari percakapan yang kami lakukan terus-menerus dengan pengguna dan pelanggan kami. Ini adalah peningkatan berkelanjutan dari sistem kami untuk memberikan pengalaman yang lebih baik yang memberi mereka nilai nyata.

Jadi, bagaimana kita bisa mendefinisikan "shutdown" untuk tim? Kapan tim memulai proyek baru? Kurangnya ROI adalah tempat yang baik untuk memulai, tetapi bagaimana kita tahu tidak ada pengembalian uang? Jawabannya akan diberikan kepada kami oleh pelanggan. Kami melihat perilaku mereka. Kami mendengarkan kebutuhan mereka, mengevaluasi apakah sistem kami memenuhi kebutuhan ini dan berpikir apa yang dapat kami lakukan untuk memenuhi kebutuhan yang selalu berubah ini. Kami menyebut metrik ini hasil.

Dan hasil ini tidak dapat diprediksi, sama seperti tidak mungkin untuk memprediksi perilaku manusia. Hasil yang baik mengharuskan anggota tim untuk secara aktif terlibat dengan pelanggan untuk menangkap perubahan dalam perilaku mereka, alasan terjadinya, dan peluang untuk memenuhi kebutuhan pelanggan dengan lebih baik di masa depan. Berita baiknya adalah bahwa perusahaan Anda kemungkinan besar sudah mempekerjakan orang-orang yang sangat pandai dalam aspek-aspek ini - desainer. Terlepas dari kenyataan bahwa desainer saat ini hadir di hampir setiap perusahaan, sebagian besar dari mereka tidak menempati posisi yang cukup tinggi untuk mempengaruhi adopsi keputusan besar. Faktanya, banyak dari mereka yang tidak diikutsertakan dalam proses pengembangan Agile, yang dirancang untuk programmer dan manajer Produk.

Integrasi desainer dalam proses pengembangan Agile adalah masalah konstan bagi banyak organisasi. Berkat hampir 20 tahun pengalaman dalam merancang, mengelola, dan berkonsultasi dengan tim produk, saya telah mengidentifikasi 5 aturan berikut yang harus diikuti oleh tim jika ingin memastikan bahwa pengalaman pengguna (UX) berhasil diintegrasikan ke dalam proses Agile mereka:

1. Desainer terpisah untuk masing-masing tim

Tidak ada kompromi. Tanpa desainer "sendiri" dalam tim Scrum, Anda hanya memiliki tim pengembangan, yang tanpa desainer tidak dapat memberikan tingkat kualitas pengalaman pengguna yang sesuai.

2. Jam kerja tim dengan klien

Aturan ini saya pelajari dari Jared Spoolyang melakukan penelitian yang membuktikan bahwa tim yang menghabiskan setidaknya 2 jam kerja setiap 6 minggu berkomunikasi dengan pelanggan (misalnya, menerima panggilan dukungan, berbicara dengan pengguna, mengawasi orang, dll.) berkembang lebih sukses produk.

3. Karya desainer adalah poin pertama dari

jaminan simpanan: Secara singkat: simpan jaminan simpanan tunggal. Pengembangan, kontrol kualitas, desain, pekerjaan penelitian - semua ini harus terletak di satu tumpukan, diprioritaskan oleh seluruh tim yang melakukan pekerjaan ini. Segera setelah pekerjaan dibagi menjadi dua tumpukan, tim akan memilih salah satu dari mereka dan memutuskan untuk memperlakukannya sebagai yang “utama”, dan yang kedua hanya akan meletakkannya di kotak belakang.

4. Hasil sebagai Filter Prioritas untuk Backlog

Saya banyak menulistentang hasilnya (dan Josh Seyden menulis seluruh buku tentang itu ), tetapi satu-satunya hal yang ingin saya catat dalam konteks topik hari ini adalah bahwa setiap item simpanan harus melalui filter tujuan akhir tim. Tanyakan kepada diri sendiri: "Apakah pekerjaan ini akan membantu mencapai tujuan?" Jika jawabannya tidak, maka jatuhkan item ini.

5. Pelatihan lintas fungsional

Pengalaman dan desain pengguna membawa banyak hal menarik yang layak dijelajahi. Acara semacam itu dapat dilakukan oleh desainer (atau analis), tetapi harus dipraktikkan dan dihadiri oleh seluruh tim. Semakin banyak tim dapat belajar bersama, semakin sedikit waktu yang dibutuhkan untuk berbagi pengetahuan yang diperoleh, dan lebih banyak untuk memutuskan di mana menerapkannya (yang merupakan subjek percakapan yang lebih produktif bagi tim).

Sifat retrospektif berulang Scrum sangat cocok untuk UX dan kegiatan desain. Integrasi wawasan pelanggan ke dalam proses kerja datang langsung dari Agile Manifesto (bekerja dengan klien, dll.). UX dan desain membawa kami lebih dekat ke tujuan Agile dari fokus pelanggan dan kepuasan pelanggan yang lebih baik. Ikuti 5 aturan ini untuk menggabungkan desain dan pengembangan tangkas.


.

More articles:


All Articles