:strip_icc():strip_exif()/u/126511/avatar.jpg?f=community){kind=avatar}
Hallo,
Ik werk bij een bedrijf met een interne software afdeling. Onze klant is dus de sales afdeling (nieuwe features) en QA afdeling (in geval van bugs) van het bedrijf. We ontwikkelen aan verschillende applicaties die allemaal verband met elkaar hebben (hele pakket is 1 release).
Wij proberen om bij ons bedrijf aan de SCRUM methodiek te houden. Dit gaat als volgt:
- Voorafgaand aan een sprint (versie X) worden met alle stakeholders de items besproken die van de backlog op de sprint backlog komen
- Ontwikkelafdeling gaat gedurende 4 weken hun ontwikkeltraject in en lost alle tickets op voor versie X.
- Sprint retro/review worden gehouden en klant accepteert de sprint. Op dat moment word de hele iteratie overgedragen aan de testafdeling.
- Software development begint na de overdracht aan sprint X+1
- De testafdeling bepaald onafhankelijk wanneer ze gaan testen (dit kan dus meteen zijn, na 2 weken, maar kan ook zijn dat ze een iteratie niet testen).
- Zodra de testafdeling al het testwerk van sprint X afgerond heeft (en er zijn geen problemen gevonden) word het overgedragen aan productie afdeling. Deze afdeling verzorgt de updates op de live systemen en regelt ook de dagelijkse bewaking van de servers.
- Zodra de testafdeling fouten vind in de software worden deze na de testronde aan de software afdeling gemeld. Van de software afdeling word verwacht dat ze het werk in sprint X+Y (Kan inmiddels 2 sprints verder zijn totdat het testwerk afgerond is) stoppen en de fouten in sprint X gaan oplossen. De testafdeling test dan nogmaals of de problemen opgelost zijn.
Het nadeel wat we van deze manier van werken ondervinden is dat de problemen in sprint X opgelost moeten worden, en in sprint X+1 t/m X+Y. Niet zelden moeten we voor elke iteratie een andere fix verzinnen omdat de code al geredesigned is.
MIjn vraag is nu hoe we dit kunnen stroomlijnen, zelf heb ik al het volgende bedacht:
- Keihard zijn en niet meer toestaan dat er nog wijzigingen aan sprint X gedaan worden, op dit moment worden alleen fixes verwacht als er kritische dingen mis gaan. Het product is dus niet releasebaar naar de productieservers. Nadeel is dat een hele release dus X maanden opgeschoven kan worden omdat er iedere keer een kritische fout in zit.
- Testen bij de software afdeling neerleggen. Zodra een sprint af is is hij ook getest en zijn alle relevante zaken getest. De productie afdeling kan alles op de server plaatsen. Bedrijf hecht veel waarde aan losse testing en developing. Ander nadeel is dat een issue getest kan worden en correct bevonden kan worden, maar naderhand toch nog stuk gemaakt word door een andere feature.
Hoe doen jullie dit?
Ik werk bij een bedrijf met een interne software afdeling. Onze klant is dus de sales afdeling (nieuwe features) en QA afdeling (in geval van bugs) van het bedrijf. We ontwikkelen aan verschillende applicaties die allemaal verband met elkaar hebben (hele pakket is 1 release).
Wij proberen om bij ons bedrijf aan de SCRUM methodiek te houden. Dit gaat als volgt:
- Voorafgaand aan een sprint (versie X) worden met alle stakeholders de items besproken die van de backlog op de sprint backlog komen
- Ontwikkelafdeling gaat gedurende 4 weken hun ontwikkeltraject in en lost alle tickets op voor versie X.
- Sprint retro/review worden gehouden en klant accepteert de sprint. Op dat moment word de hele iteratie overgedragen aan de testafdeling.
- Software development begint na de overdracht aan sprint X+1
- De testafdeling bepaald onafhankelijk wanneer ze gaan testen (dit kan dus meteen zijn, na 2 weken, maar kan ook zijn dat ze een iteratie niet testen).
- Zodra de testafdeling al het testwerk van sprint X afgerond heeft (en er zijn geen problemen gevonden) word het overgedragen aan productie afdeling. Deze afdeling verzorgt de updates op de live systemen en regelt ook de dagelijkse bewaking van de servers.
- Zodra de testafdeling fouten vind in de software worden deze na de testronde aan de software afdeling gemeld. Van de software afdeling word verwacht dat ze het werk in sprint X+Y (Kan inmiddels 2 sprints verder zijn totdat het testwerk afgerond is) stoppen en de fouten in sprint X gaan oplossen. De testafdeling test dan nogmaals of de problemen opgelost zijn.
Het nadeel wat we van deze manier van werken ondervinden is dat de problemen in sprint X opgelost moeten worden, en in sprint X+1 t/m X+Y. Niet zelden moeten we voor elke iteratie een andere fix verzinnen omdat de code al geredesigned is.
MIjn vraag is nu hoe we dit kunnen stroomlijnen, zelf heb ik al het volgende bedacht:
- Keihard zijn en niet meer toestaan dat er nog wijzigingen aan sprint X gedaan worden, op dit moment worden alleen fixes verwacht als er kritische dingen mis gaan. Het product is dus niet releasebaar naar de productieservers. Nadeel is dat een hele release dus X maanden opgeschoven kan worden omdat er iedere keer een kritische fout in zit.
- Testen bij de software afdeling neerleggen. Zodra een sprint af is is hij ook getest en zijn alle relevante zaken getest. De productie afdeling kan alles op de server plaatsen. Bedrijf hecht veel waarde aan losse testing en developing. Ander nadeel is dat een issue getest kan worden en correct bevonden kan worden, maar naderhand toch nog stuk gemaakt word door een andere feature.
Hoe doen jullie dit?
Mess with the best, die like the rest
:strip_icc():strip_exif()/u/269508/crop55c9d5fae106a_cropped.jpeg?f=community)
/u/12668/hydra.png?f=community)
/u/98547/crop5db2a7ff7f697_cropped.png?f=community)
:strip_exif()/u/62088/sp_jh2.gif?f=community)
:strip_icc():strip_exif()/u/140697/crop6180fb9103afa_cropped.jpg?f=community)