Rendben, kezdjük el
Ennek a rajznak a jelentéséről később beszélünk, most pedig engedjék meg, hogy az bevezetővel kezdjem.
A hideg februári napon semmi nem jelezte a közelgő bajt. Egy ártatlan diákcsoport először érkezett egy órára, amelynek a 'Információs rendszerek tervezésének és fejlesztésének metodológiája' nevet adták. Egy szokásos előadás zajlott, a tanár a rugalmas fejlesztési módszerekről, például a scramról beszélt, semmi nem jelezte a bajt. És a végén a tanár bejelentette:
Azt akarom, hogy tapasztaljátok meg a csapatmunka minden nehézségét, osszátok fel magatokat csoportokra, találjatok ki egy projektet, jelöljetek ki egy vezetőt, és együtt járjátok végig a tervezés minden szakaszát. A végén egy kész terméket és egy cikket várok tőletek a Hub-on.
Itt kezdődik a történetünk. Mint a biliárdgolyók, egyenként pattantunk el egymástól, míg a becsapódás energiája el nem oszlott, és végül összegyűlt egy 7 fős csoport. Lehet, hogy ez túl sok egy tanulmányi projekthez, de a szerepek jobb elosztása érdekében éppen megfelelő. Az ötletelés elkezdődött a 'Vegyünk egy kész projektet' javaslattól egészen az 'Űrobjektumok generáló emulátoráig'. De végül az ötlet, amelynek nevét az első képen olvashattad, került előtérbe.
Stop Procrastination — mi ez, hogyan működik, és hogyan fejlesztettük, valamint mi sült ki belőle
A történetet a projekt vezetőjének szemszögéből meséljük, akit szerencsére vagy sajnos engem neveztek ki. Tehát mi volt az ötlet, ami eszünkbe jutott? A SupperCommon népszerű 'Shake Alarm' óra inspirál, amely teljesen blokkolja a okostelefon működését, amíg a felhasználó meg nem tesz egy meghatározott lépést, amely valószínűleg felébreszti, így úgy döntöttünk, hogy készítünk egy hasonló alkalmazást, amely segít megszabadulni a telefonfüggőségtől, ugyanazon elv alapján, mint a 'Shake Alarm'.
A működés elve
A felhasználó időzítőket állít be
-Az idő, amit a okostelefonon tölthet
-Az idő okostelefon nélkül (blokkolási időszak)
Az időzítő lejárta után egy átfedés jelenik meg a képernyőn, amit nem lehet bezárni
-Az átfedés bezárásához egy kis próbát kell teljesíteni (beírni a jelszót egy bonyolult billentyűzeten, megoldani egy matematikai feladatot, vagy pár percig megrázni a telefont)
A módon történő feloldás után a telefonon tölthető idő a felére csökken, egészen egy percig.
Csapatot építünk
Először is meg kellett határozni, ki mivel foglalkozik, és milyen nyelven fog mindez íródni. Szerintem ez nem sokat kapcsolódik a projektmenedzsmenthez, mert amikor valódi projekthez alakítasz csapatot, már akkor azokat az embereket gyűjtöd össze, akikre szükséged van. Végül a tervezői terhet is magamra vállaltam, választottam egy vezetőt, aki tapasztalt volt az alkalmazásfejlesztésben, három programozót jelöltem ki alárendeltként, és még kettő tesztelő lett. Természetesen a programozási nyelvet a készségek alapján választottuk. Végül úgy döntöttünk, hogy Java-t használunk, mert minden programozó ismerte azt.
Feladatokat állítunk fel
Oktatóm ajánlására egy feladatlistát készítettünk egy ingyenes szolgáltatáson. . Azt terveztük, hogy a Scrum módszertan szerint dolgozunk, ahol minden stream valamilyen befejezett alkalmazást fog képviselni.
A valóságban azonban mindez egy nagy és hosszú stream lett, amelybe folyamatosan javításokat, kiegészítéseket és korrekciókat írtunk.
Specifikációkat írunk
Savin „Testing.com” című könyvének hatására megvolt a fejemben az elképzelés, hogy hogyan kellene mindennek működnie. Minden a specifikációk írásával kezdődött; véleményem szerint világos leírás nélkül, arról, hogy mit várunk, és hogy minek hogyan kell működnie, semmi sem működik. A programozók úgy fogják megvalósítani, ahogy ők látják, a tesztelők eleget tesznek más elvárásoknak, a vezető pedig harmadik eredményt vár, és végül mindig a negyediket kapjuk.
A specifikációk megírása nem könnyű, minden részletet és árnyalatot meg kell fontolni. Természetesen elsőre semmi sem sikerült. Végül a specifikációkat négy alkalommal kellett kiegészíteni és átírni. Az utolsó változatot a cikk végén, a hivatkozások részben találhatja.
Megrajzoljuk a dizájnt
A dizájn a mobilalkalmazásban a legfontosabb. Azonban nem mindenki érti ezt, beleértve a csapatomból sokan is hevesen vitáztak velem arról, hogy a dizájn nem szükséges, hogy ez a legkevésbé fontos része az alkalmazásnak stb. Nem érdemes ilyen naivnak lenni. Először is, a kész dizájn megkönnyíti a programozó munkáját, nem kell gondolkodnia azon, hogy hol és mit hova kell betenni, csak veszi és kódolja, ami meg van rajzolva. A specifikációkkal együtt a dizájn szinte teljesen felszabadítja a programozó elméjét a felesleges dolgoktól, és lehetőséget ad neki, hogy a logikára koncentráljon. Általában először egy prototípus (szörnyű) dizájnt rajzoltak:
De később a dizájnt csinosították és normális formába hozták.
(Link az összes dizájn elemhez a cikk végén).
Programozunk
A programozás nehéz, de lehetséges. Ezt a pontot most kihagyom, mivel én személyesen nem foglalkoztam vele. A programozók óriási munkát végeztek, nélkülük minden értelmetlen lenne. Természetesen sikerült megvalósítani egy részét az elképzeléseknek. A programnak még szüksége van finomításokra. Sok hiba és funkció van, amit el kell távolítani. Ha több időnk lett volna, akkor kiléptünk volna a mély alfa státusból, de addig is az alkalmazást a cikk végén tudjátok tesztelni.
Nos, és a tesztelésről
Mi a legfontosabb a programozásban? Véleményem szerint a legfontosabb, hogy minden működjön és úgy nézzen ki, ahogy kell. Ehhez nem mindig és nem azonnal jutunk el. Ehhez tesztelés szükséges. A saját tesztelőimnek egy tesztelési modellt javasoltam tesztelési esetek használatával. Először a tesztelési eseteket a specifikációkkal teljes összhangban írják, majd ezek alapján történik a tesztelés. Amit ebből kaptunk, azt lent láthatjátok a linkeken.
Köszönöm, hogy elolvastátok. Remélem, találtatok itt valami hasznosat, esetleg egy ötletet a saját startupotokhoz, vagy egy jó tanácsot vagy eszközt.
Linkek:
Legutóbbi .
Dizájn a .
és .
Magának az alkalmazásnak a . — Az alkalmazás a HandsOff néven épült, ne kérdezzétek miért (mert a Stop Procrastination túl hosszú).
Nos, és a végén
Mit gondoltok, volt-e ennek értelme?
Csak a regisztrált felhasználók vehetnek részt a szavazáson. , kérem.
Szükséges-e egy 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 kicsit van tapasztalat
Majdnem haszontalan, legfeljebb megértesz néhány általános dolgot a csapatmunkában
Felesleges idő- és energia-pazarlás
2 felhasználó szavazott. Tartózkodó nincs.
Forrás: habr.com
