Kend din kvalitet og prisen for den

Transkript

1 Kend din kvalitet og prisen for den

2 Hvem jeg er og hvad jeg vil tale om - Kort om TIA Technology - Scoping og planlægning af releases - Testplanlægning og kvalitetsopfølgning - Omkostningsstyring Flemming Louw Reimer SVP Development, TIA Technology A/S Previously: Head of Software Product Development, EG A/S Chief Technology Officer, Scanjour Vice President, Development, TIA Technology Principal Group Program Manager, Microsoft Director of Program Management, Microsoft Product Unit Manager, Microsoft Product Unit Manager, Navision Director of Service, Damgaard Development Manager, Damgaard

3 Facts of TIA - Software company owned by EQT, headquarter in Denmark - Standard software for property and casualty insurance companies employees across four countries - 57 installations in 30 countries - Driving the market forward since The global TIA partner network consists of more than 1000 implementation specialists with local knowledge TIA Technology

4 Krav specifikation og design spiller en stor rolle for omkostningen forbundet med at kende kvaliteten

5 Scope structure Roadmap Jira (Product manager) Team Jira (Product Owners) TIA Jira (DevOps) Vision Themes (Marketing) Roadmap Features Epics User stories Tasks Enhancement Object page template Product configuration Multi object configuration Object slave TPC screen SVN COMMIT Object slave The digital enabler Claims processing FNOL Question wizard DOS impl ADF coding Milestones Automated real-time management Instant premium calculation Reinsurance on-line Test prep 24-7 Digital enablement Restful services REST services

6 Release planlægning (release manager)

7 Produktions planlægning (VP & product owner) - 6 til 9 måneders horisont - Kapacitet estimeres pr. måned - Personer - Ferie - Fridage - Sygdom - Administration - Uddannelse - Etc. - Features (grov)estimeres ud fra roadmap plan (scope structure) pr. projekt - Support behov (defect resolution) estimeres Example Days Maj Jun Jul Aug Sep Okt Nov Dec Total days Available all Sickness Administration Project A Team Team Team Team Team Project B Team Team Team Team Team Project C Team Team Team Team Team Project D Team Devops All team Project E All team Support & SE All team Management All team Planned work Residual

8 Produktions planlægning (product owner) - 6 til 9 måneders horisont - Kapacitet estimeres pr. måned - Personer - Ferie - Fridage - Sygdom - Administration - Uddannelse - Etc. - Features (grov)estimeres ud fra roadmap plan (scope structure) - Support behov (defect resolution) estimeres Created and resolved defects forecast vs actual Actual resolved Actual created FC resolved FC created Days per defect forecast vs actual FC Days per defect Actual Days per defect

9 Sprint planlægning og retrospectives Sådan har vi valgt at køre SCRUM - Sprint længde er 2 uger - Alle teams sprints er aligned - Klare prioriteter er essentielle mellem support og nyudvikling - I hvert team afsættes kapacitet til support ud fra produktionsplan

10 Testplanlægning og kvalitetsopfølgning Optimal værdi skabes af en kombination af test typer, muligvis differentieret over tid. - Responsive test typer - Klassisk testning (en dygtig tester, der kan slippes løs og finde tonsvis af fejl ingen andre kan) - Eksplorative test typer - (f.eks. et område vi ved vi har få test cases bliver testet indenfor en tidsramme) - Lukning af Jira Issues baseret på repro, input fra dev og PO, kundens scenarie etc. - Strukturerede testyper er traditionelt test cases - Manuelle (f.eks. i ALM) - Automatiserede Værdien skal ses over tid både indenfor et release (sprints) og i regressions- og forandrings kontekst. - Risikovurdering (matrix) indebærer en risiko for at teste det samme hele tiden og misse nye problemer - Vores risikomatrix bruger flg. parametre (kan variere lidt per team) - Business impact - Frequence of use - Technical complexity - Product risk - Som vurderes low/medium/high konverteres til et tal og en vægtet værdi beregnes - Er inddelt efter funktionelle områder, så high risk områder kan til-vælges fra basen af struktureret test

11 Vores perspektiv på omkostninger i test Kr Manuel test Husk at tænke over: Hvad med vedligehold? Hvad med genbrug Hvad med tab af viden Automatisering Antal releases

