edp-doc/docs/technical-documentation/project/team-process/_index.md

title	weight	description	linkTitle
Team and Work Structure	50	The way we work and produce runnable, presentable software	Team-Process

This document describes a proposal to set up a team work structure to primarily get the POC successfully delivered. Later on we will adjust and refine the process to fit for the MVP.

Introduction

Rationale

We currently face the following challenges in our process:

1. missing team alignment on PoC-Output over all components
   1. Action: team is committed to clearly defined PoC capabilities
   2. Action: every each team-member is aware of individual and common work to be done (backlog) to achieve PoC
2. missing concept for repository (process, structure,
   1. Action: the PoC has a robust repository concept up & running
   2. Action: repo concept is applicable for other repositorys as well (esp. documentation repo)

General working context

A project goal drives us as a team to create valuable product output.

The backlog contains the product specification which instructs us by working in tasks with the help and usage of ressources (like git, 3rd party code and knowledge and so on).

Goal, Backlog, Tasks and Output must be in a well-defined context, such that the team can be productive.

POC and MVP working context

This document has two targets: POC and MVP.

Today is mid november 2024 and we need to package our project results created since july 2024 to deliver the POC product.

Think of the agenda's goal like this: Imagine Ralf the big sponsor passes by and sees 'edge Developer Framework' somewhere on your screen. Then he asks: 'Hey cool, you are one of these famous platform guys?! I always wanted to get a demo how this framework looks like!'
What are you going to show him?

Team and Work Structure (POC first, MVP later)

In the following we will look at the work structure proposal, primarily for the POC, but reusable for any other release or the MVP

Consolidated POC (or any release later)

Responsibilities to reliably specify the deliverables

Todos

1. SHOULD: Clarify context (arch, team, leads)
2. MUST: Define Deliverables (arch, team) (Hint: Deleiverables could be seen 1:1 as use cases - not sure about that right now)
3. MUST: Define Output structure (arch, leads)

Process (General): from deliverables to output (POC first, MVP later)

Most important in the process are:

• traces from tickets to outputs (as the clue to understand and control what is where)
• README.md (as the clue how to use the output)

Output Structure POC

Most important in the POC structure are:

• one repo which is the product
• a README which maps project goals to the repo content
• the content consists of capabilities
• capabilities are shown ('prooven') by use cases
• the use cases are described in the deliverables

Glossary

• README: user manual and storybook
• Outcome: like resolution, but more verbose and detailled (especially when resolution was 'Done'), so that state changes are easily recognisable

Work Structure Guidelines (POC first, MVP later)

Structure

1. each task and/or user story has at least a branch in an existing repo or a new, dedicated task repo

   recommended: multi-repo over monorepo

2. each repo has a main and development branch. development is the intgration line
3. pull requests are used to merge work outputs to the integration line
4. optional (my be too cumbersome): each PR should be reflected as comment in jira

Workflow (in any task / user story)

1. when output comes in own repo: git init --> always create as fast as possible a new repo
2. commit early and oftenly
3. comments on output and outcome when where is new work done. this could typically correlate to a pull request, see above

Definition of Done

1. Jira: there is a final comment summarizimg the outcome (in a bit more verbose from than just the 'resolution' of the ticket) and the main outputs. This may typically be a link to the commit and/or pull request of the final repo state
2. Git/Repo: there is a README.md in the root of the repo. It summarizes in a typical Gihub-manner how to use the repo, so that it does what it is intended to do and reveals all the bells and whistles of the repo to the consumer. If the README doesn't lead to the usable and recognizable added value the work is not done!

Review

1. Before a ticket gets finished (not defined yet which jira-state this is) there must be a review by a second team member
2. the reviewing person may review whatever they want, but must at least check the README

Out of scope (for now)

The following topics are optional and do not need an agreement at the moment:

1. Commit message syntax

   Recommendation: at least 'WiP' would be good if the state is experimental

2. branch permissions
3. branch clean up policies
4. squashing when merging into the integration line
5. CI
6. Tech blogs / gists
7. Changelogs

Integration of Jira with Forgejo (compare to https://github.com/atlassian/github-for-jira)

1. Jira -> Forgejo: Create Branch
2. Forgejo -> Jira:
   1. commit
   2. PR

Status of POC Capabilities

The following table lists an analysis of the status of the 'Funcionality validation' of the POC. Assumption: These functionalities should be the aforementioned capabilities.