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

Tískubólur

Já, hann Ívar hefur ýmsa fjöruna sopið. (6:02 mín)

08.09.2008 | Comments [2]
Flokkur: Stjórnun | Tækni
Höfundur: Pétur Orri Sæmundsen

Teymið sem minnsta vinnueiningin

Ég hef lengi verið þeirrar skoðunar að teymið eigi að vera minnsta vinnueiningin í fyrirtækjum í þekkingariðnaði. Af svo mörgum ástæðum er það ólíklegt til árangurs að vera með einnar-manneskju-verkefni og Johanna Rothman minnti mig sérstaklega vel á það í nýjustu bloggfærslu sinni. Eins og Johanna bendir réttilega á þá er það hreinlega ómögulegt að búa til kerfi sem geymir alla vitneskju forritara um eitthvað kerfi. Þess vegna er eina almennilega færa leiðin að vera með þverfagleg teymi sem hafa fókus á einu verkefni í einu, klára það og fara í það næsta, og koll af kolli. Þetta stjórnskipulag hefur m.a. í för með sér að:

• Vitneskjan er nú í mörgum hausum sem minnkar áhættuna á að þekkingin um kerfið hverfi
• Fólk fær skýr skilaboð um hvað skipti máli og getur einbeitt sér að einu í einu
• Stjórnendur geta ekki lengur hent hvaða verkefni sem er í gang þar sem teymi verður að vera til staðar til að vinna það
• Verkefni klárast! Í stað þess að dragnast með of mörg verkefni allt árið og reyna að "loka" þeim í árslok þá klárum við verkefnin eitt í einu
• Fólk vinnur og líður betur í teymum heldur en eitt út í horni (flestu alla vega...)

Eins og Johanna bendir á í þessu sambandi er að nú þarf fókus stjórnenda að færast frá því að hafa áhyggjur af því hversu fullnýttur tími starfsmanna er yfir í það að hafa áhyggjur af því hversu mörg virðisaukandi verkefni hvert teymi klárar. Þá förum við að hafa meiri tíma í hugsa um það hvað er virðisaukandi, hvað er það sem skiptir máli að teymin okkar vinni í. Það er í raun mun mikilvægara en nokkurn tímann hversu mikið er að gera hjá hverjum og einum í fyrirtækinu.

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

Agile developer tooling

If one picks any of the popular software development languages these days he could easily be dazzled by the wide variety of libraries and frameworks available for that language. In the Java world he would shortly after be also quite confused since most of these libraries take on the same problem but each one with its own little twist. That is especially evident when it comes to UI libraries and frameworks. But what I want to do here is not complain about the library-per-capita phenomena in Java land, but rather draw your attention to two specific (and rather well known) libraries and frameworks. The reason I want to do that is the smooth unobtrusive way they make it easy for me to develop the agile way.

The first one is the famous Spring framework. I noticed it has had quite the effect on my mindset while I am writing code. No longer do I worry about who and how exactly I'm going to get hold of those objects. I know it is not going to be a problem, so I just completely focus on the POJOs and when I have enough of them ready to do something meaningful, then I wire them up using Spring and the thing comes in motion very quickly. Another change in my mindset that is a direct result of using Spring I noticed is I started writing smaller, much more focused classes. I mean since now wiring them together is so easy I really started doing it relentlessly. The application ends up usually with just 2-3 lines of Spring specific code (that is when I am using the Dependency Injection container only, using other parts of the Spring framework is a different thing) so there are no strings attached really (no pun intended ;) . I find myself using the DI container part of Spring the most, but I use other parts of this excellent framework occasionally: AOP, Hibernate integration and just now - Spring Portlet MVC. These allow for using and learning the framework on-demand and gradually, no big bang knowledge transfer required. I really like it ;)

The other library I want to draw your attention to is the no less famous Hibernate. The database indifference it provides I find is not its most attractive feature (although I certainly do appreciate it). Hibernate was the first library I know that successfully implemented persistence ignorance, allowing me to write the core logic of the application with no concern for the database. Only after I had a prototype of the system, I decided to add "real" persistence to a database. With Hibernate it was really easy and more importantly the patterns that this library is encouraging go a long way towards creating maintainable applications. And if you are trying to explore Domain-Driven Design (as I am trying to do), Hibernate will fit right in.

One special note for guys who are doing development in .NET and Java. Since there are ports of both Spring and Hibernate to .NET, using these frameworks allows for really nice reuse of knowledge across platforms, something I personally have experienced since I come to Java from .NET.

24.08.2008 | Comments [2]
Flokkur: Forritun
Höfundur: Petar Shomov

Dagur 3 á Agile 2008

User Story Mapping með Jeff Patton

Ég var búinn að ákveða fyrir ansi löngu að mæta á þetta námskeið - alveg frá því Jeff kom upphaflega með tillöguna að því í febrúar síðastliðinn (valferlið á námskeiðum ráðstefnunnar var opið öllum í fyrsta sinn í ár).

Aðferðin sem námskeiðið gekk út á er ansi áhugaverð. Tilgangur hennar er að hjálpa Agile teymum að skilja markmið og þarfir notenda sinna, og að sjá skóginn fyrir trjánum þegar að notandasögum kemur. Jeff byggir þessa aðferð á "Goal-Task-Tool" módeli Don Norman. Hann aðlagar það módel fyrir hugbúnað eins og þessi mynd sýnir:

