Cum am încercat să colaborăm în echipă și ce a ieșit

Cum am încercat să colaborăm în echipă și ce a ieșit

Să o luăm pe rând

Ce înseamnă acest desen, vom discuta mai târziu, dar acum lăsați-mă să încep cu o introducere.

Într-o zi rece de februarie, nimic nu prezicea ghinionul. Un grup de studenți nevinovați s-a prezentat pentru prima dată la o lecție la un curs pe care au decis să-l numească „Metodologia organizării proiectării și dezvoltării sistemelor informatice”. A fost o lecție obișnuită, profesorul vorbea despre metodele agile de dezvoltare, cum ar fi Scrum, nimic nu prezicea ghinionul. Și iată că spre sfârșitul cursului, profesorul anunță:

Vreau să simțiți toate dificultățile muncii în echipă, să vă împărțiți în grupuri, să veniți cu un proiect, să desemnați un lider și să parcurgeți împreună toate etapele de proiectare. La final, aștept de la voi un produs gata și un articol pe Habr.

Aici începe povestea noastră. Ca bilele de biliard, am sărit unii de alții până când energia loviturii s-a dispersat și am format împreună un grup de 7 persoane. Poate că pentru un proiect școlesc este prea mult, dar pentru a distribui mai bine rolurile, a fost chiar bine. A început discuția despre idei pentru proiect, de la „Hai să luam un proiect gata” până la „Emulator pentru formarea obiectelor cosmice”. Dar, în cele din urmă, a învins ideea al cărei nume l-ați citit în prima imagine.

Stop Procrastination — ce este, cu ce se mănâncă și cum l-am dezvoltat și ce a ieșit

Povestea va fi spusă din perspectiva liderului de proiect, pe care, din fericire sau din păcate, m-au desemnat. Așadar, ce idee ne-a venit în minte? Inspirându-ne din popularul alarme „Shake Alarm” de la SupperCommon, și anume din funcția de a bloca complet funcționarea smartphone-ului până când utilizatorul nu îndeplinește o anumită acțiune, care cel mai probabil îl va determina să se trezească, am decis să creăm o aplicație similară care va ajuta la dependența de telefon, pe același principiu ca „Shake Alarm”.

Principiul de funcționare

Utilizatorul setează temporizatoare
- Timpul petrecut pe smartphone
- Timpul fără smartphone (perioada de blocare)
După expirarea temporizatorului, pe ecran apare un overlay care nu poate fi înlăturat
-Pentru a închide overlay-ul, trebuie să treci printr-un mic test (să introduci parola pe o tastatură complicată, să rezolvi o problemă matematică, să zgudui telefonul câteva minute).
După deblocarea prin această metodă, timpul petrecut pe smartphone se reduce la jumătate, și așa mai departe, până la un minut.

Construim echipa.

La început, a trebuit să stabilim cine se va ocupa de ce și în ce limbă va fi scris totul. Cred că asta are puțin de-a face cu managementul de proiecte, deoarece atunci când formezi o echipă pentru un proiect real, iei imediat pe cei de care ai nevoie. În cele din urmă, am luat și sarcina de designer, am ales un team lead care avea experiență bună în dezvoltarea aplicațiilor, iar în subordinea lui au fost desemnați trei programatori, iar alții doi au devenit testeri. Desigur, limbajul de programare a fost ales în funcție de abilități. În cele din urmă, am decis să folosim Java, deoarece toți programatorii erau familiarizați cu el.

Stabilim sarcinile.

La recomandarea profesorului, a fost creat un board de sarcini pe un serviciu gratuit. Trello. Era planificat să lucrăm pe baza sistemului Scrum, unde fiecare stream ar reprezenta o aplicație finalizată.
Cu toate acestea, în realitate, totul a culminat într-un singur stream mare și lung, în care au fost făcute constant modificări, adăugiri și corecturi.

Cum am încercat să colaborăm în echipă și ce a ieșit

