Jag arbetar just nu med ett IT-förvaltnings-team där vi kör Kanban. Med en Kanban-tavla visualiserar vi arbetet och identifierar potentiella flaskhalsar. Vi arbetar löpande med problem, orsak och förbättring. Vi har den senaste tiden börjat arbeta med klasser på aktiviteter/tjänster.
Vi arbetar frekvent och övervägande med saker som har fasta leveransdatum. Vissa gånger har det stor betydelse för hela verksamheten att vi håller leveransdatum. Andra gånger är det snarare önskvärt från beställaren att det är klart ett visst datum. På en tavla med en stor och dynamisk backlog kan det vara svårt för beställare att prioritera när de måste hålla reda på alla leveransdatum och samtidigt hur viktiga det är att datumet hålls.
Kostnad
Vi tittar på vad kostnaden blir om vi inte levererar till utsatt datum. Kommer det kosta väldigt mycket eller finns det lite utrymme för justering av planerad leverans. För att tydliggöra detta använder vi nedan klassificeringar (Baserade på David J Anderson beskrivning av Classes Of Service) Vi har fritt översatt vissa ord och gjort en anpassning som passar oss.
- UTFÖR
Först och främst har en en utför-klass. Aktiviteter som klassas som utför ska påbörjas så fort som möjligt och vi ska lägga så mycket resurser vi behöver för att på snabbast möjliga sätt ta aktiviteten i mål. Vi har inte många men när dom kommer kan det handla om produktionsstörningar som gör att verksamheten inte kan utföra sitt arbete. Dessa rör sig i en prioriterad fil på tavlan. Går ej att planera, måste utföras direkt när dom dyker upp. - KRITISKT DATUM
Sen har vi aktiviteter som har ett kritiskt leveransdatum. Dessa aktiviteter har hög affärspåverkan om vi inte håller leveransen. Dessa aktiviteter är UTFÖR-aktiviteter men med skillnaden att leverandatum är i framtiden. Behöver inte påbörjas direkt. Går att planera. - FAST DATUM
Aktiviteter där affärspåverkan om vi bryter leveransdatumet blir ringa klassas som FAST DATUM. Dessa har ett tydligt leveransdatum men ofta hänger leveransdatumet mer ihop med planerade releaser än stora kostnader för verksamheten. Vi har möjlighet att i värsta fall skjuta på leveransen av dessa en kortare tid. - STANDARD
Detta är aktiviteter som ska göras men det finns inget datum då dom måste vara klara. Alla tjänar på att göra dom så fort som möjligt men dom har inget fast leveransdatum. Det kan till exempel vara förebyggande aktiviteter för att sänka risker eller förenkla/effektivisera arbetet.
Hur får vi standardaktiviteter att bli utförda om det hela tiden beställs fasta och kritiska-datum-aktiviteter? Att sätta begränsning i hur mycket arbete som får pågå samtidigt är ett sätt. När pågående arbete(WIP) begränsas kan detta ske per klass. T.ex. sätter vi WIP-Limit (Begränsningen av hur många aktiviteter som får vara påbörjade samtidigt) olika för de olika klasserna.
exempel:
- WIP-Limit 1 10% - UTFÖR
- WIP-Limit 4 40% - KRITISKA DATUM
- WIP-Limit 4 40% - FAST DATUM
- WIP-Limit 1 10% - STANDARD
Det innebär att när vi planerar aktiviteter tar vi automatiskt in STANDARD-aktiviteter när WIP-Limit för de övriga är fylld. Vi kan även procentuellt styra hur mycket aktiviteter vi måste arbeta med som är standard genom att justera WIP-Limit. Har vi en stor mängd förbättringsåtgärder som verkligen behöver göras kanske nedan fördelning gör att vi får mer av dessa proaktiva aktiviteter genomförda.
- WIP-Limit 1 10% - UTFÖR
- WIP-Limit 2 20% - KRITISKA DATUM
- WIP-Limit 2 20% - FAST DATUM
- WIP-Limit 5 50% - STANDARD
Så länge vi är noga med att vår totala arbetsbelastningen ligger justerad/med marginal efter vår förmåga att leverera har vi har möjlighet att göra klart aktiviteter i stället för att bara påbörja nya hela tiden. Då håller vi våra cykel-tider inom förväntade och uppskattade värden. Vi försöker nu noggrant klassificera allt samtidigt som vi diskuterar med beställare och beskriver våra klassers cykel-tider. Det hoppas vi gör vår leveranskapacitet tydligare och lättare att förstå.
// Mats
Aaron öppnade med en kort presentation om hans professionella liv som utvecklare där han började med Perl 1999 och blev mer eller mindre tvingad att byta till Java 2002 som fortsatte till 2007 då han började använda Ruby.
bekant term Pair Programming. I Aarons fall fortsatte han lite längre och gick med i e-post listor för ruby-talk och ruby-core, började gå på massor av konferenser och även undervisa på ett lokalt universitet i Seattle.
Jims tal var något kortare men med ett direkt budskap att förklara fördelarna med funktionell programmering som letade sig ner till dessa tre punkter:
Heroku add-ons är små självständiga tjänster som man laddar upp i Heroku som i läggs på en Amazon EC2 instans. EC2 arkitekturen var ett starkt argument eftersom alla Heroku appar ligger i EC2 så är det extremt låg latens mellan instanserna (add-ons/appar), även internationellt och mellan kontinenter.
Kortfattat kan man säga att föreläsningen handlade om att välja rätt verktyg för jobbet.
