Siapa yang melakukan UX pada proyek scrum?

BAIK. Katakanlah Anda sedang mengerjakan proyek scrum buku teks. Anda memiliki master scrum yang berkolaborasi dengan pemilik produk. Sprint berikutnya adalah UI-berat - pada saat coders Anda mulai membangun layar, Anda benar-benar ingin memiliki beberapa ide apa yang mereka akan terlihat seperti.

Siapa yang melakukan penyadapan, dan kapan? Pemilik produk? Seseorang mendukung pemilik produk? Master scrum? Jika Anda memiliki pakar UX, apakah mereka bekerja bersama coders setelah sprint dimulai, atau apakah mereka memasok gambar rangka & mock-up di muka yang duduk di samping kartu cerita Anda dan kendala untuk memandu dan memberi tahu pekerjaan yang sedang dilakukan pengembang?

Saya cukup yakin kami membutuhkan bantuan UX, Anda tahu, tapi saya benar-benar tidak yakin di mana harus menerapkannya ...

EDIT: Biarkan saya ulangi pertanyaannya.

Bagaimana Anda memberikan pengalaman pengguna yang konsisten dan berkualitas tinggi pada proyek gesit?

Perancang interaksi

UX! = UI Anda membutuhkan perancang interaksi yang berpengalaman untuk memberikan pengalaman pengguna yang baik, bertentangan dengan kepercayaan populer yang bukan seorang programmer. Untuk Anda semua programmer yang berpikir mereka bisa melakukan UX (itu termasuk saya) izinkan saya mengatakan ini. Menjadi ahli dalam desain interaksi setidaknya membutuhkan waktu sebanyak yang dibutuhkan dalam pemrograman. Berapa banyak waktu yang Anda habiskan untuk melakukan desain interaksi murni?

Pada tahap awal, tanggung jawab desainer interaksi untuk:

1. Mengekstrak tujuan sebenarnya dari solusi dari pemilik produk
2. Definisikan personas yang akan menggunakan solusi.
3. Tulis skenario yang merupakan cerita tentang bagaimana solusi akan digunakan.
4. Kompilasi dokumen desain yang menyisakan sedikit ruang untuk ambiguitas dari sudut pandang UX

Selama proyek itu adalah tugas desainer interaksi untuk memastikan bahwa pedoman tersebut diikuti dan mengatasi masalah tambahan yang akan muncul (dan mereka akan).

Banyak pemrogram akan menentang pendekatan ini, saya yakin karena semua orang merasa bahwa mereka adalah pengecualian yang dapat merancang antarmuka "luar biasa", Anda mungkin tidak. Di sisi lain perancang interaksi yang baik - hubungan programmer sering sangat baik untuk programmer dan mereka tidak harus berjuang melawan "spesifikasi bodoh". Sayangnya desainer interaksi yang baik sulit ditemukan dalam pengalaman saya tetapi mereka di luar sana.

Seperti biasa saya sangat merekomendasikan buku-buku Alan Coopers pada subjek ("Tentang Wajah" dan "Para Narapidana menjalankan suaka")

Saya sarankan untuk mengatur pekerjaan pria UX dengan cara yang sama seperti anggota tim lainnya. Dia harus dianggap sebagai anggota tim yang setara, berpartisipasi dalam standup, dan berkomunikasi secara dekat dengan programmer.

Idealnya, mock-up harus dilakukan setidaknya satu sprint sebelumnya, tetapi untuk fitur yang lebih kecil mungkin masuk akal untuk mempertimbangkan membuat mock-up sebagai subtugas dari sebuah cerita yang direncanakan untuk iterasi saat ini.

Seperti biasa dengan gesit, gunakan akal sehat, bereksperimen dengan pendekatan yang berbeda, dan berpegang teguh pada yang cocok untuk situasi khusus Anda.

Menurut saya ini adalah kasus khusus yang harus ditangani dengan cara khusus. Scrum master pasti tidak akan berpartisipasi dalam hal ini - ini bukan perannya sama sekali. Tim biasanya sekelompok pengembang dan sebagian besar dari mereka tidak memiliki pengalaman dengan UX dan akan membuang-buang waktu untuk memaksa mereka melakukan ini. Anda akan menyewa ahli UX dan ahli tidak akan menjadi bagian dari tim - tim harus lintas fungsional dan pakar UX mungkin tidak akan menjadi pengembang. Juga pakar UX tidak akan berada di proyek selama durasinya. Pakar UX akan bekerja dengan pemilik produk satu langkah di depan untuk menyiapkan mock-up dan gambar rangka untuk cerita pengguna yang lebih baru sehingga tim tahu apa yang harus dilakukan dalam sprint berikutnya - mock-up akan tersedia selama pertemuan perencanaan.

Edit:

