Scrum - Pengembang yang Bekerja Di Luar Sprint

12

Tim Scrum

  • 3 x Pengembang
  • 2 x Penguji
  • 1 x Analis Uji Otomasi

Kami bukan tim multi-fungsi karena pengembang tidak menguji dan penguji tidak berkembang. Saya percaya ini adalah akar penyebab masalah ini.

Kami saat ini melakukan sprint dua minggu.

Pada awal sprint, semua orang sibuk, para pengembang memulai pekerjaan pengembangan dan para penguji sedang melakukan persiapan pengujian (menulis kasus pengujian, dll.)

Setelah penguji menyelesaikan persiapan mereka, mereka sekarang menunggu pekerjaan pengembangan selesai ATAU pekerjaan pengembangan selesai dan pengembang menunggu umpan balik / bug.

Para pengembang merasa gatal di sini dan mulai mengerjakan item di backlog yang berada di luar sprint saat ini. Ini telah menciptakan pengaruh yang aneh di mana kami selalu mengembangkan pekerjaan sprint berikutnya dalam sprint saat ini. Bagi saya ini terasa tidak benar.

Dari sudut pandang manajemen, mereka lebih suka para pengembang melakukan pekerjaan daripada duduk di meja mereka tanpa melakukan apa-apa, tetapi pada saat yang sama saya merasa bahwa tujuan dan fokus tim scrum harus semata-mata berada pada sprint saat ini. Saya berharap tim kami multi-fungsi tetapi sayangnya itu tidak dapat dicapai. Penguji tidak memiliki keterampilan yang diperlukan untuk melakukan pekerjaan pengembangan dan sebagian besar pengembang berpendapat bahwa pengujian ada di bawah mereka.

Apakah ini dianggap masalah dalam scrum? Apakah ada solusi untuk ini? Apakah scrum hanya bekerja dengan tim multifungsi?

Saya ingin tahu pengalaman orang lain dengan ini jika memungkinkan :)

agile scrum fml
sumber
3
Saya setuju dengan manajemen. Membuat orang duduk-duduk karena periode dua minggu yang sewenang-wenang adalah ide yang buruk. Mungkin tanggung jawab tim Anda terlalu kaku; dalam tim sekecil ini, tidak jarang bagi semua anggota tim untuk "lintas fungsional," memungkinkan mereka untuk melompat di mana diperlukan dalam sprint saat ini.
Robert Harvey
... atau mungkin Anda tidak memasukkan cukup banyak sprint Anda untuk membuat tim sibuk selama dua minggu.
Blrfl
3
Apakah pengembangan pasangan hibrida / pengujian mashup praktis? Dalam beberapa hal prosesnya sama dengan siklus pengujian unit; tulis sedikit tes sedikit. Kami tidak memiliki ini secara resmi tetapi penguji kebiasaan datang kepada kami secara langsung sebagai bug atau dua ditemukan. Kami tidak berkomunikasi melalui laporan bug formal. Pada saat "penguji saya" selesai pengujian, saya selesai memperbaiki. Menjadi aplikasi web menjadikan perbaikan turnaround menjadi efisien. Tapi setidaknya bereksperimen. Dan terus terang, bahkan jika itu tidak lebih baik atau lebih buruk, mgt akan merasakan waktu tunggu yang lebih sedikit.
radarbob
3
Apakah pekerjaan yang awalnya direncanakan untuk sprint umumnya diselesaikan dengan kualitas yang memadai? Atau apakah Anda juga meninggalkan cerita setengah jadi dari rencana semula?
Bart van Ingen Schenau
2
Anda bisa mempertahankan proses Anda tetapi menyebutnya 'kanban' alih-alih 'scrum', dan kemudian Anda tidak perlu khawatir tentang apakah proses Anda benar dengan scrum. Saya agak sarkastik, tetapi tidak juga
Eric King

Jawaban:

16

Itu masalah yang agak umum, disebabkan oleh pipelining . Tim ini multifungsi, tetapi tentu saja ada silo internal yang mengurangi kinerja.

Pertama saya ingin mencatat beberapa hal yang menurut saya penting:

  1. Jika pengembang Anda mengerjakan iterasi terlebih dahulu, mereka akan mencegah rapat perencanaan Anda. Manajer produk Anda dan tim perlu mendiskusikan apa yang paling berharga untuk iterasi berikutnya dengan benar. Prioritas tidak boleh dilakukan secara efektif oleh pengembang karena tidak ada yang lebih baik untuk dilakukan.

  2. Tidak peduli bagaimana Anda membagi dan mengatur iterasi, Anda tidak dapat benar-benar membuat semua orang sibuk sepanjang waktu dan memiliki satu tim dengan satu rapat perencanaan selama tim Anda memiliki spesialis yang bekerja di silo. Bahkan dengan pendekatan air terjun murni, Anda masih perlu "melempar barang-barang ke dinding" dan menunggu umpan balik.

  3. Anda juga memiliki masalah yang sering membutuhkan satu cerita untuk memiliki fase pengembangan, diikuti oleh fase pengujian, diikuti oleh fase perbaikan bug, diikuti oleh ... ini benar-benar dapat membuat tim Anda tidak efisien - terutama jika mereka bekerja di muka , karena mereka perlu beralih konteks.

