Planview-bloggen

Din väg till smidighet i affärsverksamheten

Hantering av produktutbud

Sätt en spik i den

Publicerad Av Robert L. Read
Sätt en spik i den

Spikes i agila mjukvaruutvecklingsmiljöer används för att undersöka ett koncept och/eller skapa en enkel prototyp. I princip är en spike en snabb (vanligtvis mindre än en sprint) utforskning genom kodning av ett område som utvecklingsteamet saknar förtroende för. Spiken är avslutad när du har lärt dig vad du behövde lära dig. Det kallas så eftersom en spik är "ändlös, men mycket smal", som om man körde en spik genom en stock.

Termen "Spike" introducerades av Kent Beck, förespråkare för Extreme Programming, som ibland konsulterar oss på Planview.

"Skapa spiklösningar för att komma fram till svar på svåra tekniska eller designmässiga problem. En spiklösning är ett mycket enkelt program för att utforska potentiella lösningar. Bygg upp spetsen så att den endast behandlar det problem som ska undersökas och bortser från alla andra frågor. De flesta spikar är inte tillräckligt bra för att behållas, så du får räkna med att slänga dem. Målet är att minska risken för ett tekniskt problem eller att öka tillförlitligheten i en användarberättelses uppskattning."

Mänskligheten uppmärksammar alltid det tunna gränssnittet mellan det triviala och det omöjliga, och det är där spikarna finns. Om utvecklingspersonalen säkert vet hur de ska utföra något, ger processen med att uppskatta och följa utvecklingen mot uppskattningar via hastighet en förutsägbar och upprepningsbar process som begränsar riskerna. Även om det inte är trivialt för de personer som arbetar med det, är arbetet i princip trivialt för en observatör utanför teamet, och därför en snorunge.

Spikes används för att utvidga det triviala genom att etablera strandfästen i det omöjliga. Bygga en hyperkub av en miljon fakta på 12 sekunder? Omöjligt - tills du bevisar att det kan göras med en enkel spik. Som all bra magi är tricket enkelt när man väl ser hur det går till.

Jag kan inte förbättra denna maxim, men kanske kan den berikas med några erfarenheter från verkligheten.

På Planview har vi använt spikar i flera olika syften. Här är tre av dem som sticker ut:

  1. En spike skrevs för att skapa ett Silverlight-grid som kunde stödja 50,000-celler för att testa påståendet att detta var möjligt med god prestanda (det är det). Detta gjordes av en ingenjör på ungefär 5 dagars arbete.
  2. Prestandan hos en anpassad hyperkubedragning testades med hjälp av en spik. Detta tog ungefär 7 dagar av arbete.
  3. Vi testade att inkludera mycket kraftfulla dynamiska grafiska element och ett abstrakt maskineri för användning.

Ingen av dessa var hastighetsgenererande. Alla dessa projekt genomfördes utanför ramen för vår formella agila process som följer framstegen i förhållande till uppskattade insatser, men alla var på sitt eget sätt avgörande för projektets framgång. I enlighet med citatet ovan använder vi spikar för att lära oss något - i allmänhet om en viss metod kommer att fungera, och ofta för att eliminera risken att ett programvaruföretag som vi inte kontrollerar inte håller måttet. I ett välskött utvecklingsarbete vill man naturligtvis göra detta i början av utvecklingscykeln snarare än i mitten eller i slutet, men ibland presenteras ett problem och dess lösningar inte förrän sent i ett projekt.

Om en organisation bryr sig för mycket om snabbhet kan den hamna i en subtil fälla av dysfunktionalitet: man missar stora möjligheter eftersom man inte är villig att investera en liten summa i att bredda området från det triviala till det omöjliga. Det är relativt enkelt att driva ett programvaruprojekt för att göra något som alla är överens om kan göras med tillräcklig ansträngning. Men om det är lätt för dig är det lätt för dina konkurrenter också. För att vara riktigt bra måste en organisation för programvaruutveckling använda sig av spikes på ett disciplinerat sätt för att åstadkomma bästa möjliga totalresultat för en given mängd arbete.

Relaterade inlägg

Skrivet av Robert L. Read

Robert L. Read studerade vid Rice University och University of Texas, där han disputerade i datavetenskap. Rob har varit huvudingenjör på Hire.com och är nu chef för produktutveckling på Planview. Han är uppfinnare av två patent och författare till uppsatsen How to be a Programmer. Han har suttit i styrelsen för Esperanto USA och talar flytande esperanto. Han försöker mycket långsamt bygga en anordning som gör det möjligt för människor att simma i tunnform.