Op zoek naar naam van nieuwe rol

[twilightschild]

Hi tweakers, ik ben op mijn werk aan het pushen voor een nieuwe functie binnen het R&D team. Deze functie zou als kerntaak moeten hebben om de kwaliteit van ‘de code’ (een beetje kort door de bocht, meer context volgt) te bewaken. Nu zou ik graag weten of een soortgelijke functie vaker voorkomt (ik zou denken van wel) en hoe deze dan wordt genoemd.

De context:
Ik werk in een middelgroot ontwikkelteam (~30 personen) in een bedrijf dat softwareproducten aanbiedt binnen een redelijke niche-branche. Zoals zoveel MKB’s geldt ook bij ons dat initieel de software is gemaakt door mensen uit het werkveld zonder al te veel kennis over software development. Dit heeft geresulteerd in een flinke berg legacy-code die eigenlijk enkel groeit omdat er nog steeds wel redelijk de ‘als het werkt is het goed’ mindset is. Oftewel: het klassieke software-evolutieprobleem.
Nu is het zo dat we sinds een aantal jaren bezig zijn met een professionalisatieslag (zowel bedrijfsbreed als binnen de R&D afdeling). Tot op heden is het echter zo dat alle rollen die gedefinieerd worden vooral gefocust op het op tijd leveren van releases e.d. en dat er geen ‘stem’ is voor software kwaliteit. Dit zorgt ervoor dat de degradatie van onze softwarekwaliteit vrolijk voortdendert.
Om dit tegen te gaan heb ik een voorstel gedaan om een nieuwe rol te introduceren. Deze rol zou zich moeten toeleggen op de kwaliteit van de producten en een tegenwicht moeten bieden aan de krachten die zo snel mogelijk een nieuwe feature willen releasen. In praktische zin hebben denk ik dat de volgende taken onder deze rol vallen:

• In kaart brengen en prioriteren van ‘technical debt’
• Stimuleren en faciliteren van kennisdeling.
• Monitoren van ontwikkelingen om synergie tussen producten te promoten en/of voorkomen dat we het wiel opnieuw uitvinden.
• Procesverbeteringen invoeren teneinde de kwaliteit te verbeteren (denk hierbij aan zaken als meer/beter testen, reviews, coding guidelines , quality metrics, etc)

Nu zou ik eigenlijk deze rolbeschrijving wel eens willen afzetten tegen hoe andere bedrijven dit aanpakken (om zelf ook niet het wiel opnieuw uit te vinden), maar ik heb moeite om goed te zoeken naar dit soort informatie omdat ik niet goed weet hoe deze rol genoemd wordt. In de andere bedrijven waar ik heb gewerkt lagen dit soort verantwoordelijkheden vooral bij de architect. Alleen is het zo dat er bij ons heel weinig architectuurwerk is (er wordt vooral doorontwikkeld aan bestaande software waarbij er weinig ingrijpende veranderingen worden gemaakt), waardoor dat wellicht niet een vergelijkbare rol is.

[Uzuhl]

Klinkt als iets wat een procesmanager doet.

[naitsoezn]

Ik moet denken aan QA - Quality Assurance. Of het een "qa manager" is, een "qa lead" of een andere fancy term is om het even, maar ik denk dat je zoekt naar iets met QA.

[diondokter]

QA is normaal gesproken de assurance voor de quality die de klanten/users krijgen.
Is het eigenlijk niet gewoon de taak van een team lead om de kwaliteit en processen rond de code te bewaken?

[John]

Zou je punt 1 en 4 niet kunnen opnemen in een definition of done? Mits je scrumt natuurlijk.

[Haan]

Dit is in principe gewoon iets wat een senior developer / development lead / of-hoe-je-het-ook-noemt altijd al zou moeten doen, daar moet je geen dedicated functie voor hoeven te creëren. dat wil je ook niet zie ik, het gaat om een rol.

[ Voor 15% gewijzigd door Haan op 18-12-2018 15:15 ]

[Gonadan]

Haan schreef op dinsdag 18 december 2018 @ 15:10:
Dit is in principe gewoon iets wat een senior developer / development lead / of-hoe-je-het-ook-noemt zou moeten doen, daar moet je geen dedicated functie voor hoeven te creëren.

Met @Haan . In feite heb je een kwaliteitsniveau wat het hele team zou moeten nastreven, eventueel aangespoord door senior/lead.
Het punt van een aparte rol is dat je feitelijk als individu moet wedijveren met de andere 'product owner' om capaciteit voor wat je gedaan wilt krijgen. Ofwel, jij trekt aan de ene kant en de commercie aan de andere kant, vaak kan je dan wel uittekenen wie er wint.

