Mengapa dan untuk alasan apa pengembang mungkin tidak menyukai "scrum harian"? [Tutup]


40

Ada keuntungan dalam memegang scrum harian, seperti:

  1. Tim saling berkoordinasi
  2. Semua orang tahu berapa banyak tugas yang telah dilakukan
  3. Burndown chart menjadi semakin lengkap
  4. Papan tugas diperbarui
  5. Itu tidak bertahan lama, 15 menit tidak akan membunuh siapa pun

Namun, baru-baru ini (setelah 6 bulan menerapkan dan menggunakan scrum), saya merasa bahwa pengembang kami tidak terlalu menyukai scrum setiap hari. Orang-orang hanya memperbarui papan tugas, tanpa cukup menjelaskan dan tampaknya mereka bosan karenanya. Saya melihat bahwa ketika karena alasan apa pun, kami tidak memegangnya, mereka baik-baik saja menjadi sangat bahagia.

Aku hanya tidak tahu apa yang salah dengan ini. Apakah ada alasan yang disebutkan di suatu tempat untuk kerugian "scrum harian" dapat miliki untuk tim? Apa yang bisa menjadi alasan bagi pengembang bosan dengan scrum harian?


14
Masalah saya dengan rapat scrum harian adalah mereka memulai dengan topik baru dan dengan cepat berubah menjadi keluhan sekitar 45 menit tentang manajemen, persyaratan tidak jelas, hambatan teknis dan politik, dan kualitas bug yang buruk yang ditulis QA.
maple_shaft

2
@Michael, Kami tidak memiliki master scrum, itu masalahnya. Satu-satunya alasan kami melakukan rapat scrum harian adalah karena manajemen yang mengakar menjalankan proyek ke tanah di mach 10 dan mereka perlu membuat perubahan proses yang tidak berarti dangkal untuk tujuan tunggal tampak seolah-olah mereka sedang menangani "masalah yang sulit dipahami". Tentu saja mengatakan kita perlu melakukan rapat scrum harian jauh lebih mudah daripada mengatakan, "mungkin jika saya fokus pada tidak mengatur pengembang mikro dan makan siang 4 jam setiap hari maka kita akhirnya bisa mengeluarkan perangkat lunak berkualitas"
maple_shaft

19
Sejujurnya, saya benar-benar benci diminta pergi ke pertemuan setiap hari dan memberi tahu semua orang apa yang telah saya lakukan. Saya mencoba melakukan pekerjaan . "Atmosfer" yang mengelilingi pertemuan - pergantian konteks, obrolan lorong, menunggu ruang - akan memakan waktu seperti woah. Lebih baik - IMO - untuk mengadakan pertemuan organik sesuai kebutuhan.
Paul Nathan


6
Scrum harian memberi terlalu banyak tekanan pada pengembang untuk menghasilkan sesuatu setiap hari. Mereka membutuhkan kebebasan untuk bereksperimen secara bebas tanpa harus membenarkan eksperimen mereka kepada siapa pun setiap hari. Mingguan lebih baik.
Acumenus

Jawaban:


42

Saya memiliki pengalaman berpartisipasi dalam tim "SCRUM" dengan beberapa majikan. Tampak bagi saya bahwa para manajer mengambil "rapat scrum harian" sebagai poin utama SCRUM, dan menetapkannya sebagai tujuan, alih-alih memilikinya seperti apa adanya: cara untuk mencapai siklus pengembangan yang lebih efektif .

Sangat cepat rapat 15 menit menjadi rapat 45 menit, pembaruannya tidak efektif karena orang akan sibuk menguap dan berpikir "kapan kita bisa pergi" daripada mendengarkan orang lain, dan itu juga akan merusak rutinitas orang (saya, misalnya, seorang burung hantu, dan mulai bekerja pada jam 9 pagi untuk pertemuan bodoh ini setiap hari adalah alasan yang cukup baik bagi saya untuk keluar dari pekerjaan).

Ketika manajer mengambil beberapa ide yang mungkin bagus jika diterapkan dengan benar, dan membawanya ke ekstrem - mereka mendapatkan kebalikan dari hasil yang mereka harapkan. Saya pribadi berpikir bahwa semakin banyak pertemuan yang saya ikuti - semakin sedikit pekerjaan yang saya lakukan. Saya memiliki 2 pertemuan rutin seminggu di kalender saya dan saya biasanya melewatkan salah satunya. Rapat adalah untuk manajer, biarkan pengembang melakukan pekerjaannya.

