Haruskah SCRUM digunakan untuk proyek dengan hanya satu orang yang mengerjakannya?

Di perusahaan kami, kami memiliki tim yang mengerjakan 3 proyek berbeda pada waktu yang bersamaan, di mana biasanya hanya satu atau dua orang yang terlibat dalam setiap proyek. Pekerjaan proyek seringkali melibatkan penguasaan teknologi baru dan atau penyelesaian bug, keduanya mengarah pada tugas yang sangat sulit untuk diperkirakan. Dalam situasi ini, manajemen masih bersikeras menggunakan SCRUM dan tidak mengizinkan mengalokasikan buffer keselamatan di akhir sprint untuk situasi yang tidak terduga. Pertemuan berdiri terjadi untuk seluruh tim, meskipun hampir semua orang bekerja pada komponen perangkat lunak yang tidak terkait atau proyek perangkat lunak yang berbeda secara bersamaan.

• Saya bertanya-tanya apakah seseorang telah melihat SCRUM bekerja dengan baik untuk proyek dengan pengembang tunggal dan tugas fuzzy, dan bagaimana Anda membuat proses bekerja dengan baik?

• Bagaimana memperkirakan tugas yang melibatkan penelitian / penguasaan teknologi baru (ini melibatkan pembelajaran bahasa pemrograman baru, platform, dan alat pengembangan)?

• Adakah yang berhasil meyakinkan manajemen untuk tidak menggunakan SCRUM untuk proyek tertentu, dan jika ya, argumen mana yang paling berhasil?

Terima kasih!

Cari "Personal Scrum" ... Saya telah melihat beberapa atau tiga posting blog dari orang yang melakukan ini. Full Scrum memiliki beberapa gagasan yang tidak akan diterjemahkan dengan sempurna ke tim satu orang. (Pengalaman saya - "massa kritis" tertentu sekitar 4 orang tampaknya membuat kerja tim menjadi baik.)

http://blog.jgpruitt.com/tag/personal-scrum/ misalnya.

Tetapi hal-hal seperti estimasi tugas, kecepatan, dan sprint terikat waktu selama daftar tugas "dilindungi" bekerja dengan baik bahkan untuk 1.

Tentu saja tidak. Scrum harian Anda akan sangat singkat, dan sangat membosankan!

Anda dapat memilih bagian-bagian yang menurut Anda akan membantu Anda, kartu masuk akal meskipun Anda tidak harus mengisinya secara penuh; berhenti setelah waktu yang ditentukan untuk memeriksa kemajuan Anda juga masuk akal. Tetapi jika Anda melakukan itu, periksa Kanban, Crystal dan semua metode Agile lainnya juga untuk bit yang akan membantu Anda.

Tidak, Anda tidak dapat melakukan scrum tanpa tim. Tim yang didefinisikan oleh SCRUM adalah "Sekelompok orang lintas fungsi yang bertanggung jawab untuk mengelola dirinya sendiri untuk mengembangkan produk" yang merupakan peran penting dalam SCRUM.

Menurut http://www.scrum.org/storage/scrumguides/Scrum_Guide%202011.pdf

Ukuran Tim Pengembangan Ukuran Tim Pengembangan Optimal cukup kecil untuk tetap gesit dan cukup besar untuk menyelesaikan pekerjaan yang signifikan. Kurang dari tiga anggota Tim Pengembangan mengurangi interaksi dan menghasilkan peningkatan produktivitas yang lebih kecil. Tim Pengembangan yang lebih kecil mungkin menghadapi kendala keterampilan selama Sprint, menyebabkan Tim Pengembangan tidak dapat memberikan Peningkatan yang berpotensi dirilis. Memiliki lebih dari sembilan anggota memerlukan koordinasi terlalu banyak. Tim Pengembangan Besar menghasilkan terlalu banyak kerumitan untuk dikelola oleh proses empiris. Peran Pemilik Produk dan Master Scrum tidak termasuk dalam penghitungan ini kecuali mereka juga menjalankan pekerjaan Sprint Backlog

Namun Anda masih bisa gesit, dan mungkin menggunakan karakteristik lain dari SCRUM seperti mempertahankan produk / sprint backlog dan perencanaan & bekerja di bawah sprint / iterasi, meninjau dan mendapatkan umpan balik dari semua pemangku kepentingan dan perencanaan ulang dan sebagainya. Silakan baca lebih lanjut tentang scrum karena lebih dari itu seperti yang dijelaskan di sini.

Saya bekerja di toko yang sama. Seperti yang dicatat orang lain di sini, apa yang Anda gambarkan mungkin gesit tetapi bukan scrum. Saya juga akan menambahkan apakah log atau sprint masuk akal atau tidak tergantung pada apakah itu pekerjaan baru atau pemeliharaan dan dukungan yang sedang berlangsung. Jika yang pertama, maka pendekatan air terjun akan lebih masuk akal untuk tim satu orang. Jika tidak, dari perspektif PM, apa yang mereka lakukan tampak seperti pendekatan yang baik jika mereka memiliki banyak proyek dalam portofolio mereka.

Bagi penggemar Agile, penyebutan hanya menggunakan air terjun adalah penistaan. Tetapi orang perlu menggunakan akal sehat.

