Kami memiliki tim SCRUM "khas" dan kami berkomitmen untuk bekerja untuk sprint, dan juga menjaga jaminan simpanan. Baru-baru ini kami mengalami masalah dalam upaya mengintegrasikan / menangani pekerjaan yang dilakukan oleh pengembang yang terlalu tinggi di luar pekerjaan band (memilih untuk bekerja di luar jam kerja / sprint normal).

Sebagai contoh, jika tim mengambil 50 poin pekerjaan, katakanlah mereka akan menyelesaikan semua pekerjaan itu dalam kerangka SCRUM pada akhir sprint dan mereka dan perusahaan bahagia. Salah satu anggota tim memutuskan untuk bekerja sendiri, pada item jaminan, pada waktu luang mereka sendiri. Mereka tidak memeriksa dalam pekerjaan ini, tetapi malah menyimpannya (kami menggunakan TFS dan itu dalam rak).

Bagaimana cara mengatasinya? Beberapa masalah ..

• Selama sprint berikutnya, anggota tim ini mengatakan pekerjaan pemrograman telah dilakukan 99% dan hanya perlu tinjauan dan pengujian kode. Bagaimana Anda menangani hal ini dalam metodologi SCRUM dan gesit?
• Pengembang lain mengeluh tentang tidak terlibat dalam keputusan desain yang terkait dengan cerita-cerita ini, karena pekerjaan dilakukan di luar band.
• Pemilik produk kami tergoda untuk melakukan pekerjaan "gratis" ini dan anggota yang berprestasi lebih mungkin melakukan ini dengan sengaja untuk mendapatkan lebih banyak fitur ke dalam produk yang timnya tidak dapat capai dalam sprint. Ada pandangan bahwa ini melanggar "proses". Jelas pekerjaan QA, UI dan dokumentasi masih perlu dilakukan pada pekerjaan ini.

Saya melihat banyak diskusi tentang tidak memaksa tim SCRUM untuk bekerja lembur, tetapi bagaimana dengan anggota tim yang bekerja di atas dan melampaui harapan yang diajukan selama perencanaan dan pelaksanaan sprint? Saya akan ragu-ragu untuk memerintah orang ini dan mengatakan Anda tidak dapat bekerja ekstra (tentu saja membakar), tetapi pada saat yang sama tampaknya menyebabkan beberapa masalah dengan anggota tim tertentu (tetapi tidak semua).

Bagaimana cara mengintegrasikan pekerjaan yang dilakukan oleh anggota berprestasi ke dalam SCRUM dan proses tangkas untuk pengembangan perangkat lunak?

Baiklah, jadi seseorang dengan antusias menulis kode hebat yang perlu dilakukan, hanya saja tidak teratur. Dengan semua penekanan karena:

BIARKAN MEREKA

Ini menyebabkan beberapa komplikasi dalam sprint scrum Anda. Apakah itu penting dalam skema besar hal? Jika dia mencapai apa yang seharusnya, maka biarkan dia melanjutkan dan membangun hal-hal besar untuk Anda.

Saya tahu beberapa programmer luar biasa yang telah meninggalkan perusahaan karena mereka tidak membiarkan programmer di luar kendala sistem buatan seperti Scrum (saya sendiri meninggalkan pekerjaan terakhir saya setelah diperlakukan seperti tidak lebih dari QA yang dimuliakan). Jika ada keluhan dari pengembang lain tentang input (keluhan yang benar-benar valid, saya dapat menambahkan), mungkin lebih baik untuk memperkenalkan program "20% waktu" untuk membiarkannya (dan lainnya) melakukan apa yang mereka lakukan dengan interferensi minimal.

Alih-alih cerita masa depan (yang mungkin memerlukan masukan dari orang lain), biarkan percobaan pengembang dengan teknologi atau fitur baru. Anda mungkin menemukan peluang baru yang hebat yang tidak akan pernah dieksplorasi sebaliknya. Saya yakin pengembang ini memiliki beberapa hal yang ingin mereka coba jika Anda membiarkannya.