Jelas ada biaya yang sangat nyata untuk situasi ini: tim tidak berkolaborasi. Saya mengalami hal ini setiap kali ada tim QA yang terlibat, jadi saya punya sedikit waktu untuk mencoba berbagai solusi.

Apa yang bekerja dengan sangat baik bagi saya adalah dua alat ini:

  1. Tekankan prinsip bahwa seluruh tim bertanggung jawab untuk menyelesaikan pekerjaan. Tolak cerita "dev done", karena itu adalah cara bagi pengembang mengatakan "bukan masalah saya lagi", yang keduanya tidak konstruktif dan jelas salah. Jika sebuah tim tidak menyampaikan cerita yang mereka terima, itu adalah seluruh tim yang tidak menyampaikan.

  2. Untuk mengisi waktu pengembang dan QA, pasangkan mereka . Sejauh ini, ini adalah cara terbaik untuk berbagi keahlian dan pengetahuan domain yang dapat Anda pilih. Pengembang dapat membantu penguji mengotomatiskan tugas mereka. Penguji dapat menunjukkan kepada pengembang di mana penting untuk menguji kode karena rapuh. Keduanya berkolaborasi dan bekerja lebih cepat daripada tidak.

Dengan menggunakan dua teknik ini, tim harus mengurangi kesunyian dan performanya. Sementara penguji dan pengembang sangat tidak mungkin untuk bertukar pekerjaan, mereka akan dapat bekerja sebagai tim dan menyelesaikan masalah secara internal, alih-alih saling menyalahkan.

Sklivvz
sumber
1
Terima kasih atas jawaban Anda. Saya sangat suka ide memasangkan sumber daya pengembang dan QA bersama. Saya akan menyarankan ini pada pertemuan berikutnya dan mudah-mudahan kita bisa mengujinya dalam sprint berikutnya. Saya akan memperbarui pertanyaan dan memberi tahu Anda bagaimana hasilnya!
fml
@ Klivvz Ini terjadi lebih sering daripada hanya ketika ada departemen QA. Ini terjadi setiap saat ketika QA adalah peran yang hanya dapat dilakukan oleh "orang tertentu". Alih-alih sumber daya menganggur mengambil tugas prioritas tinggi "berikutnya", pengembang menganggur, lalu mengambil lebih banyak pekerjaan sementara QA terus-menerus bereaksi terhadap output pengembang.
Edwin Buck
1
Jika tidak jelas di atas, "tugas prioritas tinggi berikutnya adalah" mengurangi tumpukan QA sehingga barang dapat dikirim "bukan tugas pengembangan prioritas tinggi berikutnya dari tumpukan tersebut.
Edwin Buck
1
Saran, seperti seluruh tim bertanggung jawab, sementara kedengarannya bagus, pada kenyataannya, tidak melayani tim. Ini menunjukkan bahwa setiap orang dapat dipertukarkan dan itu adalah kurangnya semua orang yang tidak mau ikut campur. Ini salah. Setiap orang di SDLC memiliki peran tertentu dan telah menghabiskan TAHUN untuk mengasah keterampilan mereka. Meminta insinyur perangkat lunak untuk menguji merusak kualitas karena mereka tidak memiliki pengalaman yang diperlukan untuk menguji kualitas, dan kemungkinan akan melakukan upaya setengah hati. Bahkan jika insinyur QA membimbing mereka, pendampingan akan mengambil waktu jauh dari pengujian dan membuat pekerjaan lebih lama.
Chuck Conway
1
@ ChuckConway tidak ada yang menyarankan apa yang Anda katakan. Pasangan tidak menggantikan atau mentoring. Idealnya Anda mempercayai tim untuk menemukan cara terbaik untuk meminimalkan waktu henti, dan itu hanya bisa dimulai dengan orang-orang memahami peran dan kebutuhan masing-masing. Tim yang terbaik, paling efisien mengatur diri sendiri (benar atau tidak, itu adalah prinsip dasar tangkas).
Sklivvz
2