Biarkan saya memberi contoh dari proyek saya baru-baru ini. Saya memimpin tim yang terdiri dari 3 pengembang dengan garis waktu 5 bulan yang agresif untuk mendesain ulang dua situs web utama. Kami melakukan pertemuan sehari-hari. Tapi itu adalah proyek air terjun karena itu adalah tim kecil, siklus hidup terbatas, dan pengembang semua adalah kontraktor jangka pendek yang berkomitmen untuk proyek hanya sampai diluncurkan. Proyek ini mengikuti siklus hidup air terjun yang sangat tradisional. Sama sekali tidak ada yang salah dengan itu. Kecuali kami benar-benar bekerja dengan cara yang "gesit", kami mempertahankan pertemuan stand-up dan kami terus melakukan praktik-praktik terbaik pengembangan tangkas. Tim kecil kami dibebaskan dari pertemuan perencanaan sprint mingguan tim yang lebih besar. Mengapa? Karena kami tidak memiliki penyebaran mingguan. Dan tim kami tidak bergantung pada atau memengaruhi pekerjaan yang dilakukan oleh tim lain mana pun. Bahkan, kami bekerja hampir secara mandiri. Setelah situs web diluncurkan, kami kemudian beralih ke proses yang gesit untuk pemeliharaan dan dukungan yang sedang berlangsung. Pengembang lain sekarang bekerja di tempat lain. Semua peningkatan direncanakan sesuai dengan penyebaran berkala.

Intinya adalah, lebih baik menggunakan proses yang paling masuk akal untuk ukuran, kompleksitas, dan kematangan setiap proyek. Jika Anda melakukan banyak penelitian, maka sulit untuk membuat perkiraan untuk lima bulan ke depan, jadi gesit mungkin pendekatan yang lebih baik daripada air terjun.

Sebagian masalahnya adalah bahwa beberapa orang tampaknya berpikir Anda dapat merencanakan lima sprint berikutnya di muka. Itu yang terjadi dengan saya sebelumnya. Anda tidak boleh merencanakan lebih dari dua sprint karena jika Anda melakukannya, Anda mengalahkan seluruh tujuan sprint. Sprint seharusnya merupakan komitmen untuk memberikan peningkatan yang realistis dalam jumlah waktu yang ditentukan. Anda tidak harus berkomitmen pada sesuatu yang Anda tidak yakin. Perencanaan sprint pada dasarnya adalah perencanaan jangka pendek, tetapi itulah intinya. Jika Anda memiliki jadwal jangka panjang, maka pikirkan memecah hal-hal menjadi kiriman yang lebih kecil. Atau mengatur pertemuan pos pemeriksaan berdasarkan di mana Anda berada di SDLC.

Perencanaan sprint seharusnya merupakan komitmen realistis tentang apa yang dijamin akan selesai dalam jangka waktu tertentu. Jika Anda menemukan bahwa perencanaan tersebut tidak memperhitungkan variabel yang tidak diketahui, mungkin Anda harus mulai memberikan rentang atau perkiraan pesimistis. Atau seperti yang disarankan lainnya, gunakan poin cerita. Sprint juga tidak boleh dipesan sepenuhnya untuk memungkinkan selip dan tugas penting lainnya yang muncul.

Seharusnya tidak hanya ada satu orang di tim Anda dan saya ragu ada sebenarnya. "Tim" di SCRUM bukan hanya pengembang. Apakah Anda perwakilan pelanggan, master scrum, pengembang, dll ...? Apakah Anda benar-benar satu-satunya orang yang melakukan sesuatu yang terkait dengan produk ini, membuat keputusan tentang hal itu, atau mencoba untuk menjualnya?

Untuk memperkirakan penelitian, Anda melakukannya sebagai sebuah cerita. Anda membuat cerita khusus untuk, "Penelitian XXX," dan memberikan poin cerita untuk itu (ingat, Anda tidak memperkirakan waktu di sini, tetapi kesulitan). Anda juga harus dapat memperkirakan dengan cukup memadai kesulitan menerapkan beberapa fitur bahkan jika Anda perlu meneliti teknologi. Terkadang fakta terakhir ini mengubah cerita menjadi "kesulitan maksimal".

Tidak, Anda seharusnya tidak bertemu dengan semua pengembang sebagai standup Anda. Anda harus bertemu dengan tim Anda , yang lagi-lagi bukan hanya pengembang.

Semoga berhasil. Semoga kalian mengerti.

Dengan asumsi Anda memiliki pemilik produk dan master scrum (jika tidak maka bukan scrum), scrum dapat bekerja untuk satu tim pria. Artefak scrum (jaminan simpanan, grafik burddown) akan digunakan sama seperti yang digunakan dalam tim multi-orang. Sekarang tentang rapat:

Standup Harian: Anda akan menggunakan standup harian untuk memperbarui semua orang yaitu pemilik produk, scrum master atau siapa pun yang tertarik dengan kemajuan tersebut. Scrum master akan menggunakan pertemuan ini untuk mempelajari segala halangan yang Anda miliki. Pemilik produk dapat membantu Anda dengan ruang lingkup kunjungan kembali jika / saat diperlukan.

Ulasan Sprint: Pada akhir setiap sprint Anda akan menyerahkan peningkatan kerja perangkat lunak Anda kepada pemilik produk atau klien. Jika tujuan sprint adalah untuk mempelajari "sesuatu", Anda akan mendemonstrasikan PoC yang dapat digunakan oleh manajemen (yaitu umumnya klien untuk PoC).