tisdag, januari 29, 2008

Agila metoder passar bäst för DotComs

Refactoring har blivit en naturlig del i agile mjukvaruutveckling. Frågan är bara hur stor del den tar av en utvecklingscykel och blir nettoeffekten positiv för resultatet.

Det är ju allmänt känt att agila metoder passar bäst för små projekt, utan externa beroenden, som ska utveckla en ny mjukvara/applikation. Det i kombination med att produktägaren är klar över vilka features som kommer skapa affärsvärde. Summan av dom förutsättningarna kan sammanfattas med ett ord, DOTCOM.

Idag ser vi inte mycket DOTCOM-projekt, även om dom finns. Däremot finns det liknande karaktärsdrag hos andra projekt där agila metoder lyckas väl. Dom projekten delar ofta samma förutsättningar med avseende på storlek och omfattning. Projekt som däremot får in beroende till andra system, externa parter, integration, governance och del av en enterprise arkitektur kan inte lyckas lika väl med agila metoder.

Agila metoder går nämligen ut på att inte ta hänsyn. Scrum har exempelvis sina sprintar där man trycker in s.k. stories. Hur de implementeras är inte intressant, bara att dom implementeras. Hur kan man alltid göra om, då man refactorerar. Har man externa beroenden så måste man ta hänsyn, följa riktlinjer, förhålla sig till en integrationsplattform, masterdata, krav på återanvändning, m m. Agila metoder har ett sätt att tackla förhållningsregler, men då enbart inom projektet - nämligen genom refactoring eller "gör om, gör rätt".

20 kommentarer:

Joakim Sundén sa...

Wow, vilket flamebait! Jag tänker inte nappa utan bara konstatera att du antingen inte bemödat dig tillräckligt om att ta reda på vad Agile är eller att du målar fan på väggen bara för att få nöjet att piska honom (bygger en "straw man" kanske andra skulle säga).

Jag vet sedan tidigare bloggposter att du anser dig vara påläst inom ämnet och "bara är av en annan åsikt". Det vore intressant att få veta vad/vem som givit dig uppfattningen att agila metoder går ut på att "inte ta hänsyn" och varför man i ett agilt arbetssätt inte skulle följa riktlinjer, förhålla sig till en integrationsplattform, återanvända etc.

Jonas Ekström sa...

Jag skriver provocerande för att spräcka hål på bubblan och hypen kring olika påfund. De påfund som är allra roligast att skriva om är dom där det skapats ett konsensus i utvecklarkretsar. Ex. agila metoder, TDD eller DDD. Man läser dogmatiska skildringar som dra horder av lärjungar utan att ifrågasätt utövandet.

Jag menar inte att de schamaner som predikar i ämnena har fel, men måste tåla en debatt.

Att inte vara påläst brukar ofta vara dom kommentarer man får då. Mycket läskande för debatten ... NOT. Tål inte utvecklare när man flamear deras bebisar eller?

Hur ser du själv på förhållandet mellan arkitektoriskt långsiktiga mål och resultatet från korta itterationer?

Min uppfattning är att agila utövare ibland missar dom målen för att sedan fastna i refactoreringsträsket för att ta sig in i matchen igen.

Jag menar att det problemet uppstår mer eller mindre beroende på storlek och omfattning av projektet.

Joakim Sundén sa...

Om du tycker att det är "konsensus i utvecklarkretsar" kring "agila metoder, TDD eller DDD" representerar din utvecklarkrets knappast verkligheten i stort (att du däremot därmed tycks leva i min "drömvärld" är en annan femma).

Jag vet inte vilka "dogmatiska skildringar" du läst, men om du rör dig i kretsar där det råder konsensus om agila metoders förträfflighet är det kanske inte så konstigt att det du läser framstår som dogmatiskt... ;-)

