Jason Fried á Business of Software ráðstefnu

Horfði nýlega á þennan skemmtilega fyrirlestur Jason Frieds sem er einn eigenda eins af uppáhalds fyrirtækjunum mínum, 37signals.

Fyrirlesturinn hans er strúktúreraður þannig að Jason eyðir fyrri hálftímanum í að úttala sig um nokkra punkta sem honum þykja mikilvægir. Seinni hálftíminn er svo Q&A. Mæli sérstaklega með fyrri hlutanum og langar að nefna nokkra af punktunum hans og spá aðeins í þeim.

• Skriðþungi (e. momentum). Jason segir að hjá 37signals sé öllu sem þeir þróa skipt upp í lítil verkefni sem hægt er að klára á stuttum tíma svo hægt sé að nýta skriðþunga stemmningar, spennings og vilja fólks til að klára verkefni. Fyrir mér var þetta enn einn plúsinn í kladdann fyrir ítrunarþróun Agile aðferða. Fólk finnur fyrir þessum skriðþunga, afkastar meira og klárar það til enda - sem er gott ;)
• Út með kröfulýsingar. Það kemur þeim sem eitthvað þekkja til Spretts lítið á óvart að hér erum við algjörlega sammála Jason. Það sem ég hafði ekki heyrt áður er hvernig Jason lýsir þess konar skjölum sem já-skjölum! Það sem hann á við er að skjölum eins og kröfulýsingum er svo auðbreytt: "Já, góð hugmynd að fítus. Bætum við setningu fyrir hann í skjalið". Að bæta fítus við í skjal tekur mun minni tíma en nokkurn tíma að útfæra fítusinn í alvöru vöru! Þess vegna er svo auðvelt að segja alltaf já við hvaða hugmynd sem er þegar ekki þarf að hugsa alla leið.
• Truflanir drepa framleiðni. Já, en þar sem ég átti bágt var þegar Jason lýsti því yfir að því minna augliti-til-augliti samneyti sem teymi hafa, því meira kæmu þau í verk! Ok, ég tel mig skilja rök hans, sem eru að skv. þeirra reynslu fer framleiðni þeirra niður þegar þeir eru of mikið á sama stað vegna þess að þeir eru sífellt að trufla hvern annan. Ég er sammála Jason að þetta sé staðreynd þegar meðlimir teymisins eru að vinna að mismunandi verkefnum, hafa allir sitt sérsvið sem enginn annar fer inn á, vinna aldrei í pörum og þurfa ekki mikla hjálp hvers annars. Mín skoðun er hins vegar sú að samhent, sjálfstýrandi teymi fólks sem vinnur að sama markmiði, í pörum (þegar við á), á sama stað og getur gengið í verk hvers annars geti orðið margfalt framleiðnara heldur en hópur einstaklinga.
• Fókuseraðu á það sem ekki breytist. Ef við fókuserum á að gera alltaf nýjasta nýtt með vörurnar okkar missum við að miklum tækifærum til þess að gera það sem skiptir mestu máli til langframa fyrir þær. Það sem skiptir máli í vörunum okkar er það sem gerir það í dag og eftir 10 ár! Skoðiði ykkar bissness og finniði út hvað það er sem fólk mun alltaf vilja frá ykkur og fjárfestið í því, ekki bara endalausum nýjungum.

Þetta eru aðeins 4 af punktunum hans Jasons og ég ætla ekki að spá í fleirum hér en hvet ykkur aftur til að kíkja á þennan fyrirlestur.

03.11.2008 | Comments [3]
Flokkur: Stjórnun
Höfundur: Daði Ingólfsson

Áhugaverð blogg úr Agile heimum #3

Það sem vakti helst athygli mína í Agile bloggheimum síðan síðast:

• Project Automation eftir Naresh Jain - Naresh um hvað hann telur þurfa að sjálfvirknivæða í hugbúnaðarverkefnum
• Agile RFP sería eftir Peter Stevens - Peter er búinn að skrifa fyrstu tvo partana af þessari seríu og eru þeir báðir mjög áhugaverðir - sérstaklega fyrir þá sem eru annað hvort að bjóða hugbúnaðarverkefni út eða taka þátt í útboðum
• Kanban Systems eftir James Shore - Einstaklega skýr og upplýsandi grein um hvað Kanban, hvernig teymi eru að nota það og hvað Jim líkar við þess konar vinnulag. Mæli líka með kommentunum frá lesendum.
• The new user story backlog is a map eftir Jeff Patton - Hef nú bloggað um "story mapping" hugmynd Jeffs áður og í þessari grein fer hann vel í gegnum hana
• Jeff Sutherland's Sprint Emergency Landing Procedure eftir Dean Leffingwell - Dean að fjalla um nokkuð sem Jeff Sutherland fór í gegnum á Agilis 2008 - varð bara að minnast á þetta þar sem Ísland og Sprettur koma fyrir í blogginu ;)

26.10.2008 | Comments [3]
Flokkur: Agile
Höfundur: Daði Ingólfsson

