• No results found

F¨ oreslagen framtida forskning

Allm¨angiltigheten hos den f¨oreslagna teststrategin ¨ar inte fastslagen. F¨or att fastst¨alla allm¨angiltigheten b¨or fler unders¨okningar f¨oretas i liknande utvecklingsprojekt.

Unders¨okningen gav tydliga indikationer p˚a att grundl¨aggande problem med utveck- lingen av Scoutnet st˚att att finna redan i den f¨orsta kravspecifikationen, vilket ¨aven Hedin och Birgisson [16] ber¨or. En framtida unders¨okning av kravarbetet skulle ge svar p˚a fr˚agan “hur kan kravst¨allningsarbetet utformas f¨or att s¨akra kvaliteten hos levererad mjukvara i ett p˚ag˚aende agilt utvecklingsprojekt hos en ideell organisation?”.

9

Slutsats

Studien presenterar ett f¨orslag p˚a hur en teststrategi kan utformas f¨or att s¨akra kvaliteten hos levererad mjukvara i ett p˚ag˚aende agilt utvecklingsprojekt hos en ideell organisation. Ett f¨orslag p˚a teststrategi f¨or Scouternas verksamhetsst¨odsystem Scoutnet har tagits fram och presenterats. Teststrategin har baserats p˚a analys av insamlad intervjudata och stu- dier av relevant litteratur. Mottagande organisation, Scouterna, har godtagit strategin som ¨agandes giltighet och denna har visat sig vara teoretiskt till¨ampbar ¨aven f¨or NSF. En j¨amf¨orelse har gjorts med utvecklingsarbetet i Sverok, men inga slutsatser r¨orande

Ut¨over teststrategin har studien genererat ny kunskap r¨orande mjukvaruutveckling hos ideella organisationer. Denna kunskapsbas f¨oresl˚as ut¨okas genom ytterligare studier av bland annat kravst¨allningsarbetet.

Ordlista

ATTD acceptanstestdriven utveckling.

backend Den del av ett mjukvarusystem som ¨ar osynligt f¨or anv¨andaren. Denna del av mjukvaran tillhandah˚aller exempelvis aff¨arslogik och databas˚atkomst.

BDD beteendedriven utveckling.

commit En serie ¨andringar i ett programs k¨allkod.

Custard Labs F¨oretaget som vid den h¨ar uppsatsens skrivande utvecklar b˚ade Scoutnet och ScoutNet.

eBas Sveroks mjukvara f¨or att hantera medlemsregister och statsbidragsans¨okningar. frontend Den del av ett mjukvarusystem som ¨ar synligt f¨or anv¨andaren. I Scoutnets fall

utg¨ors frontenden av en webbapplikation.

Get Satisfaction En webbtj¨anst som Scouterna och NSF anv¨ander f¨or att ta in syn- punkter p˚a Scoutnet/ScoutNet fr˚an sina medlemmar.

Google Apps En produktivitetssvit fr˚an Google. Tj¨ansten erbjuder bland annat e-post, kalenderfunktionalitet och dokumenthantering. I det h¨ar arbetet avses fr¨amst doku- mentdelen av tj¨ansten.

Google Hangout En snabbmeddelandetj¨anst fr˚an Google. Tj¨ansten erbjuder text-, video- och r¨ostsamtal. Den har ocks˚a st¨od f¨or sk¨arm- och dokumentdelning.

Hogia En leverant¨or som levererar Scouternas ekonomisystem.

IRC Internet Relay Chat, ett icke-persistent textbaserat kommunikationsmedel. Ett van- ligt kommunikationsverktyg i utvecklarkretsar.

KFUM Kristliga f¨oreningen av unga m¨anniskor.

KFUMs scoutf¨orbund Ett nu nedlagt scoutf¨orbund tillh¨orande KFUM-r¨orelsen. Melker Svenska scoutf¨orbundets tidigare verksamhetsst¨odsystem, Scoutnets f¨oreg˚angare

