Scrum en functioneel ontwerp

[Regenbui]

Hi All,

Wellicht niet het juiste topic, maar kon geen betere vinden. Bij een organisatie waar ik werk zijn ze druk bezig met de transitie van waterfall werken naar scrum werken.

Wat mij betreft is dit meer dan welkom, echter loop ik met een vraag rond. Hoe gaan jullie met de documenten "impact analyse" en "functioneel ontwerp" om?

Het agile manifesto zegt werkende software boven stapels documentatie. Goed of fout, een aantal teams van ons zijn voorzien van een traditionele functionele ontwerper. Deze heeft nogal de neiging om terug te vallen op het contractuele document "functioneel ontwerp".

Hoe gaan jullie hiermee om?
Welke vorm geven jullie het?
Wie schrijft dit document?
Hoe zorgen jullie ervoor dat de overdracht naar beheer voldoende is?

Ik hoor het graag.

[Johnny]

Het functioneel ontwerpdocument wordt kleiner. Voor de eerste iteratie beschrijft het enkel een minimal viable product. Daarna kun je voor iedere story die daarna komt een klein functioneel ontwerp uitwerken waarbij de klant de prioriteit bepaalt.

[Standeman]

Er dienen user stories opgesteld te worden met voldoende werk voor de komende twee of drie sprints. Gedurende die sprints zal de P.O. steeds meer user stories opstellen met stakeholders en ze verder uitwerken met het Scrum team. M.a.w, de backlog moet gevuld en voldoende 'refined' worden zodat de Scrum teams lekker aan de slag kunnen.

Meestal worden de user stories in ondersteunende software zoals Jira geplaatst en beheerd.

Wie schrijft dit document?

Stakeholders, Product Owner en Scrum Team. Zo'n beetje iedereen dus

[ Voor 23% gewijzigd door Standeman op 06-12-2017 15:34 ]

[bonzz.netninja]

Regenbui schreef op woensdag 6 december 2017 @ 15:23:
Hi All,

Wellicht niet het juiste topic, maar kon geen betere vinden. Bij een organisatie waar ik werk zijn ze druk bezig met de transitie van waterfall werken naar scrum werken.

Wat mij betreft is dit meer dan welkom, echter loop ik met een vraag rond. Hoe gaan jullie met de documenten "impact analyse" en "functioneel ontwerp" om?

Het agile manifesto zegt werkende software boven stapels documentatie. Goed of fout, een aantal teams van ons zijn voorzien van een traditionele functionele ontwerper. Deze heeft nogal de neiging om terug te vallen op het contractuele document "functioneel ontwerp".

Hoe gaan jullie hiermee om?
Welke vorm geven jullie het?
Wie schrijft dit document?
Hoe zorgen jullie ervoor dat de overdracht naar beheer voldoende is?

Ik hoor het graag.

Ik was 5 jaar lang FO-er (back in the days) maar nu de afgelopen 7 jaar Product owner/business analist. Ik schrijf nooit meer FO's. Documentatie doe ik heel minimaal en gaan meestal niet veel verder dan acceptatie criteria (in gherkin) en eventueel wat schetsen vanuit UX. Soms beschrijf ik achteraf nog wel eens wat omdat een opdrachtgever daar om vraagt, maar dit gaat buiten de sprints/scrum om.

Dat is voldoende, immers het hele team is betrokken geweest bij de oplossing tijdens refinements, dus iedereen weet er van, en er is vertrouwen dat we allemaal het maximale willen binnen de tijd. Ik hoef daar geen afspraken op papier over te zetten, het is immers onze gemeenschappelijke oplossing die we met elkaar hebben doorgenomen en bedacht.

We hebben dus juist geen contract met elkaar. Je hebt juist ruimte nodig in scope en oplossing om eventuele nieuwe inzichten (of tegenvallers) te kunnen handelen zonder je sprintdoel in gevaar te brengen. Het is echt een team effort, we maken iets met elkaar en het is onze oplossing.

[ Voor 12% gewijzigd door bonzz.netninja op 06-12-2017 15:40 ]

[Laurens-R]

