{"id":34112,"date":"2019-10-31T21:56:27","date_gmt":"2019-10-31T18:56:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-pytalis-v-komandnuyu-rabotu-i-chto-iz-etogo-vyshlo\/"},"modified":"2019-10-31T21:56:27","modified_gmt":"2019-10-31T18:56:27","slug":"kak-my-pytalis-v-komandnuyu-rabotu-i-chto-iz-etogo-vyshlo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/news\/kak-my-pytalis-v-komandnuyu-rabotu-i-chto-iz-etogo-vyshlo","title":{"rendered":"Hvordan vi pr\u00f8vede teamarbejde, og hvad der kom ud af det","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hvordan
\n<\/p>\n

Lad os tage det i r\u00e6kkef\u00f8lge<\/h3>\n

\nHvad denne illustration betyder, vil jeg komme ind p\u00e5 senere, men lad mig f\u00f8rst starte med en introduktion.<\/p>\n

P\u00e5 en kold februardag var der intet, der foruds\u00e5 problemer. En gruppe uskyldige studerende m\u00f8dtes for f\u00f8rste gang til en lektion i et kursus, vi valgte at kalde \"Metodologi for organisation af design og udvikling af informationssystemer\". Det var en almindelig forel\u00e6sning, og underviseren talte om smidige udviklingsmetoder som Scrum; intet indikerede problemer. Og s\u00e5, til slut, annoncerede underviseren: <\/p>\n

Jeg vil have, at I selv skal opleve alle byrderne ved teamarbejde. Del jer op i grupper, find p\u00e5 et projekt, udpeg en leder, og gennemg\u00e5 alle designfaser sammen. Til sidst forventer jeg et f\u00e6rdigt produkt og en artikel p\u00e5 Habr.<\/p><\/blockquote>\n

Og her begynder vores historie. <\/a><\/noindex> Som kuglerne p\u00e5 et billardbord sprang vi fra hinanden, indtil energien fra slaget var fordampet, og der samlet sig en gruppe p\u00e5 7 personer. M\u00e5ske er det for mange til et skoleprojekt, men for bedre at fordele rollerne er det lige passende. Diskussionen om ideer til projektet sp\u00e6nder fra \"Lad os tage et f\u00e6rdigt projekt\" til \"Emulator for dannelse af rumobjekter.\" Men til sidst blev ideen, hvis navn du allerede har l\u00e6st p\u00e5 det f\u00f8rste billede, f\u00f8dt. <\/p>\n

Stop Procrastination - hvad er det, hvordan fungerer det, og hvordan udviklede vi det, og hvad blev resultatet?<\/h2>\n

\nFort\u00e6llingen vil blive pr\u00e6senteret fra perspektivet af projektlederen, som heldigvis eller desv\u00e6rre blev mig. Hvilken id\u00e9 kom vi s\u00e5 p\u00e5? Inspireret af den popul\u00e6re alarmfunktion \"Ryst Alarmen\" fra SupperCommon, specifikt funktionen, der fuldst\u00e6ndigt blokerer for brugen af smartphonen, indtil brugeren udf\u00f8rer en bestemt handling, der sandsynligvis vil v\u00e6kke dem, besluttede vi at skabe en lignende applikation, der vil hj\u00e6lpe med at bek\u00e6mpe smartphoneafh\u00e6ngighed, baseret p\u00e5 samme princip som \"Ryst Alarmen\".<\/p>\n

Arbejdets princip<\/h3>\n

Brugeren s\u00e6tter timere
\n-Tid man kan bruge p\u00e5 smartphone
\n-Tid uden smartphone (blokeringsperiode)
\nN\u00e5r timeren er udl\u00f8bet, vises et overlay p\u00e5 sk\u00e6rmen, som ikke kan lukkes
\n-For at lukke overlayet skal man gennemf\u00f8re en lille pr\u00f8ve (indtaste en adgangskode p\u00e5 et besv\u00e6rligt tastatur, l\u00f8se en matematisk opgave, ryste telefonen i et par minutter)
\nEfter denne form for opl\u00e5sning reduceres den tid, der kan tilbringes med smartphoneen, med det halve, og det kan v\u00e6re helt ned til et minut.\n<\/p><\/blockquote>\n

Vi bygger et team<\/h3>\n

F\u00f8rst skulle det fastl\u00e6gges, hvem der skulle lave hvad, og p\u00e5 hvilket sprog alt dette skulle skrives. Jeg mener, det har ikke s\u00e5 meget at g\u00f8re med projektledelse, fordi n\u00e5r man samler et team til et rigtigt projekt, samler man med det samme dem, man har brug for. I sidste ende tog jeg ogs\u00e5 ansvar som designer og valgte en teamleder, der havde god erfaring med app-udvikling; tre programm\u00f8rer blev sat under ham, og to andre blev testere. Selvf\u00f8lgelig blev programmeringssproget valgt ud fra f\u00e6rdighederne. Det blev besluttet at bruge Java, da alle programm\u00f8rer var bekendt med det.<\/p>\n

Vi fasts\u00e6tter opgaver<\/h3>\n

Efter anbefaling fra l\u00e6reren blev der oprettet et opgaveliste p\u00e5 en gratis tjeneste. Trello<\/a><\/noindex>. Det var planlagt at arbejde efter Scrum-systemet, hvor hver sprint ville repr\u00e6sentere en afsluttet applikation.
\nMen i praksis blev det hele til \u00e9n stor og lang sprint, hvor der konstant blev lavet \u00e6ndringer, tilf\u00f8jelser og rettelser. <\/p>\n

\"Hvordan
\n<\/p>\n

Vi skriver specifikationer<\/h3>\n

Under indflydelse af Savins bog \u00abTesting.com\u00bb havde jeg en klar forestilling om, hvordan alt skulle v\u00e6re. Det hele begyndte med at skrive specifikationer, for uden en klar beskrivelse af, hvad vi forventer, hvordan det skal fungere, vil intet fungere. Programm\u00f8rer vil kode det, som de ser det, testere vil teste noget andet, og lederen vil forvente noget tredje, men resultatet vil altid v\u00e6re noget fjerde.
\nDet er ikke nemt at skrive specifikationer; man skal overveje alle detaljer og nuancer. Selvf\u00f8lgelig lykkedes det ikke i f\u00f8rste fors\u00f8g. I sidste ende blev specifikationerne revideret og \u00e6ndret fire gange. Den sidste version kan du finde i slutningen af artiklen, i afsnittet med links. <\/p>\n

Vi tegner design<\/h3>\n

Designet i mobilapplikationen er det vigtigste. Ikke alle forst\u00e5r dette, inklusive mange fra mit team, som ivrigt har diskuteret med mig om, at design ikke er n\u00f8dvendigt, at det er den mindst vigtige del af applikationen osv. Man skal ikke v\u00e6re s\u00e5 naiv. For det f\u00f8rste er et f\u00e6rdigt design en lettelse for programm\u00f8rens arbejde; han beh\u00f8ver ikke at t\u00e6nke over, hvad han skal putte hvor, han tager bare og kodning det, der er tegnet. Sammen med specifikationerne frig\u00f8r designet n\u00e6sten helt programm\u00f8rens sind fra un\u00f8dvendige ting og giver ham mulighed for at fokusere p\u00e5 logikken. Generelt blev en prototype (horribelt) designet f\u00f8rst:<\/p>\n

\"Hvordan
\n
\nMen derefter blev designet trimmet og bragt i orden.
\n(Link til alle designelementer i slutningen af artiklen).<\/p>\n

\"Hvordan
\n<\/p>\n

Programmering<\/h3>\n

Det er sv\u00e6rt at programmere, men muligt. Jeg vil springe over dette punkt, da jeg personligt ikke har besk\u00e6ftiget mig med det. Programm\u00f8rerne har gjort et stort stykke arbejde, uden hvilket alt ville v\u00e6re meningsl\u00f8st. Selvf\u00f8lgelig lykkedes det at realisere nogle af id\u00e9erne. Og programmet har stadig brug for forbedringer. Der er mange fejl og funktioner, der skal fjernes. Havde vi haft mere tid, ville vi v\u00e6re ude af dyb alfa, men indtil videre kan du teste applikationen i slutningen af artiklen.<\/p>\n

Og om testning<\/h3>\n

Hvad er det vigtigste i programmering? Efter min mening er det vigtigste, at alt fungerer og ser ud, som det skal. Som regel fungerer det ikke altid og ikke med det samme. Til det er testning n\u00f8dvendig. Til mine testere tilb\u00f8d jeg en testningsmodel ved brug af test cases. F\u00f8rst skrives test cases i fuld overensstemmelse med specifikationerne, og derefter udf\u00f8res testningen baseret p\u00e5 dem. Hvad der kom ud af det, kan du se nedenfor i links. <\/p>\n

Tak fordi du l\u00e6ste. Jeg h\u00e5ber, du fandt noget nyttigt her, m\u00e5ske en id\u00e9 til dit eget startup, eller m\u00e5ske et godt r\u00e5d eller et v\u00e6rkt\u00f8j.<\/p>\n

Links:<\/h3>\n

Seneste specifikationerne<\/a><\/noindex>.
\nDesignet i Figma<\/a><\/noindex>.
\nTest cases<\/a><\/noindex> og bug reports<\/a><\/noindex>.<\/p>\n

Selve applikationen p\u00e5 HokeyApp<\/a><\/noindex>. \u2014 Applikationen blev bygget under navnet HandsOff, sp\u00f8rg ikke hvorfor (fordi Stop Procrastination er for langt).<\/p>\n

Og til sidst<\/h3>\n

Hvad mener du, gav alt dette mening?<\/p>\n

Kun registrerede brugere kan deltage i unders\u00f8gelsen. Log ind<\/a><\/noindex>, please.<\/p>\n

Er denne praksis n\u00f8dvendig i uddannelsesinstitutioner, og hvor nyttig og anvendelig er den i det virkelige liv?<\/h2>\n