Hogyan próbáltuk ki a csapatmunkát és mi sült ki belőle

Kezdjük a sorrendben

Mit jelent ez a kép egy kicsit később, de most hadd kezdjem a bevezetővel.

Egy hideg februári napon semmi jele nem volt a bajnak. Egy csoport ártatlan diák először érkezett, hogy részt vegyen egy tantárgyból, amelyet úgy döntöttek, hogy „Módszertan az információs rendszerek tervezésének és fejlesztésének megszervezéséhez”. Volt egy rendes előadás, a tanár úr beszélt a rugalmas fejlesztési módszerekről, például a Scrumról, semmi sem vetített előre bajt. És a végén a tanár bejelenti:

Azt szeretném, ha magad tapasztalnád meg a csapatmunka minden nehézségét, oszlj csoportokra, dolgozz ki egy projektet, nevezz ki egy vezetőt, és együtt menj végig a tervezés összes szakaszán. A végére egy kész terméket és egy cikket várok Öntől a Habréról.

Itt kezdődik a történetünk. Mint labdák a biliárdban, úgy pattogtunk egymásról, amíg a becsapódás energiája el nem oszlott, és egy 7 fős csoport összegyűlt. Talán ez túl sok egy képzési projekthez, de a szerepek jobb elosztása helyes. Megkezdődött a projekt ötleteinek megvitatása, a „Vegyünk egy kész projektet” az „Emulátor űrobjektumok kialakításához”-ig. De végül bejött az ötlet, aminek a nevét az első képen olvastad.

Állítsd meg a halogatást – mi az, mivel eszik, hogyan fejlesztettük ki és mi lett belőle

A történetet a projektmenedzser nevében mondják el, akit szerencsére vagy sajnos rám bíztak. Szóval milyen ötlet jutott eszünkbe? A SupperCommon népszerű „Shake Alarm Clock” ébresztőórája ihlette, nevezetesen az okostelefon teljes blokkolásának funkciója, amíg a felhasználó nem hajt végre egy bizonyos műveletet, amely valószínűleg felébreszti, ezért úgy döntöttünk, hogy létrehozunk egy hasonló alkalmazást, amely segít megszabadulni a telefonfüggőségtől, ugyanazon az elven, mint a „Rázd meg az ébresztőórát”

Működési elv

A felhasználó beállítja az időzítőket
- Az okostelefonon eltölthető idő
- Okostelefon nélküli idő (blokkoló időszak)
Amikor az időzítő lejár, egy átfedés jelenik meg a képernyőn, amelyet nem lehet kicsinyíteni
-A fedőréteg bezárásához egy kis teszten kell keresztülmenni (jelszó beírása zavaros billentyűzeten, matematikai feladat megoldása, pár percig rázni a telefont)
Az ilyen módon történő feloldás után az okostelefonon eltölthető idő felére csökken, és így tovább akár egy percig.

Csapatépítés

Először is meg kellett határozni, hogy ki mit csináljon és milyen nyelven írják le mindezt. Szerintem ennek nem sok köze van a projektmenedzsmenthez, mert amikor összeállítunk egy csapatot egy valódi projekthez, azonnal összeállítjuk azokat, akikre szükségünk van. Ebből kifolyólag a tervezői terhet is magamra vállaltam, kiválasztottam egy alkalmazásfejlesztési tapasztalattal rendelkező csapatvezetőt, három programozót rendeltek hozzá, két másik pedig tesztelő lett. Természetesen a programozási nyelvet a képességek alapján választották. Ennek eredményeként a Java használata mellett döntöttek, mivel minden programozó ismerte azt.

Feladatok beállítása

Tanári javaslatra ingyenes szolgáltatáson feladattábla készült Trello. A tervek szerint a Scrum rendszer szerint működnének, ahol minden stream egyfajta komplett alkalmazás lenne.
A valóságban azonban mindez egyetlen nagy és hosszú folyamból jött ki, amelyen folyamatosan történtek szerkesztések, kiegészítések, javítások.