i Sverige.

mock-objekt En bit mjukvara som simulerar en annan mjukvaras beteende. MySQL En relationsdatabasmotor med tillh¨orande SQL-dialekt.

NSF Norges speiderforbund.

PHP Ett programmeringsspr˚ak, fr¨amst avsett f¨or webbsystem.

produktionskod Den delm¨angd av mjukvaran som inte ¨ar avsedd f¨or testning. Det ¨ar denna mjukvara som skapar ett reellt v¨arde f¨or anv¨andaren.

Redmine Ett webbaserat projektverktyg. Scouterna och NSF anv¨ander framf¨orallt verk- tygets ¨arendehanteringsdel.

Redpill Linpro F¨oretaget som ursprungligen utvecklade Scoutnet. De ¨ar inte l¨angre en aktiv part i utvecklingsarbetet.

Scouterna Organisationen som organiserar scoutr¨orelsen i Sverige. scoutk˚ar En f¨orening som driver scoutverksamhet.

Scoutnet Scouternas verksamhetsst¨odsystem.

ScoutNet Norges speiderforbunds verksamhetsst¨odsystem.

sprint I Scrum en avgr¨ansad tidsperiod, under vilken utveckling sker. Denna utveckling ska ha p˚a f¨orhand uppsatta m˚al, vilka realiseras som fungerande leverabler i slutet av tidsperioden.

SSF Svenska scoutf¨orbundet.

Svenska scoutf¨orbundet Det nu nedlagda scoutf¨orbund som f¨orst utvecklade Scoutnet i Sverige.

Sverok Den ungdomsorganisation som organiserar den svenska spelhobbyn. V¨alk¨anda f¨or sina s¨att att maximera statsbidrag genom kreativ uttolkning av regler f¨or statsbidrag och implementation av digitala st¨od f¨or detta.

Sverok Admin AB Ett f¨oretag ¨agt av Sverok, vilket utvecklar och saluf¨or de verksam- hetsst¨odsystem som anv¨ands av bland andra Sverok.

Symfony Ett ramverk f¨or utveckling av st¨orre webbsystem skrivna i PHP.

ticket En avgr¨ansad uppgift som ska utf¨oras, inte alldeles olikt restaurangv¨arldens bong- begrepp. Termen anv¨ands i m˚anga ¨arendehanteringssystem..

TMMi Test Maturity Model integration.

Trello En webtj¨anst som erbjuder projektledningsst¨od med ett kanban-inspirerat anv¨andargr¨anssnitt. verksamhetsst¨odsystem Ett datasystem som hanterar bland annat medlemsregister,

versionshantering En metodik f¨or att hantera versioner av programvara. Detta m¨ojligg¨or bland annat parallell och distribuerad utveckling.

Wordpress Ett publiceringsverktyg f¨or webben, byggt i PHP.

XP eXtreme Programming. En agil utvecklingsmetodik som l¨agger mycket tyngd vid testdriven utveckling och parprogammering som verktyg f¨or att h¨oja kvaliteten i den levererade mjukvaran.

Referenser

[1] World Organization of the Scout Movement. Mission, Vision and Strategy. http://scout.org/brand (l¨ast 18 november 2014).

[2] Scouterna. V˚ar organisation. http://www.scouterna.se/om-scouterna/var- organisation (l¨ast 15 november 2014).

[3] Svenska scoutf¨orbundet. Protokoll 10 f¨ort vid Svenska Scooutf¨orbundets f¨orbundsst¨amma den 19 - 20 november 2011 i Bor˚as. Bor˚as, 2012.

[4] Cheung RC. A User-Oriented Software Reliability Model. IEEE Transactions on Software Engineering 1980, Volym SE-6, andra utg˚avan.

[5] Raymond E S. The Cathedral and the Bazaar. http://www.catb.org/ esr/writings/ cathedral-bazaar/cathedral-bazaar (l¨ast 18 april 2015).

