Scrum - Apa yang sibuk dengan anggota tim selama sprint


33

Jadi, scrum sprint adalah periode waktu yang tetap di mana serangkaian fitur tertentu harus diimplementasikan. Dan tim scrum terdiri dari semua orang yang berkomitmen untuk memberikan fitur-fitur tersebut, kebanyakan dari mereka biasanya adalah pengembang dan penguji.

Setelah menetapkan aturan ini, orang mungkin bertanya-tanya bagaimana membuat semua orang ini sibuk selama seluruh sprint. Pada awal sprint belum ada yang bisa diuji, dan pada akhir sprint biasanya tidak ada atau sangat sedikit yang tersisa untuk dikembangkan / diperbaiki.

Saya telah melihat 2 pendekatan untuk menangani hal ini, tetapi tidak satu pun dari mereka tampaknya menyelesaikan masalah dengan benar.

1) Biarkan anggota tim memutuskan apa yang harus dilakukan setiap kali mereka kehabisan tugas.

Cons:

  • Jika apa yang mereka lakukan tidak direncanakan secara menyeluruh (yaitu refactoring besar, beralih ke kerangka pengujian baru), pekerjaan mereka mungkin menjadi sia-sia atau macet setengah jalan
  • Di sisi lain, perencanaan pekerjaan semacam itu bisa memakan banyak waktu, dan klien mungkin kecewa melihat tim membuang waktu untuk sesuatu yang tidak membawa nilai langsung.
  • Tugas semacam itu biasanya tidak dapat diperkirakan secara menyeluruh, sehingga cukup mudah bagi pekerja yang tidak berprinsip untuk menghabiskan waktu menonton kucing YouTube tanpa tercermin di papan scrum atau di mana pun.

2) Buat ruang dalam sprint hanya untuk pengembangan, dan mulai pengujian setelah sprint selesai (ketika pengembang mulai mengerjakan fitur dari sprint berikutnya)

Cons:

  • Saat mengembangkan fitur untuk sprint saat ini, pengembang terganggu dengan memperbaiki bug dari yang sebelumnya, dan mereka dapat gagal untuk melakukan jumlah pekerjaan yang diperkirakan akan dilakukan selama sprint saat ini
  • Dibutuhkan dua papan scrum: satu untuk fitur sprint saat ini, dan satu untuk bug sprint sebelumnya

Jadi pertanyaan saya adalah: bagaimana cara mendistribusikan pekerjaan dengan benar selama sprint antara pengembang dan penguji sehingga tidak ada yang kelebihan beban dengan pekerjaan atau berakhir tanpa tugas di titik mana pun? Adakah cara untuk meningkatkan pendekatan yang dijelaskan di atas? Atau ada pendekatan yang lebih baik?


9
Anda tampaknya jatuh cinta pada mitos pemanfaatan
Nathan Cooper

1
@holdenmcgrohen Bagaimana perkiraannya dilakukan - merencanakan poker atau yang lainnya?
Robbie Dee

3
Penguji harus menulis kasus uji pada hari pertama. Yang perlu mereka lakukan hanyalah cerita. Jika pengembang memiliki waktu henti yang signifikan selama sprint, itu berarti Anda tidak mengambil cukup banyak cerita. Plus, mungkin jika penguji Anda baik, mereka membuat pengembang Anda sibuk dengan laporan bug di dekat akhir sprint. Juga, idealnya, Anda memiliki beberapa cerita teratas di backlog, jadi kasus terburuk, pengembang dapat bekerja pada salah satu dari pasangan top di backlog.
Gort the Robot

1
@ holdenmcgrohen, kami juga menghadapi masalah serupa di proyek kami. Kami telah mulai menambahkan Stretch story (tidak boleh ' harus dimiliki ') sebagai bagian dari sprint dan hanya dipilih ketika pengembang tidak mengerjakan tugas. Sekarang pendekatan ini membantu kita menjaga kesibukan penguji dalam memulai hari dari sprint berikutnya.
user6005214

