Projektledning: Funktioner (milstolpar, uppgifter och återkopplingsslingor)

Projektledning är mångfacetterad, och hur vi alla går tillväga för att bryta upp de olika aspekterna av våra projekt beror sannolikt på hur vår arbetsplats gör det, hur kunden vill göra det eller hur vi väljer att göra det själva.

När det gäller det här inlägget, när det kommer till att arbeta specifikt med ett givet projekt, pratar jag specifikt om hur vi tar upp kraven i ett projekt och delar upp dem i mer hanterbara delar och leveranser för de människor som vi arbetar för. Och när jag gör detta tror jag att det är viktigt att de hålls i slingan och kan se framsteg vid rätt kontrollpunkter för att få feedback.

Trots att jag har förändrat olika aspekter av min verksamhet eftersom jag har lärt mig mer om vad som fungerar och vad som inte fungerar, har en sak förblivit konsekvent i hur jag hanterar utvecklingsrelaterade aspekter av funktioner i ett projekt.

Funktioner: Milstolpar, uppgifter och återkopplingsslingor

När vi börjar prata om den här typen av saker är det lätt att glida in i vår branschs jargong. Och även om jag inte nödvändigtvis tycker att det är något överdrivet tekniskt med "milstolpar" och "uppgifter", är en "feedback-loop" något som är lite annorlunda, men jag kommer att täcka det ett ögonblick.

Med tanke på en uppsättning krav, oavsett hur stora, börjar jag omedelbart gå igenom dokumentet – oavsett hur vi tar emot det – och tänka på alla delar som kommer att krävas för att uppnå en viss funktion. Oavsett vilka språk, verktyg, ramverk eller applikationer som du väljer att arbeta med, tror jag att det är här det är viktigt att ha en djup förtrogenhet med det du arbetar med.

Dela in funktioner i milstolpar och milstolpar i uppgifter.

Därifrån kommer jag sedan att ta en given funktion och dela upp den i olika uppgifter, och jag kommer att upprepa det för var och en av funktionerna. Vanligtvis kommer jag att försöka göra varje funktion till en milstolpe, men vissa funktioner är större än andra och måste delas upp i flera delar. För detta ändamål delas ett projekt vanligtvis upp så att:

• En funktion blir en milstolpe (eller milstolpar),
• En milstolpe är en grupp av uppgifter,
• Och en uppgift motsvarar en funktionell enhet (inte nödvändigtvis en funktion i den övergripande kodbasen dock).

Sedan kan du arbeta bakåt från detta för att se hur det motsvarar en release:

• En uppgift motsvarar vanligtvis ett åtagande,
• En uppsättning commits motsvarar en tagg,
• En tagg motsvarar sammanslagning av en funktion,
• En funktion motsvarar en milstolpe.

Vid denna tidpunkt bör en milstolpe vara redo att distribueras till iscensättningsmiljön så att kunden kan utvärdera den mot vad han/hon har i tankarna (och i kraven) för att se till att den uppfylls.

Det är här en feedbackloop kommer in i bilden. Men först definierar jag en återkopplingsslinga helt enkelt som:

En konversation kring en viss funktion som avgör om den är färdig eller kräver mer arbete.

Även om andra går in mycket mer i detalj. Jag avviker dock.

Så i väntan på att kunden ska höra av sig angående den senaste milstolpen, då kommer jag – eller vi – vanligtvis att gå vidare med nästa milstolpe. Det är därför det är viktigt att ha ett konsekvent sätt att arbeta med milstolpar, uppgifter och feedback (tillsammans med grenar i källkontroll och iscensättningsmiljöer).

Börja arbeta på en ny funktion efter att ha bestämt den sista till källkontroll och iscensättning.

Om feedback kommer tillbaka från kunden tar vi vanligtvis feedbacken, bestämmer vad som kan göras, vad som inte kan göras, och sedan batchar vi det till en ny milstolpe. Ibland läggs milstolpen till i slutet; andra gånger läggs det till som nästa prioritetsobjekt. Allt beror på arbetets art, feedbacken och hur den passar in i projektets omfattning.

Mer än funktioner

Generellt sett är detta bara en översikt över hur jag försöker hantera utvecklingsaspekterna av funktioner. Men att titta på milstolpar, uppgifter och återkopplingsslingor är något som är viktigt eftersom när det systemet väl är på plats skapar det ett förutsägbart sätt som du och ett team kan implementera lösningar på.

Dessutom skapar det förutsägbarhet med leveranser och kommunikation med din kund, och detta fungerar särskilt bra med återkommande kunder, eftersom de vet vad de kan förvänta sig.

Som med många av de saker som jag skriver om, försöker jag inte presentera detta som evangelium, men jag tror att det är viktigt att ha ett system på plats. Jag tror aldrig att man ska starta ett projekt om det inte bara är ett personligt sidoprojekt.

Så oavsett vilket tillvägagångssätt du väljer, ha åtminstone ett tillvägagångssätt.