Tim scrum kami terdiri dari peran scrum yang biasa. Kami tidak memiliki perancang UI / UX dan pengembang bekerja UI / UX dengan pemilik produk. Di sinilah letak masalahnya. Setiap kali kita akan membuat backlog dan kita tidak mendefinisikan desain UI / UX yang tepat sebelum awal sprint, kita menghabiskan terlalu banyak waktu selama sprint mencoba menyelesaikan desain UI / UX.

Ini persis benar untuk analisis dan arsitektur fitur. Apakah Anda berpikir bahwa setiap detail yang mungkin tentang fitur harus diberikan kepada pengembang sebelum dimulainya sprint atau haruskah itu menjadi tugas dalam fitur? Kami telah mengalami hal ini dan menghasilkan beberapa fitur yang tidak ditentukan yang tidak memiliki kriteria apa pun.

Pertama: lihatlah pembicaraan yang bagus ini , Florian Haas memberi di FROSCON (GER). Ini tentang ketidakmungkinan praktis melakukan scrum sama sekali.

The kabar baik : Sejak scrum adalah mustahil untuk menerapkan, Anda bebas untuk melakukan apapun yang Anda inginkan.

The kabar buruk : Jangan panggil scrum itu.

Itu membebaskan Anda dari pertanyaan: »Apakah saya melakukan scrum dengan benar?« (Jawab: Tidak, Anda tidak ) dan Anda dapat melanjutkan ke pertanyaan praktis kehidupan, hal itu.

Kami tidak memiliki perancang UI / UX dan pengembang bekerja UI / UX dengan pemilik produk

Ini bukan situasi yang tidak biasa. Tetapi scrum AFAIR menentang spesialisasi: setiap orang harus memiliki keahlian yang sama dan dapat bekerja secara bergantian.

Setiap kali kita akan membuat backlog dan kita tidak mendefinisikan desain UI / UX yang tepat sebelum awal musim semi kita akhirnya menghabiskan terlalu banyak waktu selama sprint mencoba untuk menyelesaikan desain UI / UX.

Ya, saya sekarang situasinya terlalu bagus. Saya bekerja di sebuah tim, di mana kami harus berurusan dengan backlogitem yang sangat luas seperti »Sebagai pengguna, saya ingin melihat informasi x « dan hanya itu. Kemudian barang itu mendarat di sprint board. Satu dev mengambilnya. Selesaikan itu. Setelah menerapkannya, peer review pertama terjadi, di mana diskusi dimulai tentang bagaimana seharusnya UI.

Kemudian QA-Phase datang dan diskusi dimulai lagi.

Setelah sprint, kami melakukan scrum yang menuntut peninjauan di mana desain robek oleh PO . Sayangnya, pelanggan kami tidak melihat ulasan, jadi dia tidak melihat perangkat lunak pada saat itu.

Tapi kemudian siklus itu dimulai lagi sampai PO puas.

Dan kemudian datang pelanggan ...

Dari kisah perang ini Anda lihat, bahwa proses (khusus) ini sangat tidak efektif.

Apa yang berhasil bagi kami pada akhirnya adalah melemparkan scrum ke papan tulis.

Tapi itu bukan solusi untuk pertanyaan Anda;)

Apakah Anda berpikir bahwa setiap detail yang mungkin tentang fitur harus diberikan kepada pengembang sebelum dimulainya sprint atau haruskah itu menjadi tugas dalam fitur?

Solusi untuk dilema ini akan melibatkan umpan balik yang ketat antara a) pelanggan itu sendiri dan PO , sehingga kriteria yang dirumuskan relatif ketat. b) Umpan balik yang ketat antara tim scrum dan PO untuk meminimalkan peluang untuk berkendara.

Saya akan melanggar beberapa (lebih) aturan scrum untuk mendefinisikan satu backlogitem: a »dummy kerja«. Yang dapat ditinjau dengan cepat oleh PO dan pelanggan untuk meminimalkan waktu pengembangan yang dihabiskan untuk item sederhana.

tl; dr

Apa yang harus menjadi masukan dari tim scrum?

Informasi yang cukup untuk memenuhi spesifikasi sesedikit mungkin.