1
Ingatlah bahwa di sebagian besar sprint Anda memilih subset tugas dari backlog . Jika Anda menyelesaikan semua komitmen Anda, Anda dapat memulai sprint berikutnya dengan mulai mengerjakan lebih banyak item dari backlog - sama seperti jika Anda menabrak, Anda menarik lebih sedikit item dari backlog di sprint berikutnya dapat menyelesaikan yang belum selesai. Dogma sampah; Sadarilah bahwa tujuan dari alat ini adalah untuk melayani Anda, bukan untuk Anda untuk melayani alat tersebut.
keshlam

Jawaban:


49

Di awal sprint belum ada yang bisa diuji

Sangat? Anda tidak memiliki persyaratan untuk memvalidasi? Tidak ada diskusi dengan pelanggan Anda? Tidak ada kerangka kawat untuk dievaluasi? Tidak ada rencana tes untuk dipikirkan?

pada akhir sprint biasanya tidak ada atau sangat sedikit yang tersisa untuk dikembangkan / diperbaiki

Saya tidak pernah berada di tempat itu dalam suatu proyek. Tidak ada lagi pekerjaan yang harus dilakukan? Selalu ada sesuatu. Apakah semua tes Anda sepenuhnya otomatis? Bagaimana CI Anda terlihat? Bisakah lapisan akses basis data dire-refored menjadi lebih sederhana? Dan saya belum pernah mengerjakan apa pun dengan daftar bug dan backlog kosong. Apa yang biasa dilakukan pengembang Anda dalam fase pengujian air terjun?

Saya tahu beberapa orang menjadi sangat religius tentang apa yang ada dan yang bukan 'SCRUM'. Saya tidak peduli tentang itu. Tapi saya pikir Anda memiliki dua masalah di sini:

  1. Departemen QA 'tradisional' yang menguji kode setelah 'diselesaikan' oleh pengembang daripada bekerja dengan pelanggan dan pengembang untuk memastikan Anda membangun hal yang benar dan juga membangunnya dengan benar. Lihatlah kuadran lincah pengujian oleh Lisa Crispin. Penguji terbaik terlibat dalam setiap tahap siklus pengembangan perangkat lunak dan pengembang terbaik menulis tes mereka sendiri.

  2. Mencoba untuk tetap berpegang erat pada jadwal SCRUM sprint 1 minggu / 2 minggu tanpa memiliki backlog yang diprioritaskan dan berukuran yang dibagi menjadi tugas-tugas yang cukup mudah untuk diselesaikan dalam waktu singkat dalam satu sprint. Jika Anda memiliki ini maka akan selalu ada lebih banyak pekerjaan untuk dilanjutkan. Mungkin fitur terakhir yang Anda kerjakan dalam sprint ini tidak masuk ke rilis sprint ini, tetapi itu selalu bisa masuk ke yang berikutnya.

Ke samping. Jika Anda memiliki tim kohesif kecil maka peran kurang penting. Alih-alih memiliki seseorang dengan penguji label yang tidak diizinkan untuk menulis kode produksi, atau seseorang yang memberi label pengembang yang berpikir mereka di atas pengujian, semua orang harus melakukan apa pun yang diperlukan untuk tim untuk berhasil, termasuk tugas manajemen proyek yang ditakuti ketika mereka diperlukan, ini disebut tim lintas fungsional.

Satu poin tambahan yang disampaikan oleh @Cort Ammon dalam komentar. Manifesto tangkas berbicara tentang kolaborasi pelanggan atas negosiasi kontrak. Itu kata kamu:

klien mungkin kecewa melihat tim membuang-buang waktu untuk sesuatu yang tidak membawa nilai langsung