Að koma hlutum í verk

Verandi með nokkra hatta á höfðinu þessa dagana, svo sem "eiginmaður" og faðir, húseigandi, kennari við HR, fjármálastjóri Spretts, verktaki hjá Símanum og wanna-be hlaupari, og með nokkuð mikið að gera, þá var ég kominn í stöðu sem kallast "thrashing" á tölvumáli. Thrashing er það ástand sem örgjörvar lenda í þegar nýting þeirra nálgast 100% í fjölvinnsluumhverfi, þ.e. að  undir vissum kringumstæðum þá fer meiri tími/orka í að skipta um verk heldur en í að vinna þau.

Hausinn á mér rúmaði ekki lengur neitt nema hluti sem ég þurfti að gera, og verulega stór hluti af minni orku og athygli fór í að skipta um verk, og of lítill í að hugsa um hvernig væri best að gera þau. Ekki lengur.

Ég "las" núna nýlega bók með því ágæta nafni "Getting Things Done" eftir David Allen, þ.e. ég hlustaði á hana sem hljóðbók, og ég verð að segja að þetta er einhver praktískasta bók sem ég hef lesið í seinni tíð.

Nokkrar öflugar hugmyndir úr bókinni:

 - Það að skrifa ekki niður það sem menn hafa í huga að koma í verk er eins og að halda öllu í RAM á tölvu. RAM er ekki hentugt sem geymslumiðill til lengri tíma. Vel skipulagt "todo" kerfi er eins og harður diskur sem losar vinnsluminni til að vinna að mikilvægari hlutum.
 - 2 mínútna reglan: Ef þú telur að taki minna en 2 mínutur að bregðast við áreiti (tölvupósti, hugmynd sem þú fékkst, bréf inn um bréfalúguna), þá skal gera það strax. Annars má íhuga að fresta því. 2 mínútur er u.þ.b. þröskuldurinn þar sem fer að verða dýrara að halda utan um verkið en að framkvæma það strax.
 - Skipuleggja innbox alls staðar þar sem áreiti á sér stað, minnisbók á ferðinni, á skrifstofunni og á tölvunni, og hafa nákvæmlega eitt skipulagt kerfi þar sem maður flokkar inn atriði til að gera úr ÖLLUM innboxum.

Ég er kominn af stað að útfæra þetta kerfi, og finn greinilegan mun nú þegar á öllu vinnulagi hjá mér. Ég mæli því eindregið með þessari bók við alla þá sem hafa áhuga á að koma hlutum í verk. Til að auka skilvirkni í því sem menn eru að gera þá er þetta stórgóð bók.

Það er samt gott að hafa í huga að aukin skilvirkni (efficiency) er ekki endilega ávísun á meiri/betri áhrif (effectiveness)...

07.10.2008 | Comments [4]
Flokkur: Bækur | Sprettur | Stjórnun
Höfundur: Guðlaugur Stefán Egilsson

Áhugaverð blogg úr Agile heimum #2

Það sem vakti helst athygli mína í Agile bloggheimum síðan síðast:

• Micro-Design v/s Macro-Design v/s BUFD frá Naresh Jain - Naresh um mismunandi skala hönnunar (kóða)
• Should the Daily Standup Be Person-by-Person or Story-by-Story? - Mike Cohn með nokkra vinkla á daglega scrum-ið
• Husbanding willpower - Steve Freeman með merkilega færslu um viljastyrk og af hverju við eigum ekki að breyta öllu í einu þegar kemur að lífstíl eða vinnuaðferðum
• Is Distributed Development Viable - Jay Fields hefur skoðanir á og reynslu af dreifðri þróun
• red, green, refactor ...commit - Kevin Rutherford talar um hvar "commit" skrefið er í hans TDD ferli

01.10.2008 | Comments [2]
Flokkur: Agile
Höfundur: Daði Ingólfsson

Dude, where's my C# for the Java Virtual Machine?

 

C# 3.0 has gotten some great new features that are making the language so much more expressive. Two of my favorite are extension methods and lambda expressions. So now, people have started creating all kinds of crazy extension methods to the built-in type String and every other CLR class.

Last week I was working on this Java project and doing some logging as part of my work, and was getting rather annoyed by the idea of having to check the logging level just before every darn log statement. And then I remembered that the same was true for the .NET equivalent of log4j, but in C# you could do so much better. So I decided to sit down and get some C# lovin'. First, just to be sure that you dear reader understand what the issue really is, here is how typical logging is happening using log4net:

Now, that thing on line 4, that is the nasty check I was talking about earlier. It is there purely as an optimization in case the debugging level is set to something higher then "DEBUG" in which case, since the log statement will not be rendered anyway, the logging string will not be evaluated (you do not know how slow that RetrieveSlowData method is, looks pretty slow to me ;) ). So all in all, I understand the reasoning, it's just that I do not want to do it ;).

Enter extension methods! Without further ado here is my extension method for log4net:

So not a lot of code for the extension, basically just an overload of the Debug method which accepts a delegate as its only parameter. The new overload checks for the DebugLevel and only then invokes the delegate which is supposed to evaluate the log message.So let's see how it is being used:

So now looking at line 4 you can see there is no checking whether the debug level is "in scope". What you can also see in line 4 is the other new element introduced in C# 3 that I mentioned earlier - lambda expressions. They can be automatically converted to delegates and are extra terse and I think that's what makes this approach feasible. This one has no parameters, thus the strange looking opening and closing braces before the "=>" signature.

With a little bit more effort one could easily add an exception parameter and implement all this for the other levels of logging. And all this without modifying the existing (dare I say ancient) log4net.

You might be wondering if I just put too much effort into saving me a line of code. For those of you who do, I just have to point out the following benefits:

• this line shows up way too often
• there is less noise in my code
• now I can free my mind from having to remember to put in this check
• it is always there, guaranteed

So, I wonder how long we will have to wait for JSR-666 that will introduce C# for the JVM ;)

26.09.2008 | Comments [6]
Flokkur: Forritun
Höfundur: Petar Shomov

Áhugaverð blogg úr Agile heimum

Það sem vakti helst athygli mína í Agile bloggheimum þessa vikuna:

• Observed Requirement frá Martin Fowler - Martin nefnir nokkrar nýstárlegar leiðir sem sumir nota í dag til að uppgötva hvað notendur vilja eða þurfa
• Tactical vs Strategic misses the point - Jason Yip talar um sínar skoðanir á hönnun sem hugsar út fyrir einstök verkefni og hönnun sem hugsar einungis um einföldustu lausn núverandi vandamáls
• It's not my fault, it's the vendor's fault - Jason skrifaði líka kjarnyrta færslu um samninga þar sem verð, tími og umfang eru meitluð í stein og hvar raunveruleg áhættan í þeim liggur
• The Equipoise of Agile - Israel Gat skrifaði þessa mögnuðu færslu um jafnvægislistina að hjálpa fyrirtæki að umbreyta sjálfu sér til að vinna eftir nýjum aðferðum og hugsa innan nýrrar hugmyndafræði

21.09.2008 | Comments [0]
Flokkur: Breytingar | Stjórnun
Höfundur: Daði Ingólfsson

Hverju eigum við að brenna?

Þau teymi sem vinna sína vinnu í sprettum/ítrunum þekkja flest svokölluð brennslurit, ekki satt?!?! Jæja, kannski ekki íslenska heitið en það sem á ensku kallast burndown chart. Þegar teymi vinna í sprettum inniheldur sprettsbackloggurinn (e. sprint backlog) sögur sem oftast eru í stærðarmældar í sögupunktum og tæknileg verk (e. technical task) sem mæld eru í ótrufluðum klukkutímum. Vaninn er að fylgjast með því hversu vel teyminu vindur fram innan spretts með því að plotta á línuriti tímana sem eftir eru miðað við dagafjölda spretts. Dæmi má sjá hér að neðan um brennslurit spretts.

Eins og sést þá má nota svona rit til að sjá, gróflega, hvort það sem teymið skuldbatt sig til að gera á áætlunarfundi sprettsins muni klárast fyrir lok sprettsins. Þessi rit eru lýsandi, auðveld í uppsetningu og viðhaldi, og segja okkur oft meira heldur en verkveggurinn okkar (e. task board). Gallinn við brennslurit sem sýna brennda klukkutíma er að þau segja okkur ekkert um hversu margar sögur teymið er búið að klára til enda. Það má náttúrulega segja að samvinna brennslurita og verkveggja ætti að nægja til að segja teyminu og hagsmunaaðilum hversu vel gengur að klára eitthvað sem verður hægt að skoða/prófa/nota í lok sprettsins. Þroskuð Agile/Scrum teymi færa sig þó oftar en ekki yfir í að mæla sögupunkta frekar en ótruflaða klukkutíma. Eitt teymi sem ég hef verið að vinna mikið með á þessu ári er að prófa sig áfram með að mæla bæði, eins og sjá má á eftirfarandi ljósmynd.

Eins og sést glöggt á þessu riti þá var teymið að klára tæknilegu verkin sín nokkuð jafnt og þétt en sögurnar sjálfar voru ekki að klárast fyrr en undir blálokin. Þetta eru mikilvægar upplýsingar sem geta sagt okkur ýmislegt um teymið og að skoða svona rit í ferlisskoðun (e. retrospective) getur hjálpað teyminu að ræða um hvernig það ætli sér að gera tilraunir til að bæta sögubrennslu sína í næsta spretti svo það sitji ekki eftir með mikið af tæknilegum verkum kláruðum en ekkert til að sýna á demói.

Hver er ykkar reynsla af brennsluritum sem þessum? Hafið þið endað uppi með fullt af tæknilegri vinnu unninni en ekkert til að sýna vörueigendunum á demóinu?

17.09.2008 | Comments [0]
Flokkur: Scrum | Stjórnun
Höfundur: Daði Ingólfsson