Ada dua hal yang saya pikir harus Anda pertimbangkan di sini:

1. Jangan menghalangi aliran kreatif seseorang.
   • Jika seorang dev ingin bekerja di luar jam kerja, maka biarkan mereka.
2. Jangan membuat karya untuk orang lain.
   • Jika seorang dev ingin melakukan pekerjaan di luar jam kerja, pasti lebih baik tidak menciptakan lebih banyak pekerjaan untuk orang lain .

Poin 2 kemungkinan adalah apa yang dikhawatirkan oleh pengembang lain.

Seperti yang Anda sebutkan, mereka tidak suka fakta bahwa kode ditulis tanpa masukan seluruh tim. Ini mungkin karena, dalam hal desain, akhirnya menjadi lebih rendah. Dan kode dengan desain inferior memiliki cara menginfeksi kode lain di sekitarnya.

Jadi, apa yang bisa kamu lakukan?

Biarkan kode dev yang ambisius untuk isi hatinya, tetapi membuatnya jelas tidak ada alasan untuk menganggap kode ekstrakurikulernya akan digunakan .

Bagaimanapun, ia adalah bagian dari sebuah tim, dan karenanya tim harus terlibat dalam bagaimana semua kode dikembangkan.

Namun, jika karyanya bagus dan sesuai dengan desain yang disetujui tim maka ia akan dapat menggunakan banyak dari apa yang sudah ditulisnya (bonus!). Jika tidak, itu akan memaksanya untuk lebih memikirkan desainnya saat berikutnya ia memutuskan untuk memulai.

Dengan cara ini, tidak ada yang diberitahu TIDAK , dan tidak ada yang membuat pekerjaan ekstra untuk mereka.

Bawa dia kembali ke tim

Anda harus bertanya pada diri sendiri (atau tim yang lebih baik, termasuk yang berprestasi):

Mengapa perilaku ini menjadi masalah?

Karena Anda memberi label pengembang sebagai orang yang berprestasi lebih tinggi, saya kira pekerjaannya berkualitas baik, jadi saya akan menganggap ini bukan masalah.

Tapi sepertinya ada masalah lain:

• Pekerjaan tambahan tidak diuji dengan benar
• itu tidak didokumentasikan
• anggota tim lainnya tidak mengetahuinya
• pengembang memutuskan hal berikutnya untuk diterapkan, bukan PO
• pengembang tidak mendapatkan umpan balik dari berbagai pemangku kepentingan untuk dimasukkan dalam karyanya.

Mengapa saya akan apa adanya adalah:

Mengapa pengembang melakukannya?

• Jika pada akhir sprint tidak cukup banyak pekerjaan yang tersisa, harus ada keputusan tim (termasuk PO) tentang apa yang harus ditangani selanjutnya. Mengapa pengembang menghindari keputusan ini?

Setelah Anda menjawab pertanyaan-pertanyaan ini, Anda dapat mulai menjawab pertanyaan Anda sendiri:

• jika itu bukan masalah, biarkan dia melakukan pekerjaannya. Meskipun beberapa orang memperlakukan SCRUM sebagai sebuah agama, seharusnya tidak seperti ini.
• Kemungkinan besar Anda memiliki dua masalah dalam tim: yang disebabkan oleh pengembang nakal dan yang memicu perilaku pengembang nakal. Temukan cara untuk menyelesaikannya nanti dan yang pertama akan hilang.

