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.
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
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.
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:
Men så blev designet finkæmmet og bragt tilbage til det normale.
(Link til alle designelementer i slutningen af artiklen).
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
Design på
Selve applikationen er tændt
Nå til sidst
Synes du, at det hele gav mening?
Kun registrerede brugere kan deltage i undersøgelsen.
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