Op zich juich ik het wel toe als iemand extra aandacht aan de kwaliteit wil besteden, maar je kunt dat niet alleen blijven doen. Daar zal je het hele team (inclusief opdrachtgever) in mee moeten krijgen wil je echt wat kunnen bereiken.

[Freeaqingme]

Ik zou dit ook als lead developer / team lead oppakken. Het in kaart brengen van technical debt kan wellicht eenmalig iets toevoegen, maar vervolgens moeten er dan ook nog resources vrijgemaakt worden om dat op te pakken. Dat is zeer zelden iets wat in isolatie gebeurt.

Een lead dev's rol zou hierin kunnen zijn om te pushen dat als ze feature X gaan ontwikkelen, er iets ruimer ingeschat wordt, en dat er op de backlog ook specifieke stories worden meegenomen om een keer component X te refactoren. Daarnaast kan die dan ook een stukje "scout's honor" pushen, waarbij er bij code reviews op gelet wordt dat developers de code iedere keer juist iets opruimen, in plaats van her en der corners cutten en het juist iedere keer iets meer vervuilt.

Wat je eventueel ook nog zou kunnen overwegen is een soort van "lead developers overleg", waarin je bijvoorbeeld bespreekt waar nou de grootste pijnpunten zitten in de codebase, en hoe de teams die gezamelijk kunnen oppakken. Daarin kan je dan ook meteen voorkomen dat teams los van elkaar hetzelfde wiel gaan uitvinden.

[twilightschild]

Iedereen bedankt voor de reacties.

naitsoezn schreef op dinsdag 18 december 2018 @ 09:50:
Ik moet denken aan QA - Quality Assurance. Of het een "qa manager" is, een "qa lead" of een andere fancy term is om het even, maar ik denk dat je zoekt naar iets met QA.

Uzuhl schreef op dinsdag 18 december 2018 @ 09:47:
Klinkt als iets wat een procesmanager doet.

Ik ga allebei eens even googlen om te zien hoe dat aansluit bij wat wij voor ogen hebben, bedankt!

John schreef op dinsdag 18 december 2018 @ 14:53:
Zou je punt 1 en 4 niet kunnen opnemen in een definition of done? Mits je scrumt natuurlijk.

We scrummen (nog) niet.

Haan schreef op dinsdag 18 december 2018 @ 15:10:
Dit is in principe gewoon iets wat een senior developer / development lead / of-hoe-je-het-ook-noemt altijd al zou moeten doen, daar moet je geen dedicated functie voor hoeven te creëren. dat wil je ook niet zie ik, het gaat om een rol.

Gonadan schreef op dinsdag 18 december 2018 @ 15:15:
[...]

Met @Haan . In feite heb je een kwaliteitsniveau wat het hele team zou moeten nastreven, eventueel aangespoord door senior/lead.
Het punt van een aparte rol is dat je feitelijk als individu moet wedijveren met de andere 'product owner' om capaciteit voor wat je gedaan wilt krijgen. Ofwel, jij trekt aan de ene kant en de commercie aan de andere kant, vaak kan je dan wel uittekenen wie er wint.

Op zich juich ik het wel toe als iemand extra aandacht aan de kwaliteit wil besteden, maar je kunt dat niet alleen blijven doen. Daar zal je het hele team (inclusief opdrachtgever) in mee moeten krijgen wil je echt wat kunnen bereiken.

Freeaqingme schreef op dinsdag 18 december 2018 @ 15:18:
Ik zou dit ook als lead developer / team lead oppakken. Het in kaart brengen van technical debt kan wellicht eenmalig iets toevoegen, maar vervolgens moeten er dan ook nog resources vrijgemaakt worden om dat op te pakken. Dat is zeer zelden iets wat in isolatie gebeurt.

Een lead dev's rol zou hierin kunnen zijn om te pushen dat als ze feature X gaan ontwikkelen, er iets ruimer ingeschat wordt, en dat er op de backlog ook specifieke stories worden meegenomen om een keer component X te refactoren. Daarnaast kan die dan ook een stukje "scout's honor" pushen, waarbij er bij code reviews op gelet wordt dat developers de code iedere keer juist iets opruimen, in plaats van her en der corners cutten en het juist iedere keer iets meer vervuilt.

Wat je eventueel ook nog zou kunnen overwegen is een soort van "lead developers overleg", waarin je bijvoorbeeld bespreekt waar nou de grootste pijnpunten zitten in de codebase, en hoe de teams die gezamelijk kunnen oppakken. Daarin kan je dan ook meteen voorkomen dat teams los van elkaar hetzelfde wiel gaan uitvinden.

