Agil utvecklingsmetodik för
Bygga Rails-app
Vi skriver ner en lista med mål, roller och funktioner
- Mål - vilka är målen för hela projektet - affärsmässiga och andra. Detta kommer att hjälpa dig att bestämma vilka funktioner som är viktiga
- Roller - vem ska använda webbplatsen - besökare, inloggade medlemmar, administratörer? Har olika personer olika uppfattningar om samma information på webbplatsen?
- Funktioner - vilka är de grundläggande kategorierna av interaktion på webbplatsen? Till exempel: Användare: registrering, användning av forum och bloggning; Administratörer: moderering av användarinnehåll
Vi skriver en lista med berättelser
- En story skiljer sig från en feature eftersom den representerar en enda interaktionstråd ur en viss användares perspektiv.
- Det är vanligt att uttrycka berättelser i form av "Som ____ vill jag ____ så att jag kan _____." Detta tvingar dig att besvara tre viktiga frågor - Vem är detta till för? Vad vill de göra? Varför vill de göra det?
- Om du inte kan slutföra en berättelse i den här formen är det troligt att du inte har svar på någon av dessa tre frågor ännu, så du måste tänka lite för att få svaren innan berättelsen är handlingsbar.
- Ex: "Som administratör vill jag förbjuda användare från forumet, så att jag kan förbättra kvaliteten på det innehåll som användare skickar in på webbplatsen.
- Skriv ner dessa berättelser på anteckningskort. Detta kommer att hjälpa dig med uppskattning och prioritering.
Vi uppskattar berättelserna
- Uppskattning är ett stort ämne i sig, men grundidén är att associera en viss nivå av ansträngning med varje berättelse.
- De vanligaste skalorna är 0/1/2/3/4, 0/1/2/4/8. Jag tycker inte att detta är otroligt viktigt, men välj något och håll dig till det.
- Häng inte upp dig för mycket på exaktheten i uppskattningarna. Det är många saker som påverkar hur lång tid det tar att skriva klart en berättelse, så små skillnader i berättelsens komplexitet tenderar att försvinna i bruset.
- Ditt mål här är att skilja på saker som kräver lite ansträngning, som berättelser som resulterar i att du skapar en enkel modell med en REST-kontroller, från berättelser som kräver mycket ansträngning, som att gränssnittet mellan din applikation och ett utmanande API från tredje part, eller en berättelse som kräver att du använder en teknik som du inte är så bekant med.
- Skriv uppskattningen på varje kort.
Vi prioriterar berättelserna
- Ordna om korten i den ordning som du vill ta dig an berättelserna.
- Det är egentligen bara produktägaren som kan fatta det här beslutet. Det finns många saker som spelar in i prioriteringen - deadlines, användartester, affärsvärde osv. Uppskattning kan ha mycket att göra med prioritering, eftersom det belyser alternativkostnaden. Produktägaren kanske verkligen vill ha den där detaljerade Admin Dashboard, men om alla stories för att få det att fungera totalt uppgår till 40 poäng, är det då värt att lägga en månad på just den här funktionen? Kanske vill produktägaren fortfarande ha berättelsen
- Finns det några berättelser som inte passar in i den allra minsta livskraftiga produkten för lansering? Om så är fallet bör du flytta ner dem. Försök att färdigställa en fungerande app så snabbt som möjligt så att du kan presentera den för användarna.
- Vid det här laget flyttar jag vanligtvis mina kort till Pivotal Tracker, men jag känner många människor som föredrar penna och papper.
Vi testkör den första berättelsen till slutförande
- Börja med Cucumber Skriv en Cucumber-funktion som täcker användarens interaktion med webbplatsen från början till slut. Definiera de odefinierade stegen när du kommer till dem, och när du träffar ditt första misslyckande vet du att det finns ett beteende som du önskar att din app inte har (Detta kommer att hända mycket snabbt i början, eftersom din tomma app inte har mycket beteende).
- Om jag har Javascript-interaktioner som är en viktig del av användarinteraktionen, försöker jag låta Cucumber testa dessa med @javascript-taggen.
- Fortsätt till Rspec Skriv testet för det beteende du önskar att du hade.
- Skriv din kod Skriv koden som gör att specifikationen godkänns. Detta kommer att ta dig genom hela din applikation från routing till UI, till modeller, till databasschemat, till styrenheten. Du kommer att ta itu med dessa kodstycken i den ordning som dina tester leder dig till.
- Upprepa tills gurkan passerar och du är klar med berättelsen.
- Nu är det en bra tid att fixa CSS-stylingen förutsatt att du har gjort designen. Om jag arbetar ensam eller utan en designer, gillar jag att försöka wireframe användargränssnittet antingen på papper eller i något som Balsamiq Mockups innan jag ens börjar koda berättelsen.
Vi accepterar berättelsen
- Är berättelsen acceptabel? Gör den som du ville att den skulle göra? Om inte, måste du gå tillbaka och få det att fungera som det var tänkt. Att skriva gurktester i förväg hjälper till att förhindra att detta händer.
- Klarar du alla dina tester? Du har väl inte förstört bygget? Om så är fallet måste du fixa det du förstörde.
- Om du arbetar ensam kan det vara bra att låta någon annan göra acceptansen åt dig, eftersom det kan vara svårt att se sitt eget arbete med objektiva ögon.
Vi upprepar tills vi är klara
Det är så här jag gör saker. Det är inte på något sätt det enda sättet att göra saker på, men det är ett mycket vanligt sätt att göra saker på i Rails. Jag tror att det finns en bra debatt att föra kring värdet av agil uppskattning, eller av särskilda tekniker som Cucumber vs. Steak eller RSpec vs Test::Unit, men de flesta Rails-utvecklare kommer att hålla med om att det rätta arbetsflödet är att:
1) Identifiera en enskild berättelse
2) Skriva tester för det
3) Slutför det.
Swedish 
English 
Japanese 
German 
French 
Spanish 
Italian