Om man tittar på tongivande personer inom Agile, som t.ex. Martin Fowler, Pragmatic Programmers (Dave Thomas & Andy Hunt) eller Alistair Cockburn (samtliga är "signatories" av http://www.agilemanifesto.org/), är det knappast dogmatism man associerar till. Agile är i mina ögon snarare ett mycket pragmatiskt och prövande angreppssätt som kan sägas ha fötts ur vad som "faktiskt fungerar" snarare än vara skapat utifrån "så här borde det gå till". Dessutom är en kontinuerlig och frekvent omprövning av metoder och arbetssätt en mycket viktig del av Agile.

Det är klart att det finns dogmatiska förespråkare också - det finns det väl för allt - men bland ledande förespråkare och i rörelsen i stort känns just dogmatism väldigt främmande.

Jag har viss förståelse för att man kan bli lite less på att vissa trender snabbt blir sanningar där eventuellt ifrågasättande bemöts med höjda ögonbryn och nedsättande oj-han-kommer-nog-från-1800-talet-och-har-bara-inte-upptäckt-frälsningen-än. Självklart måste även Agile ifrågasättas och diskuteras, men frågan är om det görs bäst genom "debatt" där man går in med en antagonistisk inställning, bygger "straw men" av "motståndarsidan" och beskriver den i pejorativa ordalag ("trycker in s.k. stories", "schamaner som predikar", associationer till "dotcom" etc).

Det kanske istället är en diskussion som behövs där man bemödar sig om att första sin diskussionspartner och hur denne tänker. Och där vet jag väldigt lite om ditt alternativ till agila metoder. Det skulle inte förvåna mig om ditt föreslagna arbetssätt inte alls står i motsatsställning till, utan kan förenas med, agila metoder.

När det gäller t.ex. Eric Evans (DDD) och Martin Fowler så handlar deras arbete väldigt mycket om enterprise-arkitektur (som du kanske vet har Fowler skrivit den viktiga boken "Patterns of Enterprise Application Architecture" och Evans bok handlar väldigt mycket om beroendebn till andra system och avgränsningar mellan (delar av) system). Så jag ser verkligen inte varför Agile skulle vara förknippat med små projekt utan externa beroenden. För mig tycks det tvärtom särskilt viktigt att jobba med korta iterationer, ha täta avstämningar, kommunicera mycket, skriva gott om tester och vara beredd på förändring just när man arbetar i sådan miljöer. Och inte att försöka täcka in alla eventualiteter i en gigantisk planeringsfas långt innan implementationen sker. (Om det nu är ditt alternativ, det är som sagt inte helt lätt att utläsa).

För att besvara din fråga ser jag inga motsättningar mellan arkitektoniskt långsiktiga mål och resultatet från korta iterationer, jag förstår faktiskt inte ens hur det kan vara ett problem. Kanske har det att göra med din syn på Scrum, att hur stories implementeras inte är intressant, men det anser jag vara en missuppfattning (om inte en nidbild :-)) av ramverket.

Okej, jag nappade tydligen på ditt bete ändå och kanske behövdes din ton för att denna diskussion skulle äga rum. Om nu något gott kan komma av den... :-)

Jag är förresten lite osäker på vad du menar med refactoring. Refactoring är ju "the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure" (Fowler, "Refactoring: Improving the Design of Existing Code"). Jag förstår inte riktigt hur det passar in i ditt sammanhang.

David Vujic sa...

Den där lekstugan som vi jobbar i (it-industrin) har lekt färdigt nu. Vi som förespråkar lättrörliga metoder är väldigt influerade av den riktiga industrin, nämligen bilindustrin.

Toyota, en av världens största biltillverkare och starkaste varumärken, bygger sin organisation med långsiktighet. Och ja, med lättrörliga metoder.

Jag förstår att diverse småpåvar känner sig hotade när den traditionella arkitektrollen tappar sin makt till förmån för ett team med gemensamt och individuellt ansvar. Men systemutveckling är inget enmansjobb, tyvärr.

Jonas Ekström sa...

Joakim, du får ursäkta om jag hoppar över att bemöta tramset och referenserna till diverse skrifter, som utgjorde ca 95% av inlägget.

Jag hoppar istället ned till sista meningen i ditt inlägg. Refactoring är enkelt uttryckt agila metoders räddning. Eftersom agila metoder jobbar scenariobaserat är det kanske inte så konstigt att gränssnitten kan bevaras mer eller mindre intakta under ett projekts livscykel.

Bakom spacklet däremot är det en svart låda där snabbaste möjliga vägen ofta blir resultatet av implementationen under en sprint. I små isolerade applikationsutvecklingsprojekt kanske det inte spelar någon roll, eftersom du inte behöver ta hänsyn till omvärldskrav - du kan ju alltid refactorera senare.

Efter ett antal iterationer ökar behovet av refactoring och då ska ramverk bytas ut, datamodeller normaliseras, klasser konsolideras och så vidare. Det svängrummet och den utvecklarlyxen finns inte när du bygger lösningar med externa beroenden och riktlinjer.

