Apakah Agile manajemen mikro yang baru?


80

Pertanyaan ini sudah lama muncul di kepala saya, jadi saya ingin bertanya kepada mereka yang mengikuti praktik lincah / scrum di lingkungan pengembangan mereka.

Perusahaan saya akhirnya memberanikan diri untuk menggabungkan praktik lincah dan telah mulai dengan tim 4 pengembang dalam kelompok lincah berdasarkan percobaan. Sudah 4 bulan dengan 3 iterasi dan mereka terus melakukannya tanpa sepenuhnya gesit untuk kita semua. Hal ini disebabkan oleh fakta bahwa kepercayaan manajemen untuk memenuhi persyaratan bisnis dengan permintaan jenis ad hoc dari atas.

Baru-baru ini, saya berbicara dengan pengembang yang merupakan bagian dari inisiatif ini; mereka mengatakan kepada saya bahwa itu tidak menyenangkan. Mereka tidak diizinkan untuk berbicara dengan pengembang lain oleh master Scrum mereka dan tidak diizinkan untuk menerima panggilan telepon apa pun di area kerja (yang mungkin tidak masalah sampai batas tertentu). Sebagai contoh, jika saya ingin berbicara dengan teman saya untuk tendangan yang ada di tim lincah, saya tidak diizinkan tanpa persetujuan dari master Scrum; yang duduk tepat di sebelah tim lincah.

Gagasan dari semua ini atau gesit adalah untuk memberikan kekosongan yang lengkap untuk pengembang tangkas dari gangguan apa pun dan meminta mereka dimasukkan ke dalam 6 jam produktif yang baik Baiklah, teman-teman, saya bukan guru yang gesit tetapi apa yang saya baca dari dokumen Yahoo agile rollout dan sejenisnya untuk organisasi lain, itu memberi saya perasaan bahwa gesit itu tidak murah. Dibutuhkan sumber daya dan anggaran untuk menanamkan tangkas ke dalam tim dan memperbaiki masalah saat mereka tiba untuk mengembalikan mereka ke jalur yang benar.

Sebagai permulaan, ini membutuhkan pelatihan untuk pengembang dan pelatihan untuk manajer dan lain-lain, dll ... Master Scrum saat ini adalah seorang manajer yang mengambil beberapa hari kelas pelatihan tangkas yang dibayar oleh manajemen sekarang memimpin tim tangkas ini. Saya juga mendengar dalam pertemuan itu bahwa manifesto lincah tidak menentukan bahwa lincah tidak diatur dalam batu dan disesuaikan secara berbeda untuk masing-masing perusahaan. Yah, semua itu terdengar bagus dan masuk akal.

Sebagai kesimpulan, saya selalu berpikir gesit seharusnya membawa harmoni dalam tim pengembangan yang menghasilkan pengembang yang bahagia. Namun, saya mendapatkan perasaan yang sangat berlawanan ketika berbicara dengan para pengembang di tim tangkas. Mereka tidak bahagia bahwa mereka tidak dapat berbicara apa pun selain bekerja, duduk dengan tenang sepanjang hari hanya bekerja, dan mereka merasa itu hanyalah cara lain bagi manajemen untuk membuat mereka bekerja lebih banyak.

Tolong beritahu saya, jika ini adalah salah satu contoh praktik baik yang digunakan untuk tujuan keuntungan egois untuk lebih banyak dolar? Atau mungkin, hanya kami para pengembang seperti saya dan tim lincah ini merasa bahwa mereka tidak suka bekerja di lingkungan di mana mereka hanya bernapas karena mereka sedang bekerja.


Ini adalah perusahaan di bidang perawatan kesehatan yang memiliki kantor di seluruh AS. Ini benar-benar terasa seperti lincah gaya koboi yang membuat saya benar-benar tidak ingin lincah sama sekali, terutama di perusahaan saya saat ini.

Semua itu ada hubungannya dengan manajemen yang benar-benar murah. Memotong kopi mahal untuk versi yang lebih murah, menekankan pada tabungan dan menjadi produktif sambil tetap bersandar mungkin.

Perasaan saya adalah bahwa seseorang dalam manajemen di belakang pintu membuang ide ini, yang gesit membuat Anda menghasilkan lebih banyak sehingga kami dapat menunjukkan kepada atasan kami bahwa kami memproduksi lebih banyak dengan jumlah karyawan yang sama. Atau, mungkin, ini akan memungkinkan kami untuk mengurangi jumlah karyawan jika itu masalahnya.

