feat(team-process): IPCEICIS-724, WiP, to be discussed in arch session

content/en/docs/project/team-process/_index.md

@@ -5,18 +5,35 @@ description: The way we work and produce runnable, presentable software
 linkTitle: Team-Process
 ---
 
-## Rationale
+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.
 
-This document describes a proposal to set up a team work structure to primarily get the POC successfully delivered. In the latter we will adjust and refine the process to fit for the MVP.
+## Introduction
+
+### Rationale
+
+We current face the following [challenges in our process](https://confluence.telekom-mms.com/display/IPCEICIS/Proof+of+Concept+2024):
+
+1. missing team alignment on PoC-Output over all components
+    1. Action: team is committed to **clearly defined PoC capabilities**
+    1. Action: every each team-member is aware of **individual and common work** to be done (backlog) to achieve PoC
+1. missing concept for repository (process, structure, 
+    1. Action: the **PoC has a robust repository concept** up & running
+    1. Action: repo concept is applicable for other repositorys as well (esp. documentation repo)
 
 ### General working context
 
-We are a **team** and create in an agile manner **output** to fulfill a **project goal**. The **backlog** holds the specification by which we imperatively manufacture by use of **tasks**.
+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).
 
 ![alt text](./_assets/P1.png)
 
+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.
 
 ![alt text](./_assets/P2.png)
@@ -36,40 +53,58 @@ In the following we will look at the work structure proposal, primarily for the
 
 ![alt text](./_assets/P4.png)
 
-### Todos
+#### Todos
 
-1. a
+1. SHOULD: Clarify context (arch, team, leads)
-1. b
+1. MUST: Define Deliverables (arch, team) (Hint: Deleiverables could be seen 1:1 as use cases - not sure about that right now)
-1. c
+1. 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)
+
 ![alt text](./_assets/P5.png)
 
 ### 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
+
 ![alt text](./_assets/P6.png)
 
+#### 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
-1. each repo has a main and development branch. development is the intgeration line
+1. each repo has a main and development branch. development is the intgration line
 1. pull requests are used to merge work outputs to the integration line
 1. optional (my be too cumbersome): each PR should be reflected as comment in jira
 
-#### Workflow
+#### Workflow (in any task / user story)
 
-1. `git init` --> always create as fast as possible a new repo
+1. when output comes in own repo: `git init` --> always create as fast as possible a new repo
 1. commit early and oftenly
-1. comment on tickets
+1. 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. 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! 
+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