Nola saiatu ginen talde lana eta zer atera zen

Nola saiatu ginen talde lana eta zer atera zen

Demagun

Zer esan nahi du argazki honek pixka bat geroago, baina oraingoz sarrerarekin hasiko naiz.

Otsaileko egun hotz batean ez zegoen arazorik zantzurik. Ikasle errugabe talde bat etorri zen lehen aldiz “Informazio sistemen diseinua eta garapena antolatzeko metodologia” deitzea erabaki zuten gai bati buruzko klase bat ematera. Ohiko hitzaldi bat zegoen, irakasleak garapen-metodo malguei buruz hitz egin zuen, hala nola Scrum, ezerk ez zuen arazoak iragartzen. Eta amaieran irakasleak iragartzen du:

Talde-lanaren zailtasun guztiak zuk zeuk bizitzea nahi dut, taldetan banatu, proiektu bat sortu, lider bat izendatu eta diseinu-fase guztiak elkarrekin igarotzea. Bukaeran, zuengandik produktu amaitu bat eta Habréri buruzko artikulu bat espero dut.

Hemen hasten da gure istorioa. Bilarreko bolak bezala, elkarren aurka errebotatu genuen, talkaren energia xahutu eta 7 laguneko taldea elkartu zen arte. Agian hori gehiegi da prestakuntza-proiektu baterako, baina egokia da rolak hobeto banatzeko. Proiekturako ideien eztabaida hasi zen, "Har dezagun prest egindako proiektu bat"tik "Emulatzailea espazioko objektuen eraketa". Baina azkenean ideia sortu zen, zeinaren izena lehen irudian irakurri zenuen.

Gelditu Procrastination - zer den, zerekin jaten den eta nola garatu genuen eta zer atera zen

Istorioa proiektuaren arduradunaren izenean kontatuko da, zorionez edo zoritxarrez, esleitu zidaten. Orduan, zer ideia etorri zitzaigun burura? SupperCommon-en "Shake Alarm Clock" iratzargailu ezagunean inspiratuta, hots, telefonoa guztiz blokeatzeko funtzioa, erabiltzaileak ziurrenik esnatuko duen ekintza jakin bat egin arte, lortzen lagunduko duen antzeko aplikazio bat sortzea erabaki dugu. telefonoaren mendekotasuna kentzeko, "Astindu iratzargailua"-ren printzipio berean

Eragiketa printzipioa

Erabiltzaileak tenporizadoreak ezartzen ditu
-Smartphone batean eman daitekeen denbora
-Smartphonerik gabeko denbora (blokeatzeko epea)
Tenporizadorea amaitzen denean, gutxitu ezin den gainjarri bat agertzen da pantailan
- Gainjartzea ixteko proba txiki bat egin behar duzu (sartu pasahitza teklatu nahasi batean, matematika arazo bat konpondu, telefonoa astindu pare bat minutuz)
Modu honetan desblokeatu ondoren, telefonoan eman daitekeen denbora erdira murrizten da, eta horrela minutu bat arte.

Talde bat eraikitzea

Lehenik eta behin, hori guztia nork zer egingo zuen eta zein hizkuntzatan idatziko zen zehaztu behar zen. Uste dut horrek zerikusi gutxi duela proiektuen kudeaketarekin, izan ere, benetako proiektu baterako talde bat osatzen duzunean, berehala behar dituzunak biltzen dituzu. Ondorioz, diseinatzaile baten zama ere hartu nuen, aplikazioen garapenean esperientzia ona zuen talde-zuzendari bat aukeratu nuen, hiru programatzaile esleitu zizkioten eta beste bi probatzaile bihurtu ziren. Jakina, programazio-lengoaia trebetasunen arabera aukeratu zen. Ondorioz, Java erabiltzea erabaki zen, programatzaile guztiek ezagutzen baitzuten.

Zereginak ezartzea

Irakaslearen gomendioz, zereginen taula bat sortu zen doako zerbitzu batean Trello. Scrum sistemaren arabera lan egitea aurreikusi zen, non korronte bakoitza aplikazio oso moduko bat izango zen.
Hala ere, egia esan, hau guztia korronte handi eta luze batetik atera zen, zeinari aldaketak, gehiketak eta zuzenketak etengabe egiten zitzaizkion.

Nola saiatu ginen talde lana eta zer atera zen

