🥇Hvordan vi forsøgte os med teamwork, og hvad der kom ud af det

Hvordan vi prøvede teamarbejde, og hvad der kom ud af det

Lad os tage det i rækkefølge

Hvad denne illustration betyder, vil jeg komme ind på senere, men lad mig først starte med en introduktion.

På en kold februardag var der intet, der forudså problemer. En gruppe uskyldige studerende mødtes for første 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æsning, og underviseren talte om smidige udviklingsmetoder som Scrum; intet indikerede problemer. Og så, til slut, annoncerede underviseren:

Jeg vil have, at I selv skal opleve alle byrderne ved teamarbejde. Del jer op i grupper, find på et projekt, udpeg en leder, og gennemgå alle designfaser sammen. Til sidst forventer jeg et færdigt produkt og en artikel på Habr.

Og her begynder vores historie. Som kuglerne på et billardbord sprang vi fra hinanden, indtil energien fra slaget var fordampet, og der samlet sig en gruppe på 7 personer. Måske er det for mange til et skoleprojekt, men for bedre at fordele rollerne er det lige passende. Diskussionen om ideer til projektet spænder fra "Lad os tage et færdigt projekt" til "Emulator for dannelse af rumobjekter." Men til sidst blev ideen, hvis navn du allerede har læst på det første billede, født.

Stop Procrastination - hvad er det, hvordan fungerer det, og hvordan udviklede vi det, og hvad blev resultatet?

Fortællingen vil blive præsenteret fra perspektivet af projektlederen, som heldigvis eller desværre blev mig. Hvilken idé kom vi så på? Inspireret af den populære alarmfunktion "Ryst Alarmen" fra SupperCommon, specifikt funktionen, der fuldstændigt blokerer for brugen af smartphonen, indtil brugeren udfører en bestemt handling, der sandsynligvis vil vække dem, besluttede vi at skabe en lignende applikation, der vil hjælpe med at bekæmpe smartphoneafhængighed, baseret på samme princip som "Ryst Alarmen".

Arbejdets princip

Brugeren sætter timere
-Tid man kan bruge på smartphone
-Tid uden smartphone (blokeringsperiode)
Når timeren er udløbet, vises et overlay på skærmen, som ikke kan lukkes
-For at lukke overlayet skal man gennemføre en lille prøve (indtaste en adgangskode på et besværligt tastatur, løse en matematisk opgave, ryste telefonen i et par minutter)
Efter denne form for oplåsning reduceres den tid, der kan tilbringes med smartphoneen, med det halve, og det kan være helt ned til et minut.

Vi bygger et team

Først skulle det fastlægges, hvem der skulle lave hvad, og på hvilket sprog alt dette skulle skrives. Jeg mener, det har ikke så meget at gøre med projektledelse, fordi når man samler et team til et rigtigt projekt, samler man med det samme dem, man har brug for. I sidste ende tog jeg også ansvar som designer og valgte en teamleder, der havde god erfaring med app-udvikling; tre programmører blev sat under ham, og to andre blev testere. Selvfølgelig blev programmeringssproget valgt ud fra færdighederne. Det blev besluttet at bruge Java, da alle programmører var bekendt med det.

Vi fastsætter opgaver

Efter anbefaling fra læreren blev der oprettet et opgaveliste på en gratis tjeneste. Trello. Det var planlagt at arbejde efter Scrum-systemet, hvor hver sprint ville repræsentere en afsluttet applikation.
Men i praksis blev det hele til én stor og lang sprint, hvor der konstant blev lavet ændringer, tilføjelser og rettelser.

Hvordan vi prøvede teamarbejde, og hvad der kom ud af det

Vi skriver specifikationer

Under indflydelse af Savins bog «Testing.com» havde jeg en klar forestilling om, hvordan alt skulle være. Det hele begyndte med at skrive specifikationer, for uden en klar beskrivelse af, hvad vi forventer, hvordan det skal fungere, vil intet fungere. Programmører vil kode det, som de ser det, testere vil teste noget andet, og lederen vil forvente noget tredje, men resultatet vil altid være noget fjerde.
Det er ikke nemt at skrive specifikationer; man skal overveje alle detaljer og nuancer. Selvfølgelig lykkedes det ikke i første forsøg. I sidste ende blev specifikationerne revideret og ændret fire gange. Den sidste version kan du finde i slutningen af artiklen, i afsnittet med links.

Vi tegner design

Designet i mobilapplikationen er det vigtigste. Ikke alle forstår dette, inklusive mange fra mit team, som ivrigt har diskuteret med mig om, at design ikke er nødvendigt, at det er den mindst vigtige del af applikationen osv. Man skal ikke være så naiv. For det første er et færdigt design en lettelse for programmørens arbejde; han behøver ikke at tænke over, hvad han skal putte hvor, han tager bare og kodning det, der er tegnet. Sammen med specifikationerne frigør designet næsten helt programmørens sind fra unødvendige ting og giver ham mulighed for at fokusere på logikken. Generelt blev en prototype (horribelt) designet først:

Hvordan vi prøvede teamarbejde, og hvad der kom ud af det

Men derefter blev designet trimmet og bragt i orden.
(Link til alle designelementer i slutningen af artiklen).

Hvordan vi prøvede teamarbejde, og hvad der kom ud af det

Programmering

Det er svært at programmere, men muligt. Jeg vil springe over dette punkt, da jeg personligt ikke har beskæftiget mig med det. Programmørerne har gjort et stort stykke arbejde, uden hvilket alt ville være meningsløst. Selvfølgelig lykkedes det at realisere nogle af idéerne. Og programmet har stadig brug for forbedringer. Der er mange fejl og funktioner, der skal fjernes. Havde vi haft mere tid, ville vi være ude af dyb alfa, men indtil videre kan du teste applikationen i slutningen af artiklen.

Og om testning

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ødvendig. Til mine testere tilbød jeg en testningsmodel ved brug af test cases. Først skrives test cases i fuld overensstemmelse med specifikationerne, og derefter udføres testningen baseret på dem. Hvad der kom ud af det, kan du se nedenfor i links.

Tak fordi du læste. Jeg håber, du fandt noget nyttigt her, måske en idé til dit eget startup, eller måske et godt råd eller et værktøj.