Sama seperti saya menyukai gagasan bahwa menambahkan pekerjaan gratis ke dalam campuran adalah hal yang baik, ini bukan pekerjaan gratis - tidak kecuali jika pengembang tunggal juga merupakan penguji, dan QA serta pembuatnya dan perancang serta yang lainnya. Jika karyanya dapat dimasukkan ke dalam sprint berikutnya tanpa dampak apa pun, maka .. lakukanlah. Tapi saya pikir itu tidak pernah terjadi. Paling tidak, semua orang harus memahami apa yang telah dia lakukan dan apa dampaknya pada mereka. Mereka harus memahami bahwa perubahannya sedang dalam dan jadi tidak menduplikasi usahanya - sulit untuk memberitahu seseorang bahwa mereka telah bekerja keras pada tugas hanya untuk menemukan pria nakal melakukannya minggu lalu.

Anda bekerja di lingkungan yang gesit, dan satu hal yang saya tahu tentang gesit adalah bahwa ia dirancang untuk bekerja untuk Anda, bukan melawan Anda. Jadi, Anda perlu mengubah cara Anda bekerja untuk memungkinkan kegiatan ekstra kurikuler semacam ini terjadi. Itu berarti mendapatkan masukan dan persetujuan semua orang, Anda tidak dapat melakukan ini tanpa persetujuan mereka. Sangat vital. Jika tim tidak menyukainya, maka lelaki nakal itu berhenti melakukannya. Akhir dari. Bukan satu orang melakukan apa yang dia suka, tidak peduli seberapa bagus pekerjaannya, itu adalah upaya tim sepanjang jalan. Tim yang didahulukan.

Jadi, Anda perlu duduk semua orang di pertemuan perencanaan berikutnya dan membahas ini, semua anggota tim perlu memutuskan untuk mengizinkannya, atau mengubah proses Anda untuk mengelola kegiatan semacam ini dengan lebih baik.

Mungkin Anda akan mendapatkan solusi di mana semua orang mengerjakan proyek favorit mereka dan membawanya ke meja (Anda dapat membayangkan kekacauan pengiriman Anda yang akan menyebabkan :) yang menyoroti masalah dengan itu di tempat pertama) atau Anda dapat mengamanatkan area di mana setiap pengembang memiliki otomasi untuk mengembangkan solusi apa pun yang mereka sukai yang merupakan 'kontribusi' yang serupa dengan berapa banyak proyek sumber terbuka yang bekerja, atau Anda dapat memberi setiap orang waktu luang untuk bereksperimen (waktu 20% yang lama).

Apakah pengembang ini menulis tes dan kode bersih / padat atau dia hanya mendorong apa pun yang bisa dia lakukan dengan cepat? Saya pribadi tidak akan mengizinkan siapa pun bekerja di luar jam yang ditentukan karena akan mengacaukan perkiraan Anda dan ketika Anda menunjukkan masalah lain terjadi.

Namun, Anda tidak boleh kaku dalam proses Anda. Scrum hanyalah kerangka kerja sehingga Anda selalu dapat menyesuaikan proses untuk memasukkan waktu tambahan (tapi sekali lagi ini sulit untuk merencanakan apa yang mungkin dilakukan seseorang).

Anda juga bisa memintanya untuk mengerjakan hal-hal selain proyek. Melihat teknologi baru atau membuat pelatihan tentang hal-hal yang dia lakukan berbeda. Intinya adalah apa pun yang dilakukan di luar jadwal yang Anda rencanakan akan menghancurkan perkiraan Anda dan saya tidak akan membiarkan itu terjadi.

kami menghadapi hal yang sama juga, pada dasarnya kami melakukan sesuatu seperti 20 poin tetapi pada minggu lalu atau bahkan di tengah sprint kami kehabisan tugas pengkodean namun karena Pengujian dan proses selanjutnya kami tidak mengambil risiko untuk memilih PBI lain, Jadi apa Programmer lakukan adalah untuk melihat ke dalam simpanan dan mulai mengembangkan PBI masa depan (diam-diam!) dan memberi tahu seluruh tim dalam perencanaan bahwa PBI siap untuk meninjau dan menguji kode! seperti yang kamu katakan.

