Beyond Sprint 0: Alternatif Untuk Mengintegrasikan Tim

Scrum adalah metodologi manajemen proyek paling populer di dunia dengan lebih dari 72% tim menggunakan Scrum atau scrum-hybrid. Kemungkinannya bagus bahwa jika Anda bekerja dalam pengembangan web, Anda menggunakan Scrum dalam beberapa bentuk.

Tren saat ini di Scrum adalah "Sprint 0" atau sepupunya yang lebih berseni "Design Sprint". Banyak yang telah ditulis tentang apakah ini benar sprint (bukan) tetapi sedikit yang telah dikatakan tentang mengapa mereka ada sejak awal, mengapa mereka begitu keras kepala bertahan, dan alternatif apa yang ada.

Saya pribadi menyukai Scrum dan saya selalu mencari cara untuk meningkatkan cara saya mengimplementasikannya secara bertahap. Dalam artikel ini, saya ingin membagikan metode yang telah saya masukkan ke dalam alur kerja saya dan yang menurut saya berguna saat menggabungkan UX/UI dan pengembangan, serta menciptakan visi proyek yang lebih kuat.

Beberapa definisi singkat sebelum kita mulai:

• lari cepat 0
  Upaya awal tim untuk membuat dokumen panduan yang diperlukan untuk proyek scrum: visi, jaminan simpanan produk, dan perkiraan rilis produk.
• Sprint Desain
  Upaya awal tim untuk membuat desain panduan untuk sisa rilis.
  

Mengapa Sprint 0 Dan Desain Sprint Ada

Semuanya baik dan bagus untuk mengatakan, “Sprint 0 bukanlah sprint yang sebenarnya, jangan lakukan itu.” Tapi adaptasi sprint-ish ini ada karena suatu alasan. Banyak tim mengadopsinya karena proyek mereka memiliki kebutuhan yang belum terpenuhi di luar lingkup langsung Scrum. Pengamatan saya adalah bahwa Sprint 0 dan sprint desain paling sering digunakan untuk mengatasi situasi berikut:

1. Kurangnya visi pemandu yang kuat;
2. Kurangnya integrasi desain ke dalam alur kerja pengembangan.

Proses Scrum mengasumsikan visi yang jelas telah dikembangkan dan dikomunikasikan oleh pemilik produk. Tetapi angkat tangan Anda jika Anda pernah mengerjakan proyek di mana visinya lemah, salah, atau tidak terlihat. Gerakan mengungkap kekerasan seksual demi menghapuskannya! Sprint 0 merupakan upaya tim pengembangan untuk mengisi kesenjangan visi. Ini bukan ide terburuk, jadi apa masalahnya? Dari perspektif tangkas, Sprint 0 tidak berulang, tidak memanfaatkan bakat seluruh tim, dan memberikan hasil yang samar-samar. Dan sebelum Anda menunjukkan, "Hei, masalah sebenarnya di sini adalah bahwa tim scrum tidak harus melakukan pekerjaan pemilik produk," Saya benar-benar percaya tim tangkas lintas disiplin adalah salah satu lingkungan terbaik untuk mengembangkan yang kuat, realistis visi dan tujuan.

Saya mengusulkan metode yang lebih gesit untuk membangun visi yang telah berhasil saya gunakan dalam proyek tanpa serah terima. Saya akan mengeksplorasi kedua situasi di mana adaptasi seperti sprint ini digunakan dan menjelaskan bagaimana sprint pertama alternatif ini mendukung alur kerja yang gesit dengan lebih baik.

Visi Dan Sprint Prototipe

Dalam situasi pertama, di mana ada kekurangan visi yang kuat, dokumentasi panduan atau ide terlalu lemah untuk benar-benar memulai proyek Scrum. Untuk proses apa pun (termasuk Scrum), Anda memerlukan arahan sebelum memulai perjalanan. Agile sangat bagus untuk mencari tahu cara terbaik untuk mencapai tujuan, tetapi menghasilkan visi awal tidak berada dalam cakupannya. Faktanya, yang hilang dari Scrum sama sekali adalah deskripsi dari visi yang diperlukan untuk memulai proses pengembangan. Apakah itu benar-benar Scrum atau tidak, Sprint 0 hanyalah tim web di garis depan, menggunakan alat yang mereka miliki, mencoba mencari tahu apa yang perlu mereka lakukan sebelum mereka mulai melakukannya.

