Keuntungan Scrum untuk pengembang sendiri? [Tutup]

Scrum menjadi metodologi manajemen proyek, bagaimana Anda akan 'menjualnya' kepada pengembang dalam tim yang cukup senang dengan situasi saat ini?

Tampaknya mudah bagi saya untuk menjelaskan kepada Manajer Produk kami bagaimana Scrum akan memungkinkan dia untuk mendapatkan rilis reguler, untuk mengubah persyaratan, dan membuat tim untuk fokus pada cerita prioritas tinggi terlebih dahulu. Saya merasa mudah untuk menjelaskan apa yang membawa TDD atau Integrasi Berkelanjutan dalam kehidupan sehari-hari pengembang.

Tetapi bagaimana pengembang dapat diyakinkan untuk merangkul Scrum? Bagaimana Scrum membuat hidup mereka lebih mudah?

Scrum akan memberikan lebih banyak visibilitas tentang apa yang sedang terjadi . Manajemen yang buruk, perubahan menit terakhir, tekanan, dan semua hal yang biasanya dihadapi pengembang.

Namun, itu juga akan membawa banyak visibilitas pada penunda, pengembang itikad buruk, individualis gila, ... dengan kata lain, pengembang buruk.

Scrum adalah pedang bermata dua

Scrum akan memberi Anda peluang untuk menyelesaikan masalah tersebut. Itu sebabnya sangat kuat.

Memecah tujuan besar ("menyelesaikan perangkat lunak") menjadi bagian-bagian kecil - cerita - dan memutuskan mana yang harus dilakukan pada sprint saat ini meningkatkan produktivitas dan mengurangi stres. Ketika Anda tahu secara spesifik apa yang seharusnya Anda lakukan sekarang , ada sedikit yang perlu ditekankan, dan Anda bisa fokus mengerjakan bagian kecil itu alih-alih merasa kewalahan oleh keseluruhan yang besar.

Stack Ranks / Backlog menjaga tonggak sejarah dari kematian

Sebagai seorang pengembang, 'pola destruktif' yang paling saya lihat dalam pengembangan perangkat lunak adalah ketika beberapa 'pengontrol eksternal' (misalnya manajemen proyek, manajemen eksekutif) menjadi sangat senang dengan kenyataan bahwa 'fitur favorit' tidak akan berhasil ' tanggal kalender 'dan memerintahkan mars kematian.

Scrum, karena peringkatnya 'fitur-fitur penting' tinggi dalam daftar jaminan membantu pengembang mengelola ketegangan ini secara proaktif dalam dua cara. Pertama, Anda dapat peringkat 'fitur favorit' tinggi di backlog sehingga dia kemungkinan besar akan senang. Kedua, ini memberikan jawaban yang sangat visual dan konkret untuk "karena kami memindahkan 'widget yang berkedip' ke peringkat 1, sangat mungkin bahwa kami tidak akan mendapatkan 'bouncing bunnies' dalam sprint ini karena sekarang berada di peringkat 7. Apakah Anda nyaman dengan pertukaran ini? "

Saya juga menemukan bahwa dengan sprint pendek, 'pengontrol eksternal' kurang kesal dengan menunda pekerjaan. Jika 'widget berkedip' tidak menjadikannya sebagai 'tonggak sejarah 1' dan 'tonggak sejarah 2' tidak berakhir sampai 9 bulan dari sekarang, sponsor 'widget berkedip' menjadi sangat kecewa. Tetapi jika 'widget berkedip' adalah tumpukan peringkat 7 bukan 1 karena memang ada 6 hal penting yang harus dilakukan terlebih dahulu, ini berarti bahwa kita mungkin akan mendapatkannya dalam sprint + 1 atau paling buruk sprint + 2 yang berarti itu akan muncul 12 atau 18 minggu dari sekarang (menggunakan sprint 6 minggu). Dalam pengalaman saya, menunggu 3 bulan adalah 'dapat diterima' untuk yang tidak sabar - selain itu, kembali dalam model 'air terjun' dari tonggak sejarah 3+ bulan,