Menyimpang dari topik:

Kami tidak melakukan scrum lagi. Kami tidak melakukan estimasi. Kami menyimpan papan sprint. Kami tidak melakukan sprint. Kami mengembangkan fitur / memperbaiki bug dan merilis ASAP. Ketika fitur baru diimplementasikan, mereka pergi ASAP ke server publik di mana kita bisa mendiskusikan desain lebih lanjut dengan pelanggan sekencang mungkin.

Jawaban kanonik adalah "lakukan apa yang berhasil untuk Anda."

Scrum adalah salah satu metodologi tangkas. Ini secara eksplisit dirancang untuk mengubah dan beradaptasi dengan tim Anda dan proyek Anda. Fokus Anda harus:

Individu dan interaksi atas proses dan alat
Perangkat lunak yang
bekerja dengan dokumentasi yang komprehensif Kolaborasi pelanggan atas negosiasi kontrak
Menanggapi perubahan setelah mengikuti rencana ( Agile manifesto )

Ini bukan pertanyaan tentang apa yang harus dimiliki tim Anda untuk memulai sebuah cerita, Ini pertanyaan tentang input apa yang memungkinkan tim khusus Anda untuk menyelesaikan kebutuhan bisnis tertentu.

Dalam pengalaman pribadi saya, itu tergantung pada tujuan bisnis. Beberapa cerita sudah dilengkapi dengan riset UI / UX dan desain penuh, dan itu tidak masalah. Beberapa cerita datang dengan persyaratan yang tidak jelas, karena bisnis hanya perlu menyelesaikan masalah. Itu juga oke.

Ada faktor-faktor lain juga, tentu saja. Seperti apakah perancang Anda adalah bagian dari tim pengembang, atau pemasaran, atau pengembangan produk, dll. Banyak faktor. Lakukan saja apa yang diperlukan untuk memuaskan bisnis, fleksibel, dan pastikan Anda membahas hal-hal ini selama retrospektif Anda, sesuaikan proses seperlunya.

Saya mendapat dorongan serupa dari pengembang. Masalah dari sudut pandang mereka adalah bahwa mereka waspada terhadap berapa lama bagian UX mungkin perlu diimplementasikan. Jika mereka setuju untuk mencoba dan menyampaikan cerita N dalam sprint tetapi beberapa cerita memakan waktu lebih lama dari yang diharapkan karena bolak-balik di UX maka mereka merasa itu tercermin buruk pada mereka.

Apa yang berhasil bagi kami adalah:

1. Seseorang bekerja dengan pemilik produk untuk membuat tiruan layar untuk dikembangkan. Ini ditinjau selama proses penyempurnaan cerita biasa sebelum cerita ditarik ke dalam sprint yang memberikan semua orang kesempatan untuk berdiskusi dengan jujur.
2. Jangan mencoba dan menyelesaikan desain sebelum pengkodean, cukup keluarkan di sana lalu bicarakan apa yang perlu diubah. Biaya untuk melakukan perubahan lebih jelas yang membantu pemilik produk / pelanggan memutuskan apakah itu layak sementara.
3. Kepercayaan antara pemilik produk / pelanggan dan pengembang. Pada akhirnya semua orang berusaha mengirimkan barang ke pelanggan. PO tidak diperbolehkan mengeluh tentang tim yang tidak mengirimkan semuanya dari sprint. Para devs tidak dapat dengan sengaja menghalangi karena mereka khawatir tidak akan melahirkan.
4. Praktek. Kami baru saja mendapatkan ukuran cerita perkiraan yang lebih baik dan mampu menemukan kemungkinan masalah.

Tl; DR: Jangan sepenuhnya mendefinisikan UX sebelum pengkodean. Tunggu sampai pengguna melihatnya dan bermain dengannya.

Apakah Anda berpikir bahwa setiap detail yang mungkin tentang fitur harus diberikan kepada pengembang sebelum dimulainya sprint atau haruskah itu menjadi tugas dalam fitur?

Sederhananya, jika pemilik produk tidak dapat memberikan desain ui / ux sebelum sprint, pengembangan ui / ux harus menjadi cerita , bukan tugas.