Saya yakin akan ada banyak penggemar SCRUM yang akan mengatakan "Tapi ini luar biasa" - yah, selamatkan, saya sudah mendengar semuanya.


5
Ketika 'hari sebelumnya' dibahas, itu berarti sejak pertemuan terakhir dan diadakan kira-kira 24 jam di depan. Tidak ada alasan Anda tidak dapat memilikinya saat memulai hari atau beberapa jam kemudian. Setiap orang tidak dipaksa untuk kode pada saat yang sama.
JeffO

6
@ Jeff - kirim ke manajer. Bagaimanapun, SCRUM baik untuk pengembangan ad-hoc, tetapi tidak akan bekerja dengan baik untuk proses pengembangan jangka panjang yang telah direncanakan sebelumnya. Ketika saya memiliki tugas yang berlangsung selama seminggu, apa yang harus saya bicarakan pada pertemuan harian? "Aku selesai menulis fungsi lain"? Siapa peduli?
littleadv

6
@ littleadv: "Saya terus bekerja pada fungsi X. Saya tidak memiliki penghalang jalan" sudah cukup untuk rapat scrum. Itu informasi penting bagi tim. Adapun scrum hanya baik untuk pengembangan ad-hod, saya harus tidak setuju. Saya telah melihatnya digunakan untuk proyek yang panjang, berkelanjutan, dan sukses . Terserah tim untuk melakukannya dengan sepenuh hati, tapi itu bukan peluru perak. Ini bekerja untuk beberapa tim, bukan untuk yang lain.
Bryan Oakley

