Citerus blogg om framgångsrik mjukvaruutveckling

Mini-ramverk för vy-injicering i Android

Fri, 04 May 2012 06:00:27 GMT

Häromdagen tröttnade jag på att skriva boilerplate-kod i mina Android-aktiviteter för att komma åt mina xml-definerade vyer. Så, som en rolig övning och för att friska upp mina Annotations-kunskaper beslöt jag mig för att skriva ett mini-injection-ramverk för vyer. Det visade sig, att på tjugo minuter och lika många kodrader hade jag vad jag behövde.

Det vanliga sättet i android för att få tillgång till vyer i Android är att använda findViewById() på följande sätt:

TextView  mQuestionText;
mQuestionText = (TextView) findViewById(R.id.questionText);
// Use view

Kanske inte jättejobbig kod att skriva, men den är rätt irriterande att se i onCreate hela tiden om man har många vyer i sin aktivitet och det är lätt hänt att man gör det här på många olika ställen vilket kan göra koden svåröverskådlig. Dessutom, om man byter typ på vyn, t. ex. från CheckBox till ToggleButton så måste man ändra på två ställen och riskerar tråkiga class cast exceptions.

Min tanke med ett litet mini-injection ramverk var att istället kunna byta ut koden ovan med att bara annotera deklarationen på följande vis och sedan kunna lita på att vyn inte är null och castad till rätt typ:

@Inject(id=R.id.questionText)
TextView mQuestionText;
//Use view

Min lösning för att göra detta var att skapa en runtime-annotation-klass Inject med ett fält id som ovan samt en hjälpklass som givet en aktivitet injicerade referenser till alla medlemsvariabler av typer som ärver View och som har annoteringen Inject på sig. Total skulle då en deklaration och onCreate kunna se ut så här:

@Inject(id=R.id.questionText) TextView mQuestionText;
@Override public void onCreate(Bundle savedInstanceState)  { 
    super.onCreate(savedInstanceState); 
    setContentView(R.layout.main);  
    injectViews(this); 
}

Det trevliga med koden ovan är att onCreate-metoden inte växer med antalet deklarerade vyer, något som jag annars retat mig på, samt att jag slipper skriva

mView = (TextView) findViewById(R.id.view);

hela tiden!

Själva implementationen av ViewInject.injectViews() och annoteringen är enkel. Annoteringsklassen:

@Retention(RetentionPolicy.RUNTIME) //Make the annotation readable at runtime
public @interface Inject {  
    int id();
}

Och den statistiska metoden för att injicera vyn:

public static <T extends Activity> void injectViews(T activity) { 
    Class<T> cls = (Class<T>) activity.getClass();  
    Field[] fields = cls.getDeclaredFields();  
    for (Field field : fields) {   
        //Check field is subclass of View   
        if (View.class.isAssignableFrom(field.getType())) {    
            Inject injectAnnotation = field.getAnnotation(Inject.class);    
            if(injectAnnotation != null) {     
                try {      
                    View view = activity.findViewById(injectAnnotation.id());      
                    if(view == null) {       
                        throw new RuntimeException("No View for id ...
                    }                     field.set(activity, view);
                } catch (Exception e) {
                    throw new RuntimeException("Error, cannot load ..."); 
                } 
            }     
        }     
    }
}

Givetvis vill man brodera ut klassen ovan med lite bättre felhantering, tydliga loggar och möjlighet att byta ut vyerna mot mockade varianter när man testar. Men då skulle ramverket bli mer än 20 rader, så det lämnas till läsaren att lägga till efter behov.

All kod och ett testprogram finns open source på https://github.com/staxgr/ViewInject.

Och givetvis finns det redan nån annan som gjort det bättre. Så om ni vill ha en mer mogen och innehållsrik variant så rekommenderar jag att ni testar Roboguice, det ska jag göra!

Happy coding!

Craftsmanship exchange - en vecka i Grand Rapids

Tue, 24 Apr 2012 07:30:11 GMT

Jag flög ut från Stockholm den 14 april för att inleda vårt craftmanship exchange med Atomic Object. Atomic Object är ett företag som på många sätt liknar vårt företag och som på olika sätt har kopplingar till Citerus. Det är därför extra roligt att detta utbytesprogram äntligen har kommit igång.

Atomic har ett spännande koncept där de bygger hela produkten åt sina kunder, vilket betyder att de har stor kompetens kring utveckling, produktdesign och effektiva arbetssätt.

Under veckan fick jag se prov på hur otroligt bra det kan fungera när man samarbetar i tvärfunktionella team och ta fram nya funktioner utan väntetider. Design, utveckling och testning i en härlig röra med kundens problem i fokus!

I Atomics stora rum fanns en "Radiator" som visualiserade en massa olika information kring status på pågående utvecklingsprojekt, statistik på deras hemsida och vilka som närmast var på gång att publicera bloggposter på hemsidan. Inspirerande!

Jag hade innan utbytet blivit informerad om att projektet jag skulle jobba i baserades på Ruby on Rails. Det skulle visa sig att applikationen var en modern webbapplikation med ett rikt användargränssnitt och det blev därför mycket utveckling för klientdelarna av applikationen.

De tekniker som nyttjades flitigast var CoffeeScript och ett ramverk för JavaScript vid namn Backbone.js. Detta var för mig både ett nytt språk (CoffeeScript) och ett nytt ramverk, vilket var väldigt spännande och roligt att se. Jag parprogrammerade med Matt Fletcher, Jared Sartin och Paul Hart under veckan och fick se mycket av testdriven utveckling med CoffeeScript blandat med en ständigt pågående designprocess. TDD för JavaScript/CoffeeScript är något som jag inte har sett praktiserats tidigare, men det kommer jag ta med mig som en riktigt viktig del i arbetet med denna typ av applikation.

Det är utmanande att sätta sig in i ny teknik och en ny applikation på så kort tid men med stora öron och ögon kan man absorbera och lära sig mycket. Jag hoppas att jag även kunde bidra med lite nytta under veckans parprogrammeringssessioner.

Vi gick även genom ett retrospektiv över projektets första fas och hade flertalet lunchdiskussioner om olika ämnen, däribland operativsystem och design thinking.

Under min sista dag höll jag i en "brown-bag"-lunch där jag presenterade lite kring mina tankar kring Clojure och varför det har kommit att intressera mig.

Utöver dagarna som var fulla med nya erfarenheter blev jag väl omhändertagen och fick se mycket av Grand Rapids och en del av de närliggande städerna. Jag var med och tittade på ett cykellopp, åt trevliga middagar och hade after-work med i stort sett alla på Atomic. Det känns fantastiskt att ha fått umgås med alla på Atomic, både på och utanför arbetet.

Det har varit en otroligt lärorik vecka och det är otroligt bra att Citerus och Atomic Object har skapat möjligheten att genomföra dessa utbyten.

I maj tar vi emot Matt Fletcher från Atomic då han under en vecka kommer att arbeta med oss på Citerus. Vi ser verkligen fram emot detta och framtida utbyten!

Matt Fletchers blogg om den gångna veckan.

Om övertid i utvecklingsprojekt

Mon, 16 Apr 2012 09:22:33 GMT

Vi börjar i rätt ände: vad, om något, är problemet med övertid i utvecklingsprojekt? De problem som lyfts fram generellt är ganska tunga saker. Det påstås att övertid:

Ökar kostnaden mer än produktiviteten
Bidrar till fler defekter
Sänker motivationen
Ökar ångest och depression och påverkar familjelivet
Försämrar talangmarknadserbjudandet

Olika sorters övertid

All övertid är inte lika. Dels kan övertid användas i kortvariga och sällsynta perioder, dels kan övertid användas som en stående standardlösning. Det går också att skilja på övertid som mer frivilligt väljs av den som gör jobbet, och övertid som beordras.

Frivillig och kortvarig övertid är sannolikt mindre problematisk än beordrad och långvarig övertid. De stora problemen som lyfts fram har sannolikt störst koppling till denna typ av övertid.

Svårt att studera

Effekten av övertid verkar inte helt lätt att studera, eftersom många faktorer påverkar produktiviteten i ett företag, och dessutom är det inte alls uppenbart hur man egentligen mäter produktiviteten i utvecklingsprojekt.

Trots detta verkar många överens om att långvarig övertid är skadlig för utvecklingsarbetets produktivitet (och för arbetslivskvaliteten). Vi kan studera den forskning som finns inom industrin, och resonera kring om motsvarande kan gälla inom kunskapsarbete.

Ökar kostnaden mer än produktiviteten

Intuitivt kan tyckas att fler timmar borde leda till att mer blir gjort. I praktiken är det inte så enkelt.

Den första frågan vi behöver ställa oss är: är alla arbetstimmar på jobbet lika produktiva?
Svaret blir nej. Ibland är vi extremt produktiva, och ibland gäller motsatsen.

Nästa fråga blir: hur påverkar övertid vår produktivitet? Om vi jobbar 50% mer, kan vi då förvänta oss 50% mer resultat? Svaret tycks vara nej. På kort sikt kan vi förvänta oss att vi får mer gjort, men förbättringen är inte linjär mot antalet timmar. I och med att vi blir tröttare mot slutet av dagen eller veckan, så minskar också vår produktivitet.

En studie i byggbranschen visade på att efter flera veckors övertid så tjänande man inte längre något alls på att fler timmar arbetades. Man fick alltså ut lika mycket som om man hade jobbat normal arbetstid.

Redan på kort sikt ser vi alltså att vi inte får ut så mycket från övertid som man skulle tro. På lång sikt kan rent av produktiviteten sjunka, när följdeffekterna av övertiden gör sig gällande.

Bidrar till fler defekter

Tom deMarco citerar i sin bok "Slack" kollegan Tim Lister: "People under pressure don´t think faster" [3]. Mer koncist än så kan det knappast sägas.

Utvecklingsarbete kräver kreativitet och koncentration. Tröttheten som kommer med långvarig övertid hjälper knappast med det. Tvärtom ligger det nära till hands att tro att övertid ökar risken att vi introducerar defekter i koden.

Är det OK att programmera onykter? Möjligtvis hemma, men knappast på jobbet. Men det är accepterat att programmera när man är helt uttröttad, trots att tröttheten lätt kan motsvara effekten av onykterhet. [2] Hjälper sådana trötta timmar verkligen projektet framåt, eller gör de att vi tar ett steg bakåt?

Felsökning och felrättning är kostsamt och svårt att tidsplanera, vilket påverkar produktiviteten och förutsägbarheten på lång sikt. Ett fel som tar några timmar att orsaka kan kosta dagar eller veckor att hantera.

Sänker motivationen

När en medarbetare behöver jobba övertid för att försöka leva upp till en plan som bestämts av någon annan. så är det knappast bra för motivationen.

Sett ur motivationsperspektivet är kortvarig och frivillig övertid sannolikt mindre skadlig, just eftersom den väljs frivilligt. Dock får vi vara vaksamma på att gränsen mellan frivilligt och påtvingat ibland kan vara suddig. När ett visst beteende, t.ex. att jobba långa dagar, satt sig i väggarna styrs vi mer av det än vi ibland vill erkänna ens för oss själva.

Ökar ångest och depression och påverkar familjelivet

Den forskning som oftast nämns kommer från industrin. Där man upptäckt att allvarliga olyckor lättare inträffar när arbetare jobbar övertid och är trötta.

En studie gjord av University College i London på 2000 medelålders kontorsarbetare kom fram till att de som arbetat i snitt elva timmar per dygn hade runt 2,5 gånger så ofta perioder av depressiva sjukdomar som de som bara arbetat 7-8 timmar per dygn. [4]

Att långa dagar och veckor påverkar den som har en familj (och för all del släkt och vänner) kan tyckas uppenbart, men är det kanske inte alltid. Jag diskuterade själv detta med en mentor i branschen, och kommenterade att jag inte reser så mycket som konsult att det borde påverka mina barn. "That's what you think", var hans svar. Omedelbart insåg jag vilken enorm händelse det var för mig som liten när min pappa kom hem från sina tjänsteresor, och då hade han nog ändå bara varit borta ett par dagar.

Försämrar talangmarknadserbjudandet

Det är inte orimligt att tro att ett företag som blir känt för att låta sina anställda arbeta långa perioder av övertid gradvis blir mindre attraktiva som arbetsgivare.

Varför använder vi övertid?

Om övertid är så problematiskt, varför är det fortfarande så vanligt?

Det fungerar, på kort sikt
De negativa effekterna kommer med fördröjning. När väl problemen uppstår är det inte alls säkert att vi kopplar dem till användadet av övertid. Paradoxalt nog kanske vi väljer att jobba ännu mer övertid för att försöka lösa problemet, vilket bara förvärrar situationen.
Kostnaderna är inte synliga, t.ex. kostnaden för personalomsättning
Synen på medarbetare som "resurser" som ska "allokeras" abstraherar bort problemen
Intuitivt känner vi att fler timmar borde leda till att mer blir gjort
Vår passion för det vi gör driver oss att arbeta mycket
Vi är rädda för att vi inte visar framfötterna tillräckligt mycket om vi säger nej till övertid

Vägar framåt

Kontinuerlig omprioritering

Genom att prioritera utvecklingsarbetet per funktion och kvalitet, kan vi se till att nyckelegenskaper hos produkten färdigställs tidigt i projektet. Då ökar sannolikheten att vi kan hålla tidplaner och budgetar genom att anpassa omfånget i produkten ellt eftersom vi lär oss mer om vad som är görbart inom de satta ramarna - istället för att jobba övertid.

Detta är vägen vi går när vi i scrum använder en noggrant prioriterad produktbacklog och utvecklar produkten i stabila inkrement.

Fler högproduktiva timmar

Övertid är ett sätt att lägga till fler timmar av arbete till ett utvecklingsprojekt. Vilka andra sätt finns det att lägga till fler timmar?

Inga, kan tyckas, om man endast räknar antal timmar. Men om man nyanserar målet och formulerar om det som att lägga till fler högproduktiva timmar till arbetet, så öppnar sig ytterligare en möjlighet. Den möjligheten handlar om att konvertera de timmar som idag är lågproduktiva till högproduktiva.

Detta är den väg vi går när vi väljer att fokusera på "servant leadership", som vi gör med t.ex. scrum. Målet för en stöttande ledare är att hjälpa sin organisation att bli mer produktiv på ett uthålligt sätt. En stöttande ledare hjälper till att konvertera lågproduktiva till högproduktiva timmar.

Uthålligt tempo

Ett slagord i den agila rörelsen är "sustainable pace". Ett utvecklingsteam ska kunna arbeta utan bortre tidsgräns med det tempo man håller. Det betyder att man håler sig till en rimlig längd på arbetsdagen, tar sina helger ledigt och unnar sig semester då och då. Utan vilan blir inte tempot uthålligt.

Läs mer

The dawn of the Citerus-Atomic exchange program!

Fri, 13 Apr 2012 14:23:11 GMT

Tomorrow it's time for me to embark the plane on my journey towards Grand Rapids, MI and the start of the first episode of our exchange program with Atomic Object.

I'm looking forward to meeting all of the cool people of Atomic and no doubt I will learn a lot of new stuff.

I will have the chance to work with Atomic during a week on one of their Ruby on Rails projects. This is really exciting since this is completely new ground for me. Although I've looked at Ruby (and Rails), I've never had the opportunity to work with it professionally.

I've also heard there will be chances to see breweries, bike races and have nice dinners and it will be nice to see what Grand Rapids has to offer.

In May, Matt Fletcher from Atomic will continue this program by joining us for a week and everyone at Citerus are looking forward to his arrival!

www.atomicobject.com

NFC i Android - Okomplicerat och roligt!

Tue, 10 Apr 2012 11:33:56 GMT

Near Field Communication, NFC, är en spännande teknologi med många möjligheter. Kanske inte minst betallösningar som vi förhoppningsvis får se ute i butikerna inom en överskådlig framtid. Trots att jag har haft en telefon med NFC-teknologi i över ett år nu, först Nexus S och nu Galaxy Nexus, så har jag aldrig nyttjat funktionen. Dels för att det inte funnits några intressanta tillämpningar och dels för att jag själv inte hittat någon spännande tillämpning att själv implementera. Tills häromdagen.

För att få tillgång till NFC-funktioner krävs följande tillstånd:

<uses-permission android:name="android.permission.NFC"></uses-permission>

I mitt fall behöver jag även API-nivå 10 för att kunna läsa och skriva till taggarna. Det betyder dock inte att man måste kräva denna API-nivå. Om NFC-funktionerna inte är en nödvändighet för appen så kan man helt enkelt utesluta dessa för telefoner som saknar denna möjlighet.

if(Build.VERSION.SDK_INT < Build.VERSION_CODES.GINGERBREAD_MR1) {
// do whatever necessary to hide NFC features
}

Man behöver även kontrollera att telefonen har stöd för NFC, dvs om den har ett NFC-chip. Det gör man enklast genom att kolla om NfcAdapter.getDefaultAdapter(context) returnerar null. I RemoteStick finns möjligheten att båda skriva och läsa från taggar. Taggarna måste nämligen först programmeras med information om vilka enheter som ska styras och på vilket sätt. För detta använder jag en separat aktivitet i appen. Här väljer man vilka enheter som ska styras och på vilket sätt och sedan håller man helt enkelt upp taggen för telefonen för att programmera den. För att undvika att andra appar också försöker läsa av taggen i detta skede kan man fånga upp intents och hindra andra aktiviteter att få dessa. Detta kallas Foreground Dispatch.

public void onPause() {

    super.onPause();

    mAdapter.disableForegroundDispatch(this);

}


public void onResume() {

    super.onResume();

    mAdapter.enableForegroundDispatch(this, pendingIntent, 
        intentFiltersArray, techListsArray);

}


public void onNewIntent(Intent intent) {

    Tag tagFromIntent = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);

    //do something with tagFromIntent

}