Ini benar-benar menimbulkan kekhawatiran dari PO kami bahwa tampaknya kami mampu lebih tetapi kami tidak sepenuhnya memanfaatkan potensi tim kami, yang sebagian benar tetapi ya, mungkin programmer kami bisa berbuat lebih banyak tetapi penguji kami tidak bisa menindaklanjuti kecepatan itu jadi ada risiko gagal lari. setelah memikirkan masalah ini, kami menemukan bahwa kami perlu mengubah pandangan kami tentang scrum dan masalah utamanya adalah bahwa orang tidak ingin mengambil risiko itu karena kami Komit PBI sehingga tim tidak merasa senang mengambil risiko memetik itu. PBI baru jika kami memiliki programmer gratis.

Cukup kita mulai Prakiraan PBI daripada komitmen make. Peramalan pada dasarnya berarti kita memilih 25 poin pada perencanaan dan mulai sprint, Dan ketika programmer bebas di tengah sprint, karena tidak ada lagi tugas pengkodean maka dia memilih salah satu PBI masa depan dan memasukkannya ke Sprint Saat ini dan mulai bekerja di atasnya, jika PBI dapat melewati semua proses (pengujian, penggabungan dan lain-lain) dalam sprint yang sama, itu adalah poin bonus bagi tim jika BUKAN kita tidak gagal berlari karena PBI itu dan hanya meneruskan pekerjaan yang tersisa ( menguji atau meging atau lain-lain) ke sprint berikutnya dan ulang poker untuk pekerjaan yang tersisa. Jadi itu bisa dilakukan dalam dua sprint berbeda dalam skenario terburuk. Saya tahu ini mungkin terdengar seperti Scrumbut tetapi sebenarnya meningkatkan cara kami bekerja. Saya hanya bisa meringkas manfaatnya seperti di bawah ini:

• Ini mengalahkan fobia kegagalan sprint karena mengambil risiko mengambil lebih banyak PBI
• Itu membuat kerja ekstra dari programmer dan tim Anda terlihat
• Ini meningkatkan kecepatan tim Anda

Namun mungkin untuk tim dengan pengalaman yang kurang, mungkin itu mengurangi dorongan yang diberikan komitmen kepada tim untuk menyelesaikan PBI

Beberapa jawaban lain menyatakan bahwa pengembang yang "terlalu berprestasi" adalah "jahat" atau "melanggar prinsip-prinsip Scrum". Ini tidak benar dan pengembang ini harus didorong (walaupun Anda tidak boleh meminta orang untuk mengerjakan sesuatu yang spesifik dalam waktu tambahan ini, tetapi Anda bisa membuat saran dan membantu mengembangkan ide).

Tidak ada dalam Scrum untuk menentukan bagaimana orang bekerja dan apa pun yang dia lakukan secara alami akan dimasukkan ke dalam kecepatan tim.

Karyanya harus dibawa ke tumpukan produk dan diperkirakan dalam pertemuan perencanaan berikutnya. Jika Anda tidak dapat memprediksi upaya yang tersisa secara langsung, Anda harus memberi waktu pada kotak waktu sprint untuk mengetahuinya (yaitu, Spike).

Menariknya Anda menggambarkan pengembang sebagai "terlalu berprestasi", saya menganggap ini berarti ia menambahkan nilai lebih banyak daripada anggota tim lainnya.

Kesulitan melakukan pekerjaan ekstra menciptakan menyiratkan ada sesuatu yang sub-optimal (atau mungkin bahkan disfungsional) di tim Anda.

Jika ini masalahnya, Anda harus bertanya pada diri sendiri mengapa ia mencapai begitu banyak, dengan mungkin hanya sedikit usaha ekstra?

Apakah mungkin bagi Anda untuk memungkinkan anggota tim lainnya mencapai lebih banyak?