Mereka mengadakan rapat harian 5 menit. Tetapi tidak diizinkan untuk mengobrol atau berbicara dengan seseorang di luar tim mereka. Semua fokus ada pada pekerjaan.


71
Saya telah melihat lebih banyak pelanggaran atas nama lincah daripada yang ingin saya komentari. Sering kali "kita melakukan lincah" berarti "kita membuang semua kemiripan proses dan melakukan apa yang kita inginkan, Yeehaw!" (untuk referensi koboi yang jelas). Lingkungan yang tenang pasti membantu, tetapi Anda harus memungkinkan pengembang untuk berbicara satu sama lain dan menyelesaikan masalah - tanpa persetujuan diktator scrum .
Berin Loritsch

28
Nah, Anda tidak melakukan Agile ...
CaffGeek

13
Ini benar-benar pidato. Bukan pertanyaan.
JohnFx

8
2 hari pada kursus master scrum bersertifikat tidak menjadikan manajer master scrum, seperti 24 jam mengajar diri sendiri c ++ dalam 24 jam tidak membuat Anda mampu menjadi programmer c ++. Mereka hanya melakukan kesalahan.
Matt

9
wajib membaca: Manifes Agile Setengah-Arsed "Kami telah mendengar tentang cara-cara baru mengembangkan perangkat lunak dengan membayar konsultan dan membaca laporan Gartner ..."
gnat

Jawaban:


89

Anda menggambarkan kediktatoran manajerial, bukan gesit. Agile adalah tentang pengembangan bertahap dalam bidang persyaratan yang berubah, bukan tentang mendikte orang tentang cara mereka melakukan pekerjaan secara individu.


7
Satu-satunya hal yang dekat yang bisa saya temukan adalah posting "Joel on Software" pada 12 hal teratas yang harus disediakan setiap perusahaan untuk programmer mereka. Salah satu dari 12 adalah tempat yang tenang untuk bekerja. Tapi aku ragu Joel Spolsky bersungguh-sungguh.
Berin Loritsch

5
Tempat kerja yang tenang akan menjadi tempat di mana jika Anda tidak memiliki percakapan, hal-hal umumnya tenang, dan di mana Anda dapat melakukan percakapan tanpa mengganggu orang lain. Itu berarti tidak ada budaya paging orang melalui interkom, dan penggunaan generator white noise atau metode lain untuk meminimalkan tingkat suara yang jelas di daerah di mana banyak orang bekerja. Aturan tidak berbicara tidak membuat tempat kerja tenang.
Kevin Cathcart

5
@Kevin Cathcart, kami sepakat untuk hal itu. Sekarang, saya pernah berada di perusahaan di mana yang sebaliknya adalah benar. Kami memiliki ~ 40 orang di bullpen dengan meja terbuka dan tanpa kubus. Satu-satunya tim yang bisa menyelesaikan apa pun adalah yang membuat sebagian besar kebisingan. Itulah tipe lingkungan yang ingin Anda lindungi.
Berin Loritsch

8
@Kevin - Departemen pengembangan saya adalah pertanian bilik terbuka, tepat di sebelah deretan tiga lonceng berlabel "Sale", "Big Sale", dan "Huge Sale". Beberapa kali sehari, orang-orang penjualan menelepon mereka dan berteriak "wooooo!". : - \
Dan Ray

2
@Dan saya punya serangkaian wawancara beberapa tahun yang lalu di mana tiga startup mengatakan kepada saya bahwa mereka harus memindahkan orang-orang penjualan dari para devs karena mereka juga! @ # $ Ing keras.
Erik Reppen

46

Mereka tidak diizinkan untuk berbicara dengan pengembang lain oleh master Scrum mereka dan tidak diizinkan untuk menerima panggilan telepon apa pun di area kerja

Ini benar-benar bukan bagian dari praktik Agile - dan masalah terpisah.

Motivasi metodologi Agile yang besar adalah peningkatan komunikasi antar pengembang. Membatasi pengembang <-> komunikasi pengembang adalah masalah terpisah dari praktik Agile. Saya tidak mengatakan ini tidak terjadi - itu jelas terjadi, dan itu dilabeli sebagai bagian dari peluncuran "gesit" di organisasi Anda, tetapi ini benar-benar masalah terpisah dari gesit (dan agak bertentangan dengan semangat pengembangan tangkas, IMO).


29
Ini benar-benar bertentangan dengan prinsip pertama dari Agile Manifesto: "Individu dan interaksi atas proses dan alat". Lihat agilemanifesto.org untuk informasi lebih lanjut.
Berin Loritsch

