Kematian Dengan Perencanaan

Kematian Dengan Perencanaan

Antipattern Nama: Death by Perencanaan
Disebut Juga Sebagai: Kaca Rencana Kasus, Rencana Detailitis
Kebanyakan Skala Sering: Kewirausahaan
Refactored Nama Solusi: Rasional Perencanaan
Refactored Solusi Jenis: Proses
Penyebab root: Ketamakan, Ketidaktahuan, Haste
Angkatan seimbang: Manajemen Kompleksitas 

Anekdot Bukti: "Kami tidak bisa memulai sampai kita memiliki rencana program lengkap." "Rencananya adalah satu-satunya hal yang akan menjamin kesuksesan kami." "Selama kita mengikuti rencana dan tidak menyimpang dari itu, kita akan berhasil." "Kami punya rencana, kita hanya perlu mengikutinya!" 

Latar belakang
   Dalam banyak budaya organisasi, perencanaan rinci adalah kegiatan diasumsikan untuk setiap proyek. Asumsi ini cocok untuk kegiatan manufaktur dan jenis lain dari proyek, tetapi belum tentu untuk proyek-proyek perangkat lunak banyak, yang mengandung banyak diketahui dan kegiatan kacau dengan sifatnya. Kematian oleh Perencanaan terjadi ketika rencana rinci untuk proyek-proyek perangkat lunak yang diambil terlalu serius.

Bentuk umum
   Banyak proyek gagal dari lebih dari perencanaan. Selama perencanaan sering terjadi sebagai akibat dari pelacakan biaya dan monitoring pemanfaatan staf. Kedua jenis lebih perencanaan yang dikenal sebagai Rencana Kasus Kaca dan Rencana Detailitis. Rencana Kasus Kaca adalah bagian dari Rencana Detailitis dalam (lebih) perencanaan berhenti setelah proyek dimulai. Dalam Rencana Detailitis, lebih perencanaan terus sampai proyek tidak lagi ada, untuk berbagai alasan tidak memuaskan.
Rencana Kasus kaca

   Seringkali, rencana diproduksi pada awal proyek selalu dirujuk sebagai jika itu akurat, tampilan saat proyek bahkan jika itu tidak pernah diperbarui. Praktek ini memberikan manajemen yang "nyaman pandangan" pengiriman sebelum proyek dimulai. Namun, ketika rencana tersebut tidak pernah dilacak terhadap, atau diperbarui, menjadi semakin tidak akurat sebagai proyek berlangsung.

   Tampilan palsu ini sering diperparah dengan tidak adanya informasi konkrit tentang kemajuan, yang sering dikenal hanya setelah penyampaian kritis slip jadwal.

   Kadang-kadang, ketika rencana proyek dibuat sebelum peluncuran proyek, manajemen mengasumsikan bahwa rencana tersebut menjamin pengiriman otomatis-persis seperti yang ditentukan tanpa intervensi (atau manajemen) yang diperlukan.

Rencana Detailitis
   Kadang-kadang solusi untuk pengiriman efektif dianggap sebagai tingkat kontrol yang tinggi melalui latihan perencanaan berkelanjutan yang melibatkan sebagian besar pengembang senior, serta manajer.

   Pendekatan ini sering berkembang menjadi urutan hirarkis rencana, yang menunjukkan tingkat tambahan (dan yang tidak perlu) detail. Kemampuan untuk menentukan seperti tingkat tinggi detail memberikan persepsi bahwa proyek ini sepenuhnya di bawah kontrol.
Gejala Dan Konsekuensi

Gejala Rencana Kasus Kaca adalah pertama kali melihat di kedua itu dan Rencana Detailitis.
Rencana Kasus kaca

Gejala biasanya termasuk setidaknya salah satu dari berikut:

Ketidakmampuan untuk merencanakan pada tingkat pragmatis.
Fokus pada biaya daripada pengiriman.
Cukup keserakahan untuk berkomitmen rinci selama proyek ini didanai.

Konsekuensinya tambahan:

Ketidaktahuan status pembangunan proyek. Rencananya tidak memiliki arti, dan kontrol pengiriman mengurangi seiring waktu. Proyek ini mungkin baik di depan atau di belakang negara penyampaian dimaksudkan dan tidak ada yang akan tahu.
Kegagalan untuk memberikan deliverable kritis (konsekuensi akhir).

Konsekuensi tumbuh secara bertahap sampai akhirnya overruns proyek, dengan pilihan biasa:

Investasi lebih lanjut.
Manajemen proyek krisis.
Pembatalan.
Kemungkinan hilangnya staf kunci.

Rencana Detailitis

Gejalanya adalah superset dari Rencana Kaca Kasus:

Ketidakmampuan untuk merencanakan pada tingkat pragmatis.
Fokus pada biaya daripada pengiriman.
Menghabiskan lebih banyak waktu perencanaan, merinci kemajuan, dan replanning dari pada memberikan software:

• Manajer proyek rencana kegiatan proyek.
• Pemimpin tim merencanakan kegiatan tim dan aktivitas pengembang.
• Pengembang proyek memecah kegiatan mereka dalam tugas.

Konsekuensi saling terkait dan makan dari satu sama lain:

   Setiap perencana harus memantau dan menangkap kemajuan pada tingkat yang ditunjukkan oleh atau rencananya, dan reestimate.

   Perencanaan tak berujung dan replanning menyebabkan perencanaan lebih lanjut dan replanning.
Tujuannya bergeser dari pengiriman perangkat lunak untuk pengiriman satu set rencana. Manajemen menganggap bahwa karena upaya dan biaya dilacak, kemajuan harus setara. Bahkan, tidak ada korelasi langsung.
Penundaan terus-menerus untuk pengiriman perangkat lunak dan kegagalan proyek akhirnya.

Penyebab khas

   Dalam kedua kasus, Rencana Kasus Kaca dan Detailitis Rencana penyebab utama adalah kurangnya pragmatis, pendekatan yang masuk akal untuk perencanaan, jadwal, dan menangkap kemajuan.
Rencana Kasus kaca

Tidak ada rencana proyek up-to-date yang menunjukkan kiriman komponen perangkat lunak dan tanggal mereka.

Ketidaktahuan prinsip proyek-manajemen dasar.
Perencanaan awal terlalu bersemangat untuk mencoba menegakkan kontrol mutlak pembangunan.
Sebuah bantuan penjualan untuk akuisisi kontrak.

Rencana Detailitis

Perencanaan berkesinambungan terlalu bersemangat untuk mencoba menegakkan kontrol mutlak pembangunan.
Perencanaan sebagai kegiatan proyek utama.
Kepatuhan pelanggan dipaksa.
Paksa kepatuhan manajemen eksekutif.

Dikenal Pengecualian

Seharusnya tidak akan ada pengecualian untuk Death oleh Perencanaan antipattern.
Solusi refactored

Solusinya adalah sama untuk kedua kasus Kaca dan Detailitis Rencana. Sebuah rencana proyek harus menunjukkan terutama kiriman (terlepas dari berapa banyak tim yang bekerja pada proyek). Kiriman harus diidentifikasi pada dua tingkat:

Produk (s). Mereka artefak dijual ke pelanggan, yang meliputi garis internal perusahaan dari bisnis yang menggunakannya.
Komponen (dalam produk). Artefak dasar teknologi yang dibutuhkan untuk mendukung layanan bisnis.

Kiriman mencakup hal-hal seperti:

Pernyataan persyaratan bisnis

• Deskripsi teknis
• Kriteria penerimaan terukur
• Skenario penggunaan produk
• Kasus penggunaan komponen

Rencana tersebut harus dilengkapi dengan validasi tonggak untuk setiap komponen, serta produk secara keseluruhan, seperti:

• Persetujuan desain konseptual
• Persetujuan spesifikasi desain
• Persetujuan desain implementasi
• Persetujuan rencana uji

Rencana penyampaian harus diperbaharui mingguan untuk memastikan perencanaan dan kontrol yang mengurangi risiko proyek yang tepat. Hal ini memungkinkan masalah, risiko, slippages, dan pengiriman awal kiriman didefinisikan harus ditangani oleh, tanggapan yang tepat waktu sesuai.

Pelacakan dilakukan pada tingkat diperkirakan kelengkapan. Hal ini terkadang berarti kemunduran kelengkapan yang masukan untuk rencana dalam periode waktu sebelumnya. Kelengkapan harus pengukuran kotor daripada pengukuran baik, misalnya, pelacakan di 25 persen langkah daripada 5 langkah persen.

Gantt chart dapat digunakan secara efektif untuk visual menggambarkan kiriman, tanggal terkait, dan saling ketergantungan. Dengan pelacakan terhadap rencana awal, negara-negara berikut deliverable akan segera jelas:

Sesuai jadwal.
Disampaikan.
Awal (dengan perkiraan tanggal pengiriman baru).
Akhir (dengan perkiraan tanggal pengiriman baru).

Hal ini penting baseline awal dan jarang. Jika tidak kemampuan untuk melacak perubahan hilang. Selanjutnya kegiatan / tugas / kiriman harus memiliki dependensi diatur antara mereka di mana mereka ada.

Ketika memperkirakan disarankan untuk memungkinkan periode kontingensi untuk semua orang yang tak terelakkan "tidak diketahui," seperti:

Persyaratan kenaikan (merayap).
Desain buntu.
Workarounds perangkat lunak pihak ketiga.
Identifikasi Cacat (menemukan masalah dalam satu set komponen yang terintegrasi).
Koreksi cacat (bug fixing).

Hal ini juga penting untuk membangun kerangka waktu minimum di mana untuk mencapai aktivitas apapun. Hal ini untuk mencegah kendala seperti dua hari untuk kode dan menguji program "sederhana".
Variasi