[6] Rask K. Intervjuad av: Holmberg J. 12 november 2014. [7] Stene I. Intervjuad av: Holmberg J. 17 november 2014. [8] Flynn R. Intervjuad av: Holmberg J. 26 juli 2015.

[9] Easterbrook S, Singer J, Storey M, Damian D. Selecting Empirical Methods for Software Engineering Research. I: Shull F, Singer J, Sjøberg D I K (red). Guide to Advanced Empirical Software Engineering. London, Storbritanninen: Springer Lon- don; 2008. s285 – 331.

[10] Walsham G. Interpretive case studies in IS research: nature and method. European Journal of Information Systems Maj 1995 s. 74–81

[11] Ghahrai A. Agile Test Strategy Example Template Testing Excellence. Blogg, 24 mars 2015 (l¨ast 21 februari 2016). http://www.testingexcellence.com/agile-test- strategy-example-template.

[12] Marick B. My Agile testing project. Exploration Through Example. Blogg, 21 august 2003 (l¨ast 21 februari 2016). http://www.exampler.com/old-blog/2003/08/21. [13] Germundsson H. Improvement Areas for Agile Test Processes. Master-uppsats.

Link¨opings universitet, 2012.

[14] H¨ost M, Regnell M, Runesson P. Att genomf¨ora examensarbete. Lund, Sverige: Stu- dentlitteratur, 2006.

[15] Patton M. Designing Qualitative Studies. I: Qualitative evaluation and research met- hods. Beverly Hills, Amerikas f¨orenta stater: Sage; 1990. s169 – 186.

[16] Hedin C, Birgisson S ¨O. Introducing the Agile Requirements Abstraction Model - Requirements Engineering in a Scrum Environment. Master-uppsats. Lunds tekniska h¨ogskola, 2008.

[17] Brannick, T., Coghlan, D. In Defense of Being “Native”. Organizational Research Methods 2007, Volym 10.1, s. 59-74.

[18] Beck K et al. (2001). Manifesto for Agile Software Development. Agile Alliance. http://agilemanifesto.org (l¨ast 31 juli 2015)

[19] Bauch, C. Lean Product Development: making waste transparent. Doktorsavhand- ling. Massachusetts Institute of Technology, 2004.

[20] Womack JP, Jones DT, Roos, D. The machine that changed the world. Simon and Schuster, 2008.

[21] Ebert C, Abrahamsson P, Oza N. Lean software development. IEEE Software 29.5 2012, s. 22-25.

[22] Sugimori Y, et al. Toyota production system and kanban system materialization of just-in-time and respect-for-human system. The International Journal of Production Research 1977, Volym 15.6 s. 553-564.

[23] Beedle M, et al. SCRUM: An extension pattern language for hyperproductive software development. Pattern Languages of Program Design 1999, Volym 4, s. 637-651. [24] Jeffries R, Anderson A, Hendrickson C. Extreme Programming Installed. Addison-

Wesley, 2001.

[25] Koudelia N. Acceptance Test-Driven Development. Master-uppsats. Jyv¨askyl¨a uni- versitet, 2011

[26] Leitner A, Ciupa I, Oriol M, Meyer B, Fiva A. Contract driven development = test driven development - writing test cases. In: ESEC-FSE ’07 Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering New York: ESEC- FSE ’07, 2007, s. 425–434.

[27] Burnstein I. Practical software testing : a process-oriented approach. Chicago, Ame- rikas f¨orenta stater: Springer, 2002.

[28] Daich G, Price G, Ragland B, Dawood M. Software Test Technologies Report. Soft- ware Technology Support Center (STSC). 1994.

[29] Crispin L, Gregory J. Agile testing: A Practical Guide for Testers and Agile Teams. Boston, Amerikas f¨orenta stater: Pearson Education, 2009 Hill Air Force Base, 1994. [30] van Veenendaal E. Test Maturity Model integration (TMMi) Release 1.0. TMMi

