Hoe we teamwerk probeerden en wat daaruit voortkwam

Laten we beginnen op volgorde

Wat betekent deze foto straks, maar laat ik voor nu beginnen met de introductie.

Op een koude februaridag waren er geen tekenen van problemen. Een groep onschuldige studenten kwam voor de eerste keer een les volgen over een onderwerp dat zij ‘Methodologie voor het organiseren van het ontwerp en de ontwikkeling van informatiesystemen’ noemden. Er was regelmatig een lezing, de leraar sprak over flexibele ontwikkelmethoden, zoals Scrum, niets voorafschaduwde problemen. En aan het einde kondigt de leraar aan:

Ik wil dat je zelf alle ontberingen van teamwerk ervaart, je in groepen verdeelt, een project bedenkt, een leider aanstelt en samen alle ontwerpfasen doorloopt. Aan het einde verwacht ik van u een eindproduct en een artikel over Habré.

Dit is waar ons verhaal begint. Als ballen in een biljart stuiterden we tegen elkaar totdat de energie van de impact verdween en een groep van zeven mensen zich verzamelde. Misschien is dit te veel voor een trainingsproject, maar het is juist goed om de rollen beter te verdelen. Er begon een discussie over ideeën voor het project, van ‘Laten we een kant-en-klaar project nemen’ tot ‘Emulator voor de vorming van ruimtevoorwerpen’. Maar uiteindelijk kwam het idee uit, waarvan je de naam op de eerste foto leest.

Stop uitstelgedrag - wat het is, waarmee het wordt gegeten en hoe we het hebben ontwikkeld en wat er van is gekomen

Het verhaal wordt verteld namens de projectmanager, die gelukkig of helaas aan mij werd toegewezen. Welk idee kwam er dan in ons op? Geïnspireerd door de populaire wekker "Shake Alarm Clock" van SupperCommon, namelijk de functie om de smartphone volledig te blokkeren totdat de gebruiker een bepaalde actie uitvoert waardoor hij hoogstwaarschijnlijk wakker wordt, hebben we besloten een soortgelijke applicatie te maken die zal helpen van telefoonverslaving af, volgens hetzelfde principe als "Shake the Alarm Clock"

Werking

Gebruiker stelt timers in
-Tijd die op een smartphone kan worden besteed
-Tijd zonder smartphone (blokkeerperiode)
Wanneer de timer afloopt, verschijnt er een overlay op het scherm die niet kan worden geminimaliseerd
-Om de overlay te sluiten, moet je een kleine test doorlopen (voer een wachtwoord in op een verwarrend toetsenbord, los een wiskundeprobleem op, schud de telefoon een paar minuten)
Na het op deze manier ontgrendelen wordt de tijd die op de smartphone kan worden doorgebracht gehalveerd, enzovoorts tot een minuut.

Een team opbouwen

Eerst moest worden bepaald wie wat zou doen en in welke taal dit allemaal zou worden geschreven. Ik denk dat dit weinig met projectmanagement te maken heeft, want als je voor een echt project een team samenstelt, verzamel je meteen de mensen die je nodig hebt. Als gevolg hiervan nam ik ook de last van een ontwerper op me, koos een teammanager die goede ervaring had met applicatieontwikkeling, drie programmeurs werden aan hem toegewezen en nog twee werden testers. Uiteraard werd de programmeertaal gekozen op basis van vaardigheden. Als gevolg hiervan werd besloten om Java te gebruiken, omdat alle programmeurs er bekend mee waren.

Taken instellen

Op aanbeveling van de docent is er een taakbord gemaakt voor een gratis dienst Trello. Het was de bedoeling om volgens het Scrum-systeem te werken, waarbij elke stream een ​​soort complete applicatie zou zijn.
In werkelijkheid kwam dit echter allemaal voort uit één grote en lange stroom, waarin voortdurend bewerkingen, toevoegingen en correcties werden aangebracht.

Wij schrijven specificaties

