Bagaimana jadwal yang ketat dan tekanan penjadwalan mempengaruhi TCO dan waktu pengiriman?

Ayah seorang teman, yang adalah manajer rekayasa perangkat lunak, berkata dengan tegas, "Penyebab nomor satu dari penjadwalan overruns adalah tekanan penjadwalan."

Di mana posisi penelitian? Apakah jumlah tekanan penjadwalan sedang, atau apakah manajer yang saya sebutkan benar atau salah, atau apakah itu masalah "semakin banyak tekanan penjadwalan yang Anda miliki, semakin lama waktu pengiriman dan lebih banyak TCO?" Apakah ini salah satu dari hal-hal di mana idealnya rekayasa perangkat lunak akan bekerja tanpa tekanan penjadwalan tetapi secara praktis kita harus bekerja dengan kendala situasi dunia nyata?

Setiap tautan ke literatur rekayasa perangkat lunak akan dihargai.

Penyebab nomor satu penjadwalan overruns adalah tekanan penjadwalan.

Saya tidak setuju. Penyebab nomor satu dari penjadwalan overruns adalah jadwal yang tidak mencerminkan kenyataan, dan terlalu optimis. Sifat manusia menentukan bahwa beberapa tekanan penjadwalan adalah kebutuhan mutlak. Hanya beberapa masalah yang muncul tanpa sejumlah tekanan penjadwalan adalah masalah yang menarik dan "yang terbaik adalah musuh yang cukup baik." Kami orang-orang teknis jauh lebih suka mengerjakan masalah yang menarik minat kami daripada masalah yang perlu dipecahkan untuk mengeluarkan produk. Singkirkan tenggat waktu (alias tekanan jadwal) dan kami akan mengerjakan masalah-masalah menarik itu, sehingga merugikan produk.

Masalah lain adalah bahwa produk tersebut harus "cukup baik". Tidak perlu sempurna. Insinyur dan ilmuwan melihat asumsi penyederhanaan yang tidak cukup valid dalam beberapa keadaan kasus khusus. Desainer grafis melihat masalah alias yang tidak terlihat oleh orang lain. Pemrogram melihat kutil dalam arsitektur mereka yang tidak berdampak pada perilaku produk. "Yang terbaik adalah musuh yang cukup baik," yang berarti bahwa kadang-kadang kita harus hidup dengan masalah yang tidak terlalu masalah.

Kurangnya tekanan penjadwalan akan menyebabkan produk dengan biaya kepemilikan yang sangat tinggi. Apa yang menyebabkan overruns adalah jadwal yang buruk. Ini bisa datang dalam berbagai bentuk. Diperlukan upaya meremehkan, gagal memperhitungkan ketergantungan, menambahkan orang ke proyek yang sudah terlambat. Untuk beberapa nama.

Waktu, kualitas, sumber daya, dan jumlah fitur semuanya terhubung. Anda dapat memperbaiki ketiganya, dan mendapatkan yang terakhir sebagai hasil dari proses penjadwalan Anda.

Cara pertanyaan Anda dirumuskan menyiratkan bahwa waktu adalah variabel Anda, dan tiga lainnya (kualitas, sumber daya, dan jumlah fitur) semuanya tetap. Pertanyaannya mungkin mendapat manfaat dari sedikit mengubah perspektif dengan memperbaiki waktu ^* , dan membiarkan kualitasnya melayang.

Sekarang pertanyaan Anda menjadi ini: "Apakah batasan waktu berdampak negatif pada kualitas"? Jawaban untuk pertanyaan ini adalah "Ya": penelitian menegaskan bahwa orang lebih buruk di bawah tekanan pada masalah yang berkaitan dengan matematika ^** bahwa mereka belum berlatih secara luas sebelumnya (yaitu mencoba lima puluh kali atau lebih), sehingga ayah teman Anda benar.

^** Ada asumsi implisit di sini bahwa pemrograman mirip dengan melakukan matematika; Saya pikir asumsi ini adil.

semakin banyak tekanan penjadwalan yang Anda miliki, semakin lama waktu pengiriman dan lebih banyak TCO?

Yah, setiap penjadwalan yang dilakukan oleh manajer tanpa mendiskusikannya dengan pimpinan teknis cenderung untuk itu. Adalah kebenaran yang sangat jelas bahwa Penjadwalan atau estimasi yang TIDAK berdasarkan fakta cenderung gagal .

