Bagaimana cara kerja Scrum ketika Anda memiliki banyak proyek? [Tutup]

Saya cukup memahami manfaat dan proses Scrum. Saya mendapatkan ide tentang backlog, grafik burndown, iterasi, menggunakan cerita pengguna, dan berbagai konsep lain dari "kerangka kerja" Scrum.

Karena itu ... Saya bekerja untuk perusahaan pengembangan web yang mengelola banyak proyek sekaligus, dengan enam anggota tim yang membentuk "tim produksi".

Bagaimana Scrum bekerja dengan memiliki banyak proyek? Apakah Anda masih menjadwalkan iterasi untuk satu proyek dalam jangka waktu tertentu dan seluruh tim mengerjakannya, lalu Anda beralih ke proyek berikutnya dengan iterasi baru ketika iterasi tersebut selesai? Atau adakah cara yang "lincah" dalam mengelola banyak project dengan iterasinya sendiri hanya dengan satu tim di waktu yang sama?

Scrum benar-benar tidak mendikte bahwa Anda harus mengerjakan satu produk mandiri. Ini hanya menyatakan bahwa ada banyak hal yang perlu diselesaikan (product backlog), ada sejumlah waktu pengembangan yang tersedia di iterasi berikutnya (dikerjakan dari kecepatan proyek) dan ada item yang dipilih oleh klien / bisnis memiliki prioritas utama dari kumpulan masalah / tugas ini yang akan diselesaikan di iterasi berikutnya (sprint backlog).

Tidak ada alasan produk backlog dan sprint backlog harus dari satu proyek - bahkan dalam satu proyek akan ada unit kerja terpisah yang seperti proyek terpisah - UI, lapisan bisnis, skema database, dll. Pengembangan perangkat lunak perusahaan secara khusus seperti ini, di mana Anda memiliki sejumlah basis kode yang semuanya harus maju. Proses Scrum - rapat, pertanyaan, grafik burn down, dll - semuanya berjalan baik itu satu proyek atau beberapa.

Karena itu, dalam praktiknya sering kali baik untuk setiap iterasi untuk memiliki tema utama - "lakukan modul pelaporan" atau "antarmuka dengan API sistem XYZ" - sehingga banyak masalah berasal dari satu proyek atau area dan di di akhir iterasi, Anda dapat menunjuk ke sebuah karya besar dan memberi tanda centang padanya.

Menurut saya jawabannya tergantung pada " siapa yang akan memprioritaskan item simpanan " (yaitu memutuskan apa yang perlu dilakukan terlebih dahulu). Jika ini adalah satu orang, maka orang ini adalah Pemilik Produk untuk proyek Anda, dan Anda dapat memiliki satu cadangan semua item untuk semua proyek - atau simpanan per proyek - dan Anda memilih item simpanan dari semua proyek saat Anda merencanakannya sebuah Sprint. Dalam hal ini, Scrum "berfungsi" dengan baik.

Jika setiap proyek memiliki tanggung jawabnya sendiri, maka Anda mungkin akan menghadapi beberapa masalah di mana setiap penanggung jawab akan - kurang lebih secara sadar - mencoba untuk mendukung proyeknya. IMHO, Anda hanya perlu memiliki satu Pemilik Produk yang memiliki kewenangan untuk menyelesaikan prioritas melalui arbitrase.

Salah satu aturan yang harus diikuti dalam konteks seperti itu adalah jangan pernah mengubah konten Sprint selama Sprint . Jika perlu, Anda dapat mempersingkat iterasi menjadi dua atau tiga minggu untuk mengurangi risiko harus menambahkan item mendesak di Sprint saat ini.

Saya harus tidak setuju. Saya pikir itu adalah kunci dari proses untuk memiliki tim yang berfokus pada satu proyek selama sprint. Jika Anda memiliki beberapa spesialis yang tidak dapat berkontribusi pada seluruh proses pengembangan (penulis konten, staf grafis, analis proses bisnis, dll.) Saya akan mengeluarkan mereka dari tim ketika mereka tidak dapat lagi berkontribusi. Atau lebih baik lagi, buat mereka dilatih tentang beberapa tugas berbeda sehingga mereka dapat berkontribusi pada hal-hal seperti pengujian.

