Toe ek in 2020 my werk by Wayfair gekry het, was ek opgewonde om by 'n skraal, skrapse span aan te sluit wat 'n b2b-instrument in stand gehou het wat groot hoeveelhede besigheid aangedryf het. Ek het gekom van 'n rol waar ek meestal in 'n silo gewerk het, so ek was veral opgewonde om weer deel van 'n ontwikkelingspan te wees. Ek het egter baie vinnig gevind dat baie van die span soveel kundigheid gehad het in die gereedskap wat ons gebruik het dat hulle hierdie voorafbepaalde aanname gehad het dat ander ontwikkelaars dieselfde agtergrond, ervaring en kennis gehad het. Die groot probleem was dat die gereedskap waaraan ons gewerk het intern en eie was, so baie van die nuwer ontwikkelaars het hulle nie so goed geken as die ervare ontwikkelaars nie. Nou, dit is nie 'n kwessie oor die algemeen nie. Dit het egter baie problematies geword toe Jira-kaartjies geskep, geprioritiseer, geskat en toegeken is met min besonderhede. Natuurlik, die titel het die algemene probleem verduidelik, en die ervare ontwikkelaar wat dit geskryf het, het waarskynlik presies geweet waar om te begin soek om veranderinge aan te bring, maar dié van ons wat nuwer aan die platforms was, het baie min gehad om op te bou om te begin. Dit het groot gate in doeltreffendheid veroorsaak, waar ons voortdurend die meer vaste ontwikkelaars gejaag het vir meer inligting. Nog 'n neweproduk van hierdie opstelling was dat ons tegniese ontwerpvergaderings geneig was om te sloer, aangesien meer en meer van ons vrae gehad het oor kaartjies wat vir skatting aangebied word. Besonderhede is voortdurend in gesprek uitgestryk, maar niks is opgeneem nie. Hierdie vergaderings sou voortsleep, en dan sou dieselfde vrae terugkom sodra die kaartjie toegeken is (tensy die gevolmagtigde die gesprek van weke gelede waar die vrae aanvanklik gevra is, magies kan onthou). Hierdie werkvloei was ongelooflik frustrerend en ondoeltreffend. Maar, daar is hoop! 'n Kort rukkie nadat ons hierdie kwessie herken en dit bespreek het, het vergaderings gladder begin vloei, minder tyd geneem en meer impak gehad. Kaartjies was ryk aan besonderhede en maklik om op te tree, te toets en te voltooi. Hier is hoe ons dit gedoen het. Die probleem: Onvoorbereide kaartjies en lang vergaderings Ons tegniese ontwerpvergaderings sou dikwels ontspoor word deur kaartjies wat nie genoeg besonderhede het nie. Ontwikkelaars, ontwerpers en ander belanghebbendes sal te veel tyd spandeer om bykomende inligting te soek of om vae aspekte van 'n taak uit te klaar. Dit het nie net ons vergaderings verleng nie, maar het ook die ontwikkeling vertraag aangesien toegewysde kaartjies gereeld sou terugspring, wat meer verduideliking vereis het voordat werk kon voortgaan. 'n Goeie voorbeeld hiervan kan 'n kaartjie wees wat gerapporteer is deur 'n vaste ontwikkelaar wat eenvoudig gesê het: "Ons moet pryse vir vloerskus vasstel." Dit is duidelik dat sonder 'n voldoende hoeveelheid agtergrondinligting is daar absoluut niks wat jy kan doen wanneer jy hierdie kaartjie ontvang nie. Wat is die probleem met pryse op vloer-skus? Wat word verwag om te gebeur? Maak die hoeveelheid van die sku in die wa saak? Daar is baie oop vrae en regtig geen manier om te begin werk sonder om by 'n vergadering in te spring nie. 'n Beter kaartjiebeskrywing is dalk. "Vloer-sku's word grootmaat geprys en ons stelsel hanteer nie die prys-/hoeveelheidswiskunde behoorlik wanneer die hoeveelheid in die wa die grootmaatprysdrempels oorskry nie." Nou, daar is nog nie genoeg detail hier nie, maar dit verduidelik ten minste die probleem behoorlik. Ek gaan nie die voorbeeld moeg maak nie, maar die ontwikkelaar(s) sal al hierdie besonderhede moet invul met herhaalde vrae, gesprekke en aanbiedings totdat ons genoeg besonderhede het om te skat of aan die kaartjie te werk, afhangende van die huidige taak. Dit het gelei tot baie verlore tyd wat ons as ontwikkelaars nie kon terugkry nie. Die oplossing: Implementering van kaartjiesjablone Om hierdie probleem op te los, het ons 'n stel gestruktureerde kaartjiesjablone ontwikkel wat aangepas is vir die tipe werk wat gedoen word. Hierdie sjablone het verseker dat elke kaartjie - hetsy 'n foutverslag, ontwerpverandering, kenmerkversoek of optimaliseringstaak - al die nodige inligting bevat het voordat dit bespreek of toegewys is. Die reël was eenvoudig: as die sjabloon nie volledig voltooi was nie, was die kaartjie nie gereed vir die vergadering of vir ontwikkeling nie. Foutverslae Beskrywing: 'n Kort, maar gedetailleerde beskrywing van die probleem Verwagte gedrag: 'n Meer gedetailleerde verduideliking, insluitend skermkiekies of Figma-verwysings, van hoe dinge behoort te werk. Werklike gedrag: 'n Gedetailleerde beskrywing van wat gebeur en hoe dit verskil van die verwagte gedrag Stappe om te herskep: Spesifieke, gedetailleerde stappe oor hoe om die probleem te herskep. Dit moet so benader word dat iemand 'n nuwe incognito-venster in die instrument kan oopmaak en die probleem kan herskep sonder om van die stappe af te wyk. (opsioneel) Ontwikkelaarnotas: Hierdie is 'n opsionele afdeling waar ons voorgestelde benaderings kan insluit as ons reeds 'n goeie idee het oor waar dit moet gaan of hoe dit ontwikkel moet word. Ons wil nie ontwikkelaars dwing om dinge op 'n sekere manier te doen nie, maar enige leiding hier kan help om die uitvoering van kaartjies later te bespoedig. (opsioneel maar verkieslik) Eksterne impakte: Dit is waar ons enige eksterne bronne noem wat hierdie werk kan beïnvloed. Is daar spanne wat reeds 'n oplossing vir 'n fout in ons API geskep het wat in kennis gestel sal moet word wanneer ons dit regmaak? Maak hierdie fout staat op ander spanne/API's/bronne vir inligting wat moontlik 'n impak kan hê op hoe lank dit neem om dit reg te stel? (opsioneel) Impak: Het dit 'n bekende, meetbare impak op die span of besigheid? Dit is nie altyd bekend of maklik om te meet nie, en daarom is dit 'n opsionele veld. Maar dit is belangrik om te weet vir prioritisering as dit bestaan. Ontwerp veranderinge Beskrywing: 'n Kort, maar gedetailleerde beskrywing van die probleem Verwagte gedrag: Skermkiekies of Figma-skakels vir die verwagte, ontwerpte gedrag. Werklike gedrag: Skermkiekies of video's wat besonderhede gee oor wat werklik gebeur, sowel as 'n beskrywing van wat gebeur en hoe dit verskil van die verwagte gedrag (opsioneel) Stappe om te herskep: As dit 'n spesifieke UI-element is wat slegs in spesifieke situasies verskyn, moet ons presies weet hoe/wanneer dit teenwoordig moet wees sodat ons weet hoe om ons veranderinge te toets. (opsioneel) Ontwikkelaarnotas: Hierdie is 'n opsionele afdeling waar ons voorgestelde benaderings kan insluit as ons reeds 'n goeie idee het oor waar dit moet gaan of hoe dit ontwikkel moet word. Ons wil nie ontwikkelaars dwing om dinge op 'n sekere manier te doen nie, maar enige leiding hier kan help om die uitvoering van kaartjies later te bespoedig. (opsioneel) Impak: Het dit 'n bekende, meetbare impak op die span of besigheid? Dit is nie altyd bekend of maklik om te meet nie, en daarom is dit 'n opsionele veld. Maar dit is belangrik om te weet vir prioritisering as dit bestaan. Kenmerkversoeke Beskrywing: 'n Volledige gedetailleerde prentjie oor wat die kenmerk is. Hoe dit moet funksioneer, wat die verwagte insette/uitsette is, ens. Ons moet ook enige redenasie wat ons het oor hoekom hierdie kenmerk hier aangevra word, insluit. Ontwikkelaarnotas: Die ontwikkelaar moet hierdie afdeling gebruik om leiding te gee oor bekende raamwerke/patrone wat gebruik moet word om naatloos by die res van ons kodebasis in te pas. Ons wil nie die ontwikkelaars dwing om kode op enige sekere manier te skryf nie, maar enige leiding hier sal die uitvoering van kaartjies vinniger maak en behoort tot meer vaartbelynde PR-gesprekke te lei. (opsioneel maar verkieslik) Mockups: As ons voorbeeldvragte, skermkiekies of Figma-verwysings het wat ontwikkeling moet lei, moet dit alles hier ingesluit word. (opsioneel maar verkieslik) Eksterne impakte: Dit is waar ons enige eksterne bronne noem wat hierdie werk kan beïnvloed. Is daar spanne wat reeds 'n oplossing geskep het vir 'n ontbrekende kenmerk in ons API wat in kennis gestel sal moet word wanneer ons dit byvoeg? Maak hierdie kenmerk staat op ander spanne/API's/bronne vir inligting wat moontlik 'n impak kan hê op hoe lank dit neem om dit te bou? (opsioneel) Impak: Het dit 'n bekende, meetbare impak op die span of besigheid? Dit is nie altyd bekend of maklik om te meet nie, en daarom is dit 'n opsionele veld. Maar dit is belangrik om te weet vir prioritisering as dit bestaan. Optimaliseringstake Beskrywing: 'n Kort, maar gedetailleerde beskrywing van die probleem Huidige staat: 'n Meer gedetailleerde verduideliking van hoe die kode tans werk en hoekom dit ondoeltreffend is. Voorkeurstaat: 'n Gedetailleerde beskrywing van wat ons beoog om met hierdie optimalisering reg te stel, watter doelwitte ons probeer bereik Ontwikkelaarnotas: Dit is 'n gids van die ontwikkelaar wat die behoefte aan optimalisering uitroep. Dit moet spesifieke lêers en toetse uitroep wat geredigeer moet word sowel as die spesifieke afdelings wat ons glo die bottelnek in prestasie is of verwarring veroorsaak. : Toets Notas oor hoe hierdie optimalisering bekragtig of geverifieer kan word. Ons moet nie net sien dat ons werklik iets uit hierdie proses gekry het nie (en dit is dalk iets waaroor ons kan spog), maar ons moet ook verifieer dat die veranderinge nie enige bekende eksterne prosesse beïnvloed het wat op die kode staatgemaak het nie. verander. Eksterne impak: Dit is waar ons enige eksterne bronne noem wat hierdie werk kan beïnvloed. Maak hierdie kenmerk staat op ander spanne/apis/bronne vir inligting wat moontlik 'n impak kan hê op hoe lank dit neem om dit te bou of te toets? Impak: Het dit 'n bekende, meetbare impak op die span of besigheid? Dit is nie altyd bekend of maklik om te meet nie, maar om 'n herfaktor of optimalisering te regverdig, moet ons hierdie inligting hê. Die impak van sjablone Die resultate was onmiddellik. Ons het vinnig gesien dat ons ongeveer 3x meer kaartjies in 'n enkele uur lange tegniese ontwerpvergadering kon deurkom as wat ons voorheen kon. Die besprekings wat ons tydens hierdie vergaderings gehad het, was ook meer voordelig en impakvol. Ons het in die proses die tyd geneem om randgevalle uit te roep, spanne wat geraak is, en potensiële vertoningsstoppers of bottelnekke in die proses, en het ontwikkelaars voorberei vir die werk in plaas daarvan om al ons tyd te spandeer om te probeer verstaan vir meer besonderhede. Ons het onsself ook in 'n patroon ingedwing waar ons al hierdie terugvoer in die kaartjie aangeteken het, hetsy in die beskrywing of kommentaar. Die sjablone was 'n konstante herinnering dat hierdie besonderhede belangrik was en dat dit teenwoordig en maklik moes wees om te vind. Op 'n manier het hierdie sjablone ons brein opgelei om 'n dokumentasie-eerste benadering tot hierdie kaartjies te volg, om te verseker dat wie ook al die kaartjie gegryp het, of dit nou 'n junior ontwikkelaar of gesoute ingenieur is, genoeg inligting sal hê om 'n hoë-gehalte kode te skryf . Vervolgens het ons opgemerk dat ons ontwikkelingsiklusse meer bondig was, ons skattings meer akkuraat was, en ons het daardie gesogte 100%-voltooiingsmerk op naellope baie meer gereeld bereik as wat ons ooit tevore gehad het. Ons kon ons bord byna konsekwent skoonmaak. Nie net is dit belangrik vir die besigheid omdat hulle opdaterings ontvang het toe ons vir hulle gesê het dat hulle dit sal ontvang nie, maar dit was 'n groot vertroueversterker vir die span aangesien jy jouself voortdurend in 'n posisie van sukses plaas. Ons belanghebbendes het ons verbeterde doeltreffendheid en deurvloei gesien en 'n groter vertroue in ons span en ons proses gekry. Hulle het ook opgemerk dat ons kode 'n hoër gehalte is, aangesien ons meer tyd kon spandeer om op die werklike probleem op hande te fokus. Ons het van die begin af geweet dat dit ons lewens as ontwikkelaars sou verbeter, maar ons het nie besef hoeveel van 'n positiewe impak dit ook op ons sakevennote sou hê nie. Sleutel wegneemetes vir ander spanne As jy voel dat jou span voortdurend belas word deur 'n gebrek aan bevestiging, kan dit die moeite werd wees om te ondersoek of die skep van gestruktureerde kaartjiesjablone vir jou kan werk. Dit is belangrik om te noem dat dit wel bykomende ontwikkelaartyd neem om die kaartjies uit te voer met genoeg detail om op te tree. Ek glo wel dit is 'n geregverdigde koste en dit lei tot groot kostebesparings op die lang termyn aangesien dit jou werkvloei geweldig verbeter, maar dit is belangrik om te noem dat hierdie veranderinge nie net gratis gebeur nie. Iemand moet tyd afstaan om navorsing te doen en 'n kaartjie van hoë gehalte op te skryf en dat iemand waarskynlik jou ontwikkelingspan sal wees. Dit gesê, dit is maklik om te sien hoe groot oorwinning dit vir 'n span kan wees. Om te begin sal ek 'n paar kort stappe aanbeveel. Evalueer of jy werklik 'n probleem het of nie. Soms sukkel een of twee ontwikkelaars met dokumentasie of kennis-oordrag, maar dit is nie 'n aanduiding van 'n volskaalse probleem met jou kaartjies nie. Miskien kan ander dinge soos beter onbaording of dokumentasie sommige van daardie probleme oplos. eers as jy vind dat dit 'n wydverspreide kwessie is wat oplossing nodig het, is die volgende stap om te kategoriseer watter tipe kaartjies jy gewoonlik kry en watter tipe inligting in elkeen vereis word. Die ooglopende kandidate is foute en kenmerke, maar afhangende van die aard van jou maatskappy se besigheid, het jy dalk ander soorte kaartjies wat voortdurend deur jou stelsel vloei en verskillende behoeftes het. Miskien bestuur jou span 'n ETL-pyplyn en jy moet weet watter insette/uitsette op kaartjies wat daarmee verband hou, beïnvloed word. Miskien besit jou span 'n SDK en die kaartjies wat daarmee verband hou moet op 'n spesiale/prioriteit wyse hanteer word en moet insluit watter besigheidsfunksies deur 'n verandering beïnvloed kan word? Ken jou span en hul vereistes sodat jy presies kan bepaal watter tipe sjablone benodig word. Tweedens, sodra jy al hierdie inligting het, plaas dit op skrif iewers gedeel waartoe almal toegang het. Miskien is dit 'n gedeelde dokument, of 'n wiki-bladsy wat die span bestuur en toegang verkry, of dalk kan jy selfs sjablone in Jira self skep, wat mense dwing om dit te gebruik. Maak nie saak wat jou benadering is nie, jy moet inkoop van die span en ontwikkelaars kry, wat beteken dat hulle dit moet kan sien. Dit is een van die belangrikste stappe, want hierdie proses sal nie verder gaan nie, tensy jy 100% inkoop het van enigiemand wat kaartjies gaan skryf. Bied hierdie sjablone aan jou span, versamel terugvoer, verduidelik hoe jy dink hierdie nuwe proses sal jou en jou belanghebbendes raak. Maak seker dat almal in die span gemaklik is met die nuwe proses. Volgende, moet u hierdie veranderinge afdwing. Kaartjies wat sonder genoeg besonderhede aangebied word, moet onmiddellik sonder bespreking teruggegooi word. Dit is belangrik om streng te wees om die sjabloonriglyne te volg, anders sal mense altyd redes vind om dit te omseil. “Hierdie kwessie is te kritiek, ek het nie tyd om dit op te skryf nie” is 'n algemene klagte wat ons sal ontvang. As u egter streng is met die behoefte aan 'n sjabloon en met mense werk wat dit probeer omseil, sal u hulle uiteindelik wen. Laastens By Wayfair het ons groot verbeterings aan ons span se proses sowel as moraal gesien deur die klein veranderinge hierbo aan te bring. Ek hoop dit help jou span ook.
