Ketika Agile salah [tertutup]

Saya menulis kursus Agile untuk beberapa orang baru yang baru saja bergabung, dan saya ingin menambahkan kisah peringatan agar mereka mengerti bahwa Agile tidak dimaksudkan untuk semua proyek.

Masalah saya adalah bahwa, karena sifat dari proyek tempat saya bekerja dengan Agile telah bekerja dengan cukup baik sejauh ini, saya tidak dapat dengan jujur ​​menunjukkan apa yang bisa salah dan mengapa ketika Anda menggunakannya dalam jenis proyek yang salah.

Apa hal yang harus diperhatikan ketika proyek Agile salah?

Kegagalan terbesar dengan tim "Agile" adalah hasil dari apa yang disebut Cargo Culting . Pada dasarnya, tim menginginkan efek dari tim tangkas yang sukses sehingga mereka meniru tindakan visibile

• Standup harian (berjalan sekitar satu jam atau lebih)
• Memecah pekerjaan menjadi sprint
• Kisah-kisah pengguna (yang biasanya hanya sedikit lebih dari sebuah kalimat tetapi perkiraannya diharapkan)

Mereka adalah tiga yang akan Anda lihat secara konsisten "diterapkan" dalam lingkungan ini tetapi sangat sedikit komitmen untuk benar-benar gesit. Bahkan, Anda akan mendengar manajemen mengatakan bahwa kami "lincah." (Lari ke dua kata itu pertanda buruk.)

Anda juga akan mendengar banyak tentang utang teknis, tetapi definisi utang teknis mereka adalah "lakukan dengan cepat dan kotor dan mungkin kita akan memperbaikinya nanti." (Terjemahan: kita akan membuatnya terdengar seperti kita prihatin dengan pemeliharaan tetapi pada kenyataannya kita akan mempertahankan mentalitas ruang ketel yang sama karena itulah yang bekerja untuk kita di masa lalu).

Frasa kunci lainnya: "Saya tahu kisah-kisah ini tidak sepenuhnya didefinisikan tetapi kami lincah sehingga kami dapat memperbaikinya seiring berjalannya waktu."

"Kami sedang melakukan pengembangan tangkas sehingga Anda harus dapat mengakomodasi apa yang saya butuhkan dalam sprint saat saya mengidentifikasinya."

"Kami tidak dapat mengunci cerita komitmen kami di awal sprint karena kebutuhan terus berubah mid-sprint."

Indikator kunci tentang apakah proyek Agile akan berhasil adalah jika pemimpin proyek (scrum master atau peran apa pun) telah memiliki pengalaman atau pelatihan formal tentang memimpin proyek agile. Terlalu sering saya melihat orang membaca tentang Agile dalam sebuah buku atau mengambil kursus dua hari tentang menjadi seorang scrum master dan berpikir mereka punya daging untuk berhasil mengimplementasikannya. Maaf itu tidak terjadi kapten.

Orang yang tidak mengerti apa itu lincah dan menerapkannya pada:

• klien yang tidak dapat dikomentari hingga batas waktu
  ... dan mengancam akan melakukan tindakan hukum setelahnya;

• manajer yang menjauhkan pengembang dari klien , (mungkin karena mereka sedikit di bawah bayaran, dan dapat melompat kapal, akan bekerja untuk klien tersebut) dan memainkan permainan " telepon rusak " dalam upaya putus asa (seringkali berhasil, meskipun) untuk terlihat sibuk dan bermanfaat,

  Lihat juga: manajemen jamur , alias "disimpan tidak jelas, diberi pupuk kandang" dan bos-bos berambut runcing . :)

• tim yang terlalu besar untuk pergi ke mana pun;

• perusahaan-perusahaan yang mempertahankan gaji para perancang arsitektur sistem yang pernah terkenal, yang dengan putus asa mengalihkan perhatian dari fakta bahwa mereka benar-benar kehilangan pandangan terhadap pembuat kode yang sebenarnya, dengan mendesain familias UML sagrada yang luar biasa, tidak taktis, sulit disadari .

Agile tidak cocok untuk kontrak jangka tetap atau harga tetap. Setelah Anda mendaftar untuk binatang seperti itu, Anda harus mengirim. Agile sangat pandai dalam melanjutkan pengembangan untuk selamanya, karena pelanggan berubah pikiran dan 'mengklarifikasi' persyaratan mereka. Itu tidak membantu Anda pada hari uang habis, tetapi masih harus menyelesaikan pekerjaan.

Agile sangat baik untuk fase pasca-proyek ketika Anda melakukan pembaruan inkremental dan perbaikan bug.

Aspek lain di mana Agile gagal bukanlah kesalahan Agile, ini adalah kesalahan orang yang bersikeras pada semua hal lama seperti dokumentasi proyek lengkap, desain muka, dan jalur komunikasi yang buruk. ( Manifesto tangkas setengah arsed ).

Berikut adalah beberapa pertanyaan yang mungkin berguna untuk mencari jawaban dalam hal menemukan contoh di mana upaya Agile dapat berjalan buruk:

• Apakah Agile manajemen mikro yang baru?
• Proses Agile: bagaimana dan apa yang harus didokumentasikan?
• Perpaduan yang tepat antara perencanaan dan pemrograman pada proyek baru

Pernahkah Anda mendengar "pseudo Agile"? Berikut adalah beberapa entri blog tentang hal itu:

• Dari Pseudo-Agile hingga Waterfall - Jalur perusahaan perangkat lunak kecil dan baru
• Pseudo Agile!