bonzz.netninja schreef op woensdag 6 december 2017 @ 15:37:
[...]

Ik was 5 jaar lang FO-er (back in the days) maar nu de afgelopen 7 jaar Product owner/business analist. Ik schrijf nooit meer FO's. Documentatie doe ik heel minimaal en gaan meestal niet veel verder dan acceptatie criteria (in gherkin) en eventueel wat schetsen vanuit UX. Dat is voldoende, immers het hele team is betrokken geweest bij de oplossing tijdens refinements en er is vertrouwen dat we allemaal het maximale willen binnen de tijd. We hebben juist geen contract met elkaar maar proberen de waarde te maximaliseren binnen de tijd die er is. Je hebt juist ruimte nodig in scope en oplossing om eventuele nieuwe inzichten (of tegenvallers) te kunnen handelen zonder je sprintdoel in gevaar te brengen.

Gherkin for the win Wij hebben in combinatie met het Cucumber framework Gherkin criteria direct kunnen koppelen aan een automated UI test Waardoor je direct kan zien of een user story af is of niet (en als het nog steeds ruimte voor interpretatie over laat, betekend dat gewoon dat de case niet voldoende is uitgewerkt in Gherkin).

[Tarkin]

Regenbui schreef op woensdag 6 december 2017 @ 15:23:
Hi All,

Het agile manifesto zegt werkende software boven stapels documentatie. Goed of fout, een aantal teams van ons zijn voorzien van een traditionele functionele ontwerper. Deze heeft nogal de neiging om terug te vallen op het contractuele document "functioneel ontwerp".

Beginnen met iedereen de scrum guide te laten lezen: http://www.scrumguides.or...rum-Guide-US.pdf#zoom=100

En je traditionele functionele ontwerper (en bij voorkeur het hele team) "User stories applied" lezen. Akkoord bepaalde concepten voldoen nu misschien niet meer, maar het is een zeer solide basis om op te beginnen.


Het is normaal dat je FO'er zijn documenten mist. Hij heeft immers niets anders geleerd. Het is ook een manier om te kunnen zeggen van "jamaar het staat in het document (verborgen onder 85 paragraphen maar soit) dus het is mijn fout niet..." Daar moet je vanaf stappen.

Je hebt verschillende manieren waaronder een MVP (minimum viable product) maar ook story workshops. Uit die story workshops kan je bv ook je MVP uithalen. Die workshops worden door iedereen van het development team + stakeholders gedaan.

[Tjmen]

Als kleine nuance, het Agile Manifeste zegt ook: "That is, while there is value in the items on the right, we balie the items on the left more." Het betekent dus niet dat je niets mee hoeft te documenteren. In het kader van beheer of compliance kan het nog steeds waarde hebben.

Maar inderdaad, wat Tarkin hierboven terecht zegt, is dat mensen in eerste instantie vasthouden aan wat ze kennen. Zorg dat alle teamleden (functietitels bestaan niet in de Scrumguide) de waarde inzien van een nieuwe manier van werken en zorg dat ze daarin ondersteund worden. Bijvoorbeeld met behulp van hierboven genoemde activiteiten en tools.

[Cronax]

Dat je via Scrum gaat werken wil niet zeggen dat je nooit meer een impact analyse of functioneel ontwerp gaat doen, je gaat het alleen een stuk minder doen. De plek van een traditionele functionele ontwerper is als ondersteuning voor de Product Owner. Die kan niet altijd in zijn/haar eentje alles over een user story te weten komen wat nodig is om de waarde (en dus prioriteit) van de story te bepalen. Ook is het niet altijd makkelijk om wensen om te zetten in functionaliteit (en daarmee user stories). Daarbij sluiten de skills van een FOer uitstekend aan.

Ik ben sinds kort gedetacheerd bij een nieuw project, we hebben hier 3 developers, 1 tester, 1 Product Owner en 2,5 FTE aan analisten. De business materie is op zijn zachts gezegd complex te noemen.

[drm]