3
+1 Saya belum pernah bertemu scrum harian yang membutuhkan waktu 15 menit. Sebagian besar mengambil setidaknya setengah jam, dan kehilangan fokus cukup cepat :( Saya pikir ada nilai dalam pembaruan status singkat, tapi sayangnya tidak ada toko tempat saya bekerja berhasil membuatnya pendek.
Andres F.

5
Masalah lain adalah ketika "mintalah para devs memberi tahu kami apa yang terjadi" pertemuan menjadi "mintalah para devs memberi tahu kita semua tentang pemikiran mereka tentang ke mana mereka akan pergi selanjutnya". Sangat berbeda, dan membutuhkan lebih banyak waktu. Dan kemudian manajemen berpikir, oh karena kita semua ada di sini, mari kita adakan pertemuan lain di sini!
Spencer Rathbun

35

Saya akan menemukan setiap hari berdiri membosankan dan tidak berguna jika saya merasa ada sedikit atau tidak ada nilainya di dalamnya. Ada beberapa hal yang dapat mengurangi utilitas standup harian.

  • Informasi yang dibagikan tidak pernah menyinggung atau memengaruhi saya dengan cara apa pun.
  • Tidak adanya kepemilikan tim dan semua orang selalu mengerjakan proyek mereka sendiri.
  • Tidak adanya komunikasi tim di luar standup.
  • Kurangnya kemajuan yang terlihat atau dikomunikasikan.
  • Tidak adanya informasi untuk dibagikan.

Ini hanya di luar kepala saya, tetapi selalu ada alasan yang lebih mungkin.

Mungkin Anda harus bertanya langsung kepada pengembang mengapa mereka tampaknya tidak tertarik? Jika Anda ingin lebih banyak / komunikasi yang lebih baik itu harus dimulai dengan Anda.


Tapi @dietbuddha, bagaimana scrum, jika pengembang tidak berbagi informasi atau bagian dari proyek?
Saeed Neamati

4
" Informasi yang dibagikan tidak pernah menyinggung atau mempengaruhi saya dengan cara apa pun, " membuat scrum harian saya membosankan.
René Nyffenegger

2
@ Saeed Neamati: A Thing tidak harus seperti itu untuk yang namanya. Itu tidak berarti Anda tidak melakukan Scrum. Saya tidak bekerja dengan Anda, jadi saya tidak bisa tahu. Bisa juga ada perbedaan antara bagaimana hal itu seharusnya dilakukan dan bagaimana mereka sebenarnya dilakukan.
dietbuddha

19

Beberapa masalah yang terjadi dengan pertemuan SCRUM harian:

  • mereka yang bertahan terlalu lama. Anda tidak ingin ada manajer pria di harian itu karena mereka adalah akar penyebab masalah semacam ini. Lihat bagaimana biasanya mereka yang menggunakan kursi (ya, harus membela mereka adalah untuk memikat orang agar cepat)
  • harus mendengar tentang seseorang (atau 2 atau 3 devs) yang menggambarkan masalah terisolasi apa pun yang ia miliki alih-alih memutuskan untuk menjadwalkan pertemuan nyata lain nanti untuk membahasnya dengan yang bersangkutan
  • jam bodoh. Pertemuan-pertemuan itu tidak harus terjadi di pagi hari: Anda tidak berbicara tentang apa yang telah Anda lakukan kemarin dan memutuskan apa yang akan Anda lakukan hari ini; Anda berbicara tentang apa yang telah Anda lakukan antara harian terakhir dan yang satu ini dan memutuskan apa yang akan Anda lakukan sampai yang berikutnya.
  • kurangnya kepemilikan aplikasi untuk para devs. SCRUM berfungsi jika devs tidak diperlakukan sebagai kode monyet. Tanda pertama dari proses yang salah adalah ketika para devs bukan yang mengevaluasi berapa banyak waktu yang akan dilakukan.
  • jam bodoh lagi. Jika bagian dari tim telah mulai mengerjakan beberapa hal dan "berada di zona" ketika harian terjadi, itu akan mengganggu. Waktu yang baik untuk melakukan itu setiap hari adalah ketika tidak ada orang yang bekerja (setelah makan siang misalnya, atau sebelum memulai beberapa diskusi untuk makan siang).

3
@jhocking: Sebenarnya, sangat baik bagi manajer untuk menghadiri rapat (atau pemangku kepentingan, atau siapa saja yang tertarik). Namun, aturannya adalah: Hanya pengembang yang bicara. Semua orang hanya berbicara ketika diminta. Sesederhana itu ... (dan ya, para penghuni hutan kami menghadiri rapat harian, dan mereka mematuhi aturan itu).
sleske

2
Jika manajer Anda dapat menaati aturan itu bagus.
jhocking

Saya secara pribadi mengalami kekurangan master scrum yang menyalahgunakan argumen "jam fleksibel" untuk menahan harian ketika itu nyaman bagi mereka , jadi itu salah satu ladang ranjau yang potensial. Yang lain mulai "setelah" sesuatu. Itu membuat tampilan sehari-hari seperti sesuatu yang "disatukan", sedangkan memulai "sebelum" tidak hanya mematahkan persepsi ini, tetapi juga membantu menjaga rapat tetap singkat. Itulah mengapa pagi hari sering lebih disukai - harian terjadi sebelum pekerjaan yang "tepat" dimulai.
mikołak

1 untuk poin terakhir Anda (rencanakan saat tidak mengganggu pekerjaan, yaitu hal yang tidak bisa saya selesaikan semalam sebelumnya atau memiliki ide cemerlang tentang di rumah).
Cees Timmerman

14

Pengaturan waktu adalah pembunuh bagi banyak orang. Pemrogram suka kode terlambat, tidur larut dan masuk setelah pagi sibuk. Harus berada di kantor pada waktu yang tetap - terlalu dini bagi mereka. Dan sudah terlambat untuk orang lain yang mungkin datang lebih awal dan sudah mulai bekerja.

Flow adalah masalah lain. Seorang programmer yang mengalir dengan beberapa fitur akan bekerja hingga larut malam, pulang dan kembali diisi ulang dan siap untuk melanjutkan. Harus duduk melalui pertemuan dengan sebagian besar masalah yang tidak berhubungan dapat mengalihkan perhatiannya.


+1 Saya memiliki masalah yang sama dengan proses yang meresepkan terlalu banyak pertemuan. Lihat juga paulgraham.com/head.html , poin 1 dan 2.
Giorgio

11

Pengamatan saya terlalu sering pertemuan-pertemuan ini bagi para manajer untuk terlihat dan merasa seolah-olah mereka benar-benar melakukan sesuatu daripada berguna untuk tim dan proyek.

Misalnya, tim ditugaskan untuk melakukan serangkaian perbaikan bug pendek pada proyek yang berbeda. Mereka benar-benar tidak bekerja sebagai tim tetapi sebagai individu. Namun, karena kebijakan perusahaan / departemen mengamanatkannya, ketua tim / manajer tetap mengadakan rapat scrum harian. Semua yang dicapai adalah menghabiskan 15+ menit untuk pertemuan yang tidak berguna dan mengatasi 15-30 menit gangguan dan kurangnya produktivitas sebelum dan sesudah pertemuan.

Sekarang, saya telah melihat scrum dilakukan dengan baik dalam sebuah proyek yang memiliki tenggat waktu yang ketat dan membutuhkan banyak koordinasi antara orang-orang yang bekerja pada berbagai bagian. Dalam konteks itu, itu adalah sistem yang hebat. Tetapi, dalam konteks "Kami mengadakan rapat karena kami adalah toko scrum / gesit dan itulah yang kami kira harus dilakukan" benar-benar dapat menyedot.


10

Pastikan tidak ada yang memonopoli pertemuan.

Jika 4 dari pengembang mendapatkan omongan mereka keluar dari jalan dalam 5 menit, dan 10 menit berikutnya yang dihabiskan mendengarkan pemimpin tim merinci semua menakjubkan , mengagumkan perkembangan baru dia buat, yang kebanyakan tidak seperti biasa atau sebagai mengagumkan seperti yang dia pikirkan, orang akan cepat bosan.


Mundur sejenak dan pikirkan tim Anda:

  • Apakah mereka bekerja secara efektif?
  • Apakah tugas selesai tepat waktu?
  • Apakah kodenya kuat dan ditulis dengan baik?
  • Apakah tim memastikan tidak ada yang jatuh melalui celah?
  • Apakah tim berkoordinasi sendiri sehingga mereka tidak menduplikasi pekerjaan atau menginjak kaki masing-masing?

Jika jawaban Anda untuk semua hal ini adalah "Ya", mungkin Anda harus mempertimbangkan mengapa Anda ingin memaksakan pekerjaan yang sibuk seperti rapat harian, bagan pembakaran, dan papan tugas di tim Anda. Nilai apa yang ditambahkannya? Apakah Anda ingin menghasilkan data birokrasi semata-mata untuk kesenangan Anda sendiri atau Anda mencoba membuat tim lebih produktif?

Apakah ada penurunan produktivitas sejak scrum harian berhenti, atau apakah semuanya berjalan sama seperti sebelumnya? Jika tidak ada yang berubah, mengapa melanjutkan pertemuan?


9

15 menit. Apakah itu 15 menit (ditambah waktu untuk mempersiapkannya) menyampaikan informasi yang cukup baru dan berguna antara anggota tim untuk meningkatkan produktivitas tim untuk hari mendatang dengan nilai lebih dari 15 menit? Jika tidak ada jumlah konten scrum yang berguna setiap hari, anggota tim mungkin berpikir bahwa mereka akan membuat kemajuan yang lebih jauh ke arah tujuan jika mereka keluar dari pertemuan ini secepatnya dan kembali bekerja.

Jika Anda hanya ingin memperbarui papan dan bagan sesering mungkin, letakkan salinan konsep di wiki.


8

Saya sarankan jika Anda mengadakan rapat Retrospektif untuk melihat "Apa yang berjalan dengan baik" dan "Apa yang tidak berjalan dengan baik" dan melihat apakah para pengembang membuat daftar pertemuan harian itu sendiri sebagai pemborosan waktu. Maka Anda perlu mengatur ulang sedikit.

Pengalaman pribadi saya:

  • Tujuannya adalah untuk mengetahui apa yang kita lakukan hari ini dan di mana kita berada kemarin. Alih-alih berpegang pada agenda, itu masuk ke diskusi teknis blocker antara 2 orang dan 15 lainnya bosan. Identifikasi masalah tetapi diskusikan di luar
  • Orang tidak masuk ke ruang rapat tepat waktu, dan ini menjadi siklus yang dilakukan oleh beberapa orang dengan sengaja. Jadi Scrum Master perlu berdiskusi dengan mereka di luar pertemuan untuk memastikan mereka memulai dan mengakhiri tepat waktu.
  • Kami sudah memperbarui grafik burndown di luar pertemuan Scrum sehingga itu bukan tujuan utama dari stand-up harian.

+ 1 + 1 + 1 Ini jawabannya. Tempat di mana saya pernah bekerja yang tidak melakukan retrospektif, memiliki semua masalah yang digariskan semua orang. Di mana saya bekerja sekarang kami memiliki Scrum, Scrum of scrums (interteam), retrospektif dan bahkan retrospektif dari mereka. Semua untuk memastikan bahwa hal-hal yang mengganggu Anda dan tidak berfungsi berhenti atau berubah sebanyak mungkin dan hal-hal yang berjalan dengan baik dilanjutkan. Tanpa scrum ini menjadi sangat membosankan dan di luar topik dengan mudah. Saya juga percaya bahwa "pertemuan" yang direndahkan oleh begitu banyak orang hebat jika mereka memiliki komunikasi yang sangat baik, dengan topik, tepat waktu dan singkat.
Michael Durrant

7

Perlawanan datang ketika: 1) Mereka digunakan untuk memaksa orang bergegas masuk jam 9 pagi. Ini stres ekstra ketika kereta terlambat. 2) Kepemimpinan scrum yang buruk. Pemimpin harus memberi tahu orang-orang untuk mengambil barang-barang di luar jalur daripada meminta orang berdiri mendengarkan sesuatu yang tidak mempengaruhi mereka. 3) konten yang tidak berharga. Sekali lagi ini adalah masalah kepemimpinan scrum. Ini seharusnya menjadi forum untuk mengatasi kemacetan, masalah lintasan dan kolaborasi potensial. Apa yang sebenarnya terjadi adalah semua orang hanya mengatakan apa yang mereka harapkan untuk bekerja pada hari itu yang tidak berguna atau menarik bagi orang lain. 4) Berdiri. Saya tidak akan berdiri untuk berdiri. Logika di balik berdiri adalah bahwa hal itu mendorong orang untuk bersikap singkat. Orang sebenarnya hanya mengoceh tanpa peduli.