Mijn ervaring met lead devs is dat ze meestal gelieerd zijn aan één product. Heb je dan niet alsnog een hiaat voor zaken die je afdelingsbreed zou willen doen? Stel bijvoorbeeld dat er functionaliteit is die bestaat in meerdere producten en vanuit historie heeft ieder product zijn eigen manier om die functie uit te voeren (en vaak verandert, anders is het niet heel relevant). Dan is het afdelingsbreed wenselijk om te consolideren om dubbel werk te voorkomen. Maar vanuit de individuele producten gezien is dit misschien minder wenselijk omdat de teamleden het beste uit de voeten kunnen met de methode die ze kennen. Of zou dat out een leadoverleg zoals @Freeaqingme voorstelt moeten komen?

[naitsoezn]

diondokter schreef op dinsdag 18 december 2018 @ 13:35:
QA is normaal gesproken de assurance voor de quality die de klanten/users krijgen.

Uiteraard in the end, maar kwaliteit die de klanten / users krijgen begint intern. Testen is een breed begrip, dat gaat niet alleen over de correlatie tussen wat de klant verwacht en wat de klant krijgt. Volgens mij is een groot deel van de wat TS vraagt een onderdeel van een goede testbase. In de breedste zin het woord. En een kleiner gedeelte is gewoon interne processen die geoptimaliseerd / geprofessionaliseerd moeten worden. Code-reviews zouden daar bv bij kunnen helpen, maar dan moet je wel een standaard hebben waar je naar reviewt. En zo nog wel meer dingen. Ik weet niet of het echt een functie is om iets dergelijks op te zetten, of iets wat iemand 'erbij' doet (al-dan-niet met een toegewezen budget / tijd), want zoiets opzetten is een werkje maar het handhaven/toepassen is niet meer dan beleid.

Edit: Ik lees nu dat TS nog niet scrumt. Nou ben ik de laatste om te zeggen dat scrum de heilige graal is, maar ik zou me toch eens verdiepen in de methodiek want er zitten best een paar onderdelen in die je er uit kunt halen en toe kunt passen om de problematiek van TS te tackelen. Ik wist trouwens niet dat er nog steeds dedicated software-bedrijven waren die niet op een (vorm van een) dergelijke methodiek waren overgestapt

[ Voor 17% gewijzigd door naitsoezn op 18-12-2018 19:06 ]

[Rmg]

twilightschild schreef op dinsdag 18 december 2018 @ 09:44:

• In kaart brengen en prioriteren van ‘technical debt’
• Stimuleren en faciliteren van kennisdeling.
• Monitoren van ontwikkelingen om synergie tussen producten te promoten en/of voorkomen dat we het wiel opnieuw uitvinden.
• Procesverbeteringen invoeren teneinde de kwaliteit te verbeteren (denk hierbij aan zaken als meer/beter testen, reviews, coding guidelines , quality metrics, etc)

Bij ons hebben ze dit in een "competence lead" rol gestopt, die gaat o.a tegen product owners aanduwen op het gebied van code quality en op development afdelingsniveau processmatig dingen aanpassen en implementeren (metrics, style, guideles etc etc)

In ons geval een rol die over alle projectteams heengaat.

Met een developmentteam dat liever gewoon cowboyt en projectleiders die deadlinegericht zijn ipv kwaliteit kan het nogal een uitdagende rol zijn..

[ Voor 7% gewijzigd door Rmg op 18-12-2018 22:31 ]

[NMe]

Dit lijkt me meer op zijn plek in Persoonlijke Financiën, Studie en Loopbaan.

PRG >> PFSL

[NeHoX]

Data Integrity Specialist
Quality Assurance
Data Quality Manager

Geef het beestje een passende naam. Wat veel belangrijker is, is Mijnes inziens de uitleg van de rol/functie en waarom deze nodig is en wat het beoogde doel zal zijn.

[Faeshaas]

Waarom niet een tool als TICS introduceren en voor elke levering die gedaan wordt een definition of done/guideline opstellen als in "De code duplicatie moet met x procent verminderd zijn" en "De code coverage moet met x procent verbeterd worden". Op die manier is iedereen zich bewust van de kwaliteit die geleverd wordt en is ook iedereen verantwoordelijk dit te verbeteren. 1 iemand aanwijzen om hierbij de kar te trekken lijkt me niet wenselijk.

Om maar een cliche spreuk te gebruiken: "Quality is free, only the absence costs money"