Kelemahan nyata dari Sprint 0 adalah bahwa membangun dokumen panduan untuk proyek pada saat Anda memiliki informasi paling sedikit memberikan nilai rendah untuk proses pengembangan berikutnya.

Memandu visi proyek yang tidak selaras dengan realitas yang muncul berulang kali harus melalui proses mahal Sprint 0, atau lebih sering diabaikan begitu saja.

Alternatif yang lebih baik adalah sprint prototipe: sprint pertama yang melibatkan seluruh tim sambil benar-benar membangun prototipe awal itu sendiri.

Proses Visi Sprint Prototipe

Ide brainstorming diterjemahkan ke dalam kesetiaan visual yang rendah, prototipe bekerja secepat mungkin. Prototipe ditulis dalam kerangka kerja HTML dan CSS front-end fungsional, yaitu bahasa bersama tim. Tidak semua orang dapat memahami lembar spesifikasi atau pernyataan visi. Setiap orang dapat memahami situs web dan komunikasi menjadi lebih mudah dan menggabungkan berbagai disiplin ilmu.

Pada akhir sprint pertama, prototipe siap untuk pengujian awal di beberapa bidang termasuk kegunaan umum, aksesibilitas, dan daya tanggap seluler. Di tim saya, ini adalah peningkatan yang valid dan penting dilakukan. Sprint prototipe juga menghasilkan backlog produk awal. Saat item backlog diselesaikan di sprint mendatang, prototipe mendapatkan kesetiaan. Prototipe bukanlah kode sekali pakai — ini mendasar.

Dalam beberapa proyek, visi tertulis dihasilkan saat prototipe diproduksi. Tetapi dalam banyak proyek, prototipe adalah visi. Itu berbicara dalam bahasa bersama tim dan, tentu saja, tidak pernah keluar dari langkah dengan produk.

Contoh

Contoh di bawah ini adalah prototipe yang berfungsi untuk aplikasi e-niaga, yang diselesaikan dari garis besar kasar di RFP awal. Meskipun kasar, itu berperan penting dalam memfokuskan energi tim ke arah yang produktif, melompati banyak gangguan potensial dan perangkap untuk fokus pada kriteria fungsional.

Prototipe awal sering kali menghasilkan perubahan pada persyaratan, yang hanya merupakan tebakan terbaik sampai sesuai dengan pengalaman pengguna. Sebagai contoh, salah satu wawasan yang kami peroleh dari sprint prototipe yang ditunjukkan di atas adalah bahwa harga dan tombol 'beli' awalnya terlalu rendah di halaman. Permintaan awal adalah menempatkannya di bawah info produk dan di atas rekomendasi, tetapi prototipe fungsional dengan cepat menunjukkan bahwa hierarki tidak terlalu fungsional.

Fungsi lain yang terungkap adalah bahwa gambar galeri pada awalnya diminta untuk berukuran besar dan meregangkan lebar penuh halaman. Alih-alih memberikan alasan hipotetis kepada pemangku kepentingan mengapa itu tidak berhasil, prototipe mampu menunjukkan masalah dalam bahasa bersama yang dipahami seluruh tim. Dalam sesi kekuatan dengan pemangku kepentingan, kami dengan cepat mengatur ulang halaman ini menjadi hierarki yang disepakati secara universal.

Karena prototipe lahir dapat diakses dan responsif, kami dapat segera memulai pengujian pada beberapa perangkat dan teknologi. Meskipun desainnya (bahkan jika dapat disebut demikian pada tahap awal ini) sengaja dibuat dengan ketelitian rendah, segera terlihat bahwa perpesanan pengalih tahun di desktop terlalu besar di seluler dan mengganggu kegunaan (kiri). Kami dengan cepat memperbarui prototipe untuk menggunakan pengalih yang lebih kecil di header (kanan).

Beberapa masalah lain terungkap dengan cepat selama sprint prototipe ini:

• Klien, setelah mengklik navigasi fungsional, segera menyadari bahwa mereka telah melewatkan komponen fungsional utama dalam spesifikasi mereka: sebuah blog. Ini memengaruhi perkiraan dan waktu, tetapi kami dapat menyesuaikan dengan cepat.
• Jelas bagi tim UI bahwa tampilan harga terlalu rumit dan membingungkan. Kami menjelajahi kemungkinan lain dengan klien dan dapat dengan cepat membuat prototipe dan pengguna menguji beberapa solusi selama sprint prototipe.

Alih-alih visi berpotensi menjadi hambatan atau menjadi usang segera setelah pengembangan dimulai, dalam sprint prototipe visi dan kriteria fungsional dikembangkan bersama dan saling mendukung. Dan karena visi dihasilkan oleh tim, tidak ada penyerahan kepada tim dan dengan mudah menghindari periode berisiko itu dalam proses pengembangan.

Desain dan Sprint Prototipe

Dalam situasi kedua — kurangnya integrasi desain dengan pengembangan — sering kali Anda akan melihat "sprint desain" digunakan. Saya menemukan arah ini bahkan lebih kontraproduktif daripada Sprint 0. Tantangan dalam mengintegrasikan desain ke dalam proses pengembangan yang kompleks adalah nyata tetapi sprint desain adalah pendekatan yang mengalahkan diri sendiri. Sprint desain adalah bandaid untuk gejala — tantangan membangun tim terintegrasi — tetapi tidak mengatasi masalah mendasar — ​​tantangan untuk memahami dan memenuhi kebutuhan pengguna. Desain pemuatan awal ke dalam satu sprint menghindari tantangan integrasi, tetapi manfaat dari proses desain yang terintegrasi dan bertahap serta jendela yang terbuka untuk memahami dan menjangkau pengguna sama sekali hilang.

Sprint prototipe yang saya gunakan dalam proyek tanpa penyerahan adalah alternatif yang produktif dan sepenuhnya gesit untuk sprint desain. Ini kolaboratif dan menggabungkan UI/UX dan pengembangan dari tahap awal proyek. Bahkan tim desain yang paling berpengalaman pun dapat mengambil manfaat dari keterlibatan disiplin lain dan, secara kritis, memastikan kode dan tujuan desain tidak bertentangan.

Seringkali sprint desain juga diharapkan untuk menyempurnakan visi. Ini adalah langkah putus asa berdasarkan pemahaman yang samar-samar namun mendalam bahwa proses desain lebih siap untuk menghasilkan visi daripada pengembangan. Namun, visi yang dihasilkan desain adalah pengganti yang buruk untuk upaya nyata, kolaboratif, dan seluruh tim.

Desainer yang buruk dibebani dengan menghasilkan produk akhir untuk memulai pengembangan tanpa informasi lintas disiplin yang diperlukan untuk membuat upaya itu benar-benar berharga. Meskipun seorang desainer dengan pengetahuan teknis dan lebih banyak pengalaman akan memiliki kesempatan yang lebih baik untuk mendapatkan hak ini masih sangat berisiko. Dengan tidak adanya produk yang berpotensi dapat dikirim pada akhir fase untuk menguji tebakan terus berlanjut ke pengembangan. Jika desainnya tidak tepat sasaran, atau jika spesifikasinya berubah, hal itu dapat mengakibatkan penundaan yang lama saat dikembalikan ke tim desain. Agile pada intinya adalah proses manajemen risiko, dan kami dapat melakukan lebih baik daripada memulai proyek tangkas kami dengan sprint desain yang secara inheren berisiko.

Proses Desain Prototipe Sprint

Perubahan paling penting dari sprint desain yang lebih tradisional adalah bahwa selama sprint prototipe, tim langsung beralih dari kertas ke prototipe dan melewatkan penggunaan Sketch, InVision, Photoshop, atau program tata letak digital lainnya. Mereka bertindak sebagai penopang visual pada tahap ini, muncul untuk memperkenalkan nilai dengan sangat cepat (karena desainer yang baik membuat hal-hal yang terlihat bagus), tetapi nilai sebenarnya dari mockup fidelitas tinggi pada awal ini sangat rendah, sementara potensi bahaya yang ditimbulkannya — pemangku kepentingan pernikahan untuk solusi yang salah — tinggi.