Foundation, 2012.

[31] Laxman Gawand H. Agile testing is one of the best practices- with a proper test plan and strategy. Testing Experience: The Future of Testing December 2011 s. 42–47.

[32] IEEE Computer Society Standards Coordinating Committee. Standard Glossary of Software Engineering Terminology. IEEE Software, 1990.

[33] Stolberg S. Enabling Agile Testing through Continuous Integration. In: Agile Con- ference, 2009. AGILE ’09 Proceedings Agile 2009 Conference 24–28 August 2009, Chicago, Illinois. Chicago, Amerikas f¨orenta stater: Agile Alliance, 2009, s. 369–374. [34] Chen L. Continuous Delivery: Huge Benefits, but Challenges Too IEEE Softwa-

re 2015, Volym 32, andra utg˚avan, s. 50–54.

[35] Sheppard TE. Do not use testing metrics for the wrong reason. Testing Experience: Metrics September 2010 s. 115–117.

[36] Musa JD, Ackerman AF. Quantifying software validation: when to stop testing? Software, IEEE 1989, Volym 6, tredje utg˚avan.

[37] Kniberg H, Skarin M. Kanban and Scrum - Making the Most of Both. Raleigh, Amerikas f¨orenta stater: Lulu Press, 2010.

[38] Rask K. E-post 19 februari 2015

[39] Scouterna, Webbplats i WordPerss. http://www.scoutservice.se/utveckla- karen/scoutwebb/webbplats-i-wordpress (l¨ast 19 april 2015).

[40] Scouterna, Scouterna.se. http://www.scouterna.se (l¨ast 19 april 2015). [41] Scouterna, Scoutservice. http://www.scoutservice.se (l¨ast 19 april 2015).

[42] Sverok Admin AB. eBas. http://sverokadmin.se/stodsystem/ebas/ (l¨ast 25 februari 2016).

[43] Gustavsson D. Intervjuad av: Holmberg J. 3 mars 2016.

[44] Kipling R. Just So Stories for Little Children. London: Macmillan & Co; 1902. [45] Hevner A, Chatterjee S. Design Research in Information Systems. New York: Spring-

Figurer

1 Beskrivning av arbetsprocess. . . 4 2 Testprocessen som del i utvecklingsprocessen. Testaktivteter ¨ar markerade

i r¨ott. . . 9 3 De fem niv˚aerna i TMMi. . . 10 4 Ett rimligt f¨orh˚allande mellan automatiserade och manuella tester enligt

Ghahrai [11]. . . 13 5 Maricks testmatris [12]. . . 14 6 Scoutnets utvecklingsfl¨ode enligt Rask. . . 18

Bilagor

Bilaga 1 Intervju med Kim Rask, 12 november 2014

Bilaga 2 Intervju med Ingrid Stene, Skype, 17 november 2014 Bilaga 3 Intervju med Russel Flynn, telefon, 26 juli 2015 Bilaga 4 Intervju med David Gustavsson, telefon, 3 mars 2016 Bilaga 5 E-post fr˚an Kim Rask avseende avbruten utveckling Bilaga 6 F¨orslag till teststrategi f¨or Scoutnet

Intervju med Kim Rask, Stockholm, 12 november 2014

Kim Rask ¨ar ansvarig tj¨ansteman f¨or Scoutnet hos Scouterna. Hur skulle du beskriva historiken f¨or Scoutnet?

