Agile software ontwikkeling met continuous delivery
•Download as PPTX, PDF•
0 likes•164 views
Een gastcollege waarin ik uitleg heb gegeven over continuous delivery en agile methodieken die we binnen het knowNow project van Info Support hebben toegepast.
Recommended
More Related Content
What's hot
What's hot (9)
Viewers also liked
Viewers also liked (20)
Similar to Agile software ontwikkeling met continuous delivery
Similar to Agile software ontwikkeling met continuous delivery (20)
More from Willem Meints
More from Willem Meints (11)
Agile software ontwikkeling met continuous delivery
- 1. Agile software ontwikkeling met continuous delivery W. Meints
- 2. Even voorstellen • Willem Meints • Technical Evangelist / Microsoft MVP • Dagelijks werk: • Praten over mijn werk • Teams helpen met het adopteren van continuous delivery • Nieuwe technologie introduceren bij teams
- 3. Introductie Of waarom zou je ooit een product willen bouwen?
- 4. Mijn ervaring met productontwikkeling Learn, Know, Share • Content kunnen lezen om iets nieuws te leren • Expert profiel opbouwen op basis van je kennis • Kennis delen door zelf content op knowNow te zetten
- 5. Een risicovolle onderneming! • Klanten • Voor wie bouw ik dit? • Ervaart hij een probleem? • De markt • Kan ik genoeg geld verdienen? • Welk verdienmodel? • Product • Is het probleem op te lossen? • Wat werkt prettig?
- 7. Het risico van een klant De feedbackloop
- 11. De feedbackloop
- 12. Een feedbackloop maken • Maak het super eenvoudig om feedback te leveren • Reageer vlot op feedback • Zoek naar het echte probleem • Belangrijk: Je mag nee zeggen!
- 14. Een goed product bouwen Experimenten bouwen en onderhouden
- 15. Wat moet je minimaal doen om een goede release op productie te zetten?
- 16. Stel, je productieomgeving is ingestort. Gebruikers kunnen er niet meer bij. Wat doe je om snel de bug te fixen?
- 18. “I have not failed, I’ve just found 10,000 ways that won’t work” Thomas Edison Inventor, Scientist
- 20. Werk met feature branches
- 21. Automatische testen, builds en deployments
- 23. Automatische acceptatie testen Scenario: Activating an account starts the onboarding process Given Mike has requested a login When Mike clicks the activation link in the email Then Mike his account is activated and he receives an onboarding email
- 24. Automatische build • Voor elk pull request een build • Gebruikt voor het deployen • Controleert of het compileert • Voert kwaliteitscontroles uit • Master branch build • Gebruikt als controle van je backup • Controleert of het compileert • Voert kwaliteitscontroles uit
- 25. Deployment • Automatisch van test naar acceptatie deployen • Goedkeuring product owner acceptatie • Goedkeuring team op Ring 0 Ring 1 Ring 0 Acceptatie Test
- 26. Planning enzo Had ik het daar al over gehad?
- 27. “Je krijgt het over een week, want de rest is nog niet af.” Developer knowNow
- 28. Bouwen Een typische sprint met SCRUM Testen Einde sprintFeature 1 is klaar
- 29. “Bouwers klaar? Deployen maar!” Willem Meints Lead Developer - knowNow
- 30. Stop met schatten! • Want ik schat dat 98% van de schattingen er naast zit. • De andere 2% heeft mazzel gehad.
- 31. Beter plannen voor beginners • Keer de volgorde om: Laat het team vragen om werk! • Je kan toch niet sneller dan dat zij bouwen, dus stop met jezelf op te winden • Bespreek bottlenecks met het team en neem die weg • Zorg als product owner dat je weet waar je naar toe wilt • Deel de visie vroegtijdig, zodat het team kan helpen met plannen
- 32. Beter plannen voor beginners • Neem de tijd om het probleem te bespreken • Hiermee maak je de planning eenvoudiger • Denk na over alternatieven zonder code • Stel lastige dingen uit • Klinkt raar, maar de lastige dingen worden eenvoudiger over tijd. • Maar, als het niet anders kan, pak het dan aan.
- 33. Beter plannen voor beginners • Kan het kleiner gemaakt worden? • Sneller feedback • Minder kans op fouten • Zijn er dingen die het tegenhouden? • Wat moet je doen om de feature naar productie krijgen? • Doe dat eerst! Dan gaat de nieuwe feature ook sneller.
- 34. Stimuleer gewenst gedrag • Sommige delen van SCRUM zijn heel handig: • Daily standup – Eenvoudige manier om elkaar op de hoogte te houden • Retrospective – Voorkomt afrekencultuur • Andere tips: • Neem eens snickers mee naar de retro • Stop eens met praten over wie de schuldige is van een fout • Stimuleer verantwoordelijk gedrag
- 35. Ideeën voor thuis Om mee te nemen
- 36. 5 tips om betere software te bouwen 1. Experimenteer, meet en verbeter 2. Maak het zo eenvoudig mogelijk 3. Automatiseer alles wat je vervelend vindt 4. Stop met schatten 5. Zorg voor jezelf en voor je medemens
Editor's Notes
- Als je succes
- Ik wil jullie een verhaal vertellen over knowNow. Specifiek over hoe wij knowNow hebben gebouwd. Maar voordat ik je heb laten zien hoe we knowNow hebben ontwikkeld met behulp van continuous delivery, wil ik je eerst vertellen waarom knowNow bestaat. knowNow bestaat, omdat we een probleem ervaarden met de manier waarop kennis werd gedeeld in het bedrijf. Ik heb een keer meegemaakt dat ik iets uitgezocht hoe je javascript coverage in Visual Studio aan de praat krijgt. Vol trots vertelde ik erover aan een collega en kwam erachter dat hij hetzelfde had gemaakt. Jammer, want ik wist het niet en had makkelijk zijn werk kunnen hergebruiken. Had mij minder tijd gekost. We (Joop Snijder en ik) ontdekten dat kennis niet werd gedeeld, waardoor dingen dubbel werden uitgezocht. Daarbij ontdekten we dat portalen als Sharepoint niet werden gebruikt, omdat mensen niets terug konden vinden. Mensen in het bedrijf wilden wel kennis delen, maar deden dat niet omdat er geen tool was die hun uitnodigde om te delen. Daarom hebben we knowNow bedacht. We bieden je een fijne omgeving om kennis op te doen. We maken het opdoen van kennis slimmer door een profiel van je op te bouwen, zodat we kennis op maat kunnen aanraden En we bieden een omgeving aan om kennis snel te kunnen delen Klinkt gelikt en goed doordacht? Zo zijn we zeker niet begonnen. We begonnen namelijk met een heel ander idee.
- Als je het mij vraagt was knowNow een zeer gevaarlijke onderneming. Want als ik heel eerlijk ben dan had ik, toen we begonnen, geen idee waar we mee bezig waren. Ik had in mijn hoofd een mooie user interface en coole technieken, maar geen idee waarom ik dat precies wilde hebben. Als je sofware zoals knowNow gaat bouwen dan krijg je hoe dan ook te maken met allerlei vervelende risico’s. Zo zou het zomaar kunnen dat je iets bouwt dat niet werkt. Slechte kwaliteit software is een nachtmerrie en zeker niet iets wat zorgt voor goede inkomsten. Daarnaast is er nog een probleem. Je moet, als je een succesvol bedrijf wilt runnen, geld verdienen. Kan dat wel met knowNow? Ik had geen idee! Ik had in mijn hoofd een klant, namelijk mijn collega’s. Maar of dat nou de goede gebruikers waren… Geen idee. Wellicht was mijn probleem wel helemaal verkeerd geformuleerd, waardoor niemand het snapt. Je kan dan met het verkeerde probleem bij de goede klant aankomen. Als ik dan mijn collega’s ga vragen om meer kennis te delen dan is dat eigenlijk een vorm van ongevraagd advies. Erg leuk, maar niemand gaat wat doen daarmee.
- Eigenlijk hadden we geen idee wat we wilden doen. En er was ook geen hapklare manier om erachter te komen. Want bij een simpele huiswerkopdracht lukt het wel om erachter te komen welke risico’s je loopt. Maar een product als knowNow heeft veel impact op de organisatie. Je vraagt nogal een investering van mensen. Ze moeten ineens kennis gaan delen via jouw product. Daarnaast verwacht je dat iedereen ook nog eens alle kennis bij je komt halen.
- Toen we begonnen met knowNow dachten we dat we het allemaal snapten. We gingen druk aan de slag met ontwerpen. We vroegen onze gebruikers niet wat hij ervan vondt.
- Aan het einde van drie maanden kwamen we uit ons hok gekropen en lieten we vol trots ons idee zien. We waren op dat moment eigenlijk niet op zoek naar feedback, maar waren vooral heel trots dat het gelukt was. Maar toen we de ontwerpen van knowNow lieten zien kregen we duidelijk feedback, ookal vroegen we er niet om. Het was ruk, we snapten er helemaal niets van en waren eigenlijk maar een stel prutsers. Grappig detail hierbij: Hij was boos, maar hij wist zelf ook niet wat hij dan wel wilde hebben! Dan zit je mooi te kijken.
- Daar hebben we iets van geleerd. We zijn gaan werken met experimenten. En wel in twee fasen. Eerst zijn we gaan kijken, wat heb je minimaal nodig om kennisdeling op gang te krijgen. Dat is betrekkelijk eenvoudig vast te stellen: - Je hebt een mogelijkheid nodig om kennis te delen in de vorm van een editor - Je moet content kunnen vinden in knowNow - En je moet content kunnen lezen op knowNow We hebben toen dat gemaakt en uitgerold naar een pilotgroep van 60 mensen. Deze mensen hebben we gevraagd om feedback zodat we konden meten of het werkte. Aan de hand van de feedback zijn we toen gaan bedenken wat ons volgende experiment zou moeten worden.
- De feedback loop is een belangrijk hulpmiddel dat je gaat inzetten. Voor zo ongeveer alles op het project zul je moeten bedenken waar het toe bijdraagt. Onthoud: Alles dat je niet doet kost niets, en is dus altijd beter dan wel iets doen! Dus als je iets gaat doen, bedenk dan in ieder geval een manier om te bepalen of het iets oplevert.
- Wat we ook hebben ontdekt is dat feedback halen noodzakelijk is. Je kan wel zeggen: We luisteren naar je, maar als je nooit contact zoekt dan krijg je niets. We hebben dat op twee manieren aangepakt. We hebben het super eenvoudig gemaakt om feedback te leveren. In knowNow zit een knop op elk scherm, waarmee je direct commentaar kwijt kan. Je kan het ook nog eenvoudiger doen. Maak een knop in je UI op elk scherm die een mailto link bevat naar je emailadres. We hebben wel gemerkt dat het belangrijk is dat je snel reageert. Het is helemaal niet erg dat er iets breekt. Maar mensen willen graag dat je opschiet. Vandaag gemeld is vandaag nog gefixed!
- Naast feedback van de gebruiker zijn we in knowNow ook metrieken gaan verzamelen. Via google analytics kun je eenvoudig bijhouden hoe je applicatie wordt gebruikt. Je kent het denk ik wel van websites, maar het kan ook worden gebruikt voor programma’s. Je kan namelijk niet alleenpage visits tracken, maar ook events. Hiermee kun je snel zien of er na een release meer of minder gebruik wordt gemaakt van een feature. Alternatief dat ik je hier kan aanraden is Application Insights. Deze tool kun je eenvoudiger in je .NET code hangen dan Google Analytics en het biedt ook meer op andere vlakken zoals performance metingen.
- Een product ontwikkelen gaat, zoals je merkt, veel verder dan alleen even een paar java of C# klasses aan elkaar knopen. Eigenlijk gaat het daar helemaal niet zo over heb ik gemerkt. De meeste tijd bij knowNow was ik in discussie met Joop Snijder over wat er nu precies wel en niet in ons product moest. Daarnaast spendeerde ik ook nog eens heel veel tijd aan het bespreken van feedback met gebruikers. Wat er overbleef was dan de tijd die ik had om het te bouwen samen met mijn team.
- Conclusie hier is dus dat we iets heel raars doen. Als we een hotfix maken dan kan het ineens super super super snel. Maar bij een release zijn we minimaal een jaar aan het testen…. HMMM!? Dat heb ik in vorige projecten ook gedaan. Elke keer een enorm traject met kwaliteitscontroles. Maar eigenlijk is dat heel raar, want blijkbaar kan het ook met een hele simpele set stappen!
- Die hele gekke situatie met ellenlange releases hebben we opgelost door twee dingen. Ten eerste hebben we deze uitspraak opgehangen en zijn we ons er naar gaan gedragen. Als je iets sloopt is dat helemaal niet erg. Want we hebben op die manier ontdekt dat er een manier is waarop het niet moet. We hebben ook een manier gevonden waarop het wel moet.
- Een belangrijke tweede stap die we gezet hebben is het introduceren van het vangnet. Elke keer als we een probleem tegenkwamen die erg vervelend uitpakte voor ons dan gingen we nadenken over een manier om vangnet te introduceren die dat probleem tegen zou gaan.
- Om je een voorbeeld te geven. We hadden in het verleden maar 1 branch waarop we werkten. TFS sourcecontrol ondersteund wel meerdere branches, maar als je er een keer mee gewerkt hebt dan weet je ook dat het enorm lastig is om ermee te werken. Je sourceboom wordt namelijk volledig gekopieerd op je werkstation. En je moet in een andere map gaan werken. Met een sourcecontrol boom van 3.7 GB wordt dat wat duur als je 20 branches open hebt staan. Daarom zijn wij overgestapt naar GIT . We hebben daarbij een truc geadopteerd die ook door Github wordt gebruikt. Elke keer als we iets nieuws willen maken dan maken we daarvoor een feature branch. Deze branch gebruiken we om te ontwikkelen en te testen. Zijn alle testen geslaagd en is de feature af? Dan deploy je de branch naar productie. Pas als het daar goed is aangekomen en werkt merge je de spullen met master. Op deze manier is master altijd uit te rollen. En kun je dus terug als het kapot gaat!
- Een andere stap die we hebben genomen om onszelf te helpen is door het automatiseren van zo ongeveer alle routine taken. Je moet hierbij denken aan builds, deployments en vooral testen.
- Ik vind zelf testen ongelofelijk vervelend. Elke keer opnieuw het programma doorklikken en allerlei exotische paden aflopen om te kijken of je niets kapot hebt gemaakt. Wat mij betreft is dat dus een taak die je aan iemand anders mag geven of beter nog automatiseert. Unittesten zijn denk ik wel de bekendste voorbeelden die je hier kan noemen. Super eenvoudig te introduceren en te onderhouden. Helaas is correcte werking niet altijd 100% te garanderen met unittesten. Vaak gebruik je mocks voor externe webservices etc. Daarom hebben we binnen knowNow ook gebruik gemaakt van service testen om te controleren of losse services met elkaar konden praten. Tot slot hebben we ook nog gebruik gemaakt van UI testen. Met al deze automatische testen kunnen wij als team, zonder te kijken (!) naar productie. Als ze maar groen zijn is het goed! Belangrijke kantekening is wel dat we hebben gemerkt dat UI testen snel kapot gaan. We wilden nogal eens wat veranderen in de UI. Daar moest je dan weer de UI testen op aanpassen. Alles met elkaar was dat erg veel werk. Daarom, kijk eerst wat je nodig hebt en push zoveel mogelijk naar beneden! Draai alleen UI testen voor belangrijke flows en de rest als je ziet dat het vaak kapot gaat. Risicogedreven testen zijn wat mij betreft het belangrijkste.
- We hebben er bij knowNow voor gekozen
- Deployments bij knowNow hebben we net als de build volledig geautomatiseerd. Zodra je een build start vanuit je feature branch wordt er een deployment uitgevoerd op de testomgeving. Dit is de eerste controle of het werkt. Er worden daarna testen gedraaid tegen de testomgeving om te kijken of het goed werkt. Als dit allemaal gelukt is gaan we direct door naar acceptatie. Op de acceptatieomgeving kijken we dan of de UI er goed uit ziet en we geen rare dingen zien. Als dat goed gaat dan drukken we op een knop in release management en zetten we alles door naar productie. Deze heet binnen knowNow ring 0. Ring 0 is onze interne productieomgeving. Hier werken de Info Support medewerkers op. Deze krijgen de bleeding edge spullen van ons die nog wel eens heel raar willen werken. Dat geeft niet, want dat zijn collega’s van me en het kost me dus minder op het moment dat het daar kapot gaat. Als we als team het idee hebben dat het werkt zetten we het door naar ring 1. Ring 1 is ook een productieomgeving, maar dan met externe klanten. Deze krijgen de releases minder snel, maar wel stabieler.
- We hebben het nog helemaal niet over sprints, planning en al dat soort dingen gehad. En daar heb ik een goede reden voor, want als er iets kapot is aan SCRUM dan is het wel de planning.
- Wait what!? Maar het is kapot en ik wil het nu! En je hebt het blijkbaar al af!