Configuration Management

[FireAge]

Zonder al te veel in details te treden ben ik nu bezig twee afdelingen samen te voegen.
Daarbij merged een groep met voornamelijk software kennis, met een groep met voornamelijk hardware kennis.
Het is de bedoeling dat er geen overschot aan managers optreedt.

Nu zit ik een beetje met de term configuration management.

In de software groep hebben we een configuration manager, die de leiding heeft over een trac/subversion/hudson systeem. Hij zorgt voor correcte releases, spreekt mensen aan op het correct inchecken van compilebare code, is verantwoordelijk voor het testen, en het onderhouden van de automatische nightly builds. Hij runt tevens de CCB (change control board) om met de project leider te bepalen wat prioriteit heeft en wie welke tickets gaat afhandelen.

Nu is dit redelijk nieuw voor mij, en ik vroeg me af of dit standaard is in professionele software ontwikkeling.
Hoe groot moet een project zijn (in FTE) voordat zo'n manager nodig is, en wat zijn de voordelen?
Kunnen de specialisten dit niet zelf oppakken als deeltaak?
Hebben alle grote software projecten tegenwoordig een dusdanig systeem?

Ik hoop dat hier mensen rondlopen die wat ervaringen kunnen delen op dit gebied.

[Remus]

Als ik een ding heb geleerd is dat niks standaard is in professionele software ontwikkeling. Ik kom dit weekend wel met een uitgebreidere reactie.

[FireAge]

Graag!

Ik geloof dat dit de structuur is die is binnengeslopen via ICT/Noviq.
Tevens een Scrum/Sprint structuur waar ik niet van onder de indruk ben.

[Verwijderd]

Hij doet dus de planning en is de buildmaster.
Dat zijn natuurlijk rollen die je wel nodig hebt. Het maakt hem echter geen manager.

Er zijn zat functies waar het woord manager in voorkomt, zonder dat het een managersfunctie is.

[ Voor 27% gewijzigd door Verwijderd op 11-02-2011 11:11 ]

[Maranello]

Ik denk dat je beter kan spreken over Release Management dit sluit weer nauw aan met Change Management. Release manager is er voornamelijk om het overzicht te bewaren en de kwaliteit van de code te kunnen bewaken.

Misschien is dit nog interessant om te lezen

[Remus]

FireAge schreef op vrijdag 11 februari 2011 @ 09:45:
Nu zit ik een beetje met de term configuration management.

Misschien is het een deformatie van mijn vorige werkgever, maar configuration management associeer ik meer met het ITIL proces van bijhouden welke hardware, software en dergelijke je waar hebt (en hoeveel), dan met software ontwikkeling an sich.

In de software groep hebben we een configuration manager, die de leiding heeft over een trac/subversion/hudson systeem. Hij zorgt voor correcte releases, spreekt mensen aan op het correct inchecken van compilebare code, is verantwoordelijk voor het testen, en het onderhouden van de automatische nightly builds. Hij runt tevens de CCB (change control board) om met de project leider te bepalen wat prioriteit heeft en wie welke tickets gaat afhandelen.

Een dergelijke rol valt misschien wel onder release of integration management oid, maar is daarmee IMHO nog niet de naam 'manager' waardig (afgezien misschien van het CCB deel). Het is gewoon een uitvoerende taak. Waarschijnlijk is hier gewoon sprake van 'vlag op de strontschuit', waarbij het woord 'manager' wordt gebruikt om een ondankbare taak meer schwung te geven.

Nu is dit redelijk nieuw voor mij, en ik vroeg me af of dit standaard is in professionele software ontwikkeling.
Hoe groot moet een project zijn (in FTE) voordat zo'n manager nodig is, en wat zijn de voordelen?
Kunnen de specialisten dit niet zelf oppakken als deeltaak?
Hebben alle grote software projecten tegenwoordig een dusdanig systeem?

Ik hoop dat hier mensen rondlopen die wat ervaringen kunnen delen op dit gebied.

Nee, er is geen standaard voor, al zijn er natuurlijk wel best practices die gebruikt worden. Kijk bijvoorbeeld eens naar hoe Scrum werkt, dat gebruikt een totaal andere invulling van planning en verantwoordelijkheid. Maar zoals met zoveel dingen in software ontwikkeling: je moet het niet doen omdat anderen het ook zo doen, je moet iets doen omdat het een positief effect heeft op hoe je werkt (arbeidsgeluk, productiviteit, efficientie ed).

Wij gebruiken scrum (of iig een mutatie van scrum , en het team is zelf verantwoordelijk voor de goede werking van de continuous builds ed. Faalt een build door jouw commit dan wordt je gewoon geschopt door een ander lid van het team. Aan de andere kant wordt een release over het algemeen door een aparte buildmaster geregeld omdat het systeem waar mijn team aan werkt niet op zich staat en onderdeel is van een complex landschap van afhankelijkheden.

De globale planning en doelen wordt opgesteld door het hogere management samen met de teamleiders/scrummasters, maar de planning voor een sprint wordt door het team zelf opgesteld.

[FireAge]

Ok, iedereen bedankt voor de info. Ik ga eens kijken wat ik binnen de teams kan doen om te zorgen dat ik geen dubbele posities heb, maar ook geen belangrijke ondersteuning verlies.