Agile Process with Fixed Cost
-
date post
21-Oct-2014 -
Category
Technology
-
view
1.107 -
download
1
description
Transcript of Agile Process with Fixed Cost
The right tools for the job
Agile process with a fixed budget
The right tools for the job
Contents
• The challenge• Overview of process • The process• Environments• Release• Managing change• Summary
– Planning– Sprint allocation– Sprint
• Planning• Development• Scrum• Testing• Deployment
– Sign-off– Feedback
The right tools for the job
The challenge
CFO Vs Developer
The right tools for the job
The challenge
Software development works best using an iterative process with constant feedback (agile, scrum, CMMI) but CFO’s like to know what they are getting and how much it costs before they sign off a project. In other words, developers want agile and CFOs want waterfall.
How do you square this circle………………………?
The right tools for the job
The solution
An agile process with a fixed cost for a fixed amount of effort. This allows you to use an agile process and manage change like waterfall by tracking items added to the backlog.
Let’s take a look at this in detail…
The right tools for the job
Overview of process
Overview of the stages
1
2 3
4
5
6
7
1) Planning2) Sprint allocation3) Planning4) Sprint
1) Development2) SCRUM3) Deployment4) Testing
5) Sign-off6) Feedback7) Track changes
The right tools for the job
The process
The right tools for the job
Planning
Entering the user storiesIA
1) Information Architecture and designs are produced either by an external agency or FelineSoft.
2) These are broken up into discrete blocks of work known as User Stories. These will reference the documents provided.
3) All of this is loaded into Team Foundation Server and this is made available on-line through a web portal.
User Stories
The right tools for the job
Planning
Estimation
1) The development team reviews the user stories.
2) Assumptions are noted in the User Story in TFS.
3) Points are assigned using the Fibonacci sequence.
4) Assumptions are fed back to the product owner and signed off.
5) User Stories are re-estimated.
The right tools for the job
Sprint plan is created
The sprint plan defines the expected number of sprints based on the estimated user stories. The first sprint is a kick-off sprint and sets up all the environments along with automated deployment. The final 2 sprints are used for any minor change requests and polishing the solution. This is done while final testing is taking place and content is being loaded.
Planning
Start22 Jul
Finish06 Dec
01 August 01 September 01 October 01 November 01 December
Planning22 Jul - 16 Aug
Kick-off Sprint05 Aug - 16 Aug
Sprint 121 Aug - 03 Sep
Sprint 206 Sep - 19 Sep
Sprint 324 Sep - 07 Oct
Sprint …n10 Oct - 23 Oct
Content Loading25 Oct - 21 Nov
Polishing Sprint 128 Oct - 08 Nov
Polishing Sprint 213 Nov - 26 Nov UA
T
Training on Content loading24 Oct
Final Testing24 Oct - 06 Dec
Go-live
Today
The right tools for the job
Sprint allocation
Allocation of user stories to sprint The estimated user
stories are allocated to the next sprint. A spread of user stories sized is selected to ensure you have some 1 and 2 points stories to do at the end of the sprint. The capacity is defined by earlier sprints or for the first one the company average.
1 pts
2 pts5 pts8 pts8 pts
13 pts5 pts8 pts8 pts
13 pts
1 pts
13 pts5 pts8 pts8 pts
13 pts Capacity 40pts
Backlog Sprint
The right tools for the job
Sprint planning
Confirming the technical approach to each user story The development team
works through each User Story and creates technical documentation for each one. This is all stored in a Project WiKi within your portal. Ensuring you always have complete documentation for the project. This is also the final chance to confirm User Story estimations.
The right tools for the job
Sprint planning
Test plan writing Test plan writing is done during the planning stage. Tests are created in test manager and associated with User Stories. Each test plan is signed off by the client- this ensures that all parties understand the acceptance criteria during development, testing and sign-off.
The right tools for the job
Sprint
The right tools for the job
Sprint
The delivery of release quality code
• User Stories are completed by the development team.
• Each night the code is automatically deployed.
• The test team tests the completed user story and logs any bugs associated with the user story and assigned to the developer.
• Each day a SCRUM takes place to ensure that there are no impediments.
The right tools for the job
Sprint
Development Development is done in VS.NET Premium 2012 with ReSharper. This ensures the development team has the maximum productivity with the best tools for the job. Each developer also has a minimum of iCore5 with 8GB of RAM and 17” monitors.
The right tools for the job
Sprint
SCRUM Each day a SCRUM takes place where impediments are raised. These are tracked in TFS as issues and associated with a User Story. They can also be found in the risk register Excel sheet in our portal. This ensures that our client can easily access the list even without VS.Net.
The right tools for the job
Sprint
Deployment Code is checked by the development team once each User Story is completed. It is then deployed automatically each night to the integration server. As there is a zero overhead no time is wasted ensuring the testing team have the latest code ready to test. This ensures bugs are fedback to the development team as quickly as possible.
TFS Build
Integration
Checked in code is built
Nightly and deploy
The right tools for the job
Sprint
Testing Testing is completed using VS.Net Test and Test Manager; all bugs are recorded directly in to TFS and associated with the User Story. Screen shots can be captured along with videos of how to reproduce the bug and all are stored directly in TFS. This is all accessible through your on-line portal.
The right tools for the job
Client Sign off and feedback
The right tools for the job
Client sign-off and feedback
Deploy to stage for review Once all User Stories have been passed by the test team the branch is released to staging where the client can sign it off based on the agreed testing plan. At this stage only bugs that don’t comply with agreed testing scope are raised.
TFS Build
Integration
Checked in code is built
Nightly and deploy
Stage
Bugs
All User Stories passed
The right tools for the job
Client sign-off and feedback
Feedback Feedback is provided using the Microsoft Visual Studio 2012 Feedback Tool. This allows you to add bugs, change requests and minor alterations directly into the development environment, using screen capture, voice and attaching files. This greatly reduces the number of emails and increases clarity of understanding.
The right tools for the job
Environments
The right tools for the job
Environments
The agile process does not work without continuous testing. To enable this you must reduce the overhead of deployment as much as possible.
This is achieved through automated deployment and the right environment setup.
The right tools for the job
Environments
Developers1 ͙! .. n
Features1 ͙! .. n
Integration Stage Production
The right tools for the job
Environments
Environment per person and task
• Each developer has their own setup.
• Features are deployed to a new environment for testing before being merged into the main branch.
• Integration is used by the test team to ensure the main branch is good.
• Stage only takes release branch for final testing and UAT by the client.
• Production is the live environment.
Developers1 !͙ .. n
Features1 !͙ .. n
Integration Stage Production
The right tools for the job
Release
The right tools for the job
Release
Final testing before go-live The final sequence before go-live ensures each of the major areas are covered and future updates of the site are made as quickly and cost effectively as possible through the automation of testing of the site’s major features. The site is tested for performance and security along with a final set of regression testing. The final sweep is then completed with the client before sign-off of the site and go-live.
Finish06 Dec
November December
Write release test plans
Content Loading
Polishing Sprint 1
Performance testing
Functional / Regression Testing
Polishing Sprint 2
Automate Smoke Tests
Security Test
Client UAT
Training on Content loading24 Oct
Final Testing24 Oct - 06 Dec
Dry run 22 Nov
Go-live06 Dec
The right tools for the job
Managing Change
The right tools for the job
Management of change
The change request
All projects have some amount of change and thus managing this is important. FelineSoft achieve this by tracking all the User Stories added following project planning. These user stories can then either be completed out of an agreed contingency or additional change request budget. FelineSoft recommend that at least 1 additional sprint is budgeted for in order to handle the changes. These are shown in the project plan as polishing sprints. All changes can thus be exported from TFS into an Excel sheet for analysis by stakeholders.
1 pts
2 pts5 pts8 pts8 pts
13 pts5 pts8 pts
8 pts
13 pts
Created during planning
Added after planning
Change Request
Scope
The right tools for the job
Summary
The agile fixed price process is perfect for clients that need to keep their CFO happy with a fixed price and fixed budget or have a defined scope from IA and design. This allows you to leverage all the benefits of agile while keeping to the principles of waterfall intact.
If you don’t have design or IA then there is always “Change for free money for nothing” but that is for another time.
The right tools for the job
Contact Us
This presentation was written by Ralph Johnson of FelineSoft and this is the process FelineSoft use to manage clients that want to work agile but still require a fixed price.
Please get in contact if you have questions or what to work with us.E: [email protected] T: 0845 658 6767