Inhoudsopgave:
Een agile softwareontwikkelingsteam zijn, betekent zeker verschillende dingen voor verschillende mensen. Er zijn gradaties van adoptie over een zeer breed spectrum, met blijkbaar zeer weinig organisaties die denken dat ze het goed doen. Volgens VersionOne's State of Agile Survey (uitgebracht in april 2017) zegt 80% van hun respondenten dat ze "op of onder een nog volwassen wordend niveau" zitten. Helaas stoppen ontwikkelteams vaak niet veel moeite in het 'leren'-gedeelte van de iteratie. We willen opschieten en de Scrum-ceremonies achter de rug hebben, zodat we weer code kunnen schrijven. Er is tenslotte zoveel werk te doen! Maar is onvoldoende coderingstijd echt het probleem?
Voor velen van ons kan brandbestrijding net zo goed specifiek worden vermeld in onze functieomschrijving. We gaan elke dag naar ons werk wetende dat we klaar moeten zijn om in een oogwenk van de paal te glijden, onze hoed te pakken en op de vrachtwagen te springen. We accepteren het zoals de dingen zijn, en we gaan ervan uit dat we er niets aan kunnen doen. Maar wat als de hoofdoorzaak van onze strijd een ernstig gebrek aan efficiëntie is? Iedereen weet hoe belangrijk het is om het beter te doen dan dat andere bedrijf daar. We kunnen er gewoon niet komen - we hebben blijkbaar niet de bandbreedte. Managers voegen meer mensen toe en vergroten de omvang van hun organisatie en hebben nog steeds dezelfde problemen. Het lijkt erop dat u niet over de bult heen kunt komen, omdat uw teams software niet efficiënt ontwikkelen (en u bent niet de enige).
Principes bij efficiënte ontwikkeling
Pixabay
Dus wat zorgt ervoor dat we inefficiënt zijn? Voor de meesten van ons is het eerste dat in me opkomt een gebrek aan automatisering (geautomatiseerde builds, implementaties, testen). "Zodra we genoeg automatisering hebben, wordt het leven beter." Helaas is dat slechts een deel van de oplossing. Overweeg het effect van herbewerking op uw project. De meest efficiënte manier om een functie te bouwen, is door deze eenmaal correct te bouwen en nooit meer terug te gaan en hem aan te raken. Bugs, refactoring en andere soortgelijke activiteiten heropenen in wezen de patiënt nadat hij de operatiekamer heeft verlaten en er is een inherent risico aan verbonden. We kunnen herbewerking niet elimineren, maar we moeten zeker proberen het te minimaliseren.
"Maar omarmt agile rework (bijv. Refactoring) niet?" Dat doet het eigenlijk op een bepaalde manier, omdat de makers van agile begrepen dat twee belangrijke oorzaken van herbewerking onvoorziene omstandigheden en veranderende zakelijke vereisten zijn. Het blijkt dat mensen slecht zijn in het voorspellen van de toekomst. Agile makers begrepen ook dat een enorme bijdrage aan inefficiëntie is wat ontwikkelaars 'gold-plating' noemen - een ingepakte functionaliteit waarvan we denken dat iemand die zal gebruiken, ook al hebben eindgebruikers er nooit echt om gevraagd. Het is als varkensvlees voor uw softwareproduct - een complete verspilling van tijd. 'Bouw geen ruimtestation als ze alleen maar een Volvo vragen.' Bedrijven zijn dus verstandig begonnen het varkensvlees weg te laten en in plaats daarvan refactoring te omarmen, door alleen functionaliteit toe te voegen wanneer er een duidelijke behoefte is. Maar de onvoorspelbaarheid van het leven is niet de enige drijfveer voor herbewerking, toch?
Gemiste details in elk stadium van de ontwikkeling van functies zullen uiteindelijk tijd en geld verspillen. Effectief samenwerken vooraf zal u na verloop van tijd een hoop nabewerking besparen (omgaan met gemiste vereisten, een kortzichtig ontwerp, enz.). We hebben allemaal blinde vlekken en we hebben allemaal extra paar ogen nodig. Veel ontwikkelingsteams omarmen dit aan de achterkant tijdens de codebeoordeling, maar steken veel minder energie in vroegtijdige samenwerking wanneer problemen goedkoop en met minimale investeringen kunnen worden opgelost.
Hoe vaak heb je een functie geïmplementeerd en tegen het einde belangrijke tekortkomingen gevonden die tijdens de vereisten / ontwerpbesprekingen hadden moeten worden opgemerkt? Het is alsof je van Atlanta naar Montgomery probeert te rijden en je realiseert je na enkele uren dat je per ongeluk naar Birmingham bent gereden. Hoeveel tijd werd er besteed aan het proberen om de code precies goed te krijgen, alleen om de patiënt later weer te openen omdat er belangrijke vereisten waren gemist? Het gebruik van collectieve intelligentie zou absoluut tijd en geld besparen, maar in plaats daarvan werken ontwikkelaars vaak afzonderlijk aan functies.
Traditionele zwermen
Pixabay
Traditioneel zwermen betekent dat het team samen aan verhalen werkt met meerdere mensen die tegelijkertijd aan een kleine functie werken, waardoor de feedbacklus wordt verkort en de algehele voltooiingstijd voor de functie wordt verkort (dwz verdeel en heers). Dit zwermt in wezen binnen elke discipline (backend-ontwikkelaars, UI-ontwikkelaars, enz.). Voordat de ontwikkeling begint, werken de UI-ontwikkelaars aan het identificeren van onafhankelijke taken die gelijktijdig kunnen worden uitgevoerd. Ze bespreken interfacepunten, zodat iedereen weet hoe zijn stuk in het geheel past. De teamleden kunnen vervolgens doorgaan met het voltooien van hun toegewezen taken en alles samenbrengen aan het einde tijdens de integratie. Frequente commits en periodieke codebeoordelingen helpen ervoor te zorgen dat alles op de rails blijft. Deze aanpak vereist samenwerking tussen de ontwikkelaars,wat sowieso helpt om een beter eindresultaat te produceren. We geven vaak prioriteit aan de tijd die we besteden aan het schrijven van code (welke code dan ook) over de tijd die we besteden om ervoor te zorgen dat we niet de verkeerde code schrijven. Als je kijkt naar de mogelijk bespaarde tijd, wordt de waarde duidelijk.
Gedeblokkeerd worden
Pixabay
Een andere waardevolle benadering van zwermen is om het team in het begin te concentreren op het verminderen van de afhankelijkheid om gelijktijdige ontwikkeling over de disciplines heen te vergemakkelijken. Overweeg de natuurlijke ontwikkelingsstroom van een UI-functie. De automatiseringstesters (SDET's) zijn afhankelijk van een werkende gebruikersinterface om tegen te testen, de ontwikkelaars van de gebruikersinterface zijn afhankelijk van een werkende backend-API en de backend-ontwikkelaars zijn afhankelijk van configuratie, database-updates en geautomatiseerde builds / implementaties. Het is dus mogelijk dat UI-ontwikkelaars pas met hun werk beginnen als de API's klaar zijn en SDET's mogelijk pas met hun werk als de functie is voltooid. Elke discipline werkt geïsoleerd, wat de samenwerking bemoeilijkt omdat de mensen met wie je moet communiceren druk bezig zijn met andere dingen.Maar wat als u de afhankelijkheden eerder zou kunnen verminderen en de disciplines allemaal tegelijkertijd aan dezelfde functie zou laten werken?
Hier zijn enkele voorbeelden:
1. Geïmplementeerde functionele gebruikersinterface met stubs
Om SDET's te deblokkeren, kunnen UI-ontwikkelaars ze een functionerende gebruikersinterface geven die net genoeg werkt om ze tests te laten schrijven. Backend API-integratie en CSS-stijlen kunnen nog steeds in behandeling zijn, aangezien geautomatiseerde testframeworks zoals Selenium het niet kunnen schelen als die dingen niet af zijn. Het kunnen allemaal rook en spiegels zijn. Hoewel er veranderingen kunnen optreden die enige herwerking veroorzaken, weegt het voordeel van het vroeg starten van de tests op tegen dat risico.
2. Geïmplementeerde backend-API's (stubbed, hard-coded data)
Door back-end-API's aan te bieden waartegen de UI-ontwikkelaars kunnen testen, kunnen integratieproblemen tussen de front-end en de API ('s) vroegtijdig worden gedetecteerd. Soms kom je erachter dat de aangeboden API niet voldoet aan de behoeften van de front-end ontwikkelaars. Mogelijk ontbreken hele oproepen, de handtekening kan onjuist zijn of er kunnen problemen zijn met de structuur van de gegevens. Als er een verbroken verbinding is, kunt u er net zo goed vroeg over te weten komen voordat er iets is verhard.
3. Maak een HelloWorld-versie van nieuwe applicaties en services.
Als er een nieuwe service nodig is (bijv. Een microservice), maakt u de opslagplaats en bouwt u een "hallo wereld" -versie van de service. Hierdoor kunnen dev-ops-bronnen starten met Jenkins-taken en implementatiescripts voordat de service daadwerkelijk wordt ontwikkeld.
Deze optimalisaties maken een vroege feedbackloop mogelijk waarin iemand kan zeggen "Ik heb iets anders nodig" voordat de ontwikkeling van het onderdeel dat de verandering vereist, is voltooid.
Inpakken
Het is ongelooflijk belangrijk dat we erachter komen hoe we de time-to-market van functies waaraan we werken, kunnen verkorten. Het bedrijf haalt geen waarde uit het hebben van een heleboel functies die in uitvoering zijn, en ontwikkelaars hebben dringend functies nodig die snel moeten worden geïmplementeerd, zodat defecten zo dicht mogelijk bij het punt van injectie kunnen worden opgelost. Ontwikkelaars hebben ook dringend behoefte aan interactie met elkaar, hoewel ze eigenlijk alleen maar code willen schrijven. Het is beter voor alle betrokkenen, ook voor de eindgebruiker die gewoon een beter product wil. Als u het ze niet geeft, gaan ze het ergens anders zoeken.
Swarming is een uiterst waardevol hulpmiddel in de toolbox van uw organisatie, als mensen de tijd nemen om te leren hoe het moet. Het is geen raamwerk of zelfs maar een activiteit - het is een mentaliteit. Voor elk gebruikersverhaal stellen teamleden zichzelf twee vragen:
- Hoe organiseren we taken voor dit verhaal om meerdere mensen tegelijk te laten bijdragen?
- Wat is het minimum dat ik moet doen om iemand die op mij wacht te deblokkeren?
Wat als uw team snel functies samen bouwt in plaats van langzaam zelfstandig een aantal functies te bouwen? Ze kunnen daadwerkelijk reageren op veranderende zakelijke vereisten en voldoen aan de behoeften van het bedrijf wanneer het bedrijf deze nodig heeft. Concurrenten zouden bang voor je zijn - klanten zouden van je houden. Dat is een recept voor een succesvol bedrijf.
© 2017 Mike Shoemake