Scriem specificațiile.

Sub influența cărții lui Savin «Testarea.com», aveam o viziune despre cum ar trebui să fie organizat totul. Totul a început cu scrierea specificațiilor, deoarece consider că fără o descriere clară a ceea ce așteptăm, ce și cum ar trebui să funcționeze, nimic nu va funcționa. Programatorii vor programa totul așa cum văd ei, testerii vor testa altceva, iar managerul va aștepta un alt rezultat, dar se va obține, ca întotdeauna, un altul decât cel dorit.
A scrie specificații nu este ușor, trebuie să te gândești la toate detaliile, toate nuanțele. Desigur, din prima dată nu a ieșit nimic. În cele din urmă, specificațiile au fost completate și refăcute de patru ori. Ultima variantă o poți găsi la sfârșitul articolului, în secțiunea linkuri.

Desenăm designul.

Designul într-o aplicație mobilă este cel mai important. Totuși, nu toată lumea înțelege acest lucru, inclusiv mulți membri din echipa mea au contestat cu vehemență faptul că designul nu este necesar, că este cea mai puțin importantă parte a aplicației etc. Nu trebuie să fii atât de naiv. În primul rând, designul final este o ușurare pentru programator, nu trebuie să se gândească la ce, unde și cum să plaseze elementele, pur și simplu ia și creează ceea ce a fost desenat. Împreună cu specificațiile, designul eliberează aproape complet mintea programatorului de lucruri inutile și îi oferă posibilitatea să se concentreze asupra logicii. În general, mai întâi a fost desenat un design prototip (îngrozitor):

Cum am încercat să colaborăm în echipă și ce a ieșit

Dar apoi designul a fost îmbunătățit și adus la un aspect normal.
(Linkul către toate elementele de design la finalul articolului).

Cum am încercat să colaborăm în echipă și ce a ieșit

Programare

Programarea este dificilă, dar realizabilă. Voi omite acest moment, deoarece eu personal nu m-am ocupat de asta. Programatorii au realizat o muncă imensă, fără de care totul ar fi fost fără sens. Desigur, am reușit să implementăm o parte din idei. Și programul mai are nevoie de lucru. Există multe bug-uri și funcții care trebuie eliminate. Dacă am fi avut mai mult timp, am fi ieșit dintr-o adâncă fază alfa, dar până atunci puteți testa aplicația la finalul articolului.

Și despre testare

Ce este cel mai important în programare? Din punctul meu de vedere, cel mai important este ca totul să funcționeze și să arate așa cum trebuie. Cum trebuie nu iese întotdeauna și nu imediat. Pentru aceasta este necesară testarea. Tinerilor mei testeri le-am propus un model de testare folosind case de testare. Mai întâi se scriu cazuri de testare în conformitate cu specificațiile, iar apoi se efectuează testarea pe baza acestora. Ce a rezultat din asta puteți vedea mai jos în linkuri.

Vă mulțumesc că ați citit. Sper că ați găsit aici măcar ceva util, poate o idee pentru startup-ul vostru, sau poate un bun sfat sau instrument.

Linkuri:

Cele mai recente specificații.
Design pe Figma.
Cazuri de testare și rapoarte de bug-uri.

Aplicația în sine este pe HokeyApp. — Aplicația a fost construită sub numele HandsOff, să nu mă întrebați de ce (pentru că Stop Procrastination este prea lung).

Și, în final,

Credeți că a avut sens totul acesta?

Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.

Este necesară o astfel de practică în instituțiile de învățământ și cât de utilă și aplicabilă este în viața reală

  • Necesare, o experiență neprețuită

  • Necesară, deși puțină experiență

  • Aproape inutilă, cel mult înțelegi trăsăturile generale ale muncii în echipă

  • O pierdere de timp și efort

Au votat 2 utilizatori. Nu sunt abțineri.

Sursa: habr.com

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster