Djupstudie Collective Documentation Ownerhip - Wiki Jakob Nilsson-Ehle (d02jn@efd.lth.se) 1
1 Innehåll 1 Inledning............................... 3 1.1 Vad är en wiki?............................ 3 1.1.1 Målet med studien...................... 3 1.2 Studien................................ 3 1.3 Grundläggande krav......................... 4 1.3.1 Vad krävs av en wiki?.................... 4 1.3.2 Vad kräver en wiki av systemet?.............. 5 1.3.3 Vad kräver en wiki av användaren?............. 5 2 Wikins inverkan på projektet.................... 6 2.1 Mina mål med wikin......................... 6 2.2 Hur wikin användes i verkligheten................. 6 2.2.1 Vad wikin förenklade..................... 7 2.2.2 Utvecklarnas förhållande till wikin............. 7 2.3 Vad mer kan man göra?....................... 7 3 Reflektioner.............................. 8 4 Tack till................................ 9 5 Källreferenser............................. 9
2 Sammanfattning Inom XP är en av hörnstenarna Collectiv Code Ownership - alla äger koden, alla ändrar i koden. Men det nämns sällan något om hur dokumentationen skall hanteras. Det finns verktyg att generera dokumentation direkt från koden, till exempel Javadoc och Doxygen, men de har två stora nackdelar. För det första är de ytterst tekniska, och den dokumentationen som bildas där blir enbart för de som är direkt intresserade av hur koden fungerar. För det andra är det rent tidsmässigt väldigt dyrt att generera dokumentationen, flera minuter kan det ta att skapa de sidor som krävs. Det måste helt enkelt finnas ett bättre alternativ för den dokumentation som kräver snabb uppdatering och inte fullt så tekniska detaljer, men som ändå kräver att alla kan ändra i den och uppdatera den hur de vill. Naturligtvis finns det. Fenomenet 1 Wiki löser alla ovanstående problem, och sparar även en logg av alla ändringar, så att man lätt kan ändra tillbaka allting till en tidigare version. 1 Jag kallar det fenomen, då det inte är begränsat till ett företag, en person eller ens en mjukvara
1 Inledning 3 1 Inledning 1.1 Vad är en wiki? Grundtanken med en wiki är att det skall vara en webbplats där alla kan ändra materialet direkt, och direkt se skillnaden. Oftast är det implementerat mot en webbserver kopplad mot en databas som uppdateras i realtid när någon ändrar en text. En wiki har oftast ett eget markup-språk för att formatera de sidor som skrivs. Dessutom är det standard att wikin kommer med versionskontroll för att enkelt kunna ändra tillbaka eventuella felaktigheter i sidorna. Wiki (wi ki) kommer från Hawaiianskans Wiki wiki vilket betyder snabb, något som refererar till att det går snabbt att ändra en sida, i kontrast mot de statiska HTML 2 -sidor som kräver att den som vill ändra en sida måste ladda ner den, göra sina ändringar, och sedan ladda upp sidan på servern igen. Något som ofta kräver, förutom kunskaper inom HTML, någon form av login och lösenord till servern. Wiki-konceptet uppfanns av Ward Cunningham som tillsammans med Kent Beck och Ron Jeffries är en av grundarna av Extreme Programming. Den första Wikin någonsin - the Portland Pattern Repository - skapades av Ward som ett sätt att skriva och definiera design patterns. Idag har wikin börjat växa sig allt större, och den kanske nu mest kända är Wikipedia, ett gratis uppslagsverk som drivs av den ideella organisationen Wiki- Media Foundation. I Sverige är (förutom svenska Wikipedia) den populäraste susning.nu, som tyvärr ganska nyligen tog bort ändringspriviligiet från de flesta av sina användare. Detta på grund av missbruk av systemet, vilket är en risk man måste ta hänsyn till. 1.1.1 Målet med studien De frågor jag har tänkt besvara med den här studien är: Hur väl förhåller sig Wiki till XPs filosofi? Vilka krav måste mötas för att wikin skall göra någon nytta? Hur väl passar en wiki i ett mindre utvecklingsprojekt? Krävs det någon som korrekturläser den? Finns det andra tillämpningar för Wiki inom XP förutom rent dokumentationstekniskt? För att lösa detta tänkte jag helt enkelt ta hjälp av webapplicationen pmwiki (http://www.pmwiki.org/) för att sedan låta medlemmarna i teamet utnyttja den. 1.2 Studien Våren 2005 var jag coach för Team 08, 7 personer som slumpmässigt sammanfogats för att utveckla ett program enligt metodiken Extreme Programming. Mitt mål var att granska hur en wiki kunde underlätta dokumentationsarbete för utvecklarna genom att ge alla direkt access till en databas där de både kunde 2 Hyper Text Markup Language, standardspråket för webbsidor
1 Inledning 4 Fig. 1: Vem som helst kan ändra vilken sida som helst läsa, skriva och ändra informationen som det passade, med förhoppningen om att det skulle vara en värdefull hjälp för teamet. Det den här rapporten fokuserar på är först hur själva wikisystemet fungerar, vilka krav man måste ställa på wikin, på systemet wikin kör på och på användarna som skall nyttja wikin, och där samtidigt en koppling till vilka practices inom XP man kan koppla till wiki-konceptet. Efter det tänkte jag gå in på hur wikin fungerade i praktiken, varför det gick som det gick och vad man hade kunnat göra annorlunda. 1.3 Grundläggande krav I den här delen tänkte jag ta upp vad som krävs av och för wikin för att man skall finna det lönsamt - överhuvudtaget möjligt - att unyttja en wiki i sitt projekt. 1.3.1 Vad krävs av en wiki? För att man skall kunna använda en wiki måste man ställa några grundläggande krav på applikationen. Naturligtvis skiljer de sig ofta från fall till fall, men vissa kärnfunktioner måste ändå vara närvarande för att nyttjandet av wikin skall flyta utan större problem. Till att börja med så måste wikin implementera någon form av markupspråk, som är simplare än HTML, men ändå kraftfullt nog för att kunna presentera data på det sättet man vill. Tyvärr finns det ingen standard för hur markup i en wiki skall se ut, utan de flesta applikationer skriver sin egna markup, som dock liknar varandra.
1 Inledning 5 För det andra krävs det en versionshistorik för alla sidor på wikin (Se figur 2). Vem som helst med behörighet skall närsomhelst kunna återställa sidan till en tidigare version. Fig. 2: Versionshantering är viktigt för att wikin skall fungera Till detta kan man lägga en mängd övriga krav som kanske inte är livsviktiga för att kunna köra wikin, men ändock viktiga för att det skall bli en smidig process. Till exempel borde wikin kunna låsa sidor så att två personer inte kan ändra den samtidigt. Även skulle man kunna kräva ett användarbaserat system med privilegier och administrationsrättighter. 1.3.2 Vad kräver en wiki av systemet? I sin allra enklaste form tycker man inte att en wiki borde kräva särskilt mycket - en databas och en applikation som kan skriva och läsa databasen. Om man även tar hänsyn till kraven ställda i sektion 1.3.1 får man även utöka kraven på systemet. Absolut grundläggande för att skapa webbinterfacet är en webbserver. Vissa wikis, såsom project forum, kommer med en egen server, andra kräver att man redan har en webbserver installerad. Till webbservern (om nu wikin kräver det) måste man också ha ett script/programmeringsspråk kopplat. PHP 3 är vanligast av de jag har sett, men det finns för nästan alla språk, inklusive CGI/Perl 4, JSP 5 och ASP 6. Till sist krävs även en eller flera databaser. I sin allra enklaste form är de en mängd textfiler sparade lokalt på datorn, men det kan sträcka sig till stora databaskluster. 1.3.3 Vad kräver en wiki av användaren? För att hålla sin wiki i god form krävs inte bara rent tekniska krav på systemet - systemet ställer även krav på dess användare. I andra fall kan de förfalla 3 PHP Hypertext Preprocessor. Se www.php.net 4 Common Gateway Interface är ett interface för att koppla scriptspråk till en webbserver. Perl är ett scriptspråk i första hand för *NIX-system 5 Java Server Pages, webbapplikationer skrives i Java. JSP kompileras till skillnad från Perl och PHP som tolkas direkt 6 Active Server Pages, microsofts svar på JSP, kan bindas till flers av microsofts programmeringsspråk
2 Wikins inverkan på projektet 6 med obegriplig struktur, bortglömda sidor och oförståeliga versionsloggar. Den som är van vid XP borde dock inte har några problem att anpassa sig. Några krav på användaren kan man nämligen låna därifrån med mindre eller inga modifikationer. Continuos Integration Uppdatera ofta - inte bara wikin utan sin egen vy av den också -. Så fort man har något nytt att skriva så skall man skriva in det, hittar man något utdaterat så tar man bort det. Refactor Hittar man något som är dåligt formulerat eller tvetydigt skriver man om det. Hittar man ett stycke som är alldeles för långt kan man bryta ut det till en egen sida. Collective Code Ownership är en practice som summerar upp hela poängen med wikin. Allt ditt är mitt, allt mitt är ditt. Man skall inte vara rädd för att ändra vad någon annan har skrivit, är man tveksam kan man ta upp vad man tänker ändra med den som skrev originaltexten, men generellt är principen att så fort man skickar in någonting till en wiki har man gett alla andra rätten att ändra det. Summa sumarum handlar det om att uppdatera allt det som behöver uppdatera och så fort det behöver uppdateras. 2 Wikins inverkan på projektet 2.1 Mina mål med wikin När projektet inleddes var mina förhoppningar att projektets wiki i så stor mån som möjligt skulle ersätta de dokumentationsuppgifter som kommer med ett XP-projekt, såsom tracking, spikes, stories, planning, manual, med mera. Dock ej teknisk dokumentation då det är något som enklast autogenereras från källkod. En wiki har kapacitet att i princip spara vilken skriven information som helst, och med hjälp av dess markup-språk kan den dessutom utformas väldigt effektivt. Även bilder, jar 7 -filer, ljud och en viss grupp fördefinierade binära filer går också att spara. 2.2 Hur wikin användes i verkligheten Upp till och med iteration fyra användes wikin ganska snålt. De flesta utvecklare lade helt enkelt upp information på CVS:en istället och lämnade bara ett meddelande på wikin att den fanns på CVS:en. Under planeringsmöte fem bestämde jag mig för att konfrontera utvecklarna angående detta. Vi kom då tillsammans fram till vad wikin var bra och mindre bra för. De flesta höll med om att den var ett nyttigt verktyg som utnyttjades för sällan. Varför det var så var de inte säkra på, men jag har ett par teorier. Teamet gavs tvetydig information då det både fanns en katalog för spikes i CVS:en och en sida för Spikes på wikin. Då spikeskatalogen fanns i samma fönster som programmeringsuppgifterna var detta det givna valet att skriva allt som man kom fram till under spikandet i. 7 Java archive. Direkt körbara kompilerade filer som har paketerat ihop alla externa klasser som behövs för den givna applikationen
2 Wikins inverkan på projektet 7 Utvecklare som var mitt uppe i en programmeringsuppgift fann det störande att behöva växla mellan för många fönster. Man vill gärna ha all information i det fönstret man jobbar i, annars uppstår hack i utvecklandet. Teamet gavs inte tillräcklig information om wikins potential och användningsområden. Få personer inom teamet visste i förhand vad en wiki var, och hur den skulle utnyttjas, något som jag tyvärr tog för givet. Efter den diskussionen gjordes ett par ändringar för att förenkla wikin. Informationen på sidan refaktoriserades för att blir mer övergriplig, och en sida med meddelanden lades till. Resultatet blev att wikin användes bättre och oftare. Mer vetting information hamnade där, och folk vågade även ändra andras text. Även under långlabben användes wikin för att uppdatera trackern. 2.2.1 Vad wikin förenklade Det finns delar av utvecklingsprocessen som jag är relativt säker har förenklats av wikin. Den första är trackern, där vi har kunnat uppdatera i wikin vem som jobbar med vad, vad som är prioriterat hur, hur det är estimerat och vad dess totala kostnad blev. Naturligtvis kan det göras på papper också, men wikin gjorde det på ett renare och bekvämare sätt. Jag tror delvis att framgången berodde på att vårt team under nästan hela utvecklingstiden saknade en whiteboard att göra anteckningar på, men också för att det var något jag som coach försökte lobba för från början. Eftersom de senaste stories efter varje planeringsmöte låg uppe på wikin var det en smal sak att uppdatera dem under utvecklandets gång. Den andra är manualen som skrevs helt online på wikin, av flera anledningar. För det första skrevs den en bit in i projektet då folk mer hade vant sig vid wikin. För det andra var manualen en separat story, som inte krävde att man delade sin uppmärksamhet med ett annat fönster. För det tredje är det naturligt att manualen inte är statisk, utan uppdateras parallellt med programmet. Slutligen underlättade wikins uppladdningsfunktion och förenklade markup-språk avsevärt möjligheten att skapa en bra layout. 2.2.2 Utvecklarnas förhållande till wikin Inom teamet fanns det generellt två olika typer av förhållningssätt till wikin, vilka direkt i individens grundkunskapen. De som kände till vad en wiki var, var även de som var mest intresserade av att utnyttja den och kom med flest förslag. De som inte kände till det innan hade ett ganska ointresserat förhållningssätt. 2.3 Vad mer kan man göra? Det som gjordes under iteration fem skulle naturligtvis gjorts mycket tidigare. En kontinuerlig refaktorisering av wikin hade behövts av coacherna iallafall under den första tiden, efter vilket det förhoppningsvis hade kunnat övergå mer och mer som teamets uppgift. Det hade nog också varit på sin plats att förbereda wikin aningen mer än vad jag hade gjort - den zero feature release jag hade gett dem var i det fallet fullt av frågetecken; hur skulle spikesen rapporteras? vad skulle står under huvudsidan? och så vidare.
3 Reflektioner 8 Man hade även kunnat dela ut en lathund till wikin där den grundläggande informationen fanns - hur man editerar en sida, hur man signerar en ändring, vad skillnaden på en minor och major edit är, hur man skapar en egen sida med mera. Slutligen handlar det om motivation. Det gäller att kunna motivera sitt team att utnyttja de verktyg de har. Genom att ge känslan av att folk bidrar till något - och ge mycket feedback när de gör det - ökar man inte bara motivationen utan även teamkänslan. 3 Reflektioner Rent teoretiskt är en wiki ett bra verktyg som borde falla väl i linje med Extreme Programmings idéer, och det är ett synnerligan lyckat koncept, om man tittar på de succéfyllda sidorna som använder sig, eller bara består, av en wiki. Den wikin som vårt projekt använde sig av var till en början misslyckad, men har efter diskussioner och reflektioner någorlunda väl integrerats i utvecklingsprocessen. Det är dock mycket kvar att göra för att den skall bli en naturligt verktyg för utvecklarna. En liknande djupstudie utfördes förra året av Tomas Raneland och Linus Walleij. Enligt deras rapport fungerade wikin snarare som en anslagstavla och diskussionsbräda än ett utvecklingsverktyg. Liknande är det med den här wikin. Innan refektoriseringen var i princip dess enda uppgift att meddela folk när och hur en spike hade gjorts. I nuläget är den fortfarande än anlagstavla, men med den skillnaden att den inte hänvisar till information på någon annan plats (till exempel teamets lokala CVS) utan faktiskt innehåller den informationen den annonserar. Jag anser att wikin är berättigad att betraktas som ett möjligt utvecklingsverktyg, när man väl har gett den den tiden som krävs för att integreras i utvecklingsprojektet.
4 Tack till 9 4 Tack till Tomas Raneland och Linus Walleij för en bra idé och djupstudie att jämföra med Team 08 och Jenny Nilsson för att ni ville använda wikin Gustav Olsson, Mikael Jarheden, Anders Hellström och Görel Hedin för granskningen av utkastet Anna Nilsson-Ehle för korrekturläsningen Patrick Michaud, som skapade PMWiki Ward Cunningham, som grundade wiki-konceptet 5 Källreferenser http://www.pmwiki.org http://en.wikipedia.org/wiki/wiki http://en.wikipedia.org/wiki/ward Cunningham http://en.wikipedia.org/wiki/extreme Programming