Fix-Price Projects And Agile – PyCon Sette
1 like392 views
The document discusses the challenges and solutions of fix-price projects in software development, emphasizing the limitations of traditional approaches and the benefits of agile methodologies. It highlights the importance of flexible project execution, sprint-wise billing, and test-driven setups to ensure successful project outcomes. Key points include the need for reliable estimations, early delivery of working products, and the importance of adapting to change.
Fix-Price Projects And Agile – PyCon Sette
- 1. Fix-Price ProjectsFix-Price Projects And AgileAnd Agile PyCon 7, 2016PyCon 7, 2016 live slides @ tinyurl.com/pycon7-fix
- 2. Peter BittnerPeter Bittner Developer (of people, companies, code) Co-founder Painless Software @peterbittner, django@bittner.it behave-django codeship-yaml django-analytical django-apptemplates django-organice
- 3. You Know That WellYou Know That Well deadline overtime features still missing deployment big-bang release bugs, bugs, bugs (regression) customer complaints renegotiations (price pressure) unpaid fixes (liability)
- 4. 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?
- 5. “ 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)
- 6. 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
- 7. 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 dimensionsReliable dimensions Estimated dimensionsEstimated dimensions Why Fix-Price Projects?Why Fix-Price Projects?
- 8. 3 Dimensions of a Project3 Dimensions of a Project 1. Time 2. Budget 3. Features “ Failing projects nail all 3 of them.
- 9. (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.
- 10. (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 workshopOffer a workshop You try to do it allYou 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!
- 11. Successful ApproachSuccessful Approach Fix deadline + budget Total estimation = non-binding ("plausibility check") Explain advantages of sprint-wise billing Sprint-wise billingSprint-wise billing Reduce risk (always deliver a working product) Freedom to change your mind (change features) Get what you need (not what you ordered)
- 12. Critical ElementsCritical Elements Ship early, ship often Build first what creates most value Never ever touch the deadline! Plan a going-live party with customer On timeOn time On budgetOn 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
- 13. Software that "simply works" – tested! I got what I need – awesome! On time, on budget, working solutions
- 14. AgendaAgenda (Failing) Traditional setup (Successful) Test-driven setup Why it makes sense What do we need? A) Sales Process B) Project ExecutionB) Project Execution
- 15. (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 phaseA closing test phase “ Big bang release.
- 16. (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 specificationUpfront specification “ Building trust. Gaining speed.
- 17. Why It Makes SenseWhy 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.
- 18. What Do We Need?What Do We Need? 1. User stories 2. Test specifications “ Acceptance criteria = Scenarios.
- 19. Tools & ResourcesTools & Resources , Jira: , PyCharm, ... behave behave-django Behave Pro https://painless.software/test-driven-project
- 20. Wow, isn't that what we were always looking for? It's awesome, honey. Buy it? Buy it!
- 21. Thank you!Thank you! for your precious timefor your precious time Painless SoftwarePainless Software Less pain, more fun.