Share
Met een tool die zo krachtig is als Pivotal Tracker, kan het soms lastig zijn om je ervan te overtuigen hoe je het optimaal kunt gebruiken. En hoewel we niet doen alsof we alle antwoorden hebben, heeft de tijd die we hebben besteed om diep en vies te worden met Tracker ons een goed uitkijkpunt gegeven om de betere praktijken van de ... minder goede te bespreken.
Hier zijn dan wat wij beschouwen als leidende praktijken voor het verkrijgen van het meeste sap van de Tracker-vrucht en voor Agile succes in bredere zin.
Taal is vloeiend en vatbaar voor interpretatie, dus probeer een Tracker-verhaal niet te gebruiken als een standaard voor een gesprek. Overweeg een ontwerpdoorloop van een verhaal of project met ondersteuning en testers te doen, zodat ze kunnen helpen met verschillende perspectieven op gebruik en verzoeken van klanten.
Staan jouw verhaalreacties op stapel? Breng mensen kort bij elkaar om de problemen te bespreken en werk het verhaal vervolgens bij met de belangrijkste punten. Het persoonlijk bespreken van problemen kan misverstanden minimaliseren die te gemakkelijk een afleiding of tijdverlies kunnen worden.
Waar mogelijk moeten klanten en ontwikkelaars samen verhalen schrijven omdat een verhaal zowel een klantwaarde als een ontwikkelaarproduct is. Op deze manier kunnen ieders interesses en standpunten worden gedeeld en afgestemd.
Voer een wekelijkse iteratieplanningsbijeenkomst uit, zodat het team komende verhalen kan beoordelen en beoordelen. Ontwikkel schattingen als een groep, zodat iedereen kan worden gehoord. Om het proces lichter te maken, zou je een schattingsspel kunnen spelen. We raden Settlers of Catan hiervoor niet aan. Probeer in plaats daarvan iets meer als Rock, Paper, Scissors.
Als u een bepaald verhaal wilt schatten, laat dan elk teamlid de vingers uitslaan - in lijn met de schattingsschaal die u hebt gekozen - om hun suggestie voor de complexiteit van het verhaal aan te geven. Heeft iedereen hetzelfde geschat? Super goed! Zo niet, begin dan een discussie en schat samen het verhaal.
Maak verhalen die incrementeel zijn en gericht zijn op het perspectief van de gebruiker. Dus als je een bakstenen muur moet repareren, probeer dan te focussen op de interactie van de gebruiker met een specifiek aspect van de muur, niet met de hele muur zelf. Het verhaal, "De muur moet in goede vorm zijn", zou nuttiger zijn als: "Passanten moeten geen zichtbare scheuren in de muur zien."
Tegelijkertijd zullen sommige verhalen een groter bereik hebben of ingewikkelder zijn, ondanks je beste bedoelingen. Je moet dit nog steeds proberen te minimaliseren en de oefening alleen reserveren voor verhalen met een onduidelijke of enorme reikwijdte, en ze vervolgens opsplitsen. Anders is een schatting van 8 (op basis van de Fibonacci-schaal) een schreeuw om hulp.
Als ontwikkelaar moet je om opheldering vragen en zoeken naar naden waar het verhaal kan worden opgesplitst in meerdere verhalen.
Het schip besturen en tegelijkertijd een lek dichten is op zijn zachtst gezegd een uitdaging. Daartoe zou u een Tracker Czar moeten hebben, die ook niet zou moeten coderen in het project waarvan zij eigenaar zijn. Het bezitten van een project is een grote verantwoordelijkheid, maar het maakt een enorm verschil.
Hoewel het waar is dat iedereen verhalen kan maken en deze in de Icebox kan plaatsen, moet alleen de klant (of een PM die optreedt namens de klant) prioriteit geven aan hen.
Als eigenaar van de onderneming moet een deel van het besluitvormingsproces van een klant bepalen welke functies voorrang hebben boven andere. Met andere woorden, de klant moet de moeilijke keuzes maken.
Door karweitjes om te zetten in functies worden ze opnieuw geformuleerd als items met directe en verifieerbare waarde voor zowel de eindgebruiker als projectdoelen. Dit kan eenvoudigweg een kwestie zijn van het herschrijven van het verhaal, of krachtiger debatteren voor zijn bedrijfswaarde.
Herstel nooit een geaccepteerd verhaal; maak in plaats daarvan een nieuw verhaal of een nieuwe bug. Het is schoner, je kunt nieuwe informatie gerichter houden en het doet niets af aan het werk dat al is gedaan. Je kunt altijd in de URL naar het originele verhaal plakken voor context.
Het afwijzen van een verhaal met zowel tact als duidelijkheid kan een uitdaging zijn, maar er zijn enkele strategieën om het soepeler te laten verlopen.
Als je niet aan boord bent met een bepaalde functie of een bepaald verhaal, voeg je commentaar toe met "weigeren:" - het is gemakkelijker om te scannen en erachter te komen welke opmerking gerelateerd is aan de weigering.
Er kan immers meer zijn dan op het eerste gezicht lijkt. Nogmaals, heb een gesprek. Beoordeel opnieuw wat er ontbreekt en maak een nieuw verhaal; verwerp het niet alleen zonder alle details te kennen.
Locatie, locatie, locatie - het is van het allergrootste belang. Verplaats een afgewezen artikel naar de top van de actieve groep in de huidige iteratie. Wanneer ontwikkelaars kijken naar het volgende verhaal om aan te werken, zullen ze het afgewezen verhaal als het volgende zien.
Zelfs als er geen aantoonbaar universele manier is om Pivotal Tracker te gebruiken voor Agile ontwikkeling, en hoewel het een verscheidenheid aan benaderingen kan accommoderen, hebben tijd en ervaring ons bewezen dat sommige praktijken logischer zijn.
Als u vragen of feedback voor ons heeft, horen we graag van u! Bezoek onze website voor meer informatie of neem contact met ons op via [email protected].
Accentsconagua