Agile contracts
•Télécharger en tant que PPTX, PDF•
2 j'aime•1,073 vues
This presentation tells what things are essential for any contract, what information has to be included in typical software development contract, what has changed after agile software development approach emergence and how to prepare your own agile software development contract.
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Agile contracts
Similaire à Agile contracts (20)
Dernier
Dernier (20)
Agile contracts
- 1. AGILE CONTRACTS Presentation is based on real-life events and personal experience
- 2. Supplier’s scope of supply Project plan Price and payment terms Customer’s scope of supply Quality requirements Change implementation procedure Delivery and acceptance Project governance Legal frame
- 7. SCOPE
- 8. Describe scope by using user stories or in other agile software development friendly way with clearly described expected outcome.
- 9. Example of a user story As a [role], I want [goal/desire] so that [benefit]. As a traveler I want to find my seat in a bus so that I can change it.
- 10. Initially a contract has to contain the least possible scope, that gives added value to a customer.
- 11. Each user story included in a contract need to have an estimate in complexity points or mandays.
- 12. PRICE AND PAYMENT TERMS
- 13. Payment terms need to be easily understandable and acceptable by all involved parties. agile ≠ time/material
- 15. Contract has to contain detailed description of a customer’s involvement requirements in a project.
- 16. PROJECT PLAN
- 17. In the beginning of a project there is at least one iteration (sprint) needed for preparation works.
- 18. During a project there is at least one iteration (sprint) needed for acceptance testing.
- 20. Project governance is described as part of customer’s scope of supply and change implementation procedure.
- 22. Software has to be potentially shippable at the end of each iteration (sprint).
- 23. System testing is performed during each iteration (sprint).
- 24. Acceptance testing is performed during a separate iteration (sprint).
- 26. Contract has to contain short and clear description of user story replacement principles.
- 27. WHAT HAS NOT CHANGED?
- 28. Legal frame Quality requirements Supplier’s scope of supply: a) non-functional requirements (for example, technology requirements, integration requirements) b) support and maintenance of functionality in production
- 29. HOW TO MAKE YOUR OWN AGILE CONTRACT?
- 30. Together with a customer gather user stories for least possible project scope that brings value to a customer Gather non- functional requirements Agree with a customer on software development approach and explain involvement requirements 1. 2. 3.
- 31. Agree with a customer on needed deliverables and acceptance procedure Agree with a customer on price and payment terms Prepare a legal frame 5.4. 6.
- 32. Sources of inspiration Agile Contracts by Alistair Cockburnhttp://alistair.cockburn.us/Agile+contracts Agile Contracts by Tom Arbogast, Craig Larman, and Bas Voddehttp://www.agilecontracts.org/agile_contracts_prim er.pdf Scrum guide (in Latvian)http://www.autentica.lv/lv/article/scrum-celvedis- latviesu-valoda/ original (in English) http://www.scrumguides.org/scrum-guide.html
Notes de l'éditeur
- Typical software development contract consists of: 1) legal frame – part of a contract which contains general information about a project and contains references to attachments; 2) supplier’s scope of supply – functional and non-functional requirements of a solution; 3) Price and payment terms – price and terms when and how it is paid; 4) customer’s scope of supply – material and non-material deliverables, which a customer has to supply; 5) quality requirements – measurable requirements of a software solution (e.g, performance requirements, requirements towards number of known errors); 6) project plan –activities required to meet project goals scheduled in time; 7) project governance – the way how a customer and a supplier will keep control over a project; 8) delivery and acceptance –project deliverables and their acceptance criteria; 9) change implementation procedure – contains principles, how to change a scope of a project.
- Contract is not a document written by lawyers and used only by lawyers, but it is a document that describes the way how a customer and supplier will cooperate to create an IT solution and reach goals of a project. Each member of a team needs to know a contract to some extent.
- Contract needs to reflect reality, i.e., how an actual work will be done during a project. If contract does not reflect a reality, then reality changes to reflect what’s written in a contract, not vice versa. Changes in a contract can be made at any time during a project – there is no need to spend too much time before the project to have a perfect contract.
- Each contract motivates people act in one or other way. Good contract motivates people to cooperate in order to reach project goals.
- Has there been a lot of changes since agile was started to be used in software development projects? Not so much.
- If there is no clearly described outcome, then it will not be possible to demonstrate solution at the end of each sprint.
- It is important to have the LEAST possible scope and use it for learning. Since agile has built-in option of self-improvement, both a customer and a supplier will be more informed and able to build better IT solution. It is also important to reach a level where a scope brings added value, because then a customer will be able to use it for a business and feel safe about an investment.
- In order to be able to replace user stories and prioritize them there has to be an estimate for each user story.
- If you are not able to explain your payment term in 60 seconds, there is a great probability that a customer will not accept them. There is no link between software development approach and payment terms – agile does not mean time/material. The most often used are fixed price contract, where fixed price is number of complexity points multiplied by a price of a complexity point.
- Focus of this section has shifted from infrastructure to participation in a project. It is very important that a customer understands software development approach and requirements towards involvement in a project.
- Although it would be nice to start programming solution immediately, there is usually a need to spend some time on doing formal things like getting access to environments, setting up infrastructure etc.
- Although system testing is done during each sprint, there is a need to test a whole solution.
- Usually there is no need of having separate governance procedure, since there are frequent meetings with a customer as part of agile software development approach.
- Delivery and acceptance procedure has shortened, because software has to be potentially shippable at the end of each iteration. Documents are accepted he same way as before.
- User stories can be replaced or they can be eliminated at all.
- Support and maintenance of a solution starts as soon as some part of functionality is given to the end users. This should not be forgotten.