Projekt

Obecné

Profil

Akce
Historie

Wiki »

Konvence projektu

Pravidla týmu

Obecná pravidla

  • Pro komunikaci používáme platformu Discord
  • Weekly standup schůzky se konají pravidelně ve čtvrtek
  • Každý zodpovědně vyplňuje strávený čas na storkách – ten, kdo je poslední, storku uzavírá
  • Iterace budou dlouhé 2 týdny a začínat/končit budou vždy ve čtvrtek
  • Po uzavření iterace (nestanoví-li se jinak) obepisuje mentora/zadavatele vedoucí týmu

Role členů

  • Milan Janoch
    • Vedoucí týmu
    • Backend programátor
      • Programování Jira pumpy
    • Tester
    • Dokumentarista
    • Správce Redmine storek
  • Jakub Pavlíček
    • Hlavní architekt datových pump
      • Navrhuje generický a snadno rozšiřitelný kód
    • Backend programátor
      • Programování Git pumpy
    • Diplomat
      • Obepisuje vedoucího a mentora s dotazy, domlouvá schůzky
  • František Urban
    • Fullstack programátor
    • GitLab specialista
    • Tester
    • Správce Redmine storek
  • Jakub Homolka
    • Specialista na databáze a zpracování dat
    • Frontend programátor
    • UX + UI designér
  • Jan Vandlíček
    • Frontend + utility programátor
    • Researcher
      • Hledá nové technologie, které můžeme zapojit do projektu
    • Správce Discord serveru
  • Štěpán Faragula
    • Fullstack programátor
    • Tester
    • Dokumentarista
    • Správce Redmine Wiki
    • Správce Discord serveru

Angličtina vs čeština

  • V angličtině
    • Zdrojový kód + komentáře
    • Commit messages
    • Artefakty
    • Dokumentace kódu
    • Popisky merge requestů
    • Případné připomínky na Code Review
  • V češtině
    • Storky v Redmine (krom klíčového slova v názvu)
    • Komunikace v týmu a s mentory/zadavatelem

GitLab

  • Branches
    • Projekt obsahuje dvě hlavní větve - dev a main
    • Další větve feature/<num> jsou určeny pro přidávání nových funkcí do repozitáře
    • Větve bug/<num> slouží k fixování bugů
    • Větve enh/<num> slouží k vylepšení stávajících funkcionalit
  • Merge requesty + commity
    • Žádný kód nesmí jít přímo do main/dev větví - pro každý commit využíváme merge requesty do dev větve
    • Code Review - každý merge request musí být schválen jiným členem z týmu
    • Při vytváření merge requestu zvolte minimálně jednoho člena týmu, který vám udělá CR
    • Každý merge request by měl obsahovat stručný popis toho, co se do kódu přidalo
    • Každý merge request/commit by měl obsahovat na začátku číslo tasku (pokud není task definován, tak použít např. označení #NoUS - No User Story)
    • Do mainu se merguje až po konci iterace, kdy se demo ukazuje zákazníkovi
    • Každý merge request bude řešit pouze jednu storku - nekombinujme víc věcí dohromady!
  • Formát commit message a merge request: [re #číslo_tasku] Message_co_se_udelalo
  • Příklady:
    • [re #465465] Created form for selecting data source
    • [re #1679684] Fixed issue where data source could be null

Jak operovat s větvemi?

  • Stáhnutí nejnovějších změn
    1. git checkout dev
    2. git pull
  • Jak vytvořit novou větev?
    1. git checkout -b nazev_vetve
    2. Tento příkaz vytvoří novou větev nazev_vetve z větve, ve které se aktuálně nacházíte (ujistěte se, že jste ve větvi dev a máte stáhnuté nejnovější změny)
  • Jak se přepnout do existující větve?
    • git checkout nazev_vetve
  • Vytvoření merge requestu (jsme ve vetvi nazev_vetve)
    1. git add .
    2. git commit -m "[#15134] Created new DB schema"
    3. git push origin nazev_vetve
    4. Přejděte do GitLabu, kde se objeví návrh na nový merge request -> zvolte merge request z vaší větve do větve dev
  • Merge z devu do mainu
    • Bude se dělat ručně přes GitLab
  • Jak řešit konflikty?
    1. Stáhněte si nejnovější verzi devu - git checkout dev a git pull
    2. Přejděte do vaší větve , na kterou chcete rebasovat - git checkout vase_vetev
    3. Začněte rebasovat - git rebase dev
    4. Postupně řešte konflikty a ukládejte vyřešené konflikty pomocí git add . a git commit -m "[#15134] xxx - rebase"
    5. Pokračujte pomocí git rebase --continue, dokud nevyřešíte všechny konflikty
  • Konvence souborů
  • Konvence v kódu
    • Pro názvy atributů a metod používáme CamelCase

Redmine

Názvy úkolů

  • Název storky je zásadně v češtině, stručný a srozumitelný
  • Každá storka musí mít vyplněnou poznámku obsahující detailní informace
  • Název storky má začínat klíčovým slovem v angličtině se všemi velkými písmeny
  • Klíčové slovo slouží k označení rozsáhlejších úkolů, které se skládají z více storek seskupených dohromady
  • Zatím existují tato klíčová slova:
    • ADMINISTRATION = administrace
    • ANALYSIS = analýza problémů
    • ARTIFACT = sepsání artefaktů
    • CODE = blíže neurčená implementace kódu
    • CICD = úprava CICD pipeline na GitLabu
    • DATABASE = práce se SPADe databází
    • DOCKER = modifikace Docker
    • GIT = úprava GitLabu
    • JIRA = implementace Jira pumpy
    • MEETING = schůzky
    • WIKI = úprava wiki na Redmine
  • Tvorba nových klíčových slov je povolena, důležité je, aby se shodovala se souvisejícími storkami
  • Vytváření nových klíčových slov je povoleno, důležité je, aby byla stejná mezi souvisejícíma storkama

New chat

Druhy úkolů

  • Bug
    • Neočekávané chování
    • Neúmyslná chyba
  • Enhancement
    • Dokumentace
    • Artefakty přidávající zadavateli hodnotu
    • Funkcionalita popsaná ve specifikaci požadavků
  • Feature
    • Nová funkcionalita nad rámec specifikace požadavků
  • Task
    • Administrativa
    • Analýzy

Druhy aktivit

  • Analysis = studium, analýza problémů, návrh architektury
  • Design = návrh GUI
  • Implementation = implementace funkcí, opravování chyb
  • Verification = kontrola požadavků
  • Documentation = psaní dokumentací – uživatelské, programátorské, psaní dokumentačních komentářů
  • Administrative = vytváření storek, schůzky, psaní artefaktů

Druhy priorit

  • Low = nejméně prioritní úkol – drobnosti
  • Medium = normální úkol – psaní dokumentů, nice-to-have funkce
  • High = prioritní úkol – schůzky, důležité funkce
  • Urgent = nejvíce prioritní úkol – hotfixy, bugy vedoucí k pádu aplikace

Stav úkolů

  • New = nově vytvořený úkol, který ještě nebyl nikomu přiřazen
  • Assigned = přiřazený úkol konkrétnímu členovi/členům
  • Resolved = vyřešený úkol čekající na akceptaci (akceptaci provádí autor úkolu – ověření, že daná funkce je opravdu to, co autor očekával)
  • Closed = uzavřený úkol (po akceptaci)

Autor: Milan Janoch + Štěpán Faragula
Datum: 15.3.2025
Stav: hotový

Aktualizováno uživatelem Štěpán Faragula před 17 dny(ů) · 15 revizí