Specifikációkat írunk

Savin „Testing.com” című könyvének hatására megvolt a saját ötletem a fejemben, hogyan is kellene mindent elrendezni. Az egész a specifikációk megírásával kezdődött, úgy gondolom, anélkül, hogy világosan leírnánk, mit várunk, mit és hogyan kell működnie, semmi sem fog működni. A programozók mindent úgy fognak programozni, ahogy látják, a tesztelők mást tesztelnek, a menedzser a harmadikra ​​számított, de az lesz, mint mindig, a negyedik.
A specifikációk megírása nem egyszerű, át kell gondolni minden részletet, minden árnyalatot. Természetesen elsőre semmi sem működött. Ennek eredményeként a specifikációkat négyszer kiegészítették és újraírták. Az utolsó lehetőséget a cikk végén, a linkek részben találja.

Tervezés rajza

A tervezés a mobilalkalmazásban a legfontosabb. Ezt azonban nem mindenki érti, még a csapatomból is, sokan hevesen vitatkoztak velem, hogy nincs szükség a tervezésre, hogy ez az alkalmazás legkevésbé fontos része stb. Nem szabad ennyire naivnak lenned. Először is, egy kész terv megkönnyíti a programozó munkáját, nem kell azon gondolkodnia, hogy mit hova és hova tegyen, hanem csak veszi és szedi a lerajzoltat. A specifikációkkal együtt a tervezés szinte teljesen megszabadítja a programozó elméjét a felesleges dolgoktól, és lehetőséget ad a logikára koncentrálni. Általában egy prototípus (szörnyű) terv készült először:

De aztán a tervezést átfésülték, és visszaállították a normális kerékvágásba.
(Az összes design elem linkje a cikk végén).

Programozás

A programozás nehéz, de lehetséges. Ezt a pontot kihagyom, mivel személyesen magam nem foglalkoztam ezzel. A programozók hatalmas munkát végeztek, enélkül minden értelmetlen lett volna. Természetesen néhány elképzelésünket sikerült megvalósítanunk. És a program még fejlesztésre szorul. Nagyon sok hiba és funkció van, amelyeket el kell távolítani. Ha több időnk lenne, kiszállnánk a mély alfából, de egyelőre a cikk végén lehet tesztelni az alkalmazást.

Nos, a tesztelésről

Mi a legfontosabb a programozásban? Véleményem szerint az a lényeg, hogy minden működjön és úgy nézzen ki, ahogy kell. Nem mindig sikerül jól és nem azonnal. Ez tesztelést igényel. Tesztelőimnek teszteseteket használó tesztelési modellt javasoltam. Először teszteseteket írnak ki teljesen a specifikációnak megfelelően, majd tesztelik őket. Az alábbi linkeken megtekintheti, hogy mi sült ki ebből.

Köszönöm, hogy elolvasta. Remélem találtál itt legalább valami hasznosat, esetleg ötletet az induláshoz, esetleg valami jó tanácsot vagy eszközt.

referenciák:

Legutolsó specifikációk.
Tervezés bekapcsolva figma.
Teszt esetek и hibajelentések.

Maga az alkalmazás be van kapcsolva HokeyApp. — Az alkalmazás HandsOff néven készült, ne is kérdezd, miért (mert a Stop Procrastination túl hosszú).

Hát a végén

Szerinted ennek az egésznek volt értelme?

A felmérésben csak regisztrált felhasználók vehetnek részt. Bejelentkezés, kérem.

Szükséges-e ilyen gyakorlat az oktatási intézményekben, és mennyire hasznos és alkalmazható a való életben?

• Szükséges, felbecsülhetetlen tapasztalat

• Szükséges, bár egy kis tapasztalat

• Szinte haszontalan, legfeljebb a csapatmunka általános jellemzőit fogod megérteni

• Idő és erőfeszítés pazarlása

2 felhasználó szavazott. Nincs tartózkodás.

Forrás: will.com