BTM - Dev guidelines

# BTM - Dev guidelines ## Coding standards We'll be using the default formatting/naming conventions for .NET (export default from Visual studio). The editorconfig file will part of our repos. ## Branching strategy We'll be using the branching strategy described here https://dev.azure.com/IngEurCDaaS01/IngOne/_wiki/wikis/P01847-RoPlatform-wiki/2881/Release-timeline-and-branching-strategy. ### Example of branch name (for a feature) feature/btm/name-of-your-user-story ### Commit messages We'll try to use meaningful descriptions for our commits (in english) ## PR naming We'll use the same name as the title of the user story. ## PR template It will be part of our repo (through our project template). ## PR gates / branch policies - code coverage (min 80%) - 2 reviewers - work item obligatoriu - build triggered la fiecare push pe feature branch - quality gates? - poate investigam un pic la Sonar # BTM - Agile way of working ## Backlog management As a *product owner?*, when I am defining a new *Feature*, I need to make sure that Feature is linked to an *Epic* and it has start/end dates?? - todo: poate un check cu alex aici [Define features and epics in Azure Boards to organize your product and portfolio backlogs ](https://docs.microsoft.com/en-us/azure/devops/boards/backlogs/define-features-epics?view=azure-devops&tabs=agile-process ) ## Preparing a sprint As a *team member*, when I create a new *user story*, I need to make sure that it is linked to a *Feature*. The newly created *user story* can be moved to a sprint only if it is [ready](#Definition-of-ready) or it can remain in the backlog and it will be groomed in a future *grooming session*. The purpose of a *grooming session* is to get a set of selected user stories(the sprint backlog) into the [ready](#Definition-of-ready) state. We have a grooming session every sprint. In order to make the *grooming* session a success, we created the *pre-grooming* session with the purpose of investigating user stories individually. As a *team member*, in the time interval between the pre-grooming and the grooming, i try to get the user stories that are assigned to me, as close as possible to being [ready](#Definition-of-ready). The purpose of the *planning session* is to define what the next sprint's purpose is. As a *product owner*, i will prioritize user stories and establish the sprint structure. We organize a *planning* session every sprint. As a *product owner*, when i prepare a user story, i need to assess the impact that it could have on product squads, identify the Product Owner and make sure ## During the sprint We meet every day in *daily scrum meetings*. The purpose of these meetings is to get the team aligned and identify anything that might stop the team from reaching the sprint goal. At the beginning of a sprint, all the user stories are `unassigned`. When a user story is `unassigned`, it means that nobody is actively working on it. As a *team member*, before i begin working on a user story, I make sure the user story is [ready](#Definition-of-ready) (it is estimated, has a parent, is well described,acceptance criteria is defined, etc.). If anything is missing, i discuss the *user story* with the *product owner* / other team members and update the description accordingly. As a *team member*, I will not begin working on a user story if it is not *ready*. As a *team member*, when i begin working on a user story, i assign the user story to myself and change the status to `Active`. I then create `tasks` to split the workload and move the tasks on the taskboard [accordingly](#User-story-statuses). A user story that has an `Active` status should have at least one task in status `WIP`. As a *team member*, when a user story is assigned to me, I am *responsible* for getting the story [done](#Definition-of-done) by the end of the current sprint. This means that, by the end of the sprint, I will make sure that the user story is: - code reviewed - tested - the PR is merged - the user story is marked as `Closed` on the taskboard As a *developer*, i make sure i follow the [coding guidelines - TBD] when i write code. As a *tester*, I make sure that my work items are in [ready](https://hackmd.io/OqkWbpuAQrm77UMnKlwV9A#Definition-of-ready-QA-storytask) state before I begin working on it. As a *tester*, when bugs are found on a story, define the bug as a child item for that story. As a *team member*, i can begin working on a new *user story* if all the other user stories that i am assigned to are either in the `Closed` state or are in `Resolved` state but have an assigned team member doing the testing/code review (i have to make sure this is true). As a *team member*, I need to make sure that my work items are linked to a pull request before i ask for a code review / testing. If I want to automatically complete those work items when completing the PR, i check the box to *Complete linked work items after merging*. As a *team member*, when i am assigned to test a *user story*, i need to make sure that the acceptance criteria is defined (i know how to test it and which data to use). If i don't know how to test the user story, i reach out to the *product owner*/*story owner* and find out. If i find no defects, I *approve* the PR. If i find any defects, i add them as comments on the PR and set my vote to "*waiting for author*". ### User story statuses A *user story* can have one of these statuses: * Active *( WIP )* * Resolved *( Implementation completed / Ready to test )* * Closed *([work done](#Definition-of-done))* A *task* or a *bug* can have one of these statuses: * WIP - i am actively working on this task * Testing - i finished dev work and testing is work in progress * Closed - *([work done](#Definition-of-done))* ### Definition of ready A user story is ready if it is immediately actionable. The whole team must understand the "done" criteria and what tests will be performed to demonstrate that the story is complete. - it is linked to a parent *Feature* - it is estimated (the *Story points* field is not empty) - it has a comprehensive *description* - described preferably using Gherkin - it has a comprehensive technical implementation plan - it has acceptance criteria, test data, validated by QA - it clearly defines contracts between BE and FE, when necessary (ideally, we use [openAPI](https://swagger.io/docs/specification/basic-structure/) to describe them) ### Definition of done - unit tests were written - code review was performed - testing was done according to acceptance criteria ( in some cases is also recommended to compare functionality with the old application ( oldrecord / oldritm ) ) - PR is merged (see branching strategy) - story/tasks are `Closed` in Azure Boards - testing status OK from Business Squads ### Definition of ready QA story/task - code review done ( Pull Request has at leat 1 approve by another developer ) - it has acceptance criteria, test data ( e.g. user, client identification ) - environment ( e.g BOX, DEV, ST) - developer's Pull Request and branch to deploy - for automated testing, PO defines the test plan ( in confluence / azure ) ----- __Notite sedinta way of working__ criteriile de acceptanta le scrie PO pe user story si sunt validate ( clare/ suficiente ) de QA la sedintele de pro-grooming/grooming pentru testele automate scrie PO test planul in confluence/azure. Aici facem story separatat pentru Alex de scris teste cand avem task de testat manual pe story, estimarea unui story sa includa efortul tuturor partilor ( dev/ qa) bugurile gasite de QA pe story sunt trecute ca buguri ( story -> bug ) de trecut pe Alex ca reviewer la PRuri