Pasangkan Pemrograman dengan Scrum


10

Saya berada di tim yang saat ini menggunakan Scrum, dan kami sedang mempertimbangkan untuk menambahkan pemrograman pasangan untuk membantu meningkatkan keterampilan lintas-fungsional tim, serta membantu mengurangi cacat dengan filosofi "dua kepala lebih baik dari satu".

Di tim kami, setiap anggota tim biasanya mendaftar untuk beban kerja penuh selama perencanaan sprint (dengan "penuh" menjadi angka yang kurang dari 40 jam seminggu, memungkinkan untuk rapat, kolaborasi, dll.), Dengan satu pemilik khusus untuk setiap tugas. Saya percaya ini cukup umum di tim Scrum tetapi mungkin belum tentu sesuai dengan buku.

Secara khusus, saya ingin menghindari situasi di mana anggota tim ragu-ragu untuk berpasangan karena mereka memiliki tugas mereka sendiri untuk dikerjakan, yang saya khawatir kemungkinan akan terjadi jika tim hanya mengatur diri sendiri tanpa waktu yang ditentukan untuk pemasangan. .

Mengingat ini, apa cara terbaik untuk memperhitungkan upaya / jam / poin cerita dalam skenario penyandingan, untuk memastikan kami telah mengalokasikan waktu yang tepat untuk penyandingan?

Beberapa opsi yang dipertimbangkan adalah:

  1. Izinkan dua orang mendaftar untuk setiap tugas dan (kira-kira) menggandakan jumlah jam yang diperkirakan
  2. Hanya anggota tim "hands on keyboard" yang mendaftar untuk setiap tugas, yang diperkirakan berdasarkan perkiraan jam orang tersebut. Siapa pun di tim yang akan mendukung pemasangan akan mendaftar lebih sedikit tugas dalam sprint untuk memberikan waktu untuk mendukung pemasangan.

Jawaban:


4

Opsi paling umum yang saya lihat ketika pemrograman pasangan digunakan dalam scrum adalah untuk menggandakan estimasi pengembangan.

Artinya, jika tugas diperkirakan memakan waktu 3 jam untuk satu orang, waktu yang dialokasikan akan menjadi 6 jam untuk pasangan.

Ganti jam untuk poin jika itu membuat Anda merasa lebih bersih;)


Terima kasih Oded. Jawaban ini paling ringkas menjawab pertanyaan spesifik saya. Namun, terima kasih banyak kepada DXM yang membantu mengidentifikasi akar permasalahan, yang lebih banyak terkait orang daripada proses. Saya berharap dapat menerima lebih dari satu jawaban.
Cliff

15

Saya pikir orang lain sudah memberikan jawaban yang baik tetapi saya akan menambahkan saya hanya karena saya pikir tim Anda baru saja beralih ke Scrum dan sekarang kalian berada di posisi yang sangat mirip dengan kami ketika kami mulai.

Pertama, perkenalan kami dengan Agile dan lebih spesifiknya Scrum tidak terlalu mulus. Pada dasarnya manajemen turun dan berkata, mulai hari ini Anda akan melakukan Scrum dan ini adalah proses yang Anda semua akan ikuti. Begitu banyak untuk Orang - orang di Atas Proses .

Proses yang awalnya kami ikuti (secara membabi buta, saya dapat menambahkan) berakhir sangat mirip dengan bagaimana Anda menggambarkan. Orang-orang mendapatkan tugas yang ditugaskan, semua orang dipesan dan kita semua kembali ke meja kami dan pergi. Kemudian kami mengadakan pertemuan stand-up yang membosankan setiap hari.

Kunci untuk menyadari adalah bahwa Agile, dan Scrum termasuk, sebenarnya tentang orang. Ketika tim masuk ke perencanaan iterasi, jangan biarkan Scrum master Anda (yang mungkin manajer Anda) untuk memberi Anda jam, cerita dan tugas. Benar-benar HINGGA TIM. Saya pikir bagi banyak orang ini adalah konsep yang sangat sulit untuk dilalui karena selama bertahun-tahun sebelumnya mereka datang untuk bekerja dan mereka akan memiliki bos (manajer, pimpinan teknis ...) yang hanya akan menugaskan pekerjaan. Mereka menyelam ke Scrum tetapi semua orang (termasuk master scrum sendiri) terus beroperasi dalam mode yang sama.