Mungkin sulit untuk menjelaskan dan saya mengerti pelanggan terkadang sangat sulit, tetapi ini akan menjadi bendera merah besar bagi saya. Mereka mempercayai Anda dengan kode sumber / hubungan klien / bisnis / apa pun yang Anda kembangkan untuk mereka. Jika mereka tidak dapat mempercayai Anda untuk bertindak secara profesional demi kepentingan terbaik mereka, maka Anda memiliki masalah atau mereka melakukannya.

Saya telah menulis posting yang berbicara tentang pengembang perangkat lunak yang tidak dianggap profesional. Seorang dokter profesional, pengacara, insinyur sipil dihadapkan dengan klien yang mengubah persyaratan pada mereka sebagian tidak akan hanya mengurangi kualitas dan mengeluh tentang hal itu. Mereka akan memberi tahu klien mereka bahwa itu akan menjadi masalah. Jika klien mendorong maka seorang profesional tidak akan secara membabi buta melakukannya dengan standar inferior yang berbahaya karena mereka akan bertanggung jawab. Kami tidak mengikuti ujian masuk profesional dan karenanya tidak bertanggung jawab. Itu tidak berarti kita tidak seharusnya mencoba menjadi lebih baik.

Singkatnya, saya tidak akan terlalu khawatir tentang mencoba membuat orang menjadi lebih efisien pada awal dan akhir sprint, tetapi melihatnya sebagai gejala dari masalah yang lebih luas dalam tim. Pernahkah Anda mendengar tentang Pemrograman eXtreme (XP) . Saya akan mengatakan prinsip-prinsip dari XP untuk diterapkan di sini adalah komunikasi dan rasa hormat:

  • Hormati tim Anda untuk melakukan apa yang menurut mereka terbaik. Saya berpendapat bahwa jika ada banyak menonton video kucing maka Anda memiliki pengembang yang buruk atau Anda memperlakukan mereka dengan buruk.
  • Komunikasi. Jika pengembang Anda berbicara satu sama lain, ke penguji, ke manajemen, ke pelanggan, maka semua orang mungkin harus memiliki perasaan yang baik tentang apa yang terjadi selanjutnya dan jika tidak, mereka hanya bisa bertanya.

Ya, ya dan ya. Temukan jawaban dalam segala hal.
David Arno

Jawaban yang bagus - paragraf terakhir perlu dikerjakan. Naikkan dan jelaskan poin-poin di sini daripada menunjuk ke beberapa buku tebal.
Robbie Dee

1
Apa yang biasa dilakukan pengembang Anda dalam fase pengujian air terjun? - Saya tidak bermaksud membandingkan scrum dengan watefall, melainkan dengan pendekatan mirip kanban, di mana selalu ada daftar fitur yang harus dilakukan yang sudah dievaluasi dan diprioritaskan. Scrum backlog berisi fitur yang tidak diperiksa dengan baik oleh tim, jadi jika satu pengembang (yang saat ini tidak memiliki fitur untuk mengerjakan) memutuskan untuk mulai menerapkan salah satu dari mereka di tengah sprint, ini dapat menyebabkan konsekuensi yang tidak terduga .
holdenmcgrohen

@ holdenmcgrohen cukup adil. Perkiraan saya selalu mengerikan, yang saya coba pertanggungjawabkan, jadi saya selalu ingin memiliki sesuatu selanjutnya. Saya pikir standup dan pairing harian dapat membantu di sini, jika pengembang Anda tidak dibiarkan terlalu lama mereka tidak bisa menyimpang terlalu jauh.
Encaitar

@Encaitar Hebat +1
Robbie Dee

20

Poin pertama adalah bahwa Scrum adalah tentang mengoptimalkan tim , bukan masing-masing individu. Jika tim produktif dan efisien, tidak masalah jika seseorang menganggur di awal atau akhir tugas.

Namun, di setiap tim yang saya ikuti, selalu ada banyak pekerjaan. Biarkan saya mengatasi beberapa masalah spesifik Anda:

Pada awal sprint belum ada yang menguji,