"Ini benar-benar bertentangan dengan prinsip pertama <i> Manifesto <XXX>"; ganti apa pun untuk XXX, dan Anda akan memiliki kultus pilihan Anda. ;-) Serius, bukankah ini membuat Anda bertanya-tanya?
CesarGon

5
@ CesarGon, dalam hal ini kita berbicara tentang prinsip-prinsip apa yang membuat kerja tangkas. Jika Anda tidak dapat mengacu pada prinsip-prinsip inti tangkas, maka mungkin Anda tidak ingin tangkas. Cukup mudah. Saya tidak mengatakan "masuk agama", saya mengatakan "lakukan apa yang Anda percayai". Serius, bukankah itu membuat Anda bertanya-tanya?
Berin Loritsch

1
@ CesarGon, apa yang OP jelaskan adalah tentang kebalikan dari maksud dari pedoman itu yang bisa Anda dapatkan. Pada titik apa Anda menganggap nada menengah Anda cukup dekat? Cara Anda berbicara kedengarannya seperti perbedaan 95% antara nada cukup dekat. Ayo. Dan beri saya kredit. Saya telah bekerja di dunia nyata dan mendefinisikan proses di perusahaan untuk waktu yang lama. Saya mengerti betul apa yang cukup dekat - dan apa yang OP jelaskan bukan.
Berin Loritsch

2
@Berin Loritsch: Saya memang memberi Anda kredit; bukan niat saya untuk tampil sebaliknya. Komentar awal saya tentang pemujaan mencoba terdengar bercanda sebagian, sebenarnya. Poin yang saya coba sampaikan adalah bahwa kita tidak perlu beberapa baris pada manifesto untuk mempertahankan sesuatu yang terang-terangan melawan akal sehat. OP menjelaskan situasi yang membuat semua alarm berdering. Saya harap Anda menerimanya dengan baik; maaf kalau saya terlalu kasar. :-)
CesarGon

31

Kedengarannya seperti implementasi tangkas yang cukup menyimpang. Agile, jika ada, harus mengurangi manajemen mikro, bukan meningkatkannya. Tim membuat komitmen dan bagian dari proses adalah bahwa manajemen percaya bahwa tim akan mencapainya. Scrum harian adalah cara bagi pengembang untuk berkomunikasi satu sama lain dan cara untuk menginformasikan apa yang mereka lakukan, bukan bagaimana mereka menghabiskan waktu mereka (yang merupakan kesalahan yang saya lihat di beberapa tempat). Bahkan proses estimasi harus menghapus penjagaan waktu eksplisit dari estimasi, karena Anda harus memperkirakan kompleksitas relatif, bukan berapa lama sebuah cerita (kesalahan umum lainnya). Mengontrol waktu yang dihabiskan pengembang adalah ciri manajemen mikro, dan menghilangkan waktu dari proses adalah salah satu prinsip inti lincah.


24

Lingkungan yang Anda gambarkan terdengar seperti varietas taman omong kosong pseudo-Agile .

Saya terlibat dengan Agile sebelum Agile. Sekitar tahun 2000 saya kehabisan kode, mendengar tentang Extreme Programming, mencobanya, dan menyukainya. Itu memberi saya sebagai pengembang konteks di mana memproduksi perangkat lunak yang solid adalah hal yang paling penting, dan itu memberi saya alat untuk meminimalkan banyak omong kosong yang membuat saya gila. Saya menyukainya.

Masalahnya hari ini, yang saya jelaskan secara rinci di tempat lain , adalah bahwa sebagian besar orang "mengadopsi Agile" hari ini tidak tertarik untuk meningkatkan apa pun jika itu membuat mereka tidak nyaman. Jadi bagi mereka, "Agile" hanyalah tongkat baru untuk mengalahkan pengembang dengan cara yang sama. Berbeda dengan, katakanlah, cara untuk secara radikal meningkatkan produktivitas sambil menghilangkan semua omong kosong yang memperlambat pembangunan.

Sekarang juga. Saya memulai sebuah perusahaan, dan saya akan menggunakan banyak XP, ditambah banyak trik lain yang saya sandarkan di dunia Agile. Tapi justru karena cerita seperti milikmu, aku tersentak setiap kali mendengar tentang adopsi Agile akhir-akhir ini.

Jadi untuk menjawab pertanyaan Anda secara langsung: Agile seharusnya bukan manajemen mikro yang baru. Itu harus tentang memberdayakan orang-orang yang melakukan pekerjaan aktual untuk menyelesaikannya. Tetapi dalam kasus Anda, Agile terdengar seperti kebohongan terbaru yang mereka sampaikan kepada Anda saat mereka menuruti insting buruk mereka sendiri. Untuk itu saya benar-benar minta maaf.