12 Omkostninger ved forskellige typer af fix - Brug den rette type automatisering på et givent tids punkt - Manuel test skaber samarbejde og afklaring, undervurder det ikke - Automatisering skaber høj kode kvalitet både produkt og test kode Kr Anbefalinger: Release quality in Hotfix quality in Test quality in Build quality in Design quality in Forsøg at undgå det Triage defect fixes hårdt for at minimere risiko for regression Brug risikovurdering til testplanlægning Fokus på DevOps til automatisering af deployments Fokus på unit test samt tidlig automatisering Valider tidligt og ofte med kunder/brugere Efterstræb Minimal Viable Product Tid

13 Risk Matrix - eksempel Core Sub areas Functional area Business impact Frequence of use Technical complexity Product risk Product risk Automated Details Coinsurance Functional Areas Agreements management (Create and adjustments) High N UI. Test hint: Create contra Coinsurance Functional Areas Algorithm (user function) Medium N DB. Customization needed Coinsurance Functional Areas Premium calculation (leader) High Y (case coverage) Coinsurance Functional Areas Premium- commission calculation (follower) High N Coinsurance Functional Areas Commission calculation (Broker) Medium Y (case coverage) Coinsurance Functional Areas Claims roles generation Medium N Checkbox claims relations Coinsurance Functional Areas Coinsurance in the policy module Medium N UI. Test hint: Check on pol Coinsurance Functional Areas Automatic claims recovery High Y (case coverage) Coinsurance Functional Areas Automatic claims recovery maintenance High Coinsurance Functional Areas Coinsurance GL transactions Medium N DB. Expected to write scrip Coinsurance Functional Areas Coinsurance Cash Call Medium Y (case coverage) Check REI-544 for function Coinsurance Functional Areas Hold until paid Low Y (semi-auto) Follow automatic scripts (4 Coinsurance Functional Areas Coinsurace item overiview page Low N UI. Test hint: Create contra Coinsurance Processes Coinsurance as Follower Medium N Coinsurance Processes Coinsurance as Leader High N {check service cat} Low Coinsurance Services-Integrations

14 Ressource forhold og overvejelser - Det giver mindre og mindre mening at skelne skarpt mellem Dev og Test. - Engineering Managers leder derfor folk med begge roller - Udviklere har også ansvaret for unit tests - Ift. alle arbejdsopgaver udgør test (manuel, automatiseret o.s.v.) p.t. omtrent 1/3, men er stigende - Team størrelse er optimalt mindre end 10 - Vores scrum teams (po, sm, dev, test) producerer også dokumentation - Estimering og planlægning af sprints bør tage højde for alle roller og alle opgaver Role Count % Engineering manager 3 3% Software Engineer 47 54% Software Test Engineer 26 30% Product Owner 7 8% Support & SE Manager 1 1% VP R&D 1 1% Release Manager 1 1% Content Manager 1 1% Total %

15 Estimeringsmodel (illustrativ) Task Role Hours Weighted Talk to customer Product owner 10 0,01 Customer requirements Product owner 10 0,1 Customer Test cases Product owner 1 0,01 Handover from designer to development 20 0,05 Design specification Developer 10 0,1 Development Developer 100 Unit test Developer 10 0,1 Sparring Developer 1 0,01 Code-review Developer 2 0,02 Task test / functional test QA/Test 45 0 Regression test QA/Test 5 0,05 Release notes Writers 1 0,01 Online help Writers 2 0,02 Training material Writers 2 0,02 Marketing material Writers 2 0,02 Package DevOps 2 0,02 IT management DevOps 2 0,02 Project management Project Manager 0 0,05 Total % risk 293 1,3

16 Omkostningsstyring - Tidsregistrering er en nødvendig forudsætning - Overvej granulariteten - Vedligehold - Nyudvikling - Simplificer livet for udviklingsteamet ift. Registrering - Integrer tidsregistrering fra dev teamets primære tool til ERP system om muligt - TFS -> ERP - Jira -> ERP - Opfølgning per måned på omkostninger - Release niveau - Projekt niveau - Forholdet mellem vedligehold/nyudvikling/management A happy CFO

17 Opsummering og key take-aways - Gør meget ud af at strukturere og styre scope - Review ofte - Hav styr på vedligehold og tidsforbrug til andre ikke-nyudviklingsopgaver - Arbejd med risikovurdering ift. test planlægning - Følg op på test indsats kontra kvalitet (fundne fejl) - Udarbejd en planlægningshorisont der giver mening - Undgå at gå I for mange detaljer for tidligt - Vær stringent omkring produktionsplanlægning - Følg op på fremdrift v.h.a. agile metoder (sprint review, retrospectives) - Erkend at prisen for kvalitet stiger med kompleksiteten

18 Q & A