Het introduceren van iets zoals TICS lijkt me de taak van een software integrator die op deze manier het code archief beschermt.

[DeveloperNL]

Misschien eerst agile gaan werken en het team laten oplossen. Ik zou dit niet bij 1 persoon laten liggen. Iedere developer heeft een verantwoordelijkheid om technical debt op te sporen en gezamenlijk op te lossen. Wat je hier mee voorkomt is dat je een functie creëert die iets roept maar eigenlijk weinig mandaat heeft (iets van technical lead), want vaak is een product manager/owner verantwoordelijk voor het product en die kijkt naar business belangen. Als je met een heel team het probleem inzichtelijk (bijvoorbeeld met Sonarqube) maakt op een backlog en een deel van de capaciteit reserveert om technical debt op te lossen kan het vrij snel gaan.

Je kunt daarna ook met pull requests en met meerdere personen aan 1 taak werken zodat je minder nieuwe technical debt er bij krijgt.

[twilightschild]

naitsoezn schreef op dinsdag 18 december 2018 @ 19:04:
[...]
Edit: Ik lees nu dat TS nog niet scrumt. Nou ben ik de laatste om te zeggen dat scrum de heilige graal is, maar ik zou me toch eens verdiepen in de methodiek want er zitten best een paar onderdelen in die je er uit kunt halen en toe kunt passen om de problematiek van TS te tackelen. Ik wist trouwens niet dat er nog steeds dedicated software-bedrijven waren die niet op een (vorm van een) dergelijke methodiek waren overgestapt

Ik hoop/denk dat we er wel binnen afzienbare tijd naartoe gaan. We komen van een staat waar er eigenlijk nauwelijks een proces was. Daarna hebben we een aantal jaren geprobeerd om grotendeels zelf een proces te bedenken. Nu lijkt het inzicht te komen dat we misschien beter gebruik kunnen maken van ~60 jaar aan herd knowledge en een gewoon een bestaand proces moeten gaan gebruiken.

Rmg schreef op dinsdag 18 december 2018 @ 22:28:
[...]


Bij ons hebben ze dit in een "competence lead" rol gestopt, die gaat o.a tegen product owners aanduwen op het gebied van code quality en op development afdelingsniveau processmatig dingen aanpassen en implementeren (metrics, style, guideles etc etc)

In ons geval een rol die over alle projectteams heengaat.

Met een developmentteam dat liever gewoon cowboyt en projectleiders die deadlinegericht zijn ipv kwaliteit kan het nogal een uitdagende rol zijn..

Interessant, we zijn dus niet de enigen die met zo'n soort situatie zitten. Is dit bij jullie een rol waarvan je verwacht dat hij lange tijd zal bestaan of is het meer een tijdelijke rol die zou kunnen vervallen als kwaliteit wat meer op de radar staat bij iedereen?

NeHoX schreef op woensdag 19 december 2018 @ 00:56:
Data Integrity Specialist
Quality Assurance
Data Quality Manager

Geef het beestje een passende naam. Wat veel belangrijker is, is Mijnes inziens de uitleg van de rol/functie en waarom deze nodig is en wat het beoogde doel zal zijn.

Uiteraard is dat belangrijker. Dat hebben we redelijk goed op het netvlies. Maar het is ook goed om te leren van hoe anderen zulke zaken aanpakken. Mijn gedachte was dat ik op basis van de naam van zo'n rol eens kon gaan kijken hoe die rol ingevuld werd bij andere bedrijven om zo te zien of wij misschien nog wat over het hoofd gezien hadden.
Uit de reacties blijkt dat dit helemaal niet een gebruikelijke rol is en kwaliteit in het algemeen veel meer in het hele team verweven zit, met een controlerende functie bij een team lead of een lead dev. In ons geval vraagt dat denk ik om een cultuuromslag.
Ik denk dat het bij ons goed zou zijn om een kwaliteitgeoriënteerde rol te hebben, maar wellicht zou dit een tijdelijke rol moeten zijn die vervalt zodra er meer focus op kwaliteit is binnen het team.

Bedankt voor de input allemaal

[elhopo]

Je zou kunnen beginnen met het instellen van code reviews. Een opgelost issue wordt door iemand anders binnen het team nagekeken, steeds weer een ander natuurlijk. Zo heeft iedereen een beetje oog voor wat de ander doet. Je bouwt dan samen ook aan de kwaliteitsdoelstelling. Als iets niet volgens jouw idee goed is opgelost kan je met de betreffende ontwikkelaar in discussie. Zo ontstaat langzamerhand het gevoel binnen het team een gevoel van kwaliteit. Soms kom je iets tegen wat groter is dan het issue. Dan kan je met elkaar afspreken dat er een nieuw issue wordt aangemaakt voor dit specifieke punt.

