Liquid Hub consulting solutions outsourcing AN AGILE DEVELOPMENT

Liquid. Hub consulting | solutions | outsourcing AN AGILE DEVELOPMENT METHODOLOGY THE CODE REVIEW PROCESS The Agile Process Team Brad Huett Megan Schmid Erich Villasis Siva Natarajan Bryce Budd Thursday, December 23, 2021 Don Kasner Dave Latham Steven Hill fueling business transformation

What are the Code Review Roles? The Code Review Roles: The Code Review Manager – There is one Code Review Manager and this role is responsible for an efficient Code Review Process. This role assigns the Code Review Leads and Technologists for the Sprint reviews. These assignments should be a Client resources, if possible The Code Review Lead – This role leads the review and guarantees that the success criteria defined in the items below are met. The Code Review Lead is the 3 rd level of code base understanding and is available for development work should the Primary and secondary development resources are not available for bug or feature / functionality change requests. This role should be a Client resource, if possible. The Code Technologist – This role monitors all activities of the Code Review and ensures that a clear understanding of the code base is created in their mind. The Code Technologist is the 2 rd level of code base understanding and is available for development work should the Primary development resource are not available for bug or feature / functionality change requests. This role should be a Client resource, if possible. The Code Developer – This role has developed the code and brings the QA Objective requirements to the Code Review along with meeting the prerequisites stated below. The Code Developer is the 1 st level of code base understanding and is the Primary development resource for bug or feature / functionality change requests. 2 fueling business transformation

What is the Delivery Review? The Delivery Review Each Code Review requires the following items to be validated. Most of them are self-explanatory. This list should act as a “Check List” during the Code Review: # 3 The Prerequisite Items, Knowledge and Actions Responsible Role 1 User Story has Assigned Code Review Lead and Code Technologists Code Review Manager 2 Primary Developed Code Knowledge Responsibility Developer 3 Secondary Developed Code Knowledge Responsibility Code Technologist 4 Alternate Developed Code Knowledge Responsibility Code Review Lead 5 Developed Code has Single Unit of Work, Unit Tests, whenever Possible Developer 6 All New Software Entities and Dependencies are in the Test Assembly Code Review Lead 7 The Code Passes all Unit Tests in the Test Suite Runner Code Review Lead 8 The Code Tests Happy and Primary Sad Tests: Conditionals and Exceptions Code Review Lead 9 The Code Structure Meets the Current Criteria Code Review Lead 10 The QA Objective has Been Delivered Developer 11 The QA Objective is Able to be Performed Developer 12 A List of Development Changes is Created Developer 13 A Revisited Code Review is Scheduled, if Required Code Review Lead 14 The Code is Understood at a Level that Facilitates a Secondary Knowledge Level Code Technologist 15 An Estimated Level of Effort Required to Get to the Integration Review Developer 16 In Conclusion - Query for Questions, Issues and Potential Blocks Code Review Lead fueling business transformation

What is the Integration Review? The Integration Review After the Sprint User Story Development status is moved from the Code Review status to the Code Integration status the developed code is migrated to the QA environment. The QA environment for Integration Development and QA Objective validation will help to ensure that any infrastructure dependencies are consumed in a fashion similar to the Client-facing environments. Exercising the QA Objective in the same environment as QA with is using helps to minimize the “Bugs” that should be found by the Development Team and not left to the QA Team to identify. This should deliver code to QA that exceeds a 95 – 5 percent paradigm of success. This process leaves the QA Team with the time and resources to find issues that neither the Development or QA teams thought of during the Sprint process. Each Integration Review will validate the replacement of Mock and Stub dependencies with real Infrastructure dependencies. This list should act as a “Check List” during the Integration Review: # 1 2 3 4 5 6 7 8 9 4 The Prerequisite Items, Knowledge and Actions Validate that the Code is in the QA Environment Ensure that Unit Tests have been moved to a Test Region and Ignored Validate that the Integration Tests are Validating the Return Object Content Only Run the Integration Tests and Validate Success: Happy and Sad Paths Validate that the Code Standards and Best Practices have not been Violated Run the QA Objective: The QA Teams Test Suite Validate that all of the QA Test Suite Passes Create Green Spec. Flow Tests and Validate Results In Conclusion - Query for Questions, Issues and Potential Blocks fueling business transformation Responsible Role Code Review Lead Code Review Lead Developer Code Review Lead

In Conclusion: The Code Review Process Code Review and Quality Assurance The successful completion of the Integration Review will set the Spec. Flow Web display to GREEN. This will be the state that is required to move the development tasks out of the IN PROGRESS JIRA status to the IN QA JIRA status. When a bug is discovered the development task is returned to RED. When all bugs are resolved and the “Definition of Done” is met then both the Development and QA Spec. Flow report will be set to GREEN. The GREEN status signified that the Sprint User Story is a candidate for Stakeholder Demonstration. 5 fueling business transformation