RSM US & USI – Collaboration Process

RSM US & USI – Collaboration Process. Agenda: Introduction ADO Adoption & Collaboration (US/Offshore) Development & Deployment Approach Test Approach/Strategy Open Questions Q & A..

RSM | 2. One Week Sprint Cadence Monday Sprint n- Planning Sprint Review Sprint Retrospective Tuesday Daily Stand Up Wednesday Daily Stand up Thursday Daily Stand Up Backlog Refinement Friday Daily Stand Up Onshore Offshore — SyncUP Dally ..

RSM | 3. Meeting structure Ceremonies Sprint Planning Grooming + Design (180)* (4R Technique) * - The discussion will happen for the upcoming sprint stories. Daily scrum (15') Sprint Review and Demo Sprint Retrospective Scrum Poker Onshore/ Offshore - SymUp Week 1 WED THU MON x x x TUE x x FRI x x x x Sprint Planning: PO + BA + Dev + QA Team. Daily Scrum: Scrum Team. Sprint review + Demo: Scrum Team + BA + Stakeholders (if any). Sprint Retrospective: Scrum Team. Sync-up: Scrum team + Onshore technical team. *Scrum Team: POIBA + Dev Team + QA + SM. Note : - The above timings - TBD x x x x x.

DEVELOPMENT & DEPLOYMENT PROCESS. RSM | 4.

RSM | 5. Azure DevOps is a powerful platform that offers a suite of tools for project management, version control, and CI/CD. It provides a seamless environment for teams to collaborate and deliver high-quality software. CREATING PROJECTS: Efficient project creation involves defining clear goals, establishing work items, and setting up sprints. Utilize Azure DevOps' project templates to streamline the process and ensure a structured foundation for your team. UNDERSTANDING GIT: Git is a distributed version control system that allows for efficient collaboration and code management. It provides a robust framework for tracking changes and managing code repositories. SETTING UP GIT IN AZURE DEVOPS: Integrating Git into Azure DevOps involves creating a Git repository, establishing branching strategies, and configuring build and release pipelines for continuous integration and deployment..

RSM | 6. Implementing code reviews and pull requests in Git enables collaborative code validation and ensures high code quality. This fosters a culture of continuous improvement and knowledge sharing. BRANCHING STRATEGIES: Effective branching strategies such as feature branching and release branching are essential for managing code changes and facilitating parallel development. AUTOMATED TESTING AND CONTINUOUS INTEGRATION: Leveraging automated testing and continuous integration with Git in Azure DevOps enhances code quality and accelerates the development process. It enables early detection of issues and seamless integration of code changes. RELEASE MANAGEMENT WITH GIT: Git in Azure DevOps facilitates streamlined release management by enabling release pipelines and deployment strategies. This ensures efficient delivery of software to production environments..

RSM | 7. Below illustration is the proposed workflow for the code commits and the pull requests for the branches in the Azure Repos.

OUR PROPOSED BRANCHING DEPLOYMENT STRATEGY. Managing all the source code changes Tracking all code changes Enabling multiple developers to work on the same project simultaneously PRIMARY BRANCHES: MAIN/MASTER: The primary branch where all the production code is stored. Once the code in the “develop” branch is ready to be released, the changes are merged to the master branch and used in the deployment. DEVELOP: *OPTIONAL This is where all the actual development happens. All the pre-production code is stored here, and the completed code of all the supporting branches is merged directly to the develop branch. SUPPORT BRANCHES: FEATURE, HOTFIX AND RELEASE During the development, developers create different branches for specific use cases using the develop branch as the base. This strategy was aiming to provide a simple and lightweight approach to manage the development. It adheres to the following guidelines when managing the source control with a single primary branch which is main.

TEST STRATEGY & APPROACH. RSM | 9. [image] iiiiii"IåKhE iii iii .eggn__—.

RSM | 10. 2. 3. 4. 5. 6. 7. 8. Table of Contents Introduction.................................. 1.1 Purpose of this Document ................................... 1.2 Test Objectives......................................................................................................................................3 Testing Levels Overview......................................................................................................................a Meetings.................................................................................................................................................5 Measures and Metrics ..........................................................................................................................6 Risks Assumptions ..........................................................................................................................................6 External Testing Scope ...................... 2.1 2.2 In Scope for Testing Out of Scope for Testing Approach to Testing .......................................................................................................................... 4 3.1 3.2 3.3 3.4 3.5 3.6 Assumptions, Constraints, and 4.1 4.2 4.3 4.4 Testing Roles and Responsibilities .................................................. Test Tools .................................................................................. .. T raing Risks Constraints............ Test entry and Exit Criteria.............................................................................. Test Entry and Exit Criteria................................... Exit Criteria ..................................................................... Test Deliverables ......5 ......5 ......6 ......8 5.1 5.2 Test Test Environments/lnstances automation ...

RSM | 11. TEST STRATEGY & SIGN OFF. Dev Instance Unit Testing Instance Build Verification Test est Scenario Identification est Scenario [Cases Unit Test Results UAT Instance moke Testing Release Check List Execution — QA to share it with business. Go/No-Go uthorization with business. Release Notes - Publishing PROD Go-Live deployment & nnouncement by the ech architect. Go-Live Announcement emplate — TBD. (email o be shared with all takeholders). cheduled eployment Creation est Cases Walkthrough est Cases - Sign off. Execution Defect Identification QA Sign off - UAT Deployment uthoring Test Plan & ign off..

OPEN QUESTIONS. RSM | 12. [image] iiiiii"IåKhE iii iii .eggn__—.

RSM | 13. RSM & SoO – TBD, Need to understand their setup.

Q&A. RSM | 14. [image] iiiiii"IåKhE iii iii .eggn__—.

THANK YOU!. RSM | 15. [image] iiiiii1EZLLlLE! iii.

AGILE AND QA KPIS DASHBOARDS. RSM | 16. [image] iiiiii"IåKhE iii iii .eggn__—.

RSM | 17. KPI DASHBOARDS. Tracking Field In ADO 1 2 3 4 5 6 7 8 9 10 11 12 14 15 16 KPI Total Work capacity Total Work Capacity Dev (Story Points) Total Work Capacity Miscellaneous (Story Points) Committed Sprint capacity (Development) — 4 Weeks Value Area - Functional & Technical Committed Sprint capacity (Miscellaneous - Feature) - 4 weeks Value Area - General Tasks (Bug, Impact analysis, Tech debt, TDD, refinements, sprint planning meeting, POC egg) Estimation variance -( for 4 weeks) for User story with Value Area Functional, and Technical User Stow Acceptance Ratio Feature Acceptancy Ratio Functional user story to technical user story Ratio (%) for value ara functional and technical Capacity utilization for support : Support definition - Any production incident that requires code change only for m•ssed technical requirements First time right (UAT) : (excluding PROD defects) First time right ( PROD) Defect Leakage in QC Defect Leakage in UAT (%) Defect Leakage in Production (%) Depth of Defect Backlog Target 85% of Total Work Capacity 15% of Total Work Capacity of Total Work Capacity 15% of Total Work Capacity 85% to 115% - 95% No RAG No RAG No RAG RAG Indicator — Applicable — Applicable — Applicable Green — On Target Range Amber - +/- 15% within target value Red - +/_ greater than 15% target value No target, to be used for analysis No RAG— Lower % is better Green — On Target Amber - +/- 15% within target value Red -+/- greater than 15% target value 15% less than previous Pl..

RSM | 18. KPI Dashboards – ADO field and Owner Mapping (1/2).