Waarom ik het zo zou doen is dat ik denk dat er nu binnen het team geen gevoel voor kwaliteit is, Iedereen is zeg maar de schaamte voorbij en dumpt gewoon nieuwe code in de bestaande codebase. Dit omdat het toch al 'troep' is. Als jij daar nu ineens politie agent gaat spelen krijg je iedereen tegen je, en zet je jezelf buiten het team. Door anderen te betrekken krijg je meer het wij gevoel en zal iedereen op den duur meer een gevoel voor kwaliteit gaan krijgen. Je wil eigenlijk dat dit intrinsiek komt, en niet van buitenaf wordt opgelegd...

Ja, het gaat wellicht wat langzaam, maar iedereen werkt eraan mee en wellicht steek je ook nog eens wat van een ander op.

[ Voor 5% gewijzigd door elhopo op 19-12-2018 09:15 ]

[downtime]

DeveloperNL schreef op woensdag 19 december 2018 @ 08:45:

Wat je hier mee voorkomt is dat je een functie creëert die iets roept maar eigenlijk weinig mandaat heeft (iets van technical lead), want vaak is een product manager/owner verantwoordelijk voor het product en die kijkt naar business belangen.

Want kwaliteit is niet een business belang?

[twilightschild]

Faeshaas schreef op woensdag 19 december 2018 @ 08:03:
Waarom niet een tool als TICS introduceren en voor elke levering die gedaan wordt een definition of done/guideline opstellen als in "De code duplicatie moet met x procent verminderd zijn" en "De code coverage moet met x procent verbeterd worden". Op die manier is iedereen zich bewust van de kwaliteit die geleverd wordt en is ook iedereen verantwoordelijk dit te verbeteren. 1 iemand aanwijzen om hierbij de kar te trekken lijkt me niet wenselijk.

Om maar een cliche spreuk te gebruiken: "Quality is free, only the absence costs money"

Het introduceren van iets zoals TICS lijkt me de taak van een software integrator die op deze manier het code archief beschermt.

Ik denk dat dit al een stap te ver is voor ons. Het gaat ervan uit dat het enige/grootste probleem code duplicatie is. Ik denk dat het voor ons belangrijk is om een overzicht te krijgen van de zaken die een nadelige invloed hebben op onze kwaliteit en of efficiëntie en die te prioriteren.

In het algemeen is het zo dat er wel een consensus lijkt te bestaan dat onze legacy ons tegenwerkt en dat dit iets is dat we moeten aanpakken. Dat gevoel lijkt er (gelukkig) te zijn in alle lagen van de organisatie. Wat (naar mijn idee) het probleem is, is dat niemand een idee en/of de tijd heeft om dit aan te pakken. Het feit dat veel van onze senior devs geen software-achtergrond hebben speelt hier denk ik ook in mee.

Mijn idee is om een rol te hebben om dit handen en voeten te geven. Omdat het hele bedrijf doordrongen lijkt te zijn van het belang van het terugdringen van onze technical debt/legacy denk (hoop) ik dat het niet zo zal zijn dat één iemand de kar moet trekken. Het gaat er meer om dat één iemand dedicated tijd krijgt om te onderzoeken wat de meest opportune veranderingen zijn om door te voeren. Het zou goed kunnen dat dit meer een project is dan een rol, maar ik denk dat we momenteel op het punt zitten dat het in dat geval een meerjarig project gaat worden

[twilightschild]

elhopo schreef op woensdag 19 december 2018 @ 09:14:
Je zou kunnen beginnen met het instellen van code reviews. Een opgelost issue wordt door iemand anders binnen het team nagekeken, steeds weer een ander natuurlijk. Zo heeft iedereen een beetje oog voor wat de ander doet. Je bouwt dan samen ook aan de kwaliteitsdoelstelling. Als iets niet volgens jouw idee goed is opgelost kan je met de betreffende ontwikkelaar in discussie. Zo ontstaat langzamerhand het gevoel binnen het team een gevoel van kwaliteit. Soms kom je iets tegen wat groter is dan het issue. Dan kan je met elkaar afspreken dat er een nieuw issue wordt aangemaakt voor dit specifieke punt.

