🥇 Kuidas me proovisime meeskonnatööd ja mis sellest välja tuli

Kuidas me üritasime meeskonnatööd ja mis sellest välja tuli

Alustame järjekorras

Mis see joonis tähendama hakkab, selgub hiljem, aga lasege mul alustada sissejuhatusest.

Külmas veebruarikuises päevas ei olnud midagi, mis oleks kurja ennustanud. Rühm süüdistusteta tudengeid tuli esmakordselt loengule aine kohta, mida nad otsustasid nimetada "Info- ja arendussüsteemide projekteerimise ja arendamise metoodika". Oli tavaline loeng, õpetaja rääkis paindlike arendusmeetodite, nagu Scrum, kohta, mis ei tundunud ebanormaalsena. Ja siis õpetaja lõpetuseks kuulutas:

Soovin, et te kogeksite kõiki meeskonnatöö raskusi, jagungete rühmadesse, mõelgete välja projekt, määraksite juhataja ja läbiksite koos kõik projekteerimise etapid. Lõpus ootan teilt valmistoote ja artiklit Habr'isse.

Siit alustab meie lugu. Nagu biljardipallid põrkasime üksteisest eemale, kuni löögi energia hajus ja koos kogunes seitsme inimese grupp. Võib-olla on see õppeprojekti jaoks liiga palju, kuid parema rollijaotuse saavutamiseks on see täiesti sobiv. Alanud arutelu ideedest projektile liikudes "Võtame valmis projekti" kuni "Kosmoseobjektide moodustamise emulaator". Kuid lõpuks esitati idee, mille nime te lugesite esimeselt pildilt.

Lõpeta viivitamine — mis see on, millega seda süüakse ja kuidas me seda arendasime, ning mis sellest välja tuli

Lugu jutustatakse projekti juhi vaatenurgast, kelleks on õnneks või kahjuks nimetatud mind. Ja milline idee meile pähe tuli? Inspireerituna populaarsest äratuskellast "Raputa äratuskell" ettevõttelt SupperCommon, mille funktsioon on täielikult blokeerida nutitelefoni kasutamine, kuni kasutaja sooritab teatud toimingu, mis tõenäoliselt paneb ta üles ärkama, otsustasime luua sarnase rakenduse, mis aitab vabaneda telefonisõltuvusest, sama põhimõtte järgi nagu "Raputa äratuskell".

Tööprintsiip

Kasutaja seadistab taimerid
-Aeg, mida võib nutitelefoni taga veeta
-Aeg ilma nutitelefonita (blokkeerimise periood)
Kui taimer on lõpuni jõudnud, ilmub ekraanile ülekatteke, mida ei saa sulgeda
-Ülekate sulgemiseks tuleb läbiseks teha väike väljakutse (sisestada parool keerulisel klaviatuuril, lahendada matemaatikaülesanne, raputada telefoni paar minutit)
Pärast sellist avamist väheneb aeg, mille võib nutitelefoni taga veeta, kaks korda ning see kestab kuni ühe minutini

Kogume meeskonda

Esiteks tuli määrata, kes millega tegelema hakkab ja millisel keelel see kõik kirjeldatakse. Ma arvan, et see ei ole tõeliselt seotud projektijuhtimisega, kuna tõelise projekti jaoks kogud sa kohe inimesed, keda vajad. Lõpuks võtsin oma kanda ka disaineri koormuse, valisin ühe tiimijuhi, kellel oli hea kogemus rakenduste arenduses, tema alluvusse määrati kolm programmeerijat ja kaks muud said testijateks. Loomulikult valiti programmeerimiskeel oskuste põhjal. Lõpuks otsustati kasutada Java't, kuna kõik programmistid olid sellega tuttavad.

Seame ülesanded

Õpetaja soovitusel loodi tasuta teenusel ülesannete tahvel. Trello. Plaan oli töötada Scrumi süsteemis, kus iga voog oleks teatav lõpetatud rakendus.
Kuid tegelikkuses kujunes sellest üks suur ja pikk voog, kuhu pidevalt tehti muudatusi, lisaelemente ja parandusi.

Kuidas me üritasime meeskonnatööd ja mis sellest välja tuli

Kirjutame spetsifikatsioone

Raamatu „Testimine.com” mõju all oli mul peas oma ettekujutus, kuidas kõik peaks olema korraldatud. Kõik algas spetsifikatsioonide kirjutamisega, sest minu arvates ei toimi miski ilma selge kirjeldusega, mida me ootame, mis ja kuidas peaks töötama. Programmaatorid programmeerivad kõik nii, nagu nad ise näevad, testijad katsetavad midagi muud, juht ootab kolmandat, ja tulemus on nagu alati neljas.
Spetsifikatsioonide kirjutamine ei ole lihtne, tuleb läbi mõelda kõik detailid ja nüansid. Loomulikult ei õnnestunud esimesel korral midagi. Lõpuks täiendati ja tehti spetsifikatsioone ümber 4 korda. Viimase variandi leiate artikli lõpust, linkide jaotises.

Joonistame disaini

Mobiilirakenduse disain on kõige olulisem. Kuid mitte kõik ei mõista seda, sealhulgas paljud mu meeskonnast vaidlesid minuga sihikindlalt, et disain ei ole vajalik, et see on rakenduse kõige vähem oluline osa jne. Ei tasu olla nii naiivne. Esiteks, valmislahenduse disain on programmeerimise töö lihtsustamine, sest tal ei pea olema muret selle üle, kuhu ja kuidas midagi asetada, ta lihtsalt võtab ja vormistab, mida on joonistatud. Koos spetsifikatsioonidega vabastab disain praktiliselt täielikult programmeerija meelt tarbetutest asjadest, andes talle võimaluse keskenduda loogikale. Alguses joonistati prototüübi (karm) disain:

Kuidas me üritasime meeskonnatööd ja mis sellest välja tuli

Kuid hiljem viidi disain korda ja muudeti normaalseks.
(Lingid kõikide disainelementide kohta artikli lõpus).

Kuidas me üritasime meeskonnatööd ja mis sellest välja tuli

Programmeeri

Programmeerida on keeruline, aga võimalik. Jätan selle hetke vahele, kuna ma ise sellega tegelenud ei ole. Programmeerijad on teinud tohutut tööd, ilma milleta oleks kõik mõttetu. Muidugi suudeti teostada osa ideedest. Programm vajab veel täiustamist. Palju vigu ja funktsioone, mida tuleb eemaldada. Kui meil oleks rohkem aega, oleksime välja tulnud sügavast alfast, aga praegu saate rakendust proovida artikli lõpus.

Ja testimisest

Mis on programmeerimise peamine asi? Minu arvates on kõige tähtsam, et kõik töötaks ja näeks välja nii, nagu peab. Mitte alati ei õnnestu nii kohe ja kohe. Selleks on vajalik testimine. Oma testijatele pakkusin testimise mudelit testjuhtumite abil. Esiteks kirjutatakse testjuhtumid täielikult spetsifikatsioonidega kooskõlas, seejärel toimub nendest lähtuvalt testimine. Mida sellest tuli, saate vaadata allpool linkides.

Aitäh, et lugesite. Loodan, et leidsisite siit vähemalt midagi kasulikku, võib-olla idee oma idufirma jaoks või hea nõu või tööriista.