PendingIntent och IntentFilter skapas på följande sätt:

PendingIntent pendingIntent = PendingIntent.getActivity(

    this, 0, new Intent(this, 
    getClass()).addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP), 0);


IntentFilter ndef = new IntentFilter(NfcAdapter.ACTION_NDEF_DISCOVERED);

    try {

        ndef.addDataType("*/*");    
            /* Handles all MIME based dispatches.
            You should specify only the ones that you need. */
    }

    catch (MalformedMimeTypeException e) {

        throw new RuntimeException("fail", e);

    }

   intentFiltersArray = new IntentFilter[] {ndef, };

Skrivning till taggen går till så här (om än typiskt i flera steg):

Ndef tag = Ndef.get(tagFromIntent);
...
tag.connect();
tag.writeNdefMessage(new NdefMessage(new NdefRecord[] { 
    new NdefRecord(NdefRecord.TNF_MIME_MEDIA,
    “application/org.remotestick”.toBytes(), new byte[0], payload) }));
tag.close();

Jag vill att taggen ska tolkas som MIME-data med typen “application/org.remotestick”. Detta gör det betydligt lättare att identifiera RemoteStick-programmerade taggar när de senare läses av. Payload i det här fallet är den byte-array som skrivs till taggen och vars format, som jag definierat själv, är oväsentligt för denna artikel. När en tagg sedan läses in vill jag inte öppna RemoteStick utan bara utföra de kommandon som finns lagrade. Det naturliga vore här att sätta ett intent-filter på en BroadcastReceiver eftersom jag egentligen inte vill öppna RemoteStick men intents för NFC-taggar skickas bara till aktiviteter. I fallet RemoteStick ser därför manifestet ut såhär:


<activity android:name=".activities.NfcCommandDispatcher"></activity>
<action android:name="android.nfc.action.NDEF_DISCOVERED"></action>
<category android:name="android.intent.category.DEFAULT"></category>
<data android:mimetype="application/org.remotestick"></data>

Och i aktivteten (null checks och try-catch exkluderade):

@Override
protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);
    Intent intent = getIntent();

Tag tagExtra = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);

Ndef tag = Ndef.get(tagExtra);

tag.connect();

NdefMessage msg = tag.getNdefMessage();

for (NdefRecord rec : msg.getRecords()) {

    byte[] payload = rec.getPayload();

    // parse payload

    // send broadcast intent

}

tag.close();

finish();
}

