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

Dagur 2 á Agile 2008

Value-Stream Mapping með Alan Shalloway

Hóf daginn á þriggja tíma námskeiði hjá Alan. Ansi klár kallinn enda búinn að vera 38 ár í hugbúnaðarbransanum! Alan er mikill áhugamaður um og hvatamaður fyrir Lean hugmyndum og byrjaði raunar á því að kvarta undan því að Agile stefnuyfirlýsingin skuli segja "fólk og samskipti umfram ferli og tól". Ástæðan er sú að hann vill meina að fólk geti ekki virkað almennilega saman án góðra ferla og þykir honum því miður að minna sé gert úr ferlum í textanum. Hvað um það...á þessu 3 tíma námskeiði fórum við djúpt ofan í kortlagningu virðisstrauma. Alan fór ofan í fræðin á bak við aðferðina, tilgang og tók dæmi um niðurstöður slíkrar kortlagningar hjá hans kúnnum. Svona kortlagning hjálpar okkur að sjá heildarflæðið frá því að einhver fær hugmynd þangað til henni hefur verið umbreytt í eitthvað sem gefur fyrirtækinu og kúnnum þess virði. Gerðum æfingu saman í þessu sem var mjög skemmtilegt og áhugavert. Hans reynsla er sú að í allir sem gera þetta fyrir sitt ferli fá eitthvað áhugavert út úr því og sumir sjá allt í einu einhvern stað í ferlinu þar sem gríðarleg sóun eða töf á sér stað. Í æfingunni sem ég gerði með borðfélögum mínum, þar sem einn þeirra leiddi okkur í gegnum hans ferli, sáum við t.d. að bara það að komast frá ákvörðun um nýtt kerfi að fyrsta spretti í þróun þess tekur vanalega um 3 mánuði!!! Í hröðum heimi dagsins í dag eru 3 mánuðir ansi mikið bara til að komast af stað.

Alan sagði svo ýmislegt sem mér þótti áhugavert á námskeiðinu sem ekki endilega er beintengt kortlagningu virðisstrauma (vitna óbeint og þýði eins vel og ég get):

• Toyota gengur alltaf út frá því að þeirra vöruþróunarferli sé það allra besta á hverjum tíma. Þeir segja: "Af hverju skyldi maður gera eitthvað sem maður veit að er EKKI besta leiðin?"
• Að nota lækkun kostnaðar sem leiðarljós í stjórnun er versta stjórnunaraðferð sem til er! Úr því verður vítahringur þar sem gæði, hraði og mórall starfsmanna minnkar stöðugt. Lean leiðin er að þróa allt í hæstu gæðum sem gerir þér kleift að þróa stöðugt hraðar sem lækkar kostnað og eykur tekjur.
• Skilgreining Alans á viðskiptalegu gildi er: 1) Það sem kúnninn vill/þarf og 2) öflun þekkingar á því sem kúnninn vill/þarf.

Politics of Backlog Management með Luke Hohmann

Þetta námskeið byrjaði á því að Luke las upp email sem hann fékk frá Rachel Davies þar sem hún minnti alla námskeiðshaldarana á það að þau námskeið sem sögð voru "workshop" ættu að ganga mest út á samskipti þeirra sem mættu. Að því sögðu bað hann okkur að henda fram hugmyndum um umræðuefni tengd titli námskeiðsins. Ég valdi að fara á borð þar sem umræðuefnið var innri og ytri hagsmunaaðilar og þeirra aðkoma að backloggnum. Mér fannst ekki margt nýtt koma í þeirri umræðu og í minnisbókinni minni eru bara komment sem komu frá öðrum borðum í kringum mig:

• Eitt borðið ræddi það hvort gegnsæinu inn í ferlið þyrfti að vera stillt í hóf eftir aðstæðum og voru menn mjög á skiptum skoðunum. Þeir sem vildu "ritskoðun" vildu hana vegna þess að sumir settu persónulega vegferð fram fyrir viðskiptahagsmuni eða vegna þess að of miklar upplýsingar gætu leitt til rangrar forgangsröðunar. Aðrir, eins og ég, vildu meina að í tiltölulega þroskuðu umhverfi ætti að gera tilraunir með öll gögn en það sem helst skipti máli væri að gögnin væru í réttu samhengi fyrir viðkomandi.
• Annað borð fjallaði um hvernig of mikil áhersla á skammtímamarkmið kæmi niður á langtímamarkmiðum fyrirtækis og hvernig mögulega væri hægt að eiga við það. Ráðin voru t.d. að gera vörueigendum grein fyrir neikvæðum áhrifum "legacy code"; að segja kúnnum sem senda inn beiðnir um nýja virkni eða villulagfæringar hvað þú ætlir að gera OG hvað þú ætlir ekki að gera; að sjá til þess að stórar tækni- eða hönnunarbreytingar í kerfinu komist inn á vöruvegvísinn (e. product roadmap).

A Framework For Agile Leadership með Todd Little og Pollyanna Pixton

