Igår kväll tittade jag igenom mina anteckningar från Agila Sverige 2010 – vilka dagar! Jag är laddad med nya insikter, idéer och ett par schyssta punchlines att leverera vid tillfälle.
Några av favoriterna bland tiominuterstalen är Joakim Holms det STORA missförståndet, som handlade om att programmering inte alls är samma sak som tillverkning. Programmering är 100 % designarbete. Visst har du hört talas om den där husbyggarmetaforen? Det är snarare ritningen som vi utvecklar när vi arbetar vid datorn, vi bygger inte alls huset. Det gör kompilatorn och webbservern åt oss, eller hur?
Jag har redan följt Daniel Brolunds råd från hans tal Var en guldfisk och undvik kollaps: skriv ut en bild på en guldfisk och rådfråga den varje gång du vill lägga till ytterligare en if-sats i koden, kanske göra en till branch:ning i versionshanteringsträdet eller utveckla kod som kan behövas någon gång i framtiden. Vad skulle guldfisken tycka om det? Just nu tittar två förvånade ögon från en tecknad fisk på mig. Ok, I get the message. Undvik komplexitet, varje extra liten krånglighet är ett steg på vägen mot kollaps.
Marcus Ahnve tycker att vi ska kasta ut experterna och fokusera på helheten och jag tror att han har rätt. Vi har en expertkultur i vår bransch, där det ofta ses som orimligt att en och samma person kan vara duktig på databas OCH html! Det här innebär att många arbetar med samma sak i varje projekt, kan man då verkligen förvänta sig att individer tar helhetsansvar?
På eftermiddagarna var det öppet forum (Open Space) med längre diskussioner om ämnen med lättrörlig anknytning. Bland annat om hur en agil chef kan vara, tips och tricks på hur man arbetar för att bli ett bättre team och varför det ibland är svårt med förändringsarbete.
Vill du följa med nästa år?
Wednesday, May 12, 2010
Wednesday, March 3, 2010
In Swedish, kanske?
Varför är det så ovanligt att programmerare skriver kod på svenska?
Idag skrivs nästan all mjukvara in english, även hos företag som har svenska som huvudspråk. För en tid sedan slog det mig att IT-avdelningen kan vara den enda delen i en organisation som använder sina egna termer för att beskriva produkter och tjänster.
Är det verkligen bra?
Företagets språk - domän - borde kanske också återspeglas fullt ut i utvecklingen av mjukvara? Då blir det domändriven design* på riktigt.
Nackdelar?
Om företaget anställer en person som inte kan svenska lär det ta tid att förstå koden, ingen tvekan om den saken. Det blir en längre startsträcka, men som en bonus lär man sig terminologin som faktiskt används i hela organisationen.
Vanligare är kanske att man lägger ut hela sin systemutveckling utomlands. Då behöver alla verksamhetskrav översättas och i praktiken innebär det att företaget faktiskt byter språk (eller blir flerspråkigt).
Det finns ju inga tekniska hinder för att skriva kod med svenska tecken, men det kanske känns konstigt i början. Som att lära sig ett nytt språk? Ett tips: börja med att skriva enhetstesterna på svenska. Namn och beskrivningar går ju att sno rakt av från kravdokumentet eller postit-lappen på väggen. Hör av dig och berätta om dina erfarenheter!
* Läs mer om domändriven design (Domain Driven Design)
Idag skrivs nästan all mjukvara in english, även hos företag som har svenska som huvudspråk. För en tid sedan slog det mig att IT-avdelningen kan vara den enda delen i en organisation som använder sina egna termer för att beskriva produkter och tjänster.
Är det verkligen bra?
Företagets språk - domän - borde kanske också återspeglas fullt ut i utvecklingen av mjukvara? Då blir det domändriven design* på riktigt.
Nackdelar?
Om företaget anställer en person som inte kan svenska lär det ta tid att förstå koden, ingen tvekan om den saken. Det blir en längre startsträcka, men som en bonus lär man sig terminologin som faktiskt används i hela organisationen.
Vanligare är kanske att man lägger ut hela sin systemutveckling utomlands. Då behöver alla verksamhetskrav översättas och i praktiken innebär det att företaget faktiskt byter språk (eller blir flerspråkigt).
Det finns ju inga tekniska hinder för att skriva kod med svenska tecken, men det kanske känns konstigt i början. Som att lära sig ett nytt språk? Ett tips: börja med att skriva enhetstesterna på svenska. Namn och beskrivningar går ju att sno rakt av från kravdokumentet eller postit-lappen på väggen. Hör av dig och berätta om dina erfarenheter!
* Läs mer om domändriven design (Domain Driven Design)
Sunday, February 28, 2010
Twitter Design Pattern
På Twitter har man 140 tecken på sig att säga något, sedan tar det stopp. Texten ska helst vara läsbar, så frktngr får man vara sparsam med.
[raderna ovan innehåller 140 tecken]
Det jag speciellt gillar är att man som twittrare måste ta bort all onödig information för att kunna leverera korta meddelanden utan brus. Finns det här designmönstret på flera ställen?
ONE: #business
Ibland pratar man om att berätta hissversionen av ett förslag eller en affärsidé:
Vi levererar det stora företagets IT-kompetens med det lilla företagets själ och den enskilde konsultens engagemang.
[116 tecken]
Här i Sverige pratar vi ju inte med varandra i hissen, men vad sägs om twitterversionen?
TWO: #requirements
I den agila världen används redan Twitter Design Pattern, där man gärna skriver krav i form av User Stories. Många Scrum-team och beställare gillar kortfattade och tydliga beskrivningar av det som ska göras:
Som en redaktör vill jag kunna lägga till och ta bort nyheter på internetbanken, så att bankens kunder kan ta del av aktuell information.
[137 tecken]
TWEET: #programming?
Jag har inte sett några tydliga tecken på Twitter Design Pattern i utveckling av mjukvara ännu. Men tänk om vi bara fick skriva 140 tecken när vi programmerar fram en metod? Enligt designmönstret behöver jag (trots begränsningarna) skriva koden både läsbar och meningsfull, helst utan krångliga frKrtNgr. Vilken utmaning!
Jag tror att resultatet skulle kunna bli lika enkelt och tydligt som på Twitter:
man behöver ju sällan läsa tidigare tweets för att hänga med. Meddelanden är isolerade och externa beroenden tar man med som länkar, taggar och re:tweets (Dependency Injection, Interface och arv?).
Vilka fler områden finns det som skulle kunna följa Twitter Design Pattern, har du några exempel?
http://twitter.com/davidvujic
[raderna ovan innehåller 140 tecken]
Det jag speciellt gillar är att man som twittrare måste ta bort all onödig information för att kunna leverera korta meddelanden utan brus. Finns det här designmönstret på flera ställen?
ONE: #business
Ibland pratar man om att berätta hissversionen av ett förslag eller en affärsidé:
Vi levererar det stora företagets IT-kompetens med det lilla företagets själ och den enskilde konsultens engagemang.
[116 tecken]
Här i Sverige pratar vi ju inte med varandra i hissen, men vad sägs om twitterversionen?
TWO: #requirements
I den agila världen används redan Twitter Design Pattern, där man gärna skriver krav i form av User Stories. Många Scrum-team och beställare gillar kortfattade och tydliga beskrivningar av det som ska göras:
Som en redaktör vill jag kunna lägga till och ta bort nyheter på internetbanken, så att bankens kunder kan ta del av aktuell information.
[137 tecken]
TWEET: #programming?
Jag har inte sett några tydliga tecken på Twitter Design Pattern i utveckling av mjukvara ännu. Men tänk om vi bara fick skriva 140 tecken när vi programmerar fram en metod? Enligt designmönstret behöver jag (trots begränsningarna) skriva koden både läsbar och meningsfull, helst utan krångliga frKrtNgr. Vilken utmaning!
Jag tror att resultatet skulle kunna bli lika enkelt och tydligt som på Twitter:
man behöver ju sällan läsa tidigare tweets för att hänga med. Meddelanden är isolerade och externa beroenden tar man med som länkar, taggar och re:tweets (Dependency Injection, Interface och arv?).
Vilka fler områden finns det som skulle kunna följa Twitter Design Pattern, har du några exempel?
http://twitter.com/davidvujic
Thursday, October 15, 2009
My Job went to India...
Språk är en cool grej, tycker jag. Just nu ägnar jag mycket tid och energi åt att bland annat försöka förstå det här:
Ja, det är jättesvårt! Men också inspirerande och en ordentlig utmaning. Mindre inspirerande är att det i mjukvarubranschen inte precis uppmuntras till språklig mångfald. Inte när det handlar om programmeringsspråk. Häromdagen kunde man läsa en artikel om IT-folk som tycker att det är tufft att begränsa sig (se länk längre ned). En utvecklare, ett programmeringsspråk, en plattform?
Varför? Konkurrensmässigt blir man ju väldigt sårbar, både som person och som konsultföretag. Varför välja svenskar som levererar IT-lösningar när man kan välja väldigt många lika duktiga (men billigare) proffs utomlands? Expert betyder väl inte att man bara kan en sak?
Svenska IT-företag behöver folk som är flerspråkiga, det är en bra grej!
(artikel)
Ja, det är jättesvårt! Men också inspirerande och en ordentlig utmaning. Mindre inspirerande är att det i mjukvarubranschen inte precis uppmuntras till språklig mångfald. Inte när det handlar om programmeringsspråk. Häromdagen kunde man läsa en artikel om IT-folk som tycker att det är tufft att begränsa sig (se länk längre ned). En utvecklare, ett programmeringsspråk, en plattform?
Varför? Konkurrensmässigt blir man ju väldigt sårbar, både som person och som konsultföretag. Varför välja svenskar som levererar IT-lösningar när man kan välja väldigt många lika duktiga (men billigare) proffs utomlands? Expert betyder väl inte att man bara kan en sak?
Svenska IT-företag behöver folk som är flerspråkiga, det är en bra grej!
(artikel)
Sunday, April 26, 2009
Scrum på fem
- Scrum-metodiken skapades av Ken Schwa... Stopp!
- I det Agila Manifestet står det skriv... Stopp!
- I Scrum har man Sprintar, Backlogs och Burndown cha... Stopp!
Visst har man hört det där några gånger för mycket. Det är väl lagarbete och människor det handlar om? Scrum är ju inte särskilt mycket att hålla reda på, egentligen. Det är enkelt, konkret och borde gå att beskriva på fem.
Så:
1. Planeringsmöte med produktägaren.
2. Laget har ett eget planeringsmöte.
3. Perioden är igång (kallas för Sprint).
Laget arbetar med uppgifterna och har korta dagliga möten.
4. Perioden är slut och laget har en demo för alla som är intresserade.
En demo ger en ganska trevlig känsla av ett avslut och att det är dags att gå vidare till nästa del.
5. Till sist: laget har ett kort återkopplingsmöte.
Missa inte den här punkten! Det är här det händer grejer i laget.
Det var allt, det är det här som Scrum handlar om. Ganska enkelt, eller hur?
- I det Agila Manifestet står det skriv... Stopp!
- I Scrum har man Sprintar, Backlogs och Burndown cha... Stopp!
Visst har man hört det där några gånger för mycket. Det är väl lagarbete och människor det handlar om? Scrum är ju inte särskilt mycket att hålla reda på, egentligen. Det är enkelt, konkret och borde gå att beskriva på fem.
Så:
1. Planeringsmöte med produktägaren.
2. Laget har ett eget planeringsmöte.
3. Perioden är igång (kallas för Sprint).
Laget arbetar med uppgifterna och har korta dagliga möten.
4. Perioden är slut och laget har en demo för alla som är intresserade.
En demo ger en ganska trevlig känsla av ett avslut och att det är dags att gå vidare till nästa del.
5. Till sist: laget har ett kort återkopplingsmöte.
Missa inte den här punkten! Det är här det händer grejer i laget.
Det var allt, det är det här som Scrum handlar om. Ganska enkelt, eller hur?
Subscribe to:
Posts (Atom)