RemoteStick behöver alltså inte vara körandes för att taggarna ska läsas in av programmet. Aktiviteten läser in och tolkar datat från taggen och skickar det vidare till en BroadcastReceiver. Faktum är att det är samma BroadcastReceiver som används i andra sammanhang (i integrationen med apparna Locale och Tasker) så även om en dispatcher på detta vis kan kännas aningen ful så integrerade det väldigt bra med redan befintlig kod. Just den här tillämpningen kan till exempel användas för att släcka ner hela huset med en tagg vid sängkanten eller slå på belysning när man kommer hem med en tagg vid entrédörren. Hur skulle du vilja se NFC-teknologin användas?

Värdet av Story Points

Fri, 30 Mar 2012 10:11:20 GMT

"Varför använder vi inte helt enkelt timmar?" är en fråga som ofta dyker upp. Det är lätt att förledas att tro att estimering i timmar ger en bättre noggrannhet och tillförlitlighet. Jag vill peka på några exempel som visar på styrkan med Story Points och varför du bör använda dem istället.

För det första måste vi acceptera att estimering av ett arbete är per definition betingat med en viss osäkerhet. Det är just ett estimat vi ska leverera, ofta med en rad osäkra parametrar såsom; föränderliga krav, otydliga klarkriterier, olika möjliga tekniska lösningar, samt teknisk komplexitet. Visst skulle vi med möda, kunna klargöra dessa osäkerheter men ofta kostar det mer än det smakar. Vi vill leverera ett lagom gott estimat med minimal ansträngning.

Det har visat sig att kostnaden för att ge säkrare estimat växer exponentiellt. Ofta är det initiala, grova estimatet tillräckligt nära den verkliga storleken. Det förutsätter dock att en viss bearbetning av kraven har gjorts tidigare, så att man vet vad man estimerar. De gånger estimat felar gör de ofta det åt båda håll så att felen till viss del tar ut varandra.

Ett estimat skall ge oss en del av det beslutsunderlag som behövs för att kunna prioritera backloggen. Det behövs även för att lyckas planera in en lagom stor mängd arbete i varje sprint . Med estimatet kan vi även ta fram längre prognoser för vad som kan levereras om 6 månader eller ett år. I alla dessa fall kan vi acceptera en viss osäkerhet i estimatet.

Problematiken

Ett problem med användningen av timmar är den falska exaktheten man tror sig få. Det är lätt att räkna fram hur många mantimmar som ryms i sprinten och förledas att planera efter detta. Då är det lätt hänt att man tar på sig för mycket jobb. Om det saknas några timmar för att få med den där sista viktiga storyn kan man tänka sig att någon vill lösa detta genom att slänga in ytterligare en person i teamet för just denna sprint. I praktiken kommer det troligen falera kapitalt. Den nya personen är kanske inte insatt i domänen och har svårt att leverera fullt ut. Han eller hon kommer behöva mycket hjälp av sina kollegor, vilket leder till att även deras effektivitet minskar. Dessutom har gruppdynamiken rubbats vilket även det leder till minskad effektivitet för hela gruppen. I praktiken har väldigt lite vunnits av den nya resursen och ibland kan det istället varit en ren kostnad.

Dessutom är resultatet av en timmes jobb olika beroende på vem som utför arbetet. Estimaten är därför personberoende och blir förlegade när teamet förändras. Vid en sprintplanering blir det viktigare att veta exakt vem som ska utföra arbetet för att i realiteten veta om det kommer hinnas med eller inte. Detta är en detaljstyrning som varken är önskvärd eller effektiv och som med fördel undviks.

Story Points

När man estimerar m.h.a Story Points mäter man varje story relativt varandra. Detta innebär att det spelar ingen roll om en Story Point innebär en eller tio timmars jobb. Story A kommer alltid att vara dubbelt så stor som story B. Fördelen med denna relativitet är att det gör estimaten mer robusta och underlättar våra planeringar, både långsiktigt och kortsiktigt.

Fördelen för teamet

Estimeringarna kommer aldrig att bli förlegade, så länge kraven håller sig intakta. Dessutom kan inte produktägaren ifrågasätta teamets estimat på samma sätt som om man hade pratat om timmar. "Det där kan väl aldrig ta åtta timmar att göra?" skulle kunna myntas. Däremot är det svårt för någon att påstå "Det där kan väl aldrig ta 5 Story Points att göra?" utan att jämföra med andra krav.

Andra fördelar med användningen av Story Points är att det ger en enklare sprintplanering. Mängden jobb som kan planeras in beror då endast på teamets historiska velocitet. Komplexitet såsom ändringar i gruppsammansättning eller team med olika velocitet behöver då inte tas i beaktande. Historiskt vet vi mängden Story Points som brukar klaras av i en sprint. Har inget ändrat gruppens förutsättningar så är vår bästa gissning att kommande sprint bränner lika många poäng.

Även om gruppsammansättningen skulle förändras håller våra estimat fortfarande. Det är bara teamens velocitet som förändras och den kommer vi empiriskt ta reda på. Estimaten är inte längre personberoende.

Fördelen för Produktägaren

Långsiktigt tillhandahåller detta mer tillförlitliga prognoser som spänner över flera sprintar. Eftersom vi vet att estimaten endast förändras om kraven ändras, kan vi känna oss säkra på att dessa prognoser håller. Produktägaren kan då med god framförhållning kommunicera detta till kunden och ge dem trovärdiga löften eller förhoppningar avseende kommande releaser.

Om några nya krav behöver läggas till i backloggen är det enkelt att se vilka av de lägre prioriterade kraven som måste skäras bort för att få plats med det nytillkomna.

Vid förändring i teamens velocitet kan snabbt en ny prognos tas fram som speglar den nya situationen. Vi behöver inte sätta oss i nya estimeringsmöten för att gå igenom backloggen på nytt.

Sammanfattning

Story Points kan verka skrämmande och konstigt för den oinvigde. Men med lite eftertanke inser man att de förenklar vårt dagliga arbete och ger oss en rad fördelar. Inte bara för teamet, utan för hela organisationen.

Citerus 2 707 m.ö.h!

Wed, 28 Mar 2012 15:05:41 GMT

I förra veckan var det dags för vår årliga förlängda Citerusdag. Julfesten i december hade avslöjat resmålet; vi skulle till Marocko förstod vi snabbt när vi kom in till kontoret som var omstylat med hjälp av kuddar, lyktor, tyger och tält. Sedan dess har vi läst in oss lite på Atlasbergen, och det så kallade "Kasbah" vi skulle besöka i byn Imlil som ligger 1,5 timmes bussresa från Marrakech.

Ett kasbah är ett sorts fort. Kasbahn var boplatsen för den lokala ledaren och fungerade även som försvar när staden var under attack. En kasbah har höga murar som vanligtvis inte har några fönster. Ofta byggdes de på en höjd för att göra dem enklare att försvara, så var även fallet för vårt kasbah - Kasbah du Toubkal.

Namnet kommer från närheten till bergstoppen Jbel Toubkal, som med sina 4 176 m.ö.h är den högsta bergstoppen i Atlasbergen (och faktiskt i hela Nordafrika). Bergets höga höjd gör att toppen är snötäckt under stora delar av året, och vi kan lova att det är vackert!

Vi anlände onsdag lunch, efter en wi-fi-enablad (och väldigt tidig) flygning från Arlanda. Vi togs emot med traditionellt, sött myntate och dadlar. Därefter serverade en traditionell lunch på takterassen, med en magnifik utsikt under en strålande sol. Eftermiddagen ägnade vi åt en rundvandring i byn innan vi satte oss för att jobba med vårt kursutbud några timmar. Ett innovativt gäng hjälptes åt att identifiera behov, konkretisera målgrupper samt specificera kurs/workshop-innehåll för inte mindre än sex nya kurser. Skall bli spännande att transformera dessa till färdiga kurser under året.

Efter en tidig kväll, där alla somnade ovaggade, vaknade vi till ytterligare en strålande dag. Efter en stärkande frukost, som bestod av hemgjord yoghurt, närproducerad honung, hembakat bröd, ägg från byns hönor samt ännu mer myntate, var det dags att bestiga ett berg. En toppbestigning av Toubkal tar minst tre dygn, varför vi nöjde oss med en dagstripp till ett närbeläget bergspass. Efter fyra timmars vandring belönades vi av en fantastisk vy över nästa by, samt en välsmakande lunch serverad på 2 500 meters höjd. Vi omringades snart av en flock getter, som nyfiket studerade dessa mystiska IT-konsulter.

Vandringen hemåt krävde stor uppmärksamhet, eftersom stigarna bestod av mycket lösa stenar. Alla kom dock helskinnande tillbaka till kasbaht där vi pustade ut med bad och tvagning i ett traditionellt hammam. Efter någon timmes ångbad var vi redo för ett nytt arbetspass, innan det var dags för ytterligare en traditionell måltid. Vid det här laget hade vi lärt oss att vi kunde vänta en grönsakssoppa och därefter cosucous med grönsaker (inte helt al dente enligt några kritiker) samt en Tagine, som är en sorts gryta som ofta baseras på kyckling eller lamm. Tagine är också namnet på kärlet som maten tillagas i, det traditionella keramikfatet med toppigt lock, som ställs över öppen eld.

Natten kom att bli orolig för många av oss, då ett oväder drog in med storm och regn, vilket kändes rejält i de något luftiga byggnader vi bodde i. Tur dock att ovädret inte kom tidigare. Fredag morgon skulle vi ägna åt några timmars arbete, då vi planerade för eftermiddagens artikelskrivande innan vi satte oss på bussen till Marrakech.

Vi tog farväl av Kasbah du Toubkal (men många av oss sa nog tyst: "På återseende!")

Hotellet i Marrakech hade en rejäl tilltagen trädgård med pool, vilket ju alltid är lockande för oss nordbor. Efter en snabbincheckning var det dags att göra stan; vi gick till ett traditionellt "riad" för att äta lunch. En riad är ett traditionellt marockanskt hus, byggt kring en innergård. I Marrakech finns det ett oräkneligt antal sådana som tar emot gäster.

Efter lunchen var det dags att utforska Medinan, den gamla muromgärdade stadskärnan som är Marrakech stora dragplåster. Det är inte helt enkelt att hitta så vi tog hjälp av en guide som visade oss runt. Det stora torget Djema el-Fna är Marrakechs hjärta; där huserar sagoberättare, ormtjusare, gnauaorkestrar, akrobater, tiggare och många bondfångare. Precis intill torget ligger den delvis täckta souken (marknaden) där olika hantverkare har sina egna gatstumpar. Vi beslöt oss för att satsa på att shoppa och pruta under lördagen och åkte istället tillbaka till hotellet för ett arbetspass, denna gång vid poolen. Under några koncentrerade timmar formulerade vi artiklar om olika ämnen, som ett led i vår djupt rotade tradition att bjuda på kunskap. Med oss hem till Sverige har vi ett halvt dussin artikelutkast som kommer att publiceras under våren, ytterligare lika många ligger kvar på idéstadiet för framtida bruk.