Jonas Ekström sa...

David du tar upp en annan aspekt av problemet med agila metoder. Du visar upp en bitterhet över ett dåläge som verkar bottna i att du inte fick vara med och leka bland de stora grabbarna.

Nu när agila metoder slagit igenom kan vilken cowboy-kodare som helst skaffa en picka och spela sheriff i stan. Yeehaa!

Joakim Sundén sa...

Tråkigt att du kallar det jag skrivit för trams och att du inte är intresserad av att diskutera. Då ska jag inte ödsla mer av din (eller min) tid.

Unknown sa...

Hej Jonas,

Jag skulle vilja veta vilket arbetssätt du föreslår om man inte arbetar för ett DotCom-företag.

Mvh Joakim Ohlrogge

Jonas Ekström sa...

Joakim O, den andra Joakim var också inne på problemet att föra en debatt om man själv inte har några alternativ till det man kritiserar. Det är det jag menar med att vara dogmatisk. Dvs att det finns bara en väg och det är den sanna vägen.

Självfallet finns det lika många angreppssätt på metodik som det finns permutationer av förutsättningar (företagskultur, plattform, organisation, sektor, mognad, etc). Det handlar om att välja metod efter förutsättningarna och jag tror att det finns tillfällen där agila metoder inte har de rätta effekterna. Där de genererar mer skada än nytta.

Jonas Ekström sa...

Joakim S, jag är intresserad av att diskutera, men inte om vilka kretsar jag rör mej i, att jag har en antagonistisk inställning eller uttrycker mej i pejorativa ordalag ... det var hela svenska akademins ordlista du fick in där föresten.

Det är heller inte intressant att diskutera dom heliga skrifter du refererar till. Fowler och Evans står mej upp i halsen vid det här laget.

Jag vill diskutera verkligheten med folk som släppt sargen och börjat åka skridskor. Jag tror mej förstå att du är en bland dom och då ska du väl inte behöva lyfta fram evangelium av dessa herrar, utan skriva utifrån dina egna upplevelser?

Det avsåg jag med trams och f.ö. så fortsatte jag med ett resonemang kring refactoring som jag gärna vill ha din input/reaktion på.

Med hopp om svar ...

Unknown sa...

Jonas Ekström skriver i det ursprungliga inlägget:

"Agila metoder går nämligen ut på att inte ta hänsyn. Scrum har exempelvis sina sprintar där man trycker in s.k. stories. Hur de implementeras är inte intressant, bara att dom implementeras."

och i en uppföljning till en kommentar:

"Bakom spacklet däremot är det en svart låda där snabbaste möjliga vägen ofta blir resultatet av implementationen under en sprint."

Den som agerar på det viset arbetar inte enligt Agile. Läs Agile Manifesto, i detta fallet framförallt den nionde principen:

"Continuous attention to technical excellence and good design enhances agility."

David Vujic sa...

Jag antar att du tycker att du är en av de "stora grabbarna" då.

Jag tror att du blandar ihop Scrum och testdriven utveckling. Vi som utvecklar testdrivet låter systemdesignen växa under projektet. Där stöter vi ibland på protester från Den Store Powerpointarkitekten/Påven. Scrum är inte lika med mjukvaruutveckling, du kan driva en frisörsalong med Scrum om du vill.

Påven: varför ska man ta avgörande designbeslut när man har som minst kunskap om lösningen, dvs innan eller i början av ett projekt? Det verkar ganska korkat.

Om du arbetat testdrivet så hade du snabbt upptäckt att det inte har något alls med vilda västern att göra, snarare tvärtom. Gillar du inte kvalitet?

Jonas Ekström sa...

Nils,

Det är alltid kul med folk som refererar till olika texter som om de vore heliga. Ännu roligare är det då man börjar skapa tolkningar av texterna för att de ska passa in i alla sammanhang. Känns det igen? Fundamentalism, dogmatism, kallas det för och det är det jag försöker påpeka i min blog.

Btw Jag skrev på Agile Manifesto för fyra år sedan och står för det. Jag anser inte att det är fel på agila metoder, men de passar inte in i alla typer av sammanhang.

Jonas Ekström sa...

David,

