Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Kravmaga2
- 1. Kravmaga - nærkampteknikker for overlevelse i enterprise gettoen - hvordan jobbe med krav når du ikke vet hva du vil ha?
- 2. Tidlig prototyping ● jruby og cucumber ● spike solution med jruby(irb) – tidlig utforsking av system/teknologi ● prototype i cucumber basert på kunnskap om kundebehov og det vi har lært om teknologien fra spiken ● iterere og bygge videre på prototypen basert på feedback
- 4. Vi snakker med den tekniske eksperten
- 7. Cucumber architecture Kravet defineres i en feature fil
- 8. Cucumber architecture Prototypen implementeres som en del av stepsene
- 9. Cucumber architecture Kode som trengs av flere step refactoreres til 'verden' i env.rb
- 10. Cucumber architecture Kode som skal brukes av både cucumber og webapplikasjonen flyttes ut til reservation_system.rb
- 11. Cucumber architecture Implementerer en minimal webapp som bruker reservation_system.rb
- 12. Cucumber architecture Manipulerer cucumber 'world' til Å kunne kjøre mot reservation_system.rb direkte, eller teste en web applikasjon
- 14. ...så hvorfor? prototyping => feedback => krav => prototyping Dette er ikke cowboy programmering, det er iterering! https://github.com/bjornno/kravmaga.git
Notes de l'éditeur
- Vi er kommet for å snakke om krav. Jeg heter Bjørn Nordlund osv..... å jobbe krav er vanskelig, særlig hvis kunder/steakholders ikke har noen god ide om hva de trenger og når man i tillegg ikke kjenner problem domenet så godt. Når man trener på å kode, har vært populært å hente begreper fra asiatisk kampsport, som dojo, kata osv, og siden kravarbeid er enda vanskeligere så synes vi det passet fint å innføre et nytt begrep – kravmaga. Krav Maga er en av de mest dødelige kampteknikkene som finnes, utviklet for å drepe facister i gettoene i øst europa i mellomkrigstida. Vi har riktignok fornorsket dette ordet til kravmaga, som i surmaga.... Enterprise gettoen kjennetegnes ved: - legacy systemer - lite kundekontakt - mye lagdeling - utilgjengelig produkt eier - lite kommunikasjon på tvers av team - organisasjon fortsatt preget av fossefallstenkning, selv om alle sier de itererer (Up front design eller cowboy programmering) I dette foredraget ønsker vi å vise hvordan man så tidlig som mulig kan sette opp en feedback sløyfe mellom reelle tekniske ting og kundens behov. Og vise hvordan vi som programmerere kan bidra effektivt til dette ved tidlig prototyping . Feedbackloopen gjør oss i stand til å iterere raskere og lære mer om problemene vi ønsker å løse for hver iterering.
- Som nevnt er målet vårt med å lage en prototype å få opp denne feedback sløyfen mellom forskjellige stakeholdere så tidlig som mulig. Vi har valgt å bruke ruby og cucumber til dette, fordi det er noe vi har jobbet med før, og fordi vi føler det er spesielt gode verktøy til hurtig prototyping, og for å beskrive systemoppførsel. Men dere vil kanskje velge andre verktøy som dere kan bedre, eller om passer bedre til deres problem. En prototype er en skisse av et system, og vi kommer til å vise hvordan vi kan ta en blyantstrek av en irb session som skraper nok i overflaten til at vi tror vi kan lage en litt mer gjennomarbeidet skisse med cucumber. Vi bruker så denne skissen til å lære mer om programmet og som utganskpunkt for videre samtaler med vår stakeholder. Når vi har fått litt erfaring med skissene våre viser vi en måte vi kan leverage cucumber feature fila vår til å drive fram en mer tradisjonell prototype i form av en web applikasjon som stakeholder og evt. andre tidlig brukere kan se på. Vi møter ofte stor motstand mot å starte med å programmere så tidlig i et prosjekt, og blir møtt av argumenter som at vi må jobbe mer med design arkitektur for å unngå cowboy programmering. Vi mener at vi heller bør starte med minst mulig begrensninger i form av design og arkitektur slik at vi står friere til å la disse valgene vokse naturlig fram som et resultat av iterering over problemet. Vi har valgt et case fra et prosjekt vi jobber i, og vi må derfor beskrive kort litt om domenet og presentere et tidlig ønske fra vår produkteier.
- Multiple control unit mcu Fra 12 HD video + 12 audio oppover så lenge lommeboka tillater I dag settes en konferanse opp ved å gå inn på mcu'en. MCU er en begrenset ressurs Ønsker en applikasjon (web) for å booke konferanser, og ønsker at dette skal være eneste måte slik at man unngår å komme til konferansen og at det ikke er nok porter, eller at noen bare får audio. Ok, hva skal til for å få slått en spiker tvers igjennom for å utforske mulige løsninger for kundeønsket vårt? Vi får ved å kontakte MCU teamet vite at det finnes et api for å reservere disse resursene allerede, og vi har begynt å leke litt med dette, men står nå fast på et par ting. En interaktiv IRB sesjon er kjempefin for å teste ut forskjellige antagelser.
- Vi har gravet fram guruen på MCU'en som har laget api'et, selv om han aller helst ville sitte nedi hulen sin i fred, så fikk vi lokket han frem med noen seigmenn.
- Kunden har veldig dårlig tid fordi han skal i workshop for å finne kravene til løsningen
- !!!! Da har vist hvordan man kan få opp en feedbackloop tidlig i prosjektet. og brukt denne gjennom presentasjonen. Det er fortsatt en lang vei å gå med å utvide spesifikasjonen av systemet og ikke minst å implementere det egentlige systemet, og det viktige blir å holde denne feedbackloopen oppe. Vi har vist noen eksempler på hvordan vi bruker feedback loopen til å sammen med stakeholdere på både teknisk side og produkt siden slik at de faktisk må forholde seg til realitetene og ikke bare kontre med har ikke tid, eller vent til neste overleveringsfase. Dette har blitt feedet rett inn i kravene og videre inn i prototypen. Vi tror dette har spart oss for mye tid, og vi kan delta mer aktivt som bidragsytere i stedet for å vente. Kanskje får vi gitt verdifull inputt til utformingen av produktet, og det api'et som mcu gjengen jobber med før ting blir helt låst. Som dere ser av stacktracen her så er det fortsatt en lang vei å gå før vi nærmer oss det endelige produktet.