Saya telah melihat situasi di mana tim dikelola secara mikro, berpotensi atas cerita pengguna yang bersifat preskriptif, definisi selesai, yang akhirnya menjadi gerah bagi para pengembang. Apakah pengembang ini melakukan pekerjaan yang dia inginkan? Saya berasumsi dia membuat keputusan yang baik. Apakah bekerja dengan cara ini di minggu kerja akan membantu anggota tim lainnya juga?

Mintalah mereka juga menjadi guru

Sangat menyenangkan bahwa Anda memiliki pengembang bintang dengan keterampilan terbaik dan tercanggih dalam grup. Saya akan memuji dan memuji ini. Seringkali orang seperti itu adalah 'perekat' yang menyatukan organisasi.

Saya akan melihat tantangan sebagai 'bagaimana membuat pengembang yang kurang berpengalaman lebih dekat dengan produktivitas pengembang yang paling maju'.

Salah satu cara yang bagus untuk melakukan ini adalah untuk fokus pada pengembang bintang untuk menghabiskan lebih banyak waktu mengajar, melatih dan membimbing anggota tim yang kurang berpengalaman dan lebih lambat. Saya pertama kali akan membahas ini dalam 1-ke-1 dengan pengembang bintang sehingga mereka tahu apa yang Anda lakukan dan mengapa. Lain bijaksana mungkin dipandang dengan kecurigaan sebagai agenda tersembunyi / manajemen yang buruk

Ketika Anda melakukan standup, sekali atau dua kali sehari, jika orang ini kehabisan pekerjaan dan orang lain masih melakukan tugas, lihat memprogram-berpasangan sehingga ia dapat berpasangan dengan anggota junior dan memberikan pengetahuan dan pengalaman yang hebat. Pastikan untuk mengajukan pertanyaan "apakah ada yang butuh bantuan? Apakah ada yang mencari pasangan?"

Anda juga dapat menemukan beberapa pekerjaan 'sampingan' untuk pengembang terbaik ketika mereka tidak memiliki pekerjaan, seperti meningkatkan perangkat yang digunakan oleh semua orang, menjalankan kelompok diskusi klub buku teknis atau terlibat dalam proyek organisasi lainnya.

Saya akan menjawab pertanyaan yang berbeda. Saya pikir bagaimana menghadapi situasi ini di Scrum benar-benar tidak penting. Scrum lebih seperti pedoman. Jika Anda ingin ini terjadi, temukan cara sederhana untuk mengadaptasi proses Anda seperti mengasumsikan pekerjaan sudah dilakukan.

Pertanyaan sebenarnya adalah apakah Anda ingin dev ini melakukan apa yang dia lakukan. Saya pikir beberapa aspek memainkan peran kunci dalam menjawab pertanyaan itu:

1. Apakah programmer melakukan pekerjaan dengan baik.
2. Apakah semua orang baik-baik saja dengan dia melakukan pekerjaannya sendiri (baik atau buruk). Bagaimanapun, dia menghindari proses desain!
3. Apakah jam ekstra dibayarkan atau tidak.

Semua ini memengaruhi apakah masuk akal bagi produk Anda bahwa ia melakukan apa yang ia lakukan. Sekali lagi, memasukkan keputusan Anda dalam proses desain bukanlah masalah. Bersikaplah fleksibel.

Ini melanggar penyewa Scrum karena tim tidak memutuskan pekerjaan dalam sprint. Ini adalah tim scrum . Tim perlu mendisiplinkan programmer ini jika disiplin ingin diberikan.

Masalah lain yang diciptakannya adalah ia mengacaukan kecepatan tim. Pekerjaan di luar band tidak dihitung terhadap kecepatan dan terbakar. Jadi, ini dari pekerjaan band selesai, tim rata-rata 50 poin dalam kecepatan, tetapi lebih dari 50 poin dilakukan. Pemilik produk akan melihat ini dan menuntut kecepatan lebih tinggi di sprint berikutnya. Kecepatan itu mungkin tidak mungkin.

Tim (bukan PO atau ScrumMaster) perlu mengatasi ini dengan programmer jahat.