Bildekilde: pixabay.com

Ekstrem programmering

Se for deg dette: Et programvareutviklingsprosjekt for et nytt produkt, basert på først-til-markedsfordel, har nettopp blitt oppdaget på bedriftens radar. Tradisjonelle metoder for ekstrem programmering, der klienten vet "nøyaktig" hva de vil, er ute. Teamet ditt er lite og sammensatt av unge fagpersoner som sannsynligvis vil svare godt på en radikal prosjektledelsesmodell. Hva er alternativene dine?

Du vil sannsynligvis si, Agile Project Management, selvfølgelig! Men hvilken metodikk vil du bruke? Det er flere alternativer: for det første er det den enormt populære Scrum: som innebærer å lage korte "sprints" basert på kundens etterslep av oppgaver. Og så er det Kanban, som jobber med å optimalisere rørledningen til arbeidet. Det er også ekstrem programmering, ofte forkortet til XP, som fokuserer på å forsterke de positive aspektene ved tradisjonelle programmeringsmodeller slik at de jobber maksimalt.

Ekstrem programmering er en veldig populær (selv om den ikke er så populær som Scrum) metodikk med fokus på å møte endrede kundekrav. Det første ekstreme programmeringsprosjektet ble startet i mars 1996 av Kent Beck på Chrysler. I sin bok fra 1999, Extreme Programming Explained: Embrace Change, detaljerte han aspektene for programvareutvikling.

Kent Beck var også pioneren innen testdrevet utvikling, som satte bruk-case-testing på radaren som en forbedring av måten ting ble gjort da: å skrive linjer og kodelinjer og deretter teste den. Han var også en av de opprinnelige underskriverne av Agile Manifesto, og hjalp til med å forme manifestet til å endre måten ekstrem programmeringsprogramvare ble skrevet på.

De fem verdiene for ekstrem programmering basert på Explained er:

Kommunikasjon

Ekstrem programmering er ikke avhengig av omfattende dokumentasjon. Faktisk foreslås ekstrem programmeringsdokumentasjon bare når det er nødvendig. Så metodikken er avhengig av kommunikasjon mellom teammedlemmer og også med brukerne.

enkelhet

Dette er kjernen i Extreme Programming. Metodikken favoriserer enkle design, ikke tenker for langt frem i tid, men fokuserer på kravene i dag, samtidig som programmet i seg selv er robust nok til å legge til kravene fremtiden kaster opp.

Tilbakemelding

Denne essensielle sløyfen med å gå frem og tilbake skiller agile systemer generelt og Ekstrem programmering spesielt fra andre programvareprosjekteringsmetoder. Den kontinuerlige tilbakemeldingen kan fungere på forskjellige måter, men de jobber alle for å gjøre systemet sterkere og mer pålitelig.

Tilbakemeldinger kan komme i forskjellige smaker:

  • Fra selve programmet: Kode testes kraftig gjennom prosjektutviklingssyklusen, slik at endringer kan implementeres av utviklerne.
  • Fra klienten: Dette er en viktig del av de fleste Agile-systemer. Klienter skriver akseptstestene som utviklingen er basert på, og dette danner ryggraden i utviklingsprosessen. Alle iterasjoner blir også levert til klienten for periodisk tilbakemelding.
  • Fra teamet: Når en ny brukssak / -historie er opprettet, vender teamet seg umiddelbart tilbake med kostnadsberegning og estimering av tidslinjer, noe som styrker opp kravene når de oppstår. I ekstrem programmering er det ingen som "eier" noen kode, og derfor, innen ekstreme programmeringsteam, oppmuntres tilbakemeldinger på andres kode.

Mot

Dette kan virke som en merkelig verdi i ekstrem programmering for programvareutvikling, mer egnet til noe som Army eller the Marines! Men tenk på det: Programvareprosjekter har i lengre tid blitt ødelagt av tradisjonelle ekstreme programmeringsmetoder for styring; sikre komforten med omfattende dokumentasjon og hierarki som ikke tillater innovasjon. Denne verdien illustrerer kjernen i ekstrem programmering: Vær klar til å hoppe, uten fallskjerm hvis det kommer til det! Se på denne forskjellige stilen for prosjektledelse, og vær klar til å være ansvarlig, å gi avkall på hierarki og være ansvarlig og arbeide uten å vite alt i begynnelsen.

Respekt

Respekt, den femte verdien, ble lagt til senere, og betyr respekt for andre og jeget. Det innebærer også respekt for koden som blir skrevet og for klientens forventninger og behov. Denne verdien ligger til grunn for kommunikasjonen mellom forskjellige interessenter også.

Aktiviteter i et ekstremt programmeringsprosjekt