Kvällen ägnades åt att utforska Marrakechs nattliv. Vi kan väl konstatera att den inte går av för hackor! "What happens in Marrakech stays in Marrakech" är nog en passande devis för den här stadens partyscener.

På lördagen tillät vi oss en sovmorgon, innan vi tog hela poolområdet i besittning för att testa Scrum-simuleringsövningar! Vi hade kul, men en och annan undrande blick fick våra lego-byggen av övriga gäster. På eftermiddagen var det så dags för lite seriös shopping! Ett gäng mycket nöjda souk-besökare kom tillbaka till hotellet med välfyllda påsar med vacker keramik, sirliga tekannor och handsydda skinnpuffar. Allt som återstod efter det var hemresan och självklart fantastiska minnen från Marocko!

Bidrag från Crazy Snake - Jfokus Edition

Tue, 28 Feb 2012 15:29:39 GMT

Under tävlingens gång såg vi många ormar som försökte att vinna genom att äta så mycket frukt som möjligt. Andra gick in för att döda sin motståndare när tillfälle gavs.

Koden till några av tävlingsbidragen hittar ni här: https://bitbucket.org/citerus/crazysnake-public-jfokus/downloads

Så här beskriver skaparna sina tävlingsbidrag:

Skaparen av ormen Pazport-Ygge och vinnare av Crazy Snake - Jfokus Edition beskriver sin kod:

"Algoritmen för att avgöra nästa drag har egentligen tre steg:

Kontrollera om vi kan göra en serie drag som i max 6 drag kommer innebära att motståndaren dör, oavsett vad motståndaren gör.
Om det inte går, prioritera möjliga riktningar att gå i för att samla frukt genom att hitta alla frukter som vi kommer nå först och räkna ut avståndet mellan alla par av dessa frukter. Prioritera sen frukterna som kommer ge oss uppskattningsvis flest frukter på minst tid.
Sist är det ett antal kontroller att vi inte går in i en vägg eller går in i ett utrymme som vi inte kan kommar ur"

Skaparen av ormen ShakeASnake beskriver sin kod:

"Jag implementerade min orm helt i Java. De två centrala klasserna heter Finder och Evaluator. Klassen Finder söker efter det bästa draget i en given position genom att pröva alla möjligheter, först ett drag framåt, sedan två och tre osv tills tiden är slut. Klassen Evaluator utvärderar en given position för att se vilken orm som leder. Den försöker bland annat hitta den närmaste frukten och se till att ormen inte trasslar in sig i sig själv. Den senare funktionen skrev jag på kort tid på tisdagskvällen och det blev då en rekursiv algoritm. Efter Jfokus skrev jag om den till en iterativ algoritm som blev betydligt mer effektiv."

"Klassen som implemeterar hjärnan - ShakeASnake - gör egentligen inte så mycket mer än konverterar informationen i HeatState till en intern struktur som går att modifiera. Jag valde att spara frukternas positioner i en array eftersom det verkade mer effektivt än en lista, men efter att ha lyssnat på Cliff Click inser jag att mina 'micro benchmarks' kanske inte var helt tillförlitliga. Jag skrev också en egen klass Pos att använda istället för Position. Eftersom det bara finns ett begränsat antal positioner kändes det onödigt att allokera nya objek för alla förflyttningar. Klassen Pos returnerar alltid samma statiskt allokerade objekt för en viss position, vilket också gör att man kan jämföra positioner med hjälp av == istället för equals."

Skaparna av ormen Snakeway beskriver sin kod:

"Vi implementerade vår ormhjärna i Scala. Vi implementerade A* algoritmen för att få ormhjärnan att kunna navigera förbi hinder."

"vi införde logik för att finna 'fruktkluster' så att ormen skulle prioritera områden som var rika på frukt. Vi jobbade också med att balansera in att välja frukt där motståndaren inte var och att undvika frukt där vår orm 'låg efter' motståndaren."

"Vi började arbetet onsdagen innan Jfokus med ett möte där vi diskuterade strategier och tog fram en enklare spelplan innan vi hade tillgång till spelmotorn. Med (den reverse-engineerade) spelplanen kunde vi testa A*-navigeringen tidigt. Under den följande veckan fortsatte vi arbetet på varsitt håll och vi delade koden på bitbucket."

Vi heter testare

Wed, 22 Feb 2012 12:41:58 GMT

"Quality Assurance". Alla använder uttrycket: utvecklare, management, scrum masters, testare, med flera. Begreppet finns i många branscher och enligt Wikipedia började hantverksgillen med Quality Assurance redan under medeltiden för att sätta en standard på sina medlemmar. Men det var förmodligen först under industrirevolutionen som det tog fart ordentligt. Det var då särskilda personer som fick i uppdrag att säkerställa att en annan persons arbete hade ett godkänt resultat.

I vår bransch anses det viktigt att arbeta med QA. Vi budgeterar tid och pengar för QA, anställer speciella personer och ser till att ha QA-tasks med i sprintplaneringen. Men vad betyder det egentligen?

Tänk på hur det blir när vi byter ut akronomet "QA" mot det fullständiga uttrycket "Quality Assurance" i några vanliga påståenden:

- "Vi har en Quality Assurance i vårt team"
- "När du har kodat klart så får Quality Assurance-specialisten titta på det där"
- "Någon Quality Assurance-person borde Quality Assurance-a den buggfixen"
- "Quality Assurance-arbetet gör vi i slutet på sprinten"

Visst låter det konstigt? Vad är det egentligen vi säger? Menar vi verkligen att kvalitet är något som en person har ansvaret för? Menar vi verkligen att kvalitet arbetar vi med i slutet av sprinten? Kan man verkligen säkerställa kvalitet? Om det går, vill vi ens göra det?

System är i grunden så komplexa att det är praktiskt taget omöjligt att faktiskt säkerställa att ett program är fritt från buggar. Det gäller till och med de enklaste små program och är ännu tydligare i större. Detta gör att det faktiskt är omöjligt för någon, hur specialiserade på "Quality Assurance" de än är, att kvalitetssäkra ett program.

Men det borde egentligen inte handla om kvalitetssäkring, det borde handla om testning. Testning är processen att sammanställa information om ett system med syftet att använda informationen till något (Gerald M. Weinberg. "Perfect Software and Other Illusions about Testing"). Vi ställer ett antal utvalda frågor genom våra tester och utvärderar svaren vi får från dem. Det vill säga, vi tar reda på hur systemet beter sig givet en viss inmatning och funderar på om beteendet känns rimligt och önskvärt. Ibland kan vi inte själva avgöra det och tar hjälp av produktägaren som äger rätten att besluta om systemet uppfyller dennes önskemål.

Vår förmåga och fallenhet för att ställa frågor gör testare värdefulla i tidiga skeden av utvecklingsarbeteet. Vi är till exempel med på planeringen och bidrar med frågor om hur specialfall ska hanteras, hur systemet ska bete sig när uppkopplingen går ner, om andra delar av applikationen påverkas, och så vidare. Ibland ställer vi dumma frågor bara för att hålla igång samtalet för vi vet att det är redan på planeringen som allvarliga fel såsom missuppfattning och grova feltänk uppträder och ju längre vi diskuterar desto större är chansen att vi upptäcker dem. Vi vet att vi redan där kan bidra med att se till att kvalitet är någonting som är närvarande i utvecklingen.

Men för att verkligen lyckas måste hela teamet och hela organisationen ta sitt ansvar och tänka på kvalitet. Det bör genomsyra tankar och agerande hos programmerare, produktägare, linjechefer och scrum masters.

Vi borde alltså inte kallas Quality Assurance-personer eller Quality Assurance-specialister och vi varken kan eller bör kvalitetssäkra något. Vi ställer frågor och utvärderar svaren. Vi heter testare.

Vinnare av Crazy Snake - Jfokus Edition

Tue, 21 Feb 2012 08:38:42 GMT

Kort beskrivet gick tävlingen ut på att deltagarna skapade sin egen ormhjärna och mötte en annan ormhjärna i en match bestående av tre heat. Den som hann äta mest frukt innan tiden var ute eller överlevde när motståndaren dog vann heatet. Den ormhjärna som vann flest heat blev King of the hill och fick möta nästa utmanare. För att vinna hela tävlingen gällde det att vara King of the hill klockan kvart över tre den andra tävlingsdagen. Citerus tillhandahöll ett API och en testmotor.

Tolv bidrag var med och tävlade från start och redan då kunde man se att det skulle bli en hård kamp om titeln som King of Jfokus 2012. När andra tävlingsdagen startade var det tydligt att många hade ägnat föregående kväll åt kodning, nya bidrag och uppdaterade bidrag gjorde kampen ännu hårdare. Under de två tävlingsdagarna deltog totalt 24 tävlingsbidrag och sammanlagt uppdaterades bidragen 67 gånger.

När klockan slog kvart över tre på den andra tävlingsdagen korades King of Jfokus 2012 och det vinnande bidraget var Paxport-Ygge. PetSnake7 var det bidrag som vann flest matcher under tävlingens gång: 70 vinster på 91 spelade matcher. Under tävlingsdagarna delades också tre spurtpriser ut till den som var King of the hill just då.

Resultat:

King of Jfokus 2012 - Paxport-Ygge
Spurtpris 1 - pwnBrain
Spurtpris 2 - Nagini
Spurtpris 3 - Wurstmeister
Flest vunna matcher - PetSnake7

Ett stort tack till alla deltagare och åskådare för det stora engagemanget och intresset.

Crazy Snake - Jfokus Edition!

Wed, 08 Feb 2012 10:48:33 GMT

Ibland handlar utmaningen om att ändra en hel avdelnings arbetssätt, ibland om att snabbt realisera värde ur en otymplig kodmassa, och ibland sitter svårigheterna i den kod som skall skrivas. Från stora till små utmaningar - nästan alltid finns det mycket att lära och erfarenheter att utbyta. Just därför vill vi åter igen bjuda in dit till en programmeringsutmaning på Jfokus. Gnugga dina geniknölar, sparka igång din favorit-Maven-IDE och kör igång här!