Suatu hari, Anda akan muak dengan ini, jadi Anda akan mulai membaca buku, blog, dan terus mengajukan pertanyaan seperti ini di pertukaran tumpukan. Kesadaran yang akan Anda dapatkan adalah bahwa Anda sebagai pengembang dan rekan tim Anda harus menjadi kekuatan pendorong di belakang komitmen untuk bercerita dan menugaskan tugas. Jika kalian merasa akan mendapat manfaat dari pemrograman berpasangan, tentu saja buatlah 2 tugas untuk masing-masing insinyur dan tetapkan jam keduanya. Satu-satunya hal yang harus dilakukan oleh scrum master adalah mengukur kecepatan terhadap cerita lengkap yang Anda sampaikan SEBAGAI TEAM dalam iterasi sebelumnya.

Juga hal lain yang mengganggu saya adalah bagaimana orang-orang diberitahu bahwa kapasitas mereka SELALU 75% dari total jam, jadi itulah yang mereka komit dan kemudian untuk seluruh durasi iterasi mereka mengeluh bahwa a) mereka tidak bisa membantu Anda atau b) mereka tidak dapat melakukan hal yang benar karena mereka terlalu banyak ditugaskan. Orang tidak boleh diberi tahu berapa jam untuk berkomitmen dan mereka tentu harus mendorong kembali jika scrum master mencoba menarik sesuatu seperti ini! Setiap orang harus berkomitmen untuk apa yang mereka sukai. Misalnya, saya seorang pemimpin tim dan sering kali saya berakhir di diskusi desain acak yang tidak direncanakan, atau membantu seseorang dengan kode, atau memecahkan masalah hal-hal aneh, sehingga kapasitas saya tidak pernah di atas 50%.

Butuh siklus rilis tim 4 kami untuk belajar untuk tidak melakukan hal-hal yang baru saja saya sebutkan dan meskipun kami sudah benar-benar membaik, jika Anda bertanya kepada para ahli, kami bahkan tidak gesit. Jadi masih banyak pembelajaran yang harus dilakukan.

Pembaruan 1: Tanggapan untuk komentar Cliff Nah Anda menawarkan telinga Anda jadi ini dia ...

Anda benar, perubahan budaya adalah kunci, tetapi perubahan ini tidak perlu terjadi di tingkat eksekutif. Manajer grup Anda sendiri dapat mengubah budaya dalam tim Anda dan mengisolasi kalian dari BS korporat yang harus ia tangani. Apa yang Anda gambarkan adalah PERSIS kami tentang dari 2007 hingga 2010. Tim kami (dan tim lain juga) menjatuhkan rilis setelah rilis. Dalam salah satu rilis menggunakan "proses untuk menjadi gesit" manajemen kami berhasil memiliki 9 orang menghasilkan pekerjaan yang biasanya akan dilakukan oleh satu orang dan kami butuh waktu dua kali lipat. Saya memiliki begitu banyak waktu luang, sehingga saya bahkan memperbarui resume saya.

Kemudian, saya berbicara dengan bos saya dan menjelaskan semua hal ini kepadanya betapa lincahnya orang dan bahwa jika Anda ingin kami peduli dengan produk, mari kita membuat keputusan yang memengaruhi cara kami bekerja dan mengirimkan produk. Saya pikir dia memutuskan untuk menjadikannya percobaan, dia membuat setiap perubahan yang kita ... yah, kebanyakan saya sendiri, tapi saya banyak berbicara dengan tim, karenanya kapasitas 50% :) ... diusulkan. Mungkin saja dia berpikir bahwa jika dia melakukan semua perubahan yang kita minta dan kita masih gagal, dia akan kembali dengan kemenangan "Sudah kubilang".

Jadi dalam 12 bulan terakhir, kami telah menghilangkan begitu banyak "bodoh" itu bahkan tidak lucu. Pertemuan kami sebenarnya masuk akal sekarang karena kami bekerja bersama, bukan sendirian. Kami masih memiliki kepemilikan (setidaknya untuk saat ini) dari bagian-bagian tertentu dari produk, tetapi kami juga sangat sering berpapasan dengan kode masing-masing. Kami terus-menerus melakukan tinjauan kode sehingga tidak hanya anggota tim yang belajar kode lain, tetapi mereka juga belajar teknik pengkodean dan desain yang lebih baik. Kami telah membagi tim monolitik, raksasa "gesit" menjadi 3 tim yang berbeda sehingga perencanaan dan pertemuan lainnya jauh lebih singkat dan orang-orang benar-benar peduli tentang mereka karena mereka tidak duduk dan mendengarkan hal-hal yang tidak mereka pedulikan. SAYA' Saya pernah melihat malam ketika 4 dari 5 orang kami (salah satu tim) akan online pukul 11 ​​malam dan tidak ada yang mengatakan kepada kami bahwa kami harus bekerja keras atau pernah menekan kami untuk bekerja lebih dari 40 jam. Orang yang tidak peduli setengah tahun yang lalu, tiba-tiba terlibat dan bersemangat dengan pekerjaan yang mereka lakukan. Dan yang diperlukan oleh manajer kami hanyalah berkata, "kalian memutuskan apa yang benar dan melakukan apa yang perlu Anda lakukan dan saya akan menjauhkan BS perusahaan dari tim sebanyak yang saya bisa."

