{"id":34112,"date":"2019-10-31T21:56:27","date_gmt":"2019-10-31T18:56:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-pytalis-v-komandnuyu-rabotu-i-chto-iz-etogo-vyshlo\/"},"modified":"2019-10-31T21:56:27","modified_gmt":"2019-10-31T18:56:27","slug":"kak-my-pytalis-v-komandnuyu-rabotu-i-chto-iz-etogo-vyshlo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/kak-my-pytalis-v-komandnuyu-rabotu-i-chto-iz-etogo-vyshlo","title":{"rendered":"Hoe we probeerden samen te werken en wat daaruit voortkwam","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hoe
\n<\/p>\n

Laten we stap voor stap doorgaan<\/h3>\n

\nWat deze afbeelding betekent, komen we later op terug, maar laten we nu beginnen met de inleiding.<\/p>\n

Op een koude febrari-dag leek er niets aan de hand. Een groep onschuldige studenten kwam voor het eerst naar de les van een vak dat ze 'Methodologie van de organisatie van het ontwerp en de ontwikkeling van informatiesystemen' hadden genoemd. Het was een gewone lezing, de docent sprak over flexibele ontwikkelingsmethodes zoals scrum, en er leek niets aan de hand. En toen, aan het einde, kondigde de docent aan: <\/p>\n

Ik wil dat jullie zelf alle moeilijkheden van teamwork ervaren, deel je op in groepen, bedenk een project, wijs een leider aan en doorloop samen alle fasen van het ontwerp. Aan het einde verwacht ik een eindproduct van jullie en een artikel op Habr.<\/p><\/blockquote>\n

Hier begint ons verhaal. <\/a><\/noindex> Als biljartballen stuiterden we van elkaar af totdat de energie van de impact wegebde en we samen een groepje van 7 mensen vormden. Misschien is dit voor een schoolproject te veel, maar om de rollen beter te verdelen is het perfect. De discussie over projectidee\u00ebn begon van 'Laten we een bestaand project nemen' tot 'Een emulator voor de creatie van ruimte-objecten'. Maar uiteindelijk kwam het idee naar voren, de naam waarvan je op de eerste afbeelding kunt lezen. <\/p>\n

Stop Procrastination \u2014 wat is dat, hoe werkt het en hoe hebben we het ontwikkeld en wat is het resultaat?<\/h2>\n

\nHet verhaal zal worden verteld vanuit het perspectief van de projectleider, die mij gelukkig of helaas is aangesteld. Wat voor idee kwam er bij ons op? Ge\u00efnspireerd door de populaire wekker 'Shake Alarm' van SupperCommon, met name de functie om de smartphone volledig te blokkeren totdat de gebruiker een bepaalde actie uitvoert, die hem hoogstwaarschijnlijk wakker zal maken, hebben wij besloten een soortgelijke applicatie te cre\u00ebren die helpt om van smartphone-verslaving af te komen, op dezelfde manier als 'Shake Alarm'.<\/p>\n

Werking principe<\/h3>\n

De gebruiker stelt timers in
\n- Tijd die je met je smartphone kunt doorbrengen
\n- Tijd zonder smartphone (blokkadeperiode)
\nBij het verstrijken van de timer verschijnt er een overlay op het scherm die niet kan worden gesloten
\n- Om de overlay te sluiten moet je een kleine uitdaging aangaan (een wachtwoord invoeren op een ingewikkeld toetsenbord, een wiskundig probleem oplossen, de telefoon een paar minuten schudden)
\nNa deze ontgrendeling wordt de tijd die je met de smartphone kunt doorbrengen gehalveerd, en dit tot \u00e9\u00e9n minuut.\n<\/p><\/blockquote>\n

We bouwen een team<\/h3>\n

Allereerst moest worden bepaald wie wat zou doen en in welke programmeertaal alles geschreven zou worden. Ik denk dat dit weinig te maken heeft met projectmanagement, want wanneer je een team samenstelt voor een echt project, haal je meteen de mensen erbij die je nodig hebt. Uiteindelijk nam ik ook de rol van ontwerper op me, en koos ik een teamleider met goede ervaring in app-ontwikkeling, aan wie drie programmeurs ondergeschikt werden gemaakt, en nog eens twee werden testers. Uiteraard werd de programmeertaal gekozen op basis van vaardigheden. Uiteindelijk werd besloten om Java te gebruiken, aangezien alle programmeurs hiermee bekend waren.<\/p>\n

We stellen taken op<\/h3>\n

Op aanbeveling van de docent werd er een takenbord gemaakt op een gratis service. Trello<\/a><\/noindex>. Er was gepland om volgens het Scrum-systeem te werken, waarbij elke stream een soort afgeronde applicatie zou zijn.
\nMaar in werkelijkheid resulteerde dit in \u00e9\u00e9n grote en lange stream, waarin voortdurend wijzigingen, aanvullingen en correcties werden aangebracht. <\/p>\n

\"Hoe
\n<\/p>\n

We schrijven specificaties<\/h3>\n

Onder invloed van het boek van Savin \"Testing.com\" had ik mijn eigen idee van hoe alles georganiseerd moest zijn. Het begon met het schrijven van specificaties, want zonder een duidelijke beschrijving van wat we verwachten, hoe het moet werken, zal er niets functioneren. Programmeurs zullen alles programmeren zoals zij dat zien, testers zullen iets anders testen, de leidinggevende verwacht iets derde, en het resultaat zal zoals altijd de vierde zijn.
\nSpecificaties schrijven is niet makkelijk, je moet alle details en nuances overdenken. Natuurlijk lukte het niet de eerste keer. Uiteindelijk werden de specificaties vier keer aangepast en herschreven. De laatste versie kun je aan het einde van het artikel vinden, in de sectie links. <\/p>\n

We tekenen het ontwerp<\/h3>\n

Het ontwerp in een mobiele applicatie is het belangrijkst. Niet iedereen begrijpt dat, ook niet veel leden van mijn team die fel met mij in discussie gingen dat ontwerp niet nodig is, dat het de minst belangrijke deel van de applicatie is, enzovoort. Wees niet zo na\u00efef. Ten eerste is een afgerond ontwerp een verlichting voor de programmeur, hij hoeft niet na te denken over wat waar en hoe moet worden geplaatst, hij neemt gewoon en zet neer wat er is getekend. Samen met de specificaties bevrijdt het ontwerp de geest van de programmeur bijna volledig van onnodige zaken, en geeft het hem de mogelijkheid om zich op de logica te concentreren. Over het algemeen was er eerst een prototype (vreselijk) ontwerp getekend:<\/p>\n

\"Hoe
\n
\nMaar later is het ontwerp ge\u00ebgaliseerd en naar een normaal niveau gebracht.
\n(Link naar alle ontwerpelementen aan het einde van het artikel).<\/p>\n

\"Hoe
\n<\/p>\n

Programmeren<\/h3>\n

Programmeren is moeilijk, maar mogelijk. Ik laat dit moment buiten beschouwing, omdat ik hier persoonlijk niet mee bezig ben geweest. De programmeurs hebben enorm veel werk verzet, zonder welke alles zinloos zou zijn geweest. Natuurlijk is het gelukt om een deel van de plannen te realiseren. De applicatie moet nog verder worden verbeterd. Er zijn veel bugs en functies die moeten worden verwijderd. Had ik maar meer tijd, dan zouden we uit de diepe alfa komen, maar voorlopig kunt u de applicatie aan het einde van het artikel testen.<\/p>\n

En over testen<\/h3>\n

Wat is het belangrijkste in programmeren? Naar mijn mening is het belangrijkste dat alles werkt en er uitziet zoals het moet. Hoe het moet is niet altijd en niet meteen het geval. Hiervoor is testen nodig. Aan mijn testers heb ik een testmodel aangeboden met gebruik van testcases. Eerst worden testcases geschreven in volledige overeenstemming met de specificaties, en vervolgens wordt de test uitgevoerd op basis daarvan. Wat hieruit is voortgekomen kunt u hieronder in de links bekijken. <\/p>\n

Bedankt voor het lezen. Hopelijk hebt u hier iets nuttigs gevonden, misschien een idee voor uw startup, of misschien een goed advies of een hulpmiddel.<\/p>\n

Links:<\/h3>\n

Laatste de specificatie<\/a><\/noindex>.
\nOntwerp in Figma<\/a><\/noindex>.
\nTestcases<\/a><\/noindex> en bugrapporten<\/a><\/noindex>.<\/p>\n

De applicatie zelf op HokeyApp<\/a><\/noindex>. \u2014 De applicatie werd gebouwd onder de naam HandsOff, vraag niet waarom (omdat Stop Procrastination te lang is).<\/p>\n

En tot slot<\/h3>\n

Wat denkt u, had dit alles zin?<\/p>\n

Alleen geregistreerde gebruikers kunnen deelnemen aan de enqu\u00eate. Log in<\/a><\/noindex>, alstublieft.<\/p>\n

Is zo'n praktijk nodig in onderwijsinstellingen en hoe nuttig en toepasbaar is het in het echte leven?<\/h2>\n