Tidak ada masalah dengan cara Anda bekerja terkait dengan SCRUM dan sprint, asalkan akan dicatat pada saat evaluasi bahwa pekerjaan pengembang selesai dalam waktu yang lebih singkat (dan berapa lama waktu) yang direncanakan. Ini akan memungkinkan tim untuk mengambil lebih banyak poin cerita untuk sprint berikutnya. Bagaimanapun, titik sprint adalah untuk menjadi lebih baik dalam perencanaan. Jelas Anda masih memiliki ruang untuk perbaikan.

kami selalu mengembangkan pekerjaan sprint berikutnya dalam sprint saat ini

Wah! Ini teknis tidak mungkin di Scrum. Anda tidak tahu item backlog apa yang akan ada dalam sprint berikutnya, yang akan ditetapkan pada awal sprint berikutnya dalam sesi perencanaan sprint.

Tetap menarik untuk belajar tentang cara-cara kreatif baru yang diciptakan organisasi untuk menyabot Scrum.

Martin Maat
sumber
3
Masalah dengan pernyataan seperti "Whoa! Ini secara teknis tidak mungkin di Scrum" dan "... cara kreatif baru yang diciptakan organisasi untuk menyabotase Scrum" adalah bahwa mereka menyiratkan ada cara yang benar untuk "melakukan Scrum". Agar ada cara yang benar, Scrum harus bersifat proskriptif, yaitu menempatkan proses di depan orang. Karena itu scrum bukanlah proses yang gesit jika ada cara yang benar untuk melakukan scrum.
David Arno
@ David Arno Itu bagus, Anda pada dasarnya mengatakan metodologi apa pun secara definisi tidak gesit. Bahkan manifesto yang gesit. Hanya kekacauan yang tak terduga yang akan gesit. Tapi tunggu .. siapa yang menyuruhku kacau? Serius sekarang: adagium tangkas "orang sebelum proses" ada di sana untuk menyelesaikan konflik. Jika seseorang harus memilih, ia harus melakukan apa yang masuk akal, tidak harus sesuai dengan peraturan. Menurut saya, tim OP bisa membaca buku Scrum tanpa masalah. Dan mungkin memang demikian, pertanyaan kuncinya adalah seberapa transparan mereka.
Martin Maat
1
@ Davidvidno sebenarnya, itu hanya menyiratkan bahwa ada cara-cara spesifik yang salah untuk melakukan Scrum, dan itu tampaknya tidak kontroversial. Misalnya, segala sesuatu yang bertentangan dengan Agile Manifesto tampaknya secara objektif salah.
Sklivvz
1

Scrum mengoptimalkan tim , bukan individu. Inti dari scrum adalah agar tim menjadi efisien. Jika pengembang mulai mengerjakan hal-hal di luar sprint saat ini, mereka merugikan tim. Ini juga menunjukkan bahwa Anda agak gagal dalam proses perencanaan Anda, jika Anda gagal merencanakan pekerjaan yang cukup untuk mengisi pegas.

Jika pengembang telah kehabisan tugas pengembangan, mereka benar-benar harus melakukan dan membantu penguji atau penulis teknologi atau desainer - siapa pun di tim. Mereka tidak perlu harus menulis tes yang sebenarnya (meskipun, mereka harus ), tetapi mereka masih dapat berpartisipasi dalam proses pengujian. Mereka dapat menulis skrip yang membantu penguji menjadi lebih efisien, atau mereka hanya dapat berdiskusi dengan penguji apa tantangan mereka dan terus membantu mereka mengatasi tantangan tersebut (misalnya: menambahkan atribut id ke elemen halaman web, menyediakan kait atau API yang dapat diuji oleh penguji dapat digunakan dalam tes mereka, dll).

Saya pikir inti masalahnya adalah jika pengembang Anda tidak selalu bekerja pada sprint saat ini, mereka belum bekerja sebagai tim. Scrum master Anda harus memperhatikan, dan bekerja untuk membuat tim bekerja sebagai unit daripada kumpulan individu.

Saya juga menyarankan bahwa ini adalah masalah manajemen. Jika mereka menekan pengembang untuk tetap sibuk maka mereka belum sepenuhnya merangkul scrum. Ini adalah hal lain yang dapat dibantu oleh scrum master. Mereka dapat bekerja dengan manajemen untuk membantu mereka memahami bagaimana scrum bekerja sehingga mereka dapat membantu mendukung dan mendorong tim pengembangan daripada menumbangkan mereka.

Bryan Oakley
sumber
0

Saya pikir masalah utama di sini adalah sebagai berikut:

sebagian besar pengembang berpendapat bahwa pengujian ada di bawah mereka