4

Saya sudah berhasil dan menjadi bagian dari tim scrum berkali-kali. Alasan utama mengapa pengembang tidak menyukai scrum adalah:

  • Karena mereka dijalankan oleh master scrum yang sangat buruk, jika itu berubah menjadi 45 menit master scrum Anda perlu ditingkatkan untuk mengendalikan scrum.
  • Alasan terbesar dan paling Jujur mengapa mereka tidak menyukainya, adalah karena sangat sulit untuk bersembunyi dalam etika kerja yang buruk, yaitu, lebih terang-terangan, itu menunjukkan orang-orang malas. Beberapa devs yang pernah bekerja sama dengan saya mengejutkan, mereka membutuhkan waktu berhari-hari melakukan tugas yang seharusnya 30 menit. Seorang PM yang baik harus menghilangkan hambatan bagi para dev yang berarti mereka harus dapat membajak tugas-tugas mereka dalam sprint. Devs tidak menyukainya karena mereka harus berdiri setiap hari dan menunjukkan kemajuan yang telah mereka buat. Ini menyebabkan kecemasan ketika mereka tidak dapat menunjukkan kemajuan karena alasan apa pun. Jika itu karena masalah yang valid master scrum yang baik harus segera menyelesaikan masalah itu.

Masalah muncul ketika master scrum tidak memiliki otoritas, keterampilan atau kemampuan untuk menyelesaikan masalah pemblokiran. Bahkan saya telah melihat beberapa masalah penguburan dengan harapan mereka akan pergi. Ini bencana.


