Desainer UX bekerja satu Sprint di depan

13

Desainer UX kami biasanya memiliki cerita di Sprint X yang akan diimplementasikan oleh pengembang di Sprint X + 1 (Desainer UX dan pengembang / penguji berada dalam satu tim). Saya pikir ini masuk akal karena jika Anda tidak memiliki layar mockup dan spesifikasi yang jelas, Anda tidak dapat benar-benar memperkirakan pekerjaan selama Perencanaan Sprint.

Namun di Scrum Anda hanya seharusnya memiliki cerita pengguna yang memberikan nilai kepada pengguna. Dalam kasus kami, cerita desain UX tidak memberikan nilai seperti itu (mereka lebih seperti kegiatan perawatan backlog). Juga biasanya pelatih Scrum tidak merekomendasikan memiliki spesifikasi lengkap sebelum dimulainya Sprint, sebuah rekomendasi yang menurut saya sulit untuk dipahami.

Jadi, apakah Anda melihat kelemahan dalam pendekatan kami? Tampaknya bekerja untuk kita, tetapi itu agak bertentangan dengan prinsip-prinsip Scrum.

scrum user-experience Eugene
sumber
3
Mengapa desain UX tidak memberikan nilai kepada pengguna? Dengan asumsi Anda terus scrum dan terus menggunakan desainer UX, saya tidak bisa melihat bahwa ada alternatif, dan jika Anda tidak memiliki alternatif, bagaimana mungkin ada kerugian?
Michael Shaw
Karena mockup layar dan daftar persyaratan UI tidak memberikan nilai langsung kepada pengguna. Ini memberikan nilai hanya setelah diimplementasikan dalam kisah Sprint berikutnya.
Eugene
Masalah Anda mungkin karena Anda tidak memiliki desainer atau idealnya insinyur UX, Anda memiliki seniman grafis. Mereka hanya menggunakan photoshop, bukan? Tidak ada CSS JS atau XAML atau Interface Builder atau potongan teknis front-end? Jadi kamu tidak punya desainer. Anda membutuhkan desainer asli. Maka Anda tidak akan memiliki kebingungan ini.
RibaldEddie
Tidak. Kami memiliki desainer interaksi pengguna dan desainer grafis. Keduanya bekerja satu langkah di depan pembangunan
Eugene
10
Bagaimana berinteraksi dengan basis klien Anda menggunakan maket dan prototipe tidak membawa nilai bagi pengguna? Nilai tidak didefinisikan sebagai kode pengiriman. Tangibilitas sangat baik untuk dimiliki tetapi tidak penting untuk nilai.
BobDalgleish

Jawaban:

15

Namun di Scrum Anda hanya seharusnya memiliki cerita pengguna yang memberikan nilai kepada pengguna.

Nilai tidak diukur hanya dalam baris kode yang dapat dikirim.

Anda tampaknya menyiratkan bahwa memiliki UI yang dirancang dengan baik tidak memberikan nilai apa pun. Tentu saja. Jelas ada nilai bagi pengguna akhir, tetapi ada juga nilai bagi tim pengembangan Anda, yang merupakan pemangku kepentingan yang benar-benar valid. Jika Anda tidak memiliki alat dan bahan untuk melakukan pekerjaan Anda, Anda tidak dapat memberikan nilai kepada pengguna akhir.

Jangan terpaku pada dogma scrum. Scrum ada untuk membuat Anda lebih efisien. Jika melakukan UX story one sprint sebelum Anda menerapkan UI membantu Anda memberikan perangkat lunak yang lebih baik, lakukanlah.