Ekstrem programmering skiller fire enkle aktiviteter i et prosjekt. De er:

  • Koding : Ekstrem programmering anser dette som den viktigste aktiviteten. "Uten kode er det ingenting, " sier Kent Beck, grunnleggeren av Extreme Programming.
  • Testing : Kode er bare det med mindre den testes. Ekstrem programmering er besettende når det gjelder testing, ved bruk av enhetstester for å bekrefte at koden fungerer og klientgenererte akseptstester for å bekrefte at koden tester det som må testes.
  • Lytte: Å lytte, eksemplifisert med kjerneverdien av kommunikasjon, er en aktivitet som krever at utviklerne ikke bare hører klientene, men virkelig lytter til hva de vil. Utvikling og forretning er to forskjellige ting, og ofte klarer ikke utviklere å forstå forretningssaken til en bestemt beslutning. Kundens behov, så vel som utviklerne, danner grunnlaget for "lytte" -aktiviteten.
  • Designing : Det kan overraske deg at i et programvareutviklingsprosjekt er designaktiviteten, ofte så viktig og primær, plassert på slutten. Dette er fordi ekstrem programmering bevisst ønsker å få folk ut av tankegangen "design og utvikling" som industrien har pleid i mange år. Det er ikke for å begrense viktigheten av å designe. Snarere er god og minimal design et av kjennetegnene på et prosjekt.

Fra verdiene og aktivitetene kommer de 12 prinsippene for ekstrem programmering, som de er utarbeidet av grunnleggeren, i sin bok Extreme Programming Explained.

  • Planleggingsspill
  • Parprogrammering
  • Testdriven utvikling
  • Hele teamet
  • Kontinuerlig integrering
  • Forbedring av design
  • Små utgivelser
  • Kodingsstandarder
  • Eier av kollektiv kode
  • Enkel design
  • Systemmetafor
  • Bærekraftig tempo

Noen få av disse ekstreme programmeringspraksisene, alle kartlagt til programvareingeniørs beste praksis, er forskjellige fra generiske Agile-metodologier. Noen av fremgangsmåtene for ekstrem programmering blir forklart nedenfor:

  1. Planleggingsspill

Dette er planleggingsdelen av prosjektet, referert til som "Planning Game". Det inkluderer planlegging for neste iterasjon og utgivelse, i samråd med brukeren / klienten, samt en intern planlegging av teamene, med hensyn til oppgavene de vil jobbe med.

  1. Parprogrammering

Dette involverer to personer som jobber med et stykke kode. Den ene personen, kalt tastaturet, skriver inn koden, mens den andre, kalt skjermen, fører tilsyn med koden, kommenterer og foredler den, etter behov. De to personene bytter ofte rollene sine. Dette har vist seg å forbedre effektiviteten til kode betydelig. Dette passer kanskje ikke til alle utviklingsscenarier, og det er noe du må vurdere før du registrerer deg for Extreme Programming.

  1. Testdrevet utvikling

All kode som er skrevet blir gjennomgått enhetsmessig, det vil si at hvert kodestykke som kan gjøre noe testes først. Ekstrem programmering legger mye vekt på testing. Dette hjelper til med å bekrefte at koden fungerer, og slik at den deretter kan vurderes for inkludering i selve det ekstreme programmeringsprosjektet. Det er analogt med enhetstester på skolen: små informasjonstykker testet, slik at læreren / eleven kan gjøre kurskorreksjoner og ikke flyte under de årlige eksamenene!

  1. Designforbedring (refactoring)

XP-prosjekter, basert på funksjonen i enkelhet, tar sikte på kontinuerlig å forbedre koden som er skrevet. Dette betyr at hele koden (og noen ganger også databasen) alltid forbedres. Refactoring tilfører ingen funksjonalitet; den forbedrer bare den eksisterende koden. Gjør det strammere og tydeligere. Det tilsvarer å redigere et stykke å skrive, polere det og gjøre det bedre.

  1. Enkel design

I ekstrem programmering blir ikke funksjoner lagt til før det kreves spesielt. Selv om koden som det arbeides med for øyeblikket er veldig lik det som kan være nødvendig i fremtiden, tas den ikke opp med mindre den er avtalt som en brukerhistorie.

  1. Systemmetafor

Dette inkluderer standardisering av alle navnekonvensjoner slik at dets formål og funksjon lett blir dechiffrert. For eksempel kan operasjoner eller operasjoner hjelpe enhver programmerer med å forstå funksjonaliteten deres. Dette bør lages på tvers av hele det ekstreme programmeringsprosjektet, slik at det er lett for alle å se på koden og endre eller bedre den, etter hva som måtte være.

Roller innenfor et ekstremt programmeringsprosjekt:

