WikiWiki och XP i små projekt

Transkript

1 WikiWiki och XP i små projekt Thomas Raneland, d00tr@efd.lth.se Linus Walleij B.S.Sc., d00lw@efd.lth.se 15 maj 2003 Sammanfattning I denna djupstudie analyseras användandet av så kalla WikiWiki-teknik i ett projekt som drivits enligt projektmetodiken extreme Programming. Såväl sociala, organisatoriska som tekniska aspekter berörs. Slutsatsen är att WikiWiki-tekniken är mycket lämpad för projekt av denna typ, och att programvaran som använts är enkel att installera och modifiera för lokala behov. Innehåll 1 Introduktion 2 2 Vad är WikiWiki? 2 3 Projektet och utvecklingsprocessen 2 4 Så användes WikiWiki-tekniken i projektet 3 5 Roller inom gruppen 5 6 Programvaran Installation och driftsättning Behörighetssystem Traditionell dokumentationsprocess visavi Wiki 8 8 Tänkbara utökningar i programvaran 9 9 Slutsatser 9 10 Tack till Referenser 10 1

2 1 Introduktion Det är känt att interna webbplatser delvis löser problemet med dynamisk dokumentation och kommunikation inom en projektgrupp. I projekt som använder extremprogrammering som utvecklingsprocess är kommunikation extra viktig. Vi har studerat hur WikiWiki-teknik fungerar i ett litet utvecklingsprojekt. Vår förhoppning var att programmerarna skulle kännas sig mer engagerade och delaktiga i projektet, genom att få ett lika stort ansvar för webbplatsen. 2 Vad är WikiWiki? WikiWiki (själva ordet är Hawaïanska och betyder snabb ) är en teknik för att tillhandahålla webbplatser där användarna själv kan lägga till nya, och redigera samtliga webbsidor. Tekniken utvecklades först av Ward Cunningham 1997 för webbplatsen Portland Pattern Repository. 1 Sajten var ämnad att samla designmönster som användarna själva upptäckt. Därför behövde redigering kunna utföras enkelt av alla med tillgång till sajten. Genom länkar på varje webbsida kan användaren lägga till egen text. Ofta finns även en diskussionssida kopplad till varje webbsida. Där kan metadiskussioner kring webbsidan hållas, till exempel rörande faktakvalitet, innehållets struktur, om sidan skall brytas ned i undersidor osv. Till skillnad från den statiska webbsidans WYSIWYG What You See Is What You Get, ger Wikisidor en helt annorlunda användarupplevelse av WYSIWYME What You See Is What You May Edit man erfar en känsla av att webbsajten erkänner sina egna brister och accepterar att bli rättad och förbättrad. Det står varje användare fritt att lägga till nya webbsidor. Således kan sidoämnen lätt ges egna sidor, vilket gör att webbplatsens struktur utvecklas. Därmed kan en WikiWiki-sajt hållas välstrukturerad trots att sajten har ett stort antal medförfattare. För varje artikel (uppslagsord) sparas de senaste versionerna så att man kan jämföra den nuvarande artikeln med en tidigare version, och om det behövs återgå till en tidigare version, se figur 1. Wikipedia 2 är den största sajten med Wiki-teknik och omsätter i dagsläget tals artiklar. Historiskt har Wiki-sajterna utvecklats ur s.k. Blog -program, d.v.s. webbloggar eller nätsamhällen communities som har ett naturligt inslag av informationsutbyte. Varianter på konceptet förekommer också exempelvis i manualen för skriptspråket PHP, där läsarna kan annotera, dvs kommentera alla sidor på ungefär samma vis som rättningar är införda i marginalen på flera av Universitetsbibliotekets referensböcker. På så vis kan man hävda att fenomenet egentligen har flera hundra år på nacken. Jämförelser med encyklopedisternas verk sammanställning och koncentration av mänsklighetens samlade kunskap kan också göras. 3 3 Projektet och utvecklingsprocessen Det projekt vi studerat och medverkat i fick uppdraget att utveckla ett program för tidtagning i endurotävlingar. I projektet fanns två coacher (författarna) och tio programmerare. Utvecklingsprocessen som användes var extremprogrammering (XP), en lättviktsprocess (engelska: agile process) där tyngdpunkten ligger på förändring, kommunikation och delat ansvar Se 4 Se Jeffries, Anderson & Hendrickson