Saya melakukan beberapa riset tambahan karena saya tahu saya membaca tentang ini di suatu tempat dan akhirnya saya menemukannya di Sukses dengan Agile: Pengembangan Perangkat Lunak Menggunakan Scrum oleh Mike Cohn . Mike membahas dengan tepat peran perancang UX dalam tim. Deskripsi awalnya mirip dengan tambang dan dia menganggapnya sebagai perubahan alami ketika perusahaan mengubah metode pengembangan dari air terjun ke Scrum tetapi kemudian dia menyimpulkan itu sebagai cara yang tidak direkomendasikan. Alasannya adalah bahwa jika desainer UX bukan bagian dari tim, mereka dapat menganggap diri mereka sebagai tim yang terpisah dan mereka tidak harus berbagi komitmen dari tim pengembangan.

Terlepas dari jawaban @Adam Byrtek ini sepertinya jawaban yang benar. Jadikan UX cowok sebagai bagian dari tim dan biarkan dia bekerja sama dengan pengembang tentang kisah pengguna yang saat ini diterapkan. Ini tidak akan memakan waktu sepanjang waktu orang UX sehingga ia juga akan bekerja sama dengan pemilik produk atau pelanggan untuk menyiapkan mock-up dan gambar rangka untuk memulai satu atau dua sprint.

Saya berlangganan kotak peringatan Jakob Nielsen (sebagian besar karena kritiknya pada praktik desain web yang mengganggu) dan saya ingat saya baru saja membaca beberapa artikel tentang topik (walaupun saya hampir tidak memiliki sedikit pemahaman tentang seluruh proses pengembangan tangkas), mungkin mereka akan ada gunanya bagi Anda:

• Proyek Pengalaman Pengguna Agile
• Proyek dan Kegunaan Pengembangan Agile

Untuk "Scrum buku teks":

Pertama, Scrum Masters tidak berkolaborasi dengan Pemilik Produk - tidak berarti selain itu seluruh tim, termasuk SM dan PO berkolaborasi untuk membangun sistem.

Kedua, tim Scrum seharusnya homogen dengan anggota tim lintas fungsi. Jadi Anda tidak akan memiliki "UX Guy".

Juga, Anda mungkin tidak akan membangun UX a Sprint di depan kode fungsional. Fitur disampaikan sepenuhnya dalam Sprint tunggal. Jika UX yang terkait dengan fitur terlalu rumit untuk dikirim bersamaan dengan kode fungsional dalam Sprint tunggal, maka Anda mengukir seluruh fitur hingga sesuatu yang dapat dilakukan, termasuk elemen UX, dalam Sprint tunggal.

Siapa yang mengerjakan UX pada proyek air terjun? Siapa yang melakukan pengembangan mainframe pada proyek XP?

Metodologi proyek tidak masalah. Setiap proyek teknologi membutuhkan peran khusus tertentu. Terkadang, sebuah proyek dapat pergi tanpa "perancang interaksi" yang berlisensi dan terikat (apa pun artinya). Terkadang Anda memang membutuhkan seseorang yang terspesialisasi. Tetapi hal yang sama dapat dikatakan untuk setiap peran lainnya.

Jadi pertanyaan kedua Anda tentang bagaimana Anda memberikan pengalaman pengguna yang berkualitas tinggi menggunakan gesit. Kami berhasil dalam proyek scrum terakhir saya terlibat dengan melibatkan analis bisnis dan pelanggan lebih awal dan sering. Selain itu, kami memiliki pengembang yang memiliki perhatian khusus terhadap UX. Dia cenderung melakukan sedikit perubahan pada UI yang sedang dikerjakan para devs setelah mereka melakukan komitmen.

Kami tidak menghasilkan UX yang sempurna di akhir setiap sprint. Demo umumnya memaparkan satu atau dua masalah dari perspektif UX. Tapi kami memperbaikinya untuk sprint berikutnya (jika mereka layak untuk pelanggan) dan pada saat kami merilis untuk produksi kami memiliki UX yang sangat solid.

Jika menurut UX, yang Anda maksud adalah perancang antarmuka pengguna, mereka hanyalah peran atau sumber daya lain untuk tim. Desain Antarmuka Pengguna, seperti desain apa pun, memotong suatu proyek. Ada sejumlah pekerjaan arsitektur / desain yang masuk akal yang harus dikerjakan di depan dan ada sejumlah yang bisa dilakukan saat Anda melanjutkan.

Perlu dicatat bahwa tugas-tugas desain UI sering tidak masuk dalam lingkup yang sama dengan sprint pengembangan. Dalam mendesain komponen UI, desain mungkin membutuhkan banyak sprint untuk diimplementasikan.

Dalam praktiknya, saya cenderung menemukan desainer UI / UX membutuhkan waktu yang wajar untuk menangani aspek-aspek yang harus konsisten di seluruh solusi. Saya suka menganggapnya sebagai arsitektur perangkat lunak. Desain komponen tertentu sering dapat dilakukan sprint sebelum implementasi, tetapi saya cenderung menemukan bahwa begitu desainer mulai berjalan, mereka dapat jauh melampaui kecepatan implementasi. Sprint kemudian cenderung menjadi tempat yang baik untuk mengimplementasikan / mengeksplorasi tampilan & nuansa serta mendapatkan umpan balik kegunaan saat solusinya mulai terbentuk. Hasil dari latihan-latihan selanjutnya dimasukkan kembali ke dalam perencanaan sprint berikutnya.