Hvordan vi prøvde å samarbeide og hva som kom ut av det

La oss starte i orden

Hva betyr dette bildet litt senere, men la meg foreløpig starte med introduksjonen.

På en kald februardag var det ingen tegn til problemer. En gruppe uskyldige studenter kom for første gang for å ta en klasse om et emne som de bestemte seg for å kalle "Metode for organisering av design og utvikling av informasjonssystemer." Det var vanlig forelesning, læreren snakket om fleksible utviklingsmetoder, som Scrum, ingenting varslet problemer. Og til slutt kunngjør læreren:

Jeg vil at du skal oppleve alle vanskelighetene med teamarbeid selv, dele inn i grupper, komme med et prosjekt, utnevne en leder og gå gjennom alle designstadiene sammen. Til slutt forventer jeg av deg et ferdig produkt og en artikkel om Habré.

Det er her historien vår begynner. Som baller i biljard spratt vi av hverandre til energien fra støtet forsvant og en gruppe på 7 personer samlet seg. Kanskje dette er for mye for et opplæringsprosjekt, men det er helt riktig å fordele rollene bedre. En diskusjon av ideer for prosjektet startet, fra "La oss ta et ferdig prosjekt" til "Emulator for dannelse av romobjekter." Men til slutt kom ideen frem, navnet som du leste på det første bildet.

Stopp utsettelse - hva det er, hva det spises med og hvordan vi utviklet det og hva kom ut av det

Historien vil bli fortalt på vegne av prosjektlederen, som heldigvis eller uheldigvis ble tildelt meg. Så hvilken idé kom til våre sinn? Inspirert av den populære "Shake Alarm Clock" vekkerklokken fra SupperCommon, nemlig funksjonen med å blokkere smarttelefonen helt til brukeren utfører en bestemt handling som mest sannsynlig vil få ham til å våkne, bestemte vi oss for å lage en lignende applikasjon som vil hjelpe kvitt telefonavhengighet, på samme prinsipp som "Rist vekkerklokken"

Prinsippet om drift

Brukeren setter tidtakere
-Tid som kan brukes på en smarttelefon
-Tid uten smarttelefon (sperreperiode)
Når tidtakeren utløper, vises et overlegg på skjermen som ikke kan minimeres
-For å lukke overlegget må du gå gjennom en liten test (skriv inn et passord på et forvirrende tastatur, løs et matematisk problem, rist telefonen i et par minutter)
Etter opplåsing på denne måten halveres tiden som kan brukes på smarttelefonen, og så videre opptil ett minutt.

Bygge et team

Først var det nødvendig å bestemme hvem som skulle gjøre hva og på hvilket språk alt dette skulle skrives. Jeg tror dette har lite med prosjektledelse å gjøre, for når du setter sammen et team for et ekte prosjekt, setter du umiddelbart sammen de du trenger. Som et resultat tok jeg også på meg byrden av en designer, valgte en teamleder som hadde god erfaring med applikasjonsutvikling, tre programmerere ble tildelt ham, og to til ble testere. Selvfølgelig ble programmeringsspråket valgt ut fra ferdigheter. Som et resultat ble det besluttet å bruke Java, siden alle programmerere var kjent med det.

Sette oppgaver

Etter anbefaling fra læreren ble det opprettet en oppgavetavle på en gratis tjeneste Trello. Det var planlagt å jobbe etter Scrum-systemet, hvor hver stream skulle være en slags komplett applikasjon.
Men i virkeligheten kom alt dette ut av en stor og lang strøm, som det stadig ble gjort redigeringer, tilføyelser og rettelser til.

Vi skriver spesifikasjoner

Påvirket av Savins bok "Testing.com", hadde jeg min egen idé i hodet mitt om hvordan alt skulle ordnes. Det hele startet med å skrive spesifikasjoner, som jeg tror, ​​uten en klar beskrivelse av hva vi forventer, hva og hvordan det skal fungere, vil ingenting fungere. Programmererne vil programmere alt slik de ser det, testerne vil teste noe annet, manageren ventet den tredje, men det vil vise seg å bli den fjerde som alltid.
Det er ikke lett å skrive spesifikasjoner, du må tenke gjennom alle detaljene, alle nyansene. Selvfølgelig fungerte ingenting første gang. Som et resultat ble spesifikasjonene supplert og gjort om 4 ganger. Du finner det siste alternativet på slutten av artikkelen, i lenkedelen.

Tegne et design

Design i en mobilapplikasjon er det viktigste. Imidlertid er det ikke alle som forstår dette, inkludert fra teamet mitt, mange argumenterte heftig med meg at design ikke er nødvendig, at dette er den mest uviktige delen av søknaden osv. Du burde ikke være så naiv. For det første gjør et ferdig design programmererens arbeid enklere; han trenger ikke tenke på hva han skal plassere hvor og hvor, han tar og setter inn det som er tegnet. Sammen med spesifikasjonene frigjør designet nesten fullstendig programmererens sinn fra unødvendige ting, og gir ham muligheten til å konsentrere seg om logikk. Generelt ble en prototype (forferdelig) design tegnet først:

Men så ble designet kammet og brakt tilbake til det normale.
(Link til alle designelementer på slutten av artikkelen).

Programmering

Programmering er vanskelig, men mulig. Jeg vil utelate dette punktet, siden jeg ikke personlig har forholdt meg til dette selv. Programmererne gjorde en enorm mengde arbeid, uten noe som alt ville vært meningsløst. Selvfølgelig klarte vi å realisere noen av ideene våre. Og programmet trenger fortsatt forbedring. Det er mange feil og funksjoner som må fjernes. Hvis vi hadde mer tid, ville vi komme ut av dyp alfa, men foreløpig kan du teste applikasjonen på slutten av artikkelen.

Vel, om testing

Hva er hovedsaken i programmering? Etter min mening er hovedsaken at alt fungerer og ser ut som det skal. Det fungerer ikke alltid rett og ikke med en gang. Dette krever testing. Til testerne mine foreslo jeg en testmodell ved bruk av testcases. Først skrives testtilfeller i full overensstemmelse med spesifikasjonene, og deretter utføres testing av dem. Du kan se hva som kom ut av dette i lenkene under.

Takk for at du leste. Jeg håper du fant i det minste noe nyttig her, kanskje en idé for oppstarten din, eller kanskje noen gode råd eller et verktøy.

referanser:

Siste spesifikasjoner.
Design på figma.
Testtilfeller и feilrapporter.

Selve applikasjonen er på HokeyApp. — Applikasjonen ble bygget under navnet HandsOff, ikke engang spør hvorfor (fordi Stop Procrastination er for lang).

Vel på slutten

Synes du alt dette ga mening?

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Er slik praksis nødvendig i utdanningsinstitusjoner og hvor nyttig og anvendelig er den i det virkelige liv?

• Nødvendig, uvurderlig erfaring

• Trengs, men litt erfaring

• Nesten ubrukelig, på det meste vil du forstå de generelle egenskapene ved å jobbe i et team

• En sløsing med tid og krefter

2 brukere stemte. Det er ingen avståelser.

Kilde: www.habr.com