Cara kami menangani ini di perusahaan kami adalah kami bertanya kepada pengembang bagaimana mereka dapat mengatakan bahwa mereka benar-benar menyelesaikan pekerjaan mereka jika mereka tidak dapat membuktikannya. Tentu saja, satu-satunya cara untuk membuktikannya adalah dengan menunjukkan bahwa kode yang mereka tulis benar-benar berfungsi, dan ini dilakukan melalui pengujian. Harus ditunjukkan kepada mereka bahwa jika mereka setuju untuk berpartisipasi dalam pengujian, maka pengujian akan dilakukan lebih cepat, dan mereka akan memiliki lebih banyak waktu untuk membuat kode fungsi tambahan (yang juga perlu diuji).

Pastikan bahwa pengujian kode Anda tidak di bawah tingkat pengembang. Ini adalah bagian integral dari proses pembangunan. Itu tidak dapat dipisahkan dari hanya coding. Siapa saja dapat membuat kode. Tidak semua orang bisa membuat kode dan membuktikan bahwa apa yang mereka kodekan benar-benar berfungsi.

Cara lain untuk membuat para pengembang sibuk adalah membuat mereka bekerja pada pengkodean tes otomatis untuk fungsi yang mereka kembangkan dalam sprint. Tes-tes tersebut kemudian dapat digunakan untuk pengujian regresi yang akan dijalankan secara berkala.

Either way, melakukan sesuatu yang tidak direncanakan pada awal sprint adalah besar tidak-tidak. Lebih baik tidak melakukan apa pun, daripada melakukan sesuatu yang tidak direncanakan. Fungsi yang mereka tulis dalam kasus-kasus itu kemungkinan besar tidak memenuhi kriteria DoD (Definition of Done), karena mungkin tidak diuji dengan baik, karena para penguji sibuk dengan menguji apa yang semula direncanakan. Ini adalah cara yang pasti untuk memperkenalkan bug dan menurunkan kualitas produk, yang kemudian mengirim tim ke dalam spiral masalah regresi dan pergantian konteks yang menurun, mengakibatkan stres, mengurangi kecepatan, dan akhirnya, berhenti dari tim karena hal itu.

Vladimir Stokic
sumber
Saya akan mengatakan programmer sedang menguji kode, mereka hanya tidak membuat tes otomatis. Ada perbedaan besar.
JeffO
Dalam kasus khusus ini, saya berani bertaruh bahwa satu-satunya pengujian yang dilakukan oleh programmer ini adalah dari IDE. Tidak banyak pengembang yang benar-benar membangun solusi ke dalam paket instalasi, menyebarkan paket dari awal seperti yang dilakukan pengguna akhir, dan kemudian benar-benar menguji solusinya. Ini dalam banyak kasus tidak cukup, dan merupakan alasan untuk penurunan kualitas yang signifikan.
Vladimir Stokic
0

Secara teori, semua anggota tim SCRUM harus memiliki pengetahuan yang sama, sehingga setiap anggota dapat mengambil setiap tugas dari setiap anggota lainnya. Jika tidak, Anda harus menyebarkan pengetahuan.

Namun dalam praktiknya selalu ada semacam spesialisasi. Perangkat lunaknya mungkin kompleks, anggota tim memiliki keterampilan yang berbeda, dll. Membagi tim menjadi pengembang dan penguji hanyalah satu contoh (sangat umum) dari spesialisasi.

Menyebarkan pengetahuan mungkin membutuhkan waktu lebih lama daripada yang ingin diterima manajemen.

Untuk pengalaman saya, Anda bisa melakukan beberapa hal:

  • Jangan membuat tim terlalu kecil. Jika Anda misalnya memiliki 4 pengembang dan 4 penguji, akan lebih mudah untuk memindahkan tugas ke pengembang atau penguji lain, maka hanya memiliki 3/2 seperti pada contoh ini.
  • Cobalah untuk membagi tugas yang lebih besar. Jika Anda memiliki tugas yang lebih kecil, Anda akan lebih fleksibel.
  • Tetapkan beberapa tugas opsional yang dapat dilakukan jika ada waktu tersisa.

Saran-saran ini mungkin bukan teori SCRUM 100%, tetapi pertama-tama Anda harus terus mengembangkan pengembangan. SCRUM hanyalah sebuah kotak alat.

bernie
sumber
0

Tampaknya Anda perlu menguraikan tim Anda. Seperti itu:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

Jika saya mengerti tes otomasi, pria harus memulai beberapa hari lebih awal.

Tapi saya merasakan ada masalah di tim Anda: Saya punya masalah dengan pengembang yang tidak menguji kode mereka sendiri. Jika orang-orang tes mempersiapkan tes tanpa meninjau kode mereka mungkin hanya melakukan tes blackbox yang tidak memperhitungkan poin keputusan dari program yang dikembangkan. Anda puas dengan kualitas perangkat lunak Anda?

Lucas
sumber