Share via

Aanbevelingen voor het formaliseren van softwareontwikkeling en -beheer

  • Artikel

Van toepassing op deze aanbeveling voor de controlelijst voor operationele uitmuntendheid van Azure Well-Architected Framework:

OE:03 Formaliseer softwareideetie- en planningsprocessen. Maak gebruik van gevestigde industrie- en organisatiestandaarden. Gebruik een algemene achterstand met prioriteit en voldoende gedetailleerde specificaties. Op basis van resultaten zorgt u voor continue verbeteringen in uw planningsproces.

In deze handleiding worden de aanbevelingen beschreven voor het beheren van softwareontwikkelingsprocedures in overeenstemming met vastgestelde normen. Het vermogen van uw team om software van hoge kwaliteit te produceren, is afhankelijk van een gestructureerde, gezamenlijke benadering van de ontwikkelingsplanning. Producteigenaren en -managers moeten het werk dat ontwikkelaars op elk moment in een ontwikkelingscyclus uitvoeren, duidelijk kunnen begrijpen en duidelijk kunnen maken aan belanghebbenden. Ontwikkelaars moeten daarentegen de doelstellingen van de ontwikkelingscyclus begrijpen via goed geschreven functies, gebruikersverhalen en acceptatiecriteria. Vastgestelde standaarden bepalen hoe ontwikkelprocedures moeten worden uitgevoerd en stellen het workloadteam in staat om effectief samen te werken, waardoor het risico op verwarring over doelen en verwachtingen wordt verminderd.

Belangrijke ontwerpstrategieën

Formaliseer uw procedures voor softwareontwikkeling om ervoor te zorgen dat producteigenaren, projectmanagers en ontwikkelaars de doelstellingen van elke sprint begrijpen en consistente kwaliteit leveren aan belanghebbenden. Zie de handleiding voor continue integratie voor meer informatie over ontwikkelprocedures.

Standaarden voor ontwikkelingsplanning

  • Samenwerking: Het proces voor het definiëren van voorgestelde wijzigingen in de workload moet een gezamenlijke inspanning zijn. De meeste wijzigingen in de workload hebben invloed op meerdere functies en/of onderdelen, dus het betrekken van zoveel mogelijk leden van het workloadteam zorgt ervoor dat belangrijke overwegingen niet worden gemist en dat iedereen op de hoogte is van de impact op hun specifieke domein. Samenwerking helpt ook bij het duidelijk definiëren van het bereik van een wijziging en het verdelen van de benodigde taken die nodig zijn om de wijziging te realiseren in goed gedefinieerde werkitems, omdat een grotere groep met expertise in verschillende domeinen in staat zal zijn om door ervaring ondersteunde schattingen te maken voor de vereiste inspanning.

  • Hulpprogramma's: Gebruik gevestigde, in de branche bewezen hulpprogramma's en processen, zoals Agile, Scrum en Kanban-borden. Het ontwikkelen van uw eigen hulpprogramma's en processen is een belangrijke onderneming, die tijd en ontwikkelingscycli in beslag nemen die anders aan uw workload zouden kunnen worden besteed. De meeste ervaren DevOps-engineers en producteigenaren zijn bekend met dit soort hulpprogramma's en processen, dus de leercurve bij het gebruik ervan moet minimaal zijn. Op dezelfde manier zal het onboardingproces voor nieuwe medewerkers ook profiteren van het gebruik van standaardhulpprogramma's en processen, omdat ze waarschijnlijk al een zekere mate van blootstelling aan dezelfde tools en processen hebben.

