Agile mindset versus Agile mechanismen

https://flic.kr/p/bkcj5q

Ik merk herhaaldelijk dat softwareteams te veel op mechanismen focussen en het basisprincipe uit het oog verliezen. Dit geldt met name voor Agile-methoden. Methoden zoals Scrum hebben zoveel mechanismen dat die nieuw voor agile volledig verdwalen. Ik schreef dit oorspronkelijk als een e-mail aan mijn team om te verduidelijken wat mijn mening over Agile was, maar ik heb het nu naar zoveel mensen gestuurd dat ik het advies van Scott Hanselman verander in een blogpost.

Ik beschouw mezelf enigszins gekwalificeerd om dit inzicht te geven. Ik ben een behendige beoefenaar uit de tijd dat Agile ontwikkeling het gebruik van een schroevendraaier inhield - om je eigen cellen te ontmantelen en een open zitplan te maken!

Vroeg in mijn carrière werkte ik bij een medisch softwarebedrijf. We hebben desktopsoftware gebouwd voor het beoordelen van afbeeldingen die op de desktop van Doctor in ziekenhuizen is geïnstalleerd. Het implementatieproces omvatte het reizen met cd's naar een andere stad en het installeren van de desktops en de beeldservers. We waren onderworpen aan FDA-goedkeuring, dus moesten we bouwen aan specificaties die de FDA-goedkeuring hadden gehad. Dit creëerde een ideale omgeving voor top-down watervalmethodologie. Alle specificaties zijn opgeschreven, goedgekeurd, afgemeld en we hebben alleen die specificaties en die specificaties gebouwd. Pas toen het ontwikkelaarsteam met het installatieteam begon te reizen en artsen te zien die onze software gebruikten, beseften we dat we zoveel beter konden doen als we eerder in de cyclus met de klant konden praten. We hebben gecodeerd naar exacte specificaties en toch iets afgeleverd dat niet zo nuttig was als het had kunnen zijn. Deze afbeelding toont enkele van mijn ervaringen.

Hoe softwareontwikkeling mis kan gaan vanaf https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Rond deze tijd hoorde mijn team van iets genaamd het Agile Manifesto en een praktijk genaamd Extreme Programming. Aangezien het werd ondertekend door veteranen uit de industrie wier boeken we actief lazen, leidden mensen zoals Martin Fowler en Kent Beck de praktijk veel legitimiteit. Mijn team van vijf ontmantelde onze cellen, trok onze PM (proxy voor onze klant) naar ons toe om naast ons te komen zitten, zette een bord met indexkaarten op en ging aan het werk. We hadden een wekelijkse cyclus van planning en demo's, veel paren en discussie. Ik heb ongeveer 15 jaar in verschillende iteraties en variaties hiervan gewerkt, in verschillende bedrijven. Eén team leek helemaal geen methodiek te volgen, maar het was omdat alle teamleden een diepe agile achtergrond hadden, iteratie en samenwerking hun standaardwerkingstoestand was en ze geen opgelegd proces nodig hadden.

Dus gaat Agile over open plattegronden of veel praten? Als je stand-ups en retro's hebt, kun je dan beweren dat je Agile bent? Waar past Scrum of TDD in? Vaak raken mensen te verstrikt in de details van het proces - Scrum of Kanban? Twee weken of een week sprint? Als je geen achterstandsverzorging hebt, ben je dan echt Agile? Opgegroeid met actieve ontwikkeling met behulp van Agile-methoden, waarbij andere ontwikkelaars even betrokken zijn, praktijken ontwikkelen en aanpassen, heeft me een goed inzicht gegeven en dit artikel is om de basisprincipes te identificeren.

Agile zijn is in staat zijn om snel aan de behoeften van klanten te voldoen. Betekent dit dat we sneller code schrijven? Nee. We kunnen de natuurwetten niet overtreffen, en het kost tijd om een ​​solide multifunctionele applicatie te bouwen.

Wat we moeten doen is

  1. Identificeer de essentiële bedrijfsproblemen die we met code willen oplossen
  2. Lever snel een theoretische oplossing om de hypothese te testen
  3. Herhaal en pas aan als de behoeften veranderen, of we leren meer
  4. Doe het in samenwerking, met de klant een betrokken deel van het team

Al het andere dat we doen is 2 en 3 hierboven minder pijnlijk maken - om te weten of we zo snel mogelijk aan de behoefte voldoen en zo niet snel kunnen veranderen. Als u hebt besloten om te bouwen (versus kopen), schrijft u aangepaste software. Dit betekent dat het gespecialiseerde vereisten en omgevingen heeft.