Ada sesuatu yang bisa dikatakan untuk perusahaan yang dapat mengambil pandangan mereka sendiri tentang apa yang Agile dan membaginya menjadi sesuatu yang lain.

Saya bekerja pada tim Agile yang sangat sukses, serta beberapa yang berusaha Agile, tetapi tidak bisa membuatnya bekerja.

Yang sukses memiliki unsur-unsur berikut:

• Persyaratan yang benar-benar "Agile". Ada kisah-kisah pengguna, dan kami menandainya.
• Pemilik produk yang tersedia. Jika cerita pengguna yang saya koding tidak lengkap, saya bisa dengan mudah pergi ke pemilik produk, bertanya padanya apa yang harus ada di sana, menambahkannya, dan melengkapi kodenya.
• Komitmen terhadap proses dan kesadaran bahwa itu adalah kurva belajar.
• Tim yang fokus.
• Manajer yang tahu dan mengerti cara Agile dalam melakukan hal-hal yang berkomitmen untuk membuatnya bekerja.

Tim yang sukses melakukan Agile, dan melakukannya dengan sangat baik. Saya akan berpikir bahwa jika Anda tidak memiliki poin-poin di atas, Anda bisa gagal dengan mudah. Hal pertama dan kedua berjalan beriringan, dan jika Anda tidak memilikinya, maka Agile tidak akan berfungsi.

Tim yang saya ikuti yang tidak melakukan Agile dengan baik memiliki beberapa elemen juga:

• Kurangnya komitmen dari manajemen. Manajemen tidak percaya pada filosofi, dan sebagai akibatnya ragu untuk berkomitmen.
• Persyaratan didokumentasikan di tempat lain selain cerita pengguna. Lihat di atas tentang komitmen manajemen. Selain itu, kami memiliki analis persyaratan yang dibayar tinggi dan alat persyaratan mahal yang dibutuhkan seseorang untuk membenarkan penggunaannya.

Saya akan menambahkan jawaban bagus yang sudah diposting bahwa, berdasarkan pengalaman saya, lincah dan khususnya Scrum hanya akan berfungsi jika manajemen DAN tim bersedia menaruh banyak visibilitas tentang apa yang terjadi.

Ini berarti bahwa di perusahaan publik (pemerintah misalnya), akan sangat sulit untuk membuatnya berfungsi dengan baik.

Agile menurut saya adalah semua tentang budaya tim yang berlatih. Jika budaya menyebalkan, anggota tim tidak rukun, dan orang-orang tidak berkolaborasi untuk memenuhi komitmen sprint maka budaya atau tim kurang.

Namun saya tidak perlu mengatakan bahwa Waterfall akan selalu bekerja di lingkungan seperti itu, ini bukan situasi hitam dan putih, sangat sedikit yang benar-benar hitam dan putih.

Tim Agile yang baik adalah komunal. Mereka memiliki semangat kesukuan di mana semua anggota bekerja menuju tujuan yang sama. Tim berhasil atau gagal bersama. Mereka bekerja bersama dalam memecahkan masalah. Seorang anggota tim akan menghentikan apa yang dia lakukan dengan tugasnya untuk membantu anggota tim yang berjuang keluar. Semuanya tenggelam atau berenang.

Ketika ini tidak terjadi maka dengan cepat menjadi jelas apa yang salah. Jika anggota tim sedang duduk, mengetik di laptop atau mengirim pesan teks, atau membuat zonasi selama standup harian maka Anda tidak memiliki tim Agile yang baik. Jika manajer proyek Anda menegakkan semua prosedur, definisi, dan terminologi Scrum, tetapi semua orang hanya menjaga irama dan membayar layanan bibir, maka ini hanya lelucon yang agak mencolok tentang apa sebenarnya Agile, dan ini dalam banyak hal menyebabkan disfungsi tim, inefisiensi. , tenggat waktu yang terlewat, dan proyek yang gagal.

Agile yang Gagal dalam banyak hal lebih buruk daripada tim Waterfall yang cukup sukses dan mungkin memiliki tingkat keberhasilan proyek yang lebih rendah.

Saya tidak tahu ini dari pengalaman pribadi, tetapi secara hipotetis, ada banyak keadaan ketika lincah bukan pilihan terbaik.

• Proyek yang produknya penting untuk kehidupan atau properti - Misalnya, Anda tidak ingin menggunakan gesit untuk mengembangkan perangkat lunak yang menjalankan alat pacu jantung Anda. Mengapa? Karena Anda memiliki toleransi hampir nol untuk kesalahan. Pertimbangkan contoh klasik kesalahan pemrograman dalam kedokteran sehubungan dengan Therac 25 . Memang, itu tidak dibangun dengan lincah, tetapi intinya adalah: Mengembangkan kehidupan atau properti kritis bukanlah tempat untuk mengatakan, "kita akan membersihkan itu di sprint berikutnya" atau "kita tidak perlu hebat, hanya baik cukup."

• Proyek dengan terlalu banyak pengembang junior - Agile mengharapkan sejumlah otonomi dalam kelompok yang berpartisipasi. Jika tidak ada cukup pengalaman dalam tim, maka otonomi itu dapat merugikan Anda.

• Proyek yang membutuhkan tingkat kontrol atau perencanaan yang lebih tinggi daripada yang ditawarkan secara tradisional dengan Agile.

Saya berasumsi bahwa orang lain akan melompat masuk dan membantu dengan contoh yang lebih baik, atau menurunkan sedikit babat yang telah saya tulis ;-).

Ingatlah bahwa ketika satu-satunya alat yang Anda miliki adalah palu, setiap masalah terlihat seperti paku. Tidak semua proyek paku.