Sedan jag först började läsa om agila metoder har jag uppskattat tanken att sitta tillsammans som något självklart och ovedersägligt.

Efter ett par försök på olika håll tycker jag mig se ett par återkommande mönster för vad som får tekniken att fungera bättre.

Gemensamma intressen

För att det ska löna sig för en grupp människor att sitta tillsammans krävs att de har något gemensamt. De bör arbeta i samma projekt, mot samma deadline och samma kodbas.

Därför

Forma team som arbetar i grupp mot gemensamma mål, och placera dem tillsammans.

Men

Tänk på att inte forma för ensidiga team — Gemensamma intressen betyder inte att alla gillar att knacka Ruby, utan att alla strävar mot samma mål och hjälps åt att komma dit. Tvärfunktionella team innehåller alla kompetenser som behövs för att leverera en färdig produkt.

Lagarbete

Ola Ellnestam beskriver ett anti-mönster som han kallar för The Graveyard:

Föreställ dig ett rum, ganska stort. Ungefär 100 kvadrat. Du kan knappt höra surrandet från ett halvdussin datorer. Det är varmt, inte hett, bara lite över normal rumstemperatur. Någon hostar. Sedan blir det tyst igen, förutom det svaga surrande datorljudet. Du lyssnar lite noggrannare och märker ett svagt, oregelbundet klickande. Du får en känsla av att den som är källa till ljudet inte vill störa för mycket. Ljuset i taket flimrar till.

Du sveper snabbt med blicken över rummet, räknar till 1, 2, 3 … 7 sittande personer. De verkar stirra ut i tomma rymden, och det hade de också gjort om det inte vore för datorskärmarna framför dem. Det är som om det stod glasväggar mellan personerna i rummet. En dator står längst ner i rummet. Skärmsläckaren snurrar förbi lite text.

Förutom Gemensamma intressen blir det mycket mer värdefullt att sitta tillsammans om man faktiskt jobbar som ett lag istället för som en grupp individer. Man blir mindre beroende av nyckelpersoner, eftersom alla har hygglig inblick i vad som händer.

Därför

Som Ola säger, uppmuntra Lagarbete och kommunikation genom att hitta rutiner som får flera personer att jobba på olika aspekter av samma uppgift.

Men

Ett väl fungerande Lagarbete är svårt att skapa på syntetisk väg. Var försiktig så att eventuella knuffar för att stimulera lagarbete inte hindrar teamets naturliga sätt att arbeta.

Storleken har betydelse

Kommunikationen sägs bli bättre av att sätta gruppmedlemmar fysiskt nära varandra, så att de kan använda högeffektiva kommunikationsmedier — tal och ansiktsuttryck — och uppnå osmotisk kommunikation.

Det är dock svårt att skala det här — större grupper kommunicerar mindre effektivt och det blir svårare för medlemmarna att socialt knyta an till hela gruppen.

Därför

Ge dina team Gemensamma intressen, så att de har något att kommunicera kring, men inte så stora mål att de behöver vara fler än 5-9 personer.

Men

Om ditt team av någon anledning måste vara stort, försök introducera tekniker och regler för att minimera störningar (både inifrån och utifrån), maximera kommunikationsmöjligheterna och stimulera social interaktion.

Privat sfär

Jag har vid ett par tillfällen suttit i jättebra grupper, med Gemensamma intressen och lagom storlek, men två meter ifrån vår arbetsyta har ett annat, mycket mer högljutt team (med tråkig humor) suttit och förpestat lugnet. Som jag minns det var vi väldigt tysta och skötsamma, men något säger mig att de tänkte samma sak om oss.

Därför

Isolera team från varandra genom att ge varje team ett eget rum där de inte störs av buller från utomstående. Alternativt, möblera med skärmar och whiteboards så att teamet får vara någorlunda ifred från störmoment.

Men

Att team är fysiskt avskilda från varandra till vardags betyder inte att de ska sluta kommunicera, bara att de ska undvika att störa varandra med slumpmässigt oljud.

Telefonrum

Om jag delar rum med fem personer och min fru ringer för att fråga om deklarationen vill jag helst inte prata inför mina kolleger. Eller om jag behöver ringa för att boka en läkartid eller bara snacka med en kompis. Dessutom finns det få saker som är så störande för omgivningen som någon annans mobiltelefonsamtal.

Därför