Alat-alat ini paling baik pada mockup datar dengan kesetiaan tinggi tetapi prototipe awal tidak memiliki kesetiaan tinggi atau datar. Papan tulis, pensil, dan kertas memungkinkan kerja tim melalui ide-ide dengan cepat tanpa terikat padanya. Kemudian dapatkan pemikiran itu menjadi prototipe fungsional sesegera mungkin.

Setiap anggota tim, termasuk desainer, harus terbiasa dan dapat mengerjakan prototipe secara langsung selama fase lo-fi. Tetapi jika itu tidak mungkin (atau itu adalah tujuan jangka panjang dan Anda harus bergerak maju sekarang), maka pendekatan berpasangan di mana seorang desainer dan pengembang bekerja berdampingan adalah baik. Sketsa dapat dideskripsikan oleh perancang dan diinterpretasikan oleh pengembang bersama-sama, memperluas pemahaman bersama mereka tentang setiap sudut pandang.

Contoh

Contoh di bawah ini menunjukkan proses kami menyaring analisis mendalam dari situs web yang ada secara langsung menjadi prototipe fungsional. Ini memungkinkan temuan laporan untuk dievaluasi dalam pengaturan web asli, pengalaman yang sangat berbeda dari rekomendasi analisis intelektual dalam dokumen cetak:

Selain itu, tidak seperti dokumen analisis mendalam (sekaligus membantu) prototipe fungsional bebas dari jargon dan menggunakan bahasa verbal dan visual bersama yang dapat dipahami semua orang. Ini membuka percakapan pada tampilan visual untuk semua anggota tim dan disiplin ilmu.

Pertanyaan utama kami saat membuat template ini adalah seberapa banyak detail desain yang harus disertakan. Karena kami memiliki dokumen kaya yang penuh dengan analisis untuk diambil, kami dapat mengambil prototipe lebih jauh. Namun, dengan mengingat bahwa visual dapat dengan cepat (dan secara tidak sengaja) berpindah dari ranah ide ke ranah fakta, kami menjaga tata letak tanpa komitmen dan menyaring dokumen menjadi elemen dan makna esensialnya saja.

Pengujian internal membawa kami ke rata-rata solusi yang lebih berfokus pada pengguna, melompati banyak masalah potensial, tetapi kami secara sadar menghindari membuat keputusan desain yang disempurnakan ini di awal proses. Sangat penting untuk terus menimbang semua ide dan saran, termasuk klien, terhadap data yang diketahui dan untuk mengingat bahwa kumpulan pengetahuan kita lebih kecil pada titik ini daripada pada tahap proyek lainnya.

Alasan lain penting untuk menjaga prototipe awal tetap lo-fi dan tidak menyertakan elemen "desain" apa pun adalah bahwa dukungan tim dapat digagalkan oleh elemen visual yang tidak relevan yang menimbulkan reaksi mendalam yang tidak diinginkan. Kami menjauhi warna dan bahkan tidak menyertakan logo klien (sebagai gantinya menggunakan ruang kosong atau kotak abu-abu muda sebagai pengganti). Percakapan harus terus dipandu menuju kriteria fungsional seperti hierarki konten, aksesibilitas, kegunaan, bahasa, dan makna. Yakinkan tim bahwa "hal menyenangkan" akan datang tetapi tidak pada tahap awal ini.

Faktanya, tujuan penting dari sprint prototipe yang sukses adalah membuat keputusan desain di muka sesedikit mungkin. Desain yang sukses diberi makan oleh pengalaman pengguna, jadi berikan waktu untuk pengetahuan proyek yang muncul untuk menginformasikan UI.

Kapan Sprint Prototipe Selesai?

Sprint selesai ketika prototipe dan artefak yang menyertainya disetujui oleh tim penuh (termasuk klien), dan prototipe dianggap siap untuk pengujian kegunaan dan aksesibilitas awal.