Ini dimulai sebagai percobaan (kecurigaan saya, dia tidak pernah mengatakan itu kepada saya), tetapi sekarang grup kami lebih baik dibandingkan dengan kelompok pengembangan lain di departemen dan kami bahkan memiliki pengembang lain yang sekarang mencoba untuk datang dan bergabung dengan kami.

Rintangan terbesar bagi kami sejak perubahan ini terjadi (dan masih menjadi masalah saat ini) adalah kenyataan bahwa para insinyur di lingkungan perusahaan yang normal seperti tikus percobaan dalam sangkar. Bahkan ketika manajer Anda memutuskan untuk benar-benar "gesit" dan menghilangkan kandang, semua orang telah berada di kandang itu begitu lama, mereka bahkan tidak menyadari bahwa mereka bebas. Begitu pun dengan semua kebebasan, mereka terus bertindak seolah-olah mereka masih terkekang. Saya pikir apa yang akan membantu adalah memiliki setidaknya beberapa orang dalam tim (seperti Anda), yang pergi ke luar batas kelompok dan mencari cara yang lebih baik dalam melakukan sesuatu. Kemudian kembali ke kelompok itu dan aduk sedikit.

Dalam kasus Anda, mungkin pemrograman berpasangan bukan solusi jika Anda mencari kekuatan eksternal lain untuk turun ke tim dan memberi tahu mereka cara bekerja. Alih-alih, membuang aturan, duduk bersama mereka, tanpa manajemen, dan bertanya kepada mereka apa yang ingin mereka lakukan? Apa yang akan membuat mereka bahagia? Produktif? Identifikasi masalah terbesar dan tanyakan kepada TEAM apa solusi yang menurut mereka seharusnya.


Saya sangat setuju. Sebagian dari masalahnya adalah bahwa filosofi Agile tidak tertanam dengan baik dalam budaya pembangunan, dan kami mencoba untuk memperbaikinya dengan proses, di mana idealnya itu harus diperbaiki melalui perubahan budaya. Tanpa pendaftaran tugas, anggota tim baik mengambil sikap "bukan pekerjaan saya" terhadap tugas (untuk satu hal, tim tidak benar-benar lintas fungsional, yang merupakan salah satu alasan kami mencari untuk menerapkan pasangan), atau mereka menjadi mudah terganggu. Hasilnya adalah ketidakseimbangan beban kerja di antara tim. Saya mendengar saran tentang bagaimana kita bisa menyelesaikan masalah ini dengan proses yang lebih sedikit.
Cliff

Terima kasih telah memperbarui. Manajemen sebenarnya sangat mendukung dan tidak membiarkan tim bebas berkuasa menentukan "bagaimana". Tapi saya pikir bagian dari masalah inti adalah bahwa tim tidak memiliki pola pikir lintas fungsional. Sebagai contoh, tim telah menciptakan dinding imajiner un / akuntabilitas berdasarkan keahlian individu. Di satu sisi, anggota tim merasa sangat diberdayakan dan mengambil kepemilikan untuk bagian-bagian fitur yang ada di area fungsional yang ditentukan sendiri, tetapi di sisi lain mereka tidak merasa bertanggung jawab atas bagian-bagian fitur yang tidak berada di area fungsional mereka (" bukan pekerjaan saya ").
Cliff

