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

Fix-Price Projects And Agile – PyCon Sette

Embed Size (px)

Citation preview

Fix-Price ProjectsFix-Price ProjectsAnd AgileAnd Agile

PyCon 7, 2016PyCon 7, 2016

live slides @ tinyurl.com/pycon7-fix

Peter BittnerPeter BittnerDeveloper (of people, companies, code)Co-founder Painless Software@peterbittner, [email protected]

behave-django codeship-yaml django-analytical django-apptemplates django-organice

You Know That WellYou Know That Well

deadline

overtime

featuresstill missing

deployment

big-bangrelease

bugs, bugs, bugs(regression)

customercomplaints

renegotiations(price pressure)

unpaid fixes(liability)

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?

“ Agile does not exist.Agile does not exist.-- the infamous Peter Bittner

It's really not a method, but just a set ofbest practices derived from experience(in software development)

AgendaAgenda

Why fix-price projects?3 dimensions of a project(Failing) Classic approach I+II(Demanding) Successful approach

A) Sales ProcessA) Sales Process

B) Project Execution

It's a planned economy (annual plan)Budget known in advanceTarget dates depend on goals + budget

Revenue expected fromnew featuresSums up to total profit

Reliable dimensionsReliable dimensions

Estimated dimensionsEstimated dimensions

Why Fix-Price Projects?Why Fix-Price Projects?

3 Dimensions of a Project3 Dimensions of a Project1. Time2. Budget3. Features

“ Failing projects nail all 3 of them.

(Failing) Classic Approach(Failing) Classic ApproachAll features + fixed deadline + fixed budgetMust be estimated competitivelyBuffers are never sufficientNot ready for change = renegotiations

“ You try to do the impossible.

(Failing) Classic Approach II(Failing) Classic Approach II

They will buy it (low risk)Time to get to know themPlace to sell your approachRoom to come up with an estimation

Offer a workshopOffer a workshop

You try to do it allYou try to do it allYour goal: rough estimationBecause you want all features (too)And meet budget + time"I told you at the workshop" syndrome

“ Good!

“ Bad!

Successful ApproachSuccessful ApproachFix deadline + budgetTotal estimation = non-binding("plausibility check")Explain advantages of sprint-wise billing

Sprint-wise billingSprint-wise billingReduce risk (always deliver a working product)Freedom to change your mind (change features)Get what you need (not what you ordered)

Critical ElementsCritical Elements

Ship early, ship oftenBuild first what createsmost valueNever ever touch thedeadline!Plan a going-live partywith customer

On timeOn time On budgetOn budget

Welcome change: Reprioritise,reorder, redo features (beforesprint starts)Stick to the process: No overtime,no changes in a running sprint (fullconcentration)Bill every sprint ("when time isexhausted")

“ Fixed working hours = no renegotiation

Software that "simply works"– tested!

I got what I need –awesome!

On time, on budget,working solutions

AgendaAgenda

(Failing) Traditional setup(Successful) Test-driven setupWhy it makes senseWhat do we need?

A) Sales Process

B) Project ExecutionB) Project Execution

(Failing) Traditional Setup(Failing) Traditional Setup

Long acceptance test phase in the endA lot of manual testingRegression after bug fixesNo guarantee of stable implementationRisky defects liability period

A closing test phaseA closing test phase

“ Big bang release.

(Successful) Test-driven Setup(Successful) Test-driven Setup

Acceptance test specification in concept phaseTests implemented by programmersTests executed automaticallyExtremely short handover in the endRegression under control

Upfront specificationUpfront specification

“ Building trust. Gaining speed.

Why It Makes SenseWhy It Makes SenseNo additional budget requiredProduct stabilityWaste less money for bug fixingCheap repeatability of testingFocus on advanced quality topics

“ Make the same things earlier.

What Do We Need?What Do We Need?

1. User stories2. Test specifications

“ Acceptance criteria = Scenarios.

Tools & ResourcesTools & Resources,

Jira: , PyCharm, ...behave behave-django

Behave Pro

https://painless.software/test-driven-project

Wow, isn't that whatwe were always

looking for?

It's awesome,honey.

Buy it?

Buy it!

Thank you!Thank you!for your precious timefor your precious time

Painless SoftwarePainless SoftwareLess pain, more fun.