Panduan Scrum | 13. Tim Pengembang di Scrum

Diterbitkan: 2022-04-25

Tim Pengembang di Scrum adalah grup interdisipliner yang terdiri dari semua orang yang terlibat dalam pembuatan Produk. Dalam artikel hari ini, kita akan melihat karakteristik apa yang seharusnya dimiliki. Kami juga akan mempertimbangkan komposisi dan tanggung jawab Tim Pengembang yang mampu mencapai Tujuan secara efektif.

Tim Pengembang di Scrum – daftar isi:

  1. Fitur Tim Pengembang
  2. Tim pengembangan
  3. Tanggung Jawab Tim Pengembang
  4. Ringkasan

Fitur Tim Pengembang

Tim Pengembang yang bekerja sesuai dengan prinsip-prinsip Scrum adalah kelompok spesialis yang independen. Itu tidak menggunakan dukungan dari spesialis atau subkontraktor eksternal. Tapi apa yang menentukan bahwa Tim cocok untuk mencapai Tujuan? Dan tanggung jawab apa yang termasuk dalam tugas Tim Pengembang – terlepas dari spesialisasinya?

Agar efektif, Tim Pengembang harus memiliki setidaknya tiga karakteristik: kemampuan untuk mengatur diri sendiri, dorongan untuk tumbuh, dan interdisipliner.

Organisasi mandiri

Ketika kita berbicara tentang Tim Scrum, di mana Tim Pengembang adalah bagiannya, kita menggunakan istilah "manajemen diri". Ini berarti manajemen diri di tingkat organisasi. Tim Scrum secara keseluruhan memutuskan tidak hanya siapa yang akan melakukan pekerjaan dan bagaimana, tetapi juga apa yang akan mereka kerjakan. Dalam Tim Scrum, sebagian besar tugas manajemen adalah milik Pemilik Produk dan Scrum Master.

Development Team

Oleh karena itu, dalam kasus Tim Pengembang, pengorganisasian diri lebih penting daripada pengelolaan diri. Ini mengacu pada tanggung jawab perencanaan, yaitu memutuskan sendiri siapa yang akan melakukan tugas tertentu, kapan dan bagaimana.

Mengejar pembangunan

Fitur utama dari Tim yang efektif adalah dorongan untuk berkembang. Cara menyelesaikan tugas yang ditetapkan sebelumnya harus ambisius. Hasil ini tidak hanya dari kecenderungan individu dan sikap setiap anggota Tim Pengembang. Peningkatan kompetensi dan usaha juga didorong oleh suasana dalam Tim, yang mendefinisikannya secara keseluruhan.

Interdisipliner

Interdisipliner Tim berarti bahwa anggotanya bersama-sama harus memiliki semua keterampilan yang diperlukan untuk menciptakan Increment yang berharga di setiap Sprint. Ini juga berarti bahwa setiap anggota Tim melakukan tugas yang diperlukan untuk Sprint tersebut. Setiap orang melakukan apa yang diperlukan untuk mencapai Tujuan. Bahkan jika itu berarti mengambil tugas baru di luar keahlian Pengembang. Adalah suatu kesalahan untuk tetap berpegang teguh pada kompetensi atau peran profesional seseorang.

development team features

Tim pengembangan

Menurut Panduan Scrum, jumlah maksimum Pengembang adalah delapan. Komposisi kecil seperti itu mendorong komunikasi dan keterbukaan, karena anggota Tim memiliki kesempatan untuk saling mengenal. Namun, Tim tidak boleh lebih kecil dari tiga orang. Itu harus cukup besar untuk membuat kemajuan yang terlihat bisnis di setiap Sprint.

Pengembang dalam Scrum disebut orang dengan berbagai keterampilan dan tanggung jawab. Dalam kasus apa pun nama tersebut tidak diperuntukkan bagi orang yang melakukan pemrograman. Dengan demikian, Tim dapat mencakup pemrogram dan perancang, peneliti dan analis, penguji dan ilmuwan, serta spesialis lainnya.

Tidak ada hierarki di antara Pengembang. Itu sebabnya mereka tidak menggunakan gelar profesional atau ilmiah.

Asumsi penting tentang komposisi tim Pengembang adalah bahwa itu adalah satu kesatuan. Oleh karena itu, tim yang lebih kecil yang mengerjakan Tujuan lain tidak boleh dipisahkan darinya.

Tanggung Jawab Tim Pengembang

Tanggung jawab Tim Pengembang dapat dibagi menjadi tiga bidang. Ini adalah:

  • Tugas perencanaan
  • Bekerja pada produk
  • Meningkatkan kerjasama dalam Tim

Tugas perencanaan

Penjadwalan tugas adalah kewajiban yang harus dipenuhi oleh semua Tim Pengembang berbasis Scrum. Ini terdiri dari membuat rencana Sprint dan memasukkannya ke dalam Sprint Backlog, yang akan kami jelaskan dalam artikel terpisah. Yang paling penting adalah bahwa Tim Pengembang mengerjakannya bersama-sama. Dengan cara ini setiap Pengembang akan dapat secara realistis menentukan jumlah tugas yang harus diselesaikan dalam Sprint yang diberikan. Dalam jangka panjang, ini memungkinkan Tim untuk mempertahankan kecepatan dan rencana yang konstan dengan lebih akurat.

Sama pentingnya untuk mengawasi denyut nadi, yaitu menyesuaikan rencana dengan kenyataan setiap hari. Jika masalah muncul, mungkin ada kebutuhan untuk berubah: untuk mengatur ulang tugas, mendistribusikan pekerjaan secara berbeda, atau berbicara dengan Scrum Master tentang kesulitan yang muncul.