Waarom ik het zo zou doen is dat ik denk dat er nu binnen het team geen gevoel voor kwaliteit is, Iedereen is zeg maar de schaamte voorbij en dumpt gewoon nieuwe code in de bestaande codebase. Dit omdat het toch al 'troep' is. Als jij daar nu ineens politie agent gaat spelen krijg je iedereen tegen je, en zet je jezelf buiten het team. Door anderen te betrekken krijg je meer het wij gevoel en zal iedereen op den duur meer een gevoel voor kwaliteit gaan krijgen. Je wil eigenlijk dat dit intrinsiek komt, en niet van buitenaf wordt opgelegd...

Ja, het gaat wellicht wat langzaam, maar iedereen werkt eraan mee en wellicht steek je ook nog eens wat van een ander op.

Misschien heb ik mijn vraag niet duidelijk geformuleerd, maar het is niet mijn intentie om een rol te hebben die in zijn eentje verantwoordelijk is voor de kwaliteit en dus bijvoorbeeld mensen gaat aanspreken op dingen die ze verkeerd doen (politieagent). Het idee is meer dat er een rol is die kijkt hoe we organisatorisch kunnen verbeteren met als doel de kwaliteit van de code en het product te verhogen. Code reviews zou één van de (voor de hand liggende) dingen kunnen zijn die zo'n rol introduceert.

[DeveloperNL]

downtime schreef op woensdag 19 december 2018 @ 09:23:
[...]

Want kwaliteit is niet een business belang?

Nee, maar ik heb bij genoeg bedrijven binnen gekeken waar de waan van dag regeert

twilightschild schreef op woensdag 19 december 2018 @ 09:35:
[...]
Misschien heb ik mijn vraag niet duidelijk geformuleerd, maar het is niet mijn intentie om een rol te hebben die in zijn eentje verantwoordelijk is voor de kwaliteit en dus bijvoorbeeld mensen gaat aanspreken op dingen die ze verkeerd doen (politieagent). Het idee is meer dat er een rol is die kijkt hoe we organisatorisch kunnen verbeteren met als doel de kwaliteit van de code en het product te verhogen. Code reviews zou één van de (voor de hand liggende) dingen kunnen zijn die zo'n rol introduceert.

Dit zou bij ieder teamlid moeten zijn. Je bent gezamenlijk verantwoordelijk voor het product. Er zou geen rol moeten zijn. Als je een rol creëert, gaan mensen verantwoordelijkheid afschuiven, want hij/zij is verantwoordelijk voor kwaliteit. Kwaliteit is onderdeel van het ontwikkelen en als team bepaal je hoog de lat wordt gelegd. Soms zijn er best goede redenen om genoegen te nemen met minder kwaliteit (bijvoorbeeld snelle introductie op de markt op product te valideren, voordat concurrent er mee komt).

[twilightschild]

DeveloperNL schreef op woensdag 19 december 2018 @ 09:45:
Dit zou bij ieder teamlid moeten zijn. Je bent gezamenlijk verantwoordelijk voor het product.

Ik denk dat we het daar helemaal met elkaar eens zijn. Maar nu is het zo dat dit in de huidige situatie gewoon niet zo is, dus wat te doen om in die situatie uit te komen?

Ik heb een beetje een top-down idee waarbij ik deze nieuwe rol wil gebruiken om tijd vrij te maken voor kwaliteitgerelateerde ontwikkelingen, waarbij ik hoop dat dat dan doordruppelt en op termijn onze mind set verandert.

[Rmg]

twilightschild schreef op woensdag 19 december 2018 @ 08:48:

Interessant, we zijn dus niet de enigen die met zo'n soort situatie zitten. Is dit bij jullie een rol waarvan je verwacht dat hij lange tijd zal bestaan of is het meer een tijdelijke rol die zou kunnen vervallen als kwaliteit wat meer op de radar staat bij iedereen?
[...]

Het zal een permanente rol zijn maar, maar het werk en werkdruk zal wel veranderen over de maanden/jaren heen als het goed is.

Nu is het veel overleg met product owners (wat geen software mensen zijn vaak, multidisciplinaire teams hier) over dat kwaliteit nu scheelt in de support in de toekomst. Het opzetten van tooling (Perforce Helix), Het trainen (/op training) van devs en managers waar nodig. En een advocate voor kwaliteit zijn binnen de organisatie. In de toekomst zal het meer een ondersteunende rol gaan moeten worden


TICS installeren en je DOD aanpassen om op die manier "Kwaliteit" bij iedereen door de strot te duwen en dan er vanuit gaan dat het goed komt is natuurlijk supernaief. Neem dan nog een development team dat het niet eens is met de uitslag van dergelijke tools omdat ze het 'beter weten' dan heb je het feest compleet. Binnen enkele weken heb je 0 productiviteit en een zwaar beroerde sfeer.