Hasil kiriman sprint Anda tidak harus selalu berupa kode kerja, dan tim itu sendiri dapat menjadi "siapa" dalam cerita. Anda dapat memiliki kisah seperti "Sebagai anggota tim pengembangan, kami memerlukan maket UI untuk dapat mengimplementasikan UI". Anda kemudian memperkirakan berapa lama waktu yang dibutuhkan tim Anda untuk mengirimkan maket, dan itu menjadi salah satu cerita pertama yang Anda kerjakan.

Anda tidak perlu mengeja UI, cukup terima permintaan fungsional (cerita) dan nilai itu mengetahui Anda harus memikirkan UI. Setelah klien menentukan UI meminta masalah.

Sekarang Anda tahu UI akan dikenakan biaya beberapa waktu Anda harus dapat merencanakan lebih baik, Lain kali Anda mengambil tugas yang termasuk pekerjaan UI Anda akan menetapkan beberapa poin cerita tambahan untuk itu.

Jika Anda scrum, siapa pun bisa menjadi desainer UI / UX.

UI / UX seharusnya tidak menjadi renungan. Itu harus disampaikan. Itu harus disetujui oleh pemilik produk Anda. Itu harus muncul, bahkan jika hanya sebagai gif, saat menyampaikan.

Itu tidak berarti itu tidak bisa berubah. Itu adalah sesuatu yang akan sering berubah. Ini juga sesuatu yang Anda ingin umpan balik lebih awal. Jangan biarkan kode mendorong desain UI. Biarkan pelanggan yang mengendarainya. Dorong kembali hanya ketika pelanggan meminta sihir. Kalau tidak, buat mereka sadar akan jumlah pekerjaan yang mereka minta dan berapa biayanya.

Satu-satunya UI / UX yang diselesaikan adalah perangkat lunak mati.

Dari komentar Anda:

"Itu harus disetujui oleh pemilik produk Anda." Di sinilah masalah muncul. Ada sejumlah besar waktu yang dihabiskan untuk proses persetujuan ini dan kami akhirnya menghabiskan berhari-hari alih-alih beberapa jam yang awalnya diperkirakan. - Rashid

Hilangkan semua yang tidak perlu memperlambat Anda.

Anda punya ide. Beri tahu pemilik produk. Mereka seharusnya duduk di sebelah Anda.

Mereka membencinya? Berpindah. Suka? Lakukan. Tidak mengerti itu Tunjukkan pada mereka.

Rapat singkat yang sering tidak terjadwal. Berbicara. Gambarlah di papan tulis atau kertas. Diejek dalam program cat menggunakan tangkapan layar. Komunikasikan, setujui, laksanakan, dan ulas ide dengan cepat.

Jika pemilik produk tidak ada, ambil manusia yang nyaman dan tanyakan pada mereka. Apa pun untuk memulai iterasi. Ulangi pemilik produk segera setelah Anda bisa.

Jangan habiskan satu detik untuk membuatnya cantik. Langsung saja ke intinya. Pertahankan ide-ide Anda kecil dan tambahan dan Anda dapat dilakukan sebelum ada orang yang bahkan meminta perkiraan.

Dalam pengalaman saya:

• Analisis awal yang terlalu sedikit menyebabkan pengembangan berhenti-mulai yang tidak efisien
• Terlalu banyak analisis di muka menyebabkan kelumpuhan analisis (Sprint tidak pernah memulai)

Apa yang kita lakukan:

• Tentukan beberapa kriteria " Siap untuk Pengembangan "
• Untuk cerita UX, ini mungkin "kami memiliki bingkai gambar yang dipahami dengan baik oleh tim"

Selama perencanaan Sprint:

• Cerita apa pun yang tidak siap untuk pengembangan dibuang (mereka akan terlalu mengganggu tim dan kembali untuk analisis lebih lanjut)
• Setiap Cerita batas dinyatakan "Berisiko Tinggi" dan dilakukan tepat di awal Sprint
• Cerita yang dipahami dengan baik diperkirakan dan diizinkan ke dalam Sprint

Sistem ini memungkinkan kami untuk mendedikasikan sebagian besar setiap Sprint untuk dieksekusi yaitu kami bekerja jauh lebih efisien.