När du säger "när man har som minst kunskap om lösningen". Det är ju det som är grejen att arkitektens ansvar är att just förutse förmågor i arktiekturen under ett livscykelperspektiv. Har man inte den kunskapen är man inte arkitekt och då ska man inte sura över det utan förhålla sig till dennes aktoritet och rätta in sig i ledet.

Jag skämtar bara med dej, men faktum är att jag tror att du överskattar dej själv och underskattar komplexiteten i vissa projekt. Det kommer med åren ... snart får kanske även du installera powerpoint.

David Vujic sa...

Aha, så du menar att Arkitekten kan se in i framtiden?

Skapar man sina fina klassdiagram och modeller innan man börjat är det en ren gissningslek och dessutom lämnar man kravspecifikationen i samma ögonblick, till förmån för modeller som redan efter en vecka blir inaktuella.

Framtiden är oviss och krav förändras, det har andra branscher sedan länge insett och trevligt nog även många av oss i it-industrin. Vi som jobbar lättrörligt och testdrivet välkomnar förändring, det är ju inbyggt i själva processen.

Jonas Ekström sa...

David,

Jag tror kanske vi pratar om varandra en aning. När jag säger arkitekt så menar jag någon som jobbar långsiktigt på en IT-avdelning inom en viss logisk enhet (CRM, ERP, ECM, etc) eller en arkitekt som arbetar med mål och förmågor som går på tvären genom de logiska enheterna (säkerhets policies, SOA infrastruktur, BPM, MDM, etc). Jag avser inte den person som får till uppgift att designa en ny extern webplats. Det är en utvecklarroll och inte en arkitektroll. Arkitektens uppgift är att sätta upp ramarna för projekten och se till att de förhåller sig till långsiktiga mål definierade av en IT-organisation eller en CIO-organisation.

David Vujic sa...

Men vad menar du då med att "agila" metoder inte tar någon hänsyn, vilda västern etc.?

Det du skriver i din kommentar ovan är ju krav som ska ge någon form av affärsvärde. Krav är det som styr lättrörliga projekt. För att uppfylla dessa krav bryter vi ner dem till mindre och konkreta delar och levererar dessa i iterationer. Där varje leverans är en testbar produkt.

Var ser du motsättningen?

Jonas Ekström sa...

David,

Lättrörliga projekt och agila metoder bygger på korta iterationer för att kunna jobba efter ett mål som anses vara rörligt. Vad gör målet rörligt?

Det är lite relativitetsteorin över det hela. Målet är nämligen rörligt ur vissa personers (utvecklarnas) betraktelse, medan det i andras inte upplevs rörligt. Där ser man snarare rörigheten än rörligheten i användningen av agila metoder bland utvecklare.

Agila utvecklingsmetoder tenderar ofta även användas i det syftet att man inte vill eller kan förstå kraven, snarare än att de förändras med tiden.

Det är en del i motsättningen, men det finns en annan som jag försökt få fram ovan. Nämligen att man under en iteration försöker skapa något som ska kunna betraktas som en intakt leverans och kunna demas.

Just den strävan efter leverans kommer skapa scrum masters som inte tar hänsyn till externa faktorer, utan fokuserar på gränssnitten och testbarheten istället för vad som produceras under skalet.

När tillräckligt mycket krav har kommit in trängs man in i en återvändsgränd och tvingas till refactorering och omskrivningar som kunde förutses om man inte tvingat sig in i korta iterationer med leveransmål enligt ex scrum.

David Vujic sa...

Krav förändras och framtiden oviss, det är min och många kollegors och beställares erfarenheter av många projekt genom åren. Där har du rörligheten.

I projekten träffar vi beställaren och ställer frågor och får feedback. Flera gånger. Under hela projektets gång. Skulle vi ha misstolkat krav så upptäcks det redan efter första leveransen, inte ett år senare.

Scrum och andra lättrörliga metoder bygger till stor del på flera människors kunskaper, tvärfunktionella team, hellre än en ofta självutnämnd expert. Denne expert har också oftast fokus på annat än affärsvärde. Ett team med ständig kommunikation med beställare har betydligt större chanser att möta beställarens krav, det är min erfarenhet.

Unknown sa...

Helig är inte ordet jag skulle använda, MEN Agile Manifesto definierar vad Agile är. Den enda dogmatism jag ser kommer från dig Jonas. Men för att återgå till min poäng så ligger bördan på dig att förklara varför principen om technical excellence inte är tillämpbar i detta fallet.