Se till att varje team har ett dedikerat rum med dörr som är avsett för privata telefonsamtal. Om lokalerna tryter, låt flera team dela på ett telefonrum. Vi har ett litet konferensrum som man inte kan boka, men som ockuperas för mindre möten. När det är ledigt används det flitigt som telefonrum, annars hänger folk ganska oblygt i korridoren.

Det viktigaste är att folk inte känner sig utsatta när de sköter sina personliga förehavanden, och att deras kolleger inte störs om de saknar normala telefonspärrar.

Samfälliga avbrott

När någon utomstående kommer in i gruppens rum för att prata med en enskild medlem avbryts och störs alla medlemmars arbete. Ofta tror den som frågar att den har korn på vem som vet mest, men lika ofta visar det sig att gruppen tillsammans vet mer än någon enskild medlem, särskilt om gruppen ägnar sig åt Lagarbete

Därför

Arbeta för att utomstående inte ska tilltala enskilda medlemmar om arbetsrelaterade saker, utan hela gruppen — alla är ändå inblandade konversationen, från det att någon säger ”Hörru, Kim, jag undrar…”.

Men

Om det rör privata angelägenheter, lämna gruppens arbetsyta, för att störa så lite som möjligt.

Slutsats

Som alla tekniker fungerar samsittning olika bra i olika sammanhang. Efter ett gäng bra och några dåliga erfarenheter vill jag driva tesen att fokuserat lagarbete i en mindre grupp i alla fall är en bra start.

Ständigt återkommande teman ovan är Gemensamma intressen, Lagarbete och kommunikation.

Kommunikationen ses ofta som den stora fördelen med att placera grupper tillsammans, men jag tror inte förbättrad kommunikation kommer gratis, den är avhängig flera andra aspekter av teamets samarbete.

Jag har haft stora problem i mitt liv med att skilja på de engelska termerna accuracy och precision — jag väljer att översätta det med korrekthet och noggrannhet.

Min tvååriga dotter visade idag exakt hur de skiljer sig.

Accuracy or precision?

Hon berättade att den stora klumpen till höger, som ser ut som en potatis, var en lång dator. Liksom de små spetsiga grejerna mitt på ritbrädan, förutom en, som var en bil.

Då slog det mig. Hennes ritande är inte särskilt korrekt — accurate, men hon är en fena på att rita små, minutiösa detaljer med stor noggrannhet — precision.

Wikipedias definition talar om sanningsenlig vs. reproducerbar, men det är ju inte alls lika bedårande.

När jag funderar på vad som är viktigt för att lyckas med mjukvarudesign återkommer jag ganska ofta till god språkkänsla. Jag har tidigare hävdat att en av de viktigaste kvalitéerna i god design är bra namngivning, men också att vara konsekvent i sitt uttryck (problemlösande) och inte vackla mellan olika stilnivåer (abstraktionsnivåer).

Och samma gäller egentligen för att kunna förstå programkod — vad termer betyder, hur element passar i sitt sammanhang.

Jag berömmer mig själv med att vara ganska bra på engelska, men jag märker att jag under åren tappat ganska mycket fart för att jag missförstått eller inte alls förstått grundstenar i tredjeparts-API:er och datavetenskapslitteratur. Så mycket av vår vetenskap genomsyras av metaforer att det är rätt tufft att hänga med om man inte är intresserad av att förstå och även av att kunna uttrycka sig.

Men det här gäller nog inte bara den tekniska sidan. Hänvisningar till och vikten av språk återkommer hela tiden i XPs system av tekniker och värderingar (t.ex. Metafor, User Stories, Kommunikation som en del av värdegrunden).

Jag snubblade idag över någon som beskrev en enkel retrospektivövning där varje deltagare ombeds att med ett ord beskriva sina känslor inför en nyss avslutad iteration. Det finns ju professionella författare som hade haft stora besvär med att åstadkomma det.

Vi har en engelskspråkig gruppchef, och jag märker att våra gruppmöten ofta blir lite tysta. Folk är inte rädda för att prata, men tröskeln är högre för att dra ett skämt eller försvara en ståndpunkt på något annat än sitt modersmål, även om alla är väldigt duktiga på engelska.

Knepigt.

Det verkar på det hela taget som att man som systemutvecklare borde vilja slipa sin språkkänsla, så att man lättare kan ta in den massiva ström av metaforer som möter oss dagligen. Förmodligen på engelska.

Men vi borde också vilja träna oss på att uttrycka känslor och önskningar med hjälp av metaforer och andra tekniker, för att effektivt kunna kommunicera med vårt team. Kanske på svenska, kanske på firmans koncernspråk, men åtminstone på teamets Lingua franca.