Kematian oleh variasi Perencanaan berada di tingkat detail, dan bisa pergi dari mengidentifikasi tonggak utama, yang biasanya dikaitkan dengan tahap pendanaan / persetujuan, untuk mikro-kiriman dalam tahap pengiriman proyek untuk setiap tim.

Variasi ini sama-sama berlaku untuk kedua kasus Kaca dan Detailitis Rencana:

Variasi pendanaan
Micro-kiriman variasi

Versi Kaca Kasus mikro-kiriman berencana hanya bervariasi dari Rencana Detailitis di bahwa itu tidak pernah diperbarui. Ini menunjukkan kiriman sangat kecil yang tidak dapat sepenuhnya dipahami sebelum memulai proyek. Oleh karena itu, setiap perkiraan harus dengan definisi tidak benar berdasarkan tidak adanya pemahaman yang benar dari perangkat lunak yang akan dibangun. Jenis rencana biasanya diproduksi oleh amatir berbakat secara teknis. Meskipun tugas perlu dipahami dengan jelas, menempatkan mereka dalam hasil rencana hanya dalam perencanaan yang tidak perlu dan pelacakan (dalam kasus Rencana Detailitis), sebagai lawan melakukan.
Contoh

Contoh didasarkan pada pengalaman kita sendiri dalam belajar "dengan cara yang keras."
Rencana Kasus kaca

Untuk contoh ini, kita akan mengatakan sistem integrator memutuskan untuk membangun komponen middleware belum tersedia dari salah satu vendor besar, terlepas dari standar internasional yang dikeluarkan lebih dari setahun yang lalu. Integrator sistem setuju untuk rencana pengiriman rinci sebelum memulai pekerjaan proyek untuk mendapatkan sumber pendanaan. Rencana tersebut didasarkan pada perkiraan dari staf yang belum disampaikan software "marah."

Rencananya adalah sangat spesifik teknis, dan perkiraan sangat optimis; dan itu terus direferensikan oleh manajer proyek, tetapi tidak pernah diperbarui untuk mencerminkan upaya yang sebenarnya.

Hal ini menyebabkan tanggal pengiriman terjawab. Ada kurangnya pengetahuan untuk kemajuan nyata proyek; sistem integrator yang tahu tentang kegagalan tanggal pengiriman hanya setelah tanggal telah berlalu. Rencana yang ditunjukkan pada gambar di bawah ini adalah kutipan dari sebuah proyek pembangunan.
Rencana Detailitis

Dalam upaya untuk mengendalikan pengembangan untuk memastikan bahwa kontrol penuh didirikan, perusahaan pengguna akhir menghasilkan rencana yang memiliki tiga tingkatan:

fase pembangunan.
tugas tim dan usaha.
Tim tugas anggota dan usaha.

Rencana pada gambar di bawah menunjukkan kompleksitas.

Detailitis menyebabkan ketidakmampuan untuk melacak terhadap rencana tanpa mengambil fokus yang cukup jauh dari memberikan sistem. Hal ini menyebabkan produktivitas staf berkurang secara signifikan. Manajemen rencana cepat menjadi tidak realistis karena kompleksitas.

Solusinya adalah dengan mengganti rencana rinci dengan satu yang menunjukkan kiriman kunci terhadap tanggal, dengan dependensi dan kendala. Jika penyampaian tersebut terjawab, maka sesuatu yang penting telah terjadi. Rencana sebelumnya berusaha untuk melacak kemajuan dengan usaha yang realistis: Upaya = staf x hari berlalu. Jadi apa? E = MC2, tetapi rumus tidak menciptakan tenaga nuklir!

Solusi terkait
   Analisis Kelumpuhan antipattern dapat memperburuk konsekuensi dari Kematian oleh Perencanaan. Jika tahap analisis berjalan di atas jadwal yang diberikan, baik jadwal harus menyelinap atau model analisis memadai diterapkan untuk fase hilir.
Berlakunya Untuk Pandangan Dan Timbangan Lainnya

Kematian oleh Perencanaan tidak dapat cocok dengan kacau alam (putih-air) dari pengembangan perangkat lunak, karena itu menciptakan perbedaan yang signifikan antara model perencanaan manajemen dan kegiatan pembangunan yang sebenarnya.

   Arsitek dan pengembang sering harus menjalani kehidupan ganda: Di satu sisi, mereka harus tampak bekerja sama dengan rencana manajemen untuk proyek tersebut; pada saat yang sama, mereka harus menghadapi status sebenarnya dari perangkat lunak, yang mungkin tidak menyerupai model manajemen. Misalnya, rencana tersebut dapat digunakan untuk pengembang tekanan ke mendeklarasikan modul software yang lengkap sebelum mereka dewasa. Hal ini menyebabkan masalah hilir dalam integrasi dan pengujian.