3 Figur 1: Versioner av en och samma webbsida i vårt projekt. Rollerna i ett XP-projekt skiljer sig något från rollerna i traditionella utvecklingsprojekt. Coachens ansvar är att underlätta arbetet för programmerarna, samt att kontrollera att XP så kallade practices (arbetssätt) används. Programmerarens uppgift är att formge, testa och implementera programmet enligt kundens krav. Kraven formuleras som uppdrag, s.k. userstories. Varje uppdrag beskriver ett nytt sätt att använda programmet och därmed vilken ny funktionalitet som behövs. Kunden och coacherna hade tidigare praktisk och teoretisk erfarenhet av XP. Programmerarna hade endast teoretisk erfarenhet av processen (inklusive några kortare laborationer med specifika XP-metodologier). Projektets omfattning begränsades av tiden; sex långlabbar à åtta timmar, där varje laboration föregicks av ett två timmar långt planeringsmöte. Därtill fick varje programmerare fyra timmars hemarbete mellan mötet och laborationen. Denna tid användes huvudsakligen till förberedelser inför laboration, så att arbetet kunde genomföras effektivare. Under långlabbarna fanns minst en av coacherna ständigt närvarande. Kunden, som enligt XP bör finnas till hands hela tiden, befann sig i samma byggnad och besökte arbetet cirka två gånger per laboration. Vid detta tillfälle fick coacher och programmerare möjlighet att ställa frågor, reda ut missförstånd, och testa användargränssnittet på kunden. 4 Så användes WikiWiki-tekniken i projektet För att underlätta den skrivna kommunikationen, och för att även dela ansvaret mellan gruppmedlemmarna sattes en intern WikiWiki-sajt upp. Grundstommen till denna skapades av coacherna före första planeringsmötet. Därefter stod det var och en fritt att lägga upp information, ändra i befintlig text och strukturera om sajten på bästa sätt. 3

4 Figur 2: Projektets Wikisajt, huvudsida. Det går att konstatera tre olika användningsområden för webbplatsen: För det första fungerade sajten som projektgruppens interna anslagstavla. Nuvarande och kommande arbetsuppgifter, presentation av gruppmedlemmarna och teknisk information om produkten lades upp. För det andra användes sajten ibland som ett diskussionsforum. Tillfällig information, såsom Internetadresser och skalkommandon, är lättare att kommunicera skriftligt än muntligt. Delvis tog sajten över e-postens uppgift. Mellan långlabbarna lades information upp som inte behövde läsas omedelbart, t.ex. upplysningar om vilka hemuppgifter som delats ut eller hur man kan öka kvaliteten på koden. För det tredje fanns möjlighet att använda sajten för kommunikation med kunden. Nya releaser, dokumentation och support kunde läggas upp. Kunden kunde ställa frågor om produkten på dessa sidor och få svar från någon i gruppen. På så sätt slipper man utse en särskild gruppmedlem för kundkontakt. Denna tredje användning har i skrivande stund inte utnyttjats, men å andra sidan är projektet inte slutfört än, och det är coachernas avsikt att denna möjlighet ska tas tillvara. 5 Roller inom gruppen På samma sätt som rollerna i utvecklingsarbetet är annorlunda i ett XP-projekt, kommer rollerna för en WikiWiki-sajt att skilja sig från de traditionella. På klassiska webbsajter har få tillgång till tekniken som krävs för att modifiera en webbsida. Speciella verktyg (FrontPage, Screem, DreamWeaver) och speciella rutiner (FTP, WebDAV, Frontpage Server Extensions) 4

