80/20 påvirker også planlegging

Vi har alle hørt om 80/20-regelen, den som sier at 80% av vår suksess (effekter) kommer fra bare 20% av våre handlinger (årsaker). Vel, denne universelle sannheten påvirker også programvareutvikling, og i denne artikkelen skal vi spole litt på det grunnleggende i denne uttalelsen.

BPM

Business Process Management, for forkortelsen på engelsk, er en ledelsesdisiplin (blant annet) som lar deg visuelt forstå prosessene som må utføres i en bedrift (eller mange andre steder). Blant de viktigste egenskapene er det at den kan analysere komplekse prosesser og gjøre dem "enkle".

Det er mange open source-verktøy som lar deg utvikle BPM-diagrammer, den jeg har brukt til denne artikkelen er BonitaSoft. Hvis du vil lære litt mer om prosessadministrasjon, er det mange opplæringsprogrammer på internett og bøker om emnet. La oss nå komme tilbake til det sentrale emnet.

Programvareprosjekter

I dag finnes det mange metoder for å utvikle prosjekter: smidig, tradisjonell, hybrid og så videre. Én ting de alle har til felles er forberedelse . Hva mener jeg med dette? At 80 % av suksessen din i dette programvareprosjektet vil avhenge av de første 20 % av hele prosessen: forberedelse.

Forbereder et prosjekt

Dette er et logisk poeng som sjelden brukes i virkeligheten (som mange andre logiske ting som er ulogiske i praksis). Når vi snakker om forberedelse, må vi forstå evnen til å forstå problemet, forstå løsningen og fremfor alt prosessen som løsningen bruker. En av de minst vanlige tingene man finner i uprofesjonelle programvareprosjekter er mangel på dokumentasjon om dette emnet. Dette forekommer vanligvis i private selskaper, siden ønsket om å selge ofte overskygger utviklingsprosessen.

Siden mange av de som leser disse artiklene jobber innen eller er relatert til teknologi, er det verdt å nevne at hvis de på noe tidspunkt i løpet av arbeidslivet møter et selskap/en leverandør som ikke oppfyller en god forberedelsesstandard, er det nesten 80 % sikkert at prosjektet ikke vil gå bra.

Abstraksjon er nøkkelen

Dette er noe jeg har lært fra tiden min med GNU/Linux, og det viser seg gang på gang å være nøkkelen i programvareutviklingsprosessen. Evnen til å abstrahere problemer og gjøre dem om til enklere ting er avgjørende for å generere elegant, og fremfor alt, holdbar kode . Og kanskje er dette en av hovedforskjellene mellom store profesjonelle prosjekter og prosjekter som vokser ukontrollert. Førstnevnte tenker gjennom, forstår og strukturerer prosessen, mens sistnevnte bare holder den i gang uten å måtte forstå den.

stager

Dette er navnet på prosjektet som Gentoo-installatøren utvikler, som du kan forestille deg, dette er ganske komplisert, siden det støtter et stort antall arkitekturer. En annen faktor å ta i betraktning er antall konfigurasjoner den støtter, på kjernenivå, init-system, etc. Og jeg forteller deg alt dette fordi det også er avhandlingsprosjektet mitt, som jeg må fullføre før jeg er ferdig med studiet. Åpenbart kan jeg ikke lage et program som vurderer absolutt alle mulige alternativer på så kort tid (til juli neste år), men i det minste kan jeg generere et som lar et funksjonelt system installeres på en veldig grunnleggende måte.

Forstå installasjonsprosessen

Takket være BPM-verktøyene kan det genereres et prosessdiagram som lar oss forstå trinnene som er nødvendige for en vellykket installasjon av Gentoo på en datamaskin.

Til tross for at den inneholder flere prosesser og delprosesser, har den åpenbart blitt ganske oppsummert, og det kan sees at vi har 18 lineære trinn. Dette er viktig fordi et program som har en lineær struktur er enkelt å implementere, og samtidig kan det genereres parallellitet i en eller flere av trådene.

En annen viktig faktor er at det lar oss abstrahere sett med prosesser etter type; for eksempel lar det å definere en kjernedelprosess oss vite at det finnes spesifikke oppgaver i den som er direkte relatert til prosessen med å installere en kjerne.

På denne måten blir hvert "komplekse" trinn et "enkelt" på en global måte, uten å miste de nødvendige detaljene. Dette letter synligheten av sammenstillingen uten å redusere spesifikasjonsnivået som er nødvendig for å fullføre prosessen. Og vi kan ikke nekte for at det er lettere å se bildet enn å lese hele håndboken på en gang 

Spare tid

En annen åpenbar fordel er at ved å ikke ha et direkte koblet programmeringsspråk, er det mulig å utføre logisk analyse uten å kaste bort tid på å implementere språket. Dette er en fordel i forhold til hvor lang tid det kan brukes på å implementere en funksjon bare for å finne ut at den vil bli kastet fordi det er en mer effektiv løsning. Som hva som ville være løsningene i pseudokode (noe som også ignoreres av mange "utviklere", men som ikke burde være).

Det er enkelt å lede prosjekter

Når disse konseptene tas i betraktning, blir prosjektledelse (av enhver art) enklere, fordi vi fokuserer innsatsen der det virkelig er nødvendig, og hvis denne delen gjøres riktig, faller resten under sin egen vekt. Jeg håper det hjelper på nysgjerrigheten din og motiverer deg til å forske på BPM, algoritmer og hvem vet, kanskje det vil oppmuntre deg til å hjelpe meg med oppgaven min  Tusen takk for at du kom så langt, så sees vi snart. Hilsen