4
+1. Agile / scrum / xp atau apa pun hanya istilah "mumbo jumbo" untuk toko IT yang bukan perusahaan perangkat lunak yang sebenarnya. Seperti yang Anda katakan, tidak ada yang melakukan perubahan radikal saat mengubur kepala mereka di pasir dengan praktik ini. Yang perlu dibaca adalah Pengembangan Perangkat Lunak Lean yang luar biasa ini : Agile Toolkit dan letakkan semua BS di belakang. Praktek-praktek ini bukan untuk toko-toko TI adalah kesimpulan saya.
Smith James

23

Ini tidak gesit.

Pertama, Scrum tidak gesit . Scrum, terus terang, adalah omong kosong. Saya dibesarkan di sebuah rumah Pemrograman Ekstrim (secara harfiah - saya memiliki Kent Beck duduk di sofa ayah saya dan berbicara kepada saya tentang pengujian), dan saya dapat mengatakan langsung kepada Anda bahwa Scrum bukan. Scrum adalah alat manajemen proyek - ritme yang ditentukan untuk proyek pengembangan. Tetapi tidak ada yang bisa dikatakan tentang pengembangan itu sendiri, dan sangat sedikit untuk mengatakan tentang persyaratan, perencanaan, dan hubungan dengan pelanggan. XP memiliki banyak hal untuk dikatakan tentang semua itu; metodologi lain yang ingin menyebut dirinya gesit harus memiliki sesuatu untuk ditambahkan ke percakapan. Para pendukung Scrum menggambarkannya bukan sebagai proses, tetapi sebagai pembungkus untuk suatu proses. Seorang pria bijak pernah menunjukkan bahwa bungkus adalah barang yang Anda buang dan buang untuk mendapatkan barang-barang bagus.

Oke, teriaklah!

Kedua, prinsip dasar XP, yang saya yakini sangat penting untuk setiap proses gesit, adalah bahwa ia berpusat pada pengembang . Ini adalah cara memberi pengembang kekuatan untuk melakukan pekerjaan yang mereka tahu harus mereka lakukan, dan sering kali berhenti melakukannya. Tim yang gesit dapat disusun sebagai demokrasi atau otokrasi, tetapi pemimpinnya adalah pengembang. Ada peran untuk manajer proyek dan sebagainya - peran vital - tetapi itu bukan salah satu dari kepemimpinan tim. Memiliki manajer - maaf, 'scrum master' - duduk di sana memerintah orang-orang di sekitar adalah pertanda pasti bahwa tim tidak gesit.

Saya merasa harus ada yang ketiga. Tidak ada.


-1, saya tidak setuju. Pengembangan lincah juga berarti Anda memurnikan dan mempermudah proses dan juga kemampuan untuk beradaptasi dengan perubahan. Yang kebetulan persis tentang apa itu Scrum. Scrum juga tentang persyaratan dan perencanaan, hanya berbeda.
Falcon

6
Eh, ayolah, ini tahun 2012. Kutip tulisan publik Kent Beck atau tinggalkan. Tidak masalah jika dia merasa tersanjung di sofa Anda.
nes1983

6
@ nes1983: Saya menulis itu di 2011. Keadaannya berbeda saat itu.
Tom Anderson

3
Saya tidak pernah mendengar istilah "utang teknis" sampai scrum muncul di radar saya. Saya pernah ke pelatihan. Minyak Ular yang mudah dijual dimaksudkan untuk menarik manajemen dengan mengorbankan pertimbangan kualitas produk jangka panjang. 100% omong kosong. Meskipun aku benar-benar akan menelannya jika Scrum Masters harus membawa pedang bergaya Conan untuk membujuk orang yang mengancam integritas prosesnya.
Erik Reppen

2
+1 untuk kata-kata kasar Scrum. Saya menganggap Scrum sebagai metodologi "Agile" untuk orang-orang yang sangat menyukai air terjun, mereka ingin melakukannya setiap dua minggu.
Kyralessa

16

Scrum adalah anak haram Agile. Ini adalah gaya paling terjun dari semua metodologi lincah, dan itulah sebabnya itu yang paling populer di kalangan manajer.

Semua metode lincah adalah tentang menghasilkan kode kerja tanpa omong kosong menghalangi. Baca lagi. Dan lagi.

Apa pun yang menghalangi tujuan itu, terlepas dari "aturan tangkas" adalah buruk. Jika aturan menghalangi, ubah aturan f * * ! Itu cara lincah, itulah yang membuatnya relevan dan efektif.