Kedengarannya seperti sudah mengambil beberapa langkah ke arah yang positif. Jadi sekarang setelah Anda mengidentifikasi area utama untuk perbaikan, sudahkah Anda mempresentasikan ini kepada tim dan meminta mereka untuk mengusulkan solusi? Jika ya, apakah mereka kembali dengan pemrograman berpasangan? Jika ya, maka tentu saja, tetapkan siapa pun yang ingin bekerja bersama untuk cerita yang sama, buat beberapa tugas dan letakkan jam pengkodean di sebelah setiap orang. Jika tidak, pernahkah Anda bertanya kepada mereka mengapa mereka begitu ragu untuk melintasi batas fungsional? Pada akhirnya jika mereka berpikir mereka akan lebih efektif tanpa menyeberang, mungkin solusi nyata ada di tempat lain.
DXM

"Bukan pekerjaanku" berarti "Aku tidak peduli" dan itu adalah masalah terbesarmu. Agile adalah untuk pengembang yang peduli dan yang dapat bertanggung jawab. Tim memiliki tanggung jawab atas produk. Tidak ada "Saya memiliki tanggung jawab untuk satu bagian" = anggota tim harus peduli dengan seluruh produk. Mengapa Anda memiliki area fungsional? Apakah karena produk Anda sangat besar?
Ladislav Mrnka

@LadislavMrnka: Meskipun mungkin ada beberapa orang di tim yang tidak peduli, dan saya pikir itu tidak masalah. Orang-orang itu akan menjadi bagal yang berfungsi untuk pekerjaan bug dan omong kosong karena keputusan besar, arah produk, arsitektur dan desain akan melewati mereka. Tetapi Anda masih membutuhkan seseorang untuk menangani dukungan teknis :). Saya pikir sebagian besar dari kita peduli dengan apa yang kita lakukan. Dan jika seluruh tim memiliki sikap "bukan pekerjaan saya", saya pikir akar penyebabnya adalah beberapa faktor eksternal lain yang perlu dipilih dan dihilangkan. Tanpa melakukan itu, mustahil untuk memberi mandat kepada tim "Anda harus peduli".
DXM

2

Scrum tidak mengamanatkan bahwa tugas-tugas ditugaskan kepada individu - jauh dari itu. Tanggung jawab atas tugas yang harus diselesaikan menjadi tanggung jawab Tim secara keseluruhan. Jika tim ingin melakukan pemrograman berpasangan, di mana masing-masing pasangan mengambil tugas, mereka tentu harus melakukannya.

Dari Panduan Scrum :

Tim Pengembangan biasanya memulai dengan merancang sistem dan pekerjaan yang diperlukan untuk mengubah Product Backlog menjadi peningkatan produk yang berfungsi. Pekerjaan mungkin dari berbagai ukuran, atau perkiraan upaya. Namun, cukup banyak pekerjaan yang direncanakan selama pertemuan Perencanaan Sprint untuk Tim Pengembangan untuk memperkirakan apa yang menurutnya dapat dilakukan dalam Sprint mendatang. Pekerjaan yang direncanakan untuk hari-hari pertama Sprint oleh Tim Pengembangan didekomposisi menjadi unit satu hari atau kurang pada akhir pertemuan ini. Tim Pengembangan mengatur diri untuk melakukan pekerjaan dalam Sprint Backlog , baik selama Pertemuan Perencanaan Sprint dan sesuai kebutuhan sepanjang Sprint.


1
Menarik. Saya memiliki Panduan Scrum Maret 2009 dan mereka benar-benar mengubah kutipan itu. Dulu: " Tim mengatur sendiri untuk menugaskan dan melakukan pekerjaan di Sprint Backlog, baik selama pertemuan Perencanaan Sprint atau tepat waktu selama Sprint."
Cliff

Interpretasi kami adalah untuk selalu membuat set awal estimasi tugas untuk setiap item backlog dan menugaskan mereka untuk anggota tim individu selama perencanaan sprint. Beberapa manfaatnya adalah membantu kita menyeimbangkan beban kerja secara efektif di antara anggota tim selama perencanaan, dan dengan pemilik yang ditugaskan untuk setiap tugas, membuatnya lebih mudah untuk memastikan kita tidak melewatkan apa pun. Ini juga membantu dalam menangkap metrik.
Cliff

@ Cliff - Jika itu yang Anda inginkan, tidak apa-apa. Yang saya katakan adalah Scrum tidak mengatakan Anda harus melakukannya dengan cara itu. Jika Anda lebih suka menetapkan item berpasangan (yang biasanya kita lakukan sebagai asuransi hit-by-a-bus), itu juga baik-baik saja, dan Anda bisa dengan mudah menghitung metrik berdasarkan pasangan.
Matthew Flynn

0