Bekerja pada produk

Bentuk pengerjaan suatu Produk dapat bervariasi secara dramatis tergantung pada area di mana Tim Pengembang tertentu beroperasi. Secara umum, tujuan yang ingin dicapai dalam setiap Sprint adalah untuk membuat Increment, yaitu fitur Produk yang bernilai bisnis.

Di sini berguna untuk berbicara langsung dan menerapkan aturan berikut:

Saat Anda mengerjakan suatu Produk, Anda harus membiarkannya dalam keadaan yang tidak hanya ditingkatkan tetapi juga tidak kurang selesai dari versi sebelumnya.

Menerapkan prinsip ini berarti bahwa Tim secara keseluruhan bertanggung jawab atas Increment. Jika Pengembang melakukan tugas dengan ceroboh, yang menyebabkan kualitas Produk menurun, orang lain harus melakukan pekerjaan untuk mereka. Di sisi lain, jika ada Pengembang yang menemukan bug di Produk, mereka harus memperbaikinya sendiri atau meneruskan informasi bug tersebut kepada seseorang yang dapat melakukannya. Kami akan menulis lebih banyak tentang mengerjakan Peningkatan Produk dalam Sprint dalam artikel terpisah.

Meningkatkan Kolaborasi dalam Tim

Bekerja dengan cara Tim beroperasi adalah tentang terus meningkatkan efisiensi dan efektivitas Pengembang individu.

Namun, itu juga, atau mungkin di atas segalanya, bekerja pada komunikasi antara Pengembang. Perbaikan terdiri dari mencari solusi yang memungkinkan pembagian tugas yang efisien dan akurat. Dan juga melatih keterampilan:

  • mengkritik solusi, bukan orang – mengubah bahasa yang kita gunakan untuk menggambarkan pekerjaan mengarah pada perubahan sikap dan peningkatan kolaborasi
  • menjauhkan diri dari ide-ide Anda – ini memungkinkan humor dan umpan balik yang lebih jujur
  • membangun kepercayaan – berkat kepercayaan, akan ada lebih banyak ide inovatif yang diajukan oleh Pengembang tanpa takut akan reaksi negatif dari lingkungan

Meningkatkan kolaborasi Tim dicapai melalui refleksi berkelanjutan tentang cara kerja Tim dan memberikan umpan balik selama Acara Scrum yang dijelaskan dalam artikel ini.

Development Team in Scrum

Ringkasan

Dalam artikel hari ini kami menyajikan karakteristik, komposisi, dan tanggung jawab Tim Pengembang Scrum. Interdisipliner, pengorganisasian diri, dan keinginan untuk berkembang menjadi ciri tim kecil ini. Dan peningkatan kerja tim yang berkelanjutan dan kerja yang efektif pada Produk – ini adalah tugas yang harus dipenuhi oleh setiap Tim Pengembang.

Jika Anda menyukai konten kami, bergabunglah dengan komunitas lebah sibuk kami di Facebook, Twitter, LinkedIn, Instagram, YouTube.

Scrum Guide | 13. Development Team in Scrum caroline becker avatar 1background

Pengarang: Caroline Becker

Sebagai Manajer Proyek, Caroline ahli dalam menemukan metode baru untuk merancang alur kerja terbaik dan mengoptimalkan proses. Keterampilan organisasi dan kemampuannya untuk bekerja di bawah tekanan waktu menjadikannya orang terbaik untuk mengubah proyek rumit menjadi kenyataan.

Lihat semua posting

Panduan Scrum:

  1. Daftar istilah dasar, peran dan pengertian
  2. Apa itu Scrum?
  3. Nilai scrum
  4. Bagaimana menerapkan Scrum di perusahaan Anda?
  5. Tim Scrum - apa itu dan bagaimana cara kerjanya?
  6. Siapa Pemilik Produk?
  7. Kesalahan paling umum dari Pemilik Produk
  8. Siapa Scrum Masternya?
  9. Karakteristik Scrum Master yang baik
  10. Kesalahan paling umum dari Scrum Master
  11. Statistik dan metrik apa yang harus dilacak oleh Scrum Master?
  12. Kerjasama antara Pemilik Produk dan Scrum Master
  13. Tim Pengembang di Scrum
  14. Kesalahan paling umum dari Pengembang
  15. Artefak scrum
  16. Scaling Scrum
  17. Sprint Backlog
  18. Apa itu Product Backlog?
  19. Apa itu Cerita Pengguna?
  20. Membuat Kisah Pengguna terbaik dengan INVEST
  21. Kesalahan Cerita Pengguna yang paling umum
  22. Kriteria Penerimaan Cerita Pengguna
  23. Estimasi dan Poin Cerita di Scrum
  24. Perencanaan Poker
  25. Game Estimasi Tim
  26. Mendefinisikan Kenaikan
  27. Acara Scrum
  28. Apa itu Sprint di Scrum?
  29. Komitmen Tim Scrum - Sasaran Produk, Sasaran Sprint, dan Definisi Penyelesaian
  30. Apa itu Grafik Burndown?
  31. Bagaimana cara membuat dan menafsirkan grafik burndown?
  32. Keuntungan dan kerugian dari grafik burndown
  33. Papan Kanban di Scrum dan Scrumban
  34. Kecepatan dalam Scrum - Kecepatan Tim Pengembang
  35. Scrum Harian
  36. Perencanaan Sprint
  37. Ulasan Sprint
  38. Apa itu Retrospektif Sprint?
  39. Kesalahan umum selama Sprint Retrospective
  40. Pemeliharaan Backlog Produk