Scrum-metoodika kasutamine pikaajalistes tudengiprojektides ESTCube-1 Missioonijuhtimissüsteemi näitel
Date
2012
Authors
Journal Title
Journal ISSN
Volume Title
Publisher
Tartu Ülikool
Abstract
Bakalaureusetöö eesmärk oli analüüsida Scrum-metoodika kasutamist pikaajalistes tudengiprojektides, kasutades näitena ESTCube-1 Missioonijuhtimissüsteemi (edaspidi MJS). Analüüs tõi välja senise Scrum-implementatsiooni nõrgemad küljed ja nende võimalikud lahendused. Et töö kirjutati ajal, mil MJS arendusprotsess oli alles pooleli, analüüsiti ka, kas antud metoodikaga tasub jätkata või tuleb valida mõni teine. Analüüsi usaldusväärsuse tõstmiseks on sisse toodud kolm teist arendusmetoodikat ja neid MJS Scrum-implementatsiooniga võrreldud.
Scrum on agiilne tarkvara arendamise metoodika, mis põhineb iteratiivsetel ja inkrementaalsetel praktikatel. Iteratiivne lähenemine näeb ette, et esmalt ehitatakse valmis väike osa tootest, mida edaspidi inkrementaalselt ehk järk-järgult järgmistes etappides laiendatakse. Scrum’i üheks olulisemaks tunnuseks ongi etappidepõhine tsükliline arendamisprotsess. Samuti iseloomustavad Scrum’i iseorganiseeruvad meeskonnad ja tugev rõhk tehnilisel täiuslikkusel. Bakalaureusetöö kirjutamise hetkeks on Scrum arendusmetoodikat kasutanud kolm MJS-meeskonda.
Analüüsist selgus, et hetkel MJS arenduses kasutusel olev Scrum-implementatsioon vastab hästi antud projekti kontekstile. Ainsa nõrkusena võib välja tuua haavatavuse juhul, kui meeskond motivatsiooni kaotab. Võimalikku probleemi saab aga vältida rangete arendustsüklite kehtestamisega või kogenematu Scrum Master’i (Scrum’i meeskonnajuhi) väljavahetamisega.
Eelnev oli ainus Scrum’i kasutamisega seotud potsentsiaalne oht, seega võib öelda, et hetkel kasutusel olev Scrum-implementatsioon tuleb projektile kindlasti kasuks. Sellegipoolest võiks töö optimeerimise eesmärkidel kaaluda ka kasulikemate praktikate laenamist teistest metoodikatest.
MJS meeskondade liikmete tase on tihti väga erinev ja seega tasuks meeskonnasiseseks ühtlustamiseks rakendada ekstreemprogrammeerimise (Extreme Programming) paarisprogrammeerimist. Paarisprogrammeerimine on kahe inimese üheaegne programmeerimine ühe arvuti taga. See aitaks vähesema eelneva kogemusega meeskonnaliikmetel teistele järele jõuda ja samal ajal ka projekti arendamisesse panustada.
Et vähendada juhtusid, mil käimasolevaid Sprinte (Scrum’i arendustsükkel) on vaja muuta, võiksid meeskonnad implementeerida Lean Software Development metoodika praktikat “Otsusta nii hilja kui võimalik”. Hetkel alustatakse tööd kõrgema prioriteediga ülesannetest, olenemata sellest, kas need on lõplikult määratletud või mitte. Antud praktika aitaks vähendada olukordi, kus varasemalt määratletud eesmärki muudetakse ja sellega seotud töö on vaja kas osaliselt või täielikult uuesti teha.
The purpose of this thesis was to analyze the use of Scrum-methodology in long-term student projects following the case of ESTCube-1 Mission Control System, and to examine whether it is a reliable methodology in the projects of given type. The analysis revealed that the implementation of Scrum in ESTCube-1 is a suitable methodology for long-term student projects. The only weakness in the current methodology implementation is vulnerability to possible lack of team motivation. However, the potential problem can be avoided with establishing a work routine that is strict enough for less experienced teams or choosing another, more experienced, Scrum Master. Another objective of the thesis was to give additional recommendations for further adjustments for Scrum if the reliability of Scrum was verified. To increase work efficiency using best practices from other methodologies alongside with Scrum should be considered. To make the teams’ work more effective as well as beneficial in educational purposes, the teams should consider implementing “Pair programming” from Extreme Programming. As this technique requires that all code is produced by two people programming simultaneously on one computer, this practice would help to raise the competence of less experienced team members and produce reliable results in shorter time. To reduce the number of cases where ongoing Sprints have to be changed, the teams should implement the “Decide as late as possible” practice from Lean Software Development. While the Sprint Backlog is currently composed of the most important items already specified in the Product Backlog, the implementation of the practice in question would reduce the time spent on tasks that later would have to be reconsidered.
The purpose of this thesis was to analyze the use of Scrum-methodology in long-term student projects following the case of ESTCube-1 Mission Control System, and to examine whether it is a reliable methodology in the projects of given type. The analysis revealed that the implementation of Scrum in ESTCube-1 is a suitable methodology for long-term student projects. The only weakness in the current methodology implementation is vulnerability to possible lack of team motivation. However, the potential problem can be avoided with establishing a work routine that is strict enough for less experienced teams or choosing another, more experienced, Scrum Master. Another objective of the thesis was to give additional recommendations for further adjustments for Scrum if the reliability of Scrum was verified. To increase work efficiency using best practices from other methodologies alongside with Scrum should be considered. To make the teams’ work more effective as well as beneficial in educational purposes, the teams should consider implementing “Pair programming” from Extreme Programming. As this technique requires that all code is produced by two people programming simultaneously on one computer, this practice would help to raise the competence of less experienced team members and produce reliable results in shorter time. To reduce the number of cases where ongoing Sprints have to be changed, the teams should implement the “Decide as late as possible” practice from Lean Software Development. While the Sprint Backlog is currently composed of the most important items already specified in the Product Backlog, the implementation of the practice in question would reduce the time spent on tasks that later would have to be reconsidered.