Contoh terbaik dari ini diberikan oleh Alistair Cockburn (salah satu pencetus manifesto lincah):

“Tempatkan 4-6 orang di ruangan dengan workstation dan papan tulis dan akses ke pengguna. Mintalah mereka memberikan perangkat lunak yang sudah berjalan dan diuji kepada pengguna setiap satu atau dua bulan, dan jika tidak biarkan mereka sendiri. "

Jika itu bekerja untuk kualitas pria yang Anda miliki, maka itu yang Anda butuhkan. Anda tidak memerlukan master scrum atau metodologi "lincah". Jika duduk di scrum harian bekerja untuk Anda, maka f * * * melakukannya. Membuat Anda berdiri hanyalah pencabutan menyedihkan dari kemampuan Anda untuk berpikir sendiri.

Ada respons terhadap jenis gesit yang Anda lakukan. Ini dia. Cetak dan pin itu di suatu tempat ketika tidak ada orang lain di sekitar dan biarkan mereka menemukannya sendiri.


Apakah mereka mengirimkan perangkat lunak yang sudah berjalan dan diuji kepada pengguna, setiap 2/3 minggu, maksud Anda?
user272671

2
@ user272671 NO. Mintalah mereka mengirimkan perangkat lunak yang berjalan dan teruji kepada pengguna secara teratur. Bukan pada jadwal sewenang-wenang bodoh seperti 2 atau 3 minggu. Jika kerumitan pengguna atau perangkat lunak sedemikian rupa sehingga siklus 6 minggu berhasil, maka lakukan 6 minggu. Jika itu bisa dilakukan pada "saat selesai" maka lakukan itu. Jangan melukai diri sendiri dengan kendala buatan. Itu tidak gesit.
gbjbaanb

11

Master Scrum saat ini adalah seorang manajer yang mengambil beberapa hari kelas pelatihan tangkas dibayar oleh manajemen sekarang memimpin tim tangkas ini.

Itu masalahmu. Manajemen menginginkan beberapa Agile, mereka tidak benar-benar tahu apa itu, dan mereka memaksakannya kepada tim. Itulah yang harus dilakukan ketika Anda ingin menurunkan produktivitas pengembang secara signifikan;)

Usulan proses baru harus berasal dari pengembang. Atau setidaknya ditinjau & disetujui oleh mereka jika itu adalah ide manajemen.

Bagaimanapun, jika pengembang menolaknya, jangan menerapkannya ! Atau itu akan menjadi bencana yang Anda gambarkan.


9

"Agile" dan "metodologi manajemen" lainnya sering disalahgunakan untuk memaksa manajemen mikro pada orang. OTOH, terkadang juga disalahgunakan untuk mempertahankan pengerjaan yang buruk.

"we Agile" adalah alasan yang paling sering saya dengar karena kurangnya perencanaan, kurangnya pemikiran tentang desain, fitur, kualitas, siklus rilis. Ini biasanya dari pengembang dan manajemen yang lebih rendah. Ini juga alasan yang paling sering saya dengar dari manajer menengah, arsitek, wiraniaga, dll. Untuk manajemen mikro, tenggat waktu yang terus berubah dan daftar pemain, memaksa lembur besar-besaran pada orang-orang (tenggat waktu yang terus berubah dan pembuat daftar memastikan bahwa tentu saja), dll. .

Keduanya tentu saja sering bertentangan langsung, dan dapat terjadi pada proyek yang sama.


Dalam pengalaman saya .. Saya hanya pernah mendengar gesit (selalu scrum) diperkenalkan untuk menjelaskan manajemen mikro. Saya tidak akan menyangkal, Ini adalah gaya manajemen keuangan yang berbeda dan unik. Saya belum pernah mendengar seorang dev mengatakan mereka gesit, dan menjelaskan kedatangan singkat. Scrum manajemen seperti apa yang Anda alami?
JM Becker

1
setiap kali saya menemukan scrum itu diperkenalkan karena seorang manajer (biasanya lebih tinggi dari manajer proyek) telah mendengar tentang itu sebagai "hal".
jwenting

7

Untuk menjawab pertanyaan awal Anda, apakah Agile manajemen mikro baru, saya akan mengatakan tidak.

Pertama, baca ini (manifesto Agile) dan Anda akan melihat bahwa tidak berbicara dengan rekan pengembang Anda tidak terdaftar.

Sebenarnya "Individu dan Interaksi" adalah kebalikan dari tidak berbicara dengan co-developer Anda.