Sementara itu mungkin benar dalam arti literal, itu menyiratkan Anda berpikir bahwa satu-satunya pekerjaan untuk tester adalah "menguji". Ada banyak hal yang dapat dilakukan sebelum mereka mulai menguji. Untuk satu, mereka dapat bertemu dengan pemilik produk dan pengembang untuk sepenuhnya memahami persyaratan. Mereka bisa sibuk mengerjakan rencana pengujian, mengumpulkan data tes, dan sebagainya. Jika mereka memiliki kemewahan kerangka kerja yang baik, mereka dapat mulai menulis tes otomatis sebelumnya.

pada akhir sprint biasanya tidak ada atau sangat sedikit yang tersisa untuk dikembangkan / diperbaiki

Saya belum melihat tim pengembangan yang kehabisan hal untuk diperbaiki. Namun, bukan itu yang seharusnya mereka lakukan di akhir sprint. Menjelang akhir sprint mereka harus membantu penguji menguji produk. Mereka dapat membantu menulis tes otomatis, mereka dapat menguji kode ulasan dan perlengkapan / kata kunci / dll yang ditulis oleh penguji. Mereka dapat bekerja dengan tim dokumentasi untuk membantu mereka menyelesaikan pekerjaan mereka, dll.

Saya telah melihat 2 pendekatan untuk menangani ini ... 1) Biarkan anggota tim memutuskan apa yang harus dilakukan setiap kali mereka keluar dari tugas.

Kelemahan dalam pemikiran Anda adalah bahwa individu kehabisan tugas. Tugas menjadi milik tim secara keseluruhan. Mereka tidak boleh melakukan pekerjaan lain selama ada cerita atau tugas yang tersisa untuk tim dalam sprint saat ini.

Buat ruang dalam sprint hanya untuk pengembangan,

Pendekatan ini tidak dalam definisi tradisional tentang scrum atau gesit. Inti lincah adalah bahwa seluruh tim terlibat dalam bekerja menuju tujuan bersama. Itu berarti bahwa semua pekerjaan yang diperlukan untuk menyelesaikan sebuah cerita harus diwakili dalam sprint - desain, pengembangan, pengujian, dokumentasi, dll.

Akhirnya, ini bukan satu-satunya solusi yang layak. Anda mengabaikan solusi yang sebenarnya, yaitu setiap anggota tim harus melakukan pitching sesuai kebutuhan untuk membantu menyelesaikan cerita dalam sprint.

Tujuannya adalah tujuan tim , tetapi Anda menulis seolah-olah setiap orang memiliki tujuan individu ("selesaikan tugas saya"). Jika seseorang tidak ada hubungannya, mereka dapat melihat apa yang sedang dikerjakan dan menawarkan bantuan. Atau, mereka dapat mengambil tugas atau cerita selanjutnya dan mulai mengerjakannya.


1
+1. Proses lincah membutuhkan kelonggaran. Untuk mengoptimalkan sistem, Anda sering harus menonaktifkan subproses. Dalam hal ini, Anda mengatakan yang terbaik dengan "mengoptimalkan tim." Yang lainnya adalah gejala dari kesalahan pemanfaatan.
CodeGnome

Pada awal karier saya, saya menghadapi beberapa perusahaan yang mengharapkan kandidat untuk bekerja di semua PHP, Java, C #, Desktop Apps (VB), QA (otomatis, manual), Photoshop, CSS dan sebagainya. Industri waktu itu menganggap perusahaan-perusahaan itu kurang profesional karena nilai spesialisasi. Saya bertanya-tanya apakah pola yang sama mendapatkan penerimaan (bahkan menjadi keharusan) di bawah Agile.
kuldeep.kamboj

1

Di semua toko tangkas tempat saya bekerja, penguji dianggap sebagai ayam sehingga mereka tidak mengalami timebox dalam sprint seperti para pengembang. Sebelum mendapatkan perangkat lunak, penguji harus menulis rencana dan memastikan lingkungan telah diatur dengan benar untuk menerima perangkat lunak. Sebagai bagian dari ini, mereka harus memeriksa dokumen desain seperti apa adanya.

