Slide 1

Slide 1 text

Fix-Price Projects Fix-Price Projects And Agile And Agile PyCon 7, 2016 PyCon 7, 2016 live slides @ tinyurl.com/pycon7-fix

Slide 2

Slide 2 text

Peter Bittner Peter Bittner Developer (of people, companies, code) Co-founder Painless Software @peterbittner, [email protected] behave-django codeship-yaml django-analytical django-apptemplates django-organice

Slide 3

Slide 3 text

You Know That Well You Know That Well deadline overtime features still missing deployment big-bang release bugs, bugs, bugs (regression) customer complaints renegotiations (price pressure) unpaid fixes (liability)

Slide 4

Slide 4 text

Who's Guilty? Who's Guilty? #1 Incompetent developers #2 Customer (feature changes) #3 "Agile" doesn't work #4 Maybe it has to be that way?

Slide 5

Slide 5 text

“ Agile does not exist. Agile does not exist. -- the infamous Peter Bittner It's really not a method, but just a set of best practices derived from experience (in software development)

Slide 6

Slide 6 text

Agenda Agenda Why fix-price projects? 3 dimensions of a project (Failing) Classic approach I+II (Demanding) Successful approach A) Sales Process A) Sales Process B) Project Execution

Slide 7

Slide 7 text

It's a planned economy (annual plan) Budget known in advance Target dates depend on goals + budget Revenue expected from new features Sums up to total profit Reliable dimensions Reliable dimensions Estimated dimensions Estimated dimensions Why Fix-Price Projects? Why Fix-Price Projects?

Slide 8

Slide 8 text

3 Dimensions of a Project 3 Dimensions of a Project 1. Time 2. Budget 3. Features “ Failing projects nail all 3 of them.

Slide 9

Slide 9 text

(Failing) Classic Approach (Failing) Classic Approach All features + fixed deadline + fixed budget Must be estimated competitively Buffers are never sufficient Not ready for change = renegotiations “ You try to do the impossible.

Slide 10

Slide 10 text

(Failing) Classic Approach II (Failing) Classic Approach II They will buy it (low risk) Time to get to know them Place to sell your approach Room to come up with an estimation Offer a workshop Offer a workshop You try to do it all You try to do it all Your goal: rough estimation Because you want all features (too) And meet budget + time "I told you at the workshop" syndrome “ Good! “ Bad!

Slide 11

Slide 11 text

Successful Approach Successful Approach Fix deadline + budget Total estimation = non-binding ("plausibility check") Explain advantages of sprint-wise billing Sprint-wise billing Sprint-wise billing Reduce risk (always deliver a working product) Freedom to change your mind (change features) Get what you need (not what you ordered)

Slide 12

Slide 12 text

Critical Elements Critical Elements Ship early, ship often Build first what creates most value Never ever touch the deadline! Plan a going-live party with customer On time On time On budget On budget Welcome change: Reprioritise, reorder, redo features (before sprint starts) Stick to the process: No overtime, no changes in a running sprint (full concentration) Bill every sprint ("when time is exhausted") “ Fixed working hours = no renegotiation

Slide 13

Slide 13 text

Software that "simply works" – tested! I got what I need – awesome! On time, on budget, working solutions

Slide 14

Slide 14 text

Agenda Agenda (Failing) Traditional setup (Successful) Test-driven setup Why it makes sense What do we need? A) Sales Process B) Project Execution B) Project Execution

Slide 15

Slide 15 text

(Failing) Traditional Setup (Failing) Traditional Setup Long acceptance test phase in the end A lot of manual testing Regression after bug fixes No guarantee of stable implementation Risky defects liability period A closing test phase A closing test phase “ Big bang release.

Slide 16

Slide 16 text

(Successful) Test-driven Setup (Successful) Test-driven Setup Acceptance test specification in concept phase Tests implemented by programmers Tests executed automatically Extremely short handover in the end Regression under control Upfront specification Upfront specification “ Building trust. Gaining speed.

Slide 17

Slide 17 text

Why It Makes Sense Why It Makes Sense No additional budget required Product stability Waste less money for bug fixing Cheap repeatability of testing Focus on advanced quality topics “ Make the same things earlier.

Slide 18

Slide 18 text

What Do We Need? What Do We Need? 1. User stories 2. Test specifications “ Acceptance criteria = Scenarios.

Slide 19

Slide 19 text

Tools & Resources Tools & Resources , Jira: , PyCharm, ... behave behave-django Behave Pro https://painless.software/test-driven-project

Slide 20

Slide 20 text

Wow, isn't that what we were always looking for? It's awesome, honey. Buy it? Buy it!

Slide 21

Slide 21 text

Thank you! Thank you! for your precious time for your precious time Painless Software Painless Software Less pain, more fun.