Hal lain yang perlu diingat adalah menjalankan proyek secara paralel akan membunuh jadwal Anda. Pertimbangkan ini: demi kesederhanaan, katakanlah kita memiliki 5 proyek menggunakan tim yang sama dan dimulai pada tanggal yang sama. Setiap proyek membutuhkan 3 bulan usaha, Dalam skenario kasus terbaik berjalan paralel, Anda akan menyelesaikan semuanya sekaligus dan itu akan memakan waktu 15 bulan. Kecepatan Anda akan melambat karena Anda hanya dapat memasukkan 1/5 upaya sebulan dalam satu sprint. Anda juga akan melakukan 5 rapat demo secara bersamaan. Jadi skenario kasus terbaik, Anda menyelesaikan 5 proyek Anda dalam 15 bulan dan pesaing Anda akan mengklaim mereka dapat melakukan pekerjaan yang sama di 3. Tim Anda memperkirakan kedewasaan akan menderita karena mereka hanya dapat mempertimbangkan 20% dari tenaga kerja yang tersedia. Anda mungkin menemukan bahwa Anda sebenarnya tidak dapat melakukan beberapa tugas dalam satu sprint. Jika Anda harus mengubah jumlah proyek yang sedang dikerjakan dari 5, tim Anda harus menyesuaikan kebiasaan memperkirakan mereka yang akan merusak efisiensi tim. Selain itu, tim Anda akan kesulitan untuk mengatur diri sendiri ketika penugasan ulang tugas sederhana mungkin memerlukan pemutaran lingkungan pengembangan baru sebelum pekerjaan dapat dimulai.

Jika Anda menjalankan 5 proyek yang sama secara serial, Anda akan mengirimkan proyek ke-5 dalam 15 bulan yang sama, tetapi Anda akan mendidik klien Anda bahwa tim Anda sangat dibutuhkan sehingga Anda memiliki backlog 12 bulan dan dapat Anda gunakan waktu itu untuk menyempurnakan tujuan proyek Anda. Atau jika Anda memiliki backlog yang konstan, Anda tahu inilah saatnya untuk mulai merekrut tim lain. Proyek terbaik Anda, bagaimanapun, selesai dalam 3 bulan dengan klien yang telah melihat peningkatan pesat selama masa aktif. Anda dapat menyelesaikan proyek itu setahun lebih awal dan dapat meletakkannya di resume Anda. Kecepatan sprint Anda akan stabil selama periode waktu itu dan Anda mungkin menemukan bahwa kecepatannya mencapai satu atau dua proyek dan mampu mencapai lebih banyak dalam sprint tertentu.

Saya pikir menjalankan proyek secara serial adalah salah satu rintangan terbesar yang diusahakan organisasi untuk mengadopsi wajah scrum. Ini adalah perubahan budaya utama yang terkait dengan dekonstruksi peran manajer proyek, tetapi manfaat dari proses scrum sangat besar.

Ingatlah bahwa SEMUA ORANG tidak perlu menjadi anggota tim penuh. Mereka dapat melibatkan klien Anda di ruang tunggu, mempersiapkan proses pengembangan. Saya mempertahankan analis bisnis, arsitek jaringan, dan orang-orang desain grafis saya sebagai pakar domain dan hanya melampirkan mereka ke tim sesuai kebutuhan. Biarkan mereka berjalan dengan sprint 0. Anda akan terkejut betapa menariknya mengerjakan tampilan-dan-rasa dan alur kerja. Ini juga baik untuk mempersiapkan klien Anda dengan pemahaman bahwa ketika pengembangan dimulai dengan sungguh-sungguh, tingkat partisipasi mereka mungkin benar-benar naik dan penting bagi mereka untuk tersedia. Beri tahu mereka jadwalnya sehingga mereka punya banyak waktu untuk menangani hal-hal seperti liburan dan liburan jauh-jauh hari.