Språk ger inte bara makt utan är också en väg till inflytande. Jag försöker bättra mitt språk genom att läsa mycket skönlitteratur och skriva lite rappakalja i bloggformat. Vad gör du?

Beroenden mellan projektgrupper verkar svårt att hantera (det kan vara ett lokalt problem, men jag väljer att låtsas att det är mer allmängiltigt).

Även om små, sammanhållna och seriella projekt verkar vara en ganska populär strategi kan jag ganska sällan i min roll som tjurig utvecklare styra hur projektportföljen ska förvaltas. Däremot har jag en del chanser att påverka hur arbetet fortlider när projekten väl är igång.

Fowler presenterar en intressant modell där SOA-tjänster utvecklas i open source-stil, så att team i beroendeställning kan agera patch-bidragsgivare till en tjänst de är beroende av.

Jag tror inte det här behöver vara specifikt för SOA-sfären, utan snarare att  projekt som använder tjänsteorienterade arkitekturer kanske karakteriseras av en viss storlek och flera parallellt aktiva team. Det vill säga; alla projekt över en viss storlek (mer än ett team) skulle kunna koka ihop något i den här stilen oavsett vilken arkitekturstil de råkar använda.

Fowlers vårdnadshavarmodell har mekanismer för att provocera fram kommunikation mellan två team i ett beroendeförhållande och det skulle man kunna spinna vidare på.

Exempelvis, genom att så länge det finns ett beroende i någon riktning kräva en aktiv representant på varandras dagliga stå-möten. Det borde stimulera teamen att hålla varandra uppdaterade på sina respektive behov och planer.

Eller genom att arrangera utbyte mellan teamen så att teamet i beroendeställning får en representant som kan arbeta med deras behov i deras kontext. På så sätt ökar man chanserna dramatiskt att rätt problem löses på rätt sätt.

Ett fokus på kommunikation och samarbete torde kunna mildra problembilden väsentligt.

Jag kanske är tjurig och enslig, men jag gillar inte teambuilding i eventformat. Jag tycker inte öl och pilkastning i skogen för mig närmare mina kolleger på ett sätt som gör att vi kommer att jobba bättre tillsammans.

Sociala aktiviteter utanför arbetsplatsen kan vara roligt, men jag ser ett par problem:

1. det förekommer som regel alkohol och att finna laganda och samhörighet under påverkan kan fungera, men det finns också en väsentlig risk att folk blir osams eller gör något oöverlagt som de ångrar på måndag morgon, och som deras kolleger kan fnissa åt när de hämtar kaffe
2. teambuilding-aktiviteter gör anspråk på folks fritid under förespegling att det är något roligt som firman bjuder på, inte något som långsiktigt ska gynna företaget genom att teamen cementeras
3. att prata jobb när man äntligen är borta från eländet ses som tabubelagt

Jag förstår tanken med att stärka relationen mellan teammedlemmar genom att stimulera ett mer personligt umgänge, men jag tror det är svårt att trigga folk att öppna sig på beställning.

Min övertygelse är att teambuilding sker bäst genom att låta team arbeta och lösa problem tillsammans och få förtroende för varandra i en arbetssituation.

Det här är bara en känsla jag har, är det någon som vet om man har granskat hur effektiv modern teambuilding egentligen är?

Michael Feathers skrev nyligen om förhållandet mellan apelsiner och duplicerad kod. Han jämför kod med fruktkött och strukturelement med de tunna hinnor i en apelsin som håller ihop köttet i klyftor.

Det här angränsar till min teori om ration mellan kod- och strukturelement som mått på kvalitet, men istället för att, som undertecknad, blankt hävda att mer struktur är bättre ställer sig Feathers frågan om det finns en optimal ratio. En lite mer mogen inställning.

Det skulle vara intressant att göra lite empiriska mätningar. Mot alla instinkter skulle jag vilja  börja med Java, för jag tror det finns en högre grad av objektorienterade open-source-applikationer skrivna i Java (FitNesse, t.ex). Undrar vad det finns för bra bibliotek för att parsa Javakod…

Ju mer kod jag läser, desto mer märker jag att riktigt lättläst kod kännetecknas av ett par enkla karaktärsdrag:

• Den har väl namngivna element — om vi lindar vår kod i bra, betydelsebärande namn är det väsentligt enklare att hitta den och navigera runt i den.
• Den är konsekvent — man löser liknande problem på liknande sätt och har en konsekvent kodstil.
• Den håller samma abstraktionsnivå inom varje strukturelement — alla metoder i en klass bör vara på samma abstraktionsnivå, alla uttryck i en metod likaså.

Jag inbillar mig att detta är enklare att förklara än design-mönster, koppling och sammanhållning och SOLID-principer, och jag tror att de här ledstjärnorna tar oss nästan hela vägen fram.

Kod skriven enligt dessa principer är inte nödvändigtvis väldesignad, men den kommer utan tvekan att vara lätt att förstå. Och kod man kan begripa kan man som regel också ändra på.

Kortis idag: jag har retat mig lite på att jag inte kan klicka på mailto-länkar i webbläsaren utan att Outlook dras igång på maskinen.

Jag hittade diverse add-ons till Firefox innan jag upptäckte att man i senare revisioner av Firefox faktiskt kan välja GMail som mailto-hanterare.

Det tackar vi särskilt för!

I väldesignad kod ser man ofta att mängden sammanhängande (jag använder en eufemism sedan ”procedurell” blivit ett skällsord) kod går mot noll, och mängden strukturelement mot oändligheten. Med ”strukturelement” menar jag språkets definitionselement — för typiska OO-språk skulle det vara klass- och metoddefinitioner.

Den här tendensen förstärks t.ex. av objektorienterade designmönster, som i sin iver att utnyttja polymorfism ökar antalet klasser för att kunna minska mängden villkorslogik.

Se på ett litet C++-program:

class Greeting
{
public:
  Greeting(const std::string& target)
    : m_target(target)
  {
  }

  void Utter(std::ostream& channel)
  {
    channel << "Hello " << m_target << "!";
  }

private:
  std::string m_target;
};

int main()
{
    Greeting greeting("Dolly");
    greeting.Utter(std::cout);
    return 0;
}

Vi har egentligen bara tre rader procedurell kod här, implementationen av Greeting::Utter och användandet av Greeting i main. Det betyder att 20 rader består av strukturelement. Av dem innehåller i sin tur tre (Greeting, Utter och main) namn som skänker någon sorts betydelse till programmet. Resterande 17 är mest syntaktiskt oväsen.

Fast jag hade inte tänkt smutskasta C++ & co här, läs Fowlers artikel för mer tankar om olika språks uttrycksfullhet.

Snarare vill jag kasta ut en fundering: skulle man kunna använda ration mellan strukturelement och kodelement som ett mått på designkvalitet? Något säger mig att det skulle funka ganska bra för språk som C++, Java och C#…

John Carter beskrev en teknik på TDD-listan för ett tag sedan, som jag tog djupt intryck av.

Han beskriver någon sorts fattigmans Design By Contract, som i vaga ordalag går ut på att man strösslar assertions i sin kod för att beskriva antaganden.

Det Carter säger, och som jag till slut förstod, var att detta egentligen är samma sak som en assertion i ett enhetstest — bara inbäddat i koden. Vad jag inte hade skänkt så mycket eftertanke var att dessa assertions, precis som dem i enhetstester, faktiskt möjliggör säkrare refactoring.

Jag vill kalla det här för intra-testning, eftersom systemet i någon mån verifierar sig självt (jag var sugen på endo-testing, men det visade sig vara upptaget. Skit också.)

Vi kanske inte ska kasta xUnit till grisarna riktigt ännu. Förutom att beskriva antaganden är en solid test-svit också ett överlägset sätt att automatiskt köra igenom all kod som täcks av testerna i de spår som dragits upp av testfallen. Att lämna assertions i vår produktionskod ger oss fortfarande inget stöd i att driva den maskinellt.

Men jämför med hur du skulle testa en förändring utan vare sig tester eller assertions. Manuellt, eller hur? Peta och klicka lite, kolla så att allt ser rätt ut? Utan automatiserade tester är det det bästa vi har för att driva systemet, men genom att lägga till intra-testning kan vi ersätta trött okulär besiktning med automatisk evaluering av systemets tillstånd.

Jag säger inte att man bör föredra intra-testning framför enhetstestning, men jag tror att det kan användas för att göra de första penseldragen stadigare när man omarbetar otestad kod för att kunna få den under test.

Michael Feathers nämner aldrig den här tekniken i Working Effectively With Legacy Code, men den hör nog hemma tillsammans med de andra under rubriken ”How do I know that I’m not breaking anything?” som beskriver diverse sätt att bryta beroenden.