4

Terus terang, dalam 99% rapat scrum harian yang saya ikuti, hampir semua diskusi / pertanyaan / jawaban dapat diatasi dengan beberapa email.

Jujur saya pikir kita perlu menunjukkan alasan yang lebih valid untuk TIDAK mengadakan pertemuan. Bangun lingkungan di mana ketika saatnya untuk memasukkan semua orang ke ruangan sendiri, itu lebih baik menjadi alasan yang baik dan diorganisir untuk memaksimalkan efisiensi waktu.

Saya benci rapat secara umum, dan lebih suka menggunakan konferensi video, telepon, email, apa pun yang memungkinkan saya untuk masuk atau tetap bekerja tanpa harus bangun dan mengganggu aliran produktivitas saya.

Saya pribadi berpikir jika Anda memiliki lebih dari empat pertemuan dalam periode 8 jam maka proyek tidak dikelola dengan baik.


ini bahkan tidak berusaha menjawab pertanyaan yang diajukan: "Mengapa dan untuk alasan apa pengembang mungkin tidak menyukai" scrum harian "?"
nyamuk

1
Saya baru saja melakukannya. Saya tidak suka scrum harian karena tidak perlu. Beberapa email dapat dengan mudah menangani sebagian besar kebutuhan.
Alex M

2
Pikiran yang menarik ... dan mungkin itu karena pengalaman scrum SAYA tidak baik. Mungkin "setiap hari" harus "mingguan" dalam kasus-kasus tertentu. Saya tahu bagi saya setiap minggu akan lebih efektif daripada setiap hari.
Alex M