Ágætisfyrirlestur um hlutverk leiðtoga og nokkur ákvörðunartól sem þeir geta nýtt sér. Til að leiða fyrirtæki, deild eða teymi byrjar allt á því að vinna með fólkinu til að finna sameiginlegan tilgang þeirra allra. Módelið sem þau Little og Pixton fóru í gegnum er eftirfarandi:

• Gerið ráð fyrir breytingum
• Ýtið undir þróun nýrra hugmynda
• Ýtið undir samvinnu
• Fólk á sína vinnu
• Vertu áhrifavaldur

Ætla nú ekki að fara í smáatriðum í gegnum fyrirlesturinn en það sem mér þótti einna áhugaverðast var ákvörðunarmódel sem þau kynntu sem hægt er að nýta til að taka ákvarðanir um hvar á að eyða peningum og orku fyrirtækis. Með því hafa mörg fyrirtæki komist að því að þau eru að eyða hlutfallslega allt of miklum peningum í verkefni sem ekki hafa neitt með aðaltilgang fyrirtækisins að gera. Yfirleitt eru fyrirtæki aðeins með 1-3 vörur/þjónustu sem aðskilur þau frá öðrum fyrirtækjum. Sem dæmi út í loftið, ef Apple eyddi svipað mikið í rafræna skjalageymslukerfið sitt innanhúss og í þróun IPhone-sins þá er það augljóst að aðeins annað þessara verkefna er til þess fallið að hjálpa Apple til að ná aðalmarkmiði sínu og skilja sig frá samkeppnisaðilum. Þrátt fyrir þetta eru mörg fyrirtæki að stressa sig á því að vera með það besta á öllum sviðum án tillits til hvar sú fjárfesting staðsetur þau á markaði. Hér er mynd af módelinu:

Þannig að í "Differentiating" kassanum er aldrei meira en 1-3 verkefni í gangi þar sem miklir peningar og orka fer iðulega í að aðskilja sig frá öðrum á markaði. Það að rukka kúnnana sína er í "Parity", þ.e. við þurfum að geta rukkað kúnnana okkar en enginn af þeim myndi verða rosalega spenntur ef þú segðir þeim að þú værir með besta rafræna rukkunarkerfi í heimi! Eða rafræna skjalavinnslukerfi! Ekki nema þú sért í rukkunar- eða skjalavinnslubransanum.

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

Agile 2008 - The Wisdom of Crowds

Opnunarræða Agile 2008 var haldin af James Surowiki, höfundi "The Wisdom of Crowds". Eins og titillinn gefur til kynna, þá fjallaði hún um visku hópa, og getu þeirra til að leysa verkefni betur en færustu sérfræðingar í mörgum tilfellum. Hann fjallaði nokkuð um hvaða samsetning af hópum væri til þess fallin að taka góðar ákvarðanir, og hvers konar umhverfi þyrfti að vera til staðar til að styðja við slíka ferla.

Einna áhugaverðast fannst mér er að fyrirtæki eru farin að beita þessu til að leysa vandamál, og ein aðferð sem hann nefndi til þess voru svokallaðir "spámarkaðir", eða "prediction markets". Í þessu tilfelli er verið að nýta þá staðreynd að bestu formlegu aðferðir til að gera spádóm um atburð í framtíðinni, eru ekki jafn góðar og meðaltal ágiskana tiltölulega upplýsts hóps. Sem dæmi um notkun, er að spá fyrir um hvenær ákveðin vara í þróun verður tilbúin til sölu.

