Proses Kualitas Paling Efektif yang Tidak Digunakan Siapa pun

Pada tahun 1976, Michael Fagan menerbitkan sebuah makalah di IBM Systems Journal yang menggambarkan proses review begitu efektif sehingga menjadi standar emas untuk kualitas software. Fagan Inspections menangkap 60 hingga 90 persen dari semua defek sebelum satu pun tes dijalankan. Sebuah studi NASA tahun 2002 menemukan bahwa setiap jam yang dihabiskan untuk inspeksi mencegah rata-rata 33 jam pekerjaan pemeliharaan di kemudian hari.

Menurut standar terukur apa pun, ini adalah proses review terbaik yang pernah dihasilkan oleh rekayasa perangkat lunak.

Hampir tidak ada yang menggunakannya saat ini.

Pertanyaannya bukan apakah Fagan Inspections bekerja. Fagan Inspections bekerja hampir terlalu baik. Pertanyaannya adalah mengapa proses dengan rekam jejak seperti itu menghilang dari pengembangan arus utama, dan apakah kita kehilangan sesuatu yang penting saat kita menggantinya.

Seperti Apa Fagan Inspections Sebenarnya

Fagan tidak menemukan code review. Ia menemukan ritual yang sangat terstruktur dan spesifik untuk menemukan defek.

Prosesnya memiliki enam fase kaku:

  1. Planning: Seorang moderator memilih peserta dan memverifikasi bahwa materi memenuhi kriteria masuk.
  2. Overview: Penulis menjelaskan latar belakang. Ini adalah penyetelan konteks, bukan review.
  3. Preparation: Setiap peserta meninjau materi secara mandiri, dengan kecepatan sekitar 150 baris per jam, dengan daftar pribadi defek yang dicurigai.
  4. Inspection Meeting: Tim berkumpul selama tidak lebih dari dua jam. Seorang reader menyuarakan logika dengan keras. Seorang recorder mencatat defek. Moderator menjaga rapat tetap fokus pada menemukan defek, bukan memecahkannya.
  5. Rework: Penulis memperbaiki setiap defek yang tercatat.
  6. Follow-up: Moderator memverifikasi bahwa perbaikan telah dilakukan dan tidak ada defek baru yang diperkenalkan.

Peran-perannya spesifik dan tidak tumpang tindih. Moderator menjalankan proses tetapi bukan otoritas teknis. Reader menyuarakan kode tetapi tidak membelanya. Penulis hadir tetapi dilarang menjelaskan maksud selama rapat. Tujuannya bukan kolaborasi. Itu adalah deteksi defek yang dingin dan sistematis.

Inilah bagian yang membuatnya berhasil. Dinamika sosial rapat rekayasa normal dihilangkan melalui desain.

Mengapa Angkanya Begitu Bagus

Tingkat deteksi defek bukanlah kebetulan. Itu berasal dari beberapa pilihan desain yang disengaja.

Preparation mandiri berarti enam orang memeriksa kode yang sama secara terisolasi sebelum diskusi kelompok mana pun bisa memengaruhi mereka. Tumpang tindih antara daftar mereka memberi tahu Anda seberapa jelas sebuah defek. Item yang hanya ditemukan oleh satu orang sering kali yang paling berharga.

Batas keras dua jam mencegah kelelahan menghancurkan penilaian. Fagan tahu bahwa efektivitas inspeksi jatuh secara drastis setelah sekitar dua jam. Kecepatan 150 baris per jam juga disengaja. Lebih cepat dari itu dan Anda mulai melihat apa yang Anda harapkan untuk dilihat alih-alih apa yang sebenarnya ada.

Aturan tanpa solusi menjaga rapat tetap fokus. Tidak ada yang menghancurkan inspeksi lebih cepat daripada ruangan penuh engineer yang merancang perbaikan untuk defek yang belum mereka karakterisasi sepenuhnya.

Kendala-kendala ini bukan beban birokrasi. Mereka adalah mekanismenya. Hapus mereka dan Anda mendapatkan sesuatu yang lebih ramah tetapi kurang efektif.

Apa yang Membunuh Fagan Inspections

Jika prosesnya begitu efektif, mengapa ia menghilang?

Jawaban singkatnya adalah bahwa proses ini mahal dengan cara yang tepat ditolak oleh pengembangan software modern.

Satu Fagan Inspection menghabiskan 15 hingga 20 persen dari upaya yang dihabiskan untuk menulis kode yang ditinjau. Dalam satu kasus yang didokumentasikan, 348 baris memerlukan 27,3 jam-orang inspeksi. Rasio itu tidak terbayangkan ketika tim mengirimkan beberapa kali sehari.