4

Ada banyak faktor yang berkontribusi terhadap ketegangan dalam rapat. Pertimbangkan ini sebagai beberapa alasan penting mengapa rapat mungkin membuat Anda lebih mahal daripada nilainya:

  • Fokus - perangkat lunak versus rapat
  • Manajemen - manajer perlu pengukuran
  • Kepribadian - Introvert vs Ekstrovert
  • Waktu - menyela, Waktu Pembuat dan Manajer
  • Sasaran, Prioritas

Masing-masing faktor tersebut dijelaskan di bawah ini,

Fokus - Saya menikmati pengembangan perangkat lunak, dan itu termasuk memikirkan tantangan (masalah), menciptakan solusi, membangun perangkat lunak, dan rapat mengalihkan perhatian dari fokus pada tugas-tugas yang membangun perangkat lunak. Ada keadaan yang disebut " Aliran " di mana pengembang terbenam dalam tantangan (masalah), telah membangun model mental dari solusi, dan memiliki fokus penuh untuk membangun solusi. Pengembang dapat bekerja hingga tengah malam, pergi hanya untuk makan dan tidur, kemudian kembali ke keadaan dekat dengan tempat mereka pergi.

Pengembang perlu menghindari gangguan, dan banyak yang menemukan bahwa ada keuntungan untuk kode hingga larut malam (mereka menghindari kebisingan, panggilan telepon, kantor yang sibuk, dan rekan non-pengembang mengganggu pekerjaan mereka). Dan ketika Anda telah bekerja sampai jam 10, 11, atau 12 siang, tidak masuk akal untuk datang kerja nanti (10, 11, siang?). Apakah masuk akal untuk mengharapkan pengembang bekerja dari jam 9 pagi sampai tengah malam?

Rapat scrum (dan apa saja) mengalihkan perhatian pengembang dari tujuan utamanya, yaitu membangun perangkat lunak.

Manajemen - Manajer perlu mengukur untuk menjadi sukses, maka kebutuhan untuk jadwal, pengiriman, jadwal, prioritas, dan pertemuan untuk mengukur dan melaporkan kemajuan, dan untuk mengekspos dependensi, keterlambatan, dan bidang risiko. Tantangan dengan Scrum adalah bahwa seorang manajer membutuhkan hal-hal ini, tetapi pengembang perlu fokus. Rapat melayani manajer, dan menyediakan cara bagi manajer untuk memperoleh, mengukur, dan melacak status dan kemajuan, tetapi rapat jarang memberikan manfaat bagi pengembang. Pertimbangkan bahwa manajer memberikan nilai lebih ketika mereka menangani gangguan, menghilangkan hambatan, dan memungkinkan pengembang untuk fokus membangun perangkat lunak.

Ada solusi untuk kebutuhan rapat. Seorang manajer dapat mengunjungi pengembang mereka, meminta laporan status, mengadopsi protokol ketika gangguan kurang mengganggu, atau mengadopsi kebijakan bahwa pengembang untuk memberi tahu mereka tentang kemajuan ketika pengembang itu interupsi. Lihat pembahasan waktu mengapa ini penting.

Kepribadian - Pertimbangkan bahwa beberapa orang introvert dan yang lain ekstrovert. Ekstrovert menikmati interaksi sosial, dan diisi ulang oleh mereka. Manajer biasanya ekstrovert (karena ekstrovert biasanya lebih baik dengan interaksi sosial), meskipun introvert dapat berhasil sebagai manajer. Introvert dapat menikmati dan bahkan unggul dalam interaksi sosial, tetapi diisi ulang oleh kesendirian. Pengembang sering introvert, dan berhasil bekerja sendiri (atau dalam tim kecil) karena mereka tidak "memerlukan" interaksi sosial; mereka bisa senang bekerja sendiri pada masalah (meskipun ekstrovert juga bisa menjadi pengembang). Rapat scrum harian bisa menjadi pertemuan sosial, bagus untuk ekstrovert, tetapi tidak begitu baik untuk introvert.