Einnig ræddi hann um gagnstætt fyrirbrigði, sem er þegar hópur af greindum einstaklingum geta tekið heimskulegri ákvörðun heldur en nokkur einn þeirra væri fær um sem einstaklingur. "Því meira sem þeir tala, því heimskari verða þeir". Sem dæmi um þetta talaði hann um innrásina í Svínaflóa, sem eftir á séð var heimskuleg ákvörðun í alla staði samkvæmt niðurstöðu opinberrar skoðunar á atburðarásinni sem hrinti því af stað. Undirliggjandi vandamál í þessu tilfelli er að allir aðilar sem koma að ákvörðunni eru búnir að ákveða fyrirfram hver niðurstaðan á að vera (það er, innrás skal gerð á Kúbu). Ráðið sem Surowiki gaf til að verjast þessu er að ef menn komast of fljótt að samkomulagi á fundi, þá eru menn að missa af einhverju mikilvægu, og ættu að fresta ákvörðun þar til einhver kemst að því hvað það er. Önnur leið til að orða þetta, er að til að taka góða ákvörðun, þá þarf að takast á um hlutina málefnalega. Þar getur komið að haldi að menn spili hlutverkið "lögfræðingur djöfsa" (devil's advocate) reglulega, svo lengi sem það er ekki alltaf sami aðilinn...

14.08.2008 | Comments [0]
Flokkur: Agile 2008 | Sprettur | Stjórnun
Höfundur: Guðlaugur Stefán Egilsson

Dagur 1 á Agile 2008

Í síðustu viku sóttum við tveir frá Spretti stærstu Agile ráðstefnu hvers árs, núna Agile 2008, og næstu daga ætla ég að skrifa stuttlega um það sem þar fyrir augu mín bar.

Rauði þráðurinn á fyrsta deginum hjá mér var viðskiptalegt gildi (e. business value).

Prioritizing for Profit með Luke Hohmann

Fyrsta sessionið hjá mér var ansi gott. Luke Hohmann (mæli með bókunum hans) leiddi skemmtilega blöndu af fyrirlestri og umræðum um "forgangsröðun til fjár". Það sem stóð upp úr fyrir mér voru ákveðnar fullyrðingar um mat viðskiptalegs gildis (e. business value) og yfirferð Lukes á þeim aðferðum sem hann notar til að hjálpa sínum kúnnum við forgangsröðun backloggs. Sjokk-setningin hans var: "Nobody prioritizes for ROI!". Hann gaf algjöran skít í það og bókina sem ég er hálfnaður með, Software by Numbers. Virkar vel í teoríunni, sagði hann, en ekki í praktík. Eitt af því sem Luke, og ráðgjafafyrirtækið hans, Enthiosys, hjálpar Agile teymum við að gera er að komast að þörfum notenda með "qualitative research" frekar en "quantitative". Með öðrum orðum, með sniðugum samskiptum við alvöru kúnna frekar en töluspám (ROI, t.d.). Ein aðal ástæðan fyrir þessu, segir Luke, er að útreikningar ROI geta verið erfiðar og tímafrekar, svo ekki sé minnst á óvissar, en "qualitative research" passar betur inn í hratt ítrunarvinnuferli Agile aðferða. Góð grein kom svo út á InfoQ á föstudaginn sem fer enn ítarlegar í þetta.

Business Value: The next iteration með Joe Little

Næst var það meira um viðskiptalegt gildi frá Joe. Ekki alveg eins skemmtilegt og sannfærandi og Luke en áhugavert að hoppa beint yfir í þetta því Joe trúir á ROI sem mat á viðskiptalegu gildi, ólíkt Luke. Talaði mikið um týpískar mælieiningar og aðferðir til að finna viðskiptalegt gildi: ROI, Kano, Lean Cycle Time, ... Væri gaman að heyra Luke og Joe spjalla.

Money for Nothing and Your Change for Free: Agile Contracts með Jeff Sutherland

Endaði þennan fyrsta dag á meistara Jeff Sutherland. Kallinn er skemmtilegur, hokinn af reynslu og fyllir mann enn meiri trú á það sem við í Spretti erum að gera. Hann talaði um hvernig hægt er að vinna útboð hugbúnaðarkerfa án þess að undirbjóða og vonast til að koma út í plús á "aukaverkum" - vel þekkt og skelfilegt fyrirbrigði. Segðu útboðsaðilanum sannleikann, segir Jeff, og notaðu Scrum sem skilyrði fyrir samvinnu. Jeff segir að samningsmódelið sem hann aðhyllist hvetji alla aðila til að klára snemma! Fer ekki út í smáatriði módelsins þar sem íslendingar fá tækifæri til að heyra kallinn lýsa þessu sjálfur á AGILIS 2008 í október sem Sprettur stendur árlega fyrir.

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

Tæknivitrun

Tókst loksins að byggja upp nógu mikinn kjark til þess að uppfæra iPhone-inn minn í útáfu 2. Sá svo sannalega ekki eftir því. Nýja útgáfan er mögnuð, svo mögnuð að ég fékk tæknivitrun.

Fyrsta vitrunin kom í Íslandsbanka þegar ég prófað MindManager og fékk nýja sýn á hvernig hægt er að vinna með og strúktúra upplýsingar á auðveldan hátt en mér fannst tólið keyra fram nýjar hugmyndir. Önnur kom þegar ég var á leiðinni heim frá Kaupmannahöfn og hitti litla frænda minn með iPod. Var búinn að heyra um iPod örugglega ári fyrr en hafði aldrei prófað. Stemningin sem fylgdi því að fara í gegnum 20 GB tónlistarsafnið hans og handleika gripinn var ógleymanleg. Sú þriðja kom þegar ég kynntist Confluence wiki-tólinu hjá Industria. Var búinn að vera nota Microsoft Sharepoint í nokkur ár og skildi þarna hvað Sharepoint var léleg græja (og samt allir að nota hana). Confluence var einhvern veginn akkúart, það sem ég vissi ekki að ég væri að leita að. Fjórða kom þegar í keypti iPhone á síðasta ári og leið eins og væri búinn að kaupa lítinn skammt af Minority Report framtíð.

Og síðan kom sú síðasta núna í vikunni þegar ég uppfærði stýrikerfið. Það að geta sett upp ný forrit í gegnum AppStore gjörbreytir græjunni; iPhone-inn er búinn að taka hamskiptum. Þetta er yndisleg græja :)

27.07.2008 | Comments [4]
Flokkur: Tækni
Höfundur: Pétur Orri Sæmundsen