Date post: | 13-Apr-2017 |
Category: |
Technology |
Upload: | ralph-johnson |
View: | 42 times |
Download: | 2 times |
FELINESOFT
AGILE PROCESS WITH A FIXED BUDGET
2
• The challenge• Overview of process • The process• Environments• Release• Managing change• Summary
• Planning• Sprint allocation• Sprint
• Planning• Development• Scrum• Testing• Deployment
• Sign-off• Feedback
Contents
3
CFO VS Developer
4
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………………………?
5
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…
6
1) Planning2) Sprint allocation3) Planning4) Sprint
1) Development2) SCRUM3) Deployment4) Testing
5) Sign-off6) Feedback7) Track changes
Overview of process
Overview of the stages
THE PROCESS
8
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.
Entering the user stories
Planning
IA
User Stories
9
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.
Estimation
Planning
10
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.
Sprint plan is created
Planning
Start22 Jul
Finish06 Dec
01 August 01 September 01 October 01 November 01 DecemberPlanning22 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
11
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.
Allocation of user stories to sprint
Sprint allocation
1 pts2 pts5 pts8 pts8 pts
13 pts5 pts8 pts8 pts
13 pts
1 pts13 pts5 pts8 pts8 pts
13 pts Capacity 40pts
Backlog Sprint
12
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.
Confirming the technical approach to each user story
Sprint planning
13
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.
Test plan writing
Sprint planning
SPRINT
15
• 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 delivery of release quality code
Sprint
16
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.
Development
Sprint
17
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.
SCRUM
Sprint
18
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.
Deployment
Sprint
TFS Build
Integration
Checked in code is built
Nightly and deploy
19
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.
Testing
Sprint
CLIENT SIGN OFF AND FEEDBACK
21
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.
Deploy to stage for review
Client sign-off and feedback
TFS Build
Integration
Checked in code is built
Nightly and deploy
Stage
Bugs
All User Stories passed
22
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.
Feedback
Client sign-off and feedback
ENVIRONMENTS
24
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.
25
Environments
Developers1 ͙� .. n
Features1 ͙� .. n
Integration Stage Production
26
• 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.
Environment per person and task
Environments
Developers1 �͙ .. n
Features1 �͙ .. n
Integration Stage Production
RELEASE
28
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.
Final testing before go-live
Release
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
MANAGING CHANGE
30
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.
The change request
Management of change
2 pts5 pts8 pts8 pts
13 pts5 pts8 pts
8 pts13 pts
Created during planning
Added after planning
Change Request
Scope
31
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.
32
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: 0117 325 1902