NSF b¨orjade utveckla ScoutNet 2009 som anm¨alningssystem f¨or sitt Landslejr. Scouter- na blev uppsagda av ClubOnWeb, som utvecklade Melker, 2010. Man fick d˚a ett halv˚ar p˚a sig att hitta en ny leverant¨or och valet f¨oll p˚a Scoutnet. Leveransen var bristf¨allig, vilket berodde p˚a d˚alig kravst¨allning och problem med f¨orst˚aelse och kommunikation mel- lan kund och leverant¨or. Kim b¨orjade ˚arsskiftet 2010/2011. Medlemmarna var uppr¨orda vid leverans, d˚a det som levererades inte var det som utlovats. Faktureringen levererades tidigt, men fungerade inte s¨arskilt bra, p˚a grund av stora integrationsproblem med ekono- misystemet fr˚an Hogia. Problem med integrationen berodde till stor del p˚a problem med att f˚a leverant¨orerna Hogia och Redpill att prata med varandra. Kim beskriver att Hogia hade stora brister i dokumentationen. Ett problem var ocks˚a frifr¨asande utvecklare, som byggde leverabler utan f¨ardiga kravbilder. Utvecklingen har ocks˚a varit personberoende, d˚a niv˚an inte varit j¨amn p˚a leverant¨orens utvecklare och projektledare. Under 2014 har Redpill lagt ner avdelningen som utvecklade Scoutnet. Ett nytt interimavtal har ing˚atts med tidigare utvecklare fr˚an Redpill (Custard Labs).

Hur ser kravprocessen f¨or Scoutnet ut?

Tv˚a fl¨oden: nyutveckling och bughantering/sm˚a features. Den senare ¨ar den vanligaste just nu. N˚agon h¨or av sig och rapporterar in ett fel. Felet l¨aggs in i felhanteringssytemet Redmine. Kim beskriver felet s˚a noga han kan, g¨arna med en sk¨arminspelning. Kim pratar sedan med leverant¨or, som bed¨omer felet utifr˚an tid och pris. F¨or nyutveckling samlas ett g¨ang till workshops f¨or att ta fram nya id´eer/behov. Detta utg˚ar fr˚an de arbetsfl¨oden som finns i verksamheten. Kim skriver ihop dessa id´eer/behov som use cases, som skickas till leverant¨or f¨or estimering. Kraven ligger p˚a en relativt h¨og niv˚a (av typen ”Administrat¨oren ska kunna byta namn p˚a en anv¨andare”).

Hur s˚ag utvecklingsprocessen ut under Redpill-tiden?

Kim har anammat Redpills arbetss¨att. Redpill har h¨avdat att de arbetat enligt Scrum, vilket inte verkar vara fallet. De har arbetat med sprintar, tickets och kanbanboards. Alla sprintar har inte avslutats med sprint review och release, vilket ses som d˚aligt. Detta har ofta berott p˚a bristande projektledning fr˚an Redpills sida, vilket f˚att till f¨oljd att Kim f˚att agera projektledare, trots att han ¨ar best¨allare.

Vilka arbetsverktyg anv¨ander du f¨or kravhantering?

Kravspecning sker i Visual Paradigm. De har en gratis community license. Det prim¨ara verktyget ¨ar Redmine, som ¨ar ett ¨arendehanteringssystem. Scouterna och NSF k¨or Trel- lo f¨or gemensam planering. F¨or kommunikation anv¨ands mail, IRC, Google Hangout och

Google Apps (dok och spec). F¨or ¨overs¨attningar anv¨ands Xliff Editor, som ¨ar en XML- editor. Det jobbas mycket med sk¨arminspelningar, vilket upplevs som tydligare ¨an bildse- rier f¨or att visa fl¨oden. Office-program anv¨ands ocks˚a. F¨or anv¨andardialog anv¨ands Get- Satisfaction, mail och telefonsupporten. Facebook anv¨ands f¨or att annonsera f¨or¨andringar i Scoutnet samt driftst¨orningar, men anv¨ands inte f¨or att samla in synpunkter. Ut¨over det anordnas emellan˚at fysiska tr¨affar.

Hur ser processerna ut f¨or leverans, validering och drifts¨attning?

