» Feature forespørsel!!!»
det er ofte kampropet vi programvareingeniører bruker for å redusere haster med kundens problem. Tross alt er det ikke tid til å legge til nye funksjoner når vi ser ut på den uendelige feilloggen som står overfor oss.
for amerikanske programvareingeniører er forskjellen mellom en feil og en funksjonsforespørsel krystallklar. En feil er et avvik mellom hvordan koden faktisk fungerer og hvordan koden vår var ment å fungere. En funksjonsforespørsel krever ny kode for å tilfredsstille en sak som ikke kan håndteres av gjeldende kodebase.
denne typen tankeprosess fører oss alltid til det mer generelle spørsmålet om hvordan programvare Som DoneDone skal brukes. Bør organisasjonen bruke en type programvare for å logge feil, en annen type programvare for å administrere kommende oppgaver, og enda en type programvare for å spore funksjonsforespørsler?
Vi bruker mye mental energi på å prøve å sile gjennom problemer som er logget av en klient eller kunde, og prøver å avgjøre om vi kaster et problem i » bug «- bøtte eller» feature request » – bøtte. For konsulentarbeid, når vi jobber med en forhåndsdefinert avtale om hvordan programvare skal oppføre seg, er dette fornuftig. Feature forespørsler kan kreve en ekstra kostnad.
men når det gjelder bare den rene praksisen med å bygge god programvare, spesielt hvis vi jobber med egne produkter, hvor mye skal vi bry oss om å kategorisere et problem på denne måten?
vi lar teknikaliteter (og teknologi) komme i veien for å fikse problemer.
Robert Martin (aka Onkel Bob) snakker mye om programvare. Han anser Nettet bare en leveringsmekanisme og ingenting mer. Det er ikke sluttbrukeropplevelsen, og det er ikke hensikten med programvaren. Det er bare en liten liten dum detalj. Likevel, når vi programmerere programmerer, er arkitekturen til våre applikasjoner for helt påvirket av Det Faktum at Det er En Webapplikasjon.
på samme måte, hva om vi vurderte begrepet vi bruker for «en ting som må gjøres» for å være en dum detalj?
Fra personens synspunkt logger den «tingen», betyr det egentlig noe for henne at hun ber om en ny funksjon i forhold til å oppdage en feil? Hun vil bare at hennes problem løses av et annet menneske, og helst å vite når hennes problem kan løses.
du kan kanskje se teknisk mer åpenbart hvis vi forlater programvareverdenen. Når rørleggeren kommer inn for å fikse den lekkende dusjen, vil jeg tro at du ikke bryr deg om detaljene. Hvis dusjhodet ble feil installert (feil) eller hvis pakningen er ødelagt (feil) eller hvis teflon tape manglet fra et billig rør (funksjon), er alt du bryr deg om hvor lang tid det tar å fikse og hvor mye du vil bli belastet.
Feil eller forespørsel? Det er begge deler. Og det spiller ingen rolle.
Forrige uke Er Vi Mammoth utgitt Kin, ET HR-programvareverktøy for små bedrifter. Kin gir deg en enkel måte å spore hver ansattes tid av forespørsler. En Ting Kin ikke gjør akkurat nå er å skille helger og helligdager fra arbeidsdager. Så, hvis du ønsket å ta av en hel uke Under Thanksgiving, du må manuelt angi hvor mange timer som du ber av.
teamet har allerede mottatt noen forespørsler om At Pårørende skal gjøre denne sporingen automatisk. Faktisk er det i utgivelseskøen. Men når Den er logget, uansett hvor Den er logget inn, bør Kin-teamet vurdere det som en feil, en funksjonsforespørsel, en oppgave eller en gjøremål?
Ringer Min indre Onkel Bob, mitt svar er enkelt: Det spiller ingen rolle hvordan du klassifiserer forespørselen. Det er bare en dum detalj.
Det er ikke å si at vi ikke bør klassifisere det i det hele tatt. Kin-teamet kan merke problemet under «funksjonsforespørsel» og jobbe med å fikse mer kritiske problemer først (som en bruker med et autorisasjonsproblem). Det er fint og dandy, og en gyldig tilnærming.
det ville Imidlertid være en feil å automatisk anta at alle ting-we-call-feature-forespørsler er mindre presserende enn alle ting-we-call-bugs. Det gjør ganske små detaljer om hvordan vi klassifiserer problemet midtpunktet for når vi løser det. Det burde ikke være sånn. På slutten av dagen er alle disse forespørslene bare ting som trenger oppløsning.
La teknikaliteten være den dumme detalj
for det formål er etiketten vi gir til alle disse forespørslene stort sett ubetydelig. Det som betyr mer er at noen deltar på dem, og det er en generell ide om når disse forespørslene vil bli adressert. Det som betyr mer er at 33% flere brukere vil dra nytte Av At Element A blir adressert mot Element B. Uansett hvilken type ting Element A eller Element B er, Er Element A mer verdifullt å adressere. Sånn ja. Ikke noe mer.
så neste gang du bruker for mye tid på å kategorisere oppgaver, feil, funksjonsforespørsler og gjøremål, husk å glemme de tekniske egenskapene. Det er bare de dumme detaljene.
Registrer Deg For En DoneDone-konto på 30 sekunder. Vil du lese Mer Av Ka Wai Cheung? Ka Wai nye bok om dagens programmerer, Utviklerens Kode, er tilgjengelig i ebok og print. Du kan følge ham på Twitter @ developerscode.