Afweging: Agile-methodologie kan te strikt worden als deze te veel prescriptief is. Streven naar een balans tussen goed gedefinieerde standaarden en innovatie.

  • Implementatie: Plan het gebruik van frequente kleine, iteratieve implementaties in plaats van grote onregelmatige implementaties. Met deze methode kunt u gebruikersverhalen en werkitems beheren vanuit het oogpunt van projectbeheer en het risico op grootschalige problemen verminderen wanneer implementaties mislukken.

  • Voorwaarden: Standaardiseer uw definitie van voltooide ontwikkelingscycli om ervoor te zorgen dat ondersteunende functies, waaronder testen, documentatie en toegankelijkheidsfuncties, met succes worden voltooid.

  • Communicatie: Definieer de standaardprotocollen voor producteigenaren en projectmanagers om toekomstige releases intern en extern te promoten. U kunt bijvoorbeeld een standaard instellen voor communicatie met externe partijen over aanstaande releases. De standaard kan dicteren dat communicatie twee weken vóór de release moet worden verzonden en dat er 24 uur vóór de release een herinnering moet worden verzonden.

  • Gebruikersverhalen: Standaardiseer een sjabloon voor gebruikersverhalen. Zorg ervoor dat elk gebruikersverhaal een afzonderlijke werkeenheid is, geschreven vanuit het perspectief van de eindgebruiker. Goed geschreven gebruikersverhalen moeten de volgende kenmerken hebben:

    • Elk gebruikersverhaal moet volledig onafhankelijk van elkaar zijn. Door gebruikersverhalen onafhankelijk van elkaar te houden, voorkomt u verwarring met overlappend werk en kan het team begrijpen of het werk aan een bepaald gebruikersverhaal afhankelijk is van het werk op andere, wat helpt bij het plannen en prioritiseren.

    • Elk gebruikersverhaal is bespreekbaar. De perspectieven van de eindgebruikers en de leden van het workloadteam zijn beide essentieel om realistische gebruikersverhalen vast te leggen die in korte tijd kunnen worden gerealiseerd.

    • Gebruikersverhalen zijn waardevol voor de eindgebruiker. Wanneer u gebruikersverhalen schrijft vanuit het perspectief van de eindgebruiker, legt u de wijzigingen vast die ze willen zien en die waarde toevoegen aan hun ervaring. Als u deze focus houdt terwijl het gebruikersverhaal wordt opgesplitst in werkitems, zorgt u ervoor dat elke implementatie een verbeterde ervaring biedt.

    • De inspanning die nodig is voor een gebruikersverhaal kan met een hoge mate van vertrouwen worden geschat. Zonder een goede benadering van de uren die nodig zijn voor een bepaald gebruikersverhaal, zal de planning moeilijk zijn en neemt de kans op ontbrekende deadlines toe, wat trapsgewijze gevolgen kan hebben voor andere geplande werkzaamheden.

    • Goed geschreven gebruikersverhalen zijn klein, zodat ze binnen enkele weken kunnen worden voltooid. Kleinere artikelen zorgen ervoor dat ze schattingsbaar en beheersbaar blijven en dat werkitems haalbaar blijven.

    • Gebruikersverhalen moeten testbaar zijn. Zonder te kunnen testen of een functie is geleverd, kan de eindgebruiker er niet op vertrouwen dat het doel is bereikt. Zelfs als er nog geen test is geschreven voor een bepaald gebruikersverhaal, moet er een duidelijk inzicht zijn in hoe een test kan worden ontwikkeld om de levering van de functie te bewijzen.

  • Acceptatiecriteria: Standaardiseer een sjabloon voor acceptatiecriteria. Zorg ervoor dat acceptatiecriteria specifiek betrekking hebben op het gebruikersverhaal en ondubbelzinnig kunnen worden bewezen met behulp van een of meer acceptatietests.

  • Tracering: Zorg ervoor dat het ontwikkelingsproces traceerbaar is. U moet de status van uw productieworkload en de bijbehorende code duidelijk traceren naar kwaliteitstests, acceptatiecriteria, gebruikersverhalen en functies. Gedetailleerde tracering kan in sommige gevallen ook een wettelijke vereiste zijn, zoals gezondheidszorg.

  • Beoordeling: Voer regelmatig interne audits van uw ontwikkelprocedures uit via retrospectieven en postmortems. Procesreflectie moet zonder schuld zijn en zich richten op leren dat als verbeteringen kan worden toegepast. Zorg ervoor dat het team nadenkt over hoe effectief het gebruikersverhaal en de taken waren bij het definiëren van de benodigde taken en de nauwkeurigheid van tijdschattingen.

  • Rapporten: Standaardiseer rapporten voor belanghebbenden die nuttige metrische gegevens bieden die gericht zijn op wijzigingen. Als u zich richt op verandering, kunt u productversnelling en vertraging bijhouden. Nuttige metrische gegevens kunnen wijzigingen bevatten in:

    • Het maandelijkse groeipercentage van acceptatie.

    • Prestaties.

    • Trainingstijd.

    • De frequentie van incidenten.

    Rapportage mag niet worden gebruikt als een hulpmiddel om het werk van personen te evalueren, dus vermijd metrische gegevens zoals verhaalpunten of coderegels voor elke engineer.

Azure-facilitering

Azure Boards is een webservice waarmee teams werk kunnen plannen, bijhouden en bespreken gedurende het hele ontwikkelingsproces. Het is goed geschikt voor op Agile gebaseerde ontwikkelprocedures.

GitHub Projects is een aanpasbaar hulpprogramma voor projectbeheer waarmee u projecten kunt organiseren en integreren met behulp van problemen en pull-aanvragen in GitHub.

Controlelijst voor operationele uitmuntendheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor operationele uitmuntendheid