Leverans deployas p˚a utvecklingsserver, stagingserver och produktionsserver. Till sta- gingservern g¨ors en deploy inneh˚allande aktuell sprints tickets, markerade med en tag. Samtidigt med deployen uppdateras alla p˚averkade tickets i Redmine och en changelog genereras. Vid behov genereras en ny upps¨attning ¨overs¨attningsfiler. Vid behov dras en ny dump fr˚an databasen in p˚a stagingservern. Utifr˚an changelogen testar Kim igenom de tickets som ska ha utvecklats. N¨ar alla dessa anses vara godk¨anda best¨alls en deploy p˚a produktionsservern. I vissa fall backas en del tickets.

Beskriv f¨orh˚allandet mellan NSF och Scouterna

Scouterna och NSF ¨ager k¨allkoden till Scoutnet/ScoutNet gemensamt. Katarina Hedberg (generalsekreterare Scouterna) har kontakt med Jens Morsø (generalsekreterare NSF). Kims motpart hos NSF heter Ingrid Stene, som ¨ar administrat¨or.

Ber¨atta om den ideella arbetsgrupp som arbetar med Scoutnet

Scoutnet har en ideell arbetsgrupp, best˚aende av en ideell ordf¨orande, tv˚a ideella utvecklare och en utbildningssamordnare, som ansvarar f¨or att knyta ideella utbildare, samt f¨or att anpassa Scoutnets manual f¨or webben. Bortsett fr˚an utbildningssamordnaren ¨ar gruppen just nu vilande.

Intervju med Ingrid Stene, Skype, 17 november 2014

Ingrid Stene ¨ar ansvarig tj¨ansteman f¨or ScoutNet hos Norges speiderforbund. Hur skulle du beskriva historiken f¨or ScoutNet?

Norges speiderforbund hade tidigare ett off-the-shelf-system f¨or medlemshanteringen. De ville ha en egen l¨osning f¨or att m¨ota sina behov. Utg˚angspunkten var att de skulle vida- reutveckla ett befintligt system, men detta var inte bra nog, s˚a de valde att bygga fr˚an grunden. Detta var 2008. I praktiken startade arbetet under h¨osten 2008, det gick live i januari 2009. Det byggdes f¨orst f¨or Landslejr. Utg˚angspunkten f¨or detta var att bygga in st¨od f¨or scoutk˚arer. Inte all data flyttades ¨over i det nya systemet. Scouterna (SSF) kom med i samarbetet 2010. Till en b¨orjan var utvecklingen parallell och samarbetet var inte s˚a bra. Detta berodde mycket p˚a personkemi och p˚a den svenska omorganisationen. N¨ar Kim kom p˚a plats blev det b¨attre.

Hur ser kravprocessen f¨or ScoutNet ut?

I praktiken handlar det om att Ingrid best¨ammer vad som beh¨ovs. Detta beskrivs och skickas in som krav. Mycket ¨ar drivet av omedelbara behov som m˚aste tillfredsst¨allas. Kraven tas fram i samarbete med kanslipersonal med koll p˚a den aktuella dom¨anen. Hur s˚ag utvecklingsprocessen ut under Redpill-tiden?

I starten var det ont om tid. Planen var att k¨ora sprintar p˚a tv˚a veckor, men detta fungerade inte. H¨ari ligger den fr¨amsta orsaken till bristen p˚a testrutiner, d˚a dessa helt enkelt prioriterades bort. Inga automatiska testrutiner sattes upp. Efterhand blev proces- sen b¨attre, men testrutinerna blev aldrig riktigt bra. Utvecklarna har varit bra. De har f¨orst˚att vad NSF faktiskt beh¨ovt och haft k¨ansla f¨or bra UX. Samarbetet har p˚a det stora hela fungerat bra, trots allt. Arbete har str¨omlinjeformats, men problem med regressions- fel har funnits hela tiden. Ingrid p˚apekar att hon inte haft samma problem med att f˚a kontakt med Redpill som Kim f˚att, men d˚a hon inte jobbar med ScoutNet p˚a heltid kan det bero p˚a det. Kim har 100%, Ingrid har 20%.

