Lean-utveckling handlar i mångt och mycket om göra lagom mycket arkitektur ”up front”, att ta svåra beslut sent, bara utföra arbete som addera värde mm. Detta i kombination med DCI där man tydligt separerar Data (domän) från Context (use cases) och Interaction (Roller) ger en kraftfull mix av användarupplevelse och tillräckligt kraftfull arkitektur för utveckling. Jim Coplien engagerade och underhöll under hela dagen.

Brian Sletten visade hur REST/ROA ger oss möjligheter att arbeta med vår data på helt nya sätt. Dessutom snabbt ( datan kan göras cachebar). Och enkelt (web-baserade protokoll för integration). Den semantiska webben är på gång (igen), den här gången med ROA och REST som drivkrafter. Brian imponerade med demonstrationer av enkelhet och kraftfullhet i Restlets och Netkernel. Mycket av detta finns att läsa om i Roy Fieldings avhandling från 2000: Architectural Styles and Design of Network-based Software Architectures.

Mer från QCon kommer!

/Emil & Stefan

Det är Typemock som intervjuar Andy under SPC09.

Min första reflektion är att Computer Swedens rapportering kring Scrum har vissa likheter med kvällspressens dito kring Svininfluensan. Överdriven skrämselpropaganda är vad det är!

Man skriver redan i ingressen att Scrum ofta är kontraproduktiv enligt flera experter på agil utveckling. Man låter vidare några (andra) experter inom området yttra sig, men efter att ha i dagarna tre lyssnat just till dessa experter, så har jag svårt att tänka mig att kontraproduktivitetskritiken kommer från dem. Jag kommer inom kort återkomma med referat från dessa experters, för övrigt lysande, sessioner på Øredev.

Att komma underfund hur enkelt och självklart Scrum egentligen är tar förvisso sin tid, men vad finns det för bättre alternativ? De agila arbetsätten är ju fullständigt överlägsna tidigare metoder på så gott som alla plan. Alla organisationsförändringar kräver förändringsledare, så också införandet av Scrum. Undersökningar visar att 75% av alla projekt som saknar en agil förändringscoach fallerar.

Vidare kommer det ju inte som en direkt överraskning att någon ur Scrum Alliance, i detta fall en av grundarna Ken Schwaber, hoppar av. Min uppfattning är inte att dessa personer är de frommaste skolgossarna i världen direkt. De här är ju personer med mycket starka och ibland extrema åsikter. Vore nästan konstigt om de var rörande överens om alla detaljer.

Det som jag däremot kan hålla med om är att Scrum blivit en riktig hype, vilket känns lovande, där ”alliansen” drar in grova pengar på så kallade Scrum Master-utbildningar. Jag förstår ändå inte kritiken. Är det inte längre okey att tjäna pengar på efterfrågade utbildningar och certiferingar? Är det inte det PMI och IPMA gjort länge nu?

Jag följer den ihåliga kritiken i CS med spänning framöver. Men glöm inte att:

Scrum är svinlätt – om man kan det!

http://computersweden.idg.se/2.2683/1.267157/nu-vaxer-kritiken-mot-scrum

Men så till ämnet, varför fallerar införandet av agila arbetssätt och hur gör man istället?

De främsta orsakerna är:

• Dålig start,
• Bristfällig planering,
• Otillräcklig finansiering,
• Bristande kommunikation och
• Rädsla för förändring

För att komma till rätt med detta bör man:

• Vinna organisationens förtroende.
• Framhäv vad den enskilde har att vinna på det.
• Utbilda alla som finns i och kretsat kring projektet.
• Känna till vad förändring innebär, se SatirChange Model.
• Använd agila coacher (75% av projekten som saknar coacher misslyckas).
• Inför automatiska byggeni projektet (Continuous Integration).
• Inför automatiserade tester.
• Teamet testar det de anser relevant, inte det som står i ev. testfall.
• Bli bra på att skapa user stories.
• Bryt ner större funktionsområden i user stories.
• Användsmå user stories.
• Använd 1 vecka korta sprintar.
• Identifiera vad som går att göra bättre.
• Förbättra processen fortlöpande.
• Var transparent mot omvärlden.
• Gör ”quick wins”.
• Starta smått.
• Involvera ledning och asärskild personer som innehar ”stödfunktioner”, som ex. Configuration Management.
• Anpassa Human Resources-funktionerna efter agila arbetsätt.
• Uppdatera styrtalen så att se avspeglar detverkliga resultatet snarare än insatsen.
• Arkitekterna ska ingå i teamen.
• Inför incitament att dela med sig av kunskap.
• Teamen ska vara multifunktionella, där arkitekten ingår.

Ett föredrag bli inte effektivare och roligare än så här. En lysande dragning!