Projektberoenden måste kanske inte göra ont

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.