2. Begränsa omfattningen
Ju större projekt desto mer energi krävs för att ändra dess riktning. Ett projekt med mindre omfattning hjälper er prioritera, att möta verkligheten och det ökar er flexibilitet.
- Prioriteringar. Ni beslutar vad som verkligen är viktigt. Vad ska med i första versionen och vad får vänta. Begränsingarna tvingar er att fatta svåra beslut.
- Verklighet. När ni kontrollerar omfattningen har ni större chans att leva upp till förväntningar på ert projekt.
- Flexibilitet. Förändringsförmågan är nyckeln till framgång och små projekt är lättare att ändra på. Varje steg i arbetet ger er erfarenhet och kunskap och ökar er flexibilitet.
Så bestäm vad som är viktigast och gör det, låt annat vänta. Ta bort sånt som inte är helt nödvändigt. Sen kan ni titta på resultatet och bedöma om det räcker. Att lägga till ny funktionalitet senare är mycket lättare när ni har något som fungerar, som ni testat och som ni alla förstår.
Hur prioriterar ni mellan tidsåtgång, kostnad och kvalitet i ditt öppna data- projekt?
Genom att begränsa omfattningen kan ni leverera i tid, till utsatt pris och med hög kvalitet.
"Make each feature work hard to be implemented. You should only consider features if they're willing to stand on the porch for three days waiting to be let in. If a request for a feature keeps coming back, that's when we know it's time to take a deeper look. Then, and only then, do we start considering the feature for real." 1
Att publicera bra mjukvara med färre funktioner är alltid bättre än något stort, fullt med buggar och problem.
3 fördelar med mindre projekt
Ju större objekt desto mer energi krävs för att ändra dess riktning. Ett projekt med mindre omfattning hjälper er prioritera, att möta verkligheten och det ökar er flexibilitet.
Ta bort sånt som försvårar förändring. När ni minskar omfattningen blir det lättare att justera och ändra och då försvinner många hinder som gör ert arbete trögare. Sånt som tidigare tog veckor att genomföra fixar ni nu på ett par timmar.
Minskad omfattning innebär att ni kan testa fler idéer snabbare, upptäcka fler missar och skapa fler framgångsrika idéer.
David Brooks skriver i The Mythical Man Month 2
"Adding manpower to a late software project makes it later." 3
"...how to keep a tangle of features from collapsing under the weight of its own complexity. To a great extent the act of coding is one of organization. Refactoring. Simplifying. Figuring out how to remove extraneous manipulations here and there." 4
"Build products and offer services you can manage. It's easy to make promises. It's much harder to keep them. Make sure whatever it is that you're doing is something you can actually sustain — organizationally, strategically, and financially."
We were more productive: By focussing on delivering small chunks of working product in short time-boxes (typically 1 week development sprints) we always had visible deadlines and a view of actual progress. 6
Referenser
1. Start With No ↩
2. Mythical Man Month ↩
3. Brooks's law ↩
4. Organizational Skills Beat Algorithmic Wizardry ↩
5. Vad betyder egentligen att jobba agilt? ↩
6. What we've learnt about scaling agile ↩