Waktu - Pengembang tidak dapat menulis kode saat mereka sedang rapat. Mereka juga tidak dapat memikirkan masalah-masalah sulit (kecuali mereka melakukan brainstorming), sementara terganggu oleh pertemuan. Pengembang membutuhkan blok besar waktu tanpa gangguan untuk fokus membangun perangkat lunak. Rapat adalah gangguan yang mengalihkan upaya mereka. Ketika Anda telah tenggelam dalam memecahkan masalah selama berjam-jam, hampir selesai, dan seseorang mengatakan "waktu untuk scrum", Anda terganggu, dan mungkin kehilangan jam kerja sambil "memindahkan gigi". Atau Anda tetap bekerja sampai jam 11:00 malam, meninggalkan pekerjaan, pulang ke rumah, tidur dengan masalah, bangun, kembali bekerja siap untuk menyelesaikan masalah, dan kemudian disela setelah satu jam mengerjakan suatu masalah, karena itu adalah "waktunya untuk scrum".

Paul Graham memiliki artikel yang sangat bagus tentang Waktu Pembuat vs. Waktu Manajer, yang menjelaskan masalah ini jauh lebih baik daripada saya. Cukup untuk mengatakan bahwa gangguan rapat, baik yang direncanakan atau tidak direncanakan dapat memutus arus, dan memaksa pengembang dari waktu Maker ke waktu Manajer. Percayalah, Anda ingin pengembang pada waktu Maker.

Sasaran, Prioritas - Pengembang dan manajer memiliki tujuan dan prioritas yang berbeda. Manajer memiliki tanggung jawab untuk melacak jadwal, meminimalkan biaya, memastikan bahwa laporan mereka bertanggung jawab, dan bahwa mereka melakukan. Pengembang memiliki tujuan untuk membangun perangkat lunak yang mengatasi tantangan / masalah. Tujuan-tujuan ini tidak bertentangan, tetapi mekanisme komunikasi yang menciptakan ketegangan. Rapat melayani kebutuhan manajer dan mengoptimalkan waktu manajer, tetapi mereka bertentangan dengan kebutuhan pengembang. Rapat scrum membuang aturan pertemuan pertama, "punya agenda", dan cenderung berkeliaran lebih banyak. Dan rapat digunakan untuk mengoptimalkan komunikasi (untuk manajer), tetapi biayanya memakan waktu pengembang (gangguan, kehilangan aliran, dll).

Apa tujuannya? Untuk membangun perangkat lunak yang memenuhi kebutuhan, dengan cepat dan dengan kualitas, sementara kendala adalah (kualitas, waktu, biaya, proses). Scrum dan metodologi gesit lainnya mengenali kendala proses, dan mencoba untuk meminimalkan faktor itu, dan telah berhasil karena mereka meminimalkan kendala itu. Tetapi menambahkan rapat memang menghabiskan waktu, dan interupsi itu membuat pengembang lebih mahal daripada durasi rapat.


0

Ubah rapat untuk memastikannya memberikan manfaat:

  1. Jadwalkan pada waktu yang menawarkan kenyamanan. Mengapa tidak bisa 30 menit setelah pekerjaan dimulai sehingga semua orang dapat meninjau email dan mengatur pemikiran mereka untuk pertemuan tersebut. Brevity membutuhkan perencanaan. Yang tidak siap bisa mengoceh selamanya.
  2. Identifikasi masalah yang bisa dihindari seandainya masalah dikomunikasikan selama pertemuan. Setiap orang perlu memahami apa gunanya.
  3. Lakukan apa pun untuk menjaga input semua orang agar tetap minimum. Itu bukan tempat untuk perdebatan. Dorong orang untuk menjadwalkan pertemuan pribadi di luar pertemuan harian yang berfokus pada topik yang perlu dibahas. Aturan: hanya satu orang yang berbicara sekaligus.

Semua pengeluh perlu memastikan bahwa mereka tidak berkontribusi terhadap masalah. Jika Anda dapat mencapai tujuan Anda untuk scrum harian tanpa harus melakukannya dengan cara yang tidak terlalu menyakitkan, kami ingin mendengarnya.

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.