Bryan Oakley
sumber
2
"Perangkat lunak yang berfungsi adalah ukuran utama dari kemajuan.", Bukan UX. UX tidak bernilai apa-apa jika tidak berfungsi perangkat lunak. Anda akan ada benarnya jika Anda menganjurkan memiliki UX pada saat yang sama atau lambat dengan fitur yang sebenarnya, tetapi Anda tidak melakukannya, jadi jawaban ini benar-benar salah.
Sklivvz
3
@ Klivvz: Saya kira kita harus setuju untuk tidak setuju. Memang benar bahwa perangkat lunak yang berfungsi adalah ukuran utama kemajuan, itu bukan satu - satunya ukuran. Sejumlah desain harus dilakukan di depan sebelum tim dapat memulai pengkodean. UX bukanlah sesuatu yang bisa Anda tempel pada akhirnya.
Bryan Oakley
4
@BryanOakley Saya setuju bahwa beberapa pemikiran perlu diberikan untuk semua pekerjaan di muka, bukan hanya ux. Namun, nilai pekerjaan itu ditentukan oleh para pemangku kepentingan. Jika pekerjaan ux dilakukan satu sprint di depan, loop umpan balik baru saja diperpanjang oleh setidaknya satu sprint. Saya akan menyarankan bahwa ini adalah risiko yang tidak perlu. UX tidak berbeda dengan desain, atau arsitektur, atau desain basis data, atau format laporan. Semuanya DAPAT dilakukan dalam satu sprint, dengan item jaminan simpanan produk yang dibuat sebagai irisan fungsionalitas vertikal.
Derek Davidson PST CST
Ini dapat dilakukan dalam satu Sprint, tetapi tanpa mengetahui apa yang akan terjadi pada pengguna, bagaimana Anda dapat merencanakan sisa pekerjaan? Jika Anda tidak tahu desain perangkat lunak terperinci Anda masih dapat merencanakan pekerjaan. Tetapi jika Anda bahkan tidak tahu seperti apa layar dan fungsionalitasnya, bagaimana Anda bisa merencanakan sesuatu?
Eugene
1
Dengan bekerja secara bertahap, seperti cara gesit yang biasa. Pengembang menghasilkan prototipe baik dalam kolaborasi waktu nyata dengan desainer ux atau berdasarkan ide mereka sendiri tentang ux; begitu prototipe berfungsi, desainer akan memeriksanya dan memberikan daftar perubahan. Sebuah cerita tidak perlu perencanaan terperinci; yang dibutuhkan hanyalah perkiraan ukuran (dan beberapa bahkan menyengketakannya).
Jules
13

Kerugian utama adalah ini:

  1. Anda suka pipa: jika desainer Anda terlambat, pengembang Anda dibiarkan tanpa pekerjaan; jika pengembang Anda terlambat, desainer Anda pada akhirnya akan bekerja lebih dari satu iterasi di muka. Ini bukan situasi yang stabil - ini tidak berkelanjutan .

  2. Desainer Anda bekerja di muka, Anda membayar biaya untuk cerita yang mungkin atau mungkin tidak dikembangkan. Bahkan jika itu jarang terjadi, Anda masih membuang uang.

  3. Desainer UX Anda membuat keputusan sebelumnya tanpa melibatkan pengembang. Anda kehilangan wawasan yang bermanfaat dan meningkatkan risiko bahwa desain tersebut keliru atau tidak realistis. Ini cukup umum karena desain UX bukan latihan "abstrak" - itu harus dibuat dari karakteristik aplikasi (termasuk apa yang layak / disarankan untuk dilakukan atau tidak secara teknis)

  4. Mengecualikan atau melemahkan pengembang Anda bukanlah cara yang berkelanjutan untuk menjalankan proyek.

  5. Desainer tidak memberikan nilai: ini berarti sulit, jika bukan tidak mungkin, memprioritaskan pekerjaan mereka dengan benar. Biasanya, pekerjaan pengembang diprioritaskan menggunakan berbagai keprihatinan, nilai, kelayakan dalam sprint berikutnya, jumlah usaha. Banyak cerita waktu dinegosiasikan dan diubah untuk menjadikannya "cocok" atau karena diskusi yang bermanfaat: jika ada yang mengubah UI (dan Anda dapat menganggap itu terjadi jika itu bukan detail implementasi belaka), apa yang Anda lakukan dengan ceritanya? Anda tidak bisa memainkannya lagi.

  6. Anda berasumsi bahwa sebuah cerita yang dapat dimasukkan ke dalam satu iterasi untuk para desainer cocok dalam satu iterasi untuk para pengembang: bagaimana Anda bisa membagi cerita sehingga asumsi ini benar?