Út frá þessu módeli sjáum við að notandasögurnar okkar geta verið skrifaðar út frá "task" eða "tool" (Jeff notar reyndar orðið "feature" fyrir "tool" í hugbúnaðarþróun og á myndinni). Dæmi um "task" sögu væri

Sem áhugagarðyrkjummanneskja
vil ég grafa holu
svo ég geti plantað tré.

en "tool" saga væri

Sem áhugagarðyrkjummanneskja
vil ég fá skóflu
svo ég geti grafið holu.

Með þessu sýnir Jeff muninn á sögunum eftir því hvort við erum að horfa á hærra stigs markmið notandans eða lausnina sem við teljum að muni hjálpa honum að ná markmiðum sínum.

Jeff sýndi okkur hvernig hann notar "Goal-Task-Tool" módelið til þess að kortleggja kerfi með því að setja upp "web cam" sem hann beindi niður á borðið sitt, sýna myndina á skjátjaldinu og kortleggja kerfi sem einn sjálfboðaliði á námskeiðinu er að vinna með í sínu fyrirtæki. Þetta tók hann minna en 10 mínútur og var hann þá kominn með "kort" af helstu markmiðum notenda, hvaða verknað (e. activity) þeir þurftu til að ná markmiðum sínum og hvaða röð aðgerða/fítusa (e. tasks/tools) þeir þurftu að beita við verknaðinn. Greinilega ákaflega gott að greina kerfi með þessu módeli og mismunandi lituðum spjaldskrárkortum. Það sem Jeff gerir svo þegar hann er kominn með kjarnaaðgerðirnar er að brjóta þær meira og meira niður til að sjá hvernig hægt er að útfæra aðgerðirnar ítarlegar og ítarlegar.

Jeff talaði um ýmislegt fleira áhugavert, eins og að búa til "span plan", en það væri of langt mál að fara út í hér þannig að ég bendi áhugasömum á að fara í gegnum glærurnar hans.

From Concept to Backlog með Gerard Meszaros

Gerard hóf þennan fyrirlestur á því að ræða spennuna milli BDUF (Big Design Up Front) og LRM (Last Responsible Moment) innan Agile hreyfingarinnar. Það eru algeng byrjendamistök að halda að engin áætlanagerð, greining eða hönnun fari fram við upphaf verkefnis sem keyrt skal með Agile aðferðum. Gerard skiptir upphafinu í tvennt: þróun vörusýnar og áætlanagerð vöru. Hann fór svo yfir það sem hann gerir vanalega innan þessara tveggja skrefa með sínum teymum. Ætla nú ekki að lýsa öllu sem hann talaði um þar sem þið getið skoðað það sjálf hérna.

Það sem vakti helst athygli mína á fyrirlestrinum var það sem hann kallaði "Wizard of Oz Testing". Þessi aðferð hjálpar teymum að finna galla á flæði og hönnun notendaviðmóts helstu aðgerða verðandi kerfis á mjög ódýran hátt. Með því að eyða 2-3 dögum í að búa til einfalda pappírsfrumgerð af helstu skjáum kerfa hefur Gerard fundið margar grundvallarhugsanavillur í viðmótshönnun þeirra. Það gerir hann með því að taka þessa pappírsfrumgerð og fá til liðs við sig nokkra alvöru notendur sem prófa að nota frumgerðina í klukkutíma eða svo. Hann leikur svo tölvuna og skiptir út pappírsskjám eins og við á út frá skipunum þessara notenda. Einn til tveir aðrir samstarfsfélagar hans fylgjast með og skrá athugasemdir niður á blað. Með þessum einfalda hætti sannreynir hann fyrstu hugmyndir sínar um hegðun kerfisins strax í upphafi.

What Are They Doing? What A CIO Wants To Know From An Agile Development Team með Niel Nickolaisen

Hann er skemmtilegur fyrirlesari þessi Niel en mér fannst fyrirlesturinn hans nú kannski fjalla meira um hvernig er að vera CIO (Chief Information Officer), hvernig þeir hugsa og hvernig hann hefur kynnt Agile inn í sitt fyrirtæki frekar en hvað CIO vill fá frá Agile teymum. Alla vega, aðal skilaboðin frá honum voru að ef þú vilt nota Agile til að ná árangri þá skaltu tala um hvernig þú ætlar að skila viðskiptalegum árangri án þess að blanda Agile/Scrum/XP/... í málið. Talaðu um Agile grundvallarreglurnar, gildin og aðferðirnar þannig að fólkið sem þú þarft að hafa áhrif á finnist þú vera að tala um kunnuglega hluti. Það er ekki eins erfitt og það gæti sýnst þar sem Agile byggir á gömlum grunni sem útfærður er á nýstárlegan máta. Niel treystir á að það sem okkur finnst kunnuglegt, hræðumst við ekki og vitnar í Cockburn í þessu sambandi:

"We prefer the familiar to the comfortable and the comfortable to the better."

Niel tók undir með fleirum innan Agile hreyfingarinnar þegar hann sagði "ROI is an illusion"! Hann taldi upp nokkra punkta sem lýstu afstöðu hans til árangursmælinga. Hann sagði mælingar

• Þurfa að styðja við stefnu fyrirtækisins
• Eiga að vera fáar og auðskildar>
• Eiga að vera að mestu leyti ófjárhagslegar
• Eiga að notast til að betrumbæta ferla, ekki til að kenna fólki um!

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