5 med login krävs för att kunna editera. Sidorna får karaktären av ett typografiskt arbete och få lägger ner tid på att ändra, lägga till eller radera. WikiWiki-sajter ger alla samma möjlighet att editera i samma ögonblick som ett fel upptäcks, utan att det vanliga rutinen (ett fel upptäcks, felet rapporteras, webbeditor avsätter tid, felet ändras) behövs. I stället klickar användaren på en länk på den sida där felet upptäckts, ändrar källtexten (skriven i ett eget format som dock stöder HTML i viss grad) och sparar. Således avvecklas rollen som webbeditor och den webbansvarige får rollen som korrekturläsare, organisatör och övervakare av sajten. I vårt fall blev det naturligt så att coacherna tog ett delat huvudansvar för sajten, men vi anser att det uppdraget lika gärna kunde delats ut till en eller två av programmerarna, som ett slags expertroll. Till rollen kan också höra att uppmana projektmedlemmar att lägga upp ny information eller att radera eller uppdatera gammal information vid ändringar. Det normala i ett XP-projekt är att minimera mängden dokumentation och i stället förlita sig till muntlig kommunikation. En stor webbplats kan tyckas motverka denna princip. Vår erfarenhet är att sajten till största delen innehåller material eller länkar till material som publicerats av tredje part, och inte blir föråldrad under projektets gång. Den enda större tekniska information som fanns om vår egen produkt var automatgenerad dokumentation 5 om de klasser ingick i programmet. Denna uppdaterades ofta för att inte vilseleda. 6 Programvaran För att driva Wikisidan behövde vi hitta en lämplig programvara. Det första vi undersökte var UseModWiki. Detta program är en modul till Webbservern Apache, som kör en helt och hållet filsystemsbaserad revisionshantering. Denna visade sig dock bara stödja en viss typ av uppmärkning av länkar mellan uppslagsord, nämligen såkallad CamelScript, vilket innebär att ord skrivs ihop så att SakerSomÄrLänkarTillAndraUppslagsord skrivs samman på detta vis. I engelskan är detta naturligt eftersom det används i en hel del varumärken och liknande, och kan eventuellt tolkas som en rörelse mot att skriva samman ord på det vis som är naturligt i svenska språket. Emellertid blir detta sammanskrivande onaturligt i svenskan eftersom vi redan av hävd skriver samman ord, och att skriva ett ord som schlagerfestivalarrangör som SchlagerFestivalArrangör ger ett stolpigt och onaturligt språkflöde som påminner om särskrivning. Därför var vi tvungna att finna en programvara med stöd för ett naturligt svenskt ordflöde. De stora svenska Wikisajterna av encyklopedisk karaktär: Susning.nu och svenska Wikipedia, har ett sådant system, och valet föll på svenska Wikipedias webbscript skrivet i skriptspråket PHP. 6 Dessa hade båda stöd för ordlänkar i form av [[dubbla hakparenteser]] vilket fungerar bra med svenska uppslagsfraser där man vill kunna använda mellanslag och små bokstäver i uppslagsord. 6.1 Installation och driftsättning Wikipedias PHP-skript finns tillgängligt under licensen GNU GPL 7 och eftersom detta ständigt utvecklas fick koden checkas ut från projektets CVS-repository. 8 En svensk översättning hade då nyligen tillkommit, och vi slapp på det viset att själva översätta texten i programmet till svenska. 5 Verktyget JavaDoc användes, 6 PHP använder nedåt naturligtvis webbservergränssnittet CGI, Common Gateway Interface, en de factostandard från NCSA, se 7 GNU General Public License, se 8 programvaran återfinns på 5

