måndag, augusti 18, 2008

De små nyheterna...

I (som jag skrev om i mitt förra inlägg) skrev jag om att man efter att ha installerat SP1 för Visual Studio 2008 fick man tillgång till "Close All" när man högerklickar på en flik. Det visade sig att det stämmer inte alls...

Idag när min kollega Pär skulle köra "Close All" i Visual Studio 2008 efter att ha installerat SP1 upptäckte vi att den funktionen inte alls kommer från SP1 utan från reSharper.

Ytterligare kärlek till reSharper alltså!

tisdag, augusti 12, 2008

De små nyheterna som gör en lycklig!

Igår släpptes Service Pack 1 för Visual Studio 2008 och Framework 3.5 vilket självklart måste laddas ner och installeras. För en gångs skull hade jag inte installerat någon av betaversionerna vilket gjorde att installationen var helt smärtfri.

De stora nyheterna är att Entity Framework och ADO.NET Data Services är släppt men ibland är det de små nyheterna som gör en lycklig! Upptäckte precis att de nu har implementerat Close All när man högerklickar på en tab!!!

Tidigare har man antingen varit tvingad att välja Close All But This och sedan stänga det fönster som blev kvar alternativt gå till Window - Close All Documents. Men nu - vilken time saver!!

reSharper 4.0

Ibland är man efter sin tid men jag känner om och om igen att jag alltid är efter Mikael Deurells tid! Under många år har han pratat om sin kärlek till reSharper och jag vet att om några år kommer jag också att prata om DFO, PowerShell och production debugging. Men nu är det reSharper som gäller! Har precis installerat version 4.0 i min Visual Studio 2008 där jag jobbar i ett Visual Basic-projekt och visst... Det är kärlek!

Okej, i VB är den absolut inte perfekt. T ex så är den inte helt med när det gäller dess rekomendationer om Imports och LINQ och inte heller funkar Split declaration and assignment när man använder LINQ. Den missar nämligen att lägga in den line continuation som VB kräver. Men vad gör väl det när man får tillgång till refactoring som Extract Method...

fredag, augusti 08, 2008

Agila människor är speciella... Del 2

Igår kväll på avslutningsmiddagen för konferensen fick jag svar på vad de asiatiska dansarna gjorde. De var alla japaner som förberedde ett uppträdande på middagen. En av dem fick en utmärkelse från Agile Alliance och han tog med sig sina landsmän upp på scen och sjöng sången Dear XP.

torsdag, augusti 07, 2008

Agila människor är speciella...

Imorse när jag hade hämtat frukost och var på väg till en TDD-clinic i C# så gick jag förbi ca 20 asiatiska killar och tjejer som stod och dansade en dans, spelade i maraccas samtidigt som de kollade på en skärm. Exakt vad de gjorde där kl åtta på morgonen är för mig fortfarande en gåta men de var i alla fall glada!

Det som man ser på den här konferensen är att folk som jobbar med agile utvecklig är helt klart passionerade för det de gör!

Vad betyder affärsvärde?

Jag har följt och varit inblandad i en tråd i ett forum på Pellesoft.se som handlar om vad värde betyder i ett agilt projekt. Man pratar hela tiden om att man ska leverera affärsvärde tidigt och ofta men vad betyder värde. Den enkla definitionen av affärsvärde är enligt mig ”något som beställaren kan använda i sin verksamhet för att tjäna pengar”.

En definition av värde som Tom och Kai Gilb har är:
Value is a perceived benefit: that is, the benefit we think we will get from something. It’s is relative to a stakeholder.

Alltså värde är något som är relevant för en intressent och som den intressenten uppfattar som en fördel.

Om man sedan pratar om affärsvärde så måste man också definiera vem intressenten är och i en försäljningssituation pratar man om tre olika typer av köpare:

Ekonomisk: Den ekonomiska köpare är den som skriver under kontraktet, ser till att projektet får de ekonomiska resurser det behöver och den enda person som kan säga ja till ett projekt.

Teknisk: Den tekniska köpare är den eller de som ansvarar för att projektet eller produkten som köps in möter tekniska specifikationer och organisationens normer. Tekniska köpare kan säga nej till ett projekt eller en produkt.

Användare: Slutanvändare av en produkt eller system. Kan också säga nej.

När man har slutfört en försäljning och fått ett signerat avtal är det allt för ofta som tekniska köpare och användare tar över projektet och den ekonomiska köparens behov (eller utlovat affärsvärde), samt hur de ska levereras, förbises.

Okej, så vidare till en definition av affärsvärde:
Business Value is the perceived benefit the Economic Buyer (and ideally the organization) will get from making investments to improve something of importance to them.

Äffärsvärde är alltså, precis som värde, en uppfattad fördel som den ekonomiska köparen kommer att få ut av en investering.

Hur mäter man då affärsvärde? Affärsvärde kan vara svårt att mäta direkt men det kan mätas om man använder en teknik som kallas Measurable Objectives. Därför kan vi säga att vi levererar affärsvärde om vi är på väg att uppfylla den ekonomiska köparens mätbara mål. Dessa mätbara mål bryts sedan ner till features som implementeras i systemet och varje feature uppfyller en eller flera av de övergripande målen.