Penjadwalan saja sudah menjadi pekerjaan penuh waktu. Anda membutuhkan lima atau enam orang di dalam ruangan selama dua jam, ditambah preparation, ditambah follow-up. Dalam organisasi besar, menemukan slot dua jam di mana moderator, reader, dua reviewer, recorder, dan penulis semua tersedia bisa memakan waktu berhari-hari.

Struktur peran yang kaku juga tidak scalable. Fagan Inspections mengasumsikan tim yang stabil dengan cukup orang untuk mengisi semua peran. Dalam sebuah startup, tim lima orang mungkin tidak memiliki siapa pun yang dapat berfungsi sebagai moderator khusus tanpa menghancurkan velocity.

Faktor terbesar adalah budaya. Fagan Inspections sengaja tidak nyaman. Penulis duduk diam sementara kolega menyuarakan kode mereka dan mencatat defeknya. Tidak ada ruang untuk “ini hanya draft pertama”. Proses mengasumsikan bahwa defek mahal dan gesekan sosial murah. Rekayasa modern berjalan pada asumsi yang berlawanan.

Apa yang Menggantikannya

Industri tidak meninggalkan review terstruktur. Ia menggantinya dengan pull requests.

Review pull request bersifat asinkron, berupacara rendah, dan tertanam langsung dalam workflow pengembangan. Seorang reviewer dapat melihat diff di antara rapat, di ponsel mereka, atau sambil menunggu CI selesai. Tidak ada peran yang ditetapkan. Penulis dan reviewer sering kali adalah orang yang sama yang hanya membutuhkan satu persetujuan lagi untuk merge.

Ini adalah peningkatan besar dalam aksesibilitas, kecepatan, dan developer experience. Ini juga merupakan regresi besar dalam deteksi defek.

Beberapa studi menemukan bahwa review informal menangkap kira-kira setengah dari defek yang ditangkap oleh inspeksi terstruktur. Sebuah eksperimen tahun 2009 oleh Basili dan lainnya membandingkan inspeksi bergaya Fagan dengan review lightweight dan menemukan bahwa proses yang lebih ringan menangkap secara signifikan lebih sedikit defek dalam materi yang sama.

Masalahnya bukan bahwa reviewer malas. Prosesnya tidak dirancang untuk menemukan defek. Proses ini dirancang untuk memungkinkan orang mengirimkan kode dengan sepasang mata tambahan yang melihatnya, yang tidak sama.

Apa yang Sebenarnya Kita Hilangkan

Review pull request mengoptimalkan throughput. Inspeksi Fagan mengoptimalkan ketelitian. Ini adalah tujuan yang benar-benar berbeda, dan tidak satu pun yang salah. Kesalahannya adalah menganggap bahwa proses yang lebih ringan adalah superset ketat dari proses yang lebih berat.

Inilah yang menghilang:

Preparation mandiri. Dalam pull request, reviewer melihat diff tanpa persiapan. Mereka belum menghabiskan satu jam membaca konteks sekitarnya, melacak stream data, dan membangun model mental. Mereka bereaksi terhadap notifikasi. Kedalaman pemeriksaan tidak sebanding.

Peran reader. Meminta seseorang menyuarakan kode dengan keras memaksa grup untuk melanjutkan dengan kecepatan yang dapat diikuti orang paling lambat. Itu memunculkan asumsi yang disembunyikan oleh pembacaan diam. Diff di layar membuat mata Anda melewati bagian yang membosankan. Seorang reader tidak melewatkannya.

Fokus hanya pada defek. Komentar pull request menyimpang ke opini gaya dan arsitektur. Ini berharga, tetapi ini bukan deteksi defek. Setiap menit yang dihabiskan untuk memperdebatkan indentasi adalah menit yang tidak dihabiskan untuk menemukan null dereference.

Data proses yang terukur. Fagan Inspections menghasilkan angka keras: defek per jam, waktu preparation, waktu rework, defect density per module. Alat review modern menghitung komentar dan persetujuan, yang hampir tidak memberi tahu Anda apa pun tentang kualitas review.

Jalan Tengah yang Praktis

Anda tidak akan menjalankan Fagan Inspections lengkap dalam lingkungan continuous deployment modern. Tetapi Anda dapat meminjam bagian-bagian yang penting.

Ide yang paling penting untuk dipindahkan adalah preparation mandiri yang terstruktur. Sebelum review async yang mendalam, wajibkan reviewer untuk menghabiskan waktu dengan materi sendirian. Bukan sekadar membaca cepat. Preparation yang sebenarnya.

Alih-alih “LGTM” generik, terapkan checklist lightweight yang meniru disiplin yang Fagan bangun ke dalam peran dan aturan:

from dataclasses import dataclass, field
from typing import List, Optional
from enum import Enum

class DefectSeverity(Enum):
    MINOR = "minor"
    MAJOR = "major"
    CRITICAL = "critical"

@dataclass
class ReviewEntry:
    line_number: Optional[int]
    category: str
    severity: DefectSeverity
    description: str

