Embed Size (px)
DESCRIPTION
Citation preview
www.eng.it
IFPUG Agile Interest Group (IG) Webinar - May 17 2012
Luigi BuglioneBuglione, Ph.D.Process Improvement & Measurement Specialist
Industry Business UnitEngineering.IT
Improving estimates by a 4-pieces puzzle
Agile-4-FSM
www.eng.it
Engineering At a glance
ERP ECMIT Security
Plant ManagementSystem
Broadband & MediaManaged Operations
System Int. & System Int. & ConsultancyConsultancy
OutsourcingOutsourcing
SoftwareSoftware
7070
1010
2020
8080
2020
5454
2727
1919
8080
1010
1010
FinanceFinance IndustryIndustry TELCOTELCO UtilitiesUtilities
%%
%%
%%
ResearchResearch and and DevelopmentDevelopment
3535
1919
4646
PA & HCPA & HC
_ The first Italian ICT player
_ more than 730 M/€ revenues_ 1000 clients_ 6,300 IT specialists
www.eng.it
3 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Goals of the presentation
G1. Introduce the ‘Agile-4-FSM’ puzzle G2. Analyze each piece of the puzzle G3. Propose possible solutions for improving estimates
Agile-4-FSM
4 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Introduction Some initial questions...
Why does it seem so difficult to apply FSM methods to Agile projects?
What about NFRs? Do they need to be sized and managed? Eventually, how?
Which kind of changes do I need to introduce in my Estimation process for achieving better estimates?
What about the maturity of my organization in the ‘sizing & estimation’ process?
5 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Some pieces of the puzzle...
1. Requirements 1. Requirements
2. NFRs 2. NFRs
3. Size Measures3. Size Measures 4. Estimating & 4. Estimating & PlanningPlanning
Agile-4-FSM
6 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Piece #1#1 – Requirements (US – User Stories)Agile-4-FSM
US Title
Relative Productivity /Estimation
High Level FUR
Implementation Priority
Functional Test
Functional Req (FUR)
Non-functional Reqs (NFR)
Org/Project related Reqs
7 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Piece #1#1 – Requirements (US2)Agile-4-FSM
Type 1 (F/Q/T)
Type 2 (Q/T)
Functionality + Q/T
complementary issues
Architectural/Project-
related issues, not
strictly linked to a functionalit
y
• US2 – 2°-generation User Stories A US writes and ‘sizes’ expressly only FUR, NFRs are implicit, not easily manageable At least, two types of US2 can be manage
Reference: Buglione L., Meglio Agili o Veloci? Alcune riflessioni sulle stime nei progetti XP, XPM.it, February 2007, URL: www.xpm.it (in Italian)
8 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Piece #1#1 – Requirements (US2) – Type1/2Type1/2Agile-4-FSM
• US2 – Type 1Type 1 This is a typical, complete US It includes the FUR-part (F) as well, after
the interplaying between Customer and Provider, the related Q/T parts
Its value besides in making visible those NFR parts requiring effort, that otherwise risk to be underestimated, even if taken into account by experience
The more you make explicit, the less the probability for a higher estimation error
Example: as in the left-side figure• US2 – Type 2Type 2
Looking at the typical activities to be run in Software Life Cycle, also in iterative SLCs as in Agile methods, some non-functional/organizational activities that need to be run, sizing zero (0) FPs but can be generically classified as Q/T (non-functional)
Since of course they need effort and must be estimated and planned, a different way is needed for being expressed
They can be simply estimated in m/d or – for the product NFR-requirements – using e.g. The IFPUG SNAP method or an elaboration of ISO/IEC 25010:2011 standard
Example: as in the right-side figure
9 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Piece #1#1 – Requirements (INVEST)Agile-4-FSM
• Evaluate Requirements – The INVEST GridINVEST Grid “INVEST” are six criteria from Mike Cohn for evaluating each US/US2
The INVEST Grid (Buglione, 2007) Create your own definitions over an ordinal scale (e.g. 0-3 as in ISO/IEC 14598-x std)
Fill cells as in a maturity model for each criterion Customer and Provider have to jointly evaluate the achieved level US/US2 will pass in production and be assigned to an iteration/Sprint only when the agreed
thresholds for the six criteria will be achieved
INVEST Description0 1 2 3
Poor /Absent Fair Good Excellent
I -Independent User Stories should be as independent as possible between them
The start of construction of the US is tied to the completion of at least another US
The completion of such US represents a constraint for starting the construction of at least another US
US can be produced with any constraint, but its release can be constrained to the completion of at least another US
US is fully independent, and it can be realized and released with any constraint
N – Negotiable User Stories should be "open" as much as possible reportingany relevant details
US is written with so much details to be a technical specification (Design phase), not allowing to negotiate any element
US is written with so much details to be a functional specification (Analysis phase), not allowing a sufficient negotiation
US is written with an informative content defining a User Requirement in a consolidated manner, yet shared between Customer and Provider
US is written with an informative content typical of a high-level need, allowing a series of feedbacks between Customer and Provider
V - Valuable User Stories should give a value for end users of the solution
US functional (F) side does not contain functionalities requested from the Customer
US functional (F) side expresses mostly qualitative (Q) and technical (T) requirements about the system, needs to be more developed on the ‘F’ side
US functional (F) side expresses mostly functional requirements as requested by the Customer, but includes also qualitative (Q) and technical (T) requirements
US functional (F) side correctly expresses only functional requirements as requested by the Customer
E – Estimable Each User Story must be able to be estimated in terms of relative size and effort
US shows only its Functional (F) side filled by the Customer, but without sufficient detailed level for allowing the Provider filling the Q/T parts
US shows only its Functional (F) side filled by the Customer, but validated with the Provider
US is complete for Q/T issues by the Provider, but needs to be validated jointly with the Customer
US shows all useful parts (F/Q/T) allowing to size and estimate needed effort, validated by both parts
S – Small Each User Story should be sufficiently granular, not too high-level defined
US has a very large size, and it can not be completed within a Sprint
US has a very large size, and it can be completed within a Sprint, but it cannot allow to create/deliver other US
US has a size allowing to be completed within a Sprint, jointly with other US, but it’s so small to create an overhead about the Testing phase
US has a size allowing to be completed within a Sprint, jointly with other US, assuring a proper balancing between development and testing activities
T – Testable Each User Story must be formulated trying to stress useful details for creating tests
US does not include tips about Acceptance Tests
US includes formal indication on Acceptance Tests, still to be completed
US includes indication of Acceptance Tests, complete, yet to be validated
US includes indication of Acceptance Tests, complete and already validated
10 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Piece #2#2 – NFRsAgile-4-FSM
URL: http://goo.gl/MIJZU
• NFRs – Non Functional Requirements NFR (IFPUG CPM v4.3.1) = Quality reqs + Technical Reqs (IFPUG CPM v4.2.1)
Quality Reqs = “any requirements relating to software quality as defined in ISO 9126:1991” Tech Reqs = “requirements relating to the technology and environment, for the development,
maintenance, support and execution of the software” Non-Functional Reqs = “a software requirement that describes not what the software will
do but how the software will do it’ ...SNAP (IFPUG Software Non-functional Assessment Process)
11 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Piece #2#2 – NFRsAgile-4-FSM
Source:: ITPC, Software Non-functional Assessment Process (SNAP) – Assessment Practice Manual (APM), v1.0, September 2011ITPC webpage: http://ifpug.org/about/ITperformance.htm
IFPUG CPM v4.3.1 (excerpts) page 1-2: IFPUG Strategic Decision: "IFPUG’s method for function point
analysis is an ISO standard and must be conformant to ISO/IEC 14143-1:2007. The method can measure “functional size” only and not “non-functional size”. This does not mean that the nonfunctional size cannot, or should not, be measured, only that it must be clearly stated as a separate measure (“A Framework for Functional Sizing” [IFPUG, 2003]).”
page 4-20: "This maintenance includes a wide range of activities that are performed during this phase of the application life cycle, some of which involve functional changes that are applicable to FPA” (thus, not all types of mainteinance)
page 4-21: Mainteinance requests: "Regardless of duration or level of work effort required, it is the type of activity that determines how the work is classified. Function Point Analysis should not be used to size perfective or corrective maintenance work”
12 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Piece #2#2 – NFRs (SNAP)Agile-4-FSM
Source:: ITPC, Software Non-functional Assessment Process (SNAP) – Assessment Practice Manual (APM), v1.0, September 2011ITPC webpage: http://ifpug.org/about/ITperformance.htm
NFR unit of measure: SNAP Points (SP) Counting base: SCU (SNAP Counting Unit) 4 categories and 17 sub-categories
o C1 – Data Operations (5 sc)
o C2 – Interface Design (4 sc)
o C3 – Technical Environment (4 sc)
o C4 – Architecture (3 sc)
3 parts in the APMo 1 – The method
o 2 – Examples
o 3 - Annexes
Update: H1/2012
13 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Piece #3#3 – Size Measures
• Size Measures Agile methods (ASD, APM) typically use time-based measures for estimating (Story
Points, Velocity, ...) and have not a standard definition for being consistently applied No/Few historical data also for using analogy estimates But the estimation logical chain is... Q (quantity) T (Time: Effort Duration) C (Costs) FUR can be sized with a FSM method, but facing the requirement granularity issue FUR is only one side of the ‘story’ ‘Functionalize’ NFRs e.g. http://goo.gl/AWZjU Again, not all iterations/Sprints are the same, they plan and release differently
Agile-4-FSM
URL: http://goo.gl/Qls7B
URL: http://goo.gl/4UCht
14 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Piece #4#4 – Estimating & PlanningAgile-4-FSM
Sprint #1 Sprint #2 Sprint #3 Sprint #4
• Estimating & Planning Each iteration/Sprint can be managed as a ‘project’ (or a ‘sub-project’) because it has
different characteristics Not all iterations/Sprints are the same, they need to be planned differently Type-1 and Type-2 US2 are placed differently within iterations use different
productivity levels according to the different balancing of FUR vs NFR related effort Nominal productivity’ (FP/Effort) www.semq.eu/pdf/fsm-prod.pdf
15 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Agile-4-FSM
• Splitting effort... Separate approx FUR vs
NFR-related efforts Increased R2 values Refine your own effort
data gathering introducing some more filters (e.g. # of layers and/or peer components measured)
Start using SNAP and/or other NFR-related approaches!
Piece #4#4 – Estimating & Planning
16 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Conclusions && Perspectives
• Agile & Requirements FURs represent a large part of User Stories, but not the whole NFRs need to be properly represented also in Agile environments, because the effort they take US2 is a simple way to start writing them and the INVEST grid could be a way to improve agile
planning, matching common-sense and a more quantitative view
• Agile & Sizing measures “Q T C” is the common-sense, logical chain to be followed and ‘Quantity’ cannot be
skipped FSM methods can be easily applied to agile projects, many experiences yet ready and applicable ‘One size DOESN’T fits all’...Only FURs are not sufficient for representing the real PROJECT
effort Sizing NFRs is the next challenge IFPUG SNAP is one possible way to start doing it!
Agile & Estimating+Planning Classifying US2 in Type-1 and Type-2 can help in better allocating resources and schedule
iterations according to the distribution of FUR vs NFR-related effort Some lessons learned
Agile is based on Experience Experience means Data Gather Data and share among the organization
Skill people on better eliciting requirements (e.g. CMMI-DEV RD process, ML3), separating FURs and NFRs
Share experiences and apply common definitions and levels of granularity across the several agile project teams, overcoming the ‘Story Point’-syndrome...it’s about Simplicity!Simplicity is prerequisite for reliability
(Edsger Dijkstra, Mathematician)
Agile-4-FSM
17 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
What is (should be) Agile?Agile-4-FSM
18 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
Q && A
Grazie mille per l’attenzioneGrazie mille per l’attenzione!!Thanks for your attentionThanks for your attention!!
Agile-4-FSM
19 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
We care of your problems and we have in mind a solution
Luigi Buglione
Industry & Service Dept
Tel. +39 - 06.8307.4472Fax +39 - 06.8307.4200Cell. +39 - 335.1214813
Via R. Morandi 3200148 Roma
www.eng.it [email protected]
Process Improvement & Measurement Specialist
ContactsAgile-4-FSM
