10 XP extreme programming

Välkommen till del 10 i avsnittet. Processer och process modeller. Den här delen går specifikt in och tittar på den gamla modellen Extreme Programming som jag ofta förkortar som XP. Expert är en form av agil process som vi kommer att gå in och titta lite mer på då den har hängt med ganska länge och också en process som även om man inte använder hela XP ofta lånar delar från den för att den är från barn. Agil process ganska stor. Och den här började utvecklas av en butik under 90 talet i olika projekt där han arbetade att. Hur kan man göra saker i det här som är effektivare, som är mer flexibla och beskriver ganska mycket delar för hur själva utvecklingen ska göras? Hur ska man skriva kod på olika sätt? För att vara en agil metod innehåller den förhållandevis många delar och regler att förhålla sig till. Om man ska använda Excel i sin helhet så säger XP rätt mycket och styr rätt mycket om hur man bör jobba. Grunden i Expert är det man talar om som Expert Salvius. Och. Här finns ett antal sådana här och du kommer att känna igen dessa från de agila principerna om kommunikation där man talar om det här med vikten av att kommunicera nära och tillsammans öga mot öga, kommunikation och extern trycker också mycket på att man vill ha in användarna representerade varje dag i vardagen. I utvecklingsteamet att i utvecklingsteamet så ska det finnas en representant från slutanvändarna för att underlätta den här kommunikationen. En annan väg är Simplicity och det handlar om att göra saker i små steg. Att ha små korta instrument för det man gör så att man hela tiden kan kommunicera och stämma av. Är det här det som efterfrågas? Gör vi rätt sak i det här, men också att inte bygga någonting som blir onödigt komplext och sedan att man håller nere komplexiteten till precis det man gör nu och det som behövs. Och detta knyts då in med feedback. Demonstrera tidigt. Lyssna på slutanvändarna. Anpassa det man gör. Och att man hela tiden får en loop i den här feedbacken som gör att vi kan jobba liknande evolutionära process. Modellen att hela tiden förändra och bygga upp vår mjukvara efter hand utifrån den feedback vi får. En annan sådan här världen väljer att tala om kurage, att tala sanning. Att inte försöka skyla över någonting, att det tar så här lång tid. Men också att komma ihåg att ingen arbetar ensam och att man är ett team, att man inte skyller på varandra utan att man är en grupp och att man också vågar stå för det man gör. I det här. Att man inte försöker undanhålla problem från sin kund, till exempel i det här. Och det går också hand i hand med att man talar om respekt i det här. Det handlar om att alla bidrar med något värde i ett projekt, att man behöver respektera kunden och deras kunskap om den domän de finns i och också respektera att de kanske inte alltid vet exakt vad man behöver och liknande. Det här kommer som förändringar att acceptera utvecklares kompetens och förmåga att fatta beslut runt det man gör, att man som ledning måste lämna ett visst ansvar och befogenheter till utvecklarna för att det ska fattas bäst beslut. Det här gör ju också att det kräver disciplin från utvecklarna, att man faktiskt tar det där ansvaret och inser att det är mitt jobb att fixa det här. Så det här går som ett utbyte i de här delarna. Så det här är grunden som expert står på. Här ser vi att här återkommer mycket av det som vi ser i de här agila principerna som bryts ner till mer detaljerade regler i XP XP rules. Och vi kommer inte att här gå igenom alla dessa för det här är en stor del. Men du förväntas läsa dem här och titta på de här för att skapa dig en mer förståelse av dem. Det är framför allt de här reglerna som man plockar och lånar in där man lånar delar från XP som process modell. Några av de vanligaste att tala om är det som är user stories med. Hur beskriver man en produkt från användarens synvinkel att man tar användarens perspektiv med hur något fungerar och gör en liten berättelse i princip som visar? Hur fungerar mjukvaran? Här finns ett överlapp. Hur tänker du om use cases? Det här är lite samma tanke med lite variation. Skillnader i det här sammanhanget. Att beskriva någonting från användarens synvinkel. Vi kommer i avsnitt om krav hantering att titta på mer. Hur kan man använda detta som ett verktyg? Man talar om kollektiv ånger cup och när man är ett gäng mjukvaruutvecklare så är det inte ovanligt att vissa blir väldigt. Protective om sin egen kod. Här är min kod. Gå inte in och pilla i min kod. Jag skriver den här koden. Jag har hand om detta, det är mitt. Den andra sidan av detta är också att man säger att problemet är din kod. Det är inte min kod, ditt problem. Fixa det. Det vill säga att man delar upp det och man lätt hamnar i ett sådant här blame game om vems fel eller någonting eller liknande. Men det här måste man släppa. Man har ett kollektiv och inger hopp. Det är allas ansvar. Man kan inte säga att det här är min kod. Min del får inte göra detta. Man behöver vara så samspelt att man kan jobba i all kod. Det handlar inte heller om att säga vems felet är, att det finns en viss bugg eller en viss missförstånd. Det är inte produktivt. Det är bättre att säga att här är det fel. Hur fixar vi det här inte? Vem råkade skriva det här för? Det har redan hänt. Det är inte intressant längre vem som gjorde det här. Det man kanske kan reflektera över är dock när det handlar om någonting som är ett problem. Hur kan man undvika ett problem igen? Men att alla har ansvar för det som är gemensamt i det här och att allt är gemensamt? Expert trycker också gärna på det man talar om som park programmering att man jobbar tillsammans med. Det här finns olika varianter på hur man beskriver park, programmering man talar om, driver och maktstrider. I vissa fall där en person har tangentbordet och så att säga styr och är den som skriver kod. Men den som sitter bredvid ser till att man följer koden. Kyle Lines pekar ut fel och liknande till exempel. Detta är också ett sätt att öka den kollektiva känslan när man delar på koden. Park programmering är en av de absolut vanligaste delarna att låna in från XP och i vissa fall så kan programmering vara väldigt bra, men det kan också vara problematiskt. Är man på ungefär samma nivå? Har man bra stöttning av varandra om man kan diskutera. Är man på alltför olika kunskapsnivå? Generellt om utvecklingen eller om den här produkten specifikt så är det kanske så att en person tar över och en annan person mest blir passiv och då inte heller har programmering då absolut lämpligaste. Det finns utmaningar i det här. Det är samma sak här. There is no cyber bullet. Det finns inga enkla svar så därför är det viktigt att titta på att förstå. Var är har programmering nyttigt och inte? Det är något som experter ser som en del i att nyttja det här. Och man tar också in det här som talar om factoring att förändra sin kod. Och när vi talade om olika instrumentella modeller så tog upp det här med genererande arkitektur som ett problem att arkitekturen om man har för snäv synvinkel inte blir lämplig i slutändan. Man gjorde därför en liten del med factoring, ett sätt att motverka detta, att med jämna mellanrum ta ett steg tillbaka. Titta på hur koden ser ut och se. Kan vi göra detta bättre? Det kan handla om att man faktiskt behöver skriva om delar för att göra en bättre, mer robust arkitektur som är mer flexibel framöver och passar bättre. Det kan också handla om att man inser att man kanske har en redundant kod, att här finns en del som faktiskt finns liknande. Här kan vi slå ihop det här och skapa en bit som man kan nyttja gemensamt. Till exempel finns många olika delar i det här och vi kommer att komma tillbaka till det i senare avsnitt också. Och man talar också om Testdriven Developments och enhets tester. XP drar det till ytterlighet där man menar att man skriver testerna först och testdriven utveckling. I sin renaste form innebär det att man skriver testerna först för att veta vad som ska göras med det som ska uppfyllas. Och i första körningen ska testerna fallera. För det finns inte koden och sedan skriver man koden och kör i efterhand för att kontrollera att det nu är uppfyllt och fungera och enhets testet som är att testa små bitar av koden i isolering. De här delarna kommer vi också tala mer om i avsnitt om verifiering och validering. Men det här är bitar som man ofta ser i andra utvecklings modeller, men som XP då också bygger in på det här. Och sedan har experten stort vikt på Sustainable pays. Det här med att man inte ska ha en arbetstakt som blir orimlig över tid får inte lov att existera. Enligt den behöver utvecklarna jobba övertid. Har man inte planerat tillräckligt väl då har man tagit sig an för mycket på för kort tid och då behöver man justera sin process så att det där inte sker igen. Så finns delar som lånas in i många andra processer. Det här är bara en del av de här olika virus som finns inom XP, men det är några av de vanligaste som man ser lyfts ut i andra sammanhang. Ja, XP har vissa problem som behöver adresseras om den inte processen i sig självt säger så mycket om krav riskerar att bli väldigt flyktiga. Ändringar sker väldigt informellt i XP och det innebär att det kan vara svårt att se konsekvenser av ändringar som sker. Vad blir följden någon annanstans? Så det här kan få krav som förändras väldigt mycket ofta och kanske inte med tillräcklig kontroll för påverkade någonting annat. Expert talar mycket om vikten med kommunikation. Men om man har ett större projekt med många intressenter i många personer som har någonting som är viktigt. Intressenter är stark på engelska är just vad står på spel för? Vem har något på spel i det här? Här kan bli konflikter mellan till exempel olika krav och sätt att se på det hela. Kommer ni att titta på mer sådana här saker, till exempel sådant som hög säkerhet kan motverka hur lättanvänt ett system är på olika sätt? Exempel. Men Expert säger att vi ska ta hänsyn till alla våra intressenter och ger dem tid. Men den adresserar inte problematiken med att det sannolikt finns konflikter mellan intressenter på olika sätt. Och hur hanterar man då de konflikterna när man måste kompromissa? Krav i ett spel definieras strikt bara via dessa storys. Det gör det också svårt att isolera är i sina står. Krav som är i konflikt med varandra är svåra att identifiera och det ökar också risken för att man glömmer bort krav. Och. I detta så är det också så att man har en mindre formell design där man kommer in med prefekturen, men det kan göra att systemet blir svårt att överblicka för att det finns få delar som adresserar helheten och framför allt tillsammans med kraven där man talar om krav som är icke funktionella som inte en specifik funktion i sig själva men som är något som finns övergripande i systemet som talar om systemets kvalitet. Den typen av krav kan vara svåra att. Att identifiera och dokumentera och se till att de uppfylls i XP. Det kommer vi att tala mer om i avsnitt om krav hantering. Så XP har många värdefulla delar men är förhållandevis stor för att vara en agil process. Men det finns väldigt mycket matnyttigt som man också kan lyfta ur i mer isolering från XP och låta sig inspireras av och samtidigt komma ihåg att där finns saker XP inte adresserar. Det är inte en universallösning på någonting. Även om det finns bra drag. Men man ska ha medveten om vad kan man behöva komplettera med om man utgår från det som sägs?