Www.synerzip.com Agile Approach @Synerzip Agile/Iterative Development With Distributed Teams WORKING...
-
Upload
clifford-briggs -
Category
Documents
-
view
235 -
download
0
Transcript of Www.synerzip.com Agile Approach @Synerzip Agile/Iterative Development With Distributed Teams WORKING...
www.synerzip.com
Agile Approach @SynerzipAgile/Iterative Development With Distributed Teams
WORKING DRAFT – September 2008
Confidential
Discussion Topics
• Agile 101
• Agile @Synerzip
Confidential
What is Agile?• Agile development is the ability to develop software quickly, in the face
of (rapidly) changing requirements• Agility is achieved by adhering to well understood practices, discipline,
and feedback• Various flavors are practiced in the industry – SCRUM, Extreme
Programming (XP), Adaptive Software Development, etc.• From Agile Manifesto of 2001: “Agile approach values…
– Individuals and interactions over processes and tools– Working software over comprehensive documentation– Customer collaboration over contract negotiation– Responding to change over following a plan
…that is, while there is value in the items on the right, items on the left are valued more”
But, Agile is not an excuse to do maverick development without due attention to requirements analyses, thoughtful design, robust
development & testing
Confidential
Why Adopt Agile Approach?
• It is just more suitable for fast moving companies– Builds software which is more likely to delight customers
• Embraces “changing requirements” as a positive, • Allows more innovation - relieves the product managers of the fear of
committing to an irreversible change– Builds better quality, robust code– Provides better visibility and delivery predictability to management
• It lends itself well for working effectively with offshore/ distributed development teams– Quick release cycles (Sprint) and scrum make the efforts put in by the
offshore team more visible leading to trust– Requires less onerous documentation around requirements, thereby main
bottleneck in leveraging offshore is dramatically reduced
When done properly…
Over 70% of large & small companies have plans to adopt one or more of the agile practices this year
Confidential
Discussion Topics
• Agile 101
• Agile @Synerzip
Confidential
Agile Approach @Synerzip• Next few pages lay out the general approach of Agile
development followed at Synerzip• This is a highly collaborative process, across distributed
teams, including client and Synerzip professionals• This general approach is applicable to all software
development & testing projects, e.g.– New Product Development– Ongoing Maint/Enhancement of Existing product– Configuration/Integration of Enterprise Software– Development of QA Automation Framework
• The very nature of Agile process is that it is flexible and adaptable in different client/project situations
• While process adaptability/flexibility is an asset, we still need follow a minimum level of software engineering discipline – “hygiene” as described in following pages.
Confidential
Agile/Iterative Dev Lifecycle1. Engagement/Project kick-off2. Development Environment and Infrastructure set-up:
version control, issue tracking and build automation3. Repetitive steps in each development iteration
a. Requirements Analysis
b. Iteration Planning & Estimation
c. Daily scrum, weekly report, monthly review
d. Test automation and test driven development
e. Change control and re-estimation
f. Coding standards and code review
g. Release process and document
h. Review of Iteration Deliverables
i. Retrospectives4. Select “Appropriate” Discipline/Rigor for Development
Confidential
1. Engagement Kick Off• What Works
• Clear agreement on project objectives, scope, team and discipline.• Team roaster is on the wiki, team has gone through the customer’s web
site and documents sent by the customer and is prepared to ask some pertinent questions.
• Standard practices at Synerzip for setting up VPN, version control and database server are explained by going over a document. Clear idea of the days required to set up these things is given to the client team.
• Clear agreement with client team on periodic interactions – daily calls, weekly reports, monthly reviews, etc.
• Team shows the first deliverable in week 2 or 3 of the engagement.
• What Doesn’t• There is no identified owner/ champion who will make it work.• No formal meeting or conference call happens to kick off the engagement.• Contract is used to define roles and responsibilities.• Teams don’t invest time on identifying and agreeing on tools of
collaboration such as VPN, Bug tracking, version control etc.• Teams start work in isolation without demonstrating what they are working
on and without seeking/ providing any feedback.
Confidential
2. Development Infrastructure
• What Works• Common version control for both on-site and off-shore teams
• All tasks including features, changes and bugs are filed in the issue tracking system.
• Separate out production build and development build by having tasks that are affected by developers’ work in the development build so that it
runs faster than the production build. • What Doesn’t
• Code drops are FTPed or Emailed back and forth.
• Two or more repositories at off shore and on site location.
• Developers check in code which is incomplete- which breaks the build.
Version control, Issue tracking & build automation
Confidential
Typical Dev. InfrastructureCommon development code-base, development- and test environment
Sending code, deploys, etc back and forth via email because some cannot ABC and others can only XYZ is a living nigtmare
Database Server Source ControlQA Sever
Offshore Team
Onsite Team
Client Network
Synerzip network
Firewall
Confidential
Build Server Structure
Confidential
Recommended Dev ToolsCategory Recommended Other Acceptable
ToolsNot Recommended
Version Control Subversion CVS/VSS/Microsoft Team System
More than one version control.
Issue Tracking Bugzilla Mercury Quality Center, Assembla, SalesForce.com, jira, SharePoint
Excel , MS Word
Project Plan Excel MS Project, Base camp, Assembla
Automated Build CruiseControl ANT, NANT
Confidential
Collaboration Tools
Category Recommended Other Acceptable Tools
Not Recommended
Voice Conference Conference Bridge Skype
Video Conference Polycom PVX Skype
Desktop Sharing LiveMeeting Webex, Goto Meeting, Remote Desktop
IM Skype/Yahoo MSN messenger
Document Collaboration
Wiki Base camp, Assembla, Sharepoint
Confidential
3a. Requirements Analysis
• What Works• Well defined independent requirements for the remote team.• Well documented requirements in a spreadsheet or a word document,
each requirement is numbered• Copious Q & A and interaction over the requirements. Questions can
be tracked using a spreadsheet or Wiki• Stakeholders Actively Participate• Gradual reduction in means uncertainty with goal uncertainty.
• What doesn’t• There is no clearly well carved of set of requirements for the remote
team to work on• Treating requirements analysis as a one time exercise.• Why document the requirements when you know it is going to change
anyway?• Assumption that the customer needs what he wants and wants what he
says.• Requirements analysis in isolation.• Trying to define every requirement to the last detail up front.
Confidential
Reqmt. and Dev. cycle - Typical
1. Client provides high-level requirements outline document, laying out the vision/roadmap (aka MRD)
2. a. On site Product Manager works with client team and prepares PRD/Product Backlog. This remains a live document. Each requirement tracked through a unique number.
b. Requirements’ details are clarified for each Iteration, through collaboration via Wiki etc. All requirements are put-up on Wiki/SharePoint, for all stakeholders to review
3. Once frozen, these requirements become “Product Backlog” - used to create Release and Iteration Plan with task list.
4. Issue Tracking System (Bugzilla) used to assign task to appropriate team members.
5. Test cases prepared against each requirement and attached to the Issue Tracking System.
6. Development team complete assigned tasks, reassign back to QA.
Steps 2-6 repeated for each iteration.
2a. PRD/Product Backlog/4. Issue Tracking
6. Development Team
Customer
Subtitle
6/19/2008
2b.Wiki
Stakeholders
1. MRD / Requirements Outline
5. Test Cases
3. Release Plan/Iteration Plan
Confidential
Reducing Uncertainty
1. The best way to deal with uncertainty is to iterate.
2.To reduce uncertainty about what the product should be, we work in short iterations and show/give working software to users every few weeks.
3.Similarly uncertainty about how to develop the product is reduced by iterating. For example, missing tasks can be added to plans, inadequate designs can be corrected sooner rather than later.
Confidential
Agile Documentation• Need far less documentation than you think• Intent of Agile Documents
– Maximize stake-holders investment– Are concise– Fulfill a purpose– Are sufficiently accurate, consistent and detailed– Are sufficiently indexed
• Typical Documents Needed– PRD, System Architecture, Project Plan, Product Backlog, Weekly Status Report, Test Cases, Test Plan.
Confidential
3b. Iteration Planning & Estimation• Product Backlog is prepared in which high level
gross estimates are done against all the requirements and the requirements are arranged in their order of priority.
• Requirements with higher risk are addressed first.
• Iteration plan has detailed tasks listed with hours estimated against each task.
• There has to be some flexibility in every estimate. At least one of the three - time, resource, scope - needs to be flexible.
Confidential
Sample Product Backlog
Confidential
Iteration Plan/Sprint Backlog
Confidential
Iteration Project Plan - ExampleHigh Level Iteration Plan For Development Phase of PRM Enhancement Work
IterationNumber of Weeks Start Date End Date User Story (Requirements)
Deliverables for the Iteration
1 3 11-Feb-08 29-Feb-08
Bulk Charge-out, Bulk Charge-in
Bulk charge-out, charge-inPass-along
2 2 3-Mar-08 14-Mar-08
Bulk Mark Destroyed, Bulk Move
Pass-along, Bulk Mark Destroyed
Create/Modify Barcode Printing Rule
Pass-along
3 2 17-Mar-08 28-Mar-08
Bug Fixes, changes for Bulk charge-out, charge-in, Mark Destroyed, Pass-along
Create/Modify Barcode Printing Rule, Bulk Move
Bulk Move
Create/Modify Barcode Printing Rule
4 2 31-Mar-08 11-Apr-08
Bar Code Printing PoC
Delete Barcode Printing Rule
Delete Barcode Printing Rule
Reconciliation
5 2 14-Apr-08 25-Apr-08
Bug Fixes, changes for Create/Modify/Delete Barcode Printing Rule
Reconciliation, Bar Code Printing
Bar Code Printing
Reconciliation
6 2 28-Apr-08 9-May-08
Bug Fixes, Minor changes for Reconciliation, Bar Code Printing
System Testing
System Architecture Document
7 1 12-May-08 16-May-08 Final System Testing, Documentation System Architecture Document
Confidential
Automated Build Script1. Build script is to provide an automated
way to generate system builds in a repeatable and consistent manner.
2. With Automated Build, you can automate the build, test and release processes and focus on more important issues.
3. Helps reducing the time and effort needed to create your application builds.
4. The build script will be part of Continuous Integration which gets triggered based on the rules e.g. developer checks-in a code file which triggers the build process.
Confidential
3c. Daily scrum, wkly report, mnthly review
• What Works• All team members answer three standard questions in the scrum which
is a 10-25 minutes stand up meeting.• Scrum happens next to the wall on which stories are put up under each
team member’s name. (See picture)• Weekly report indicates progress in terms on % completion on various
tasks.• Monthly review has no major surprises as the client team has already
gone through the salient issues.
• What Doesn’t• Team members work in isolation and no one knows what the others
are working on.• Members digress and start discussing issues and solutions in the
scrum.• Weekly report gives no idea of progress by using open statements like
“this week the team continued to work on UI layer”
Confidential
User stories on the wall
Confidential
3d. Test automation + test driven development
• What Works• Customer’s buy in is required so that team can spend the required
hours on writing tests before rushing into write the code.• Team’s buy in is required because it takes more efforts to think through
the unit tests before the code is ready. Developers find it easier to write the code than to write tests.
• Tests should run every time you build. The build should fail even if one test fails.
• Unit testing and coding happen in parallel as an intense pair programming exercise.
• What Doesn’t• Unit tests are an after thought and only partially test the code.• Unit tests are written presuming certain data and environment and they
start failing and stop being used once the data and the environment change.
• Test driven development initiative starts with writing unit tests for legacy code.
Confidential
3e. Change control and re-estimation
• What Works• New requirement or change is brought to the client’s notice right at the time
when the requirement gets communicated.
• Burn down chart shows old requirements and change requests separately.( See release burn down bar chart)
• Change requests are added to the further iterations. Re estimation is done at the end of each iteration.( See cone of uncertainty)
• What Doesn’t• Teams engage in an endless discussion whether a feature is new or part of
the original requirements or a bug.
• Changes are implicitly assumed to be included in the estimate and a separate estimation exercise is not carried out.
• Test cases don’t reflect the changes.
• Unit tests are not modified to test for the change.
Confidential
Release burn down bar chart
Sto
ry P
oint
s
Iterations
ITR 1
ITR 2 ITR
3 ITR4
ITR 5
Confidential
3f. Coding standards and code review
• What Works• Coding standards are shared in a document form between the teams.
• Naming conventions are documented.
• Peer to peer review , self review and automated review are used in addition to a senior member’s formal review.
• What Doesn’t• There is no explicit agreement on which coding standards are being
followed.
• All code is expected to be reviewed by the lead or the architect.
Confidential
3g. Release process and documentation
• What Works• There is a release document covering salient features that have got added,
bugs that are fixed and known open issues if any.
• Release numbers indicate major, minor and build number explicitly.
• Release version is tagged in version control.
• Production Release Process
• What Doesn’t• There is a no release process. Last known working version is released to
production.
• Release numbers don’t indicate whether it’s a major or a minor release.
• Release endlessly waits for a 100% bug free version.
Confidential
Production Release Process
Get latest versionCheck out related files
Code changeLocal testing
DEVELOPER PC SourceControl Server
Team testing (optional)
BuildServer
Sand box
Check in source code
Get latest versionCreate new build
New build installed on QA server
QA Server
Pass QA? Roll back changesNo
New release installed on staging server
Get latest versionCreate new build (new release)
StagingServer
Deploy to production server
Source code zip file created and stored in the SourceContrrol
Yes
DEVE
LOPM
ENT
QAST
AGIN
G
1. Source Code is taken from Source Control and build on Build Server.
2. Successful build it is copied to QA Server.
3. If QA passes the test, the new release is installed on Staging Server.
Confidential
3h. Review of Iteration Deliverables• What Works
• Client reviews Iteration Deliverables at the end of every iteration and provides feedback about the same.
• What Doesn’t• Iteration Deliverables are not timely reviewed by the client.
Confidential
3i. Retrospectives• What Works
• It’s used as a process to improve by accepting constructive criticism.
• Teams willingly provide feedback in genuine interest of the project.
• What Doesn’t• Not having retrospectives- teams repeat the same mistakes.
• Retrospectives are used to do finger pointing. (Blame doesn’t fix bugs!)
• Teams keep quiet – “why to bring up an unpleasant topic- especially if it concerns your customer”?
Confidential
4. Select Appropriate Discipline?
Unacceptable
Light Medium Heavy Overkill
Requirements/Planning (3a, 3b, 3c)
No formal requirements doc/Emails
Excel or Word Document
Wiki/SharePoint/SRS/Iteration Plan/Whiteboard
Wiki/SharePoint/SRS/Iteration Plan/Whyiteboard/Client Signoff
All steps of typical Waterfall model
Development /Coding Practices/Change Control (3e, 3f)
No Process Development Guidelines/Peer code reviews/CR
Development Guidelines/Peer code reviews/Senior Architect Reviews/CR
Development Guidelines/Peer code reviews/Senior Architect Reviews/Low Level Design review/ Client Signoff/CR
Development Guidelines/Peer reviews/Team Lead review/ Senior Architect Reviews/LLD review/ Client Signoff/CR/Approvals
QA (3d) No QA Process
QA Process/ 1QA - 4 Dev
QA Process /1.5 QA – 4 Dev
QA Process /2 QA – 4 Dev QA Process /3QA – 4 Dev
Build and Release (3g, 3h)
No Process Manual Build and Release process
Automated Build / Release Process/ Periodic Client Signoff
Separate Build/Release Environment/
Automated Build and Release/ Client Signoff with each Iteration
Separate Build/QA/Release Environment/
Automated Build and Release/ Client Signoff with each iteration
Documentation
No formal Documentation/Emails
PRD/System Architecture
PRD/System Architecture/Test Plan/Test cases/Wiki/SharePoint
PRD/System Architecture/Design Documents/Test Plan/Test cases/Release Plan
All Documents of Typical Waterfall Model
Within the Agile approach, different projects have differing need for process discipline/ rigor. We need to select the appropriate level of discipline