Home
This page will guide you through the main lean principles applying to this project, its processes, how you can participate.
In general, the following applies to the IRS:
The Catena-X data sovereignty principles apply to the Item Relationship Service Data Access, policies, and contract negotiation will be done by the EDC The IRS simplifies the interaction with data chains, which are based on the digital twin concept and the designed relationships between these digital twins.
The IRS enables to apply business logic along a distributed data chain, for example aggregation of certificates along the value chain.
Ad-hoc development of continuous data chains across company boundaries for empowerment of the use cases Circular Economy, Traceability, Quality and the European supply chain act.
A working agreement is a document, or a set of documents, that describe how we work together as a team and what our expectations and principles are. The working agreement is created by, aligned & discussed within the team at the beginning of the project, and is stored in Confluence so that it is readily available for everyone working on the project.
-
We work as one team towards a common goal, vision and clear scope.
-
We make sure everyone’s voice is heard and listened to.
-
Furthermore, we show all team members equal respect.
-
We make sure to spread our expertise and skills in the team, so no single person is relied on for one skill.
-
Meetings longer than 30 minutes should start 5 minutes later
-
Technical Excellence - Keep on improving, stabilizing, improving quality of this project at any time
-
Thinking about testing
-
Clean Code
-
Technical Excellence Thinking
-
-
Continuous Improvement Towards Perfection
-
Lean Thinking
-
Keep break the complexity down
-
Our central communication channel in Catena-X’s Teams is https://matrix.to/#/#tractusx-irs:matrix.eclipse.org.
-
For Tractus-X project, relevant topics use https://matrix.to/#/#tractusx:matrix.eclipse.org
-
If you need to get in contact with the Catena-X e.v. association, use: https://catena-x.net/en/offers-standards/item-relationship-service or info@catena-x.net
All project specific communication will be handled within this repository. Use:
-
issues for bugs, or security vulnerabilities
-
comments to participate on features or stories topics
-
discussions to participate an conceptual work
-
chat to get direct contact with the team https://chat.eclipse.org
more information on how to be part of the community: https://eclipse-tractusx.github.io/community/
-
Our core office hours, when we can expect to collaborate via Microsoft Teams, phone or face-to-face are Monday to Friday 9AM - 4PM CE(S)T ,
-
We are not expected to answer emails/messages outside working hours, on weekends or when we are on holidays or vacation.
-
Meetings which take place in addition to the Scrum ceremonies should happen in the afternoon, the morning should stay free for focussed work and/or internal meetings.
-
We record meetings when possible, so that team members who could not attend live can listen later.
-
We agree on the linked Definition of Done (DoD) for our user story’s and sprints and live by it.
-
We agree on the linked Definition of Ready (DoR) for our user story’s and sprints and live by it.
-
The DoD is subject to regular inspection and improvement and should be synchronized with all relevant teams.
-
Visualize and limit WIP
-
Address bottlenecks
-
Minimize handoffs and dependencies
-
Get faster feedback
-
Work on smaller batches
-
Reduce queue lengths
-
Optimize time "in the zone"
-
Remediate legacy policies and practices
The Scrum Master is responsible for leading any Scrum or Agile practices to enable the project to move forward.
-
Facilitate standup meetings and hold team accountable for attendance and participation.
-
Keep the meeting moving and give methodical guidance.
-
Make sure all action items are documented and ensure each has an owner and a due date and tracks the open issues.
-
Notes as needed after planning / stand-ups.
-
Make sure that items are moved to the parking lot and ensure follow-up afterward.
-
Maintain a location showing team’s work and status and removing impediments that are blocking the team.
-
Hold the team accountable for results in a supportive fashion.
-
Make sure that project and program documentation are up-to-date.
-
Guarantee the tracking/following up on action items from retrospectives (iteration and release planning) and from daily standup meetings.
-
Facilitate the sprint retrospective.
-
Coach Product Owner and the team in the process, as needed.
-
We work together on a Definition of Ready (DoR) on Feature and User Story level and all related issues assigned to a sprint need to follow this
-
We communicate what we are working on through the board
-
We assign ourselves a task when we are ready to work on it (not before) and move it to active
-
We capture any work we do related to the project in a user story/task
-
We close our tasks/user stories only when they are done (as described in the Definition of Done)
-
We work with the Product Owner if we want to add a new user story to the sprint.
-
If we add new tasks to the board, we make sure it matches the acceptance criteria of the user story (to avoid scope creep).
-
If it doesn’t match the acceptance criteria, we should discuss with the PO to see if we need a new user story for the task or if we should adjust the acceptance criteria.
-
Gherkin syntax is used to define acceptance criteria. Refer to Behavior driven development (BDD)
-
Create a pull request in GitHub
-
Ask a team member to perform the review, in the daily and assign the ticket accordingly. Assign the PR and the ticket to the team member. Note: reviews * should take precedence over starting new stories. Getting some things done is better than starting many things.
-
The reviewer checks the implemented ticket for correctness, completeness and quality and leaves comments in the PR or the ticket if necessary.
-
If the ticket is completed, the ticket will be assigned to the PO.
-
After PO acceptance, the PR is merged and the ticket is set to <DONE>.
-
If changes are necessary, assign the ticket back to the developer and repeat the cycle.
-
To achieve a uniform standard, follow Google’s Code Review Developer Guide as described here Code-Review
%%{init: {'theme':'dark'}}%%
flowchart LR
0([new issue\n bug\nsecurity finding])
inbox([inbox])
backlog([backlog])
next(next)
wip(wip)
test(test)
inr(review)
done(done)
0 --> inbox
inbox -.->|refinement\nmeeting| backlog
backlog -.->|iteration planning\nmeeting| next
next -.-> wip
wip -.-> test
test -.-> inr
inr -.-> done
style inbox fill:#2d333b,stroke:#444c56,stroke-width:0.5px,color:#768390
style backlog fill:#4184e41a,stroke:#4184e466,stroke-width:0.5px,color:#539bf5
style next fill:#46954a26,stroke:#46954a66,stroke-width:0.5px,color:#57ab5a
style wip fill:#ae7c1426,stroke:#ae7c1466,stroke-width:0.5px,color:#c69026
style inr fill:#cc6b2c1a,stroke:#cc6b2c66,stroke-width:0.5px,color:#cc6b2c
style done fill:#986ee21a,stroke:#986ee266,stroke-width:0.5px,color:#986ee2
Issues which have already been sighted and some first refinement has been conducted. Issues within the backlog are reasonable items, which will be further dealt within the development of this project. The issue needs to match to the vision and mission of this project!
This State reflects a Sprint based log of issues, which are planned to be finished within the sprint.
Issues on which the review process and test are being conducted.
-
Ask a team member to perform the review, in the daily and assign the ticket accordingly. Assign the PR to the team member.
-
PR’s should take precedence over starting new tasks. Getting some things done is better than starting many things.
-
The reviewer checks the implemented ticket for correctness, completeness and quality and leaves comments in the PR or the ticket if necessary.
-
If changes are necessary, comment it in the pull request.
-
To achieve a uniform standard, follow Google’s Code Review Developer Guide
This status will not be part of the boards. If tickets need to be close, which will not be implemented, the Github functionality to close an issue is being used!
-
Issue The User Story has a short and comprehensive summary/title
-
Person, who is responsible for getting the user story within one iteration done.
-
User Story As a <type of user>, I want <specific goal> so that <specific reason>.
-
Linked Issues is used to show up dependencies and links to parent features
-
The User Story is estimated (Story Points) (e.g. using the Fibonacci sequence). (The effort involved in documentation, creation of test cases, implementation of the non-functional requirements, if applicable, etc. must also be taken into consideration.)
-
The User Story has sufficient acceptance criteria and is accepted by the team
-
Acceptance Criteria is written in the GIVEN-WHEN-THEN format, if applicable.
-
The non-functional requirements applicable to the User Story are mentioned and accepted by the team
-
Are all acceptance criteria of the user story met?
-
Has the user story been approved by the product owner?
-
Does the user story have no open "high" and "critical" defects?
-
Has a code review been performed?
-
Successful business and technical tests if applicable
-
Were the code conventions for the implementation followed?
-
Is the application deployed on the integration/production environment?
-
Have all system, integration and user acceptance tests been successfully executed and documented?
-
Is the user, operations, and maintenance documentation updated to include the user story content?
-
Changelog CHANEGLOG.md is updated
-
Is the developer documentation created?
-
Has the user story been approved by the test manager
-
PullRequest to Tractus-X was opened.
-
In case of new dependency - IP Clearing (DASH) Tool was executed
-
Eclipse intellectual property check was executed
-
Commits according to the following convention:
see ConventionalCommits.org for more information<type>(optional scope):[<Ticket_ID>] <description>
The goal is that the maximal life cycle of a pull request: 1.5 days.
Steps:
-
Every developer creating a pull request is responsible to assign a reviewer.
-
Please check the availability of a reviewer.
-
If Review needs to be planned: Use PR’s or Issues comment functionality to get in contact with a project committer
-
main dev work is done on feature branches
-
Branches must be prefixed according to their nature:
-
feature/* - for implementing user stories
-
fix/* - for fixing bugs that appeared in the main branch
-
chore/* - any small change without any impact on the software Branch Name:
-
-
MUST contain: Subject of issue (Abbreviation of Issue without using spaces / use "-" to connect)
-
product documentation is managed here