Selanjutnya, Anda harus mencari untuk mengisi sprint. Seharusnya tidak ada waktu luang di akhir sprint jika estimasi baik meskipun estimasi tentu saja adalah seni hitam sehingga jarang mengisi persis .

Jika pengembang memiliki waktu luang di akhir sprint, waktu ini masih harus dilacak untuk memastikan itu menambah nilai (mempelajari kerangka kerja baru, melakukan analisis, pengujian lebih lanjut, dll).

Memperbaiki bug adalah kegiatan yang dapat diterima sepenuhnya untuk dilakukan dalam sprint. Ini berkontribusi pada fitur dan menambah nilai. Ini tidak boleh dilihat sebagai waktu yang dicuri dari sprint berikutnya - lebih baik menyelesaikan fitur.


8
Baca Panduan Scrum . Mungkin Anda akan menemukan bagian yang dikatakan tidak masalah untuk membagi tim pengembangan menjadi penguji dan pengembang (petunjuk, Anda tidak akan).
Nathan Cooper

3
Dokumen itu tidak mengatakan Anda memiliki anggota tim pengembangan dengan spesialisasi, tetapi Anda tidak bisa memisahkan kelompok untuk diperlakukan seperti "ayam".
Nathan Cooper

5
Kepada para pemilih, bagian mana dari pelatihan Agile yang Anda lewatkan di mana itu menentukan bahwa Anda harus mengadopsi strategi yang bekerja untuk tim Anda ? Tim Robbie Dee mengadopsi apa yang berhasil bagi mereka dalam keadaan unik mereka dengan proyek unik mereka dan kendala lingkungan. Setiap perusahaan memiliki hambatan lingkungan dan "kerusakan" yang perlu diarahkan. Ini sepertinya pendekatan yang bisa diterima untuk pertanyaan yang diajukan . Pertanyaannya bukan tentang cara terbaik untuk mengatur penguji dan upaya pengujian di tim sprint Anda.
maple_shaft

4
Tidak. OP secara khusus bertanya tentang Scrum. Anda tidak dapat melakukan apa pun yang Anda suka dan menyebutnya Scrum. Ini mungkin atau mungkin tidak gesit, tetapi memiliki bagian dari "tim" lintas fungsi Anda diperlakukan sebagai sumber daya eksternal atau sebagai apa pun selain anggota kelas satu dari tim pengembangan bukanlah Scrum.
CodeGnome

2
@CodeGnome benar-benar benar, dan menyentuh suatu hal yang selalu saya kemukakan : Agile adalah filosofi, Scrum adalah implementasi dari filosofi itu. Keduanya bukan hal yang sama, dan mematuhi aturan yang terpisah. (Ya, Scrum

-2

Di dunia yang ideal, tim Anda akan berfungsi lintas fungsi . Setiap orang memiliki spesialisasi mereka, tetapi semua orang dapat bekerja sebagai spesialisasi lain juga. Jika penguji Anda tidak dapat membuat kode tugas yang paling sederhana, maka Anda tidak memiliki tim lintas fungsi.

Cara SCRUM adalah untuk memungkinkan tim Anda menjadi lintas fungsional. Penguji Anda harus memiliki keterampilan untuk otomasi pengujian, ini adalah langkah singkat untuk mengkode beberapa hal yang kurang rumit.


6
Orang berbentuk T adalah satu hal, memiliki penguji menulis kode (kecuali jika kita berbicara untuk otomatisasi uji) adalah hal lain.
Robbie Dee

2
Ini hanya mengasumsikan bahwa hanya Penguji yang memiliki waktu henti dalam sprint? Devs memiliki downtime juga.
maple_shaft

Saya berasumsi bahwa Dev dapat melakukan pengujian tanpa pelatihan lebih lanjut. Tempat tinggal saya itu bagian dari pendidikan dan pekerjaan.
nvoigt
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.