Door zo snel mogelijk iets zichtbaar te maken voor de klant, zelfs als het een kleine subset van de functionaliteit is, kunnen we sneller feedback krijgen. Daarom pleit ik er altijd voor om me te concentreren op het bouwen van een klein deel van de functie, end-to-end, en dat helemaal tot productie te brengen. Stel, u bouwt een pagina voor uw ondersteuningsagenten om alle gegevens over een klant te bekijken. In plaats van veel tijd te besteden aan het onderzoeken van de gegevensbronnen voor de hele pagina en het eerst schrijven van alle API's, probeer dan een subset van gegevens op de pagina te krijgen tot aan de productie. U kunt uw integratie- en implementatiemechanismen oefenen, u kunt feedback krijgen over het UI-framework, hoe deze pagina past bij de rest van uw applicatie, enz. Deze dingen zijn gemakkelijker aan te passen wanneer u een kleine hoeveelheid code hebt, in tegenstelling tot tot wanneer u een volledig API-framework hebt gebouwd.

Hier zijn enkele van de andere mechanismen die essentieel zijn voor behendigheid

Sprints: Ontwikkelen in time-boxed cycli, stelt ons in staat om te inspecteren en aan te passen, en met regelmatige tussenpozen nieuwe gegevens op te nemen om ervoor te zorgen dat we nog steeds werken aan relevante functies. Software is een verplichting. We moeten alleen bouwen wat we nodig hebben en kunnen toevoegen wat nodig is, wanneer het nodig is. Daarom is het essentieel om regelmatig te kijken naar wat we tot nu toe hebben gebouwd en waar we naartoe gaan. Dit leidt tot het tweede punt.

Aangezien we van plan zijn om voortdurend te evalueren en te wijzigen, moet onze software gemakkelijk te wijzigen zijn. Wat als, nadat een klant de applicatie begon te gebruiken, hij bepaalde gegevens anders wilde laten zien dan oorspronkelijk ontworpen? Kunnen we dat doen zonder al het andere op de pagina aan te raken? Of we moeten een andere API aanroepen om gegevens te krijgen - kunnen we die verandering veilig maken? Dit is waar goede ontwikkelingspraktijken en mechanismen van pas komen

Eenheidstesten: we hebben geautomatiseerde testen op verschillende niveaus, dus er is een vangnet voor wijzigingen. Het is ook van cruciaal belang om goed op te letten wat de unit-tests daadwerkelijk testen. Eenheidstests moeten de logica testen. Als u het bovenstaande voorbeeld neemt, zou het idealiter niet nodig zijn om de eenheidstests voor onze API die gegevens naar de gebruikersinterface stuurt, te wijzigen met een andere API. Er bestaan ​​eenheidstests om u het vertrouwen te geven om de code te wijzigen, waardoor u de vrijheid krijgt om alleen te schrijven wat u nu nodig hebt, en later te rusten, om hoe dan ook geen 100% dekking te produceren.

CI / CD: hiermee kunnen we de afstand tussen vastleggen en afleveren verkorten. Dit is essentieel voor behendigheid. Wanneer barrières voor implementatie worden weggenomen en we kleine veranderingen in de productie kunnen pushen, wordt het risico op verandering aanzienlijk verlaagd. Als implementaties vervelend zijn, komen ze minder vaak voor. Minder frequente implementaties zorgen voor veel verandering, raken een groot oppervlak en zijn daarom riskanter. Als je meer te weten komt over waarom softwareleveringprestaties ertoe doen, en welke maatstaf je moet gebruiken om het te optimaliseren, raad ik dit boek van Nicole Forsgren van harte aan.

Scheiding van zorgen: een losjes gekoppelde architectuur is essentieel voor software die gemakkelijk te wijzigen is. Het verkleint het oppervlak van een verandering. Microservices en containers zijn enkele van de mechanismen die worden gebruikt om de scheiding van punten van zorg uit te oefenen. Het is belangrijk om dit te onthouden en houd bij het bouwen van API's, componenten en applicaties rekening met de scheiding van problemen.

Onthouden
Goede code kan gemakkelijk worden gewijzigd

Betere code kan eenvoudig worden verwijderd

De beste code is die welke helemaal niet is geschreven

Het is essentieel dat de bits die u maakt, zo snel mogelijk in de echte wereld aansluiten, zodat u weet hoe uw nieuwe bits eruit moeten zien en u geen tijd verspilt met het maken van onnodige bits.