Onder invloed van Savins boek ‘Testing.com’ had ik mijn eigen idee in mijn hoofd hoe alles geregeld moest worden. Het begon allemaal met het schrijven van specificaties, want ik geloof dat zonder een duidelijke beschrijving van wat we verwachten, wat en hoe het zou moeten werken, niets zal werken. De programmeurs zullen alles programmeren zoals zij het zien, de testers zullen iets anders testen, de manager verwachtte de derde, maar het zal zoals altijd de vierde blijken te zijn.
Het schrijven van specificaties is niet eenvoudig, je moet over alle details en alle nuances nadenken. Natuurlijk werkte niets de eerste keer. Hierdoor zijn de specificaties 4 keer aangevuld en vernieuwd. De laatste optie vindt u aan het einde van het artikel, in de sectie links.

Een ontwerp tekenen

Design in een mobiele applicatie is het allerbelangrijkste. Niet iedereen begrijpt dit echter, ook mijn team heeft velen heftig met mij betoogd dat design niet nodig is, dat dit het meest onbelangrijke deel van de applicatie is, enz. Je moet niet zo naïef zijn. Ten eerste maakt een kant-en-klaar ontwerp het werk van de programmeur gemakkelijker; hij hoeft niet na te denken over wat hij waar en waar moet zetten, hij pakt en typt gewoon wat er getekend wordt. Samen met de specificaties bevrijdt het ontwerp de geest van de programmeur vrijwel volledig van onnodige dingen en geeft hem de mogelijkheid om zich op logica te concentreren. Over het algemeen werd eerst een prototype (verschrikkelijk) ontwerp getekend:

Maar toen werd het ontwerp uitgekamd en weer normaal gemaakt.
(Link naar alle ontwerpelementen aan het einde van het artikel).

Programmering

Programmeren is moeilijk, maar mogelijk. Ik laat dit punt achterwege, aangezien ik dit zelf niet persoonlijk heb behandeld. De programmeurs hebben enorm veel werk verricht, zonder welke alles zinloos zou zijn geweest. Natuurlijk zijn we erin geslaagd een aantal van onze ideeën te realiseren. En het programma behoeft nog steeds verbetering. Er zijn veel bugs en functies die moeten worden verwijderd. Als we meer tijd hadden, zouden we uit de diepe alfa komen, maar voorlopig kun je de applicatie aan het einde van het artikel testen.

Nou ja, over testen

Wat is het belangrijkste bij programmeren? Naar mijn mening is het belangrijkste dat alles werkt en eruit ziet zoals het hoort. Het lukt niet altijd goed en niet meteen. Dit vereist testen. Aan mijn testers heb ik een testmodel voorgesteld met behulp van testgevallen. Eerst worden testgevallen volledig volgens de specificaties geschreven en vervolgens worden er tests op uitgevoerd. Via onderstaande links kunt u zien wat hieruit voortkwam.

Bedankt voor het lezen. Ik hoop dat je hier op zijn minst iets nuttigs hebt gevonden, misschien een idee voor je startup, of misschien een goed advies of een hulpmiddel.

referenties:

Laatst specificaties.
Ontwerp aan Figma.
Testgevallen и foutmeldingen.

De applicatie zelf staat aan HokeyApp. — De applicatie is gebouwd onder de naam HandsOff, vraag niet eens waarom (want Stop Uitstel is te lang).

Nou ja, aan het einde

Denk je dat dit allemaal logisch was?

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Is een dergelijke praktijk noodzakelijk in onderwijsinstellingen en hoe nuttig en toepasbaar is deze in het echte leven?

• Noodzakelijke, onschatbare ervaring

• Nodig, hoewel een beetje ervaring

• Bijna nutteloos, je begrijpt hoogstens de algemene kenmerken van het werken in teamverband

• Zonde van tijd en moeite

2 gebruikers hebben gestemd. Er zijn geen onthoudingen.

Bron: www.habr.com