Salah urus proyek

Salah urus proyek

Antipattern Nama: Proyek salah urus
Disebut Juga Sebagai: Humpty Dumpt
Kebanyakan Skala Sering: Kewirausahaan
Refactored Solusi Nama: Manajemen Risiko
Refactored Jenis Solusi: Proses dan Peran
Penyebab root: Tanggung Jawab (penyebab universal)
Angkatan seimbang: Manajemen Risiko (kekuatan universal)
Anekdot Bukti: "Apa yang salah Semuanya baik-baik saja dan kemudian tiba-tiba ... Kaboom?!"

Latar belakang

   Antipattern ini menyangkut pemantauan dan pengendalian proyek perangkat lunak. Jangka waktu ini terjadi setelah kegiatan perencanaan, dan selama aktual analisis, desain, konstruksi, dan pengujian sistem perangkat lunak. Urus proyek melibatkan kesalahan yang dibuat pada hari ke hari menjalankan proyek, dengan asumsi kesalahan perencanaan (seperti Death By Perencanaan) belum dibuat.

Bentuk umum
 
   Menjalankan proyek adalah sebagai kompleks kegiatan sebagai menciptakan rencana proyek, dan pengembangan perangkat lunak adalah sebagai kompleks sebagai bangunan pencakar langit, yang melibatkan banyak langkah dan proses, termasuk checks and balances. Seringkali, kegiatan kunci diabaikan atau diminimalkan.

Ini termasuk perencanaan teknis (arsitektur) dan kegiatan kontrol kualitas (inspeksi dan pengujian). Secara khusus, kesalahan dasar meliputi: definisi yang tidak memadai arsitektur, kode cukup review (pemeriksaan software), dan cakupan tes tidak memadai.

Di bawah payung tes, beberapa tahapan yang diperlukan, tetapi sering diminimalkan: Unit, integrasi, dan pengujian sistem. Pengujian integrasi sederhana terdiri pengecekan dasar komponen unit diuji untuk interoperabilitas. Penuh pemeriksaan pengujian integrasi semua dikenal jalur kesuksesan dan negara error.

   Arsitektur menetapkan rencana rinci teknologi untuk proyek, termasuk kriteria untuk inspeksi dan pengujian. Ketika arsitektur memadai didefinisikan, ada dasar yang cukup untuk memeriksa desain selama pemeriksaan dan pengujian tahap. Ketika pengujian dilakukan, modul software dapat diintegrasikan menurut arsitektur, tetapi tidak mampu beroperasi sesuai dengan kebutuhan aplikasi.

Gejala Dan Konsekuensi

Desain sulit untuk menerapkan karena kurangnya strategi arsitektur.
Ulasan kode dan inspeksi terjadi jarang dan menambah nilai minimal.
Desain uji membutuhkan usaha dan menebak ekstra karena pedoman perilaku untuk sistem didefinisikan tidak cukup.
Dalam fase integrasi dan pengujian sistem, ada banyak proyek "meronta-ronta" karena sejumlah besar cacat yang seharusnya dieliminasi dalam tahap awal seperti arsitektur, desain, inspeksi, dan pengujian unit.
Laporan cacat meningkat menjelang akhir pengembangan dan fase pengiriman / penerimaan.

Penyebab khas

Arsitektur memadai tidak mendefinisikan kriteria teknis untuk inspeksi, pengujian, integrasi, dan interoperabilitas.

Ulasan kode dan inspeksi software tidak mengevaluasi cacat desain, yang kemudian harus ditangani secara bertahap yang lebih mahal seperti pengujian penerimaan.

Test suite cukup memeriksa kebutuhan integrasi dasar, tetapi tidak memenuhi kebutuhan interoperabilitas penuh untuk aplikasi.

Semua faktor sebelumnya menunjukkan manajemen risiko tidak efektif, yang dapat ditelusuri ke praktek profesional arsitek, desainer, dan manajemen.

Dikenal Pengecualian

Seharusnya tidak akan ada pengecualian untuk Proyek salah urus antipattern.