Saya telah berada dalam situasi yang persis seperti ini.

Jika Anda memiliki satu pemilik produk di seluruh proyek, maka Phillipe benar; Satu sprint dengan satu tim seharusnya bekerja dengan baik.

Jika Anda memiliki lebih dari satu pemilik produk, maka idealnya sisi bisnis perlu memilih satu 'prioritizer' yang diberi tanggung jawab untuk menjadwalkan pekerjaan. Ini jelas merupakan solusi terbaik.

Jika (seperti yang mungkin terjadi) bisnis tidak ingin mengubah cara mereka ingin memprioritaskan hal-hal (itu akan terlalu nyaman) maka Anda dapat membagi tim., Dan menjalankan dua sprint bersamaan. Namun dengan tim yang terdiri dari enam orang, saya tidak akan membaginya menjadi lebih dari 3 tim (saya tidak ingin membaginya sama sekali, tetapi saya pikir 2-3 tim akan bisa diterapkan). Berpisah lebih jauh seperti yang disarankan Kenny, dan memiliki tim yang terdiri dari satu orang tampaknya tidak ada gunanya bagi saya, karena Anda tidak lagi memiliki tim, hanya pemrogram individu.

Jika Anda memecah tim, saya tidak menemukan banyak manfaat dalam menggabungkan stand-up, kecuali jika Anda memiliki sprint terpisah yang mengerjakan sebagian besar basis kode yang sama, tetapi itu mungkin menjadi argumen untuk menggabungkan tim-tim itu untuk tujuan sprint.

Ada pendapat lain yang saya baca akhir-akhir ini, yaitu bahwa dalam lingkungan Agile konsep Project mungkin kontraproduktif dan bisa dihilangkan. Menurut garis pemikiran ini, organisasi seharusnya berfokus pada Rilis . Ini karena Proyek adalah kotak buatan yang tidak menghasilkan nilai sampai selesai. Mereka bertentangan dengan tujuan Agile untuk sering memberikan nilai yang dapat dikirim. Sebuah rilis lebih sejalan dengan Agile karena berorientasi pada memberikan nilai dan karena jangkauannya dapat dikurangi atau diperluas berdasarkan apa yang tim dapat memberikan sebelum berikutnya Rilis .

Ada jalan tengah potensial, di mana apa yang sebelumnya disebut Proyek di perusahaan Anda sekarang dikemas ulang sebagai Tema atau Fitur Agile yang umum . Manfaat dari pendekatan ini adalah bahwa Tema atau Fitur sekarang dapat diimplementasikan dalam potongan-potongan nilai, sesuai keinginan pemilik produk.

Masih ada pertanyaan tentang satu tim yang mengerjakan beberapa Produk , dan ini adalah pertanyaan karena kekhawatiran yang sah tentang pengetahuan domain dan kemungkinan keterampilan teknis. Tapi Produk dibangun dengan Agile, bahkan beberapa Produk yang dibangun oleh satu tim, terus mengumpulkan Rilis nilai -Mampu. Sebaliknya, Proyek tidak ada nilainya sampai selesai (dan banyak yang tidak).

Sesuatu untuk dipikirkan...

Saya pikir anopres benar: cara terbaik adalah menghindari banyak proyek sekaligus dengan scrum. Lakukan segalanya untuk meyakinkan bahwa menjalankan terlalu banyak secara paralel tidak efisien.

Mari kita asumsikan 5 proyek masing-masing sekitar 3 bulan untuk tim dengan 5 orang.

Pendekatan 1: setiap orang mengerjakan satu proyek dalam tim

• 1/5 kecepatan pengiriman per proyek memberikan 15 bulan pengiriman untuk semua proyek
• Setiap orang ahli tetapi hanya dalam proyeknya sendiri
• Tidak ada semangat tim