Jag var på en presentation idag av Ryan Shriver, www.theagileengineer.com, och vi gjorde ett antal övningar runt Measurable Objectives vilket var väldigt intressant. Han hade även beräkningar där man kunde avgöra hur väl olika features man planerar att implementera uppfyller målen och vilken relation det finns mellan kostnad för implementationen och levererat affärsvärde. Detta kan man sedan då använda för att avgöra om man ska implementera feature A eller B.

onsdag, augusti 06, 2008

Agile estimering och plannering

Tidigare har jag förespråkat att använda T-shirt sizing när man estimerar produktbacklog och sedan story points till sprintbacklog-tasks men efter att ha lyssnat på Mike Cohn idag så får jag nog tänka om! Visserligen ska man inte ändra det som funkar och i de projekt jag har varit med så har det fungerat riktigt bra. Men de nackdelar med t-shirt sizing som han tar upp går ju inte att bortse ifrån.

Ett problem är att använda M, L och XXL när man estimerar features på produktbackloggen är att man inte kan addera dessa tillsammans och en kund kommer alltid att vilja veta när man ska vara klar med ett projekt. Att då svara att vi är klara om 4 small, 3 medium och 2 large funkar inte. Man måste ha estimat som går att addera så att man kan ta reda på vilken hastighet man har och därmed också kunna säga när i tiden man kommer att vara klar.

Så vad Mike föreslår är man ska använda story points när man estimerar de items man har på sin produktbacklog. Den typen av estimering gör man normalt innan första sprinten när man gör sin releaseplanering. Man bör försöka komma igenom hela produktbackloggen men inte lägga för mycket tid på varje item (ca 20 i timmen bör man klara av). Nya items kommer att komma in på produktbackloggen kontinuerligt så därför måste man också kontinuerligt estimera under varje sprint. För att estimera produktbacklogen funkar det alldels utmärkt att använda sig av Planning Poker och då behöver man heller inte konverera sina estimat till timmar.

När man sedan ska planer det jobb man ska göra i första sprinten måste man veta vilken hastighet teamet har. Om man har ett team som har genomfört ett antal sprintar är det ju inget problem men om man har ett nytt team så finns det även tekniker för att ta reda på vilken hastighet teamet kommer att ha. Hastigheten baserar man då på hur mycket teamet tror att de kommer att kunna hinna med under nästa sprint och använder det som teamets hastighet.

När teamet sedan ska bryta ner features från produktbackloggen till uppgifter i sprintbackloggen måste uppgifter mätas i ideala timmar. Vi har gjort så att vi har spelat planning poker och satt story points på uppgifterna och sedan räknat om dessa till ideala timmar. Jag frågade Mike vad han tyckte om det och han sa att det är nog i det läget bättre att göra det ”the old fashion way” och bara sätta timmar på de olika uppgifterna. Jag har alltid förespråkat att man ska, även på uppgiftsnivå, dra nytta av allas input i estimaten men Mike menar att om man har en databasexpert i temat som säger att en uppgift tar fyra timmar så är det bara att sätta fyra timmar på den uppgiften. Att implemntera en feature på produktbackloggen blir mest troligt ändå flera olika uppgifter, tex att skapa en stored procedure, att modifiera objektmodellen, att anpassa gränssnittet samt att testa de olika delarna. Och då är det bäst att de olika experterna för de olika områdena får sätta timmar på uppgifterna.

Det jag tror att jag kommer att ta med mig till mitt nästa projekt är att lära mig mer om user stories för att få en bättre produktbacklog. Estimera produktbackloggen mha planning poker i story points och sedan bryta ner den till tasks i sprintbackloggen och direkt sätta optimalatimmar på dessa.

Man blir så lycklig när man känner att bitar faller på plats! Nu måste bara se till att också uppdatera min kurs :-D

söndag, augusti 03, 2008

Agile 2008

På plats i Toronto och imorgon börjar konferensen Agile 2008. Bor på 24de våningen och idag väcktes jag av ett falskt brandalarm från 15 våningen. Lite lätt jet-laggad kunde jag inte somna om så nu tänkte jag bege mig till Torontos stora turistattraktion – CN Tower med världens högsta, av människan skapade, observatorium.

Har för övrigt lite problem med att få ström till min dator. Igår köpte jag en konverterare på Best Buy och den funkade ju bra, till allt utom min dator. Datorn har en bredare kontakt… Någon som har nått tips på var man kan köpa en som funkar även till datorsladdar?

Annars så ser jag väldigt mycket fram emot att konferensen ska dra igång imorgon! Ska bli skönt att få lite mera kolla på läget för än så länge har jag ingen aning om var de olika föreläsningssalarna ligger. Nåja, det löser sig nog och då kan jag se fram emot föredrag under veckan av så väl Mary Poppendieck och Mike Cohn!

(I mitt förra inlägg sa jag att mitt nästa inlägg skulle handla om min första erfarenhet från verkligheten med LINQToXML men det får vänta tills jag kommer hem.)