Ya, "Individu dan Interaksi" adalah apa yang mereka lakukan saat ini di dalam tim mereka. Bagaimana itu melawan manifesto gesit, jika Anda melihat dari sudut pandang master Scrum? Masalahnya sekarang adalah bahwa mereka tidak boleh berinteraksi dengan tim lain sehingga untuk menjaga produktivitas mereka, yang merupakan penyebab keluhan dari kelompok gesit.
Smith James

Mereka tidak berinteraksi. Itulah masalahnya. Tentu pengembang dapat menyalahgunakan hak istimewa dan berbicara tentang hal-hal yang tidak berguna selama berjam-jam. Namun, sebagian besar pengembang yang baik ingin memberikan proyek yang berkualitas. Ini masalah harga diri. Segala sesuatu yang dilakukan oleh scrum master merongrong itu, dan malah membuatnya menjadi masalah penindasan. Ini bukan tentang lincah. Seorang master scrum harus memungkinkan tim untuk menjadi produktif, tidak memecahkan cambuk dan memberitahu mereka untuk menjadi produktif. Mereka sudah ingin menjadi produktif.
Berin Loritsch

2

Agile harus menjadi manajemen diri yang baru. Jika gesit dipraktikkan dengan benar, banyak keputusan dibuat oleh pelanggan dan pengembang yang mengerjakan kisah pengguna dengan cakupan yang masuk akal yang ditambahkan ke dalam simpanan saat tugas diidentifikasi.

Scrum harian adalah tentang komunikasi, bukan manajemen. Akan ada beberapa diskusi tentang prioritas dan load balancing, tetapi orang yang dikelola di scrum mudah-mudahan master scrum. SEBAGAI pengembang, saya menghadiri, mengatakan apa yang saya lakukan, apa yang akan saya lakukan, dan bantuan apa yang saya butuhkan. Maka master scrum harus mulai bertindak membersihkan rintangan untuk kemajuan saya.

Tim lincah tidak boleh merasa seperti pekerjaan sehari-hari dikelola secara hierarkis. Jika keputusan dibuat dari jauh oleh seseorang yang berada di puncak organisasi hierarkis, sudah saatnya desentralisasi pengambilan keputusan! Bagi sebagian orang dan beberapa organisasi, ini mungkin jembatan yang terlalu jauh. Jika yang berikut ini tidak benar untuk organisasi Anda:

Hidup Agile Manifesto

"Kami menemukan cara yang lebih baik untuk mengembangkan perangkat lunak dengan melakukannya dan membantu orang lain melakukannya."

Hindari "Temui bos baru, Sama seperti bos lama." Berasal Agile dari dalam tim sebanyak mungkin. Kadang-kadang ini terjadi dengan memilih koalisi yang bersedia berada di proyek percobaan menggunakan Agile. Jika Anda dapat membentuk tim Agile Anda dari sukarelawan atau anggota yang diundang yang memiliki rekam jejak untuk kerja tim yang baik, mereka dapat menyelesaikannya. Gunakan tim kecil pada proyek pendek, mungkin untuk pelanggan in-house atau sangat mudah diakses.

Merangkul perubahan. Mungkin Anda bisa mengikuti pelatihan, tapi mungkin anggaran Anda ketat dan uangnya tidak ada. Peluang lain dapat memberikan peningkatan juga. Lakukan beberapa bacaan, mintalah anggota tim mempelajari apa yang dapat mereka lakukan tentang Agile dan saling mengajar. Anda mungkin dapat menemukan staf baru atau yang sudah ada yang memenuhi syarat untuk menjadi model dan memimpin dalam adopsi Agile.


1

Tim tangkas seperti tim sepak bola yang bekerja menuju tujuan yang dipahami secara umum. Saya telah menjadi bagian dari tim lincah selama beberapa tahun dan kuncinya adalah komunikasi yang efektif dan efisien di semua pemegang pasak. Manajer / Scrum master hanyalah fasilitator tim dan manajemen tradisional / manajemen mikro akan membunuh semangat tim.

Di tim yang saya telah bekerja, kami didorong untuk bermain game tim setelah jam kerja untuk meningkatkan persahabatan dalam anggota. Saya telah mengumpulkan pemikiran-pemikiran itu di sini .