Learn portable cloud development from founder of jclouds!

Wed, 23 Nov 2011 14:44:40 GMT

"My goal is to make the cloud as easy and portable as the mobile phone network."
Adrian Cole, founder of jclouds

Citerus presents a three-day hands-on class in portable cloud development, led by Adrian Cole, the founder of jclouds. Jclouds is an open library that simplifies the development of portable cloud applications for Java and Clojure developers.

Time To Market more important when launching cloud services

Today more and more business, services and applications are using cloud services, like Amazon EC2 or Microsoft Azure, to reduce their time to market and improve their agility. "The cloud" has fundamentally changed the deployment of services and data storage, reducing to mere minutes the time taken to provision hardware and deploy an application, an improbable dream several years ago.

Obstacle in API growth

However, in recent years the number of cloud providers has skyrocketed, creating a bewildering mix of 'standard' APIs. The number of APIs, and the variations between them, complicates the selection of cloud services for developers and users and creates vendor lock-in. Correctly choosing a vendor and understanding their API can completely determine the success of your project! Jclouds provides an easy to use, open standard for accessing cloud services with different APIs, allowing you to create portable multi-cloud applications, without having to learn or worry about the differences between multiple APIs.

Jclouds solves API issues

Jclouds started as an open Java library for Amazon's Simple Storage Service when Amazon was pioneering cloud storage. Since then jclouds has grown to provide an easy to use, idiomatic, Java and Clojure API for compute and storage across more than thirty cloud providers. Jclouds provides a natural way to develop for the cloud on the Java platform without being tied to a particular clouds supplier. Many problems and complexities relating to error handling, concurrency and unique API 'features' are managed under the surface, allowing you to focus development on the application in the cloud, rather than troubleshooting specific implementations.

Jclouds used by distinguished brands

Jclouds has been designed from the ground up to handle concurrency, support a common domain model, transparently handle differences between APIs and providers, and provide a portable abstraction while allowing you to access cloud specific features. Jclouds' limited external dependencies allow it to run in restricted environments like Google App Engine and reduce the risk of code conflict. Test stubs are provided for each provider to ensure that your cloud application is fully testable, even without an internet connection. Twitter, Adobe, Red Hat, Enstratus and Neotys are already using jclouds for cloud provisioning and storage, now you can too!

Citerus are proud to offer the oppurtunity to learn cloud development in collaboration with Adrian Cole, creator of jclouds. Sign up to Adrian's unique three-day course in Stockholm on 8-10 February 2012. The course will introduce the key concepts of cloud development and the toolkit required for development. Bring your own computer as you will be writing code during the class!

Links:
http://www.citerus.se/jclouds
http://www.jclouds.org
https://github.com/jclouds/jclouds

http://www.cloudsoftcorp.com

For more information
Karin Edström, CEO Citerus AB
karin.edstrom@citerus.se
Phone: +46 733 225 227

www.citerus.se

Lär dig molnutveckling från skaparen av jclouds!

Wed, 23 Nov 2011 10:14:04 GMT

"Jag ska göra molnet lika lätt och åtkomligt som mobilnätet."
Adrian Cole, skapare av jclouds

Tidsfaktorn allt viktigare vid lansering av tjänster i molnet

Att time-to-market är viktigt i mjukvarubranschen numera är ingen nyhet. Men att kunna driftsätta flertalet servrar, bakom en lastbalanserare, med full kontroll över val av både operativsystem och hårdvara (provisionering), för att sedan inom några minuter driftsätta sin applikation på dessa noder trodde inte många på för några år sedan. Molnet har i grunden förändrat hur vi idag driftsätter tjänster och lagrar data. Fler och fler tjänster och applikationer hittar numera sitt hem i moln som t ex Amazon EC2 eller Microsoft Azure.

Stötestenar med API:er och testning

Under de senare åren har dock antalet API:er för molnlagring och provisionering av virtuella maskiner ökat men framförallt har antalet leverantörer skjutit i höjden. Detta har skapat en stor blandning av olika API:er som alla har likheter och skillnader. Som utvecklare och användare av en molntjänst finns det många aspekter att titta på när det handlar om att välja API, men även vilken leverantör man väljer kan spela stor roll för hur väl tjänsten passar för användningsområdet.
Testbarhet har även det varit en grundpelare i jclouds ända sedan starten och tack vare de stubbade API:erna är det möjligt att utveckla helt utan nätverksåtkomst. Stubbade API:er är nedladdningsbara versioner som simulerar verkliga API:er från molntjänsteleverantörer.

Jclouds löser API-problematik

Ramverket jclouds erbjuder ett naturligt sätt att börja utveckla för molnet på Javaplattformen utan att binda sig mot en speciell molnleverantör. Många problem relaterade till felhantering, samtidighet och skillnader mellan olika API:er och leverantörer hanteras under ytan på ett konsekvent sätt, utan att för den sakens skulle gömmas för utvecklaren. Jclouds har en pragmatisk syn på portabilitet, med en gemensam domänmodell för de flesta användningsfall, men där det även finns stöd för att hantera skillnaderna mellan API:er och olika leverantörer.

Stora plattformar använder jclouds

Amazon var tidigt ute med sin tjänst Simple Storage Service (S3) och jclouds startades när de då tillgängliga Java-biblioteken för S3 inte höll måttet gällande samtidighet och skalbarhet. Från att ha varit ett projekt som skulle stödja lagring på Amazon S3 har initiativet växt betydligt. Numera handlar jclouds om att ge ett enkelt och idiomatiskt alternativ för molnutveckling i Java eller Clojure, jclouds har idag stöd för över 30 molnleverantörer. Jclouds är från grunden designat för samtidighet och då beroenden till externa bibliotek är få till antalet, löst kopplande och noggrant utvalda kan jclouds köra i miljöer som har speciella restriktioner, som till exempel Google App Engine. Jclouds används för provisionering och lagring hos bland annat Twitter, Adobe och Red Hat.

Djupdykning i molnutveckling

Tillsammans med Adrian Cole och Cloudsoft erbjuder Citerus en spännande djupdykning i molnutveckling. Under tre unika dagar med Adrian visas det hur det går till att skriva kod i Java och Clojure som är testbar, skalbar och flyttbar mellan olika molntjänster. Kursen kommer att introducera de viktigaste begreppen inom molnutveckling samt den verktygslåda som en utvecklare behöver för att komma igång. Med sin egen dator följer deltagaren med i kodexempel och skriver egen kod i jclouds under kursens gång.

Länkar:
http://www.citerus.se/jclouds
http://www.jclouds.org
https://github.com/jclouds/jclouds
http://www.cloudsoftcorp.com

För mer information
Karin Edström, VD Citerus AB
karin.edstrom@citerus.se
Tfn: 0733-225 227

Citerus hjälper sina kunder att lyckas med mjukvaruutveckling; antingen genom att utbilda och coacha, införa ett självstyrande ledarskap och ett lättrörligt arbetssätt eller genom att utveckla mjukvara åt dem. Allt för att de ska kunna hålla en hög innovationstakt och skapa smarta lösningar som ökar deras konkurrenskraft. Vi är ledande på Scrum, Java, Domändriven design och många andra metoder och tekniker i framkant.

www.citerus.se

Med Domändriven Design hanteras dagens ökade systemkomplexitet

Thu, 10 Nov 2011 09:59:50 GMT

Reducerad komplexitet - Ökad produktivitet!

Domändriven design handlar om att utforska modeller i en kreativ samverkan med domänexperter för att på så sätt lyfta komplexitetstaket. Programmerare kan då bygga system som snabbt genererar affärsnytta och samtidigt är konstruerade för att kunna vidareuvecklas under många år. Inte sällan finns lösningen på till synes tekniska problem i en djupare förståelse för domänen!

Under den fyra dagar långa kursen görs en djupdykning inom dessa områden. Genom att varva taktiska och strategiska diskussioner samt teoripass med kodning och modellering ger kursen de verktyg som krävs. Citerus erbjuder kursen i samarbete med Eric Evans på Domain Language Inc.

Kursen ges 5-8 december. Länk till information om kursen: DDD

För mer information,
Karin Edström, VD Citerus AB
karin.edstrom@citerus.se
Tfn: 0733-225 227

www.citerus.se

Premiär för Agil re-bootcamp hos Citerus

Mon, 31 Oct 2011 09:40:47 GMT

Mikael Boman och Tobias Fors arbetar i sina konsultroller på Citerus nära många olika kunder och såg ett behov av erfarenhetsutbyte. De har tillsammans utvecklat Agil re-bootcamp som en "stödmottagning" för insatser mot de utmaningar som uppstår när omdaningen till lättrörliga metoder inte går som förväntat. Många gånger är det helt naturliga hinder som det finns verktyg för att hantera, det gäller bara att hitta verktygen.

Korta föredrag och Open space

- En sån här dag samlar kunskap på ett sätt som drar igång kreativiteten och skapar energi, säger Mikael Boman som tillsammans med Tobias Fors kommer leda dagen. - Det blir något kort föredrag men huvudfokus för dagen är på workshoppar i Open Space-format. Vi hoppas kunna ge deltagarna ett riktigt lyft med de idéer som kommer fram under dagen. Väl tillbaka i sin vardag kan de fortsätta utveckla sitt arbetssätt. Vi har identifierat en vilja hos många som fastnat i sin agila utveckling att komma vidare. Då kan en inspirations-injektion vara precis det som behövs för att kunna ta steget, avslutar Mikael Boman.

Genererar många lösningar att välja bland

Rätt använt är Open Space ett effektivt format som fungerar väldigt bra för att lära av varandra, tillägger Tobias Fors. - Vi vet att ett antal frågeställningar kommer komma upp som många känner igen sig i, och olika lösningsalternativ kan diskuteras fram. Genom att använda Open Space som format är alla med och väljer de diskussioner som är intressanta och relevanta för den situation de befinner sig i. Agil re-bootcamp ger en nystart och gör det lättare att ta ett steg till framåt, avslutar Tobias Fors entusiastiskt.

Premiär för Agil re-bootcamp är den 24 november i Fryshuset.

För information och anmälan: klicka här eller använd länk:
http://www.citerus.se/curriculum/385866-agil-re-bootcamp

