să vă apucați din timp - iulie pentru prima temă și august pentru proiect (ambele etape).
faceți 1-2 meetings prin care să stabiliți tematica temei. Aici trebuie sa decideți și cum s-ar plia tematica pe principiile POO, mai ales pe moștenire, care trebuie să apară obligatoriu în prima temă (și în restul temelor), și cum pot fi aplicate design patterns (la proiect / temele 2 și 3). Ideea trebuie să fie cât mai practică, să se muleze pe chestii din viața reală (fără boardgames sau jocuri, s-a dovedit la ”Sheriff of Nottingham” că nu este o tactică bună, deoarece studenții stau mai mult să înțeleagă regulile jocului decât să gândească implementarea).
să vă faceți un canal de Slack privat echipei temei / proiectului.
lead-ul temei / proiectului să împartă task-uri celor care contribuie la temă / proiect, adică să spună cu ce ocupă fiecare (implementare, teste, cerință).
să se facă meetings regulate (din 2 în 2 săptămâni, cu eveniment în Google Calendar pentru toți din echipa temei / proiectului), în care se va discuta statusul curent și ce ar mai trebui făcut.
implementarea trebuie pusă pe un repository privat, la care să aibă acces doar cei care contribuie la temă / proiect, pentru a evita leak-uri (de exemplu un membru random din echipă să ia tema, să o modifice și să o vândă). Implementarea va putea fi făcută publică în cadrul echipei doar după deadline-ul hard. Aceasta nu va fi niciodată publică studenților, având în vedere că tema / proiectul pot fi reciclate în viitor.
cei de la implementare vor lucra pe un branch separat (fiecare cu branch-ul său), fiecare va face pull request.
lead-ul și cu cei de la implementare vor verifica funcționalitățile codului temei / proiectului, încât logica codului să fie corespunzătoare cerinței. La final, după ce codul este terminat, se vor verifica manual testele, pentru a vedea dacă este ceva greșit în logica codului.
cei de la implementare vor redacta cerința, având în vedere că ei știu cel mai bine implementarea, și vor da către restul echipei temei / proiectului la review amănunțit (de redactat cerința într-un Google Docs, pentru a putea adăuga fiecare comentarii și sugestii de schimbare).
când tema / proiectul (fiecare etapă) este lansat, trebuie configurat vmchecker-ul. În acest caz, vă inspirați din configurația temelor din trecut de pe vmchecker. La prima temă trebuie să creați instanța pentru anul universitar, pașii sunt
aici.
să verificați forumul zilnic și să răspundeți cât mai repede posibil (nu lăsați o intervenție fără răspuns, răspundeți prompt în maxim 4-6 ore la aceasta). Dacă aveți un răspuns complex, de care nu sunteți siguri, să vă consultați cu echipa temei respective pe Slack. Pe forum răspundeți obiectiv, clar și concis, fără mișto-uri și aroganțe sau că nu puteți răspunde la întrebarea respectivă (mai puțin dacă are direct legătură cu implementarea lor, aici le puteți răspunde în privat), așa ceva nu este permis (și nici nu vreți să fiți faimoși pe Overheard).
faceți un meeting între deadline-ul soft și cel hard pentru corectarea temei / etapei de la proiect, unde veți stabili baremul, cine corectează teme și asignarea temelor fiecărui corector. Să vă apucați imediat după deadline-ul hard. Este de preferat să dați rezultatele la maxim o săptămână (poate două) după deadline-ul hard, pentru a avea la timp feedback pentru temele viitoare.