1
Mengembangkan hubungan kerja setelah bekerja, Kita harus mengembangkan hubungan teman dan keluarga kita yang sering diabaikan setelah bekerja. Mengingat Rekan Kerja jarang berteman, dan mengambil sebagian besar peluang untuk membantu diri mereka sendiri dengan mengorbankan orang lain. Perusahaan ya-laki-laki, kroni dan alat tidak menyadarinya, karena peluang jarang. XP mungkin memiliki beberapa nilai, saya tidak punya pengalaman untuk mengatakan sebaliknya. Scrum telah menjadi versi manajemen mikro yang berbeda, setidaknya di 3 atau lebih perusahaan yang saya kenal. .... Ya tahu apa, saya terlalu membenci Corporate America sehingga menjadi sedikit objektif.
JM Becker

0

Untuk menjawab pertanyaan Anda: Tidak. Agile bukanlah bentuk manajemen mikro. Tetapi seperti alat apa pun, orang dapat menggunakannya dengan salah. Agile luar biasa ketika diterapkan dengan benar dan ketika orang konsisten dengannya.

Pikiranku pada topik "Devs tidak berbicara dengan siapa pun kecuali master scrum":

Saya telah bekerja di tempat di mana itu adalah aturan sebelumnya. NAMUN, aturan itu lebih terkait dengan meminta orang untuk menyelesaikan tugas. Sebagai contoh, saya tidak bisa secara acak naik ke tester dev dan meminta mereka untuk melakukan beberapa pengujian untuk saya dalam beberapa jam ke depan. Saya perlu berbicara dengan master scrum sehingga mereka dapat berdiskusi dengan anggota tim mereka bagaimana pekerjaan itu akan cocok dengan sprint jika itu darurat (atau jika perlu didorong ke backlog untuk sprint masa depan).

Dalam hal itu, saya mengerti konsep "devs not talk to another" karena benar-benar diterjemahkan menjadi menyalurkan tugas melalui satu pos pemeriksaan sehingga pengembang tertentu tidak bekerja terlalu keras atau begitu sibuk melakukan tugas darurat sehingga mereka tidak dapat merencanakannya. kerja selesai.

Kalau tidak, devs HARUS berbicara satu sama lain. Selalu. Ini membantu Anda mengatasi masalah lebih cepat, menjadi lebih dekat sebagai sebuah tim, dan memberikan lebih cepat.

Hanya untuk menawarkan perspektif lain: Saya juga pernah berada di lingkungan di mana orang berpikir dev "terlalu banyak bicara". Setelah duduk, kami menemukan bahwa sebenarnya diterjemahkan ke "devs tidak cukup mandiri untuk menyelesaikan pekerjaan mereka sendiri. Karena semuanya sangat terfragmentasi, devs harus pergi ke tiga orang lain untuk menyelesaikan tugas kecil."

Jadi, ketika para manajer memutuskan untuk bergerak dengan gesit, mereka berharap untuk membantu membawa informasi ke tempat yang tepat dan menghentikan banyak fragmentasi dalam organisasi. Beberapa orang agak kecewa bahwa setelah Agile diimplementasikan, para dev masih berlari bolak-balik satu sama lain. Tapi, apa yang tidak mereka sadari adalah hal itu semakin jarang terjadi. Butuh waktu lama. Jadi, mungkin jika itu yang terjadi di organisasi Anda, bisa jadi orang diharapkan gesit untuk memperbaiki keadaan dalam semalam. Itu bukan cara kerjanya.


-1

Penulis Asli Smith Janes mungkin telah memberikan pengalaman. Tapi ini adalah masalah khas yang saya temukan dalam proyek Agile.

  1. Sebagian besar organisasi, pengembang seharusnya bekerja dalam banyak proyek, dalam Agile / scrum .. Sprint tidak pernah dianggap sebagai fakta ini. Scrum Master Anda menganggap Anda harus menyelesaikan cerita Anda di akhir sprint .. Master Scrum Anda mungkin hanya didedikasikan untuk satu proyek, tetapi tidak untuk pengembang. INI ADALAH DISTRAKSI - tidak perlu hanya menerima telepon atau memungkinkan panggilan telepon.
  2. Saya telah melihat proyek Agile di mana Sprint direncanakan, Cerita dimasukkan dalam Sprint, tanpa harus berkerumun..di tengah jalan atau tengah sprint .. pengembang menemukan dependensi yang tidak terselesaikan, persyaratan atau cerita tidak selesai diceritakan ..... Ini adalah salah satu Penyalahgunaan di sebagian besar proyek gesit.
  3. Pengujian: TTD .. ya itu sangat bagus .. tapi saya telah melihat sebagian besar proyek Agile sepenuhnya bergantung pada TTD ... tidak ada cakupan atau waktu yang diizinkan untuk pengujian Fungsional atau Manusia .. Penyalahgunaan lain ... Banyak Master Scrum juga tidak tahu atau mengerti pentingnya pengujian Fungsional. Sepotong kode Anda mungkin berfungsi sempurna, jika tidak melayani kebutuhan bisnis .. tidak ada gunanya .. Ini terjadi ketika bisnis tidak berpartisipasi dengan baik di depan .. atau partisipasi ada ... tetapi tidak mencerminkan pengambilan keputusan bisnis .. Pada akhirnya, pengembang disalahkan, Anda tidak memberikan fungsionalitas..atau akan berakhir dengan perubahan menit terakhir ... jam ekstra panjang karena master Scrum Anda tidak ingin disalahkan karena cerita tidak selesai.

