We volgen een agile softwareontwikkelingsproces dat in de 13 jaar dat we nu actief zijn is herzien, bijgewerkt en aangepast. We zijn blij met het proces dat we nu hebben, maar we proberen het altijd te verbeteren. Als je inefficiënties of blinde vlekken ziet, laat het ons dan weten in de reacties hieronder.
Planning en projectbeheer
Verhalen en bugfixes
Het bedrijf, meestal via één productmanager, is primair verantwoordelijk voor het schrijven van nieuwe verhalen. De inhoud moet voldoende zijn voor de auteur om zich te herinneren waar hij/zij het over had als hem/haar in de toekomst om details wordt gevraagd. Zodra de placeholder story aan de orde komt in de werkcyclus, gaat het delivery team met de relevante stake holders om de tafel zitten en stelt hen vragen over de feature. Deze gesprekken en voorbeelden benadrukken de reden voor de functie en dienen als een krachtige motivator voor het opleveringsteam.
Het is niet nodig om verhalen te schrijven in de taal, "Als een ____, wil ik ____, zodat ik ____ kan.". De lege plekken zouden ingevuld moeten zijn vanuit de gesprekken en kunnen wel of niet nuttig zijn om in het verhaal te schrijven. Dat is aan het team of ze dat willen documenteren voor het nageslacht of voor nieuwe mensen die zich bij het team aansluiten, maar het is sneller om mensen te vertellen waarom dit verhaal belangrijk is voor het bedrijf en de kennis op die manier over te dragen.
Het is niet nodig om het eens te worden over een definitie van een story die "klaar" is voor het team om aan te werken. Als het bovenaan de backlog staat en er moet aan het ontwerp worden gewerkt of er zijn meer details nodig, dan is het jouw taak om daar achteraan te gaan voordat het coderen begint. We beginnen pas met coderen als we acceptatiecriteria hebben die duidelijk genoeg zijn voor de ontwikkelaar. De ontwikkelaar schrijft meestal de stappen voor het testen voor de tester en de producteigenaar en de business.
Iedereen in het team kan een verhaal schrijven. Ontwikkelaars en testers vinden voortdurend technische fouten, bugs en inconsistenties in de UI. Het team kan dit werk prioriteren, maar het is belangrijk dat het zichtbaar is voor zowel het delivery team als de business.
Het is niet nodig om feature-werk te scheiden van bug-werk. Een bug is wanneer de software iets doet wat de business niet wil. Van een feature is sprake als de software iets doet wat de business nog niet wil. Er is geen behoefte aan een algemeen beleid van "los eerst alle bugs op". De business weet of er bugs met een lage prioriteit zijn die kunnen wachten terwijl er aan een functie met een hoge impact wordt gewerkt.
We herleiden user stories niet naar epics en splitsen ze meestal niet op in taken. Als verhalen een gemeenschappelijk thema hebben, kunnen ze worden gelabeld met een label of dezelfde kleur krijgen als dat nodig is.
Schatting
We schatten de grootte van verhalen niet in. We kunnen de business vertellen hoeveel stories we gemiddeld per release of per tijdsperiode hebben. Met behulp van deze kennis en als je ziet hoe ver een story terug is in de backlog en het aantal stories in uitvoering, kan de business ruwweg berekenen wanneer die bug fix of feature in productie komt.
Prioriteiten
Verhalen worden in de backlog gerangschikt in volgorde van prioriteit, met de verhalen met de hoogste prioriteit bovenaan. Als het verhaal of de bugfix belangrijk is, kan het naar boven worden verplaatst zodat de kans groter is dat het in de volgende release of de release daarna komt.
De business kan de prioriteiten van het delivery team op elk moment veranderen en de houding van het delivery team zou moeten zijn dat we dat graag doen omdat we er zijn om met de business samen te werken om de software zo effectief mogelijk te maken.
Af en toe moeten er bugfixes met een zeer hoge prioriteit worden uitgevoerd. We kunnen een zwembaan toevoegen aan onze online Kanban board en ze krijgen een versnelde behandeling om de fix zo snel mogelijk in productie te krijgen.
Werkstroom
Verhalen worden van links naar rechts in de online Kanban board. De meest linkse kolom is de Backlog. De meest rechtse kolom zijn stories die naar productie zijn gepusht. De kolommen daartussen variëren per project, maar omvatten meestal Ontwikkeling, Testen en Klaar voor acceptatietesten, wat een wachtrij is waar stories staan tot de volgende release naar de testomgeving voor gebruikersacceptatie, en Gebruikersacceptatietesten.
Meer dan één persoon kan een story toegewezen krijgen. Iedereen in het team kan een story verplaatsen, idealiter met een opmerking over waarom ze de verhuizing hebben gedaan. We hanteren geen harde WIP-limieten (work in progress), omdat we socialiseren dat je echt maar aan één ding tegelijk kunt werken en dat het OK is om twee stories in de kolom Development te hebben staan als je wacht op antwoord op één ervan en het een paar dagen kan duren voordat je antwoord krijgt.
Als testers het werk van ontwikkelaars nakijken en problemen vinden, schrijven ze genoeg details op zodat de ontwikkelaar het probleem kan reproduceren, idealiter met schermafbeeldingen of een walkthrough, en het verhaal wordt teruggezet naar de kolom Ontwikkeling om te worden opgelost. Dat wordt nu de topprioriteit van de ontwikkelaar en de oplossing is meestal niet tijdrovend, waarna het verhaal teruggaat naar Testen met commentaar van de ontwikkelaar over de oplossing.
Hetzelfde proces gebeurt met gebruikersacceptatietesten. Als de eigenaar van het product of de business een bug vindt of een verandering bedenkt die ze willen, wordt het verhaal bijgewerkt en verplaatst naar de kolom Ontwikkeling. Soms is de gevraagde verandering groot genoeg om een nieuwe story te rechtvaardigen die ook geprioriteerd moet worden.
Rapportagestatus
Er zijn geen dagelijkse stand-ups of statusrapporten nodig. We hebben een online Kanban board dat alle stories in voortgang toont, hun status en wie eraan werkt. Het delivery team en de business hebben toegang tot dit takenbord. Alles waar het delivery team aan werkt is transparant.
Communicatie en vergaderingen
Als er geen dagelijkse stand-ups of statusrapporten zijn, hoe communiceren we dan? Omdat we op afstand werken, doen we alles online. Als je een internetverbinding hebt, ben je klaar. We gebruiken meestal instant messaging tools en escaleren naar telefoon of video call of screen sharing als dat nodig is. E-mail en telefoongesprekken werken ook, maar die zijn secundair en worden meestal gebruikt als iemand met wie we moeten praten niet dezelfde IM-tool gebruikt als het leveringsteam.
Stockafbeeldingen laten vergaderingen er leuk uitzien, maar synchrone vergaderingen (bijv. 5 van ons moeten vandaag om 10 uur 's ochtends een gesprek voeren) zijn duur en het doel ervan kan vaak beter op andere manieren worden bereikt. Instant messaging stelt ons in staat om asynchrone vergaderingen te houden, zodat je kunt blijven werken en aan de discussie kunt deelnemen wanneer je tijd hebt. Dit voorkomt contextverandering en voorkomt dat ontwikkelaars en testers op de klok kijken, zien dat ze over 15 minuten een vergadering hebben en besluiten om niet aan iets nieuws te beginnen. Software ontwerpen, ontwikkelen en testen vereisen ononderbroken denken gedurende grote stukken tijd en async vergaderingen zijn cruciaal om iemands flow niet te verstoren.
Blokken en teamdynamiek
Als mensen in het opleveringsteam geblokkeerd zijn (bijvoorbeeld: "Ik kan niet bij de database", "Hoe wil het bedrijf dat deze knoppen eruit zien?", "Ik zit vast bij een bepaalde SignalR-syntaxis", enzovoort), dan is het aan die teamleden om dat meteen te melden. Omdat er geen dagelijkse standup is, wordt er niet gewacht tot de volgende dag om het te melden. Iedereen die kan, helpt het geblokkeerde teamlid of brengt hem in contact met iemand die hem kan helpen.
Een belangrijke veronderstelling hierbij is dat het geblokkeerde teamlid zich uitspreekt en niet uren of dagen stilletjes blijft spartelen. We zorgen ervoor dat hulp vragen niet ten koste gaat van gepest of vernederd worden omdat je iets niet weet.
Iedereen in het team moet andere teamleden helpen. In feite is de manier waarop dit wordt benaderd cruciaal. Als je een ontwikkelaar vraagt of hij ergens hulp bij nodig heeft, zal hij 9 van de 10 keer reflexmatig nee zeggen. Ze willen het zelf uitzoeken, ze denken dat ze het bijna hebben, enz. Als je in plaats daarvan vraagt: "Hoe kan ik helpen?" of "Waarom kijken we hier niet samen naar - het is lastig." of "Kun je me laten zien hoe je dat deed? Ik wil het ook leren." zul je meer succes hebben.
Wees nederig. Wees attent. Wees oprecht. Wees behulpzaam. Wees vrolijk.
Ontwikkelingspraktijken
Testen
We schrijven VEEL client- en server-side unit tests. Deze tests helpen ervoor te zorgen dat de gelukkige padtests gedekt zijn en dat de hoekgevallen op zijn minst doordacht zijn. Ze zorgen ook voor een ontkoppeld ontwerp waarbij we dingen kunnen namaken die niet direct worden getest, zoals databasequery's die specifieke gegevens moeten retourneren om een codepad te bereiken.
Deze tests worden na verloop van tijd waardevoller. Je kunt iets veranderen in een deel van de codebase en er zeker van zijn dat je niet iets kapot hebt gemaakt dat je 6 maanden geleden hebt geschreven, nadat je hebt gezien dat alle tests geslaagd zijn.
Het uitvoeren van de unit tests om de software te controleren is niet genoeg om te weten dat we klaar zijn, dus gebruiken we ook een combinatie van integratie, end-to-end en handmatige tests.
We schrijven een aantal, maar niet zo veel integratie- en end-to-end tests waarbij we de database, API-aanroepen of de hele front- en back-end testen. Deze tests zijn langzamer uit te voeren en moeilijker te onderhouden met alle instellingen die nodig zijn, dus we gebruiken dit soort tests alleen in de meest cruciale onderdelen van de app (bijv. het winkelwagentje moet werken).
Ontwikkelaars zijn verantwoordelijk voor het handmatig testen van hun eigen code. Zij hebben het geschreven, dus ze moeten weten waar de valkuilen kunnen zitten. Ze zijn ook verantwoordelijk voor het schrijven van gedetailleerde testscripts voor teamleden die na hen gaan testen. Deze worden meestal toegevoegd aan de story. Een ontwikkelaar kan een story alleen verplaatsen als hij zijn eigen handmatige tests heeft uitgevoerd en gedetailleerde acceptatiecriteria heeft geschreven.
We hebben ook een tester die handmatig test om te controleren of de ontwikkelaar niets vergeten is. Deze handmatige tests zijn nuttig voor limiettests (bijvoorbeeld, probeer waarden als -1, 0 of 1), validatietests (bijvoorbeeld, als het veld zegt dat het vereist is, is het dat ook echt), cross-browsertests (bijvoorbeeld, als de ontwikkelaars Chrome gebruiken om te coderen/testen, werkt het dan ook met Safari op iPads?) en logicatests.
We meten geen testdekking. Dat hebben we in het verleden wel gedaan, maar we hebben nooit geweten wat we met de gegevens moesten doen. 100% testdekking is geen doel. 50% of 75% dekking vertelt me niet dat we meer tests nodig hebben, of dat we er genoeg hebben. Het is trivia en voegt overhead toe, dus we doen geen moeite meer.
Codepatronen en refactoring
We ontwikkelen codepatronen voor het project door alle ontwikkelaars om input te vragen. Na verloop van tijd veranderen we van gedachten over sommige van die patronen of voeren we updates uit voor tools. Als dat mogelijk is, halen we het patroon eruit als een gedeeld stuk code zodat het op één plek kan worden veranderd. Als dat niet praktisch is, brengen we code naar voren naar de nieuwe patronen terwijl we eraan werken.
We refactoren code als dat nodig is, meestal volgens onze eigen versie van de padvindersregel (laat de camping altijd schoner achter dan je hem gevonden hebt). Als je een stuk code opent om een kleine verandering aan te brengen, laat de rest van de code dan met rust. Als je grote veranderingen moet maken, breng die code dan naar de nieuwste coderingspatronen en tools die het team vandaag gebruikt.
Omdat we uitgebreide testsuites hebben, zijn grote codewijzigingen niet eng voor het team.
Pair Programming en Codebeoordelingen
Pair programming wordt gebruikt, maar meestal bij nieuwe of complexe code of met nieuwe teamleden. De meeste ontwikkelaars werken liever alleen aan het probleem, maar soms is dat een beetje overweldigend en dan is een uurtje of wat paren enorm nuttig.
We reviewen elkaars werk, maar niet bij elke commit. Als een ontwikkelaar zich een beetje onzeker voelt over zijn werk of coderingspatronen of werkt aan iets dat door het hele team gedeeld zal worden, dan is een code review zinvol.
Pair programming en code-reviews zijn fantastische manieren om coderingspatronen te socialiseren en te controleren of ontwikkelaars de afgesproken ontwikkelpatronen van het team begrijpen en gebruiken.
Just-in-time architectuur en UI-ontwerp
We hebben geen groot architectuurplan voordat we aan het project beginnen. We hebben een ruw idee van hoe het zal gaan, maar we proberen zo te coderen dat we opties hebben en de architectuur just-in-time kunnen veranderen als dat nodig is tijdens de ontwikkeling.
Voor sommige verhalen is het UI-ontwerp de sleutel tot het oplossen van het probleem. In die gevallen gebruiken we mockup-tools om snel een UI te ontwerpen en feedback te krijgen van de business en de producteigenaar. We doorlopen die feedback totdat we tevreden zijn met het ontwerp en dan worden de mockups bijlagen bij het verhaal zodat de ontwikkelaar een sjabloon heeft van hoe het eindproduct eruit moet zien.
UI-ontwerpmockups kunnen heel krachtig zijn als ze live met de klant worden gemaakt en de tools zijn eenvoudig genoeg om ideeën heel snel om te zetten in concrete ontwerpen.
Vertakking
We maken meestal geen branches aan voor features of bugfixes. Iedereen werkt op master. We hebben takken voor releases, zoals een testtak voor gebruikersacceptatie en een productietak, zodat we op een tak kunnen springen en een fix kunnen maken en het terug kunnen samenvoegen naar de lagere takken als dat nodig is. We maken labels/tags voor elke release kandidaat.
Continue uitrol en feedback
Elke code commit duwt een nieuwe release naar een ontwikkelingswebserver. Dit test onze code-integraties en builds, maar wat nog belangrijker is, het geeft de tester van het team, de producteigenaar en alle andere belanghebbenden een live blik op de laatste werkende code.
Het opleveringsteam vraagt voortdurend om feedback van de producteigenaar en de business over hoe de software werkt of niet werkt, zodat we kunnen bijsturen. Bij maatwerksoftware is de sleutel tot het krijgen van wat je wilt, het geven van veel feedback aan het opleveringsteam over de software die in ontwikkeling is. Continue implementatie is de plek om de nieuwste code uit te proberen.
Beheer van releases
Time-boxed vs. Feature-gedreven
Releases kunnen ofwel tijdsgebonden zijn, waarbij we alles wat klaar is elke 2 weken uitbrengen, of ze kunnen feature-gedreven zijn, waarbij we uitbrengen wanneer een functie voltooid is. We sluiten soms een compromis en brengen elke 2 weken uit, tenzij er iets belangrijks is dat bijna af is, en dan wachten we nog een paar dagen voordat we die functie uitbrengen. We doen dit niet bij elke release en de producteigenaar, de business en het delivery team moeten tot een consensus komen over de vraag of een release moet worden uitgesteld.
Time-boxed releases zijn mooi en stabiel en geven de business een verwachting van wanneer ze werkende code in productie kunnen hebben. We gebruiken feature toggles om delen van de app uit te schakelen die nog niet klaar zijn voor productie, zodat we nog steeds code kunnen uitrollen met gedeeltelijke features.
We bouwen geen sprints op met punten voor time-boxed releases omdat ik negatieve bijwerkingen van die aanpak heb gezien. Teamleden zijn vroeg klaar en willen niet aan een nieuw verhaal beginnen omdat het voor de sprint van volgende week is, of teamleden werken als een gek om het af te ronden voor de einddatum van de sprint zodat hun functie in deze release komt. Beide gaan in tegen het idee van een gestaag, duurzaam werktempo. Als we bezig zijn met een release en de code is nog niet klaar en zal dat morgen ook niet zijn, dan is dat OK.
Definitie van Gedaan
We zijn het erover eens dat een story klaar is als aan de acceptatiecriteria is voldaan, de code is ingecheckt, er geautomatiseerde tests voor de code zijn, gedetailleerde stappen voor het testen van de story zijn geschreven, de handmatige tests geen resterende problemen hebben gevonden en de business de story als klaar heeft geaccepteerd. Op elk moment kan een story die naar rechts is verplaatst en niet aan een van deze criteria voldoet, terug naar links worden gestuurd om opnieuw te worden bewerkt.
Acceptatietest van de Release Candidate en implementatie in productie
We zetten een integratieomgeving voor ontwikkeling op, een staging- of testomgeving voor gebruikersacceptatie en productie. Zodra een release candidate is uitgerold, testen de producteigenaar en de business die functies. In het ideale geval is dit niet de eerste keer dat ze deze functies of bugfixes zien en bevestigen ze dat ze nog steeds werken zoals verwacht in deze release candidate en omgeving.
Nadat de business en product owner toestemming hebben gegeven dat de release candidate er goed uitziet, wordt deze uitgerold naar productie.
Procesbeoordeling en -verbetering
Terugblik
We hebben geen sprint retrospectives. Elk moment is een goed moment voor verbetering. We hebben een cultuur waarin suggesties altijd zorgvuldig worden overwogen en waar mogelijk worden opgenomen, zelfs als ze een beetje experimenteel zijn.
Berekeningen
Na een release kunnen we onze cyclustijd herberekenen (hoe lang het duurt voor een story geïnstalleerd is in productie vanaf het moment dat het werk begint). In combinatie met het tellen van het aantal stories per release kan dit de business een eenvoudig hulpmiddel geven om te voorspellen wanneer een story die ze op het oog hebben in productie wordt genomen.
Bijvoorbeeld, als we gemiddeld 10 stories per release voltooien, en de story in kwestie is nummer 3 in de backlog en er zijn op dit moment 6 stories op het bord in uitvoering, dan is er een kleine kans dat die story in de huidige release komt (het zou de 9e story zijn, en we hebben een gemiddelde van 10), maar er is een zeer grote kans dat die story in de volgende release na de huidige komt.
