Pravidla, kterými se musí členové týmu řídit při práci. Zejména jde o práci s bugtrackerem a verzovacím nástrojem, a ImplementacniKonvence.

Organizace projektu

Tep projektu: každý měsíc (TBD přesně: např. první středu v měsíci) general meeting - review udělaného, plán na další měsíc.

Typy záznamů v bugtrackeru:

--MILNÍK--	shrnutí cíle etapy
Feature	uživatelská funkčnost či vlastnost, nově chtěná
Task	interní vylepšení, reorganizace kódu, technické úpravy
Bug	jakákoli chyba, ať od uživatele nebo z interních testů

Vývojáři:

1. dělat jen na tom, co mají přiřazeno
2. otevírat nové bugreporty když se najde chyba, a to i ve vlastním kódu (nepřiřazovat je nikomu, leda sobě když je to ve vlastním kódu)
3. když je udělaný kus práce na tasku, otestovat na lokále AND (dle vlastního uvážení) commit do úložiště AND zvednout "teploměr" AND připsat komentář co bylo uděláno (byl-li commit, napsat číslo revize)
4. když je práce na tasku dodělaná, (1) otestovat si na lokále, (2) commit do úložiště - do poznámky ke commitu napsat číslo (ID) tasku a jak byl vyřešen, (3) dát teploměr na 100%, stav na Requires testing, a přidat komentář s číslem commitu ve kterém je implementace, (4) dát vědět managementu projektu

Zdrojový kód dodržuje ImplementacniKonvence.

Management:

1. používání priority ve vztahu k plánovanému release: viz tabulka dále
2. přidání tasku => naplánovat do release, pro release milník přidat závislost na přidaném
3. nepřiřazovat tasky bez domluvy s vývojářem
4. pravidelně kontrolovat stav task listu
5. tasky nastavené na Requires testing projít s vývojáři (review a/nebo otestovat), uzavřít (zkontrolovat svn repo, do close comment dát číslo commitu)

Váha pro cíl release	Priorita
milník	Flash
MUST čili release blocker (prioritu má task)	High
SHOULD čili pokud není impl v release je třeba zdůvodnit (prioritu může mít release)	Normal
MAY čili když se nestihne, nic moc se neděje (prioritu má release)	Low