Bahan ini telah disiapkan oleh mitra kami, Equio .
Membeli produk TI untuk menyelesaikan berbagai masalah perusahaan, pelanggan bisnis sering memikirkan biaya, fungsi, kenyamanan, kemampuan integrasi, dll. Ini bukan masalah yang begitu jelas, seperti kualitas dan tingkat dukungan teknis, mereka sudah berpikir di tempat kedua.
Tetapi kualitas produk akhir sebagian besar tergantung pada bagaimana pengembang mengorganisir proses pengujian, mengidentifikasi dan memperbaiki bug, di antara pengembang yang dikenal sebagai "bug" (dari bug bahasa Inggris - bug, serangga, virus, slang kata yang biasanya berarti kesalahan) dalam program). Pertanyaan ini ditanyakan oleh sangat sedikit pelanggan bisnis perorangan.
Kami ingin memberi tahu Anda tentang cara pengembang mengidentifikasi dan memperbaiki bug, cocok untuk pengujian. Salah satu pendekatan didasarkan pada Kebijakan Nol Bug.
Spoiler! Kami akan memberi tahu Anda tentang apa yang sebenarnya menghabiskan waktu para pengembang dan mengapa mereka tidak memperbaiki semua bug. 
Tujuh pengasuh
Ada lelucon terkenal yang didedikasikan untuk pengumuman rilis baru "Kinerja aplikasi yang dioptimalkan, perbaikan bug, yang baru ditambahkan." Sebenarnya, memperbaiki bug dan menambahkan yang baru adalah proses yang abadi, bug lama diperbaiki, tetapi yang tidak kalah baru muncul.
Ini terutama terlihat ketika sejumlah besar pengembang atau bahkan beberapa tim proyek bekerja pada produk perangkat lunak, pada basis kode tunggal. Sangat sulit untuk menyinkronkan upaya mereka dan mendapatkan output sepenuhnya kode bebas kesalahan. Sebagai contoh, satu tim menyimpan perubahan di cabang master, yaitu, dalam versi utama dari kode di repositori (repositori). Pada gilirannya, tim lain dihadapkan dengan sejumlah besar konflik dan berusaha untuk memperbaikinya. Hasilnya, semua ini akan dirilis, yaitu ke versi final produk, cocok untuk pengguna biasa, dan di sini sejumlah besar bug muncul. Dan ini penuh dengan kehilangan uang, pelanggan dan, yang paling penting, ancaman terhadap reputasi pengembang.
Jadi apa yang harus dilakukan dalam situasi ini? Anda dapat membuang semua kekuatan dan sumber daya Anda untuk memperbaiki kesalahan, tetapi bagaimana kemudian Anda dapat terlibat dalam pengembangan produk, meningkatkan yang sudah ada dan menambahkan fungsi baru?
Tidak terlihat, backlog keluar
Satu perusahaan IT besar hanya punya masalah serupa. Berkat rekomendasi dari salah satu spesialis yang bekerja di perusahaan, diputuskan untuk menerapkan pendekatan
Kebijakan Nol Bug . Sayangnya, belum banyak yang ditulis tentang dia dalam bahasa Rusia.
Esensinya adalah sebagai berikut. Ketika penguji atau pengguna menemukan bug dalam produk dan memberi tahu pengembang tentang hal itu, yang terakhir memutuskan apakah bug ini akan diperbaiki atau tidak mempengaruhi kinerja produk, dan oleh karena itu koreksi dapat ditunda atau sepenuhnya dikecualikan. dari backlog (daftar tugas). Bug ini diberi status Won't Fix, setelah itu selamanya menghilang dari bidang visi pengembang. Dalam beberapa kasus, bug dengan status ini ditempatkan di bagian paling akhir dari simpanan. Ini berarti bahwa pengembang akan "mendapatkan tangan mereka" untuk memperbaikinya hanya ketika semua tugas lainnya diselesaikan.
Tetapi kembali ke perusahaan IT yang sudah disebutkan. Karyawannya menganalisis seluruh daftar bug yang terdeteksi dan mengurutkan masalah yang ditemukan. Hampir setengah dari kesalahan diputuskan untuk diperbaiki dalam waktu dekat, dan lebih dari setengahnya diberikan status Won't Fix. Semua pekerjaan ini memakan waktu sekitar dua bulan, setelah itu perusahaan memutuskan untuk mengadopsi
Kebijakan Nol Bug secara berkelanjutan. Hingga saat ini, perusahaan ini tidak memiliki lebih dari 10 tugas terbuka di backlog. Ini memungkinkan Anda untuk fokus pada implementasi fitur-fitur baru.
Ahli bug
Bagaimana bug diurutkan? Siapa yang membuat keputusan bahwa satu kesalahan sangat penting dan perlu diperbaiki, dan di sisi lain, Anda dapat terus hidup dalam damai, atau menunda koreksi sampai nanti?
Kami akan memberi tahu Anda bagaimana proses ini diatur menggunakan konsep manajemen proyek yang fleksibel (Agile). Semua orang tahu bahwa Agile mencakup beberapa teknik. Kami akan mengambil salah satu dari mereka sebagai contoh, yaitu SCRUM, karena ini paling sering digunakan dalam dunia pengembangan perangkat lunak.
Pemilik produk atau Pemilik Produk Scrum adalah salah satu anggota kunci tim proyek. Dialah yang mewakili kepentingan pengguna akhir dan melakukan segala upaya untuk memaksimalkan nilai produk. Dia juga bertanggung jawab dari awal hingga akhir untuk jaminan simpanan produk. Seluruh tim pengembangan mengambil bagian dalam menyortir bug, tetapi kata terakhir selalu untuk Pemilik Produk. Ini menentukan kesalahan mana yang akan diperbaiki dan yang ditandai sebagai Won't Fix.
Padahal, semuanya adalah uang. Misalnya, jika memperbaiki bug tidak akan menghasilkan keuntungan finansial bagi perusahaan, tetapi pada saat yang sama membutuhkan banyak waktu dan sumber daya, akan lebih baik jika bug tersebut ditetapkan status Won't Fix dan menunda memperbaikinya sampai waktu yang lebih baik. Bahkan, "pemilik produk" bertanggung jawab untuk memprioritaskan dan untuk status kesalahan yang ditemukan.
Dengan kata lain, setiap orang memiliki "kerangka di dalam lemari". Tetapi jika mereka tidak memiliki efek pada kinerja produk, jangan menghalangi tindakan pengguna, atau menghambat proses integrasi, mereka dapat diabaikan sepenuhnya.
Kriteria pemilihan
Bug "minor" semacam itu ada dalam produk pengembang mana pun.
Misalnya, di antarmuka admin sistem manajemen konten, tidak mungkin memasukkan judul yang terlalu panjang untuk bagian, artikel, dll. Pengembang memutuskan untuk tidak memperbaiki bug ini. Lagi pula, koreksi membutuhkan waktu, sumber daya, dan Anda dapat mengambil dan mengurangi nama menjadi sejumlah karakter tertentu. Cukup dengan memperingatkan pengguna bahwa nama yang panjangnya lebih dari 30 karakter tidak didukung.
Tombolnya sedikit dalam warna yang salah, elemen antarmuka terletak dua piksel di sebelah kiri apa yang diperlukan - semua ini adalah kesalahan yang tidak memengaruhi kegunaan atau kinerja aplikasi. Karena itu, mereka berpotensi dikaitkan dengan Won't Fix.
Bug kritis terutama yang ditangani oleh banyak klien yang memimpin atau dapat mengarah pada fakta bahwa klien kehilangan uang karena cacat pada programmer. Semua ini mendefinisikan Pemilik Produk, yang berkewajiban untuk mengetahui produk seperti punggung tangannya, dan tidak hanya untuk memahami fungsinya, tetapi juga untuk memahami bagaimana pelanggan bisnis menggunakannya, skenario aplikasi apa yang ada di perusahaan tertentu.
Pikiran bersama
Kebijakan Nol Bug sering dikaitkan dengan Perjanjian Tingkat Layanan (SLA). Biasanya, pengembang memiliki beberapa lini dukungan teknis.
Yang pertama menerima pesan kesalahan dari pengguna dan mengumpulkan semua data yang diperlukan untuk reproduksi dan analisisnya, dan kemudian mentransfer semua informasi ini ke baris kedua. Spesialis dari baris kedua mereproduksi kesalahan ini pada workstation atau server tempat versi produk yang sama diinstal sebagai pengguna. Jika kesalahan direproduksi, seperti yang diklaim pengguna, maka informasi tentangnya jatuh ke dalam sprint aktif, yaitu, daftar tugas untuk pengembang.
Jalur dukungan teknis pertama dan kedua, serta pengembang, memiliki SLA. Semakin kritis bug, semakin ketat standar SLA untuk memperbaikinya. Ada juga SLA umum untuk pemecahan masalah: dari kontak pelanggan untuk mendapatkan kode yang diperbaiki dalam produksi. Keputusan tentang apakah akan menetapkan status bug ke Won't Fix atau tidak ditugaskan dibuat oleh baris kedua dukungan teknis. Namun, keputusannya belum final. Pertama-tama, karyawannya dipandu oleh prinsip dan aturan sprint saat ini. Selain itu, ada kumpulan harapan dari pengembang, dari pelanggan, dari departemen pengembangan bisnis.
Jika situasi kontroversial muncul ketika semua faktor ini diperhitungkan, maka kata terakhir akan tepat di belakang garis kedua dukungan dan, tentu saja, Pemilik Produk.
Puas berarti produktif
Mengapa semua ini dibutuhkan perusahaan pengembangan? Salah satu alasannya adalah meningkatnya motivasi pengembang. Memperbaiki bug adalah pekerjaan rutin dan tidak menyenangkan, yang tidak semua orang suka melakukannya. Menerapkan fitur baru jauh lebih menarik daripada memperbaiki kesalahan rekan Anda. Ini meningkatkan produktivitas dan produktivitas. Akhirnya, dengan cara ini, tanpa mengorbankan kualitas, seseorang dapat dengan serius menghemat perawatan penguji, meninggalkan satu atau dua spesialis di perusahaan alih-alih seluruh departemen.
Mengapa pengguna dan pelanggan bisnis membutuhkan ini? Bisnis ini berkembang, terus menghadapi tantangan baru yang perlu ditangani dengan bantuan produk-produk TI. Dan jika pengembang menghabiskan sebagian besar waktu mereka menghilangkan kesalahan yang tidak penting, daripada meningkatkan fungsionalitas kreasi mereka, mereka berisiko berada jauh di belakang pesaing mereka. Bisnis akan memilih mereka yang bergerak maju, sambil menjaga bar kualitas di level tinggi.
Itu saja. Informasi lebih lanjut tentang
perusahaan "Equio" dapat ditemukan di situs web resmi mereka.
Dan di
situs web Otus Anda dapat membiasakan diri dengan kursus kami dan menghadiri
webinar gratis yang menarik minat Anda.