Sklivvz
sumber
Komentar sebagian besar di luar topik sehingga telah dihapus.
ChrisF
1
Anda mengatakan "Desainer UX Anda membuat keputusan ... tanpa melibatkan pengembang". Bagaimana Anda tahu? Hanya karena mereka bekerja satu langkah di depan tidak berarti mereka tidak bekerja dengan pengembang. Mungkin para pengembang adalah pemangku kepentingan mereka. Ini juga masuk ke poin 4 - Anda mengasumsikan bahwa pengembang dikecualikan tetapi itu belum tentu demikian. Adapun "Desainer tidak memberikan nilai", saya tidak bisa tidak setuju lagi. Anda tidak melihat nilai dalam UX yang dirancang dengan benar? Meskipun saya pikir Anda mengajukan beberapa poin yang layak untuk dibahas, Anda membuat banyak asumsi yang mungkin tidak benar.
Bryan Oakley
@Bry baik mereka bekerja pada ux atau mereka tidak. Tentunya terlibat dalam proses ux memenuhi syarat sebagai "mengerjakan" sebuah cerita. Mengenai penilaian nilai Anda ... Mereka tidak menambah nilai jika mereka bekerja sebelumnya karena mereka tidak menghasilkan apa pun yang dapat digunakan. Jika sesuatu tidak pernah mencapai pelanggan, itu tidak ada nilainya bagi mereka.
Sklivvz
re: "terlibat dalam proses ux memenuhi syarat sebagai" mengerjakan "sebuah cerita." Belum tentu. Orang-orang datang dan bertanya kepada saya sepanjang waktu, itu tidak berarti saya sedang mengerjakan cerita mereka.
Bryan Oakley
2
@BryanOakley tentu saja, tetapi masalah masih berlaku: bandingkan "mengirim kembali" desain karena itu tidak realistis untuk dilaksanakan vs melakukannya dengan benar pertama kali karena dilakukan saat pengembang sedang mengerjakannya. Selain itu, ada masalah yang hanya ditemukan selama implementasi, dan pada tahap itu perancang melakukan cerita berikutnya ...
Sklivvz
6

Saya menyukainya, karena dua alasan:

  1. tampaknya bekerja untuk Anda; sulit untuk berdebat dengan kesuksesan!
  2. tim UX mengambil cerita dan memulai percakapan lebih awal - dan percakapan adalah inti cerita
Steven A. Lowe
sumber
4

Persyaratan dasar Scrum adalah bahwa tim scrum memiliki semua keterampilan yang diperlukan untuk membuat produk yang berpotensi untuk dirilis. Dalam situasi yang Anda gambarkan, ini tidak terjadi.

Tim UX tidak memproduksi produk yang berpotensi untuk dirilis dan tim scrum tidak mampu menghasilkan irisan fungsionalitas vertikal karena mereka tidak memiliki semua keterampilan yang diperlukan. Ini adalah disfungsi.

Sklivvz telah menulis posting yang sangat baik tentang masalah yang dapat menyebabkan disfungsi di atas. Singkatnya, saya tidak berpikir Anda sedang berlatih Scrum.

Tapi sama sekali tidak ada yang salah dengan itu. Jika Anda telah menemukan cara kerja yang memberikan nilai bagi Anda semua, dan Anda semua senang dengan itu, terus lakukan itu. Satu-satunya saran saya adalah memeriksa dan beradaptasi sesering mungkin.

Namun, perlu diketahui bahwa jika tujuan Anda adalah memberikan perangkat lunak menggunakan Scrum, Anda harus mengatasi disfungsi yang diidentifikasi.

Derek Davidson PST CST
sumber
Seperti yang saya katakan di posting asli saya: "Desainer UX dan devs / penguji berada di satu tim"
Eugene
2
@Eugene Dalam arti apa mereka berada di tim yang sama? Saya akan mengatakan bahwa jika mereka bekerja satu langkah di depan, mereka tidak berada di tim yang sama. Kebetulan, Scrum juga jelas bahwa itu tidak mengenali "sub-tim" jadi sekali lagi, saya akan mengatakan bahwa situasi Anda tidak terdengar seperti Scrum. Tentu tidak seperti yang saya tahu.
Derek Davidson PST CST
Mereka bekerja satu sprint di depan dengan sisa waktu. Anggota tim lainnya biasanya setidaknya meninjau pekerjaan mereka dan kadang-kadang membantu dengan desain itu sendiri.
Eugene
4