Pendekatan 2: 1 sprint per proyek, beralih proyek

• Setiap sprint ke-6 mengerjakan proyek
• Waktu yang terlalu lama antara pekerjaan proyek - bukan nilai inkremental yang teratur untuk proyek (untuk backlog produk ya), mudah dilupakan, diperlukan upaya untuk memulihkan konteks,
• Proyek pertama selesai setelah sekitar 12-13 bulan (dengan asumsi sprint 2 minggu)

Pendekatan 3: 5 proyek dalam satu sprint

• Memerlukan pembagian tugas yang terlalu mendetail agar sesuai dengan sprint
• Sangat sedikit build tambahan per project
• Pengiriman proyek pertama setelah sekitar 12-15 bulan

Pendekatan 4: disarankan - Pekerjaan berseri

• Tim mengerjakan satu proyek demi proyek
• Proyek pertama dimulai dan dikirim setelah 3 bulan
• Proyek kedua dimulai setelah bulan ke-3, dikirim setelah bulan ke-6
• ...
• Proyek ke-5 dimulai setelah bulan ke-12, dikirim setelah bulan ke-15
• Tim sangat fokus pada proyek, penelitian intensif, dan kolaborasi dengan pelanggan
• Seluruh tim memiliki pengetahuan umum yang baik tentang semua proyek
• Tidak perlu membuang waktu untuk pengalihan konteks
• Memerlukan kerja sama tim yang baik (konflik dapat memperlambat pengiriman).

Seperti yang Anda lihat, solusi 4 umumnya lebih baik karena proyek dikirimkan lebih cepat, tim bekerja sama, dan efisien. Pendekatan lain termasuk membuang waktu dari pengalihan konteks, tidak ada kolaborasi tim penuh, total waktu pengiriman yang sangat lama untuk semua proyek, dll.

Dan bagaimana dengan perawatan backlog? Jika tim mengerjakan satu proyek sekaligus, itu sederhana - semua orang akan bergabung. Jika ada beberapa proyek, kami mungkin perlu mendelegasikan para lajang untuk memisahkan sesi perawatan (tidak melibatkan tim penuh).

Penting untuk meyakinkan pelanggan bahwa memulai proyek kedua setelah 3 bulan masih akan menghasilkan pengiriman yang lebih cepat (setelah bulan ke-6) daripada jika kami memulainya segera dengan yang lain. Ini adalah ilusi yang dilihat manajer - kami memulai 5 proyek sekaligus, kami bekerja keras dan menyelesaikannya sedikit demi sedikit. Pada akhirnya ini tidak efisien.

Itulah mengapa saya tidak percaya bahwa scrum efisien untuk banyak proyek secara paralel, sangat sulit untuk mencocokkannya ke dalam kerangka kerja dan bekerja sesuai dengan aturan scrum. Terkadang bagus memiliki 2 proyek untuk membuat semua orang sibuk, tetapi semakin banyak proyek yang kita tambahkan semakin kurang efisien scrumnya. Mungkin kanban adalah alternatif hanya untuk melihat kemajuan dan kerja tim (tidak sekuat di tim Scrum)?

Salam, Adam

Seperti yang dikatakan @Chris, proyek normal memiliki sub proyek di dalamnya. Anda hanya memiliki satu backlog.

Pikirkan dalam backlog dengan semua proyek Anda. Masalah pertama: apakah Anda menetapkan prioritas untuk tugas atau proyek? Saya lebih suka backlog per proyek. Setidaknya memiliki prioritas yang jelas yang dimiliki oleh product owner.

Memiliki pemilik produk yang berbeda, dan karena pemilik produk tersebut tidak akan menyetujui berapa banyak waktu yang harus mereka berikan untuk setiap proyek. "Seseorang" harus mengabaikan keputusan tentang bagaimana mengelola prioritas antar proyek. Catatan: pengembang tidak boleh melakukannya.