För mer information
Karin Edström, VD Citerus AB
karin.edstrom@citerus.se
Tfn: 0733-225 227

Citerus hjälper sina kunder att lyckas med mjukvaruutvecklingen; antingen genom att utbilda och coacha, införa ett självstyrande ledarskap och ett lättrörligt arbetssätt eller genom att utveckla mjukvara åt dem. Allt för att de ska kunna hålla en hög innovationstakt och skapa smarta lösningar som ökar deras konkurrenskraft. Vi är ledande på Scrum, Java, Domändriven design och många andra metoder och tekniker i framkant.

www.citerus.se

Holländske Apello utvecklar svenska chefer i agilt ledarskap

Fri, 30 Sep 2011 12:31:10 GMT

Fritänkaren och författaren Jurgen Apello beskriver en ny nivå av ledarskap i boken Management 3.0, en bok som tagit världen med storm. Efter att ha drivit företag med hundra utvecklare ägnar han sedan publiceringen en stor del av sin tid åt att åka runt i världen som ledarskapskonsult. Han hjälper ledare att praktiskt kunna tillämpa bokens nydanande teorier om ett agilt - lättrörligt - ledarskap.

Agila arbetsformer som gör jobbet roligt

Jurgen Apello har analyserat vad det är som driver människor och hur en ledare genom att se dessa behov kan förbättra sitt ledarskap och få entusiastiska medarbetare. Han tar hål på myterna om dåliga ledare och ovilliga medarbetare genom att visa hur alla, med ett annat sätt att se på saker, kan bli bättre. Citerus har lyckats få Jurgen Apello till Sverige så att även svenska chefer kan ta del av de praktiska metoder som leder till ett framgångsrikt agilt ledarskap.

Agila metoder revolutionerar ledarskap

Ledarskapet är ett område som ofta glöms bort när man talar om agilt och lättrörligt arbete. När organisationer inför agil mjukvaruutveckling är det inte bara utvecklare, testare och projektledare som måste lära sig ett nytt sätt att jobba. Utvecklingschefer och ledare ska också lära sig ett nytt sätt att leda för att stimulera agila organisationer. Det här är en unik möjlighet för ledare och chefer att snabbt nå ett agilt ledarskap.

Kursen hålls 24-25 oktober, för information om kursen och Jurgen Apello, se Citerus hemsida

För mer information
Karin Edström, VD Citerus AB
karin.edstrom@citerus.se
Tfn: 0733 225 227

Turboladda din systemarkitektur med Domändriven design och CQRS

Thu, 29 Sep 2011 08:05:10 GMT

Det har gått mer än fem år sedan Eric Evans introducerade begreppet Domain-Driven Design, DDD, med sin bok Domain-Driven Design - Tackling Complexity in the Heart of Software. Boken samlade ett antal centrala begrepp inom framförallt objektorienterad analys, design och implementation under ett gemensamt tak och har på många sätt skapat nytt liv i tankarna runt design av mjukvara med tydligt avstamp i dess problemdomän.

Introduktionen av begreppen domänhändelser (Domain Events), och Event Sourcing är troligen de områden där Domändriven design har utvecklats mest under de senaste åren. Särskilt arkitektur baserade runt designmönstret Command Query Responsibility Segregation, CQRS har rönt stor uppmärksamhet under ett par år och är ständigt återkommande ämnen på konferenser som Øredev, DDD eXchange och QCon. Både den ordinarie och den extrainsatta workshopen om CQRS på årets upplaga av Øredev är utsålda långt innan konferensstart.

CQRS är i grunden, lite beroende på vem man frågar, ett sätt att tydligt dela upp metoder så att läsning (query) och kommandon (commands) indelas i olika klasser. CQRS kombineras ofta med andra mönster som Event Sourcing och Domain Events för att skapa systemarkitekturer där interaktion med applikationen sker via kommandon och händelser. Läsning skiljs tydligt från skrivning, inte sällan med olika modeller för dessa.

CQRS i kombination med Event Sourcing vänder till viss del upp och ner på etablerade sätt att designa system och utmanar hur vi ser på systemarkitektur. En design baserad på Event Sourcing och CQRS öppnar upp en hel del intressanta möjligheter som är begränsade i en mer traditionell CRUD-arkitektur. Det kanske mest omtalade är möjligheten att bygga applikationer som helt separerar läsning från skrivning och där dessa två aktiviteter kan skalas oberoende av varandra för att hantera mycket omfattande genomströmning av data. Tidigt i tankarna runt DDD ansågs dessa typer av applikationer, med mycket data och höga krav på prestanda, som mindre lämpliga för Domain-Driven Design, en uppfattning som CQRS och Event Sourcing har kommit att till stor del förändra.

En annan intressant egenskap hos dessa typer av arkitektur är att vi genom att spara våra inkommande händelser och kommandon kan spåra inte bara nuvarande systemtillstånd, utan även hur vi kom dit. Detta, i sin tur, leder till andra möjligheter.

Om vi till exempel stöter på produktionsproblem kan vi i en testmiljö återställa systemet i ett tidigare tillstånd och sedan lägga på alla sparade kommandon igen för att på så sätt spåra exakt vad som gick fel. Detta är något som ofta kan vara svårt att göra baserat enbart på loggningsdata.

Det kan också ge oss möjlighet att köra om gamla händelser och kommandon i nya versioner av mjukvaran, eller mot alternativa modeller, och på så sätt skapa nya affärsdata ur tidigare händelser.

Citerus kan nu erbjuda dig en utmärkt möjlighet att lära dig mer om DDD och CQRS i samarbete med Greg Young, en av de absoluta frontfigurerna inom området. Anmäl dig redan idag till Gregs legendariska tredagarskurs i Stockholm den 14-16 november. Kursen introducerar teorin bakom CQRS och Event Sourcing, men främst ligger fokus på att implementera DDD och skriva fungerande kod! Du tar med egen dator så att du kan utveckla i den miljö och det språk som du är mest bekväm med www.citerus.se/cqrs

Citerus pratar Agil Innovation på Entreprenörsgalan idag

Tue, 27 Sep 2011 09:25:53 GMT

Agil Innovation och Agil Expansion är begrepp som Citerus kommer prata om på Entreprenörsgalan 2011 idag. Agil Innovation innebär att ta hjälp av agila metoder, för att fokusera på affärsnytta genom design och utveckling av en första version. För att sedan klara en vidareutvecklings- och förvaltningsfas när kunderna strömmar till och affärerna tar fart, hjälper vår erfarenhet av Agil Expansion.

Agil Innovation

Agil Innovation handlar om att använda agila verktyg för att på ett flexibelt sätt fokusera på att maximera affärsnyttan, för att snabbt kunna gå från idé till handling. Detta för att kunna kommersialisera en affärsidé med begränsade resurser, i form av tid och pengar.

Agil Expansion

När den första lanseringen är klar gäller det att vara beredd på expansion. På nätet kan framgången gå extremt snabbt och då gäller det att vara förberedd så att alla delar kan expandera. Såväl processer som organisationen behöver ofta trimmas för att klara en sådan förändring.

Så här gjorde reco.se

Det lönar sig att ta hjälp när en briljant mjukvarubaserad affärsidé skall realiseras med begränsade resurser. Läs om hur Citerus hjälpte entreprenören Tobias Basilius på resan att vidareutveckla sin sajt reco.se för att möta kraven från hundratusentals besökare i veckan.

reco.se accelererar lättrörligt

Fri, 23 Sep 2011 08:57:31 GMT

Reco.se satsade på coachning och kunskapsöverföring för kvalitetshöjning

Det lönar sig att ta hjälp när en briljant mjukvarubaserad affärsidé skall realiseras med begränsade resurser. Fokus på affärsnytta skall behållas genom design och utveckling av en första version, till vidareutveckling och förvaltning när kunderna strömmar till och affärerna tar fart. Citerus har hjälpt entreprenören Tobias Basilius på resan att vidareutveckla sin sajt reco.se för att möta kraven från hundratusentals besökare i veckan. Det är ett exempel på hur entreprenörer kan dra nytta av Agil innovation och Agil Expansion, begrepp som Citerus kommer samtala om på Entreprenörsgalan 2011 (som arrangeras av Founders Alliance) tisdagen den 27 september. Agil Innovation handlar om hur lättrörliga metoder används för att snabbt kommersialisera en affärsidé, Agil Expansion handlar om att organisera sig för tillväxt.

Oberoende rekommendationer särskiljande

Det som skiljer reco.se från andra rekommendationssajter är att de har omfattande rutiner som förhindrar rekommendationer av egna affärsrörelser och smutskastning av konkurrenter. Betygen ges av riktiga, oberoende användare. Idag är det 110.000 besökare i veckan som betraktar reco.se som en god vän som ger bra tips.

Utmaning med explosionsartad tillväxt

Efter lanseringen växte sajten explosionsartat i antalet besökare, med allt större databas och fler funktioner. Eftersom idén är att användaren bidrar frivilligt måste alla funktioner upplevas som användarvänliga. Upptid är affärskritiskt och stopp eller långa svarstider får absolut inte förekomma.

För att klara tillväxt under tidspress gjordes kompromisser under utvecklingen av koden. Tack vare duktiga programmerare fungerade koden bra trots att den blev allt yvigare. Så sakteliga började dock uppdateringar i koden innebära att bieffekter uppstod, till synes utan samband med ändringen. Ibland blev svarstiderna långa och det hände till och med att sajten gick ned ibland. Entusiasmen hos användarna började dala. De återkommande larmen började tära på både utvecklare och ledning.

Målet blev att bit för bit återställa kvaliteten i koden samt att coacha och kompetensöverföra till det befintliga utvecklingsteamet. Tobias Hill från Citerus anlitades för detta och under mottot "ingenting är omöjligt" gjordes en lista av prioriterade punktinsatser. Under den dag i veckan han jobbade axel mot axel med recos.se's utvecklare betades listan av bit för bit. Dagen avslutades med guidning om vad som skulle göras fram till nästa besök.

Ifråga sätt allt

- Det Tobias Hill åstadkom på en dag i veckan hos oss var magiskt, säger Tobias Basilius, grundare av reco.se. - Han är väldigt okonventionell, vänder ut och in på allt, tittar fram- och baklänges, hittar nya perspektiv, inget är heligt. Han kan faktiskt vara riktigt jobbig med att även ifrågasätta teknikval, organisation och ledarskap. Men han löser problem effektivt och när jag med lite perspektiv ser förändringen känner jag en stor tacksamhet att han vågade utmana oss.