Prototipe fungsional awal menghidupkan visi proyek melalui skala (jumlah halaman, cakupan navigasi, dan elemen UI utama lainnya), kompleksitas masa depan (konten placeholder dengan deskriptor yang berguna, mungkin beberapa fungsionalitas awal yang dikodekan), dan mengidentifikasi kebutuhan (diperlukan teknologi khusus , di mana mereka akan digunakan, dependensi apa pun). Keputusan mengenai alat, lingkungan kerja, dan tumpukan kode akan dibuat dengan masukan dari seluruh tim.

Mencapai peningkatan yang dilakukan ini dapat memakan waktu hanya satu hari untuk tim berpengalaman dengan klien yang responsif tetapi biasanya berlangsung sekitar satu minggu dan tidak lebih dari dua minggu. Sprint prototipe harus bergerak dengan kecepatan cepat dan melewati kerangka waktu dua minggu bisa menjadi tanda bahaya. Ini mungkin berarti ada masalah lain yang berperan.

Beberapa Masalah Umum Yang Harus Diwaspadai Selama Sprint Prototipe

Beberapa masalah umum yang harus diperhatikan saat mengimplementasikan sprint prototipe meliputi:

• Rangkullah nilai kesetiaan yang rendah dan hindari penekanan pada visual. Waspadalah terhadap poin ini karena tim yang baru dalam pendekatan ini mungkin memerlukan bantuan dan kepastian saat mereka bergerak melampaui "di mana logonya" dan fokus pada pertanyaan fungsionalitas dan hierarki yang lebih dalam.
• Sisi lain dari hal di atas, juga waspada agar tidak terikat pada ide desain/tata letak Anda sendiri. Sangat membantu untuk diingat selama sprint prototipe bahwa tidak ada yang berharga yang dihasilkan dan tetap terlepas dari hasil akhir. Juga, ini adalah alasan lain untuk menjaga agar prototipe tetap minimal dan, sejujurnya, agak jelek. Ini melayani tujuan menjaga pengguna terlepas.
• Proses awal buy-in dari kepemimpinan sangat penting . Karena seluruh tim terlibat, klien Anda, bos Anda, dan pengembang semua perlu mendukung dan memelihara proses dengan keterlibatan, kreativitas, dan waktu mereka. Jangan menjadi pemandu sorak sendirian, seluruh tim Anda perlu melambaikan pom-pom mereka!
• Komunikasi yang buruk adalah kelemahan dari semua kerja tim . Prototipe sprint tidak akan menyelesaikan masalah komunikasi yang terus-menerus, tetapi akan membawa mereka ke permukaan lebih cepat saat seluruh tim terjun ke dalam alur kerja kolaboratif segera. Masalah komunikasi apa pun yang sudah ada akan muncul lebih awal dan sering kali dalam sprint prototipe saat Anda bekerja menuju konsensus dan peningkatan pertama yang Anda lakukan. Rangkullah peluang untuk meningkatkan komunikasi dan libatkan seluruh tim dalam mencari solusi.
• Pilih kerangka kerja front-end yang tepat . Jika Anda belum memilikinya, Anda mungkin perlu mencoba berbagai kerangka kerja front end sebelum Anda menemukan kerangka kerja yang sesuai dengan alur kerja tim Anda. Saya sarankan melihat ke dalam kerangka kerja minimal seperti Fomantic atau Bulma dan tidak terjebak oleh lonceng dan peluit. Namun, kerangka kerja yang tepat selalu yang bekerja untuk tim Anda.
• Tim UI/UX perlu mengembangkan tingkat kenyamanan dan akses ke kerangka kerja ujung depan. Idealnya, mereka akan bekerja langsung pada prototipe, menghindari handoff yang tidak perlu dan kebutuhan untuk terjemahan dari satu media ke media lain (yaitu dari Sketch ke prototipe). Jika tim front-end Anda tidak terbiasa dengan CSS dan HTML, maka pendekatan berpasangan (dengan satu desainer dan satu programmer bekerja sama dalam kerangka kerja) juga berfungsi dengan baik.
• Last but not least, ingatlah bahwa Anda akan menjadi lebih baik dan lebih cepat sebagai sebuah tim ! Menjalankan prototipe sprint yang produktif adalah keterampilan yang tumbuh dengan latihan.

Apa yang terjadi selanjutnya