Akhirnya, jika kita mencapai akhir sprint dan hal-hal memakan waktu lebih lama dari yang diharapkan, itu sangat bagus untuk dapat mendorong backlog item 5-6-7 ke sprint berikutnya dan pastikan kita telah menyelesaikan 1-2-3 -4 dengan kualitas tinggi dan tanpa 70 jam minggu. Bagaimanapun, kami akan memastikan untuk mendapatkan 5-6-7 sprint berikutnya. Sekali lagi, mengingat jangka waktu yang lebih pendek yang terlibat dalam penundaan, 'pengontrol eksternal' umumnya lebih nyaman dengan ini dan tidak bersikeras bahwa kita menyelipkan tonggak sejarah dua minggu dan memesan makan malam setiap malam 'untuk hanya mendorong melalui itu'.

Orang-orang di tim Scrum dapat memutuskan banyak hal sendiri: apa yang akan dilakukan selama sprint berikutnya, bagaimana kita memecahkan cerita ini dalam tugas, siapa yang mengerjakan apa, dll. Ini memberdayakan mereka, dan hampir sama sekali bertentangan dengan mikro -pengelolaan.

Fakta bahwa persyaratan akan berubah diperhitungkan sejak awal. Pengembang tidak perlu membuat spesifikasi terperinci dengan perkiraan yang tepat dan kemudian menghabiskan waktu berminggu-minggu mengembangkan fitur hanya untuk menyadari bahwa pelanggan berubah pikiran begitu dia melihat hasilnya ...

Bagi saya, Anda dapat menetapkan sendiri tugas dari backlog adalah titik penjualan terbesar dari sudut pandang pengembang. Juga, keintiman dengan pelanggan / pemilik produk membantu memahami skema yang lebih besar.

Beberapa hal:

• Membangun poin Xavier tentang persyaratan yang berubah sejak awal - suasana politik yang kurang berkembang ketika semua orang menerima dari awal bahwa beberapa hal tidak akan seperti yang diharapkan klien. Pengiriman dan ulasan cepat akan berarti bahwa biaya mis-komunikasi rendah, dan alih-alih memainkan permainan menyalahkan, para pengembang hanya dapat mengubah hal-hal sehingga mereka berfungsi sesuai harapan klien.

• Poin cerita! Pengembang apa yang tidak suka mendapat poin untuk melakukan hal-hal !!?! Serius, ini lebih baik daripada mendapatkan lencana di SC2 atau Stack Overflow.

Ada beberapa hal yang saya sebagai pengembang suka tentang scrum.

Para pengembang cenderung diberikan lebih banyak informasi di muka. Pemilik produk perlu menjelaskan semua pekerjaan yang akan dilakukan selama sprint berikutnya dengan rincian yang cukup untuk memungkinkan perkiraan yang baik.

Perkiraan tepat waktu berarti bahwa perkiraan tersebut cukup akurat. Setiap orang biasanya memiliki gagasan yang cukup baik tentang apa yang akan selesai dalam sprint. Ini memberikan programer dan manajer proyek alat untuk mendorong kembali terhadap tuntutan yang tidak masuk akal.

Sangat menyenangkan untuk mundur setiap tiga hingga empat minggu dan mengambil napas dan setidaknya memiliki perubahan kecepatan.

Tim yang mengatur diri sendiri, tampaknya memberikan sedikit variasi dalam pekerjaan.

Secara teori setidaknya, selama sprint ada lebih sedikit interupsi dan 'darurat'.

Pertemuan harian memaksa pemrogram untuk mengucapkan beberapa kata setiap hari.

Lebih mudah untuk melihat kemajuan yang dibuat karena cerita secara eksplisit selesai dan ditinjau pada akhir setiap sprint.

Grafik burn down adalah alat yang cukup efektif untuk melacak kemajuan.

Keuntungan bagi pengembang adalah umpan balik awal (dari klien, tester, pemilik Produk, dll).

Juga sebagai pengembang, saya selalu tertarik melakukan hal-hal selangkah demi selangkah tanpa gangguan. Scrum menyediakan ini.

PS: scrum bukan metodologi tapi kerangka.