6 Figur 3: Skiss av webbsystemet där Wikin driftsattes. För att kunna använda programmet krävs tre saker: En dator med webbserver med stöd för skriptspråket PHP i en eller annan form. En databasmotor (DBMS) av typen MySQL och möjlighet att skapa databaser på denna. Tillgång till en skrivbar filarea på denna server, om man önskar stöd för att ladda upp bilder och liknande. Eftersom institutionen för datavetenskap hade begränsad möjlighet att stödja och administrera en sådan miljö valde vi att istället driftsätta Wikin hos Datorföreningen vid Lunds Universitet och Lunds Tekniska Högskola. Här fick vi tillgång till en webbserver i form av en Sun 450 med 4 processorer och stort arbetsminne, webbservern Apache samt databassystemet MySQL och en filarea. Bara databasskapandet krävde administrativa behörigheter på maskinen, själva programvaran och filarean kunde placeras i ett vanligt användarkonto på maskinen. På MySQL-sidan skapades ett konto med namnet cs0310 och en tom databas med samma namn. Till användarkontot knöts ett visst lösenord. Databasen måste sedan initialiseras med vissa fördefinierade tabeller och därtill hörande nycklar och index, vilket automatiserats av Wikipedia i form av ett SQL-skript. 9 Efter att detta skript körts och PHP-filerna placerats i en egen katalog var Wikisajten klar att användas. Ett schema över uppställningen visas i figur Behörighetssystem Vissa experiment företogs för att testa om ett behörighetssystem kunde användas för att begränsa tillgången till Wikisajten från hela världen. Det visade sig möjligt att sätta upp en lokal begränsning för den katalog där PHP-filerna låg med htpasswd, en behörighetslösning av samma typ som Unix password-system. På detta vis kunde man, om man så önskade, 9 För en introduktion till relationsdatabaser se Ullman-Widom, A First Course in Database Systems. 6

7 kopiera användarnas namn och lösenord från skolans Unixsystem och använda dessa för inloggning i Wikin. Det var också möjligt att kryptera denna förbindelse med SSL. Att använda personlig inloggning medför även andra fördelar: i den befintliga programvaran kan man sätta sig som övervakare på en viss artikel, och få en lista över senaste ändringar i de artiklar där man antecknat sig som övervakare. På så vis kan man lätt bevaka sitt eget intresseområde. Man kan även tänka sig att utöka denna funktionalitet med möjligheten att få e-post om ändringar i samma ögonblick som de sker. Vi valde emellertid att inte aktivera någon sådan säkerhetslösning: det bedömdes inte som sannolikt att någon utomstående skulle ha intresse av att sabotera vår Wiki, och ur spionagesynpunkt var vårt projekt inte heller särskilt intressant. Adressen till Wikin var heller inte allmänt känd, och även om detta inte är någon garant för säkerhet över huvud taget, så minskar det i varje fall risken att någon hamnar i Wikin utan anledning, så länge denna inte lokaliseras av exempelvis sökrobotar. I andra sammahang kan man tänka sig att informationen är i större behov av integritetsoch tillgänglighetsskydd. Exempelvis skyddas ofta ett företags interna nätverk, intranet från tillgång utifrån med brandvägg, men även internt kan tillgången behöva begränsas. En viss säkerställd spårbarhet beträffande olika ändringar kan också behövas. I sådana fall kan en tvingande inloggningsprocedur med personliga konton såsom beskrivits ovan komma att behövas. Det skall tilläggas att i vårt fall kunde användarna identifiera sig genom att skapa ett konto i Wikin med personlig inloggning och eventuellt ett lösenord om de ville försäkra sig om att ingen annan gjorde ändringar i deras namn. Om inget användarkonto skapades märktes ändringar istället med användarnas IP-nummer. I de stora Wikipedierna används denna begränsade behörighetskontroll för att temporärt eller permanent spärra IP-nummer till användare som stör den dagliga driften, såsom sabotörer. 7 Traditionell dokumentationsprocess visavi Wiki Många företag tillämpar webbaserad dokumentation av organisation, projektstrukturer, medarbetarprofiler, interna och externa tjänster osv. Flödet vid sådana dokumentationsprocedurer brukar vara något i denna stil: Medarbetaren beslutar sig för, eller beordras att upprätta ett visst dokument. Medarbetaren checkar ut ett dokumentnummer för detta ändamål. Dokumentnummersystemet är ofta anpassat för att tillåta multipla revisioner av ett och samma dokument. Innan ett dokument officiellt publicerats används ofta ett prepublikationssuffix eller liknande som indikator på att dokumentet inte är godkänt för bred publicering ens internt. Medarbetaren reviderar dokumentet ett antal gånger och sprider förhandsversionen internt inom sin arbetsgrupp för granskning. Någon medarbetare signerar dokumentet som granskat. Medarbetarens närmast överordnade avgör när dokumentet är moget för publikation. Dokumentet signeras av närmast överordnad och tilldelas ett verkligt dokumentnummer. Dokumentet kan sedan revideras iterativt, med förhandsversionscykler före varje slutgiltig publikation. 7

