Hur vi försökte samarbeta och vad som kom ut av det

Låt oss börja i ordning

Vad betyder den här bilden lite senare, men låt mig nu börja med introduktionen.

En kall februaridag fanns inga tecken på problem. En grupp oskyldiga elever kom för första gången för att ta en klass i ett ämne som de bestämde sig för att kalla "Metodik för att organisera design och utveckling av informationssystem." Det var en vanlig föreläsning, läraren pratade om flexibla utvecklingsmetoder, som Scrum, inget förebådade bråk. Och i slutet tillkännager läraren:

Jag vill att du själv ska uppleva alla svårigheter med lagarbete, dela upp dig i grupper, komma på ett projekt, utse en ledare och gå igenom alla designstadier tillsammans. I slutet förväntar jag mig en färdig produkt och en artikel om Habré av dig.

Det är här vår historia börjar. Som bollar i biljard studsade vi av varandra tills energin från stöten försvann och en grupp på 7 personer samlades. Kanske är detta för mycket för ett utbildningsprojekt, men det är helt rätt att fördela rollerna bättre. En diskussion om idéer för projektet började, från "Låt oss ta ett färdigt projekt" till "Emulator för bildandet av rymdobjekt." Men till slut kom idén fram, namnet som du läser på den första bilden.

Sluta förhala - vad det är, vad det äts med och hur vi utvecklat det och vad som blev av det

Berättelsen kommer att berättas på uppdrag av projektledaren, som, lyckligtvis eller olyckligtvis, tilldelades mig. Så vilken idé kom till våra sinnen? Inspirerad av den populära väckarklockan "Shake Alarm Clock" från SupperCommon, nämligen funktionen att helt blockera smarttelefonen tills användaren utför en viss åtgärd som med största sannolikhet kommer att få honom att vakna, bestämde vi oss för att skapa en liknande applikation som hjälper till att få bli av med telefonberoende, på samma princip som "Skaka väckarklockan"

Funktionsprincip

Användaren ställer in timers
-Tid som kan spenderas på en smartphone
-Tid utan smartphone (spärrperiod)
När timern går ut visas en överlagring på skärmen som inte kan minimeras
-För att stänga överlägget måste du gå igenom ett litet test (ange ett lösenord på ett förvirrande tangentbord, lösa ett matematiskt problem, skaka telefonen i ett par minuter)
Efter upplåsning på detta sätt halveras tiden som kan spenderas på smarttelefonen och så vidare upp till en minut.

Bygga ett team

Först var det nödvändigt att bestämma vem som skulle göra vad och på vilket språk allt detta skulle skrivas. Jag tror att det här inte har mycket med projektledning att göra, för när du sätter ihop ett team för ett riktigt projekt, sätter du direkt ihop de du behöver. Som ett resultat tog jag också på mig bördan av en designer, valde en teamchef som hade god erfarenhet av applikationsutveckling, tre programmerare tilldelades honom och ytterligare två blev testare. Naturligtvis valdes programmeringsspråket utifrån kompetens. Som ett resultat beslutades det att använda Java, eftersom alla programmerare var bekanta med det.

Ställa in uppgifter

På rekommendation av läraren skapades en uppgiftstavla på en gratistjänst Trello. Det var planerat att arbeta enligt Scrum-systemet, där varje stream skulle vara en slags komplett applikation.
Men i verkligheten kom allt detta ur en stor och lång ström, som ständigt gjordes redigeringar, tillägg och korrigeringar.

Vi skriver specifikationer

Influerad av Savins bok "Testing.com" hade jag en egen idé i mitt huvud om hur allt skulle ordnas. Allt började med att skriva specifikationer, som jag tror, ​​utan en tydlig beskrivning av vad vi förväntar oss, vad och hur det ska fungera, kommer ingenting att fungera. Programmerarna kommer att programmera allt som de ser det, testarna kommer att testa något annat, chefen förväntade sig den tredje, men det kommer att visa sig vara den fjärde som alltid.
Att skriva specifikationer är inte lätt, du måste tänka igenom alla detaljer, alla nyanser. Inget fungerade förstås första gången. Som ett resultat kompletterades och gjordes om specifikationerna 4 gånger. Du hittar det sista alternativet i slutet av artikeln, i länksektionen.

Rita en design

Design i en mobilapplikation är det viktigaste. Det är dock inte alla som förstår detta, inklusive från mitt team, många argumenterade häftigt med mig att design inte behövs, att detta är den mest oviktiga delen av applikationen osv. Du ska inte vara så naiv. För det första underlättar en färdig design programmerarens arbete; han behöver inte tänka på vad han ska placera var och var, han tar bara och sätter in det som ritas. Tillsammans med specifikationerna frigör designen nästan helt programmerarens sinne från onödiga saker, och ger honom möjlighet att koncentrera sig på logik. I allmänhet ritades en prototyp (hemsk) design först:

Men sedan kammades designen och fördes tillbaka till det normala.
(Länk till alla designelement i slutet av artikeln).

Programmering

Programmering är svårt, men möjligt. Jag kommer att utelämna denna punkt, eftersom jag inte personligen har tagit itu med detta själv. Programmerarna gjorde en enorm mängd arbete, utan vilket allt skulle ha varit meningslöst. Självklart lyckades vi förverkliga några av våra idéer. Och programmet behöver fortfarande förbättras. Det finns många buggar och funktioner som måste tas bort. Om vi ​​hade mer tid skulle vi komma ur djup alfa, men för nu kan du testa applikationen i slutet av artikeln.

Tja, om att testa

Vad är huvudsaken inom programmering? Enligt mig är huvudsaken att allt fungerar och ser ut som det ska. Det går inte alltid bra och inte direkt. Detta kräver testning. Till mina testare föreslog jag en testmodell med testfall. Först skrivs testfall helt i enlighet med specifikationerna, och sedan utförs testning på dem. Du kan se vad som kom ut av detta i länkarna nedan.

Tack för att du läser. Jag hoppas du hittade åtminstone något användbart här, kanske en idé för din start, eller kanske några bra råd eller ett verktyg.

Länkar:

Senaste specifikationer.
Design på figma.
Testfall и felrapporter.

Själva applikationen är på HokeyApp. — Applikationen byggdes under namnet HandsOff, fråga inte ens varför (eftersom Stop Procrastination är för långt).

Tja, på slutet

Tycker du att allt detta var vettigt?

Endast registrerade användare kan delta i undersökningen. Logga in, Snälla du.

Är sådan praxis nödvändig i utbildningsinstitutioner och hur användbar och användbar är den i verkligheten?

• Behövlig, ovärderlig erfarenhet

• Behövs, om än lite erfarenhet

• Nästan värdelöst, på sin höjd kommer du att förstå de allmänna egenskaperna av att arbeta i ett team

• Ett slöseri med tid och ansträngning

2 användare röstade. Det finns inga nedlagda röster.

Källa: will.com