Ada dua masalah di sini, satu tentang desain yang berpusat pada pengguna dan yang lainnya tentang penyelarasan sprint.

Pertama : Cerita pengguna harus diselaraskan dengan kebutuhan pengguna, bukan hanya jaminan simpanan. Cerita UX harus memiliki nilai yang jelas bagi pengguna. Ini tidak memerlukan spesifikasi lengkap, dan pernyataan singkat seperti,

"Pengguna akan memiliki akses yang lebih mudah ke aktivitas akun pada satu halaman daripada dibagi antara beberapa halaman"

dapat menerima dan beradaptasi dengan berbagai implementasi namun masih jelas tentang nilai bagi pengguna (akses yang lebih mudah ke aktivitas akun).

Kedua : Penyelarasan sprint. UX mendesain fitur dalam sprint X yang diterapkan pengembang di musim semi X + 1. Dalam praktiknya, ini terjadi di banyak toko dan kadang-kadang mungkin lebih seperti implementasi dalam sprint X + 2 atau X + 3. Dengan tim yang kuat dan berpengalaman, pengaturan ini dapat bekerja. Menjadi menantang jika Anda memiliki tim baru atau anggota baru yang tidak terbiasa dengan keahlian, preferensi, kebiasaan, gaya kerja, dan kecenderungan anggota tim lainnya. Jika Anda telah bekerja bersama selama kurang dari 6 bulan ini kemungkinan akan menjadi masalah.

Ambil langkah mundur, dan kaji kembali. Sisi positifnya Anda memiliki desainer dan pengembang UX yang bekerja berdampingan, yang merupakan anugerah. Mulailah dengan memastikan bahwa cerita Anda memiliki nilai yang jelas bagi pengguna.

atimba
sumber
2

Salah satu masalah yang mungkin saya lihat adalah bahwa dalam Scrum lingkup untuk sprint N +1 biasanya ditentukan tepat sebelum dimulai. Jadi bagaimana Anda bisa melakukan UX untuk sprint N +1 cerita di sprint N sebelum Anda tahu cerita mana yang akan berada dalam ruang lingkup. Jika Anda memutuskan untuk memperbaiki ruang lingkup untuk sprint N +1 pada awal sprint N Anda kehilangan fleksibilitas.

Frank Bakker
sumber
1

Namun di Scrum Anda hanya seharusnya memiliki cerita pengguna yang memberikan nilai kepada pengguna. Dalam kasus kami, cerita desain UX tidak memberikan nilai seperti itu (mereka lebih seperti kegiatan perawatan backlog).

Cara saya melihatnya, mereka memberikan banyak nilai kepada pengguna mereka. Masalahnya adalah: pengguna mereka bukan pengguna akhir perusahaan, pengguna mereka adalah tim pengembangan yang akan mengimplementasikan fitur di sprint X + 1.

mverardo
sumber
1

Anda terjebak dalam agama proses dan sepanjang jalan saya melihat scrum / gesit disalahgunakan dan pengguna diberi label yang salah. Scrum bukan alat universal, ini adalah sarana untuk mencapai tujuan.

Saya pikir grup Anda telah salah memberi label siapa pengguna Anda dan berencana untuk audiens yang salah.

Grup UX menggunakan scrum dengan cara klasik, nilai pengguna, dan adaptasi gesit terhadap input dari beberapa pengguna akhir yang ajaib. Mereka adalah satu dengan pengguna. Grup Anda menyalahgunakan scrum karena Anda hanya mengisi mekanik untuk membuat desain yang ada berfungsi, tidak ada yang dibutuhkan gesit dan scrum mengisi peran pelacakan manajemen.

Itulah mengapa ini terasa salah bagi Anda, Anda sebenarnya tidak perlu atau mendapat manfaat dari scrum dengan cara apa pun karena Anda berada dalam grup layanan dan pekerjaan Anda mengalir maju dari orang-orang UX yang telah melakukan bagian agile / scrum.

Tidak ada yang benar-benar buruk di sana, hanya ada proses yang berbeda dari yang Anda diberitahu.

Patrick Hughes
sumber