Aanbevelingen voor het formaliseren van softwareontwikkeling en -beheer
Is van toepassing op deze controlelijst voor Azure Well-Architected Framework Operational Excellence:
| OE:03 | Formaliseer software-ideeën- en planningsprocessen. Trek uit de gevestigde industrie- en organisatiestandaarden. Gebruik een algemene, geprioriteerde achterstand en voldoende gedetailleerde specificaties. Op basis van resultaten kunt u continue verbeteringen aanbrengen in uw planningsproces. |
|---|
In deze handleiding worden de aanbevelingen beschreven voor het beheren van softwareontwikkelingsprocedures in overeenstemming met vastgestelde standaarden. Het vermogen van uw team om software van hoge kwaliteit te produceren, is afhankelijk van een gestructureerde, gezamenlijke benadering van ontwikkelingsplanning. Producteigenaren en -managers moeten het werk dat ontwikkelaars op elk gewenst moment in een ontwikkelingscyclus doen, duidelijk kunnen begrijpen en verwoorden voor belanghebbenden. Ontwikkelaars moeten daarentegen de doelstellingen van de ontwikkelingscyclus begrijpen via goed geschreven functies, gebruikersverhalen en acceptatiecriteria. Vastgestelde standaarden definiëren hoe ontwikkelprocedures moeten worden uitgevoerd en stellen het workloadteam in staat om effectief samen te werken, waardoor het risico op verwarring bij doelen en verwachtingen wordt verminderd.
Belangrijke ontwerpstrategieën
Formaliseer uw softwareontwikkelingsprocedures om ervoor te zorgen dat producteigenaren, projectmanagers en ontwikkelaars de doelstellingen van elke sprint begrijpen en consistente kwaliteit leveren aan belanghebbenden. Raadpleeg de handleiding voor continue integratie als u de richtlijnen voor ontwikkelingsprocedures wilt bekijken.
Samenwerkings- en communicatiestandaarden tot stand brengen
Samenwerking: Het proces voor het definiëren van voorgestelde wijzigingen in de workload moet een gezamenlijke inspanning zijn. De meeste wijzigingen in de workload zijn van invloed op meerdere functies en/of onderdelen, dus het betrekken van zoveel mogelijk leden van het workloadteam helpt ervoor te zorgen dat belangrijke overwegingen niet worden gemist en dat iedereen op de hoogte is van de impact op hun specifieke domein. Samenwerking helpt ook duidelijk het bereik van een wijziging te definiëren en de benodigde taken te verdelen die nodig zijn om de wijziging in goed gedefinieerde werkitems uit te voeren, omdat een grotere groep met expertise in verschillende domeinen schattingen met ervaring kan bieden voor de vereiste inspanning.
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 toekomstige releases. De standaard kan dicteren dat de communicatie twee weken vóór de release moet worden verzonden en dat er 24 uur vóór de release een herinnering moet worden verzonden.
Beoordeling: Voer regelmatig interne audits uit van uw ontwikkelprocedures via retrospectieven en postmortems van de ontwikkelingscyclus. Processpiegeling moet schuldloos zijn en moet zich richten op leren dat kan worden toegepast als verbeteringen. Zorg ervoor dat het team weerspiegelt hoe effectief het gebruikersverhaal en de taken waren bij het definiëren van de benodigde taken en de nauwkeurigheid van tijdsramingen.
Rapporten: Standaardiseer rapporten voor belanghebbenden die nuttige metrische gegevens bieden die gericht zijn op verandering. Door te focussen op wijzigingen kunt u productversnelling en vertraging bijhouden. Nuttige metrische gegevens kunnen wijzigingen bevatten in:
Het maandelijkse groeipercentage van de acceptatie.
Prestaties.
Trainingstijd.
De frequentie van incidenten.
Rapportage mag niet worden gebruikt als hulpprogramma om het werk van personen te evalueren, dus vermijd metrische gegevens, zoals verhaalpunten of coderegels voor elke engineer.
Industriestandaard hulpprogramma's kiezen
Gebruik gevestigde, industrie bewezen tools en processen, zoals Agile, Scrum en Kanban boards. Het ontwikkelen van uw eigen hulpprogramma's en processen is een belangrijke onderneming, waarbij tijd en ontwikkelingscycli nodig zijn die anders kunnen worden besteed aan uw workload. De meest ervaren DevOps-technici en producteigenaren zijn bekend met dit soort hulpprogramma's en processen, dus de leercurve bij de overstap 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 mate van blootstelling aan dezelfde tools en processen hebben.
Compromis: Agile-methodologie kan te strikt worden als het te prescriptief is. Streven naar een evenwicht tussen goed gedefinieerde standaarden en innovatie.
Een standaard gebruiken om scenario's voor eindgebruikers vast te leggen
Gebruikersverhalen: Een sjabloon standaardiseren 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 helpt het team te begrijpen of het werk aan een bepaald gebruikersverhaal afhankelijk is van het werk aan anderen, wat helpt bij het plannen en prioritiseren.
Elk gebruikersverhaal is onderhandelbaar. De perspectieven van eindgebruikers en workloadteamleden zijn beide essentieel om realistische gebruikersverhalen vast te leggen die gedurende een 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. Door deze focus te behouden terwijl het gebruikersverhaal is opgesplitst in werkitems, zorgt u ervoor dat elke implementatie een verbeterde ervaring biedt.
De inspanning die nodig is voor een gebruikersverhaal is met een hoge mate van vertrouwen te schatten. Zonder een nauwe benadering van de uren die nodig zijn voor een bepaald gebruikersverhaal, zal de planning moeilijk zijn en het potentieel voor ontbrekende deadlines toeneemt, waardoor trapsgewijze effecten op ander gepland werk ontstaan.
Goed geschreven gebruikersverhalen zijn klein, zodat ze binnen een paar weken kunnen worden voltooid. Kleinere verhalen helpen ze te schatten en beheersbaar te houden en werkitems te realiseren.
Gebruikersverhalen moeten testbaar zijn. Zonder te kunnen testen of een functie is geleverd, kan de eindgebruiker niet vertrouwen dat het doel is bereikt. Zelfs als een test nog niet 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: Een sjabloon standaardiseren voor acceptatiecriteria. Zorg ervoor dat acceptatiecriteria specifiek betrekking hebben op het gebruikersverhaal en ondubbelzinnig kunnen worden bewezen met behulp van een of meer acceptatietests.
Implementatieprocedures standaardiseren
Implementatie: Plan om frequente kleine, iteratieve implementaties te gebruiken in plaats van grote onregelmatige implementaties. Met deze aanpak 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.
Tracering: Zorg ervoor dat het ontwikkelingsproces traceerbaar is. U moet de status van uw productieworkload en de bijbehorende code duidelijk traceren naar kwaliteitscontroletests, acceptatiecriteria, gebruikersverhalen en functies. Gedetailleerde tracering kan in sommige gevallen ook een wettelijke vereiste zijn, zoals gezondheidszorg.
Azure-facilitering
Azure Boards is een webservice waarmee teams werk in het hele ontwikkelingsproces kunnen plannen, bijhouden en bespreken. Het is goed geschikt voor op Agile gebaseerde ontwikkelprocedures.
GitHub Projects is een aanpasbaar hulpprogramma voor projectbeheer dat projecten kan organiseren en kan integreren met behulp van problemen en pull-aanvragen in GitHub.
Verwante koppelingen
Communitykoppelingen
Controlelijst voor operationele uitmuntendheid
Raadpleeg de volledige set aanbevelingen.