Cum am încercat munca în echipă și ce a rezultat

Cum am încercat munca în echipă și ce a rezultat

Să o luăm în ordine

Ce înseamnă această imagine un pic mai târziu, dar deocamdată permiteți-mi să încep cu introducerea.

Într-o zi rece de februarie nu erau semne de necaz. Un grup de studenți nevinovați a venit pentru prima dată să ia o clasă pe un subiect pe care au decis să îl numească „Metodologie de organizare a proiectării și dezvoltării sistemelor informaționale”. A fost o prelegere regulată, profesorul a vorbit despre metode de dezvoltare flexibile, precum Scrum, nimic nu prefigura probleme. Și la sfârșit profesorul anunță:

Vreau să experimentați singuri toate greutățile muncii în echipă, să vă împărțiți în grupuri, să veniți cu un proiect, să numiți un lider și să treceți împreună prin toate etapele de proiectare. La final, aștept de la tine un produs finit și un articol despre Habré.

Aici începe povestea noastră. Ca mingile la biliard, am sărit unul pe altul până când energia impactului s-a disipat și s-a adunat un grup de 7 persoane. Poate că acest lucru este prea mult pentru un proiect de formare, dar este corect să distribuim mai bine rolurile. A început o discuție despre idei pentru proiect, de la „Să luăm un proiect gata făcut” la „Emulator pentru formarea obiectelor spațiale”. Dar până la urmă a venit ideea, al cărei nume îl citiți în prima poză.

Opriți procrastinarea - ce este, cu ce se mănâncă și cum l-am dezvoltat și ce a rezultat din ea

Povestea va fi spusă în numele managerului de proiect, care, din fericire sau din păcate, mi-a fost repartizat. Deci ce idee ne-a venit în minte? Inspirați de popularul ceas deșteptător „Shake Alarm Clock” de la SupperCommon, și anume funcția de blocare completă a smartphone-ului până când utilizatorul efectuează o anumită acțiune care cel mai probabil îl va face să se trezească, am decis să creăm o aplicație similară care să ajute la obținerea scăpa de dependența de telefon, pe același principiu ca „Shake the Alarm Clock”

Principiul de funcționare

Utilizatorul setează cronometre
-Timp care poate fi petrecut pe un smartphone
-Timp fără smartphone (perioada de blocare)
Când cronometrul expiră, pe ecran apare o suprapunere care nu poate fi minimizată
-Pentru a închide suprapunerea, trebuie să treceți printr-un mic test (introduceți o parolă pe o tastatură confuză, rezolvați o problemă de matematică, agitați telefonul pentru câteva minute)
După deblocare în acest fel, timpul care poate fi petrecut pe smartphone se înjumătățește și așa mai departe până la un minut.

Construirea unei echipe

În primul rând, a fost necesar să se stabilească cine va face ce și în ce limbă vor fi scrise toate acestea. Cred că asta nu are nimic de-a face cu managementul de proiect, pentru că atunci când aduni o echipă pentru un proiect real, îi aduni imediat pe cei de care ai nevoie. Drept urmare, mi-am asumat și sarcina unui designer, am ales un manager de echipă care avea o experiență bună în dezvoltarea de aplicații, i-au fost repartizați trei programatori și încă doi au devenit testeri. Desigur, limbajul de programare a fost ales pe baza competențelor. Ca urmare, s-a decis să se folosească Java, deoarece toți programatorii erau familiarizați cu acesta.

Stabilirea sarcinilor

La recomandarea profesorului, a fost creat un task board pe un serviciu gratuit Trello. Era planificat să funcționeze conform sistemului Scrum, unde fiecare flux ar fi un fel de aplicație completă.
Cu toate acestea, în realitate, toate acestea au ieșit dintr-un flux mare și lung, la care s-au făcut în mod constant editări, completări și corecții.

Cum am încercat munca în echipă și ce a rezultat

Scriem specificații

Influențat de cartea lui Savin „Testing.com”, aveam propria mea idee în cap despre cum ar trebui aranjat totul. Totul a început cu scrierea specificațiilor, după cum cred, fără o descriere clară a ceea ce ne 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, managerul se aștepta pe al treilea, dar se va dovedi a fi al patrulea ca întotdeauna.
Scrierea specificațiilor nu este ușoară, trebuie să te gândești la toate detaliile, la toate nuanțele. Desigur, nimic nu a funcționat prima dată. Ca urmare, specificațiile au fost completate și refăcute de 4 ori. Ultima opțiune o găsiți la sfârșitul articolului, în secțiunea de link-uri.

Desenarea unui design

Designul într-o aplicație mobilă este cel mai important lucru. Cu toate acestea, nu toată lumea înțelege acest lucru, inclusiv din partea echipei mele, mulți au argumentat vehement cu mine că designul nu este necesar, că aceasta este cea mai neimportantă parte a aplicației etc. Nu ar trebui să fii atât de naiv. În primul rând, un design gata făcut ușurează munca programatorului; el nu trebuie să se gândească la ce să pună unde și unde, ci doar ia și tipează ceea ce este desenat. Împreună cu specificațiile, designul eliberează aproape complet mintea programatorului de lucruri inutile și îi oferă posibilitatea de a se concentra pe logică. În general, a fost desenat mai întâi un prototip (îngrozitor):

Cum am încercat munca în echipă și ce a rezultat

Dar apoi designul a fost pieptănat și readus la normal.
(Link către toate elementele de design la sfârșitul articolului).

Cum am încercat munca în echipă și ce a rezultat

Programare

Programarea este dificilă, dar posibilă. Voi omite acest punct, deoarece nu m-am ocupat personal de asta. Programatorii au muncit enorm, fără de care totul ar fi fost lipsit de sens. Desigur, am reușit să realizăm câteva dintre ideile noastre. Și programul încă mai are nevoie de îmbunătățiri. Există o mulțime de erori și caracteristici care trebuie eliminate. Dacă am avea mai mult timp, am ieși din deep alpha, dar deocamdată poți testa aplicația la sfârșitul articolului.

Ei bine, despre testare

Care este principalul lucru în programare? În opinia mea, principalul lucru este că totul funcționează și arată așa cum ar trebui. Nu merge întotdeauna corect și nu imediat. Acest lucru necesită testare. Testerilor mei, le-am propus un model de testare folosind cazuri de testare. În primul rând, cazurile de testare sunt scrise în deplină conformitate cu specificațiile, apoi se efectuează testarea pe ele. Puteți vedea ce a ieșit din asta în linkurile de mai jos.

Multumesc pentru lectura. Sper că ați găsit măcar ceva util aici, poate o idee pentru startup-ul dvs. sau poate un sfat bun sau un instrument.

referințe:

Ultimele specificații.
Proiectare pe figma.
Cazuri de testare и rapoarte de erori.

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

Ei bine, la final

Crezi că toate acestea au sens?

Numai utilizatorii înregistrați pot participa la sondaj. Loghează-te, Vă rog.

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

  • Experiență necesară, neprețuită

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

  • Aproape inutil, cel mult vei înțelege caracteristicile generale ale lucrului în echipă

  • O pierdere de timp și efort

Au votat 2 utilizatori. Nu există abțineri.

Sursa: www.habr.com

Adauga un comentariu