Med jämna mellanrum kommer andra att fråga hur jag lyckas organisera de olika uppgifterna, tillgångarna, resurserna och relaterade saker under ett projekt. För det första har jag bestämt mig för att hålla Pressware liten (och detta är av vissa anledningar), så det låter mig köra det annorlunda än om det naturligtvis vore större.
För det andra använder jag vanligtvis en mycket förminskad version av en kanban-bräda. För dem som inte är bekanta definieras kanban så här:
ett japanskt tillverkningssystem där tillförseln av komponenter regleras genom användning av ett instruktionskort som skickas längs produktionslinjen.
För det ändamålet tänkte jag dela med mig av en kort översikt över hur jag vanligtvis ställer in varje kolumn och varje kort samt de verktyg jag använder för att hantera varje uppgift.
Kanban i WordPress-utveckling
Generellt sett inkluderar varje bräda som jag sätter upp – och jag ska prata om verktygen jag använder för dessa tillfälligt – fyra kolumner som var och en definieras enligt följande:
- ATT GÖRA. Detta är i huvudsak eftersläpningen av uppgifter som måste göras för att slutföra projektet. Det är en lista över alla krav som vanligtvis beskrivs i arbetsrapporten men uppdelade i uppgifter som kan flyttas genom varje kolumn för att se framsteg som görs.
- Göra. När ett kort finns i den här kolumnen betyder det att laget, någon annan eller jag arbetar på det. Ibland kommer ett kort att innehålla flera deluppgifter (som vanligtvis identifieras som kryssrutor), och vi håller dem uppdaterade med uppgiftens status. Jag försöker hålla varje kort relaterat till en commit i källkoden så att om vi måste rulla tillbaka något, då flyttar vi tillbaka ett kort till en kolumn. Alternativt kan vi flytta kortet till nästa kolumn när vi har gjort en ändring.
- Recension / iscensatt. Den här kolumnen betyder att arbetet har utförts och att det är redo att granskas av användaren i iscensättningsmiljön på webbplatsen. Vanligtvis ger jag kunder tillgång till tavlan, så att de kan göra just det. Det vill säga, de kan se när något är klart för granskning, har tillgång till mellanstationsplatsen och kan verifiera att kraven som anges i arbetsbeskrivningen och på kortet är redo att gå.
- Klart. När kunden har verifierat att arbetet som har slutförts är utfört till deras belåtenhet, flyttas kortet till kolumnen klar, koden slås samman med huvudgrenen och sedan upprepas cykeln. Om uppgiften däremot inte är klar, går kortet tillbaka till Doing och flyttas tillbaka genom pipelinen tills det är redo att släppas.
Nu när det gäller att arbeta med projekt finns det en annan aspekt som måste beaktas: Tillgångar.
En enda källa till sanning
Specifikt pratar jag om allt som sträcker sig från:
- typsnitt,
- mönster,
- autentiseringsuppgifter för tredje parts API:er,
- tredjepartsverktyg,
- eller i allmänhet andra tillgångar som kan behövas från projektets början eller från när projektutvecklarna.
Det finns ett par sätt att hantera detta och jag försöker låta tillgångarnas karaktär diktera var jag placerar saker. Till exempel förvaras designtillgångar ofta i en delad Dropbox-mapp eller kanske ett kort, om de är små (men det är de vanligtvis inte). Även då kan jag fortfarande skapa en resurskolumn och listkort med länkar till Dropbox-mappen, till exempel.
Ett mycket enkelt exempel på att använda Trello.
Om det är referenser för ett API kan jag placera det på ett kort under kolumnen Resurser, men om det är något känsligt kan jag använda en privat Droplr-anteckning och sedan länka den från mitt val av projekthanteringsverktyg.
Du förstår dock idén: Tillgångens natur avgör var den lagras, men kanban-kortet refererar alltid till den på något sätt. Detta är vad som hjälper det att förbli en enda källa till sanning för dig och alla inblandade parter.
Och för verktyg?
Jag tror att många av oss älskar att prova på det nya glänsande. För vissa är det nästan en vana:
Släpps ett nytt projektledningsverktyg? Låt oss testa det. För andra, det finns om det finns en beprövad metod som fungerar, varför inte hålla fast vid den?
Oavsett var du faller tror jag att det är viktigt att hitta vad som fungerar bäst för dig och ditt team och sedan använda dem konsekvent och på ett föreskrivande sätt som kan tillämpas över projekt.
För mig brukar jag använda följande verktyg:
- Trello eller GitHub-projekt. Detta beror till stor del på kunden.
- Dropbox för att dela tillgångar.
- Droplr för att säkra referenser.
- Google Docs for Statements of Work och användarvillkor
- Google Dokument för utgiftsrapporter
- Fakturera för fakturor.
- Eversign för eSignaturer på ovanstående dokument.
Jag vet att för några av programvarorna ovan kan vissa vara oroliga över säkerheten, särskilt eftersom den relaterar till finansiell eller säker information.
Foto av John Salvino på Unsplash
Jag tar inte lätt på det här. Tumregeln jag försöker följa är att om det är något jag tycker måste hållas helt säkert, så kommer jag att använda ett lämpligt system för att använda det; Annars, om det är något som jag verkligen inte har något emot om någon skulle komma åt, så är det okej för mig.
Och jag tror att det är ett viktigt övervägande som vi måste göra för att tillhandahålla en tjänst till andra. Faktum är att det förmodligen är innehåll för ett annat inlägg om inte en hel annan blogg. Men det är inte det här inlägget, inte heller den här bloggen – åtminstone inte just nu.
Min poäng?
I slutändan, se till att du har följande:
- ett sätt för dig och din kund att spåra ett projekts framsteg genom utvecklingens livscykel,
- ett sätt för dem att se hur saker går som inte är öppet tekniska som källkontroll,
- ett sätt att dela och komma åt efter behov,
- förmågan att kommunicera och ställa frågor efter behov.
Jag är säker på att det finns andra saker som är värda att notera men dessa är nyckeln till innehållet i detta inlägg. Så att använda kanban i WordPress-utveckling är inte svårt, men det är också underbyggt av några ytterligare saker som kan göra processen enklare.
Behåll en enda sanningskälla som stöds av tredjepartstjänster som gör det enkelt att samarbeta.