Agile in een notendop: het einddoel is werkende software, omdat je aan werkende software pas kunt zien hoe en waar je bij moet sturen. Snel opleveren om snel waardevolle feedback te krijgen, dat doe je in een sprint. Als een FO daaraan bijdraagt is daar niks mis mee. Maar je moet het wel als een means to an end zien. Als het geen bijdrage levert aan het einddoel, maar een doel opzich is, is het waste en dat moet je zoveel mogelijk elimineren.

De kunst in zo'n transitieperiode is om te identificeren wat waardevolle elementen zijn in een FO waar een ontwikkelaar juist veel aan heeft - veel ontwikkelaars werken immers juist graag met glasharde specs - en hoe dit een belangrijke rol kan spelen in het refinement-proces: boven tafel krijgen wat het precies zou kunnen gaan worden. De grootste valkuil hier is dat refinement het domein wordt van de mensen die traditioneel meer aan het begin van de waterval stonden, zodat er alsnog een verkapt waterval ontstaat: volledig uitgewerkte functionele ontwerpen en documenten waarnaar verwezen wordt in user stories. Pas daarvoor op. Ook die refinement en alle assets die daarbij een rol spelen moet een team effort blijven. Desondanks is het niet verwonderlijk dat iemand met meer FO/analyse/design skills zich meer zal richten op de refinement dan op de daadwerkelijke oplevering van user stories. Afhankelijk van hoe je team in elkaar steekt en zich verhoudt tot andere teams in het bedrijf is het zelfs denkbaar dat dat deels buiten het scrumteam wordt gedaan. Het is ook niet verwonderlijk dat mensen met een FO-achtergrond vooral snel in product owner-achtige rollen terechtkomen.

Onthou vooral dat agile gaat over "inspect and adapt" en bij kunnen sturen, en dat iedereen met zijn eigen skillset een bijdrage kan leveren, niet om een nieuw harnas aan te trekken waar je niet meer in kunt bewegen. Met andere woorden: geef jezelf de gelegenheid om manieren te ontdekken en geef elkaar permission to fail. Dat is imho vele malen belangrijker dan dat iedereen precies doet wat "de bedoeling" is. De enige bedoeling is namelijk gewoon werkende software waar je feedback op kunt krijgen om er vervolgens weer een mes in te zetten. Release early, release often en kill your darlings.

[ Voor 7% gewijzigd door drm op 08-12-2017 23:00 ]

[DJMaze]

Regenbui schreef op woensdag 6 december 2017 @ 15:23:
Wat mij betreft is dit meer dan welkom, echter loop ik met een vraag rond. Hoe gaan jullie met de documenten "impact analyse" en "functioneel ontwerp" om?

Niet serieus.
Ik heb nog nooit documenten gezien die later NIET worden aangepast.
Gewoon omdat je tijdens de ontwikkeling op problemen stuit, en niemand ooit een capable ontwikkelaar zijn visie over een project vraagt (of dit wel vraagt maar niet hanteert omdat het niet in het budget past).

Verder gewoon ja en amen roepen tenzij men jou verantwoordelijk houdt voor de problemen.

Eigenlijk begin ik als Data Architect om te zorgen dat alles in kaart is voordat er überhaupt wordt ontwikkeld. Scheelt een hoop gedoe als de specificaties worden gewijzigd.

[ Voor 11% gewijzigd door DJMaze op 09-12-2017 02:55 ]

[raptorix]

Ik heb in verleden meegemaakt dat stukken die zich minder goed voor agile/scrum lenen gewoon buiten de sprint/teams werden geplaatst. Vooral als je moet koppelen met 3e partijen kun je nog wel eens voor onverwachte zaken komen te staan, daarnaast vind ik dat er soms wel erg makkelijk omgegaan word met documentatie, zit nu bij een organisatie waar ik behoorlijk aanloop tegen het ontbreken aan documentatie, nu snappen ze dat ook wel dat het minder snel gaat, maar het is wel zonde van de tijd.

[mpbel]

*snip* werving is hier niet toegestaan. We hebben Devschuurder werven? Gebruik Vraag & Aanbod! niet voor niets bovenaan dit forum staan prijken

[ Voor 89% gewijzigd door RobIII op 14-05-2019 14:41 ]