Development Processes Agile - Value Driven Delivery. Stefan Sobek

Transcription

1 Development Processes Agile - Value Driven Delivery Stefan Sobek

2 What is Value Driven Delivery? The reasons projects are undertaken is to generate business value Produce a benefit or improve a service Focus on delivering value à Value Driven Delivery Generally ask yourself: Which choice will add the most value for the customer

3 Financial Assessment Metrics Return on Investment (ROI) Ratio of the benefits received from an investment to the money invested in it, expressed as percentage. Higher ROI means better return on invest Net Present Value (NPV) The present value of a revenue stream (income minus costs) over a series of time periods. Higher NPV is better we make more money then we spent Internal Rate of Return (IRR) Discount rate at which the project inflows (revenues) and project outflows (costs) are equal. Higher IRR is better. Earned Value Management (EVM) Used for measuring the cost, scope and time performance by comparing the planned value (estimated costs) for a specific point in time (e.g. month) with the actual costs (real costs which occured) and the delivered features (earned value)

4 Prioritizing Value Customer-Valued Priorization Refers to the agile practice of working on the items that yield the highest value to the customer first Customer or product owner is responsible for keeping items in product backlog (things that needs to be done) prioritized by business value Scrum: Product backlog FDD: Feature list...

5 Prioritization Schemes Simple Schemes Prio-1, Prio-2, Prio-3 Easy but: leads to putting every task to Prio-1 MoSCoW Must have, Should have, Could have, Would like to have, but not this time Monopoly Money Give out Monopoly Money to the stakeholders and ask them to distribute those funds amongst the system features 100 Point Method Each stakeholder has 100 Points to vote for the most important requirements. Can distribute in any way, 20 here, 40 there or 100 on a single requirement. Dot Voting or Multi-Voting Every stakeholder gets some dots (roughly 20% of the number of options) Now they can plug these to the features they want

6 Prioritization Schemes Simple Schemes Prio-1, Prio-2, Prio-3 Easy but: leads to putting every task to Prio-1 MoSCoW Must have, Should have, Could have, Would like to have, but not this time Monopoly Money Give out Monopoly Money to the stakeholders and ask them to distribute those funds amongst the system features 100 Point Method Each stakeholder has 100 Points to vote for the most important requirements. Can distribute in any way, 20 here, 40 there or 100 on a single requirement. Dot Voting or Multi-Voting Every stakeholder gets some dots (roughly 20% of the number of options) Now they can plug these to the features they want

7 Prioritization Schemes Simple Schemes Prio-1, Prio-2, Prio-3 Easy but: leads to putting every task to Prio-1 MoSCoW Must have, Should have, Could have, Would like to have, but not this time Monopoly Money Give out Monopoly Money to the stakeholders and ask them to distribute those funds amongst the system features 100 Point Method Each stakeholder has 100 Points to vote for the most important requirements. Can distribute in any way, 20 here, 40 there or 100 on a single requirement. Dot Voting or Multi-Voting Every stakeholder gets some dots (roughly 20% of the number of options) Now they can plug these to the features they want

8 Relative Priorization Prioritized List Order of relative priority No prio-1, prio-2 etc. Feature A on top is most important Feature B is relatively to feature C more important, but less important then feature A. When a new feature (change) comes in, ask customer how important that is relatively to the other features on the list and put it there. Minimal viable product Feature A Feature B Feature C Feature D Feature E

9 Delivering Incrementally Regularly deployment of new working increments Minimal Viable Product (MVP) Also known as MMF minimal marketable feature The package of functionality that is complete enough to be useful to the users or the market (but does not represent the whole project) E.g. cell phone may need to Make andreceive calls Store contacts Access voice mail But: camera needed for MVP?

10

11 Verifying and Validating Value Validation: Are we building the right product? Verification: Are we building the product right? Communication is important Having a gap between requested and delivered features may lead to rework

12 Frequent Verification and Validation in XP Release month Iteration demo weeks Acceptance test days Stand-up meeting one day Customer collaboration Pair Programming Unit test minutes hours Code seconds

13 Frequent Verification and Validation in XP Shortest review cycle during XP practice pair programming the reviewer spots an error of the coder, the error can immediately be corrected. XP programmers write unit tests and run them in a couple of minutes to verify their code Customer collaboration should occur frequently. Gives feedback over design and if objectives met Daily standup, the team will validate who is working on what and when its done and ready. In iterations meetings (review) the team demonstrates the work they completed to the customer to verify that they are building the right product. Every few month (typically), at the end of a release the customer reviews the deliverables to verify that it is done.

14 Testing and verification in Software Development Exploratory testing Relies on testers skill, autonomy and creativity in trying to discover issues in the system Usability testing Goal is to diagnose how easy it is to use the system and uncover problems in usability which need redesign or changes Continious Integration (CI) Techniques to frequently incorparate new and changed code into project. Usually it is an automated tool to start the integration process on code changes in the code-repository (svn or git) Test Driven Development (TDD) Test should be written before the code. Write test, run it, write code, run tests, refactor. Acceptance Test-Driven Development (ATDD) Moves testing focus from code to business requirements. Usually these are acceptance test of a user story in the backlog.