8 Om dokumentet skall publiceras i en intern webbserver tillkommer för varje revision att dokumentet antingen av medarbetaren själv, eller en av arbetsgivaren utsedd webbredaktör konverterar dokumentet till ett standardiserat format såsom PDF eller HTML och genomför själva publiceringen. Processen ovan kan naturligtvis automatiseras i större eller mindre grad med hjälp av datorsystem, men har ofta detta komplexa flöde, som till sin form påminner om arbetet vid en vetenskaplig tidskrift eller en tidningsredaktion. Man behöver inte vara speciellt verserad för att se sambandet mellan ovanstående publiceringsflöde och de tunga processer som finns inom PERT, WBS eller RUP. 10 För lättviktsprocesser är detta flöde något främmande, och en mer direkt publicering är naturlig. Här passar Wikins direkta flöde som hand i handske. Om olika projektmodeller används inom samma företag eller institution kan avskärmade Wiki-sajter användas för de team som använder agila processer. Wikin tillåter på ett naturligt vis gemensamt ägarskap (engelska: common ownership) till dokumentation, kontinuerlig revision och delar inte utvecklargruppen i editorer och andra. Istället för att knyta rollen som dokumentatör till en viss fysisk person delas den av alla med tillgång till Wikin, och ett visst uppdrag (engelska: story) som rör dokumentation kan tilldelas vem som helst inom gruppen. Korta iterationscykler kan användas även för dokumentation, och det är enkelt att på impuls kvickt ändra något man kommer på, eller att ställa en fråga i anslutning till en viss webbsida. Liksom med andra elektroniska publiceringssystem har Wikin den fördelen att geografiskt eller organisatoriskt distribuerat arbete förenklas, delar av programmeringsteamet kan sitta på olika orter. Detta är dock inte direkt förenligt med XP-praktiken. 8 Tänkbara utökningar i programvaran Emedan vi använt ett ganska enkelt och rudimentärt PHP-skript från Wikipedia har vi under arbetet och genom spontan reflektion upptäckt såväl svagheter som möjliga tillägg som skulle kunna göras i programvaran, samt användningsområden som ligger utanför den nuvarande programvarans användningsområde. De flesta är relativt simpla och skulle kunna utföras av vem som helst med erfoderliga kunskaper i skriptspråket Zend 11 som används av PHP. Detta är för övrigt närbesläktat med exempelvis BASH, AWK, Perl och liknande språk. Push-Wiki eller One-Way-Wiki en Wiki kan vara editerbar enbart från insidan av ett projekt alla som deltar i projektet kan editera via nätverks- eller kontosbegränsningar, men utomstående kan bara läsa informationen och får heller inte tillgång till editeringsfunktioner. Eventuellt kan frågor och annoteringar göras av utomstående, på samma vis som i PHP-manualen, medan direkta ändringar utförs endast av projektmedlemmar. Detta kan också vara lämpligt med tanke på upphovsrättsliga komplikationer ändringar i en text tillhör normalt den som gjort ändringarna om inget annat sagts. Om bara projektmedlemmar kan ändra vet man att dokumentationen tillhör projektmedlemmarna. Bred uppladdningskapacitet Wikipediaskriptet stödjer bara uppladdning av bilder och enklare ljudfiler. Detta är lämpligt för Wikipediaprojektet, men i ett bredare sammanhang kan alla möjliga filtyper behöva bifogas en Wikisida, till exempel patchar och filreleaser. 10 Se vidare om projektstyrningsmodeller på 11 Zend är egentligen namnet på det språk och alfabet som används i zoroastrismens heliga skrift Avesta. 8