Zehaztapenak idazten ditugu

Savin-en "Testing.com" liburuak eraginda, dena nola antolatu behar zen nire ideia nuen buruan. Dena zehaztapenak idaztearekin hasi zen, nire ustez, zer espero dugun, zer eta nola funtzionatu behar duen deskribapen argirik gabe, ezer ez da funtzionatuko. Programatzaileek dena ikusten duten moduan programatuko dute, probatzaileek beste zerbait probatuko dute, kudeatzaileak hirugarrena espero zuen, baina beti bezala laugarrena izango da.
Zehaztapenak idaztea ez da erraza, xehetasun guztiak pentsatu behar dituzu, ñabardura guztiak. Noski, ezerk ez zuen funtzionatu lehen aldian. Ondorioz, zehaztapenak 4 aldiz osatu eta berritu ziren. Azken aukera artikuluaren amaieran aurki dezakezue, estekak atalean.

Diseinu bat marraztea

Mugikorretarako aplikazio batean diseinatzea da garrantzitsuena. Hala ere, denek ez dute hori ulertzen, baita nire taldetik ere, askok gogor argudiatu zidaten diseinua ez zela beharrezkoa, hau dela aplikazioaren zatirik garrantzitsuena, etab. Ez zenuke hain inozoa izan behar. Lehenik eta behin, prest egindako diseinu batek programatzailearen lana errazten du; ez du pentsatu behar zer jarri non eta non, marraztutakoa hartu eta idazten du. Zehaztapenekin batera, diseinuak ia guztiz askatzen du programatzailearen adimena alferrikako gauzetatik, eta logikan kontzentratzeko aukera ematen dio. Oro har, diseinu prototipo bat (ikaragarria) marraztu zen lehenengo:

Nola saiatu ginen talde lana eta zer atera zen

Baina gero diseinua orraztu eta normaltasunera itzuli zen.
(Artikuluaren amaieran diseinu-elementu guztietarako esteka).

Nola saiatu ginen talde lana eta zer atera zen

Programazioa

Programazioa zaila da, baina posible. Puntu hau alde batera utziko dut, nik neuk ez baitut honi pertsonalki landu. Programatzaileek lan handia egin zuten, hori gabe dena zentzurik gabea izango zen. Jakina, gure ideia batzuk gauzatzea lortu dugu. Eta programak oraindik hobetu behar du. Akats eta funtzio asko kendu behar dira. Denbora gehiago izango bagenu, alfa sakonetik aterako ginateke, baina oraingoz artikuluaren amaieran aplikazioa probatu dezakezu.

Tira, probei buruz

Zein da programazioan gauza nagusia? Nire ustez, gauza nagusia dena funtzionatzen duela eta behar den bezala ikusten da. Ez du beti ondo funtzionatzen eta ez berehala. Horrek probak eskatzen ditu. Nire probatzaileei, test kasuak erabiliz proba eredu bat proposatu nien. Lehenik eta behin, proba-kasuak zehaztapenen arabera idazten dira, eta, ondoren, probak egiten dira. Beheko esteketan ikus dezakezue zer atera den honetatik.

Eskerrik asko irakurtzeagatik. Espero dut hemen gutxienez zerbait erabilgarria aurkitzea, agian zure startuperako ideia bat, edo agian aholku on bat edo tresnaren bat.

erreferentziak:

Azkenak zehaztapenak.
Diseinua martxan figma.
Proba kasuak и akatsen txostenak.

Aplikazioa bera aktibatuta dago HokeyApp. - Aplikazioa HandsOff izenarekin eraiki zen, ez galdetu zergatik (Stop Procrastination luzeegia delako).

Bukaeran ondo

Honek guztiak zentzua duela uste duzu?

Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. Hasi saioa, mesedez.

Praktika hori beharrezkoa al da hezkuntza-erakundeetan eta zein erabilgarria eta aplikagarria da bizitza errealean?

  • Beharrezkoa, ezinbestekoa den esperientzia

  • Beharrezkoa, nahiz eta esperientzia apur bat

  • Ia alferrikakoa, gehienez ere taldean lan egitearen ezaugarri orokorrak ulertuko dituzu

  • Denbora eta ahalegina galtzea

2 erabiltzailek eman dute botoa. Ez dago abstentziorik.

Iturria: www.habr.com

Gehitu iruzkin berria