Selain itu, manajer yang menghindari Penjadwalan Berbasis Bukti juga bergerak menuju kegagalan proyek mereka berikutnya. Ada sejumlah studi tentang topik ini dan penjadwalan berdasarkan metrik adalah cara yang tepat untuk diikuti.

Penjadwalan dari kanan ke kiri.

Seseorang dalam manajemen selalu berpikir mereka adalah Steve Jobs dengan zona distorsi realitas yang terkenal. Sampai seseorang dalam pengembangan produk mendidik mereka, manajer non-teknis mungkin sering memiliki pandangan tentang penjadwalan yang secanggih film Prancis awal "Le voyage dans la lune" ("Perjalanan ke Bulan") adalah untuk ilmu roket.

Masalahnya sudah ada untuk sementara waktu. Fred Brooks berbicara tentang taksiran usus dalam Mythical Man-Month . Barry Boehm membicarakannya dalam proposal untuk pendekatan Theory-W untuk manajemen. Baru-baru ini, Steve McConnell (penulis Code Complete ) membawa konsep masalah negosiasi berprinsip menjadi fokus dalam "Cara Membela Jadwal yang Tidak Populer" .

Agile mendorong ruang lingkup proyek ke tempat yang sangat terlihat. The Agile Manifesto panggilan untuk "kolaborasi Pelanggan atas negosiasi kontrak". Saya harap, ini juga memberdayakan orang-orang yang bertanggung jawab. The Game perencanaan menghindari pemangku kepentingan non-teknis memaksa pengembang untuk janji-janji mereka membuat lama yang telah overrun oleh perubahan persyaratan atau penemuan-penemuan baru.

Jika organisasi Anda menolak gesit, ada metode hebat yang terkait dengan kalibrasi estimasi untuk rebaseline jadwal berdasarkan nilai yang diperoleh . Saya tidak berpikir bahwa nilai yang didapat dapat bekerja dengan baik dengan beberapa masalah nyata dengan prediksi, tetapi hal itu dapat membantu menghilangkan delusi tentang kecepatan proyek dan menggerogoti perkiraan yang kita miliki sebagai fakta.

Ada pepatah yang mengatakan bahwa semakin cepat Anda memulai kode, semakin lama waktu yang dibutuhkan. Tekanan jadwal dapat memiliki efek memaksa perubahan metodologi. Kadang-kadang dari air terjun ke "kode seperti neraka". Ini dapat memiliki dampak negatif pada kualitas, belum lagi semangat ketika pekerja tidak dapat melakukan yang terbaik dan rekan-rekan mereka dan pemelihara masa depan melihat mereka dalam kondisi terburuk, bukan yang terbaik. Dalam lingkungan seperti ini, beberapa tingkat kekacauan dapat dikontrol dengan kontrol sumber, pembangunan dan pengujian harian (atau integrasi terus-menerus dan uji unit), tinjauan kode, menggunakan tim yang berpengalaman dan sangat terampil, menahan godaan untuk menambah staf di akhir proyek, dan siaga lama, lembur.

Di lain waktu, perubahan metodologi mungkin dari air terjun ke peningkatan berulang. Pengalaman saya adalah bahwa manajemen lambat untuk merangkul Agile. Tapi kemudian setelah beberapa saat ada manajemen baru yang lebih mendukung Agile. Time boxing bisa seperti penganggaran - itu bisa memaksa kita untuk berpikir tentang penggunaan terbaik sumber daya terbatas. Scrum memiliki dua kotak waktu - satu adalah harian untuk umpan balik antara anggota tim, yang lainnya adalah bulanan untuk sprint melalui daftar burn down.

Creative Commons License - lihat http://en.wikipedia.org/wiki/File:Scrum_process.svg

Anda tidak perlu literatur rekayasa perangkat lunak. Probabilitas dan statistik konseptual, dari sarjana, adalah semua yang Anda butuhkan.

Perkiraan hanya itu, perkiraan. Itu tidak tepat, tidak dijamin. Untuk perkiraan apa pun, ada beberapa kemungkinan bahwa Anda akan melakukan underrun, atau memukulnya dengan hidung, dan beberapa probabilitas bahwa Anda akan overrun itu.

Probabilitas 101: p (underrun atau tekan tepat) + p (overrun) = 100%.

Jadwal berdasarkan estimasi memiliki karakteristik yang sama persis.

