Saya baru-baru ini bergabung dengan ruang peretas muda yang masih dalam proses pengaturannya sendiri. Kami beruntung karena ruang memiliki beberapa proyek internal yang perlu dikerjakan dan tidak ada kekurangan relawan untuk mengerjakannya.
Ada beberapa diskusi tentang bagaimana mengatur proyek-proyek ini. Pengalaman profesional saya yang terbaru adalah dengan Scrum, jadi saya mempertimbangkan untuk mengajukan pendekatan Scrum untuk proyek perangkat lunak kami, tetapi saya tidak yakin itu akan cocok.
Meskipun saya telah melihat Scrum bekerja dengan baik untuk tim penuh waktu kecil, sifat organisasi ini berbeda:
- Para anggotanya adalah sukarelawan . Beberapa siswa penuh waktu. Lainnya bekerja penuh waktu. Kita tidak dapat mengharapkan tingkat kontribusi konstan dari siapa pun karena kehidupan nyata mereka diprioritaskan.
- Sementara hampir semua orang memiliki pengalaman bertahun-tahun menulis perangkat lunak, tidak banyak anggota yang melakukannya secara profesional atau dalam tim.
- Tidak ada Pemilik Produk . Persyaratan untuk proyek-proyek ini ditentukan oleh komite. Anggota komite ini juga akan mengerjakan implementasinya. Ini berarti kita tidak akan memiliki Pemilik Produk tunggal, khusus, dan berdedikasi.
- Kami tidak memiliki tenggat waktu (lunak atau keras). Proyek-proyek akan selesai ketika mereka selesai.
Ini adalah perbedaan yang cukup signifikan, tetapi saya tidak yakin mereka akan menjadi penghambat penerapan Scrum. Saya pikir beberapa penyesuaian kecil dapat mengatasi rintangan ini:
- Jika kita mengubah Sprint menjadi memiliki ukuran titik-cerita yang tetap, tetapi durasi yang cair (waktu), kita masih bisa mendapatkan manfaat dari rilis berulang tanpa memberikan tekanan pengiriman yang tidak realistis pada sukarelawan dev.
- Kita bisa membuang grafik burndown dan perhitungan kecepatan . Jika saya mengerti dengan benar, ini adalah alat dan metrik yang berfungsi sebagai jembatan antara tim pengembang dan Manajemen. Mereka melayani untuk melaporkan kemajuan dalam bentuk yang bermakna bagi pengembang dan pemangku kepentingan. Mengingat kami tidak memiliki siapa pun untuk melapor (tidak ada Manajer Proyek, tidak ada Pemilik Produk, dan tidak ada pemangku kepentingan dari luar) saya percaya kami dapat membatalkan ini sama sekali.
Hal-hal yang saya pikir dapat kita manfaatkan dari yang tidak akan memerlukan penyesuaian:
- The Persyaratan Mengumpulkan pertemuan (s). Di mana semua orang duduk di sekitar meja dan membahas Kisah Pengguna, membuat sketsa pengolok UI, dan membangun Product Backlog.
- Retrospektif Sprint . Ini akan menjadi cara yang menarik bagi kita untuk berkumpul pada proses pengembangan yang bekerja untuk kita sebagai tim sukarelawan.
Hal yang saya tidak yakin tentang:
- Bagaimana Seharusnya Stand-up harian diperlakukan? Saya bertanya-tanya apakah mereka akan memiliki banyak nilai di lingkungan kita. Pemahaman saya tentang ritual stand-up adalah bahwa itu membantu komunikasi dengan menyebarkan informasi secara alami ke seluruh tim. Mempertimbangkan fakta bahwa Sprint kita kemungkinan akan memberikan kompleksitas yang jauh lebih sedikit daripada Sprint rata-rata, mungkin ada sedikit kebutuhan untuk mengikuti perkembangan / perkembangan semua anggota tim lainnya.
- Haruskah saya mendorong untuk hal-hal XP seperti Integrasi Berkelanjutan, Ulasan Kode, dan TDD? Saya khawatir ini akan banyak meminta. Saya akan lebih tergoda untuk membawa konsep-konsep ini ke dalam proyek-proyek masa depan begitu orang lebih akrab dengan Scrum dan bekerja sebagai sebuah tim.
Pertanyaan saya:
Bisakah Scrum diadaptasi ke lingkungan berbasis sukarelawan?
Dan, apakah pendekatan saya yang direncanakan sejauh ini berjalan ke arah yang benar?