Pelanggaran di sini ... rendahnya partisipasi bisnis atau peserta yang tidak sepenuhnya berpengetahuan atau pebisnis putus di tengah sprint.

  1. Tidak Semua proyek cocok untuk Agile ... Sebagian besar manajer atau master scrum tidak mengetahui hal ini .. Proyek pemeliharaan .. Cacat mungkin awalnya diasumsikan dapat dilakukan dalam 8 jam, diterima dalam sprint. Setelah menghabiskan 4 jam, temukan ini adalah Java / produk lain ... (Saya baru-baru ini menghadapi cacat yang berhubungan dengan Quartz Scheduler..di dalam proyek kami) dan cacat ini dapat mengarah pada peningkatan produk / paket..terhadap birokrasi, persetujuan, pendanaan, versi baru atau peningkatan harus disetujui oleh Teknik Internal dll., 5.Retrospeksi: hanya beberapa proyek Agile melakukan langkah ini .. Jika sama sekali dilakukan .. Manajemen, Scrum Master tidak pernah mengambil tanggung jawab atas cerita yang gagal ..
  2. Penyandingan .. Banyak pengembang memperlakukan penyandingan sebagai tempat untuk menyalahgunakan rekan kerja .. mengkritik desain lain, praktik pengkodean ... memperlakukan pemberi kerja sebagai kerja tim., Belajar dari satu sama lain ... Cara lain untuk Melecehkan Agile / Scrum.

Agile jelas merupakan metodologi yang baik .. Kecuali jika organisasi Anda tidak mengikuti sepenuhnya atau tidak terlatih .... Disalahgunakan .... efek samping 60+ jam kerja / minggu, permainan menyalahkan, moral rendah.


lihat tautan ini .. mengapa proyek Agile gagal .. brighthubpm.com/agile/55778-why-do-agile-projects-fail
mukunda

Saya kebetulan setuju dengan informasi yang disajikan dalam artikel itu di sana juga. Saya mengerti bahwa ada orang yang berpikir Agile sempurna, tetapi kenyataannya adalah Agile menyisakan sedikit atau tidak ada ruang untuk pengenalan ide-ide baru dan lebih efektif. is..brighthubpm.com / agile / 55778-why-do-agile-projects-fail
user272671

-3

Agile adalah manajemen mikro yang menyamar. Tidak ada tempat untuk inisiatif atau kreativitas dalam Agile, itu telah menghilangkan kesenangan dari pemrograman untuk memungkinkan manajer yang tidak kompeten untuk tetap mengontrol bahkan tanpa memiliki petunjuk dari sudut pandang teknis.


2
Anda tidak bisa salah lagi. Dengan gesit, tim harus memiliki kontrol kreatif yang sangat besar. Agile membutuhkan banyak inisiatif, karena timlah yang memutuskan bagaimana menerapkan setiap cerita. Manajemen sebenarnya memiliki sangat sedikit kendali atas proses yang gesit. Secara pribadi, tiga tim gesit yang berbeda yang pernah saya ikuti sangat menyenangkan. Kedengarannya seperti Anda pernah mengalami beberapa ketidakmampuan yang parah yang mengidentifikasi diri sebagai gesit tanpa mendekati gesit.
Bryan Oakley

tambahkan beberapa alasan untuk mendukung pernyataan Anda (yang masuk akal bagi saya tetapi itu tidak masalah), dan saya akan menghapus downvote
nyamuk

1
Saya setuju dengan @ Geo. Sampai saat ini, itulah kesan yang saya miliki tentang apa itu "Agile", di dunia nyata. Ketika Anda memiliki pengaturan seperti itu di lantai pabrik - itu hanyalah bentuk manajemen mikro. Sekarang Manifesto mencoba memberi tahu kita bahwa itu tidak benar. Tapi proyek demi proyek, saya dituntun untuk lebih percaya bahwa itu hanyalah nama lain untuk "Manajemen Mikro". Dan itu membunuh kreativitas.
user272671
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.