Anda tidak bisa menghilangkan ketidakpastian sepenuhnya. Akan SELALU ada kemungkinan dibanjiri. Mungkin kecil, kemungkinan Iran nuking gedung kantor Anda, tetapi masih ada. Yang terbaik yang dapat Anda lakukan adalah melihat SEMUANYA, dan mengurangi ketidakpastian sebanyak yang Anda bisa. Setelah Anda melakukannya, Anda akan, jika beruntung, memiliki jadwal dengan ketidakpastian kecil, dan kemungkinan 50% di setiap sisi.

Sekarang, pikirkanlah: Jika Anda menarik jadwal, kemungkinan Anda akan mengalami underrun atau tepat mengenai jadwal berkurang. Total masih harus dijumlahkan hingga 100%. Kemana perginya probabilitas itu? Jawab, masuk ke probabilitas overrun.

General Dynamics / Fort Worth Division mempelajari ini dengan cara yang sulit. Mereka melakukan estimasi awal untuk pengembangan F-16C / D, dan mengirimkannya ke rantai makanan. Seseorang yang lebih tinggi secara sewenang-wenang memotong satu tahun darinya, dan mengirimkannya ke Angkatan Udara. Sebagai akibat langsung, GD / FW terlambat satu tahun untuk tes penerbangan, dan Angkatan Udara TIDAK bahagia. (Perhatikan bahwa "terlambat satu tahun" sesuai dengan jadwal yang direvisi, artinya jadwal asli adalah TEPAT TEPAT.)

Saya berpikir bahwa sejumlah tekanan dalam suatu proyek adalah OK karena membantu mempertahankan fokus.

Namun, jika tekanannya tidak realistis, atau jika komunikasi antara manajemen dan tenaga teknis tidak berfungsi dengan baik, ya, ada risiko tekanan penjadwalan menghasilkan kualitas yang buruk dan / atau keterlambatan pengiriman.

Pengembang yang berpengalaman akan tahu bahwa dia tidak diharapkan untuk menghasilkan solusi yang sempurna tetapi lebih merupakan solusi yang cukup baik . Jadi perkiraan yang diberikan oleh pengembang seperti itu sudah akan mencerminkan pemahaman mereka tentang apa yang cukup baik untuk proyek tertentu.

Ada banyak faktor yang mempengaruhi definisi cukup baik.

Misalnya, berapa bulan proyek ini bertahan? Jika proyek berlangsung satu tahun, Anda dapat menulis prototipe modul yang sangat sulit itu agak cepat di awal proyek dan kemudian Anda memiliki beberapa bulan untuk menguji dan men-debug-nya sebagai kegiatan sampingan untuk pengembangan modul lain yang lebih rutin. (Anda dapat membiarkan modul itu matang selama beberapa bulan sampai cukup baik sehingga Anda tidak perlu mencoba dan melakukannya sejak awal.) Saya menemukan strategi ini sangat efektif tetapi Anda membutuhkan manajer yang mempercayai Anda dan akan membiarkan Anda buka proyek selama berbulan-bulan. Manajer (tidak percaya) lain mungkin mendorong Anda untuk menyelesaikan modul itu sesegera mungkin (tidak masalah jika Anda harus memperbaikinya nanti dan jika pendekatan ini pada akhirnya akan menghabiskan lebih banyak waktu total).

Contoh lain: proyek ini untuk produk yang hanya memiliki satu rilis. Kemudian Anda dapat mencoba menyelesaikannya dengan cepat dan mengandalkan tes ekstensif untuk memastikan bahwa produk berfungsi seperti yang diharapkan (cepat dan kotor sudah cukup baik ). Di sisi lain, jika produk akan memiliki dua atau tiga rilis, lebih baik luangkan waktu untuk mendesainnya, untuk menghindari penulisan ulang kode secara ekstensif untuk rilis selanjutnya. (Dalam hal ini, cepat dan kotor tidak cukup baik karena total waktu pengembangan selama tiga rilis lebih besar.)

Intinya, saya berpikir bahwa komunikasi yang buruk antara manajemen dan orang-orang teknis dan kurangnya pemahaman bersama tentang apa yang cukup baik untuk proyek yang ada dapat menyebabkan tekanan penjadwalan yang berlebihan, menghasilkan kualitas yang buruk / pengiriman terlambat.

Tidak pernah ada cukup waktu untuk melakukannya dengan benar pertama kali, tetapi selalu ada cukup waktu untuk memperbaikinya nanti.