På företaget jag jobbar är vi två mjukvaruutvecklare och 2,5 till som agerar säljare och support. Alltså ett för sin verksamhet väldigt litet företag.
Vi håller på att titta runt efter en lämplig metodik att göra mjukvaruutveckling på. Har kikat lite på Extreme Programming (tillsammans med Scrum för projektstyrningen), men nästan alla såna här metoder kräver minst 15-20 personer för att fungera fullt ut.
Finns det någon metodik som är lättare att applicera hos mindre företag, där utvecklarna även blir som projektledare? De andra har i princip ingen insikt i programmering, så det är svårt att flytta över något sånt ansvar dit.
Tips? Idéer?
Metod för programutveckling för mindre företag?
Rekommenderar boken "Projektboken"(Anders Marttala, Åke Karlsson) och "Arbetsgruppens psykologi", den senare mer för den som är projektledaren.
Jag har den första som studentlitteratur, om du vill köpa billigt eller få någon sida kopierad.
Projektboken går igenom bra vilka roller man bör ha osv, mycket roligare att läsa än den andra.
Jag har den första som studentlitteratur, om du vill köpa billigt eller få någon sida kopierad.
Projektboken går igenom bra vilka roller man bör ha osv, mycket roligare att läsa än den andra.
När det gäller "Agile" metodik så är faktiskt inte det viktigaste att följa en metod slaviskt. Min erfarenhet är att det är bäst att läsa in sig på 2-3 stycken, sedan plocka det bästa från varje och hitta en form som passar just ert företag. Det är ju liksom det som är hela grundtanken med "Agile".
Men helt klart, kör "Agile"
XP/SCRUM/Crystal Clear - Där finns vad du behöver.
Men helt klart, kör "Agile"
XP/SCRUM/Crystal Clear - Där finns vad du behöver.
En bra och rolig introduktion finns att finna i Henrik Knibergs "Scrum and XP from the Trenches" http://www.crisp.se/henrik.kniberg/Scru ... enches.pdf
Jag har sett/använt scrum under de senaste 1.5 åren, jag tycker inte det behövs +15 pers för att det ska funka...
Mjukvaruavdelningen använder det mycket och de är väll ca 5 utvecklare och 2 testare. Där en utvecklare också är projektledare/chef
Jag har sett/använt scrum under de senaste 1.5 åren, jag tycker inte det behövs +15 pers för att det ska funka...
Mjukvaruavdelningen använder det mycket och de är väll ca 5 utvecklare och 2 testare. Där en utvecklare också är projektledare/chef
Att XP och SCRUM kräver 15-20 personer för att funka är inte sannt. Men när du börjar komma under 6-8 pers så börjar det bli lite knepigt att följa slaviskt och du måste vara lite flexibel.
Du kommer dock inte kunna hitta någon perfekt Agile Metodik med bara 2 roller i. Det är helt klart svårare att styra upp väldigt små team effektivt än lite större där man enklare kan se roller hos folk.
Här är lite av mina erfarenheter med att jobba med Agile i små team:
- Personer måste ha och kunna hantera flera roller i projektet samtidigt.
- En projektansvarig för projektet bör utses. Även om ni bara är 2 pers så måste någon ha beslutanderätt när ni inte är överens. Dessutom måste någon hålla koll på helheten i projektet och se till så att rätt saker levereras vid rätt tid. Samt förklara för chefen varför det inte gör det ibland Funkar det inte med den personen, byt till nästa iteration/projekt.
- Använd INTE par-programmering. Visst koden blir kanske snabbare bättre, men med så få resurser är det borkastad tid/pengar. Men använd Side-By-Side programming. Dvs placera programmerarna nära varandra för en effektiv kommunikation, helst så de kan se varandras bildskärmar. Men att de gör olika saker och bara hjälper varandra när det behövs.
- Använd INTE Code refactoring som ett tvång. Tanken är god att skriva minsta möjliga fungerande kod först och sedan succesivt förbättra den. Men det tar resurser. Försök skriva rätt från början, är det buggar, hantera dessa sepparat.
- Använd INTE "Kollektivt kod-ägande". Detta fungerar bäst på lite längre projekt med fler resurser. Programmerare är också av naturen intresserad av olika områden, en del gillar "Core" saker andra db/gui etc. Utnyttja detta och låt dem "glänsa" lite. Se dock att ni inte blir 100% beroende av enstaka personer gällande kod. Men motverka detta mer genom dokumentering/kodstandarder mm.
- Använd TDD.
- Använd tidsbestämda iterationer. Flytta aldrig på ett stoppdatum, skippa funktionalitet till nästa iteration om ni inte hinner med. En perfekt iterationstid tycker jag är 3 veckor. Det är tillräckligt långt för att hinna göra något och tillräckligt kort för att hinna få ut saker/få feedback etc.
- Arbeta aktivt med er "Backlog". Den som är projektansvarig bör spendera lite tid med den helst varje dag, minst varannan.
- Låt alla vara med på backlog/iterations planeringsmötena. Dina säljare och support behövs de med. Låt dem agera uppdragsivare och bevaka projektet ur affärsmässig aspekt.
- Glöm inte göra utvärdering efter varje iteration/projekt.
Så visst går det att styra upp små team, det är dock svårare och kräver mer erfarenhet och framför allt diciplin från alla. Räkna inte med att första projektet blir perfekt.
Ett tips är att hyra in någon duktig Agile konsult på en dag eller 2 som kan agera "ScrumMaster" (Eller vad ni vill kalla det) och gå igenom allt samt kick-starta projektet. Det är väl investerade pengar.
Du kommer dock inte kunna hitta någon perfekt Agile Metodik med bara 2 roller i. Det är helt klart svårare att styra upp väldigt små team effektivt än lite större där man enklare kan se roller hos folk.
Här är lite av mina erfarenheter med att jobba med Agile i små team:
- Personer måste ha och kunna hantera flera roller i projektet samtidigt.
- En projektansvarig för projektet bör utses. Även om ni bara är 2 pers så måste någon ha beslutanderätt när ni inte är överens. Dessutom måste någon hålla koll på helheten i projektet och se till så att rätt saker levereras vid rätt tid. Samt förklara för chefen varför det inte gör det ibland
Funkar det inte med den personen, byt till nästa iteration/projekt.- Använd INTE par-programmering. Visst koden blir kanske snabbare bättre, men med så få resurser är det borkastad tid/pengar. Men använd Side-By-Side programming. Dvs placera programmerarna nära varandra för en effektiv kommunikation, helst så de kan se varandras bildskärmar. Men att de gör olika saker och bara hjälper varandra när det behövs.
- Använd INTE Code refactoring som ett tvång. Tanken är god att skriva minsta möjliga fungerande kod först och sedan succesivt förbättra den. Men det tar resurser. Försök skriva rätt från början, är det buggar, hantera dessa sepparat.
- Använd INTE "Kollektivt kod-ägande". Detta fungerar bäst på lite längre projekt med fler resurser. Programmerare är också av naturen intresserad av olika områden, en del gillar "Core" saker andra db/gui etc. Utnyttja detta och låt dem "glänsa" lite. Se dock att ni inte blir 100% beroende av enstaka personer gällande kod. Men motverka detta mer genom dokumentering/kodstandarder mm.
- Använd TDD.
- Använd tidsbestämda iterationer. Flytta aldrig på ett stoppdatum, skippa funktionalitet till nästa iteration om ni inte hinner med. En perfekt iterationstid tycker jag är 3 veckor. Det är tillräckligt långt för att hinna göra något och tillräckligt kort för att hinna få ut saker/få feedback etc.
- Arbeta aktivt med er "Backlog". Den som är projektansvarig bör spendera lite tid med den helst varje dag, minst varannan.
- Låt alla vara med på backlog/iterations planeringsmötena. Dina säljare och support behövs de med. Låt dem agera uppdragsivare och bevaka projektet ur affärsmässig aspekt.
- Glöm inte göra utvärdering efter varje iteration/projekt.
Så visst går det att styra upp små team, det är dock svårare och kräver mer erfarenhet och framför allt diciplin från alla. Räkna inte med att första projektet blir perfekt.
Ett tips är att hyra in någon duktig Agile konsult på en dag eller 2 som kan agera "ScrumMaster" (Eller vad ni vill kalla det) och gå igenom allt samt kick-starta projektet. Det är väl investerade pengar.
