Kio estas la naŭdek-naŭdek regulo?
Inĝeniera kulturo kaj programara praktiko
La naŭdek-naŭdek regulo estas fama programista ŝerco pri horplanado. Ĝi diras, ke la videbla unua parto de projekto konsumas grandan parton de la tempo, kaj la supoze fina malgranda parto iel konsumas preskaŭ tiom denove. Inĝenieroj uzas ĝin por priskribi la obstineman voston de integrado, testado, randkazoj, dokumentado, eldonlaboro kaj poluro, kiu ofte aperas post kiam ĉiuj jam komencis diri, ke la funkcio estas esence preta.
Recenzita de Jackie, Head of Learning & Development, Levellers - Laste recenzita la 8-an de junio 2026
Kion tio signifas
La regulo estas amuza, ĉar la aritmetiko estas neebla. Tio estas kio igas ĝin memorinda. Ĝi kaptas la senton, ke teamo povas atingi la plimulton de funkcianta funkcio, kaj poste pasigi longan tempon sur la lasta malfacila peco.
En programaro, la "lasta malfacila peco" malofte estas unu afero. Ĝi estas la amasiĝo de detaloj, kiuj ĉiam estis realaj sed facile ignorebla komence, ekzemple datummigracio, sekurecaj kontroloj, monitorado, pakado, permesoj, retroprovoj, mesaĝoj kaj subteno por ĉiuj strangaj kazoj, kiujn realaj uzantoj tuj trovas.
Kial tio gravas
Ĉi tiu peco de inĝeniera kulturo gravas, ĉar ĝi klarigas perene fonton de frustriĝo inter teamoj kaj la homoj ĉirkaŭ ili. De ekstere, funkcio povas aspekti preskaŭ preta, kiam demonstraĵo funkcias. De interne, tiu demonstraĵo eble ankoraŭ mankas la fortikigon, kiu transformas promesplenan konstruaĵon en ion, kion oni povas sekure eldoni kaj subteni.
La regulo ankaŭ instruas utilan horplanan lecionon. Programara laboro ne estas egale distribuita tra la vivo de tasko. La fino portas multan kaŝitan pezon. Se gvidantoj ne konsideras tion, ili kreas ciklon de gajaj progresraportoj sekvitaj de doloriga malkontento. Kompreni la regulon helpas teamojn paroli pli honeste pri tio, kion "preta" efektive inkluzivas.
Kiel ĝi funkcias
De kie venas la regulo
La regulo estas kutime atribuita al Tom Cargill de Bell Labs. La plej konata frua presita apero estas en la 1985-a kolumno de Jon Bentley "Bumper-Sticker Computer Science" en Communications of the ACM, kie ĝi aperas sub la etikedo "Rule of Credibility". Tio gravas, ĉar ĝi metas la frazon en la mondon de kompaktaj inĝenieriaj maksimoj, ne en formalan projektan administran teorion.
Ĝi ankaŭ sugestas la spiriton, en kiu homoj uzis ĝin ekde tiam. La frazo ne estas kalkulo. Ĝi estas sperta inĝeniero ruliĝanta per la okuloj pri la maniero, kiel programara laboro etendiĝas en la fina etapo.
Kial la lasta etapo kreskas
Frua progreso en programaro estas ofte tre videbla. Vi povas skizi la interfacon, kabligi la feliĉan vojon, montri funkciantan fluon kaj igi la sistemon aspekti preskaŭ kompleta. La problemo estas, ke programaro fariĝas vere reala nur kiam ĝi renkontas la tutan ĉirkaŭan medion.
Tiu medio inkluzivas realajn datumojn, realajn uzantojn, realan tempigon kaj realajn fiaskojn. Funkcio, kiu funkcias por unu enigo, eble malsukcesas por dudek aliaj. Servo, kiu funkcias glate sur tekkomputilo, eble luktas en produktado. Laborfluo, kiu aspektas bone en demonstraĵo, eble estas neuzebla sen taŭgaj permesoj, reviziovojetoj, sciigoj, retroŝarĝo kaj subtena gvidado. Nenio magia okazis. La teamo simple atingis la parton de la laboro, kie la sistemo devas ĉesi esti plaŭzebla kaj komenci esti fidinda.
Tial la vosto de la horplano sentas sin neproporcia. Fermi la interspacon inter "funkcias principe" kaj "funkcias praktike" devigas la teamon malkovri ĉiujn mankantajn supozojn.
Kiel inĝenieroj uzas la regulon praktike
Kiam inĝenieroj citas la naŭdek-naŭdek regulon, ili kutime avertas kontraŭ unu el tri kutimoj. La unua estas konfuzi demonstraĵon kun eldono. La dua estas trakti testan, operacian kaj dokumentadan laboron kiel laŭvolajn aldonaĵojn. La tria estas raporti procentan kompletiĝon kvazaŭ programara progreso estus glata kaj lineara.
En sanaj teamoj, la frazo estas uzata kun iom da memironio. Ĝi memorigas homojn ne esti trompitaj de sia propra frua impulso. Ĝi ankaŭ instigas pli bonan ampleksodifinon. Se teamo volas vere mallongan horplanon, ĝi ofte devas redukti la laboron pli signife, ne nur ŝajnigi, ke la lasta etapo estos rapida.
Kion la frazo ne signifas
La regulo ne signifas, ke programaraj taksoj estas senespera. Ĝi signifas, ke taksoj pliboniĝas, kiam teamoj difinas kompletiĝon ĝuste. Se "preta" inkluzivas integradon, testojn, deplojon, permesojn, observeblon kaj subtena transdono, la kaptilo fariĝas pli facile videbla.
Ĝi ankaŭ ne signifas, ke ĉiu projekta vosto eksplodos. Iom da laboro estas orda kaj limigita. La regulo estas memorinda, ĉar la kontraŭa kazo estas ofta, precipe en produkta laboro, platformaj ŝanĝoj, integradoj kaj ĉio uzant-alfrontanta.
Ekzemploj
Teamo konstruas novan kaspagon kaj fiere montras, ke pago sukcesas. Poste alvenas la vera fina etapo. Repagmanipulado, malsukcesintaj kartaj retroprovoj, impostaj randkazoj, kvitanca tempigo, fraŭdaj kontroloj, analizoj, klientaj subtenaj skriptoj kaj alireblecaj riparoj ĉiuj bezonas atenton. La sistemo ne estis trompe nekompleta. Ĝi estis nekomplete difinita.
Interna platformteamo diras, ke migrado estas preskaŭ preta, ĉar la nova servo estas viva. Kio restas sonas malgranda: malaktivigi la malnovan vojon. Praktike, tio signifas retroplenigojn, panelojn, deĵoraj ludlibrojn, alirŝanĝojn, sekreta rotacion, datumkonsistencajn kontrolojn kaj planon por retroŝarĝo. La videbla movo estis nur parto de la laboro.
Raportada funkcio aspektas kompleta en prepara medio. Kiam ĝi atingas produktadon, uzantoj volas eksportformatojn, horzono-konsistencon, permesajn filtrilojn, kolumnajn nomojn kongruantajn kun komerca lingvo kaj nombrojn ligantajn al financo. La "lasta dek procentoj" montriĝas esti la parto, kiu decidas, ĉu iu ajn fidas ĝin.
Oftaj miskomprenoj
Ofta eraro estas trakti la regulon kiel permeson draste plenigi ĉiun takson. Tio maltrafas la punkton. La celo ne estas ŝveligo, sed honesteco pri tio, kion kompletiĝo inkluzivas.
Alia miskomprenado estas, ke la regulo validas nur por malfortaj teamoj. Fortaj teamoj ankaŭ povas renkonti ĝin, precipe kiam la limo inter funkcia laboro kaj eldona laboro estas malklara.
Homoj ankaŭ uzas ĝin kvazaŭ ĝi temas ĉefe pri kodado. En realeco, la dolora vosto ofte loĝas en testado, integrado, operacioj, subteno kaj produktaj detaloj.
Fine, iuj aŭdas la ŝercon kaj konkludas, ke procenta kompletiĝo estas senutila. Ĝi povas esti utila, sed nur se la teamo dividas realan difinon de ĉiu mejloŝtono anstataŭ distribui optimismajn rondajn nombrojn.
Riskoj kaj limoj
La malbona versio de ĉi tiu regulo fariĝas cinismo. Teamoj ekŝultras, supozas, ke ĉiu projekto spiraligos, kaj ĉesas lerni el siaj eraroj. Tio ne estas saĝo. Ĝi estas kapitulaco.
La bona versio estas diagnoza. Se la fino de la laboro ĉiam etendiĝas, demandu, kio daŭre estas preterlasata el la plano. Ĉu estas integrado. Eldona preteco. Datumkvalito. Aprobo. Monitorado. La regulo estas plej valora, kiam ĝi malkaŝas blindan punkton, kiun la teamo povas ripari.
Ĝi ankaŭ havas naturan limon. Se laboro estas strikte limigita kaj la teamo faris la samon multfoje antaŭe, la vosto povas esti mallonga. Folkloro devus akrigi juĝon, ne anstataŭigi ĝin.
Kion fari poste
Se ĉi tiu ŝablono sonas konata, komencu per plifortigo de via difino de preteco. Klarigu eksplicite, ke progreso ne estas nur skribita kodo. Ĝi inkluzivas testojn, instrumentadon, deplojan pretecon, dokumentadon kaj ĉion alian, kion via organizo bezonas antaŭ ol ŝanĝo estas vere kompleta.
Dividu grandajn projektojn en mejloŝtonojn, kiuj ĉiu finiĝas reale, ne teatre. Petu pruvon de preteco, ne nur procentojn. Kiam teamo diras, ke io estas preskaŭ preta, demandu, kio restas en integrado, randkazoj, retroŝarĝo, subteno kaj produktada sekureco.
Plej grave, ĉesu rekompenci fruan optimismon pli ol malfruan precizecon. Teamoj ricevas pli bonajn taksojn, kiam vero estas pli sekura ol teatro.
Ĉu vi havas demandon aŭ sugeston, aŭ volas kompreni, kiel ni esploras kaj recenzas ĉi tiujn gvidilojn? Legu pri niaj redakciaj normoj kaj kiel kontakti nin.
Oftaj demandoj
Ĉu la naŭdek-naŭdek regulo estas matematike serioza?
Ne. La rompita matematiko estas la ŝerco. Ĝi estas maniero fari la horplanan voston neforgesebla.
Kial la fino de programara laboro estas ofte pli malfacila ol la komenco?
Ĉar la fino estas kie la sistemo renkontas realecon. Randkazoj, integrado, fiasktraktado kaj eldonaj detaloj ĉiuj fariĝas neeviteblaj.
Ĉu tio estas la sama kiel la Leĝo de Brooks?
Ne. La Leĝo de Brooks temas pri aldono de homoj al malfrua projekto. La naŭdek-naŭdek regulo temas pri tio, kiel la supoze malgranda fina etapo daŭre kreskas.
Ĉu agila laboro igas la regulon malaperi?
Ne aŭtomate. Ripeta liverado povas malkovri la voston pli frue, sed nur se la teamo traktas ĉiun tranĉaĵon kiel ion proksiman al vere eldonebla.
Kiel ni povas eviti la kaptilon?
Uzu pli fortan difinon de preteco, tranĉu laboron pli zorge kaj inkluzivas integradajn kaj eldonajn taskojn en la planon ekde la komenco.
Ĉu tio validas nur por klient-alfrontantaj produktoj?
Ne. Internaj iloj, infrastrukturaj ŝanĝoj, migradoj kaj datuma laboro ĉiuj povas montri ekzakte la saman ŝablonon.
Fontoj
September 1985 issue (Communications of the ACM). publication context for Jon Bentley's column and the period in which the rule entered print
Bumper-Sticker Computer Science (IIT Chicago mirror of Communications of the ACM article). early printed appearance of the rule, attribution to Tom Cargill, and "Rule of Credibility" label