DEVELOPING MAXIMUM VALUE Paul Berryman 2016 Agile DowntoEarth
DEVELOPING MAXIMUM VALUE Paul Berryman 2016 Agile Down-to-Earth © 2016 Agile Down-to-Earth – All rights reserved
DEVELOPING MAXIMUM VALUE Some keys to getting maximum effectiveness from your development teams • Empower Agility (SCRUM, XP, Lean) • Embed Quality (Dev. Ops, the Shift Left) • Architect for Efficiency (Code re-use, Design patterns) © 2016 Agile Down-to-Earth – All rights reserved 1
EMPOWERING AGILITY © 2016 Agile Down-to-Earth – All rights reserved 2
EMPOWER AGILITY SCRUM, XP AND LEAN AGILE All Projects hold fast to these principles: • Business owns vision – must have an empowered Product Owner • • • Support them with a qualified Vision team – SMEs, UX, Tech Leads, Architects Small Batches – Continuous Feedback • Always deliver the Minimally Viable Product (MVP) • Deliver in 6 month increments (maximum) Fully define the release before beginning to Sprint • 80% of User Story details in place • Prioritize and Estimate all User Stories © 2016 Agile Down-to-Earth – All rights reserved 3
NOTE: THE IMPORTANCE OF SMALL BATCHES Nothing is particularly hard if you divide it into small jobs. Henry Ford © 2016 Agile Down-to-Earth – All rights reserved 4
DEVOPS & THE SHIFT LEFT © 2016 Agile Down-to-Earth – All rights reserved 5
WHAT IS DEVOPS? From Gartner Group: • “Dev. Ops is a perspective that requires cultural change, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of an integrated approach. Dev. Ops emphasizes people and culture to improve collaboration between development and operations groups as well as other IT stakeholders such as architecture and information security. Dev. Ops implementations utilize technology, especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective” © 2016 Agile Down-to-Earth – All rights reserved 6
DEVOPS & 14 LEVELS OF QUALITY Test Level 1 2 3 4 5 6 7 8 9 10 11 12 13 Test Target Environment Before development begins Unit Testing IDE Peer Code Review (pre-commit) IDE Over the shoulder Testing IDE Static Code Review IDE Tech Lead Code Review (Post commit)Development / Sys Int Continuous Code Integration Testing Development / Sys Int Functional Testing System Integration Story Acceptance Testing System Integration Regression Testing QA End-to-End Testing / Performance Staging testing Quality Req’s Creation & Verification User Acceptance Testing App Scan Quality Code Deployment & 14© 2016 Agile Down-to-Earth – All rights reserved Verification Accountable Owner / Participants Product Owner Dev QA / Dev Dev ISG / Dev QA Product Owner QA QA Pre-Production Product Owner / End Users Tech Lead Production Ops / Dev UAT 7
SHIFT LEFT – IN THE IDE (THE INDIVIDUAL DEVELOPMENT ENVIRONMENT) Defect detection and prevention in the IDE • TDD, etc. – Create Unit Test before Code is written (NUnit, QUnit, Junit, etc. ) • Test code branch (snapshot) in the IDE • Local Static Code Analysis (SCA) • Peer code review in the IDE (pre-commit) before Check-In • QA Over-the-Shoulder Testing (OTS) © 2016 Agile Down-to-Earth – All rights reserved Check-out Branch Check-in Branch Write Unit Test Within the IDE OTS Peer Review Code solution Run Unit Test Run SCA 8
CONTINUOUS INTEGRATION / CONTINUOUS DEPLOYMENT Use your ‘Dev. Ops’ infrastructure to build your Integration base • Build from head – or snapshot build • No code is to be deployed to Integration if defects are found • C. I. integration engine controls process and error reporting • Build automation (build-once) • Release automation (deployment testing) • All executables in one Binary repository (build-once/deploy many) © 2016 Agile Down-to-Earth – All rights reserved 9
TEST AUTOMATION Use your ‘Dev. Ops’ infrastructure to discover pre-prod defects automatically • Part of the CI/CD stack • Tech Lead code review (optional) • Unit Test automation (using all developers JUnit/QUnit/NUnit) • Regression Test automation (developers Unit Tests + other tools) • Static Code Analysis (ex. Security rules enforcement) © 2016 Agile Down-to-Earth – All rights reserved 10
SAMPLE DEVOPS INFRASTRUCTURE © 2016 Agile Down-to-Earth – All rights reserved 11
ARCHITECT FOR EFFICIENCY © 2016 Agile Down-to-Earth – All rights reserved 12
ARCHITECTING FOR SUCCESS LEARN FROM OTHERS – DO NOT ‘START FROM SCRATCH’ • Code Component Catalog • Architectural Design Patterns • Static Code Analysis rules • Peer Code Reviews • Technical Design Reviews • Defect tracking • Usability Design © 2016 Agile Down-to-Earth – All rights reserved 13
CODE COMPONENT CATALOG Code components should be stored for future re-use • Source code ‘component’ is stored and tagged • Component candidates are ‘approved’ and ‘sanitized’ • Comments in components are very important • Tag with databases/systems; purpose; language; etc. • Catalog must be searchable by tag and by text string • Important: Vendors should be required to use the catalog and copy from there before writing from scratch; and prove that the catalog has nothing they can use before writing custom code ‘from scratch’ © 2016 Agile Down-to-Earth – All rights reserved 14
DESIGN PATTERNS Certain common code/services should follow a formal “Design Pattern” • Establish patterns for typical services • How to read database; how to update record repository; how to retrieve customer ID; how to store to price updates, etc. • Design patterns should have an ‘ID’ • Recommend ‘Patterns of Enterprise Application Architecture’ by Martin Fowler • Important: Vendors should be required to follow design patterns and to prove that design patterns were followed © 2016 Agile Down-to-Earth – All rights reserved 15
STATIC CODE ANALYSIS Some code quality can be enforced with Static Code Analysis (SCA) tools • Security practices should be enforced with SCA • Full code repository should be scanned regularly (daily) • Code findings are scaled – all ‘important/urgent’ should be remediated immediately • SCA tools can be customized to enforce rules that are unique to certain systems – tech lead will ‘own’ rules • Note: Most SCA tools have so many rules already available that you will have to select a sub-set • Most legacy systems will need to be remediated over time or given exceptions when implementing a new SCA tool © 2016 Agile Down-to-Earth – All rights reserved 16
PEER CODE REVIEWS All code should be reviewed by a ‘peer’ before being checkedin • Code reviews can be automated to prevent check-in until peer ‘approves’ code • Peer ID is saved with code snippet to allow for continuous improvement is code has high defect rates • Peer code review should be done in ‘real’ time rather than being added to a ‘to do’ queue • Good technique for enforcing code quality at a vendor, as the peer will be ‘on the hook’ for code quality © 2016 Agile Down-to-Earth – All rights reserved 17
TECH LEAD DESIGN REVIEW RECOMMENDED FOR CODE THAT IS DEVELOPED BY VENDOR TEAMS All code is reviewed by an Tech Lead after check-in but before promotion to system integration environment • Code reviews can be automated to prevent promotion until Tech Lead ‘approves’ code • Code is sent or put in a ‘to do’ queue for Tech Lead to review ASAP • Tech lead looking for best practices – not detailed code approval • Especially important with new vendor or new system © 2016 Agile Down-to-Earth – All rights reserved 18
DEFECT TRACKING Map your defects and source code to track defect rate by system or programmer • Track changes in defect rate (rather than trying to track each individual defect) • Use for ‘continuous improvement’ retrospectives – NOT to punish (Agile has proven that this is counter productive) • Be sure to tag code with User Story ID, programmer, peer reviewer, system, and even expected release date • Track defect rates pre-prod in addition to prod rates to gain a better view of practice standards effectiveness © 2016 Agile Down-to-Earth – All rights reserved 19
USABILITY DESIGN Design and Usability should refer to industry standards • Common Industry Specification for Usability – Requirements • UX design should be discussed before coding is begun © 2016 Agile Down-to-Earth – All rights reserved 20
APPENDIX © 2016 Agile Down-to-Earth – All rights reserved
QUALITY STEPS BY DEVELOPMENT STAGE AND ROLE QA Over-the-Shoulder testing; Nightly SCARC Rules Analysis Operations Continuous Integration Builds; Automated SCARC Enforcement; Release Candidate certification (Build once) Delivery QA Defects automatically sent to development team; Zero defect policy Staging/UAT Delivery Continuous integration; Build Manager; SI oversight; Zero defect policy QA Delivery IDE Focus (Shift Left) TDD - Unit Testing; Peer Code Review; Static Code Analysis; Snapshot builds; Code Quality review System Integration Dev Early Defect Discovery/Testing (Shift Left) Delivery UAT Defects automatically sent to development team; Zero defect policy QA Automated Unit / Functional Testing; Zero defect enforcement QA Automated Regression Testing; Zero defect enforcement QA UAT Defect Tracking; Zero Defect enforcement; E 2 E testing Operations Automated Gold Source deployment to QA Operations Automated Gold Source deployment to Staging/UAT Operations Automated Gold Source deployment to Prod Continuous Integration/Continuous Deployment © 2016 Agile Down-to-Earth – All rights reserved 22
THANK YOU © 2016 Agile Down-to-Earth – All rights reserved
- Slides: 24