DevOps and metrics presentation, co-presentation by Dave van Herpen and Harold van Heeringen (both Sogeti Nederland B.V.). The key message of the presentation is the fact that metrics are important in DevOps environments and that it is important to do a thorough analysis of which metrics are important to collect and for which reasons.
I am a agile tester, because...(Agile testing put to practice)Derk-Jan de Grood
On 12 September Andreas Prins and I gave two presentation on the TestNet session night. The theme of the event was: Transforming testing to fit modern development. Andreas identified various rhythms (or wavelengths) in the SDLC and explained the automation that can be done in order to have short lead times and frequent feedback on code quality and delivered value.
My presentation was called “I am an agile tester, because…”. During my talk I discussed what it takes to be an agile tester and I introduced 12 statements that can be used as manifesto for the agile tester. During the presentation 40+ participants filled in the survey and we got a nice impression of how agile our testing is. You can find the results below, and in the slide deck.
Using a recent project I was involved in I put these statements to the test. I explain the test strategy I applied and shared my successes and failures. One of the participants tweeted about the presentation: “A nice war story. The 12 statements trigger me to think about my own role and the role of testing within my project and organization”. I think I succeeded my mission.
Lac 2013 hogere klanttevredenheid met dev ops-ready architectuurRaimond Brookman
DevOps en Continuous Delivery, hoe past architectuur daar in? Is er spanning tussen het uitdenken van een architectuur en snel functionaliteit releasen en hoe ga je daarmee om? Is architectuur wel nodig? Wij denken van wel. Vanuit praktijkervaringen met twee van onze belangrijke producten wordt toegelicht hoe een “DevOps-ready” architectuur opgezet kan worden en hoe bestaande architecturen kunnen worden omgevormd. En daarnaast: wat is het effect voor de klant, betalen de beloftes zich ook uit?
I am a agile tester, because...(Agile testing put to practice)Derk-Jan de Grood
On 12 September Andreas Prins and I gave two presentation on the TestNet session night. The theme of the event was: Transforming testing to fit modern development. Andreas identified various rhythms (or wavelengths) in the SDLC and explained the automation that can be done in order to have short lead times and frequent feedback on code quality and delivered value.
My presentation was called “I am an agile tester, because…”. During my talk I discussed what it takes to be an agile tester and I introduced 12 statements that can be used as manifesto for the agile tester. During the presentation 40+ participants filled in the survey and we got a nice impression of how agile our testing is. You can find the results below, and in the slide deck.
Using a recent project I was involved in I put these statements to the test. I explain the test strategy I applied and shared my successes and failures. One of the participants tweeted about the presentation: “A nice war story. The 12 statements trigger me to think about my own role and the role of testing within my project and organization”. I think I succeeded my mission.
Lac 2013 hogere klanttevredenheid met dev ops-ready architectuurRaimond Brookman
DevOps en Continuous Delivery, hoe past architectuur daar in? Is er spanning tussen het uitdenken van een architectuur en snel functionaliteit releasen en hoe ga je daarmee om? Is architectuur wel nodig? Wij denken van wel. Vanuit praktijkervaringen met twee van onze belangrijke producten wordt toegelicht hoe een “DevOps-ready” architectuur opgezet kan worden en hoe bestaande architecturen kunnen worden omgevormd. En daarnaast: wat is het effect voor de klant, betalen de beloftes zich ook uit?
Tegenwoordig zijn bedrijven steeds eerder een softwarebedrijf in plaats van de verkoper van een product of dienst. Of het nu een webwinkel of een digitale dienst is, de klanttevredenheid en de mogelijkheid om in te spelen op de wensen van de klant is een essentieel onderdeel van de bedrijfsvoering. Maar hoe kom je erachter waar de klant vastloopt of afhaakt en naar de concurrentie overstapt. Beter gezegd, hoe kunnen we de klant voor zijn en hem verrassen met nieuwe en verbeterde functionaliteit?
In deze sessie laten we zien hoe je inzicht kan krijgen in het gedrag van de klant. En hoe kan dit inzicht helpen om het bedrijf zijn concurrentiepositie te verbeteren en de relatie met de klant nog sterker te maken.
DevOps is a term used in many places and unfortunately also to mean many different things. This presentation (largely in Dutch) paints the DevOps picture. While it may not give a clear cut definition (there does not seem to be one) it certainly makes clear what DevOps is about, what objectives and origins are and which factors enable and drive DevOps.
Het GEO team bij Schiphol is verantwoordelijk voor het realiseren en beheren van GIS toepassingen (geografische informatiesysteem) voor diverse klantgroepen op de hele luchthaven. In een complexe omgeving, met interne en externe stakeholders is het team eind 2016 een agile transitie aangegaan.
In deze sessie vertelt Kees van 't Hoog over de reis van de transitie van een traditionele projectaanpak naar volledig Agile aan de hand van successen, tegenslagen en groei van het team.
Continuous delivery met jenkins twist en puppetltebbens
Deliver software fast. Release features elke twee weken naar productie door een continue stroom automatisch geteste user stories. Die met een drukknop live kunnen. In deze presentatie deel ik mijn ervaringen en de toegepaste inrichting.
In de hedendaagse Agile en DevOps wereld ontstaan vaak ketenproblemen. Wat kun je daaraan doen? Wij hebben ervaren dat ketenregie een oplossing biedt. In deze presentatie leggen we twee mogelijke uitersten van oplossingen voor. Elke organisatie zal haar eigen variant moeten ontdekken. De door ons aangereikte handvatten zijn daarbij vast heel nuttig.
Presentatie op de Quality Experience Day van Sogeti op 2 oktober 2017 door Ahmed Alarieqi en Rik Marselis
Naar een toekomstbestendige dienstverlening - Themasessie 2016TOPdesk
Op verschillende locaties in Nederland organiseren wij de themasessie ‘Naar toekomstbestendige dienstverlening’ over de toekomst van servicemanagement, met in het programma de visie en roadmap van TOPdesk en de nieuwste versie van TOPdesk.
Op verschillende locaties in Nederland organiseren wij de themasessie ‘Naar toekomstbestendige dienstverlening’ over de toekomst van servicemanagement, met in het programma de visie en roadmap van TOPdesk en de nieuwste versie van TOPdesk.
De IT Regisseur - grip op IT met Integrated Service Management (ISM)De IT Regisseur B.V.
Zijn uw gebruikers niet tevreden over de ICT? Wilt u de kwaliteit van de ICT dienstverlening verbeteren? Heeft u altijd discussie over wie wat moet doen? En bent u vooral bezig met brandjes blussen? Dan wordt het tijd om Integrated Service Management of ISM® methode te implementeren. De IT Regisseur kan u als implementatie partner helpen om uw IT dienstverlening op orde te krijgen.
Presentatie Enterprise Architectuur - Agile en EssentieDanny Greefhorst
Gastcollege verzorgd voor de Hogeschool Utrecht op 22 maart 2018. De kernboodschap is dat enterprise-architectuur agile kan en moet en zich moet richten op de essentie. De essentie van architectuur is creatief en kritisch denken.
Tegenwoordig zijn bedrijven steeds eerder een softwarebedrijf in plaats van de verkoper van een product of dienst. Of het nu een webwinkel of een digitale dienst is, de klanttevredenheid en de mogelijkheid om in te spelen op de wensen van de klant is een essentieel onderdeel van de bedrijfsvoering. Maar hoe kom je erachter waar de klant vastloopt of afhaakt en naar de concurrentie overstapt. Beter gezegd, hoe kunnen we de klant voor zijn en hem verrassen met nieuwe en verbeterde functionaliteit?
In deze sessie laten we zien hoe je inzicht kan krijgen in het gedrag van de klant. En hoe kan dit inzicht helpen om het bedrijf zijn concurrentiepositie te verbeteren en de relatie met de klant nog sterker te maken.
DevOps is a term used in many places and unfortunately also to mean many different things. This presentation (largely in Dutch) paints the DevOps picture. While it may not give a clear cut definition (there does not seem to be one) it certainly makes clear what DevOps is about, what objectives and origins are and which factors enable and drive DevOps.
Het GEO team bij Schiphol is verantwoordelijk voor het realiseren en beheren van GIS toepassingen (geografische informatiesysteem) voor diverse klantgroepen op de hele luchthaven. In een complexe omgeving, met interne en externe stakeholders is het team eind 2016 een agile transitie aangegaan.
In deze sessie vertelt Kees van 't Hoog over de reis van de transitie van een traditionele projectaanpak naar volledig Agile aan de hand van successen, tegenslagen en groei van het team.
Continuous delivery met jenkins twist en puppetltebbens
Deliver software fast. Release features elke twee weken naar productie door een continue stroom automatisch geteste user stories. Die met een drukknop live kunnen. In deze presentatie deel ik mijn ervaringen en de toegepaste inrichting.
In de hedendaagse Agile en DevOps wereld ontstaan vaak ketenproblemen. Wat kun je daaraan doen? Wij hebben ervaren dat ketenregie een oplossing biedt. In deze presentatie leggen we twee mogelijke uitersten van oplossingen voor. Elke organisatie zal haar eigen variant moeten ontdekken. De door ons aangereikte handvatten zijn daarbij vast heel nuttig.
Presentatie op de Quality Experience Day van Sogeti op 2 oktober 2017 door Ahmed Alarieqi en Rik Marselis
Naar een toekomstbestendige dienstverlening - Themasessie 2016TOPdesk
Op verschillende locaties in Nederland organiseren wij de themasessie ‘Naar toekomstbestendige dienstverlening’ over de toekomst van servicemanagement, met in het programma de visie en roadmap van TOPdesk en de nieuwste versie van TOPdesk.
Op verschillende locaties in Nederland organiseren wij de themasessie ‘Naar toekomstbestendige dienstverlening’ over de toekomst van servicemanagement, met in het programma de visie en roadmap van TOPdesk en de nieuwste versie van TOPdesk.
De IT Regisseur - grip op IT met Integrated Service Management (ISM)De IT Regisseur B.V.
Zijn uw gebruikers niet tevreden over de ICT? Wilt u de kwaliteit van de ICT dienstverlening verbeteren? Heeft u altijd discussie over wie wat moet doen? En bent u vooral bezig met brandjes blussen? Dan wordt het tijd om Integrated Service Management of ISM® methode te implementeren. De IT Regisseur kan u als implementatie partner helpen om uw IT dienstverlening op orde te krijgen.
Presentatie Enterprise Architectuur - Agile en EssentieDanny Greefhorst
Gastcollege verzorgd voor de Hogeschool Utrecht op 22 maart 2018. De kernboodschap is dat enterprise-architectuur agile kan en moet en zich moet richten op de essentie. De essentie van architectuur is creatief en kritisch denken.
Webinar - EAM /Reliability & Integrity Software selectie - 15 juli 2020Stork
Er is een groot aantal Enterprise Asset Management IT-systemen op de markt. Over welke software systemen hebben we het eigenlijk en hoe bepaalt u welke software tool het beste bij uw organisatie past?
Ludolf Pijpker geeft u inzicht in de groepen Asset Management software systemen, in de verschillen ertussen en in een stappenplan om tot de perfecte match te komen. Dit voorkomt onnodig hoge kosten, bevordert de integratiemogelijkheden met andere systemen en zorgt voor soepel lopende werkprocessen.
In je bedrijf heb je de juiste software nodig om de boel draaiende te houden, maar bestaande software is lang niet altijd geschikt. In zo\'n
geval biedt software die op maat is gemaakt
uitkomst. Nearshoring
levert deze dienst onder
meer aan het mkb,
maar is tevens \'troubleshooter\'
van je bedrijfsproces.
Directeur Jacek
Salek vertelde ons er meer over.
In deze webinar neemt Gerlinde Oversluizen u mee op reis en geeft u handvatten om de eerste stappen te zetten naar uw eigen digitale fabriek.
Tijdens deze sessie kwamen de volgende vragen aan bod:
Wat is een digital factory?
Bij welke problemen kunnen digital factory concepten helpen?
When clients outsource their software development projects, they need to make sure that these suppliers don't overprice the projects. As it is often not longer possible to select the best offer, there should be another mechanism to measure the value that they are getting in comparison to the money they are paying. Supplier Performance Measurement enables clients to keep in control of theis project costs in outsourcing situations and to negotiate performance improvements with the suppliers.
Bpug 2014 agile project mgt tussen scylla en charybdisHans Smorenburg
Meer waarde creeeren met agile project en portfolio management met behoud van agility en flow in de realisatie. 10 uitgangspunten die helpen bij het versterken van wendbaarheid in business en IT.
Similar to Asl bi sl metrics themasessie 2013 devops sogeti (20)
Improve Estimation maturity using Functional Size Measurement and Historical ...Harold van Heeringen
Many software projects still fail in recent years, also agile projects. Improving estimation maturity in order to start with a realistic estimate instead of an optimistic one can really save billions of dollars in most local software industries. The Chinese government may now be moving towards an active software estimation maturity improvement strategy in its new 5-year plan. Functional size measurement and relevant historical data as well as parametric estimation tools are key to such a strategy. This presentation was the key-note speech at the China System and Software Process Improvement Association conference on software estimation, Beijing China, May 27 2016.
Nowadays, as the software industry is slowly becoming more mature, software measurement and performance measurement are becoming increasingly important. Organizations need to know their productivity and competitiveness in software development projects for various reasons. In many software development contracts, targets are set for the suppliers to reach. These targets are based on software metrics like productivity, speed of delivery and software quality. In order to check if the targets are reached, it is necessary to measure the functional size of the software product that is delivered and also the functional size of the software development project that is carried out, as there is usually a difference between these two sizes. To be able to use functional size in contracts, it must be measured in an objective, repeatable, verifiable and therefore defensible way. That being the case, the industry’s best practice is to use an ISO/IEC standard for functional size measurement, e.g. Nesma, COSMIC or IFPUG function points. However, these methods only measure the functional user requirements from the total software requirements to be delivered. In activities like project estimation and productivity measurement, the influence of the non-functional requirements is expressed in the Project Delivery Rate (PDR) which is expressed in effort hours per function point. If more than the average amount of non-functional requirements need to be realized in a project (or more severe non-functional requirements), the PDR used should also be higher. In the industry it is customary to set productivity targets based on an average (or calibrated) influence of non-functional requirements and this works quite fine in traditional software projects. In software development projects that are executed in an agile way, this is not always the case. When working agile, there are forces that influence the traditional way of performance measurement significantly, resulting in a number of serious issues. In this paper these issues are explained and a method to overcome these issues is proposed.
Nowadays, as the software industry is slowly becoming more mature, software measurement and performance measurement are becoming increasingly important. Organizations need to know their productivity and competitiveness in software development projects for various reasons. In many software development contracts, targets are set for the suppliers to reach. These targets are based on software metrics like productivity, speed of delivery and software quality. In order to check if the targets are reached, it is necessary to measure the functional size of the software product that is delivered and also the functional size of the software development project that is carried out, as there is usually a difference between these two sizes. To be able to use functional size in contracts, it must be measured in an objective, repeatable, verifiable and therefore defensible way. That being the case, the industry’s best practice is to use an ISO/IEC standard for functional size measurement, e.g. Nesma, COSMIC or IFPUG function points. However, these methods only measure the functional user requirements from the total software requirements to be delivered. In activities like project estimation and productivity measurement, the influence of the non-functional requirements is expressed in the Project Delivery Rate (PDR) which is expressed in effort hours per function point. If more than the average amount of non-functional requirements need to be realized in a project (or more severe non-functional requirements), the PDR used should also be higher. In the industry it is customary to set productivity targets based on an average (or calibrated) influence of non-functional requirements and this works quite fine in traditional software projects. In software development projects that are executed in an agile way, this is not always the case. When working agile, there are forces that influence the traditional way of performance measurement significantly, resulting in a number of serious issues. In this paper these issues are explained and a method to overcome these issues is proposed.
The importance of benchmarking software projects - Van Heeringen and OgilvieHarold van Heeringen
Benchmarking is a crucial management activity that enables organizations to understand how competitive they are. Using functional size measurement methods and historical data enables organizations to improve their processes and become more succesful.
Avoid software project horror stories - check the reality value of the estima...Harold van Heeringen
Many large software projects turn into software horror stories, resulting in newspaper headlines and even political issues. Often, the project costs and schedule were estimated unrealistically optimistic, using immature estimation techniques. A relatively simple way to avoid many problems is to perform a reality check on the estimate. This presentation was given on the conference of the International Cost Estimating and Analysis Association (ICEAA2014), June 2014 (Denver, USA)
ISMA 9 - van Heeringen - Using IFPUG and ISBSG to improve organization successHarold van Heeringen
Introduction to the International Software Benchmarking Standards Group and 3 cases in which function points together with ISBSG data really resulted in business value:
- Reality check of an estimate made by experts
- Assessing the competitive position of a department
- Selecting a single software supplier
This presentation shows why it is important to benchmark the performance of software projects and organizations. Measurement of performance and comparing this to relevant peer groups provides the knowledge and understanding for managemenr to make informed decisions on where the organization stands and where it should go. This presentation was given at the Italian GUFPI-ISMA conference (December 2013) and addressed also the way the Italian industry is performing according to the ISBSG Country Analysis report.
Using the ISBSG data to improve your organization success - van Heeringen (Me...Harold van Heeringen
This presentation gives an introduction into the ISBSG organization and shows how the ISBSG products and data can help the software industry to become more mature. Three cases from personal experience are showed: a reality check of an expert estimate (that turned out to be optimistic), the analysis of the outgoing bids of a software supplier and the measurement of the performance of a single supplier, providing target productivity levels they should reach.
In many organizations, bottom up estimation of software development projects is still the way to go. Management feels that top-down (parametric) estimation models require too much effort and cost. In this presentation, a random selection of 10 bids are analyzed and the bottom-up estimates and top-down estimates are compared with regard to accuracy and effort spend.
In many organizations, bottom up estimation of software development projects is still the way to go. Management feels that top-down (parametric) estimation models require too much effort and cost. In this paper, a random selection of 10 bids are analyzed and the bottom-up estimates and top-down estimates are compared with regard to accuracy and effort spend.
Project Control using functional size - which method to use?Harold van Heeringen
Project Control is one of the most difficult tasks of a project manager. To assess whether a project is still on track is very difficult because the team members often report overconfident status reports. Using functional size and specialized tooling, like QSM Control or SEER PPMC, helps the project manager to get a real good understanding of the status of the project. These tools produce accurate forecasts and offer the possibility to do what-if analysis in order to select the best way to get a project back on track. In this presentation, it is examined which method would produce the best results, NESMA or IFPUG FPA or COSMIC FPA.
Metrics based software supplier selection - Best practice used in the largest...Harold van Heeringen
Abstract—This article provides insight into a ‘best practice’ used for the selection of software suppliers at the largest Dutch telecom operator, KPN[1]. It explains the metrics rationale applied by KPN when selecting only one preferred supplier (system integrator) per domain instead of the various suppliers that were previously active in each domain. Presently (Q2 2012) the selection and contracting process is entering its final phase. In this paper, the model that was built and used to assess the productivity of the various suppliers and the results of the supplier selection process are discussed. In addition, a number of lessons learned and recommendations are shared.
The difference between expert estimates and parameteric estimates, and a study to see which ones are more accurate and faster to do. ISPA/SCEA conference, Brussels (May, 2012)
8. Metrics
DevOps business drivers
Customer Satisfaction
Optimal value & risk
Short TTM
Efficient operations
Business
driven
Feedback
loops
Fast flow
Multidiscipl.
teams
9. Metrics
CD - DevOps
• Continuous Delivery:
– Integratie binnen de deployment pipeline
• DevOps:
– Beweging tbv samenwerking Dev, Ops, QA &
business
10. Metrics
CD - DevOps
Basis = principes
Naam = gewenste resultaat
Continuous
Basis = organisatie
Naam = implementatiewijze
DevOps
Delivery
12. Metrics
Agile Manifesto (2001)
Mensen en hun onderlinge interactie boven processen en tools
Werkende software boven allesomvattende documentatie
Samenwerking met de klant boven contractonderhandelingen
Inspelen op verandering boven het volgen van een plan
20. Metrics
DevOps culture
“I’ll tell you EXACTLY what DevOps means:
Devops means giving a shit about your job enough to not pass the buck.
Devops means giving a shit about your job enough to want to learn all the
parts and not just your little world.
Developers need to understand infrastructure. Operations people need to
understand code. People need to fucking work with each other and not just
occupy space next to each other.”
John Vincent | @lusis | http://goo.gl/X3joO2
21. Metrics
DevOps focus:
• Vooral focus op:
– Standaardisatie
– Automatiseren
– Nieuwe technologieën
• Te weinig focus op:
–
–
–
–
Functioneel Beheer
IT support
Complexe systemen & processen
Portfolio Management
Enterprise
DevOps
22. Metrics
Wat levert DevOps op?
Improved quality of
software deployments
More frequent
software releases
Improved visibility into
IT process and requirements
Cultural change
collaboration/cooperation
More responsiveness
to business needs
More agile
development
More agile
change management process
Improved
quality of code
63%
63%
61%
55%
55%
51%
45%
38%
PuppetLabs, IT Revolution Press (December 2012)
4000+ respondents
90+ countries
24. Metrics
Harold van Heeringen
Software Cost Engineer, Sogeti Nederland B.V.
President International Software Benchmarking Standards Group (ISBSG)
COSMIC IAC, Nederlandse afgevaardigde
Nederlandse Software Metrieken Associatie (NESMA) bestuurslid
werkgroep COSMIC (voorzitter)
werkgroep Benchmarking (voorzitter)
werkgroep FPA and quality metrics in contract(ing) (voorzitter)
@haroldveendam
haroldveendam
haroldvanheeringen
24
25. Metrics
Metrics & DevOps
• DevOps doel: continu verbeteren !
• Performance:
– inzicht;
– Trends;
– stuurmechanisme.
• Benchmarken:
– Intern – tussen teams / afdelingen;
– Extern – met de markt.
• Team commitment (competitie element)
• Bewijs dat DevOps werkt – communicatie !!
25
26. Metrics
Vele soorten metrics
• Business metrics
– Bijvoorbeeld: time-to-market
• Applicatie metrics
– Bijvoorbeeld: beschikbaarheid van de applicatie
• Team metrics
– Bijvoorbeeld productiviteit
• Er zijn duizenden metrieken denkbaar…
• Welke metrics kiezen? GQM!
26
27. Goal Question Metric (GQM)
Metrics
• Veel organisaties meten zaken waar niets mee wordt gedaan;
• Kost tijd, geld en levert weinig op;
• Metrieken moeten altijd gerelateerd zijn aan een
informatiebehoefte;
• Een informatiebehoefte moet altijd gekoppeld zijn aan een doel;
• Goal Question Metric (GQM) (Basili, 1992)
27
29. Metrics
•
•
•
•
•
•
•
•
Typische doelen DevOps
Verbeterde klantwaarde;
Verbeterde kwaliteit van de software;
Snellere time-to-market (sneller dan concurrent);
Snellere recovery na incidenten;
Verhoogde beschikbaarheid;
Verlaagde kosten;
Verbeterde besluitvorming;
Verhoogde voorspelbaarheid.
29
30. Metrics
Voorbeeld GQM DevOps
• Stakeholder : Business owner Applicatie X
– Goal: Verbeterde concurrentiepositie d.m.v. snellere
implementatie van features (time-to-value)
– Questions:
• Wat is de huidige implementatiesnelheid per feature?
• Wordt de implementatiesnelheid steeds korter?
• Is de implementatiesnelheid sneller dan
marktgemiddeld?
– Metrics:
• Implementatiesnelheid: FP per kalendermaand
(trend)
• Gemiddeld aantal dagen tussen indienen change en
implementatie
30
33. Agile: Story Points
Metrics
Relatieve omvangsmaat, meet de omvang van user stories t.o.v.
elkaar. Keuze van ‘referentie’, overige relatief.
VB: Hondpunten (o.b.v. hoogte).
Ras
Hondpunten
Poedel
5
Schnautzer
Team X: Duitse herder = 10
Team Y: Schnautzer = 10
Team Z: Chihuahua = 1
6
Duitse herder
Chihuahua
10
2
Labrador
11
Sint Bernhard
12
Bulldog
7
Hondpunten/Story points is geen standaard
Niet bruikbaar voor opbouwen historische
data
Niet bruikbaar voor begroten project
Niet bruikbaar voor benchmarking/metrics
Wel bruikbaar voor begroten sprint
Wel bruikbaar voor velocity/burn down
33
34. Metrics
b.v. Waarde
• Meer functionaliteit = meer waarde !!
• Uit te drukken in objectieve, herhaalbare, verifieerbare eenheid;
– Story points? Voldoet aan geen van deze kenmerken;
– Slocs? Geen maat voor waarde. Meer slocs is goed? Of slecht?;
– Usecases? Geen objectieve maat (verschillende niveaus);
– Functiepunten: Voldoet aan alle kenmerken!
• Functiepunt analyse – meet functionele omvang
– Onafhankelijk van techniek;
– Onafhankelijk van implementatiewijze;
– Onafhankelijk van ontwikkel methodologie.
34
35. Metrics
Functiepunten en Agile
•
•
•
•
•
•
•
Functiepunten worden als ‘ouderwets’ en ‘waterval’ gezien.
Niets is minder waar!!
Moderne variant van FPA: COSMIC FPA
Nauwkeurig meten van user requirements
Objectieve eenheid, herhaalbaar, verifieerbaar!
Zeer geschikt voor meten van documentatie in agile projecten
Zeer geschikt voor meten van real-time software, embedded
software, SOA architecturen, Mobile apps, Cloud, etcetera!
• Eenvoudiger toe te passen dan NESMA/IFPUG FPA
• Proces georiënteerd, niet data georiënteerd
• COSMIC FPA is perfect geschikt voor het meten van waarde!
35
37. Metrics
User stories en COSMIC
Vaak: User stories.
Als een <type gebruiker> wil ik <iets doen> zodat ik <er iets aan
heb>.
Als een boekkoper wil ik de klantbeoordelingen van een boek lezen,
zodat ik beter kan beslissen of ik het boek wil kopen.
Functioneel Proces: Lezen klantbeoordelingen
Entry: klik link ‘lezen klantbeoordelingen van boek’
Read: Ophalen beoordelingen boek
eXit: Toon beoordelingen boek
eXit: Toon gemiddelde score (berekening)
eXit: Meldingen (fout / boodschap)
5 COSMIC FP
37
38. COSMIC FPA / SP
Metrics
Kenmerk
COSMIC Functiepunten
Story Points
Objectief / herhaalbaar /
verifieerbaar
Ja
Nee
Basis
ISO standaard
Meningen teamleden
Eenvoud meten
Gecertificeerde analist
Eenvoudig
Begroten Project / Release
Ja, i.c.m historische data en
Nee
eventueel begrotingstools (bv
QSM of SEER-SEM)
Begroting Sprint
Ja
Ja
Benchmarking
Intern en Extern
Alleen binnen team (!?)
Historische Data
Ja (ISBSG > 500 projecten)
Nee
Project Bewaking /
forecast
Ja
Ja
Gebruik in contracten
Ja
Nee
Tijd / inspanning
1 a 2 dagen (afh. Van omvang) X teamleden * 1 a 2 uur
38
39. Metrics
•
•
•
•
•
•
•
•
•
•
Typische DevOps metrics
Productiviteit – bestede uren/functiepunt
Kosten – EUR / functiepunt
Velocity – functiepunten per sprint in productie gebracht
Speed – functiepunten per kalendermaand
Kwaliteit proces – defects per functiepunt
Onderhoudbaarheid – SIG sterren
Mean Time to Recover (minuten)
Deployment Rate/frequency (keren per dag)
Change Lead time (dagen)
Change Failure rate (%)
39