[ Voor 9% gewijzigd door Rmg op 19-12-2018 10:04 ]

[DeveloperNL]

twilightschild schreef op woensdag 19 december 2018 @ 09:55:
[...]

Ik denk dat we het daar helemaal met elkaar eens zijn. Maar nu is het zo dat dit in de huidige situatie gewoon niet zo is, dus wat te doen om in die situatie uit te komen?

Ik heb een beetje een top-down idee waarbij ik deze nieuwe rol wil gebruiken om tijd vrij te maken voor kwaliteitgerelateerde ontwikkelingen, waarbij ik hoop dat dat dan doordruppelt en op termijn onze mind set verandert.

Urgentie creëren ipv top down en een nieuwe management laag maken. Stel dat je legacy code hebt in een taal die niet meer relevant is voor het bedrijf. Stel als team een doel dat je die legacy over 6 maanden kwijt wil zijn. Maak het daarnaast concreet waarom de technical debt jullie als team beperkt in het doorontwikkelen van het product. Daarnaast met directie/management daar financiële doelen/persoonlijke doelen aan koppelen.

[Faeshaas]

twilightschild schreef op woensdag 19 december 2018 @ 09:30:
[...]


Ik denk dat dit al een stap te ver is voor ons. Het gaat ervan uit dat het enige/grootste probleem code duplicatie is. Ik denk dat het voor ons belangrijk is om een overzicht te krijgen van de zaken die een nadelige invloed hebben op onze kwaliteit en of efficiëntie en die te prioriteren.

In het algemeen is het zo dat er wel een consensus lijkt te bestaan dat onze legacy ons tegenwerkt en dat dit iets is dat we moeten aanpakken. Dat gevoel lijkt er (gelukkig) te zijn in alle lagen van de organisatie. Wat (naar mijn idee) het probleem is, is dat niemand een idee en/of de tijd heeft om dit aan te pakken. Het feit dat veel van onze senior devs geen software-achtergrond hebben speelt hier denk ik ook in mee.

Mijn idee is om een rol te hebben om dit handen en voeten te geven. Omdat het hele bedrijf doordrongen lijkt te zijn van het belang van het terugdringen van onze technical debt/legacy denk (hoop) ik dat het niet zo zal zijn dat één iemand de kar moet trekken. Het gaat er meer om dat één iemand dedicated tijd krijgt om te onderzoeken wat de meest opportune veranderingen zijn om door te voeren. Het zou goed kunnen dat dit meer een project is dan een rol, maar ik denk dat we momenteel op het punt zitten dat het in dat geval een meerjarig project gaat worden

Geen tijd krijgen om het aan te pakken is een bekend probleem maar door op voorhand af te spreken dat bepaalde KPI's verbeterd moeten worden voor je mag leveren zorgt voor built-in quality. Als je dat stukje bij beetje doet dan verbeterd vanzelf de kwaliteit in zijn geheel, dit is niet iets wat je dedicated even oplost. Dit moet groeien binnen het bedrijf zodat iedereen zich hier bewust van is.

De verandering zit hem in de bewustwording bij iedereen die software moet leveren. Een tool als TICS (of andere metrics) kan je helpen dit meetbaar te maken. Waardoor je dus makkelijk afspraken kunt maken waar de te leveren software minimaal aan moet voldoen. Zolang die bewustwording er niet is bij het hele team kun je van alles verzinnen om de kwaliteit te verbeteren maar zal dit relatief weinig (of niks) opleveren.

Het is een lastig probleem, hier wordt sinds kort actief gebruik gemaakt van KPI's voor te leveren software. Dit lost niet ineens het probleem op maar maakt de pijnpunten wel goed zichtbaar zodat er naar gehandeld kan worden

[Fulgora]

Wij (200 engineers) bewaken kwaliteit van code, data en processen middels Fitness Functions. Teams bepalen zelf wat een acceptabel kwaliteitsniveau van een self contained service is, die afspraken leggen ze vast in een Architectural Decision Record waar de tech leads commentaar op leveren. Wanneer een service onder deze vooraf vastgestelde kwaliteitsstandaarden komt, weet het team dat er tijd besteed moet worden aan tech debt.

Je kunt dit in jouw kleinere organisatie misschien afvangen in een aparte QA-manager achtige rol, maar vanaf zo'n 50 devs is bijna niet meer bij te houden in welke kasten lijken zitten. Als jullie toko snel groeit zou ik dus achter m'n oren krabben of dat je dit in een rol wil stoppen. Dan is bovenstaande bottom-up approach veiliger.