Solusi refactored

   Manajemen risiko yang tepat adalah cara yang efektif untuk menyelesaikan gejala diprediksi dan konsekuensi dari Proyek salah urus antipattern. Risiko yang dikategorikan dalam beberapa cara yang bermanfaat: manajerial, proyek umum poin kegagalan, dan kualitas. Ini diperlukan untuk memahami kategori ini dalam rangka untuk lebih memenuhi syarat risiko.

Manajerial

Risiko ini terutama disebabkan oleh dan diselesaikan manajemen perusahaan:
Proses. Definisi pengembangan produk end-to-end.
Peran. Tanggung jawab spesifik untuk pelaksanaan proses.
Proyek umum Kegagalan Poin
Risiko ini proyek utama didasarkan pada driver dua puluh tiga risiko:

• Biaya overruns.
• Terminasi dini proyek.
• Pengembangan produk yang salah.
• Kegagalan teknis.
• Kualitas
• Program dan manajemen proyek. Efektivitas perencanaan dan pengendalian proses.
• Identifikasi produk. Keakuratan definisi masalah.
• Definisi arsitektur. Spesifikasi desain dan coding strategi.
• Desain solusi. Kemampuan untuk memberikan spesifikasi kode konsisten dan optimal yang sepenuhnya mendukung solusi.
• Implementasi solusi (coding). Kemampuan untuk menghasilkan sebuah implementasi kode akurat dari desain, yang berfungsi dengan cara yang diharapkan.
• Validasi solusi (pengujian). Bukti bahwa solusi diimplementasikan sepenuhnya memenuhi persyaratan masalah.
• Dukungan produk. Kemampuan terus menerus untuk mempertahankan dan meningkatkan produk dirilis.

Pemahaman umum
   Seringkali, tema manajemen risiko adalah tidak adanya pemahaman umum, sehingga pandangan yang tidak konsisten dari pembangunan, yang mengarah ke risiko solusi tidak memenuhi ruang lingkup persyaratan masalah. Sebuah perusahaan harus memahami perkembangan perangkat lunak di seluruh situs dan semua proyek. Setiap proyek harus berbagi pengetahuan umum tentang perkembangannya.

Idealnya, semua (atau sebagian besar) pengembangan staf pada sebuah proyek akan memiliki akal, pemahaman keseluruhan persyaratan masalah dan solusi dimaksudkan. Sayangnya, seringkali hal ini tidak terjadi, menyebabkan satu atau lebih dari kegagalan ini:

Fungsi terjawab. Satu atau lebih komponen jasa tidak pernah dibangun karena tidak ada pandangan bersama tentang bagaimana semua komponen akan berinteraksi pada platform pengiriman.

Fungsi yang salah. Beberapa komponen tidak melakukan fungsionalitas penuh diperlukan karena penggunaannya tidak pernah dibagikan oleh pengembang dengan pengguna (pengembang lain).

Overfunctionality. Persyaratan tidak pernah jelas dipahami dan "setan dalam rincian" tidak pernah menarik keluar. Hal ini menyebabkan pengembangan perangkat lunak di bawah "niat baik," tanpa persyaratan apapun atau perlu pernah yang jelas didirikan.

Modul kode akan antarmuka namun tidak sepenuhnya beroperasi. Tidak ada definisi benang kontrol di sistem dan modul batas.

   Solusinya refactored memerlukan kegiatan pada tahap arsitektur dan desain pembangunan. Pada tingkat arsitektur, ketergantungan antara modul harus didefinisikan. Ini termasuk penugasan tanggung jawab yang menentukan saling ketergantungan antara modul dan partisi fungsi sistem. Pada tingkat desain, benang kontrol (kasus penggunaan) di modul harus didefinisikan. Ini termasuk semua kasus penggunaan sukses serta negara error didefinisikan.

Variasi

Kegiatan manajemen risiko secara formal adalah salah satu cara untuk dokumen dan rencana mitigasi risiko. Manajemen risiko formal memerlukan identifikasi dan dokumentasi risiko proyek, biasanya dalam format tabel, yang mencakup kolom untuk keparahan risiko, deskripsi risiko, dan mitigasi risiko.

