Mengapa terlambat untuk penerbangan dan tidak terbang tidak selalu merupakan hal yang buruk? Siapa yang harus disalahkan karena terlambat ke dermaga? Mengapa datang ke bandara terlebih dahulu? Bisakah A380 terbang ke Astrakhan? Mengapa intuisi tidak selalu berhasil? Kejutan terjadi - tidak pernah terjadi dan di sini lagi? Mengapa penumpang membanting pilot setelah mendarat?Misalkan Anda sedang mengembangkan sistem informasi berskala negara (SIG) skala nasional. Tim proyek (analis, pengembang, penguji, layanan pendukung, layanan infrastruktur, dll.) Lebih dari seratus orang. Sistem ini diterapkan dalam operasi percontohan atau industri. Ribuan organisasi telah terintegrasi dengan sistem Anda dan mulai bekerja dengannya, bahkan lebih banyak lagi merencanakan integrasi. Puluhan ribu organisasi bekerja melalui antarmuka Web. Sistem ini berisi informasi yang berguna bagi warga negara dan menyediakan fungsi yang menarik. Pelanggan dan / atau pengguna membutuhkan peningkatan baru. Jutaan orang di seluruh negeri terdaftar dan menggunakan sistem. Hadiah dari dunia luar datang dalam bentuk perubahan harga minyak, sanksi, pembatasan, dll.
Disajikan? Jadi, proyek yang persis seperti itu saat ini adalah proyek perumahan GIS dan layanan komunal, yang telah kami
bicarakan sebelumnya dan sekarang kami ingin melanjutkan.
SumberPengalaman pertama Wright bersaudara
Kemungkinan besar, jika Anda bekerja di perusahaan kecil dan mengembangkan "proyek kecil", maka Anda tidak memiliki banyak proses rilis seperti itu. Skema kerjanya terlihat seperti ini. Anda hanya berpura-pura merilis beberapa fitur dalam 4-5 bulan. Kemudian Anda menulis produksi untuk satu bulan lagi, mengembangkan, mengembangkan, kemudian mencoba menstabilkan semua ekonomi ini untuk merilis versi baru dari perangkat lunak ke dalam operasi. Tentu saja, pada saat rilis ternyata beberapa perbaikan tidak dapat distabilkan dengan cara apa pun, di suatu tempat cacat dalam produksi terungkap, karena produksi telah dilakukan untuk waktu yang lama dan sekarang ada sesuatu yang berubah, di suatu tempat ternyata mereka masuk di bawah fungsi yang tidak realistis, dll. Namun demikian, pendekatan ini bekerja dengan baik untuk dirinya sendiri, tetapi, sebagai aturan, selama tim proyek kecil dan intensitas perubahannya kecil (sistem tidak dioperasikan atau diujicobakan oleh beberapa pengguna, dll.). Pada prinsipnya, tanpa proses, Anda dapat meningkatkan hingga proyek yang cukup besar - hingga 20 orang dan hingga 40 orang - semuanya tergantung pada kesejukan individu dan dedikasi mereka. Tentunya banyak orang yang akrab dengan situasi ketika tim proyek, yang terdiri dari spesialis yang keren dan putus asa, dalam kasus-kasus di mana tenggat waktu ada dan hampir semuanya menghilang secara tegang secara damai dan ... "di pundak mereka", "pada kotak pizza yang bermoral dan berkemauan keras" melalui pegunungan akhirnya menarik versi ke dalam operasi.
Percayalah, kami juga melewati ini (itu sebabnya kami sekarang suka semua jenis hal gila seperti
Racing Heroes ,
maraton , dll.). Tetapi pada titik tertentu, kami menyadari bahwa semuanya memiliki batas dan bahwa ketika menerapkan perumahan skala GIS dan sistem layanan komunal tanpa proses rilis yang jelas, kami dijamin akan mendapatkan tiga momen tidak menyenangkan utama:
- pelanggan tidak senang dengan Anda, karena Anda tidak dapat memprediksi tanggal rilis fungsionalitas ke dalam operasi dan terus-menerus memutus tenggat waktu, dan jika tugas yang tidak terduga muncul, ini menyebabkan masalah besar;
- kualitas hidup karyawan memburuk karena kekacauan konstan, pertikaian, lembur, dll.
- para pemimpin perusahaan Anda tidak puas dengan Anda, karena biaya akan sepenuhnya tidak terkendali.
Pengalaman LANIT dalam pengembangan perumahan GIS dan layanan komunal memberi tahu kami bahwa salah satu momen paling penting untuk beralih ke "rel industri" dalam implementasi proyek besar adalah konstruksi kualitas proses pelepasan. Ini, tentu saja, tidak cukup untuk kebahagiaan total, tetapi proses pelepasan mendasari segalanya, dan tanpa itu Anda dijamin akan jauh lebih buruk daripada yang seharusnya.
Dalam artikel ini kami akan menjelaskan dua utama, menurut pendapat kami, praktik yang mendasari proses rilis efektif dalam sistem TI skala perumahan GIS dan layanan komunal:
- penggunaan skema pengiriman fungsionalitas reguler,
- siklus rilis yang dipersingkat.
Di satu sisi, praktik-praktik ini cukup terkenal dan digunakan dalam banyak metodologi, serta dicatat dalam
Agile Manifesto . Namun, mereka sebagian besar bertentangan dengan intuisi, membutuhkan kualifikasi dan keterampilan tertentu, dan oleh karena itu sulit untuk dibenarkan dan bertemu dengan kurangnya pemahaman baik pada Pelanggan dan dalam tim proyek. Implementasi mereka dalam standar perusahaan akan membutuhkan pemahaman yang sangat baik tentang "apa yang ingin kita capai" dan "mengapa implementasi dari praktik-praktik ini akan mengarah pada hasil yang diinginkan". Di bawah ini kami akan mempertimbangkan dengan contoh praktik-praktik ini dan masalah utama dalam penerapannya.
Ketika kami menganalisis proses internal kami terkait dengan manajemen pelepasan, sebuah asosiasi dengan pekerjaan sebuah maskapai penerbangan modern muncul di kepala saya.
Lalu lintas udara reguler
Maskapai ini membuat analisis pasar, meramalkan rute mana yang akan memiliki arus penumpang besar dan akan menjadi menguntungkan untuk musim berikutnya, bernegosiasi dengan siapa yang dibutuhkan, mendapatkan hak atas rute yang diperlukan, meluncurkan penerbangan reguler. Jadwal penerbangan dikenal untuk waktu yang lama, sebagai aturan, selama enam bulan hingga satu tahun. Siapa yang benar-benar terbang, maskapai ini, tentu saja, tidak diketahui - ini berfokus pada rata-rata proyeksi hunian. Lebih lanjut, maskapai ini dapat membuat perjanjian jangka panjang dengan bandara, memikirkan pesawat mana yang paling menguntungkan untuk digunakan dalam penerbangan, membuat prosedur internalnya sendiri, dll. Ini semua berkontribusi pada optimalisasi biaya.SumberJika seorang karyawan perusahaan perlu berpartisipasi dalam pertemuan penting pada waktu tertentu, dan kemudian terbang ke kota lain dengan pesawat, maka ia hanya memilih penerbangan untuk dirinya sendiri dengan mempertimbangkan risiko bahwa pertemuan itu mungkin tertunda dan situasi lalu lintas.
Penerbangan reguler memiliki kelemahan. Jika seorang karyawan membeli tiket untuk penerbangan, tetapi tidak punya waktu, maka pesawat tidak akan menunggunya. Tidak menyenangkan? Ya Mungkin karyawan tersebut perlu terbang hari ini, dan hanya ada penerbangan besok atau hanya seminggu dari sekarang. Tidak begitu bagus? Ya Namun kelebihannya adalah Anda dapat merencanakan perjalanan selama enam bulan atau satu tahun dan memastikan bahwa penerbangan akan berlangsung. Anda tahu persis kapan Anda tiba, dan Anda dapat memberi tahu waktu ini kepada orang yang Anda cintai yang dapat bertemu dengan Anda, atau Anda dapat terbang dengan transfer dan tidak khawatir bahwa Anda tidak akan punya waktu untuk berlabuh. Nah, secara umum, pikirkan tentang itu, sebuah pesawat besi yang besar dan berat, yang bagi 90% umat manusia tidak mengerti bagaimana ia terbang sama sekali, akan sangat cepat membawa Anda, iblis tahu di mana dan itu akan menghabiskan biaya Anda seperti satu atau dua hari di kereta.Mari kita kembali ke proyek. Utilitas GIS menggunakan persediaan fungsionalitas biasa. Tim
LANIT membuat jadwal rilis selama 1 tahun, di mana ia memperbaiki tanggal rilis sehingga rilis sekitar 1 kali per bulan. Karena selama tahun ini semuanya masih dapat berubah seratus kali (lebih dari itu di bawah), pada saat menyusun jadwal, kami masih tidak tahu persis perbaikan apa yang akan dilaksanakan dan dioperasikan.
Saat merencanakan, jadwal pemeliharaan rutin yang diperlukan untuk layanan infrastruktur / operasi diperhitungkan. Adalah perlu bahwa perubahan global dan heterogen tidak saling tumpang tindih - dengan cara ini risiko dikurangi dan lebih mudah untuk menjaga semuanya terkendali. Misalnya, menginstal versi baru perangkat lunak dan secara bersamaan meningkatkan versi DBMS atau memperbarui firmware pengontrol penyimpanan adalah ide yang sangat buruk.
Poin penting adalah bahwa tanggal rilis tidak berubah setelahnya. Jika versi ini direncanakan untuk beberapa tanggal, maka kita harus membobol kue, tetapi menahan waktu yang direncanakan.Selanjutnya, kami akan menjelaskan mengapa dan mengapa.
Fakta bahwa kondisi untuk setiap rilis kira-kira sama (durasi, tim, tugas spesifik, dll.) Memungkinkan Anda untuk merencanakan dan men-debug semua persiapan dan prosedur rilis.
Orang yang tidak tenggelam dalam proses produksi mungkin tidak memahami kompleksitas merilis versi pada proyek besar seperti perumahan GIS dan layanan komunal. Agar versi yang akan dirilis, Anda perlu melakukan banyak operasi, seperti pengujian regresi (mungkin beberapa kali), pengujian beban, pengujian skrip penyebaran dan migrasi, analisis statistik kinerja (kueri SQL, layanan, dll.) . Situasi ini diperburuk oleh fakta bahwa operasi ini bisa lama, misalnya, menggunakan versi di bangku tes dapat memakan waktu sehari. Jika terjadi kesalahan, Anda dapat dengan mudah keluar dari jadwal. Karena itu, jika Anda tidak memiliki jadwal dengan siklus durasi reguler dan kira-kira sama, maka saya jamin setiap masalah bagi Anda adalah 146% tes yang jauh lebih serius.
Jadwal juga diperlukan untuk menentukan tenggat waktu untuk koreksi cacat dan mengkomunikasikannya kepada pengguna. Kami, sebagai suatu peraturan, memperbaiki sebagian besar cacat yang ada dalam versi saat ini. Namun, beberapa cacat mungkin memerlukan lebih banyak waktu, atau mereka dapat terjadi pada akhir siklus rilis, sehingga mereka dipindahkan ke versi berikutnya. Jika karena alasan tertentu (lihat di bawah) kami mulai mengubah versi, maka pengguna akan secara otomatis menerima koreksi nanti, yang tidak baik.
Jadwal rilis versi juga diperlukan untuk merencanakan rilis ke dalam operasi perbaikan yang memiliki tenggat waktu yang jelas. Tim produksi memahami persis kapan revisi harus dioperasikan dan memilih rilis yang diinginkan, di mana itu dirilis. Jika tanggal rilis ditunda, ini dapat menyebabkan fakta bahwa revisi akan dirilis terlambat (tentang konsekuensi dari perubahan versi karena tugas penting, lihat di bawah)
Sama seperti jaringan transportasi reguler, ini adalah dasar dari sistem transportasi global, proses pelepasan berdasarkan pengiriman fungsionalitas secara teratur adalah dasar untuk pengembangan yang efektif dari perumahan skala GIS dan sistem layanan komunal. Jika proses ini dibuat, maka sudah dimungkinkan untuk "merangkai" rencana untuk implementasi dan pengiriman fungsionalitas.
Sayangnya, cara untuk memperkenalkan praktik yang tampaknya bermanfaat dari semua pihak itu sulit dan sulit. Berikut ini adalah jebakan-jebakan utama yang dapat menyebabkan tim jatuh dan mana yang harus dipantau dan ditekan.
Naik pesawat setelah registrasi
Maskapai memiliki prosedur check-in yang efisien untuk penerbangan, yang secara khusus mencakup aturan bahwa penumpang harus check-in untuk penerbangan selambat-lambatnya 40 menit sebelum keberangkatan. Mengapa Anda membutuhkan 40 menit ini? Mereka diperlukan sehingga ada cukup waktu untuk memeriksa bagasi, memuatnya ke dalam pesawat, sehingga berdasarkan berat bagasi dan jumlah penumpang terdaftar dimungkinkan untuk menghitung bahan bakar yang dibutuhkan, mengisi bahan bakar pesawat, dll. Selain itu, waktu ini diperlukan agar penumpang memiliki cukup waktu untuk menemukan pintu keluar / terminal yang diinginkan. Jelas bahwa ada sesuatu yang salah dengan kargo atau penumpang (penumpang tersesat di bandara atau sesuatu terjadi dengan barang bawaan) dan bahkan 40 menit ini tidak akan cukup. Namun demikian, waktu akhir pendaftaran adalah kompromi yang dilakukan selama bertahun-tahun antara membuang waktu penumpang dan risiko situasi darurat.
Jika seorang penumpang suka tiba di bandara tepat di sebelah akhir check-in, maka ini berarti bahwa dia setuju dengan peningkatan risiko bahwa sesuatu akan terjadi dan dia tidak akan tepat waktu untuk pesawat. Jika maskapai bertemu orang-orang ini, ini akan mengarah pada fakta bahwa itu akan meningkatkan risiko. Mungkin dia harus membayar untuk penerbangan bus khusus ke pesawat hanya untuk penumpang ini. Mungkin, terburu-buru saat check-in di saat terakhir, staf bandara akan melakukan kesalahan dan barang bawaan akan terbang ke kota yang salah.SumberSaat merilis rilis, salah satu poin paling penting adalah kriteria yang harus dipenuhi oleh revisi dan tenggat waktu kapan harus dilakukan (mirip dengan akhir check-in). Rilis versi setiap bulan berarti bahwa jika beberapa tugas tidak siap untuk tenggat waktu ini dalam versi perangkat lunak saat ini, maka itu ditransfer ke rilis berikutnya dalam sebulan. Seringkali Anda bisa tahan dengan ini, tetapi sangat sulit untuk melakukan ini ketika tugas sangat penting, tetapi pada saat yang sama itu hanya beberapa hari atau seminggu terlambat. Ada godaan yang sangat besar untuk melanggar tenggat waktu dan memasukkan tugas yang belum siap dalam rilis dan mencoba untuk memerasnya.
Kenapa ini buruk?
Pertama,
kita harus dengan berani mengakui dan menerima kenyataan bahwa, bahwa semua "tekanan", "bagaimana jika kita menangkapnya" kemungkinan besar merupakan tusukan manajemen produksi. Ini berarti bahwa berbagai langkah tidak diambil sebelumnya dan situasi menjadi kritis. Sekarang situasinya akan dikoreksi karena “pahlawan” individu atau tim - lembur, kruk, keberuntungan, dll. Dari pengalaman, ini dapat mengarah ke solusi untuk masalah dalam jangka pendek, tetapi jika Anda melakukan ini sepanjang waktu, itu akan menyebabkan orang “kehabisan tenaga” dan konsekuensi lain yang sangat tidak menyenangkan.
Kedua, seperti dalam contoh dengan maskapai, batas waktu untuk kesiapan tugas adalah kompromi antara jadwal dan risiko. Jika kami mulai melanggar batas waktu, maka kami meningkatkan risiko masalah dengan versi - baik seluruh versi tidak akan dirilis tepat waktu, atau kualitasnya akan berkurang, dan kami akan menerima sejumlah panggilan karena fungsi yang tidak beroperasi atau masalah yang bekerja di bawah beban.
Sayangnya, situasi ketika ada tugas yang sangat, sangat penting dan perlu untuk melepaskannya dalam rilis saat ini, muncul. Tetapi gagasan utamanya adalah bahwa situasi seperti itu seharusnya tidak diterima secara umum sebagai praktik dan dorongan, tetapi lebih diakui sebagai masalah dan dipertimbangkan dalam “retrospektif”.Keterlambatan Penerbangan karena Penumpang VIP
Katakanlah Anda membeli penerbangan dengan transfer. Misalkan Anda menemukan waktu yang memadai antara bergabung. Anda tiba sebelumnya di bandara, pergi check-in, naik pesawat, menelepon ayah dan ibu saya, dan kemudian mereka mengumumkan bahwa penerbangan tertunda, karena delegasi pemerintah penting terlambat untuk itu (tentu saja, sebaliknya mereka akan memberi tahu Anda tentang cuaca buruk atau cek tambahan :)). Anda, bersama dengan seluruh pesawat, sedang menunggu delegasi ini dan, sebagai hasilnya, terbang dengan penundaan yang signifikan. Setibanya di titik tengah, Anda hanya punya waktu 30 menit untuk menavigasi di bandara besar, secara fisik sampai ke terminal lain. Mungkin Anda, tentu saja, akan tepat waktu, atau mungkin Anda akan membingungkan sesuatu dengan terburu-buru dan melarikan diri ke terminal yang salah atau bahkan tidak punya waktu untuk melalui semua prosedur yang diperlukan. Dan jika Anda juga anggota dari beberapa organisasi pemerintah lainnya (tetapi hanya sederhana) dan juga terburu-buru di suatu tempat?SumberJadi, jika maskapai secara teratur mengizinkan pergantian penerbangan, maka ini akan menimbulkan masalah dari semua pihak. Untuk seorang penumpang, ini berarti bahwa ia perlu meluangkan lebih banyak waktu untuk koneksi, penumpang akan lebih cenderung untuk mengambil risiko dan segera tiba di akhir pendaftaran. Ini akan menyebabkan lebih banyak konflik dan buang-buang waktu. Untuk maskapai, ini juga berarti bahwa lebih banyak waktu diperlukan untuk waktu henti di bandara, sehingga meningkatkan biaya.Dalam proses rilis, jika tiba-tiba beberapa tugas tidak memiliki waktu untuk waktu yang dijadwalkan, ada juga godaan besar untuk memindahkan seluruh rilis - misalnya, seminggu. Tampaknya ini adalah solusi yang mudah dan baik, terutama jika tugas ini di bawah kendali pelanggan utama.Mari kita lihat apa yang menyebabkan semua ini.
Dalam proyek perumahan GIS dan layanan komunal, dalam kerangka rilis berikutnya, hingga 100 tugas dan lebih banyak perbaikan bug dikeluarkan. Pergeseran rilis berarti bahwa pengguna akan mendapatkan fungsionalitas yang mereka butuhkan atau perbaikan bug nanti. Tentu saja, masalah yang sedang dibahas sangat penting, tetapi pada saat yang sama, banyak dari 99 tugas yang tersisa juga sangat penting, tetapi karena semuanya normal dengan mereka, kami sudah melupakannya.
Selanjutnya Jika kami mulai secara teratur mengganti versi, maka pelanggan mulai kehilangan kepercayaan pada rencana rilis. Dia selalu berpikir bahwa ya, tentu saja, rilis berikutnya dijadwalkan untuk tanggal 10, tetapi kemungkinan besar sesuatu akan terjadi dan akan ada perubahan seminggu, atau bahkan dua. Alasan pergeseran mungkin berbeda, tetapi pada akhirnya mereka semua dilupakan dan masih ada perasaan proses yang tidak stabil dan buram.
Apa yang menyebabkan ini? Selain itu, jika terjadi kerusakan atau tugas yang mendesak, pelanggan tidak setuju untuk merilisnya sebagai bagian dari rilis tertentu, tetapi membutuhkan versi khusus atau perbaikan terbaru. Sebagai hasilnya, kami memiliki biaya tambahan yang signifikan.Jika kami mengizinkan perubahan versi, maka ini mengurangi kemampuan untuk mengoptimalkan proses. Sebaliknya, jika prosedur rilis seragam dan teratur, maka kami memiliki kesempatan untuk memperbaikinya. Setelah rilis versi, kami melakukan "retrospektif", di mana kami membahas poin positif dan negatif utama yang terjadi selama iterasi. Dengan setiap pengulangan, kami melakukan beberapa perbaikan, sebagai akibatnya, biaya overhead berkurang, jumlah kesalahan berkurang, hasilnya ditingkatkan.
Kenapa pesawat besar tidak selalu lebih baik
Maskapai ini dapat menggunakan berbagai jenis pesawat pada rute: pesawat regional untuk 75-110 penumpang (tipe SSJ-100 ), atau pesawat berbadan sempit untuk 140-180 penumpang (tipe A320 , Boeing 737 ), atau pesawat berbadan lebar untuk 200-300 penumpang (tipe A330 , A340 ), atau monster seperti A380 , yang mampu mengangkut 525 hingga 853 penumpang. Secara sederhana, kita dapat mengasumsikan bahwa maskapai memilih jenis pesawat yang diinginkan dan intensitas penerbangan yang diinginkan sebagai kompromi dari keinginan penumpang untuk memiliki sebanyak mungkin penerbangan sehari dan keinginan maskapai untuk mengurangi biaya transportasi satu penumpang untuk memaksimalkan keuntungan mereka.Sekarang setidaknya tiga maskapai terbang ke kampung halaman saya di Astrakhan, membuat satu penerbangan sehari dengan pesawat regional atau berbadan sempit. Bahkan jika infrastruktur bandara di Astrakhan akan memungkinkan penerimaan A380 (pesawat Airbus terbesar dan paling luas), untuk memuatnya, orang harus secara drastis mengurangi intensitas penerbangan, yang akan sangat merepotkan bagi penumpang. Jika perbedaan biaya tidak besar, maka penumpang akan lebih memilih jumlah penerbangan yang lebih besar per hari.Kira-kira logika yang sama beroperasi dalam proses rilis. Semakin pendek waktu antara versi rilis, semakin baik bagi pelanggan.
, . , , . , , .
.
, . , , , , , . , , “” . , , . . , ( , , , , , , ).
1. ( ), “ , , ” , . , . , . , , — , .
- , . .
—
, . , . , , - , .- , — , , ( ).
, , , . , , . — , (- ) . , , . , , , “” . , , . , . , 1,5-2 , 1,5 , -.
, :
— — , — , — , .
:
— , , . .
, , . .
. , , .. , . , , . .
, . , , , . , !, — . , , , . , , . . , . , , , . , , . , , .
, , , . , 4 , 2-3. . , .
, , .
. ( — ), .. . , - , , . - , . — , . . , , , . , ( , , , , , , , ..), . , , 2018 2018 , , ASAP . 4-5 ! 5 , 2-3 , 1-1,5 .
, , — .!
. , ! ., - , . , , . , , , - , . , , .
, , , , , , . — , .
, - , - . - . , . , , . , , , .
, . . , , - , .
, . , - , , .
, . , :
.
. ? ? ?