Processer |
| « Tilbage Agilitet i processer I forbindelse med at DRIL er vokset i mandskab inden for det sidste år, har det været nødvendigt at nytænke den måde vi arbejder med projekter. Især omkring den tekniske udvikling hvor vi er blevet væsentlig forøget, men også omkring projektledelsen har vi arbejdet med nye metoder og processer for at være mest muligt effektive. Vi har derfor i forlængelse af, det arbejde som DR Medieudvikling satte i gang omkring Agile projekt forløb, implementeret en række metoder og værktøjer som er samlet under den agile projekt paraply http://agilemanifesto.org/ Konkret er vi startet blødt med blot nogen enkelte principper, men med den vision at implementere flere og flere metoder efterhånden. Kriteriet er naturligvis at de skal have en reel effekt og fordel i stedet for at være en god idé som kan blive en klods om benet. Derfor evaluerer vi konstant vores processer og metoder. Vi arbejder pt. med flg. principper. Versions kontrol - Al kode samt vigtige dokumenter skal være samlet i et versionerings værktøj, således at alle til enhver tid kan tilgå dem og at rettelser aldrig bliver til slettelser. Dette sikrer naturligvis at al information vedrørende et projekt er til rådighed til hver en tid og at sygdom og følelser ikke berører projekter mere end højst nødvendigt. Det er derfor et krav for alle projekt deltagere at være omhyggelig med altid at lægge de nyeste ting i versions kontrol systemet,
og i det hele taget at holde orden i den fælles forretning. Iterativ projektering - Projekter planlægges med flere delprojekter (fra nu af kaldet iterationer). Disse har en deadline og en efterfølgende iteration kan ikke påbegyndes før end at den foregående er afsluttet. En iteration er afsluttet når "kunden" har godkendt resultatet af iterationen og succeskriterier for iterationen er opnået. Test drevet software udvikling vha. user stories - Når et projekt skal tegnes arbejder vi først og fremmest ud fra brugerens synspunkt og udarbejder i den forbindelse de enkelte bruger oplevelser (user stories) som i sidste ende tegner hele projektet. Det er endvidere meget nemmere at få en kunde til at forholde sig til bruger oplevelser end til algoritmer og objekt hierarkier. En user storie specificeres konkret ud fra en test som dikterer hvilke input skaber hvilke output. Testen
godkendes af kunden og udvikles først, hvorefter løsningen udvikles. Efterfølgende har man så begge dele i sit versions kontrol system som til hver en tid kan afvikle alle tests og på den måde hele tiden sikre at de forskellige user stories afvikles i overensstemmelse med de oprindelige krav. Kode gennemlæsning inden check in - Når en user story er færdiggjort og har betået sin(e) test skal den lægges i versions kontrol systemet. Inden dette sker skal den dog kigges igennem af en anden person med de rette kompetencer og godkendes af denne. Det sikrer at kode er letforståeligt for fremmede da man skal være omhyggelig for at andre kan forstå ens kragetæer, hvilket især er en fordel når man et år senere skal rette eller tilføje noget. Vi påtænker at implementere Build automation og eXtreme programming som yderligere metoder... Vi vil løbende skrive om vores erfaringer og konkrete tiltag. For yderligere information - se links Generel Video site om software udvikling Bøger Software |