Menugaskan tugas pada rapat perencanaan adalah apa yang bertentangan dengan keputusan waktu dan memberdayakan tim. Ini juga bertentangan dengan kelincahan sprint karena sejak hari pertama dalam sprint setiap pengembang telah tepat menyelaraskan apa yang harus ia lakukan. Ini juga berarti bahwa setiap tugas harus diperkirakan dengan sangat benar yang hampir tidak pernah terjadi.

Saya memperkirakan tugas itu mubazir. Anda telah berkomitmen untuk mengatur cerita dan merencanakan pertemuan 2 adalah waktu yang cukup untuk membagi cerita-cerita itu menjadi tugas dan membuat kartu untuk tugas-tugas tersebut (atau mengisinya ke beberapa sistem). Tidak ada cukup waktu untuk memperkirakan setiap tugas dan estimasi ini tidak boleh menghabiskan waktu untuk pengembangan nyata.

Mengapa? Estimasi adalah sampah. Bagaimana bisa menjadi sampah? Karena melakukan lebih banyak estimasi tidak akan membawa lebih banyak nilai bisnis = itu adalah sampah dan harus dikurangi seminimal mungkin. Minimal adalah memperkirakan / mengukur cerita yang membantu Anda melakukan komitmen. Setelah Anda melakukan komitmen Anda tidak perlu estimasi lain. Anda hanya tahu bahwa Anda memiliki tanggal tetap untuk memberikan sesuatu yang telah Anda lakukan. Anda bisa menyampaikan cerita yang berkomitmen atau tidak. Memperkirakan tugas tidak akan membantu Anda dalam pengiriman itu.

Melewati estimasi tugas sama sekali tidak akan memengaruhi visibilitas ke dalam kemajuan sprint karena satu-satunya pengukuran nyata dari kemajuan adalah jumlah cerita yang telah selesai (poin cerita) dan yang masih dapat ditunjukkan dalam grafik sprint burn down.

Hanya untuk memperjelasnya. Komitmen berarti = Kami akan melakukannya . Bukan kita akan berusaha melakukannya atau yang lainnya. Ya, Anda bisa gagal menyampaikan apa yang telah Anda komit tetapi komitmen Anda harus didasarkan pada keyakinan Anda bahwa dengan pengetahuan Anda saat ini, Anda akan memberikan cerita yang dipilih. Jika Anda memiliki keyakinan ini, Anda tidak perlu estimasi lain.

Saya selalu menggunakan Scrum dalam cara di mana pengembang memilih tugas baru setelah dia menyelesaikan yang terakhir. Pengembang biasanya mengatakan yang mana yang akan mereka pilih pada pertemuan stand-up. Umumnya tidak ada aturan tugas yang harus ia pilih. Terserah tim swadaya dan diskusi antara anggota tim (di luar pertemuan stand-up). Itu menunda keputusan ke titik terbaru yang memungkinkan di mana Anda dapat bereaksi terhadap beberapa perubahan dan masalah tanpa mempengaruhi rencana imajiner Anda. Tugas itu sendiri bahkan dapat mengubah pemilik jika seseorang memiliki beberapa masalah untuk menyelesaikannya - atau tugas tersebut dapat dikembangkan berpasangan.

Bagaimana pemrograman pasangan bisa terlibat dalam hal ini? Dengan mudah. Tim melakukan komitmen dan tim harus membuatnya dalam cara memberikan ruang bagi semua teknik pengembangan yang dibutuhkan untuk menghasilkan peningkatan kerja produk. Apakah Anda memperkirakan tugas atau pengembangan tugas dan pengujian tugas? Pendekatan yang terakhir benar-benar salah. Pengujian adalah bagian dari pengembangan dan dengan cara yang sama tinjauan kode atau pemasangan adalah bagian dari pengembangan jika diperlukan.

Melakukan pemrograman pasangan harus menghasilkan penyelesaian tugas lebih cepat dengan jumlah bug yang lebih kecil dan kualitas kode yang lebih baik. Ini tidak akan dua kali lebih cepat sehingga masih ada beberapa overhead tetapi dampak nyata pada komitmen yang disebabkan oleh pasangan sesekali harus sangat kecil. Ini bukan kasus untuk pendampingan atau pengajaran. Jika Anda memiliki pengembang seperti itu yang perlu dibimbing atau diajarkan, Anda tidak boleh merencanakan kapasitasnya sama sekali untuk lari cepat di mana ia mempelajari basis kode produk atau teknologi tertentu.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.