Waarom is BDD zo overtuigend? - tutorial Cucumber

- [Instructeur] Hoe komt het dat veel organisaties de gedragsgestuurde ontwikkeling veranderen van het beheren van hun softwareontwikkelingscycli? De opkomst van BDD kwam voort uit de mislukkingen van het traditionele model van softwareontwikkeling. Dit nieuwe paradigma was nodig om enkele van de valkuilen te overwinnen die ontwikkelingsteams keer op keer waren tegengekomen. Hoewel de voordelen van BDD in theorie misschien interessant klinken, helpt het hebben van een voorbeeld van wat er mis kan gaan als we de doelen en wensen van een klant niet op de voorgrond houden, ons om de gevolgen van ontwikkeling te begrijpen op basis van slechte communicatie van vereisten. Als voorbeeld van hoe BDD ons begrip van projectmanagement verandert, laten we eens kijken hoe BDD ons begrip van projectmanagement verandert met een casestudy uit de echte wereld van wat er misgaat zonder BDD. Op de CukenFest-conferentie van 2017 gaf scrummaster Sheetal Patel een keynote speech waarin ze de transformatie binnen Vanguard Group beschreef. Voor sommige context is Vanguard Group een groot beleggingsfonds met meer dan vijf biljoen dollar aan activa. Met een organisatie van ongeveer 14.000 medewerkers zijn 2.000 daarvan toegewijde IT-professionals. Vanguard Group is een puur virtueel bedrijf met zo'n 370.000 logins en 30 tot 60.000 transacties per dag. Hun webinfrastructuur is van cruciaal belang voor hun bedrijfsmodel en wordt beheerd door meer dan 200 agile teams. Een aantal jaren geleden, voor hun implementatie van BDD, kregen ze een project dat zich bezighield met kritische berekeningen van makelaarstransacties. Het was een groot en ingewikkeld project, waarbij iemand de schatting al had gedaan en zich had gecommitteerd aan een oplevering. Er was veel werk te doen en niet veel tijd om het in te doen. De ontwikkelteams gebruikten agile principes voor het maken en testen van hun code. En tegen de tijd dat ze het einde van de ontwikkelingscyclus naderden, hadden ze meer dan 1.000 testcases. Tijdens de laatste regressietest besloot de product owner dat ze het product wilde bekijken. Ze speelde met het systeem en informeerde hun team dat een van de makelaarsberekeningen niet goed werkte. Er was een handelstype dat ontbrak in de berekening. Het aanbrengen van een wijziging in de software op dit punt was een ongelooflijk moeilijke taak, gezien het feit dat de makelaarsformule zelf zo ingewikkeld was en dat ze een monolithische applicatie hadden gemaakt waarin alles met elkaar was verbonden. Wanneer een verandering werd geïntroduceerd, was er een kabbelend effect dat al het andere beïnvloedde. Ze werden echter door de producteigenaar geïnformeerd dat de wijziging noodzakelijk was en dat de applicatie niet zonder kon worden gebruikt. Ze hadden geen andere keuze dan de verandering door te voeren in een tijdsdruk vol angst, klauterend om de veranderingen die ze introduceerden te testen. Ze hadden niet de tijd die nodig was om alles grondig te testen, maar ze deden hun best voordat ze het in productie namen. Wat ging er dan mis? Op dat moment realiseerden ze zich dat er iets cruciaals ontbrak in de vergelijking van hun ontwikkelingslevenscyclus. Vanguard bracht wijzigingen aan in hun software waar ze geen vertrouwen in hadden, wat resulteerde in stress en angst, en er waren te veel bewegende stukken om alles efficiënt te testen. Om de manier waarop ze code testten en ontwikkelden te transformeren, moesten ze eerst het probleem begrijpen.