- vi hade en taktik att varje dag Tobias var här skulle vi attackera det mest relevanta problemet. Nästan alltid var det löst innan dagen var till ända, ibland hade även några andra problem eliminerats av bara farten, avslutar Tobias Basilius.

Lättrörligt arbetssätt accelerar nya idéer

Svårigheterna att tillföra nya funktioner är som bortblåsta och reco.se kan idag expandera utan växtvärk. Förr gjordes uppdateringar så sällan som möjligt eftersom det alltid blev problem. Idag görs de varje vecka vilket innebär att sajten förbättras lika ofta, utan någon oro. Tack vare stabiliteten och det lättrörliga arbetssättet kan förbättringar och nya affärsidéer hela tiden testas mot verkligheten. De affärskritiska svarstiderna har gått ned till en sjättedel och nedtid finns inte.

Hemsida reco.se: www.reco.se, hemsida Citerus: www.citerus.se

För mer information
Karin Edström, VD Citerus AB
karin.edstrom@citerus.se
Tfn: 0733- 225 227

Citerus hjälper våra kunder att lyckas med mjukvaruutveckling; antingen genom att utbilda och coacha, införa ett självstyrande ledarskap och ett lättrörligt arbetssätt eller genom att utveckla mjukvara åt dem. Allt för att de ska kunna hålla en hög innovationstakt och skapa smarta lösningar som ökar deras konkurrenskraft. Vi är ledande på Scrum, Java, Domändriven Design och många andra metoder och tekniker i framkant.

Agil Innovation

Wed, 21 Sep 2011 11:35:24 GMT

Sätt affärsnyttan i fokus när innovationer skall realiseras!

Det är ett stort steg från att vara en driven entreprenör med affärs- och marknadsfokus, till att ha kunskap om verktyg och metoder för hur man verkligen gör i praktiken för att sätta affärsnyttan i fokus. Fokus på reell affärsnytta skall behållas genom hela kedjan; under design-, krav- och utvecklingsprocesserna - i nära anslutning till kundernas behov. Om detta kommer vi samtala med entreprenörer och innovatörer på Entreprenörsgalan som anordnas av Founders Alliance för tionde året i rad.

Det krävs erfarenhet och träning av hur man praktiskt gör för att som entusiastisk entreprenör faktiskt hålla fokus. Det underlättar, om man har några praktiska och beprövade verktyg till sin hjälp.

Lättrörliga - agila - metoder, är idag relativt väl förankrade såväl i mjukvaruindustrin (företrädesvis Scrum) som inom delar av tillverkande industrin (Lean och Kanban). Samtliga metoder har sin grund i några gemensamma principer.

Dessa principer ämnar sig mycket bra som stöd för innovationsföretag i dess uppstartsfaser. Att gå från en idé till färdig tjänst eller produkt är en snårig bana. Att ha metoder och verktyg för att få hjälp att fokusera på prioritering av krav där realiserad affärsnytta står i centrum, skulle hjälpa många innovatörer och entreprenörer att komma till nästa nivå i sitt företagande, dvs kommersialiseringsfasen. Många utvecklingsprojekt som använder Scrum som metodik, levererar användbar programvara var 14:e dag. I ett uppstartsläge kan detta vara enda chansen till överlevnad!

Jag vill introducera begreppet Agil Innovation. Det vill säga hur man kan ta hjälp av agila verktyg och metoder för att underlätta det innovativa arbetet. Låt mig konkretisera: På Citerus hjälper vi ofta snabbväxande företag och har under åren fått otaliga bevis för hur man genom att ta hjälp av verktyg och metoder från den agila världen snabbare kan visa marknaden sina idéer i form av demobara prototyper.

Begreppet "Minimum Viable Product" är centralt för alla som jobbar med innovation som behöver finansieras. Fokus på MVP innebär att du designar din produkt för att visa det som är viktigt att bevisa och därmed skapar ett fundament för en affär eller finansiering. Det kan du ofta göra med mycket mindre resurser än vad du tror.

Det handlar om att snabbt kunna få feedback från kunder och användare, genom att faktiskt kunna se hur de använder produkten, och om de återkommer. Därmed kan man iterera sig fram till en kommersiellt gångbar produkt.

Under mina år i branschen, har jag alltför ofta sett motsatsen; där man antingen låter idén stanna vid en powerpointpresentation för länge, eller att man spenderar allt för lång tid (och för mycket pengar) innan man har en produkt som kan visas upp för omvärlden. Förändringar och justeringar kostar då förödande mycket, både tid och pengar.

Jag vill påstå att Agil innovation bör läggas till listan över inspel för hur vi tillsammans kan jobba för att säkerställa att bra idéer kommersialiseras tillräckligt snabbt och i tillräckligt hög utsträckning.

Karin Edström, VD Citerus AB
karin.edstrom@citerus.se
+46 733 225 227

"Citerus - frigör kraften i mjukvara åt alla som har en vision"

Varför Clojure?

Mon, 19 Sep 2011 12:40:18 GMT

Clojure är ett av de många nya JVM-språk som börjar få fotfäste bland utvecklare. Som Lisp-dialekt så skiljer sig dock Clojure ganska mycket från många andra språk, och programmerare med Javabakgrund verkar inte sällan uppleva språket så pass annorlunda att de instinktivt ryggar tillbaka. Det är lite synd tycker vi på Citerus då det finns många bra anledningar att titta närmare på Clojure. Några av de frågor jag ganska ofta får när jag föreläser eller hamnar i samtal runt språket är funderingar runt varför man ska använda Clojure. Vad man ska ha det till? Vad är det bra på?

På Jfokus 2009 fick jag frågan vad det var med just Clojure som gjort att jag fastnade för språket. Svaret blev då spontant ganska känslobaserat. Första gången jag kom i kontakt med Clojure var under en presentation av Rich Hickey, och det var något i språket som i stort sett omedelbart tilltalade mig. Minnen från gamla universitetskurser i ML kom tillbaka. Elegansen i den funktionella programmeringsmodellen blev tydlig.

Jag laddade direkt ner Clojure och började utforska språket. Jag fick den känsla som jag tänker mig att många personer som fastnat för Ruby har; en känsla av att allt på något sätt känns naturligt och det blir omedelbart oerhört kul att programmera igen. Jag lyckades aldrig frambringa denna passion för Ruby trots att jag verkligen försökt flera gånger. Men med Clojure så kändes väldigt mycket rätt, även om inlärningströskeln inte på något sätt varit låg. Trots att verktygen är relativt primitiva, utbudet av bibliotek och tredjepartskomponenter liten och mycket måste skrivas från början så kunde jag komma långt på kort tid. Det var kul, och jag kände mig produktiv. Dessutom var Clojure-gemenskapen väldigt välkomnande och hjälpsam.

Nu tenderar rent känslomässiga argument kanske att fungerar lite sämre som beslutsunderlag för att få en organisation att ta till sig ny teknik och nya arbetssätt. Det får helst finnas andra argument, som upplevs lite mer rationella. Som tur är så saknas det inte argument av den typen för Clojure.

Utrycksfullhet

Clojure är uttrycksfullt och i grunden designat för att vara enkelt. Detta ger ett väldigt kraftfullt språk där mycket som kan upplevas som onödig ceremoni tagits bort. Det låter oss lägga fokus på det faktiska domänproblemen, och gör att vi mer effektivt kan styra bort från teknisk komplexitet. De funktionella aspekterna av Clojure, så som stöd för högre ordningens funktioner, bidrar även de till att språkets uttrycksfullhet.

Java som plattform

Genom att köra på JVM:en finns en robust och effektiv exekveringsmiljö redan på plats som är extremt väl spridd och accepterad. Genom sömlös integration med Java finns möjlighet att nyttja redan existerande tredjepartskomponenter, samtidigt som nyutvecklad Clojurekod enkelt kan integreras med existerande lösningar och miljöer. Clojure finns nu även i en version för exekvering på JavaScript-tolkar, ClojureScript.

Samtidighet

Det som ofta framförs som en viktig del av Clojures tänkta tillämpningsområde, är parallellisering och hantering av samtidighet. Under de senaste åren har utvecklingen mot snabbare och snabbare processorer bytts mot en utveckling som går mot fler och fler kärnor. En modern bärbar dator av i dag kan ofta vara bestyckad med en fyrkärnig processor, inte sällan med någon form av hyper-threadingteknik. Till och med telefoner och surfplattor kommer idag med flerkärniga processorer. Man kan argumentera för att många befintliga språk, så som Java, är mindre lämpade för att skapa de program som krävs för att till fullo utnyttja den kapacitet som flerkärniga processorer erbjuder.

Clojure är designat runt den funktionella programmeringsparadigmen. Datastrukturerna är persistenta, oföränderliga, och det finns en fullständig tanke runt identitet, tillstånd och tid. Bara det att man arbetar med icke muterbara datastrukturer hjälper långt i att hantera samtidighet. En icke muterbar datastruktur är trådsäker.

Funktionell programmering

Clojure är ett programmeringsspråk för funktionell programmering. Funktionell programmering är till stor del deklarativ, det låter oss fokusera på vad vi vill göra framför hur det ska göras. Stöd finns förstås i språket för högre ordningens funktioner, och datastrukturerna är icke muterbara. Att datastrukturer inte går att förändra efter att de är skapade, tillsammans med fokuseringen på rena funktioner, gör mycket för att hålla ner komplexiteten i program och underlätta parallellisering. Inom Domain-Driven Design förespråkar vi använding av värdeobjekt mycket på grund av detta, men det är svårt att få till i språk som Java. I Clojure får vi det som en integrerad del av språket.

Lisp

Många har starka åsikter om Lisp. Förutom ett par rader som jag klistrade in min .emacs-fil tidigt under våren 1996 hade jag ingen tidigare erfarenhet av Lisp innan jag kom i kontakt med Clojure. Släktskapet med Lisp gör Clojure annorlunda, och med det kommer några riktigt spännande möjligheter.

