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

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

Lad os starte i orden

Hvad betyder dette billede lidt senere, men lad mig nu starte med introduktionen.

På en kold februardag var der ingen tegn på problemer. En gruppe uskyldige studerende kom for første gang for at tage en klasse om et emne, som de besluttede at kalde "Metode til at organisere design og udvikling af informationssystemer." Der var jævnligt foredrag, læreren talte om fleksible udviklingsmetoder som Scrum, intet varslede ballade. Og til sidst meddeler læreren:

Jeg ønsker, at du selv skal opleve alle strabadserne ved teamwork, dele dig i grupper, komme med et projekt, udpege en leder og gennemgå alle designstadier sammen. Til sidst forventer jeg af dig et færdigt produkt og en artikel om Habré.

Det er her vores historie begynder. Som bolde i billard hoppede vi af hinanden, indtil energien fra stødet forsvandt, og en gruppe på 7 personer samledes. Måske er det for meget for et træningsprojekt, men det er helt rigtigt at fordele rollerne bedre. En diskussion af ideer til projektet begyndte, fra "Lad os tage et færdiglavet projekt" til "Emulator til dannelse af rumobjekter." Men til sidst kom ideen igennem, hvis navn du læste på det første billede.

Stop Procrastination – hvad det er, hvad det spises med og hvordan vi udviklede det og hvad kom der ud af det

Historien vil blive fortalt på vegne af projektlederen, som heldigvis eller desværre fik tildelt mig. Så hvilken idé kom til vores sind? Inspireret af det populære "Shake Alarm Clock" vækkeur fra SupperCommon, nemlig funktionen med at blokere smartphonen fuldstændigt, indtil brugeren udfører en bestemt handling, der højst sandsynligt vil få ham til at vågne, besluttede vi at lave en lignende applikation, der vil hjælpe med at få slippe af med telefonafhængighed efter samme princip som "Ryst vækkeuret"

Virkemåde

Brugeren indstiller timere
-Tid, der kan bruges på en smartphone
-Tid uden smartphone (blokeringsperiode)
Når timeren udløber, vises en overlejring på skærmen, som ikke kan minimeres
-For at lukke overlejringen skal du igennem en lille test (indtast en adgangskode på et forvirrende tastatur, løs et matematisk problem, ryst telefonen i et par minutter)
Efter oplåsning på denne måde halveres den tid, der kan bruges på smartphonen, og så videre op til et minut.

Opbygning af et hold

Først var det nødvendigt at bestemme, hvem der ville gøre hvad og på hvilket sprog alt dette ville blive skrevet. Jeg tror, ​​det har lidt med projektledelse at gøre, for når man samler et hold til et rigtigt projekt, samler man straks dem, man har brug for. Som følge heraf påtog jeg mig også byrden af ​​en designer, valgte en teamleder, der havde god erfaring med applikationsudvikling, tre programmører blev tildelt ham, og to mere blev testere. Selvfølgelig er programmeringssproget valgt ud fra færdigheder. Som et resultat blev det besluttet at bruge Java, da alle programmører var bekendt med det.

Indstilling af opgaver

Efter anbefaling fra læreren blev der lavet en opgavetavle på en gratis tjeneste Trello. Det var planlagt at arbejde efter Scrum-systemet, hvor hver stream skulle være en slags komplet applikation.
Men i virkeligheden kom alt dette ud af én stor og lang strøm, hvortil der hele tiden blev foretaget redigeringer, tilføjelser og rettelser.

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

Vi skriver specifikationer

Påvirket af Savins bog "Testing.com", havde jeg min egen idé i mit hoved om, hvordan alting skulle arrangeres. Det hele startede med at skrive specifikationer, da jeg tror, ​​uden en klar beskrivelse af, hvad vi forventer, hvad og hvordan det skal fungere, vil intet fungere. Programmørerne vil programmere alt, som de ser det, testerne vil teste noget andet, manageren forventede det tredje, men det vil vise sig at blive det fjerde som altid.
At skrive specifikationer er ikke let, du skal gennemtænke alle detaljerne, alle nuancerne. Selvfølgelig virkede intet første gang. Som følge heraf blev specifikationerne suppleret og lavet om 4 gange. Du kan finde den sidste mulighed i slutningen af ​​artiklen, i linksafsnittet.

Tegning af et design

Design i en mobilapplikation er det vigtigste. Det er dog ikke alle, der forstår dette, også fra mit hold, mange argumenterede heftigt med mig, at design ikke er nødvendigt, at dette er den mest uvigtige del af ansøgningen osv. Du skal ikke være så naiv. For det første gør et færdigt design programmørens arbejde lettere; han behøver ikke at tænke på, hvad han skal placere hvor og hvor, han tager og sætter bare det tegnede. Sammen med specifikationerne frigør designet næsten fuldstændig programmørens sind fra unødvendige ting, og giver ham mulighed for at koncentrere sig om logik. Generelt blev der først tegnet et prototype (frygteligt) design:

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

Men så blev designet finkæmmet og bragt tilbage til det normale.
(Link til alle designelementer i slutningen af ​​artiklen).

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

Programmering

Programmering er svært, men muligt. Jeg vil udelade dette punkt, da jeg ikke selv har beskæftiget mig med dette. Programmørerne gjorde en enorm mængde arbejde, uden hvilket alt ville have været meningsløst. Det lykkedes selvfølgelig at realisere nogle af vores ideer. Og programmet skal stadig forbedres. Der er mange fejl og funktioner, der skal fjernes. Hvis vi havde mere tid, ville vi komme ud af dyb alfa, men indtil videre kan du teste applikationen i slutningen af ​​artiklen.

Nå, om at teste

Hvad er det vigtigste i programmering? Efter min mening er hovedsagen, at alt fungerer og ser ud, som det skal. Det lykkes ikke altid rigtigt og ikke med det samme. Dette kræver test. Til mine testere foreslog jeg en testmodel ved hjælp af testcases. Først skrives testcases i fuld overensstemmelse med specifikationerne, og derefter udføres test på dem. Du kan se, hvad der kom ud af dette i nedenstående links.

Tak fordi du læste med. Jeg håber, at du i det mindste fandt noget brugbart her, måske en idé til din opstart, eller måske et godt råd eller et værktøj.

referencer:

Seneste specifikationer.
Design på figma.
Test cases и fejlrapporter.

Selve applikationen er tændt HokeyApp. — Applikationen blev bygget under navnet HandsOff, spørg ikke engang hvorfor (fordi Stop Procrastination er for lang).

Nå til sidst

Synes du, at det hele gav mening?

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Er en sådan praksis nødvendig i uddannelsesinstitutioner, og hvor nyttig og anvendelig er den i det virkelige liv?

  • Tiltrængt, uvurderlig erfaring

  • Tiltrængt, dog lidt erfaring

  • Næsten ubrugelig, du vil højst forstå de generelle træk ved at arbejde i et team

  • Spild af tid og kræfter

2 brugere stemte. Der er ingen undladelser.

Kilde: www.habr.com

Tilføj en kommentar