Rencana manajemen risiko sering diproduksi dengan dokumentasi formal proyek, tetapi jarang diterjemahkan ke dalam kegiatan proyek yang didanai. Hal ini penting untuk memprioritaskan risiko proyek dan penelitian anggaran dalam kegiatan mitigasi risiko yang mewakili titik rawan kegagalan.

Variasi lain, tim run-depan, sering digunakan untuk menyelidiki kemampuan produk baru dan kompatibilitas teknologi. Tim run-depan menciptakan prototipe yang menyerupai arsitektur target sistem, menggunakan teknologi utama atau backup teknis.

   Tim run-depan juga mengidentifikasi segala kekurangan teknologi dan menyelidiki strategi solusi. Tim kemudian mendidik seluruh staf proyek pada teknologi baru, sehingga memperpendek kurva belajar. Akhirnya, tim run-depan harus mendahului kegiatan pembangunan utama dengan satu sampai tiga bulan. Jika tidak, proyek utama mungkin tertunda menunggu hasil dari penelitian run-depan.

Contoh

   Sebuah pengembangan perangkat lunak tidak mengelola itu pengiriman kode. Tim pengembangan yang tersisa untuk perangkat mereka sendiri bagaimana untuk mendapatkan dari desain untuk pengiriman. Ini berarti bahwa mereka masing-masing harus berurusan dengan masalah kualitas dan proses melalui mekanisme diri yang berasal dan mengelola kegiatan mereka sendiri. Risiko menjadi kode yang tidak dapat diterima karena kurangnya kepatuhan terhadap:

Standar pengkodean (termasuk traceability untuk desain)

• Ulasan kode
• Perencanaan tes
• Unit pengujian
• Pengujian API
• Pengujian integrasi
• Pengujian fitur
• Dokumentasi program
• Risiko memanifestasikan dirinya sebagai kurang didokumentasikan kode yang telah sebagian besar belum teruji dan tidak mengintegrasikan, atau sepenuhnya memenuhi persyaratan.

Penunjukan hasil manajer proyek baru di perbaikan kualitas / proses. Perbaikan yang inkremental dan secara aktif dimiliki oleh tim melalui serangkaian difasilitasi "lihat balik" sesi untuk mengidentifikasi masalah dan isu-isu, dan kemudian penciptaan kelompok utusan untuk mengatasinya melalui perbaikan proses inkremental.

Setiap kelompok terdiri dari utusan fasilitator dari dukungan produk dan pemilik tim pengembangan (untuk setiap tim) untuk itu bagian dari proses:

• Disain
• Coding
• Pengujian
• Dokumentasi
• Setiap anggota tim kelompok utusan bertanggung jawab untuk:
• Menyempurnakan proses tertentu.
• Mendidik tim mereka.
• Memberikan penilaian subjektif dari pelaksanaan tim dari proses spesifik dan kualitas itu kiriman.

Penghubung dengan utusan lain untuk mempertahankan standar yang konsisten pelaksanaan proses dan penyelesaian masalah.

Dalam waktu enam bulan setiap proses telah secara bertahap disempurnakan beberapa kali dan masing-masing tim telah dilaksanakan setiap proses setidaknya sekali. Perbaikan yang pengurangan besar (lebih dari 50%) di:

Cacat kode

Cacat Dokumentasi

Kode yang belum diuji

Solusi terkait

   Sebuah variasi dari asap dan cermin mini-antipattern menggambarkan penggabungan backup teknis ke dalam rencana dan kegiatan proyek. Ini merupakan pelengkap penting untuk manajemen risiko, dan meringankan kesalahan strategis yang diperkenalkan oleh Proyek salah urus.
Brad Appleton menyajikan pola desain bahasa yang sangat baik untuk meningkatkan proses pengembangan perangkat lunak dalam makalahnya pada perbaikan proses Menerapkan perbaikan proses adalah elemen kunci dalam menyelesaikan proyek urus".