@dataclass
class InspectionReport:
    reviewer: str
    prep_time_minutes: int
    entries: List[ReviewEntry] = field(default_factory=list)

    def defect_count(self) -> int:
        return len(self.entries)

def run_inspection_checklist(
    code: str,
    reviewer: str,
    prep_time_minutes: int
) -> InspectionReport:
    """Structured prep produces structured output.

    Mimics the Fagan prep phase: reviewer spends focused
    time with the material, then logs findings against a
    consistent taxonomy instead of ad hoc comments.
    """
    report = InspectionReport(
        reviewer=reviewer,
        prep_time_minutes=prep_time_minutes
    )

    # Example: check for missing null handling
    if "->" in code and "null" not in code.lower():
        report.entries.append(ReviewEntry(
            line_number=None,
            category="null-safety",
            severity=DefectSeverity.MAJOR,
            description="No explicit null handling in pointer function"
        ))

    return report

Ini bukan Fagan Inspection. Ini adalah cara untuk memulihkan salah satu properti terpentingnya: output review harus terstruktur, terukur, dan fokus pada kategori defek daripada opini.

Ide lain yang dapat dipindahkan adalah deep review yang dibatasi waktu. Pilih satu module kritis per sprint. Jadwalkan review terfokus selama 90 menit dengan preparation mandiri. Catat hanya defek. Tidak ada solusi, tidak ada perdebatan gaya, tidak ada argumen desain.

Biayanya nyata. Tetapi jika rasio NASA berlaku bahkan secara kasar, satu jam fokus sekarang menghemat lusinan jam debugging nanti.

Kebenaran yang Tidak Nyaman

Fagan Inspections tidak gagal. Fagan Inspections ditolak karena ketegasan yang mereka perlukan tidak sesuai dengan kecepatan yang diprioritaskan oleh industri.

Kompromi itu masuk akal untuk banyak software. Kesalahan ketik pada tombol landing page tidak memerlukan inspeksi formal lima orang. Tetapi budaya yang menggantikan Fagan Inspections memperlakukan semua kode dengan cara yang sama, dan di situlah biayanya tersembunyi.

Defek termahal ada dalam kode yang terlihat benar, lulus tes, dan gagal di produksi dengan cara yang memakan biaya nyata. Itu adalah kode yang paling diuntungkan dari proses yang dirancang untuk menemukan defek alih-alih proses yang dirancang untuk menyetujui diff.

Review pull request ada di sini untuk tinggal, dan itu baik-baik saja. Tetapi berpura-pura bahwa ini adalah pengganti inspeksi terstruktur tidak baik-baik saja. Ini adalah alat yang berbeda untuk pekerjaan yang berbeda, dan tim yang hanya memiliki salah satu dari keduanya akan terus menemukan bug mahal yang proses yang lebih baik akan tertangkap sebelum pengiriman.

FAQ

Apa itu Fagan Inspection?

Proses review terstruktur multi-fase untuk menemukan defek dalam artefak software, dikembangkan oleh Michael Fagan di IBM pada tahun 1970-an. Fagan Inspections melibatkan enam fase (Planning, Overview, Preparation, Inspection Meeting, Rework, Follow-up) dengan peran spesifik untuk peserta. Rapat berfokus secara eksklusif pada pencatatan defek, bukan memecahkannya.

Seberapa efektifkah Fagan Inspections?

IBM melaporkan tingkat penghapusan defek lebih dari 90 persen. Studi NASA tahun 2002 menemukan bahwa setiap jam inspeksi mencegah rata-rata 33 jam pemeliharaan. Studi independen secara konsisten menemukan bahwa inspeksi terstruktur menangkap kira-kira dua kali lebih banyak defek dibandingkan review informal.

Mengapa tim berhenti menggunakan Fagan Inspections?

Proses ini menghabiskan 15 hingga 20 persen dari upaya total proyek, memerlukan penjadwalan yang sulit bagi banyak peserta, dan kaku secara budaya. Saat tim software beralih ke siklus release yang lebih cepat, overhead menjadi tidak berkelanjutan. Review pull request menggantikannya sebagai default karena lebih cepat dan lebih mudah diintegrasikan ke dalam workflow normal, meskipun menangkap lebih sedikit defek.

Bisakah tim modern masih mendapat manfaat dari Fagan Inspections?

Tidak dalam bentuk aslinya. Proses lengkap enam fase dengan peran yang ditetapkan tidak cocok untuk continuous deployment. Tetapi ide-ide inti — preparation mandiri, review terfokus yang dibatasi waktu, pencatatan defek terstruktur, dan memisahkan penemuan defek dari desain solusi — dapat diadaptasi. Tim yang menerapkan ini secara selektif pada kode kritis mendapatkan banyak manfaat tanpa overhead.