[twilightschild]

DeveloperNL schreef op woensdag 19 december 2018 @ 10:29:
[...]

Urgentie creëren ipv top down en een nieuwe management laag maken. Stel dat je legacy code hebt in een taal die niet meer relevant is voor het bedrijf. Stel als team een doel dat je die legacy over 6 maanden kwijt wil zijn. Maak het daarnaast concreet waarom de technical debt jullie als team beperkt in het doorontwikkelen van het product. Daarnaast met directie/management daar financiële doelen/persoonlijke doelen aan koppelen.

Maar het scenario waarin je als team beslist om bepaalde legacy aan te pakken insinueert dat er al een mindset is waarin het team de verantwoordelijkheid neem voor de kwaliteit terwijl mijn vraag juist was hoe we die minset moeten cultiveren.


(het gaat gelukkig sowieso niet om een nieuwe managementlaag, maar een rol die iemand binnen development op zich zou gaan nemen)

Faeshaas schreef op woensdag 19 december 2018 @ 10:31:
[...]


Geen tijd krijgen om het aan te pakken is een bekend probleem maar door op voorhand af te spreken dat bepaalde KPI's verbeterd moeten worden voor je mag leveren zorgt voor built-in quality. Als je dat stukje bij beetje doet dan verbeterd vanzelf de kwaliteit in zijn geheel, dit is niet iets wat je dedicated even oplost. Dit moet groeien binnen het bedrijf zodat iedereen zich hier bewust van is.

De verandering zit hem in de bewustwording bij iedereen die software moet leveren. Een tool als TICS (of andere metrics) kan je helpen dit meetbaar te maken. Waardoor je dus makkelijk afspraken kunt maken waar de te leveren software minimaal aan moet voldoen. Zolang die bewustwording er niet is bij het hele team kun je van alles verzinnen om de kwaliteit te verbeteren maar zal dit relatief weinig (of niks) opleveren.

Het is een lastig probleem, hier wordt sinds kort actief gebruik gemaakt van KPI's voor te leveren software. Dit lost niet ineens het probleem op maar maakt de pijnpunten wel goed zichtbaar zodat er naar gehandeld kan worden

Ik heb dit in het verleden geprobeerd, maar mijn ervaring is dat collega's weinig onder de indruk zijn van slechte metrics. Het probleem is dat men simpelweg niet de waarde van de metrics onderkent. Ter illustratie: ik heb een keer een frustrerende discussie gehad met een collega die niet inzag waarom ik vond dat een method van 3,5 duizend regels lastig te lezen was. Alles stond immers netjes bij elkaar. . Nu is het mijn debet dat ik die persoon niet kon overtuigen, maar het geeft wel aan dat metrics alleen het verschil niet gaan maken.

Dat van de KPI's is wel interessant. Dat ga ik meenemen.

[Gonadan]

twilightschild schreef op dinsdag 18 december 2018 @ 18:49:
Mijn ervaring met lead devs is dat ze meestal gelieerd zijn aan één product. Heb je dan niet alsnog een hiaat voor zaken die je afdelingsbreed zou willen doen? Stel bijvoorbeeld dat er functionaliteit is die bestaat in meerdere producten en vanuit historie heeft ieder product zijn eigen manier om die functie uit te voeren (en vaak verandert, anders is het niet heel relevant). Dan is het afdelingsbreed wenselijk om te consolideren om dubbel werk te voorkomen. Maar vanuit de individuele producten gezien is dit misschien minder wenselijk omdat de teamleden het beste uit de voeten kunnen met de methode die ze kennen. Of zou dat out een leadoverleg zoals @Freeaqingme voorstelt moeten komen?

In principe wel ja, lead developers zouden toch op één lijn moeten zitten wat kwaliteit betreft en hetzelfde moeten nastreven. Dit betekent niet dat je alles in elk team op dezelfde manier moet oplossen, want soms is een eigen manier ook gewoon logischer. Maar je behoort wel enig onderling contact te hebben om te kijken of je elkaar kunt helpen en gezamenlijk op een hoger niveau kunt komen.
Vaak heb je wel een kartrekker nodig zoals jij nu kan zijn, maar dan moet je wel de andere leads mee krijgen en zien te activeren.

downtime schreef op woensdag 19 december 2018 @ 09:23:
Want kwaliteit is niet een business belang?

Meestal zegt men van wel, totdat de keuze gemaakt moet worden om tijd te steken in iets wat nu directe klantwaarde en/of omzet genereert of iets wat 'kwaliteit' toevoegt.