I likhet med Scrum har Extreme Programming noen få utpekte roller i hvert prosjekt. Nå trenger ikke rollene alltid utføres av distinkte mennesker, og en person kan påta seg mer enn en rolle.

Rollene for ekstrem programmering er:

  • Kunde : Selvforklarende. Årsaken til prosjektet. Hun bestemmer hva prosjektet trenger å gjøre. Hun gir brukerhistoriene.
  • Programmerer : Dette er personen som:
    • Tar historiene som kunden kommer på
    • Lager programmeringsoppgaver ut av historier
    • Implementerer brukerhistoriene
    • Tester koden etter enhet
  • Trener : Treneren sikrer generelt at prosjektet er i rute, og hopper også inn for å hjelpe når det er nødvendig.
  • Tracker : Tracker stiller konkrete henvendelser til programmerere med et bestemt intervall. Typisk går han rundt og sjekker fremdriften for programmerere, tilbyr hjelp der det trengs på flere måter: å rulle opp ermer og hjelpe direkte med koden, gi beskjed til Coach, eller sette opp et møte med kunden, alt etter behov.
  • Tester : Kjører funksjonelle tester. Testeren kjører ikke enhetstester, som blir kjørt av programmererne selv.
  • Doomsayer: Dette, som navnet antyder, ligner Black Hat i Edward De Bonos system for gruppetenkning. Hvem som helst kan være en dommerspiller, som vanligvis flagger potensielle problemer og hjelper til med å holde problemer i riktig perspektiv.
  • Manager : Lederen i et ekstremprogrammeringsprosjekt ligner mer på en planlegger, og sørger for at møtene skjer som planlagt, og sikrer at beslutningene som tas under møter blir gitt videre til den aktuelle personen, oftere enn ikke, Tracker. Lederen forteller imidlertid ikke hva de skal gjøre og når de skal gjøre det. Dette gjøres av kunden og / eller brukerhistoriene selv.
  • Gull eier : Gull eier er personen som finansierer prosjektet. Dette kan være kunden, men ikke nødvendigvis det.

Noen av de ekstreme programmeringsrollene, som beskrevet ovenfor, kan kombineres, men noen kan det tydeligvis ikke.

Kunden kan for eksempel ikke være programmerer også. Programmereren og Tracker kan på samme måte ikke være den samme personen.

De ekstreme programmeringsrollene er definert tydelig nok, slik at det ikke er forvirring, og skapt for maksimal fleksibilitet og effektivitet.

Ulemper ved ekstrem programmering:

Mens tilhengere av ekstrem programmering maler et rosenrødt bilde, er faktum saken at ekstrem programmering, som navnet antagelig antyder, er ekstremt vanskelig å implementere. Fasetter av ekstrem programmering kan integreres i prosjekter mer vellykket enn å ta i bruk XP fullstendig.

Noen av negativene ved ekstrem programmering er:

  • Ekstrem programmering er funnet å være mer effektiv i mindre grupper . Effektiviteten i større grupper er omstridt, og et bedre alternativ er å dele ekstreme programmeringsteam slik at gruppene blir mindre.
  • En av nøkkelfunksjonene i ekstrem programmering, parprogrammering fungerer ikke bra i mange tilfeller . Kompleks koding kan kreve to hoder, men ikke alle oppgaver kan kreve to personer, med den andre personen en død vekt. Faktisk er parprogrammering, hvis et av medlemmene ikke er synkronisert med det andre, en av hovedårsakene til at ekstrem programmering mislykkes i mange tilfeller.
  • Avhengigheten av kunden, til poenget med å foreslå en ressurs på stedet fra kundens side, kan være dypt nervøs. Det kan også føre til interferens, både ekte og innbilt, under utvikling.
  • Ekstrem programmerings fokus på enkelhet kan gjøre det veldig vanskelig å legge til det nåværende prosjektet, noe som betyr et høyere budsjett for enda enkle endringer, som ikke forblir enkle lenger.
  • Den flate hierarkiske strukturen innebærer at teamet alltid skal være fokusert, og i mangel av en leder for å korrigere forskjellige mennesker, er et ekstremt programmeringsteam helt avhengig av den emosjonelle modenheten til alle teammedlemmer, en faktor som ikke alltid er pålitelig .

Selv med disse faktorene er Extreme Programming fortsatt et kraftig verktøy som kan brukes til riktig prosjekt, med selskaper som rapporterer om en mangfoldig økning i effektiviteten etter å ha tatt i bruk den ekstreme programmeringsprosessen. Et utviklerdrevet system i motsetning til Scrum, som er mer et prosessdrevet system, ekstrem programmering, eller i det minste deler av det, kan føre til en revolusjon i måten vi utvikler ekstrem programmeringsprogramvare.

Kategori:

Entreprenørskaputvikling