Peningkatan yang dilakukan dari sprint pertama — prototipe fungsional, fidelitas rendah — menetapkan panggung untuk semua sprint berikutnya. Dengan prototipe yang berfungsi, pengujian pengguna untuk kegunaan, aksesibilitas, dan daya tanggap dapat segera dimulai, memastikan sprint di masa mendatang diinformasikan oleh UX.

Sprint prototipe adalah awal yang baik untuk proses scrum apa pun, tetapi dalam proyek saya, langkah kami selanjutnya adalah pindah ke alur kerja jalur ganda di mana UI/UX bekerja setengah atau seluruh sprint sebelum pengembangan melakukan penemuan dan memperbarui prototipe secara visual ke mencerminkan wawasan baru.

Prototipe secara organik berkembang dan menjadi semakin lebih disempurnakan, didukung oleh penelitian UX dan kebutuhan fungsional yang realistis. Informasi itu, tidak tersedia selama sprint prototipe, hanya muncul secara bertahap saat proyek berlangsung. UI/UX dan pengembangan saling mengisi alur kerja melalui proses gesit jalur ganda.

Tidak ada handoff desain untuk pengembangan yang akan dibangun, atau aplikasi yang dikembangkan untuk mendesain ke skin. Sebaliknya, sprint prototipe melibatkan seluruh kelompok sejak awal dan membentuk fondasi yang kuat untuk alur kerja kolaboratif yang gesit di seluruh proyek.

Visi panduan yang dihasilkan dari sprint prototipe tidak akan sempurna dan kemungkinan akan berubah seiring lebih banyak yang dipelajari, tetapi pengakuan bahwa kita tahu lebih sedikit di awal daripada di fase lain dari sebuah proyek adalah inti dari alur kerja yang gesit. Ketika kami menerapkan filosofi yang sama ini pada munculnya visi dan desain proyek melalui sprint prototipe, hasilnya adalah peningkatan yang dapat ditindaklanjuti, artefak yang benar-benar berguna, persetujuan bersama, dan pola kerja tim dan kolaborasi yang dapat dipertahankan selama proyek berlangsung. .

Catatan Tentang Pengaturan Agensi

Jika Anda bekerja di agensi, Anda mungkin berpikir pendekatan ini akan sulit dijual. Sayangnya, Anda mungkin benar. Banyak lembaga secara inheren tidak gesit dan secara aktif berusaha untuk menyerahkan proyek secara total, seringkali dengan penandatanganan resmi dan dampak yang didokumentasikan dengan hati-hati untuk membuat perubahan di jalan. Mengadvokasi prototipe sprint di organisasi non-gesit adalah non-starter: itu tidak ada dalam DNA mereka. Begitu sebuah organisasi merangkul tim yang gesit dan lintas disiplin maka mereka dapat dengan mudah mempertimbangkan apakah sprint prototipe tanpa handoff akan meningkatkan proses mereka.

Kesimpulan

Sprint 0 dan sprint desain menjawab tantangan nyata yang dihadapi banyak tim scrum: kurangnya visi, kurangnya desain terintegrasi, atau keduanya. Mereka adalah respons yang dapat dimengerti dan logis, tetapi mereka tidak memberikan nilai tinggi atau berkontribusi pada tim gesit yang kuat.

Menggantinya dengan sprint prototipe adalah cara praktis untuk mengatasi kelemahan Sprint 0 dan sprint desain sekaligus meletakkan dasar untuk kolaborasi gesit yang lebih kuat selama sprint mendatang.

Sebuah sprint prototipe memanfaatkan bakat seluruh tim, menghasilkan visi yang diperlukan, menghasilkan peningkatan tim yang pertama kali dilakukan, dan menghindari penyerahan proyek. Melalui proses ini, tim membangun kepemilikan bersama atas visi proyek dan landasan yang lebih kuat untuk kerja sama lintas disiplin dalam semangat tangkas.

Bacaan Lebih Lanjut tentang SmashingMag:

• Menjadi Fasilitator yang Lebih Baik
• Beradaptasi Agile Untuk Tim Paruh Waktu
• Pentingnya Retrospektif Proyek
• Membawa Proses Desain yang Lebih Baik ke Organisasi Anda