Setiap tugas dalam scrum Anda harus memiliki perkiraan untuk total pekerjaan yang terlibat, dan hasil yang dapat diverifikasi.

Jika saya memasukkan tugas ke dalam scrum Anda "mengimplementasikan fitur X dengan antarmuka pengguna yang senang dengan manajer produk", yang memiliki hasil yang dapat diverifikasi, tetapi jelas tidak mungkin untuk memperkirakan jumlah pekerjaan yang terlibat. Jadi tugas ini tidak bisa dimasukkan ke dalam scrum.

Sekarang saya memasukkan tugas ke dalam scrum Anda "mendesain antarmuka pengguna untuk fitur X". Itu dapat diperkirakan, dan hasilnya dapat diverifikasi. Itu tugas Ok dalam scrum. Ketika tugas selesai, Anda sudah melakukannya.

Sekarang setelah tugas selesai, manajer produk Anda dapat mengatakan bahwa dia tidak menyukai hasilnya. Tidak apa-apa. Ada tugas dalam scrum, Anda telah melakukannya, dan itulah tugas Anda. Dia bisa memasukkan tugas lain ke dalam scrum berikutnya. Mungkin dengan sedikit lebih banyak arah seperti apa antarmuka pengguna yang sebenarnya dia sukai. Itu pekerjaannya. Menyetel tugas yang memberikan hasil yang bermanfaat . Kadang sulit, dan pekerjaan dilakukan yang ternyata tidak berguna. Itu sebabnya mereka menyebutnya "gesit"; tugas yang dilakukan ternyata menjadi sia-sia, dan kemudian Anda berubah ke arah yang lebih baik.

Selain itu, desain UX, terutama desain UX yang baik, adalah pekerjaan penuh waktu bagi seseorang yang telah mempraktikkan desain UX. Banyak pengembang perangkat lunak yang baik dapat melakukan pekerjaan yang lumayan menciptakan UX, tetapi mereka tidak akan melakukannya sebaik dan seefektif desainer UX yang baik (jika mereka bisa, maka mereka akan membuat desain UX dan tidak mengembangkan perangkat lunak). Jadi tidak memiliki desainer UX tidak efektif - lagi-lagi masalah bagi pemilik produk.

Saya tidak yakin Anda mengikuti prinsip gesit, tetapi di sini adalah bagaimana ini harus ditangani.

kami tidak mendefinisikan desain UI / UX yang tepat sebelum awal sprint

Tujuannya bukanlah menjadi sempurna pada saat ini. Dapatkan sebanyak mungkin input untuk persyaratan sehingga pengembang dapat membangun sesuatu yang cocok dengan apa yang diminta sedekat mungkin. Jangan membuat banyak perubahan atau mencoba mendesain hal-hal yang belum diminta. Anda akan membuang-buang waktu.

kami akhirnya menghabiskan terlalu banyak waktu selama sprint mencoba untuk menyelesaikan desain UI / UX.

Bekerja pada cara untuk menentukan kapan sesuatu dilakukan. Saya punya perasaan, seseorang terus melakukan banyak evaluasi bolak-balik dari UI / UX. Terlalu banyak orang memiliki pendapat tentang UX / UI dengan tidak ada dari klien untuk mendukung asumsi mereka.

Manager: "I think this should be bold."
Programmer: "The client didn't ask for this"
Manager: "But I think they'll like it."

Hal semacam ini bisa berlangsung selamanya. Ini bukan cacat Scrum. Seseorang ikut campur dengan persyaratan selama sprint. Kembalilah ke memutuskan apa yang diinginkan klien, tentukan berapa lama dan bekerjalah dengan mereka untuk memprioritaskan. Jika mereka pikir itu akan terlalu lama, tanyakan kepada mereka apa yang harus disingkirkan.

Ada perusahaan yang mendesain logo dengan biaya tetap. Mereka membatasi jumlah permintaan perubahan karena mereka tahu beberapa klien akan membunuh mereka dengan kematian dari seribu luka dengan semua perubahan mereka. Menghentikannya atau menagih lebih banyak. Ini disebut bisnis.