Ini dia manajer proyek "S" kami yang akan menyeimbangkan sumber daya yang dibutuhkan pemilik produk dan waktu yang dapat diberikan oleh anggota tim. Pemilik produk A membayar untuk satu bulan kerja, tetapi pemilik produk B selalu memperbarui proyeknya (dan juga membayar Anda dengan baik). Ada beberapa cara bagaimana Anda akan menyeimbangkan tim Anda agar A memiliki satu bulan (waktu pengembang), dan tidak menghentikan B mengisi kantong Anda.

Dalam kasus perangkat lunak internal (satu perusahaan, seribu proyek). Pemilik produk yang berbeda harus menyetujui waktu yang diberikan kepada mereka. Mereka tidak hidup terisolasi, tetapi dalam perahu yang sama dengan Anda (manajer proyek "S"). Mereka akan membuat hidup Anda lebih mudah karena dapat menunda beberapa tugas, tetapi pada saat yang sama Anda tidak boleh melupakan kebutuhan mereka.

Nah, saya masih mencoba mencari cara terbaik untuk melakukan ini. Tapi inilah yang kami dorong sekarang. Saya harap ini membantu.

Anggota tim dapat membagi waktu mereka di antara proyek scrum, tetapi jauh lebih produktif untuk memiliki anggota tim yang berdedikasi penuh. Anggota tim juga dapat berubah dari satu sprint ke sprint berikutnya, tapi itu juga mengurangi produktivitas tim. Proyek dengan tim yang lebih besar diatur sebagai beberapa scrum, masing-masing berfokus pada aspek yang berbeda dari pengembangan produk, dengan koordinasi yang erat dari upaya mereka.

Saya akan menyarankan menjalankan satu Sprint untuk setiap Proyek dan memiliki 1 rapat standup harian untuk menangani semua Mata Air / proyek yang aktif.

Saya ingin berkontribusi. Inilah cara saya melakukannya:

• Ada satu pemilik produk dan satu jaminan produk per tim. Pemilik produk tidak harus satu orang, tetapi "entitas" pemilik produk ini bertanggung jawab atas backlog produk.
• Product backlog memiliki cerita pengguna dari setiap proyek (semua proyek di sini). Setiap cerita pengguna memiliki poin usaha / cerita (tanggung jawab tim) dan nilai bisnis (tanggung jawab pemilik produk).
• Kami mengadakan pertemuan "product backlog grooming" di setiap sprint. Sebelum pertemuan ini, pemilik produk telah memperbarui nilai-nilai bisnis dari cerita-cerita tersebut (jika mereka memerlukan beberapa perubahan untuk alasan bisnis apa pun - yang tidak dan tidak boleh kita pedulikan-) dan menyertakan beberapa cerita baru. Dalam pertemuan ini dijelaskan cerita-cerita baru dan upayanya diperbarui juga. Pertemuan ini berlangsung sekitar satu jam (kecuali yang pertama, sekitar 4 jam).
• Ketika kita akan merencanakan sprint baru, kita membuka product backlog, mengurutkan story berdasarkan ROI (ini adalah nilai bisnis / usaha) dan merencanakan story sampai waktunya habis.

Dan itu dia. Saya dapat mengatakan ini bekerja dengan baik. Kami menggunakan beberapa spreadsheet Google (product backlog dan sprint backlog, baik dengan grafik dan sebagainya) untuk melakukan ini, dan redmine (dengan semantik tertentu) untuk organisasi online setiap hari: waktu, kemajuan tugas, dll.

Masalah dengan pendekatan ini adalah saya telah menduplikasi tugas di sprint backlog spreadsheet dan redmine. Tetapi saya tidak menemukan alat online apa pun untuk melakukan ini sepenuhnya secara online. Saya melewatkan backlog produk di redmine (tidak ada semantik lain yang berfungsi untuk saya), satu papan di jira, lebih banyak cerita di taiga, dan sebagainya