Setiap produk berkembang dengan cara misterinya sendiri. Malah pasukan yang berpengalaman tidak dapat meramalkan setiap perubahan dalam kitaran hayat produk. Ciri mudah boleh dipindahkan ke dalam aliran kerja berbilang keadaan yang mengerikan. Beberapa senario sampingan yang dibangunkan pantas boleh menjadi yang paling banyak digunakan. Malah populariti produk boleh mendorong isu prestasi yang tidak dijangka. Dan adalah perkara biasa untuk menyesuaikan perisian untuk keperluan pasaran. Satu-satunya cara untuk memiliki produk yang boleh dipercayai dan boleh diramal adalah dengan memperuntukkan sedikit masa untuk menyelesaikan hutang teknikal dan menyediakan proses pemfaktoran semula yang betul. Adalah lebih baik untuk memasukkan beberapa definisi istilah dalam artikel ini. Hutang teknikal, atau hutang teknologi, ialah kompromi terkumpul dalam pangkalan kod, yang mungkin berlaku semasa pembangunan pantas atau turun naik lain. Proses pemfaktoran semula lebih kepada menambah baik produk secara umum. Ia mungkin melibatkan aktiviti yang berkaitan dengan prestasi, struktur kod yang lebih baik dan kesederhanaan penyelesaian. Walau bagaimanapun, kadangkala kedua-dua konsep ini boleh menjadi sangat rapat. Sebagai contoh, beberapa ciri yang penuh dengan hutang teknologi mungkin memerlukan pemfaktoran semula yang betul bagi keseluruhan modul untuk menyelesaikan masalah sekali dan untuk semua dengan idea baharu dan pelaksanaan semula. Dan inilah muslihatnya. Secara umum, pembangun perisian yang baik mempunyai banyak idea untuk penambahbaikan produk. "Baiklah, kami boleh mengubah suai beberapa perkara semasa ciri ini." "Oh, itu tidak begitu penting tetapi adalah baik untuk membetulkan perkara ini dalam modul sampingan ini". Namun, adalah penting untuk membenarkan ahli pasukan anda berpeluang meningkatkan pangkalan kod, kerana ia membantu membina pasukan yang terlibat sebenar. Walau bagaimanapun, dalam artikel ini, saya ingin mendedahkan proses pemfaktoran semula dari perspektif pengurus. Contoh di atas mempunyai satu masalah - ia mungkin legap untuk seluruh pasukan kecuali devs. Walaupun QA dan pengurus mempunyai rancangan mereka untuk mengeluarkan perisian yang betul dan stabil mengikut jadual, beberapa penambahbaikan tersembunyi boleh mencipta kelainan yang tidak dijangka dan ujian semula saraf semasa keluaran. Atau pepijat baharu dalam pengeluaran jika melalui peringkat regresi, beberapa perubahan tanpa dokumen tidak disedari. Jadi, penambahbaikan kod adalah perlu, tetapi ia harus boleh diurus. Cara membina proses pemfaktoran semula yang boleh diurus dalam pasukan anda Penyelesaiannya adalah kompleks. Agile ialah kawan baik kami kerana prinsip dan ritual biasa metodologi pembangunan Agile meliputi masalah. Anda perlu: Bina hutang teknikal tertunggak dan peruntukkan sumber dengan kerap. Wujudkan proses dandanan dan perancangan yang betul untuk menemui potensi penambahbaikan. Isytiharkan proses sekiranya berlaku masalah yang tidak dijangka semasa lelaran. Dengan dandanan, saya maksudkan komunikasi antara ahli pasukan sebelum lelaran bertujuan untuk menentukan skop lelaran, menyatakan keperluan, mengurai tugas, menganggar usaha dan mengutamakan item kerja masa hadapan. Proses perancangan disambungkan dengan skop lelaran yang terhasil. Tidak setiap tugas yang diurus boleh dimasukkan dalam lelaran. Mari selami setiap topik. Membina tunggakan hutang teknikal dan peraturan peruntukan sumber Cara paling mudah untuk setiap pembangun membina tunggakan hutang teknologi ialah menggunakan teg "Untuk dilakukan" dalam kod sumber. Kemudian, anda boleh mencari pangkalan kod, menambah baik sesuatu dan menghantar permintaan tarik untuk kelulusan. Tetapi itu tidak mencukupi. Ia tidak membantu ahli pasukan untuk menyediakan perancangan yang betul dan memastikan skop keluaran. Alternatif yang lebih baik untuk menggunakan "Untuk Dilakukan" adalah untuk mewujudkan proses untuk mencipta tugasan untuk perubahan masa depan. Jika pembangun menemui beberapa tempat masalah yang berpotensi atau mempunyai idea untuk menambah baik pangkalan kod, mereka harus membuat item kerja dalam sistem tiket (Jira, Azure DevOps, atau apa sahaja sistem yang digunakan oleh pasukan). Adalah berlebihan untuk meminta jurutera memberikan penerangan terperinci tentang idea mereka untuk setiap ahli pasukan, tetapi penjelasannya harus cukup jelas untuk ketua pasukan memahami perkara utama dan skop perubahan. Ini merangkumi langkah pertama - cara kami boleh membuat senarai tugas yang berpotensi dan memberikan penerangan peringkat tinggi tentang perubahan masa hadapan. Langkah kedua ialah menjadikannya mudah difahami oleh semua orang. Tugas ini boleh dikendalikan oleh ketua pasukan pembangun, pengurus keluaran atau pengurus produk, bergantung pada kelayakan mereka. Hasilnya hendaklah memberikan butiran berikut: Apa yang sedang kita lakukan? - Penjelasan peringkat tinggi tentang idea. Mengapa kita melakukan ini? - Penerangan tentang cara perubahan ini boleh meningkatkan kelajuan pembangunan, mengurangkan risiko ketidakstabilan yang disebabkan oleh kod spageti atau meningkatkan prestasi perisian. Sejauh manakah perubahan ini penting untuk pembangunan masa hadapan? - Keutamaan perubahan. Contohnya, tanpa perubahan ini, kos penambahbaikan pada masa hadapan atau ciri perniagaan mungkin meningkat dengan pesat. Apakah risiko yang dibuat oleh perubahan ini? - Senarai ciri atau modul yang terjejas untuk membantu QA mengesahkan perubahan. Jika item kerja mempunyai jawapan kepada semua soalan ini, ia membantu mengurangkan masalah yang berpotensi pada masa hadapan. Walau bagaimanapun, mempunyai tunggakan sahaja tidak mencukupi untuk pemfaktoran semula yang boleh diurus. Anda perlu merancang perubahan yang mungkin, dan ia harus menjadi sebahagian daripada proses anda. Pasti, anda akan menghadapi tekanan ciri perniagaan dan permintaan pasaran, di mana godaan untuk meninggalkan tugas teknologi adalah tinggi. Tetapi tanpa penyelenggaraan yang betul, anda akan menghadapi masalah yang lebih besar pada masa hadapan. Cadangan untuk proses tunggakan teknologi ialah: Dalam setiap lelaran, pasukan mesti menyediakan masa untuk penambahbaikan teknologi. Jika terdapat sebarang idea untuk penambahbaikan, ia harus diformalkan sebagai item kerja dengan penerangan yang betul. Item kerja harus mengambil bahagian dalam proses dandanan dan dibincangkan oleh seluruh pasukan sehingga semua faedah dan risiko dikenal pasti dan anggaran daripada semua ahli pasukan dikumpulkan. Item Kerja hendaklah dirancang ke dalam lelaran Agile mengikut anggarannya. Pasukan harus diakui kemungkinan jumlah hutang teknologi dalam lelaran. Masa simpanan boleh ditambah jika perlu, tetapi tidak boleh kurang daripada jumlah biasa. Ini membantu menggalakkan jurutera membuat tugasan baharu dalam tunggakan dan mengutamakan tugas tersebut. Semua orang tahu bahawa cadangan mereka boleh dilaksanakan dan tunggakan itu akan menyusut suatu hari nanti, tidak berkembang menjadi senarai yang sangat melemahkan semangat. Menggunakan proses dandanan dan perancangan untuk pendedahan hutang teknologi yang berpotensi Kadangkala, tugasan hutang teknologi mungkin didedahkan semasa perbincangan dan anggaran, manakala pasukan menghadapi halangan yang tidak dijangka yang menjadikan kesedaran kurang dipercayai dan fleksibel. Sebagai contoh, anda mungkin menyedari bahawa terdapat ciri yang serupa dan mencipta ciri yang serba baharu hanya akan memburukkan lagi asas kod. Tetapi ciri tersebut tidak mengandungi fungsi perniagaan yang diperlukan dalam ciri baharu. Dan adalah lebih baik untuk mencipta perkhidmatan bersatu yang menghubungkan semua ciri serupa untuk memudahkan penyelenggaraan pada masa hadapan. Namun, perubahan ini mungkin menjejaskan dan menjejaskan kestabilan ciri lama dan di situlah letaknya cabarannya. Mungkin ada cara untuk membangunkan ciri baharu dengan murah dan menutup mata terhadap ketidaksempurnaan. Atau mungkin sekarang adalah peluang terbaik untuk mencipta perkhidmatan bersatu sementara terdapat hanya beberapa ciri yang serupa. Perkara yang paling penting ialah mewujudkan proses yang membantu ahli pasukan membuat keputusan berdasarkan fakta yang didedahkan dan anggaran yang disusun dengan betul. Adalah penting untuk mempunyai sistem yang menghalang situasi di mana keputusan sedemikian harus diterima pakai semasa fasa pelaksanaan dalam tunggakan yang komited. Jika peringkat lelaran anda berfungsi dengan baik, pendedahan detik sedemikian akan berlaku secara automatik melalui proses dandanan dan perancangan yang betul. Terdapat beberapa peraturan dan langkah asas yang boleh melindungi pasukan daripada halangan yang tidak dijangka dalam kebanyakan kes: Tunggakan dandanan hendaklah mengandungi tugasan dengan keperluan yang jelas dan boleh dilaksanakan. Tunggakan dandanan harus dikongsi dengan ahli pasukan sebelum perbincangan dan anggaran. Semua ahli pasukan mesti bersedia dan biasa dengan tugas-tugas sebelum dandanan. Jika sebarang item tertunggak memerlukan penyiasatan tambahan atau pelaksanaan semula, kebimbangan itu harus dibincangkan. Keperluan untuk item tunggakan yang bermasalah harus dimuktamadkan berdasarkan keanehan yang didedahkan. Semua kawasan masalah yang berpotensi harus didokumenkan. Setiap item tunggakan hendaklah dianggarkan. Item tunggakan yang bermasalah boleh diuraikan kepada tugasan berasingan dan dirancang mengikut keutamaan. Keputusan tentang strategi pelaksanaan mungkin terpulang kepada pengurus keluaran, mengikut risiko dan tarikh akhir. Tetapi pendekatan ini membantu untuk mendokumenkan semua keputusan. Walaupun tugas hutang teknologi ditangguhkan, ia masih ditambah pada tunggakan. Kemudian, tugasan ini hendaklah disemak dan dijadualkan. Proses ini membetulkan senario di mana beberapa idea yang baik dan perlu dilupakan semasa lelaran yang sibuk. Mewujudkan proses sekiranya berlaku masalah yang tidak dijangka semasa lelaran Namun, walaupun dengan tunggakan hutang teknologi yang diselenggara dengan baik dan proses dandanan dan perancangan yang berfungsi, adalah mungkin untuk menghadapi halangan yang tidak dijangka dan memakan masa yang sedang dibangunkan. Produk perisian mungkin rumit, terutamanya lama atau mengandungi fungsi yang kaya. Menggunakan amalan Agile membantu mengumpul maklumat lebih awal dan membuat keputusan yang betul. Salah satu penyelesaian yang paling mudah ialah mesyuarat harian. Jika jurutera menghadapi beberapa masalah, ia harus dipaparkan semasa mesyuarat dan dibincangkan kemudian. Setiap halangan adalah unik dan mungkin mengambil masa yang berbeza. Tidak kira sama ada perubahan itu akan dilaksanakan dalam lelaran semasa, bukannya ciri 'Senang untuk dimiliki' atau memerlukan semakan lengkap skop lelaran. Isu itu harus dibuat sebagai tugas hutang teknologi biasa dalam sistem penjejakan, diurai dan digambarkan sebagai tugas lain yang serupa dalam artikel sebelumnya. Konsisten adalah kuncinya, dan pasukan perlu tahu cara menangani situasi ini. Kritikan terhadap birokrasi tambahan dan cara menjawabnya Semua kaedah ini mungkin kelihatan seperti cara tambahan untuk meluangkan masa seluruh pasukan dengan birokrasi yang tidak berguna. Dan mungkin begitu jika hanya ketiadaan peraturan yang ketat dan jelas tidak mewujudkan masa yang sukar untuk semua orang. Adalah wajar untuk tidak mengikuti pengesyoran ini dalam projek jangka pendek atau pada peringkat produk bernilai minimum (MVP). Walau bagaimanapun, bekerja dalam pengeluaran dengan tanggungjawab berkualiti dan produk besar memerlukan sistem proses dalaman yang jelas. Mari kita lalui bantahan yang paling biasa. Membuat tugasan sedemikian memakan masa dan kadangkala lebih cepat untuk membuat perubahan dalam kod daripada menerangkannya Dan itu benar. Menghuraikan tugas anda dalam bahasa semula jadi kadangkala boleh menjadi lebih sukar daripada membetulkan kod. Tetapi berikut adalah beberapa penyelesaian: Mencipta sistem templat dalam sistem tiket boleh membantu. Ia membolehkan tugasan ditambah dengan cepat, dan diisi dengan parameter dan pautan yang betul. Sangat bagus untuk mempunyai beberapa dasar tiket di wiki korporat, seperti Confluence / Notion / SharePoint atau mana-mana platform dokumentasi pasukan yang lain. Halaman ini boleh memberikan contoh yang baik tentang tugasan yang dibuat dengan betul. Adalah menjadi kepentingan terbaik ketua pasukan untuk mengekalkan dokumentasi teknikal dan menggilap templat untuk membantu mana-mana ahli pasukan lain menyerahkan tiket yang jelas dan mudah difahami. Pada peringkat asas, sudah cukup untuk mewajibkan jurutera membuat tugasan dengan penerangan peringkat tinggi tanpa artikel yang luas tentang visi strategik atau potensi cadangan mereka. Penerangan harus membantu penyemak (biasanya ketua pasukan) untuk mendapatkan idea utama perubahan. Kemudian, ketua pasukan boleh mengesahkan cadangan dan mengisinya dengan butiran tambahan mengikut proses. Ini juga membantu untuk memahami sama ada perubahan ini perlu dan menyediakan beberapa penapis kualiti. Jika pembangun mempunyai masa untuk melaksanakan cadangan itu, dasar cawangan ciri boleh sangat membantu. Namun, anda perlu membuat tugasan, kerana ia berguna untuk mempunyai peraturan untuk penciptaan cawangan ciri yang dinamakan mengikut tiket. Tetapi akibatnya, kami mendapat jurutera yang berpuas hati, yang telah melaksanakan beberapa hutang teknologi, tiket dan pelaksanaan yang berkaitan yang boleh diatur dan dirancang untuk pengesahan dalam lelaran yang sesuai, tanpa risiko ketidakstabilan yang tidak dijangka. Semua perubahan ini sangat teknikal, dan penerangan tidak membantu kerana tiada siapa yang akan mendapat idea itu Mungkin. Tetapi ia bergantung kepada penjelasan. Keutamaan ialah perihalan tentang perkara yang boleh berlaku dan fungsi yang mungkin tidak stabil. Walau bagaimanapun, adalah berguna untuk menulis tentang kesan perubahan kerana ia membantu mengenal pasti kemungkinan dan senario tambahan. Selain itu, idea teknikal yang paling mendalam pun boleh diterangkan dalam ayat mudah menggunakan bahasa semula jadi. Jika mereka tidak boleh, mungkin ada sesuatu yang tidak kena dengan idea itu sendiri, dan itu boleh menjadi risiko yang berpotensi, keseluruhan cadangan itu harus dipertimbangkan semula. Hanya tulis sesuatu seperti: "Kaedah "XXX" menggunakan terlalu banyak RAM pada setiap panggilan. Mencipta cache tambahan untuk kaedah ini membantu mengurangkan penggunaan RAM dan mempercepatkan semua API. Kaedah ini menggunakan data yang jarang berubah, cukup untuk menggugurkan cache semasa dimulakan semula. Perubahan adalah selamat, tetapi mungkin menjejaskan ciri berikut: XXX, XXX, XXX…”. Dalam sesetengah kes, ini sudah cukup. Dalam yang lain, cadangan ini mungkin mencetuskan perbincangan, kerana jurutera mungkin terlupa tentang beberapa fungsi lama tetapi masih digunakan di mana cache ini boleh menyebabkan masalah. Semasa proses dandanan, idea itu akan disemak, dan pasukan akan menemui kompromi. Semua dasar ini hanya menghalang pengguna daripada menerima peningkatan baharu Kestabilan dan kebolehpercayaan adalah lebih baik daripada beberapa peratusan peningkatan dalam beberapa masa pelaksanaan ciri. Tiada siapa yang akan kecewa kerana kehilangan potensi peningkatan prestasi, tetapi mudah untuk mencemarkan reputasi produk. Adakah kita memerlukan semua birokrasi ini untuk gaya kod mudah yang tidak akan membahayakan dalam 99.99% kes? Ideanya adalah untuk menyelaraskan proses dan membantu menilai risiko. Jurutera sepatutnya mempunyai peluang untuk mengekalkan pangkalan kod dan menyediakan beberapa penambahbaikan. Untuk perkara yang kecil dan tidak menjejaskan kestabilan keseluruhan produk, anda boleh membuat item kerja agregat yang boleh disiapkan semasa lelaran. Tugasan ini masih perlu disemak sebagai permintaan tarik tetapi tidak perlu mengumumkannya secara rasmi kepada pasukan. Kesimpulan Penambahbaikan produk yang berterusan adalah penting untuk perniagaan dan membantu mengekalkan kualiti keseluruhan. Jika anda menyimpan hutang teknikal dan idea baharu di rak, anda akan terjebak dengan produk yang sudah lapuk dan tidak lama lagi bergelut untuk mencari jurutera pakar untuk mengekalkannya. Sebaliknya, tugasan ini bersaing dengan ciri perniagaan dan idea lain yang boleh memacu perniagaan ke ufuk baharu. Pengesyoran tentang tunggakan tugas teknikal ini boleh membantu mendedahkan dan menilai kepentingan tugas ini bukan sahaja untuk ahli pasukan tetapi juga untuk pihak berkepentingan. Mereka membantu membentangkan idea ini dalam bahasa semula jadi dan mengekalkan serta melindungi masa untuk pelaksanaan. Ia membebankan jurutera dengan tindakan tambahan, tetapi akhirnya, ia membantu seluruh pasukan untuk menyampaikan produk berkualiti tinggi dan boleh dipercayai. Dan tanggungjawab pengurus adalah memilih instrumen atau dasar yang betul untuk mengekalkan proses ini.
