RSM US & USI – Collaboration Process

[Audio] Hi team welcome the collaboration process between R-S-M U-S and RSM USI session It involves seamless integration of code development practices utilization of Azure DevOps (A-D-O--) for project management and structured testing and deployment pipeline. To familiarize on the same we have created our presentation on the similar lines which includes A-D-O Adoption & Collaboration Development & Deployment Approach Test Strategy/Approach..

[Audio] To facilitate efficient collaboration between R-S-M U-S and R-S-M U-S-I adopting Agile methodology with Azure DevOps (A-D-O--) can streamline processes. Here we have taken a sprint with 1 week cadence to explain the ceremonies Offshore/US syncup schedule et cetera We will also be discussing on the work item types configured for this 1 week sprint. Key elements like sprints features user stories tasks capacity planning bugs and backlogs A sprint is a set period during which specific work has to be completed and made ready for review. Sprints are fundamental to the Agile methodology offering a structured approach to project management and delivery. Sprint Duration: It’s a 1-week sprint depends upon the requirement we can change to 2 or 3-week sprint. Sprint Planning (Daily standups: A daily 15-minute meeting for the team to synchronize activities and create a plan for the next 24 hours.): In the sprint planning we can assign tasks Selecting user stories from the backlog. Breaking down user stories into tasks. Estimating effort and setting the sprint goal. Sprint Backlog: Sprint Retrospective: Reflect on the sprint process and make continuous improvements. What went well during the sprint? What didn't go well? What can we improve in the next sprint?.

[Audio] Backlog: The backlog is a prioritized list of work for the development team derived from the product roadmap and its requirements. It contains a comprehensive list of features bug fixes and technical tasks needed to deliver a viable product. The product owner maintains the backlog continually adding prioritizing and refining items based on stakeholder feedback and business goals. Epics to Features: Large initiatives or goals are identified and documented as epics. Each epic is broken down into manageable features that represent significant product functionalities. This breakdown helps in organizing work and setting clear milestones for the team. Features to User Stories: Features are further decomposed into user stories capturing the detailed requirements and user expectations. Each user story is crafted to deliver specific user value and can be independently implemented and tested. User Stories to Tasks: Development teams take user stories and break them down into smaller actionable tasks. This decomposition helps in planning assigning and tracking work more effectively. Tasks provide clear guidelines on what needs to be done ensuring no details are overlooked. Capacity Planning: The total amount of work a team can handle during a sprint based on the team's available hours and velocity. Depends upon the team's members availability including holidays vacations and other commitments we can plan the capacity. Work Details: Here we get the work details of team members. Burndown Chart Definition: A graphical representation that shows the amount of work remaining versus the time left in a sprint or project. Purpose: To track the progress of a sprint and help the team understand if they are on track to complete all planned work by the end of the sprint. Benefits of Using a Burndown Chart Visibility: Provides a clear visual representation of the team's progress making it easy to see if the team is ahead or behind schedule. Early Warning: Identifies potential issues early allowing the team to address them before they become major problems. Improvement: Facilitates continuous improvement by highlighting areas where the team may need to adjust their approach or processes. Bugs and Bug Tracking Backlogs Azure DevOps Dashboards play a critical role in providing real-time insights into project progress and performance metrics. Custom dashboards are created to track various aspects of the development lifecycle including build statuses code coverage work item tracking and deployment progress. These dashboards facilitate transparent communication between the U-S and U-S-I teams allowing stakeholders to make informed decisions based on accurate and up-to-date information..

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.

[Audio] Effective code development is the cornerstone of any software project. Both R-S-M U-S and U-S-I leverage best practices in version control code reviews and collaboration tools. Utilizing Azure Repos for managing source code the teams follow a robust branching strategy (such as Gitflow) to streamline feature development bug fixes and release processes. We will quickly walk you through the development & deployment process. Project creation In devops we have project setup and within that we create repos where all customization code resides. Branch creation We have main branch that is master and we cut off develop branch out of it. And all development code will get merged into develop branch only. Code check in So to get code merged into develop branch developer have to raise PR(Pull request) but since these branch have certain branch policy in place which can prevent to merge pr directly. What are those branch policy like required approval work item need to be associated and there should not be any active comments. Apart from this we can setup build pipeline to make sure developed code is not having any build issue and also we can integrate sast tools like sonar qube to take care of security vulnerabilities and code bugs. These PR review process not only enhance code quality but also significantly reduce likelihood introducing bugs. Once all PR get merged into develop branch we cut off feature branch out of it which goes to QA for regression/testing. Deployment: Azure Pipelines are used to automate the build test and deployment processes. The CI/CD pipelines ensure that code changes are continuously integrated tested and deployed to various environments (development staging and production). This automation not only speeds up the delivery process but also enhances the reliability and consistency of deployments. We have created a canvas app to run our ado pipeline. We configured a Yaml pipeline to export and import the solution from dev to QA For the purpose of exporting and importing of solutions we are using power platform build tools and app user (created a service connection for both dev and QA).

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 ...

[Audio] Rigorous testing practices are integral to delivering high-quality software. Unit tests integration tests and end-to-end tests are executed automatically as part of the continuous integration (C-I---) process. This ensures that any defects are identified and addressed early in the development cycle reducing the risk of introducing bugs into the production environment..

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] iiiiii1EZLLlLE! iii.

THANK YOU!. RSM | 15. [image] iiiiii"IåKhE iii iii .eggn__—.

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).