Vilka arbetsverktyg anv¨ander du f¨or kravhantering?

Redmine f¨or att rapportera fel och l¨agga best¨allningar. Har anv¨ant bilder f¨or att kommu- nicera. Kim anv¨ander sig av Trello, men det g¨or inte Ingrid i samma utstr¨ackning l¨angre. Hur ser processerna ut f¨or leverans, validering och drifts¨attning?

Efter varje utvecklingsperiod, som kan variera i l¨angd, levereras en release p˚a en stagingser- ver. Ingrid testar igenom och n¨ar hon ¨ar n¨ojd best¨aller hon en release som deployas p˚a driftservern. Om n˚agot blir fel efter det felanm¨als detta i Redmine.

Beskriv f¨orh˚allandet mellan NSF och Scouterna

Ingrid tycker att det fungerar bra, speciellt sedan Kim tog ¨over. Detta kan ha att g¨ora med personkemi, men Ingrid tror framf¨orallt att det har att g¨ora med det fokus som utvecklingen f˚att. De hade i b¨orjan gemensamma m¨oten en g˚ang i m˚anaden, varannan g˚ang i Stockholm, varannan g˚ang i Oslo. Ibland var med Redpill p˚a. Problemen i Sve- rige var k¨anda f¨or NSF. P˚a senare tid har det varit f¨arre m¨oten, d˚a de har l¨art k¨anna varandra b¨attre och kan k¨ora mer ¨over e-post. Vid liknande id´eer jobbas det f¨or att hitta gemensamma l¨osningar som fungerar f¨or b˚ada parter.

Hur ser planerna ut p˚a att sl¨appa Scoutnet som open source?

Det har varit prat om open source. Det var tal om kostnaden f¨or att s¨akerst¨alla kvaliteten i koden vid ¨oppnande. Fr˚agest¨allningar r¨orande s¨akerhet, anv¨andbarhet och licenser blev ¨

overmodiga. En metod som diskuterades var att ¨oppna upp k¨arnan av koden och l˚ata tred- jepartsutvecklare utveckla moduler som inte k¨ors i plattformen. Inga av de organisationer som blev tillfr˚agade om att vara med nappade.

Intervju med Russel Flynn, telefon, 26 juli 2015

Russel Flynn, Custard Labs (tidigare Redpill-Linpro), ¨ar nuvarande utvecklare av Scoutnet och ScoutNet.

How would you describe the history of Scoutnet?

So the project started when the Norwegian scouts approached the company that I used to work for. They wished to replace their existing, Oracle-based system with something more flexible and more suitable to their needs. For the first couple of years they were alone in this. The Swedish scouts joined the project in 2010. At first both products were run as one common project, but after a short while the codebase was split into two separate codebases. The reason for this was that the requirements rapidly diverged and maintaining a common codebase became unfeasible. Once the Swedes’ initial development phase was done, we could merge the codebases into a common one once again.

The company, Linpro, was bought by Redpill, who formed Redpill-Linpro. The plan was to be able to sell the system to more customers, but this never happened. Redpill never made a real profit from the system and halted their involvement in Scoutnet in 2014. The software is jointly owned by Scouterna and NSF. I left the company and started Custard Labs to continue the development of the software. Since I don’t have the overhead costs associated with project management, sales and all that it is possible to run a business on the project.

The number of active developers has fluctuated over the years. In fact, I’m the only person who has been an active part of the development of the system since its conception. How would you describe the development process at Redpill, from a Scouterna point of view?

Redpill-Linpro is a very open sourcey company. They are used to work in a very open way. Initially, Scoutnet was supposed to be developed using Scrum. That changed rather quickly, with only parts of Scrum being used, mainly the sprint system. The sprints weren’t actual sprints in the Scrum sense, but they worked quite well. Each sprint would contain

Related documents