9 Integration med andra programvaror man kan vilja använda sin Wiki för felspårning (bug tracking) 12 förändringshantering (application management, change management) med checklistor, regressionstestförfarande och liknande. Här duger den befintliga Wikitekniken långt, men projektmedlemmar kan behöva sätta deadlines och liknande som förenas med påminnelser om uppdraget inte utförs. Grening och release all problematik som förknippas med vanlig konfigurationsstyrning är tillämplig även på dokumentation ur detta perspektiv. Emedan Word-dokument och liknande inte gärna medger grening och mergning pga sin proprietära karaktär och därmed följande brist på programmatiskt gränssnitt, finns inga sådana hinder för det enkla textinnehållet i en Wiki. Man kan eventuellt tänka sig att lagra texten för en Wiki i CVS eller liknande istället för en databas som i dagsläget. Vid release kan man vilja ta en ögonblicksbild av Wikin för layout och publicering i tryckt form. Vad man däremot inte bör göra är att försöka tvinga in Wikin i befintliga processflöden, genom att exempelvis påtvinga granskning och godkänning av varje ändring i Wikin. Detta skall hellre utföras som speciella granskningsuppdrag (stories) där någon, gärna någon utomstående, läser igenom och försöker använda och förstå dokumentationen. 9 Slutsatser I stort har Wiki-användandet fungerat bra. Det har blivit en naturlig samlingsplats för intern dokumentation och kommunikation inom utvecklarteamet. Användarna ändrade gärna på befintliga sidor, men större strukturella förändringar, så som uppdelningar, sammanslagningar etc. skedde mer sällan. Samma fenomen återfanns även i utvecklingsarbetet, där programmerarna gärna höll sig till att ändra i befintliga klasser, men mindre gärna refaktoriserade och skapade nya klasser när så behövdes. Det är möjligt att detta skulle kunna lösas med speciella Wiki-stories. Fler likheter med utvecklingsarbetet kunde märkas. De programmerare som var mest engagerade i utvecklingsarbetet av programmet, var också de som utnyttjade webbplatsen mest, både för att läsa och för att lägga upp ny information. Vi har funnit att programvaran som användes är flexibel och lätt kan anpassas för olika specifika behov, samt visat på några möjliga sådana utvecklingsvägar. 10 Tack till... Tack till Lars Aronsson för idén. programmerarna i grupp CS0310 i kursen Programvaruutveckling i grupp 13 på Lunds Tekniska Högskola, våren Datorföreningen vid Lunds Universitet och Lunds Tekniska Högskola som tillhandahöll servern för WikiWiki-sajten. 12 Såsom i defektspårningssystem som Bugzilla, se

10 11 Referenser - Lars Aronssons uppsats om Wiki-sajter. - Var är Wiki? - Programvara för Wiki-drift. - Wikipedias uppslagssida om WikiWiki. - Lättillgängligt om XP. - Ambitiös sajt om XP med bland andra Ron Jeffries. R. Jeffries, A. Anderson, C. Hendrickson: Extreme Programming Installed. Addison-Wesley,