“Data som kod”, eller homoiconicity, och makron är ett par koncept som är starkt förknippade med Lisp. Det är koncept som kanske inte är helt enkelt att vrida sin hjärna runt, men när man väl börjar förstå vad det är och hur det kan användas så öppnas helt nya möjligheter. En konsekvens av denna egenskap, och att Clojure numera går att exekvera både på JVM:en och i en JavaScriptmiljö, är att vi kan använda samma språk för att uttrycka klientkod, serverkod och den data som flyttas mellan klient och server utan behov av mellanformat så som JSON eller XML.

Om du ännu inte kikat på Clojure så är det verkligen något som jag kan rekommendera Bli inte avskräckt över att det ser så annorlunda ut. Särskilt om du, som jag, har varit helt inne i en objektorienterad värld de senaste åren så är det ett fantastiskt sätt att vidga sina vyer och få nya perspektiv!

Ett urval av länkar

Stuart Halloway - Clojure, http://oredev.org/videos/clojure. En introduktion till Clojure och varför språket är viktigt, från Øredev 2009.
Rich Hickey - Are We There Yet?, http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey. En mycket spännande diskussion om identitet, tillstånd och tid som på många sätt utmanar etablerade sanningar runt tillstånd och OO, av Clojures skapare.
Paul Graham - Revenge of the Nerds, http://www.paulgraham.com/icad.html. En intressant diskussion om programmeringsspråk, och om det verkligen spelar någon roll vilket språk man använder. Från den kanske störste Lisp-förespråkaren av dem alla.
sthml.clj - Stockholm Clojure User Group, http://groups.google.com/group/stockholm-clojure-user-group. Användargrupp för Clojure i Stockholmsområdet

Bellmanstafetten 2011

Sun, 28 Aug 2011 20:56:28 GMT

I år lyckades vi få i hop två lag med deltagare som i nytryckta Citeruströjor avverkade de totalt 25 kilometrarna. Och till skillnad från förra året när det var kallt och mörkt fick vi i år en tävling i fantastisk väder med en skön efterföljande picknick i solen.

Nästa år satsar vi på tre lag i Bellmanstaffetten - hör av dig om du vill vara med! Under tiden laddar vi om inför Hässelbyloppet i oktober.

Agila kurser i Västerås och Linköping

Fri, 26 Aug 2011 08:21:53 GMT

Vi ser att agil/lättrörlig utveckling vinner fäste i allt fler organisationer och behovet av att utbilda personer till Scrum Master ökar över hela landet, säger Karin Edström, VD på Citerus. Att vara borta från jobbet två kursdagar klarar de flesta men med besväret kring resor och boende ser vi att det finns en tröskel mot att utbilda sig, en tröskel som vi nu tar bort för Mälardalen och Linköpingsregionen. Som ambassadörer för agila utvecklingsmetoder är det min förhoppning att fler företag och människor ska få del av fördelarna i form av högre effektivitet och pålitlighet, avslutar Karin.

Citerus lärare är certifierade av Scrum Alliance och de arbetar själva som konsulter med att införa och förbättra lättrörliga metoder.

Kurserna erbjuds följande datum:

Göteborg 30-31 augusti
Västerås 18-19 oktober
Linköping 22-23 november

Kursinformation hittar du på: www.citerus.se/kurser

För information om kurser:
Pär Buskas, 0736 - 20 44 80
par.buskas@citerus.se

För information om Citerus:
Karin Edström, 0733 - 225 227
karin.edstrom@citerus.se

Citerus är ett konsultföretag som hjälper sina kunder att lyckas med mjukvaruutveckling. Sedan 1996 har Citerus utvecklat mjukvara, lett projekt, förbättrat utvecklarpraxis och förfinat ledningsmetoder åt företag från många olika branscher. Citerus är experter på agila (lättrörliga) utvecklingsmetoder såsom Scrum, Domändriven design, Kanban och Lean. Citerus uppnår resultat genom att höja kvalitetsribban, sätta människor i första rummet och minska byråkratin.
www.citerus.se

Vad är återblickar?

Thu, 11 Aug 2011 10:15:04 GMT

Lättrörliga, eller agila, metoder har blivit ett vanligt sätt att arbeta i mjukvaruföretag idag. En central del i lättrörliga metoder är fokuset på lärande och förbättring. Med lättrörliga metoder bygger vi inte bara produkter av hög kvalitet, vi bygger också ökad kapacitet i våra organisationer.

Jag pratade med en utvecklare på ett stort produktföretag om det här med innovation och idéer. Han hade flera lovande idéer som han gärna ville utforska vidare, men fick inget gehör för dem. Jag frågade honom hur det kändes. Föga överraskande svarade han att det fick hans motivation att sakta dala.

För att en idé skulle anammas i företaget krävdes att den kom från rätt, officiellt håll. I det här fallet betydde det att de skulle komma från en chef på en viss nivå. Jag frågade om han trodde att det fanns fler som satt på idéer som inte togs tillvara. Han svarade att han trodde att nästan varenda en av hans kollegor hade en toppidé som bara låg och ruttnade bort i en byrålåda någonstans. När man försökt lyfta sin idé några gånger och misslyckats gav man helt enkelt upp.

Hur ser det ut i ert företag? Har ni en mekanism för att fånga upp idéer om såväl produkt- som processförbättringar? Hur gör ni för att undersöka vilka resultatförbättrande åtgärder era kollegor har tänkt ut, men ännu inte fått gehör för? Hur gör ni för att utvärdera dem, förankra dem och planera för deras genomförande?

Regelbundna återblickar är ett sätt att tillsammans utvärdera och förbättra verksamheten. Till skillnad från expertdrivna eller toppstyrda förbättringar, bygger återblickar på att engagera de som gör jobbet i förbättringarna. Det finns flera positiva effekter av det:

Det bygger engagemang för förbättringarna
Sannolikheten för att förbättringarna genomförs och accepteras ökar
De hjälper deltagarna att se saker och ting ur olika perspektiv

Hur fungerar en återblick rent praktiskt? Det krävs ingen svartkonst för att lyckas göra återblickar effektiva, men det krävs tålamod och uthållighet. Med lite hjälp kan ni lätt sätta ihop ett grundformat för era återblickar som ni kan använda under till exempel ett halvår, för att sedan utvärdera och förbättra det allt eftersom ni lär er mer om vad som fungerar bra för er.

Den som handleder en återblick behöver sätta sig in i vad som får en återblick att bli effektiv. En skicklig handledare fokuserar på att:

Skapa en miljö i återblicken som är trygg, så att deltagarna törs säga vad de tänker
Engagera gruppen med hjälp av interaktiva och ändamålsenliga övningar
Fånga upp det som sägs så att det inte går förlorat
Hjälpa gruppen omsätta sina idéer till en konkret och överenskommen handlingsplan

Ett sätt att lära sig mer om återblickar är att undersöka om det redan finns någon i organisationen som använder dem. I så fall kan man fråga om det går bra att delta som, helt tyst, observatör vid några tillfällen. Kanske kan också den som leder de återblickarna hjälpa din grupp med handledningen de första gångerna, så att ni blir varma i kläderna. Ett annat sätt är att ta hjälp av en erfaren extern handledare, dels för handledning de första gånger, dels för att hjälpa er att ta fram ett grundformat för era återblickar.

Rätt utförda är regelbundna ett effektivt sätt snabbt omsätta den kunskap och kreativitet som finns i organisationen till lösningar på både små och stora problem. Återblickar är med andra ord en bra affär rent ekonomiskt.

Närproducerat och kravmärkt är bättre!

Fri, 17 Jun 2011 09:13:48 GMT

Citerus är ett exempel på den typ av konsultbolag som nämns; vi är betydligt mindre än jättarna i branschen och består till övervägande del av konsulter med 10-15 års erfarenhet. Våra konsulter har dessutom jobbat tillsammans under en stor del av dessa år. Det gör att vi kan erbjuda våra kunder ett färdigt team som vi inte bara tror – utan vet – är långt mer effektivt än de flesta team som sätts ihop tillfälligt, ofta med en mix av anställda och timkonsulter.

Genom att anlita erfarna konsulter i sammansvetsade team, får man inte bara tillgång till best practices avseende tekniska vägval och kodning. Aktörer som Citerus har mycket lång erfarenhet av hur man jobbar med helheten; från att samverka med verksamheten för att på så sätt utgå från domänkunskapen när systemet eller funktionen designas, via effektiva kravformuleringsprocesser till att jobba med effektiva metoder för prioritering av arbetet, där affärsnytta alltid skall ha en framträdande plats.

Hur teamen jobbar med estimering och planering av sitt arbete, samt hur integration av den färdiga koden sker, påverkar i allra högsta grad såväl kvalitet som produktivitet. Genom att kombinera standardverktyg för enhetstestning, versionshantering och automatisering av byggprocessen kan man åstadkomma en byggmiljö som garanterar den tekniska kvaliteten i koden. Vi ser alltför få företag därute som jobbar kontinuerligt och långsiktig på detta område.

Samtliga moment i kedjan ovan kräver erfarenhet för att behärska och en förmåga att kombinera kunskapen till en helhet. Att höja och strömlinjeforma nivån kring Engineering Practices tar tid, och för varje gång team slås isär och sätts ihop igen kommer nya synsätt in som ger olikheter i den färdiga koden. Det är inte realistiskt att förvänta sig av juniora utvecklare som sätts samman i nya team skall kunna vara produktiva på en nivå som ens är jämförbar med ett samspelt team av erfarna konsulter. Detta har inget med den enskilde konsultens kompetens att göra, vi har förmånen att varje dag jobba med begåvade yngre utvecklare. Vi lär oss av dem lika ofta som de lär av oss.

Att adressera missade deadlines i projekten med att öka antalet utvecklare i teamen, ger sällan önskad effekt. Att outsorca utveckling till låglöneländer fungerar i vissa fall, när kraven är enkla och utrymmet för missförstånd litet. I de projekt där vi är involverade ser det sällan ut så. En kontinuerlig, ständig och nära dialog är en förutsättning att resultatet skall bli det önskade.

Därför erbjuder vi på Citerus ett närproducerat och kravmärkt alternativ till den traditionella outsourcingen; sammansvetsade, erfarna team på lättrörliga kontrakt, där fokus är att leverera prioriterad affärsnytta - inte att sysselsätta så många konsulter som möjligt!

Karin Edström
VD, Citerus AB

Citerus frigör kraften i mjukvara åt alla som har en vision

Läs mer

Störst är inte alltid bäst, ledare i Computer Sweden 7 juni 2011