🥇Kuidas me proovisime meeskonnatööd ja mida sealt välja tuli

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

Räägime järjestikku

Mis see joonis tähendab veidi hiljem, aga nüüd lubage mul alustada sissejuhatusest.

Külmas veebruarikuises päevas ei midagi ei ennustanud häda. Rühm süütuid üliõpilasi tuli esmakordselt loengusse aine, mille nimi oli "Infotehnoloogia süsteemide projekteerimise ja arendamise metoodika". Oli tavaline loeng, õpetaja rääkis paindlikest arendusmeetoditest, nagu Scrum, miski ei ennustanud häda. Ja lõpuks kuulutas õpetaja:

Ma soovin, et te kogeksite kõik meeskonnatöö vaevad, jaguneks kõik gruppidesse, mõtleks välja projekti, määraks juhiks ja läbiks koos kõik projekteerimise etapid. Lõpus ootan teilt valmis toodet ja artiklit Habr's.

Siit algab meie lugu. Nagu biljardivärvid, põrkasime üksteisest eemale, kuni löögi energia hajus ja koos kogunes seitsme inimesest grupp. Võib-olla on see õppeprojekti jaoks liiga palju, aga et rolle paremini jaotada, on see just õige. Ideede arutelu algas projektist "Võtame valmis projekti" kuni "Kosmoses objektide moodustamise emulaatorini". Kuid lõpuks tuli välja idee, mille nime te lugesite esimesel pildil.

Stop Procrastination — mis see on, millega seda süüakse ja kuidas me seda arendasime ning mis sellest välja tuli

Lugu jutustatakse projekti juhi vaatenurgast, kelleks minu õnneks või kahjuks määrati mind. Ja mis idee meile pähe tuli? Inspiratsiooni saades populaarsetest äratuskelladest "Shake Alarm" firma SupperCommon, nimelt funktsionaalsusest, mis blokeerib nutitelefoni töö seni, kuni kasutaja ei soorita teatud tegevust, mis tõenäoliselt paneb ta ärkama, otsustasime luua sarnase rakenduse, mis aitab vabaneda telefonisõltuvusest, sama põhimõtte alusel nagu "Shake Alarm".

Töö принцип

Kasutaja seadistab taimerid
-Aeg, mida võib nutitelefonis veeta
-Aeg ilma nutitelefonita (blokeerimise periood)
Taimeri lõppemisel ilmub ekraanile katmine, mida ei saa sulgeda
-Katmise sulgemiseks tuleb läbida väike proov (sisestada parool keerulisel klaviatuuril, lahendada matemaatikatühi, raputada telefoni paar minutit)
Pärast sellist avamist väheneb nutitelefonis veedetud aeg kahekordselt, kuni ühe minutini.

Kasutame meeskonna loomist

Esmalt tuli määrata, kes millega tegelema hakkab ja millisel keeles see kõik kirjutatakse. Arvan, et see ei ole õige lähenemine projektijuhtimisele, sest kui kogud meeskonna reaalse projekti jaoks, vajad kohe inimesi, keda sul tõeliselt vaja on. Lõpuks võtsin ka endale disaineri ülesande, valisin ühe tiimijuhi, kellel oli väga hea rakenduste arendamise kogemus, kelle alluvusse määrati kolm programmeerijat ja veel kaks said testijateks. Loomulikult valiti programmeerimiskeel oskuste järgi. Lõpuks otsustati kasutada Java't, kuna kõik programmeerijad olid selle keelega tuttavad.

Määrame ülesanded

Õpetaja soovitusel loodi tasuta teenuses ülesannete loomise laud. TrelloPlaneeriti töötada Scrumi meetodil, kus iga voog esindab mingit lõplikku rakendust.
Kuid tegelikkuses osutus kogu sellest suureks ja pikaks vooks, kuhu pidevalt tehti parandusi, täiendusi ja muudatusi.

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

Kirjutame spetsifikatsioonid

Savini raamatu «Testimine.com» mõju all oli mul peas oma ettekujutus, kuidas kõik peaks olema korraldatud. Kõik algas spetsifikatsioonide kirjutamisest, kuna arvan, et ilma selge kirjelduse tõttu, mida me ootame, mis ja kuidas peaks töötama, ei hakka midagi korralikult töötama. Programmeerijad programmeerivad kõik nii, nagu nemad näevad, testijad testivad midagi muud, juht ootab kolmandat, kuid lõpptulemusena on see nagu alati neljas.
Spetsifikatsioonide kirjutamine ei ole lihtne, tuleb läbi mõelda kõik üksikasjad ja nüansid. Loomulikult ei saanud esimesel katsel midagi korda. Lõpuks täiendati ja tehti spetsifikatsioonid neljal korral. Viimase variandi leiate artikli lõpust, lingi jaotises.

Joonistame disaini

Disain mobiilirakenduses on kõige olulisem. Kuid mitte kõik mõistavad seda, sealhulgas mu meeskonnas paljud tuliselt vaielasid minuga, et disaini pole vaja, et see on rakenduse kõige vähem oluline osa jne. Ei tasu olla nii naivne. Esiteks, valmisse disain on arendaja töö hõlbustamine, tal ei ole vaja mõelda, mis kus ja kuhu sokutada, ta lihtsalt võtab ja koodib, mis on joonistatud. Koos spetsifikatsioonidega vabastab disain peaaegu täielikult arendaja meele tarbetutest asjadest ning annab talle võimaluse keskenduda loogikale. Alguses joonistati prototype (kohutav) disain:

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

Aga siis disain viidi korda ja toodi normaalsetesse mõõtudesse.
(Lingid kõikidele disainielementidele artikli lõpus).

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

Programmeerimine

Programmeerimine on keeruline, kuid võimalik. Jätan selle punkti välja, kuna ma isiklikult sellega ei tegelenud. Arendajad tegid tohutut tööd, ilma milleta oleks kõik mõtetu. Kindlasti õnnestus teostada osa ideedest. Ja programm vajab veel täiustamist. Palju vigu ja funktsioone, mis tuleb kõrvaldada. Kui meil oleks rohkem aega, oleksime sügava alfafaasist välja tulnud, aga seni saate rakendust katsetada artikli lõpus.

Ja testimisest

Mis on programmeerimise kõige olulisem? Minu arvates on kõige olulisem, et kõik töötaks ja näeks välja nii, nagu peab. Kuidas peab, ei tule alati ja mitte kohe. Selleks on vajalik testimine. Oma testijatele pakkusin testimise mudelit testijuhtude kasutamisega. Esiteks kirjutatakse testijuhised vastavalt spetsifikatsioonidele ja seejärel viiakse need läbi testimine. Mida see kõik tõi, võite vaadata allpool linkides.

Aitäh, et lugesite. Loodan, et leidsid siit vähemalt midagi kasulikku, võib-olla idee enda idufirmale või hea nõu või tööriista.