Upload
lyphuc
View
224
Download
0
Embed Size (px)
Citation preview
Agile Training
Topics Covered
• Agile Fundamentals
• Jira Workflow
• Release Process
• Glossary
Agile Principles
The Agile Manifesto is based on 12 principles:
• Customer satisfaction by rapid delivery of useful software
• Welcome changing requirements, even late in development
• Working software is delivered frequently (weeks rather than
months)
• Close, daily cooperation between business people and
developers
• Projects are built around motivated individuals, who should be
trusted
• Face-to-face conversation is the best form of communication
(co-location)
Agile Principles
• Working software is the principal measure of progress
• Sustainable development, able to maintain a constant pace
• Continuous attention to technical excellence and good design
enhances agility
• Simplicity—the art of maximizing the amount of work not
done—is essential
• Self-organizing teams
• Regular adaptation to become more effective.
Agile Philosophy
Important
• Processes and tools
• Detailed documentation
• Contract negotiations
• Following a plan
More Important
• Individuals and interaction
• Functioning software
• Collaboration with the customer
• Adapting to changes
Why Agile?
• Business Value - The ROI and Time to Market is much quicker or faster in
Agile approach.
• Uncertainty and risk is reduced.
• Early Feedback
• Managed Complexity
• Inspect & Adapt
Scrum Characteristics
“Scrum is an iterative and incremental agile software development framework for managing product development.”
• Self-organizing teams
• Product progresses in a series of month-long “sprints”
• Requirements are captured as items in a list of “product backlog”
• No specific engineering practices prescribed
• Uses generative rules to create an agile environment for delivering projects
Scrum
Daily Scrum Meeting
• Done since last meeting
• Plan for today
• Obstacles?
24 hours
2-4 weeks
Product Backlog • Prioritized product features
• Add to at any time
Sprint Backlog expanded
by team
Sprint Planning Meeting
• Review Product Backlog
• Estimate Sprint Backlog
• Commit to iteration (2-4
weeks)
Potentially Shippable
Product Increment
Sprint Review Meeting
• Demo features to all
• Retrospective on the Sprint
Sprints
• Scrum projects make progress in a series of “sprints”
• Typical duration is 2–4 weeks or a calendar month at
most
• A constant duration leads to a better rhythm
• Product is designed, coded, and tested during the
sprint
No changes during a sprint
• Plan sprint durations around how long you can commit
to keeping change out of the sprint
Change
Scrum framework
•Product owner
•ScrumMaster
•Team
Roles
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Activities
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
Scrum framework
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Activities
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
•Product owner
•ScrumMaster
•Team
Roles
Product owner
• Has Product Vision
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as needed
• Answers requirement questions
• Accept or reject work results
Represents the voice of the customer to ensure
the Scrum Team works with the right things from
a business perspective.
The ScrumMaster
• Represents management to the project
• Runs meetings and manages process
• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences
• Moderator,Trainer,Mentor,Mediator
• Fosters continuous improvement
The team
• Typically 5-9 people
• Cross-functional:
• Programmers, testers, user experience designers, product owner etc.
• Members should be full-time
• May be exceptions (e.g., database administrator)
• Teams are self-organizing
• Ideally, no titles but rarely a possibility
• Collective responsible for delivery.
•Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Activities
Sprint planning meeting
Sprint prioritization
• Analyze and evaluate product
backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint
goal (design)
• Create sprint backlog (tasks)
from product backlog items
(user stories / features)
• Estimate sprint backlog in hours
Sprint
goal
Sprint
backlog
Business
conditions
Team
capacity
Product
backlog
Technology
Current
product
Pro
du
ct
Ow
ne
r
Sc
rum
Te
am
Cu
sto
me
rs
Ma
na
gem
en
t
Sprint Planning Meeting
Sprint planning
• Team selects items from the product backlog they can commit to completing
• Sprint backlog is created
• Tasks are identified and each is estimated (1-16 hours)
• Collaboratively, not done alone by the ScrumMaster
• High-level design is considered
As a vacation planner, I want to see photos of the hotels.
Code the middle tier (8 hours)
Code the user interface (4)
Write test fixtures (4)
Code the foo class (6)
Update performance tests (4)
The daily scrum
• Parameters
• Daily
• 15-minutes
• Stand-up
• Not for problem solving
• Whole world is invited
• Only team members, ScrumMaster, product owner, can talk
• Helps avoid other unnecessary meetings
Everyone answers 3 questions
• These are not status for the ScrumMaster
• They are commitments in front of peers
What did you do yesterday? 1
What will you do today? 2
Is anything in your way? 3
The sprint review
• Team presents what it accomplished during the sprint
• Typically takes the form of a demo of new features or underlying architecture
• Informal
• 2-hour prep time rule
• No slides
• Whole team participates
• Invite the world
Sprint retrospective
• Periodically take a look at what is and is not working
• Typically 15–30 minutes
• Done after every sprint
• Whole team participates
• ScrumMaster
• Product owner
• Team
• Possibly customers and others
Start / Stop / Continue
• Whole team gathers and discusses what they’d like to:
Start doing
Stop doing
Continue doing This is just one of many ways to
do a sprint retrospective.
•Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Activities
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
Product backlog
• The requirements
• A list of all desired work on the project
• Ideally expressed such that each item has value to the users or customers of the product
• Prioritized by the product owner
• Reprioritized at the start of each sprint
• DEEP-Detailed,Emergent,Estimated,Prioritized
This is the
product backlog
A sample product backlog
Backlog item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a reservation. 3
As a hotel employee, I can run RevPAR reports
(revenue-per-available-room) 8
Improve exception handling 8
... 30
... 50
The sprint goal
• A short statement of what the work will be focused on
during the sprint
Database
Application
Financial services
Life Sciences
Support features necessary for
population genetics studies.
Support more technical indicators
than company ABC with real-
time, streaming data.
Make the application run on SQL
Server in addition to Oracle.
Managing the sprint backlog
• Individuals sign up for work of their own choosing
• Work is never assigned
• Estimated work remaining is updated daily
• Any team member can add, delete or change the sprint backlog
• Work for the sprint emerges
• If work is unclear, define a sprint backlog item with a larger amount of time and break it down later
• Update work remaining as more becomes known
A sprint backlog
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Write the foo class
Mon
8
16
8
12
8
Tues
4
12
16
8
Wed Thur
4
11
8
4
Fri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chart
Ho
urs
Scalability
• Typical individual team is 7 ± 2 people
• Scalability comes from teams of teams
• Factors in scaling
• Type of application
• Team size
• Team dispersion
• Project duration
• Scrum has been used on multiple 500+ person
projects
Scaling through the Scrum of scrums
The Procedure or The Ticket Lifecycle using JIRA
The Procedure or The Ticket Lifecycle using JIRA
Requirements Gathering & Assignment
• The PO (Product Owner) comes up with a “New Feature /
Enhancement / Change Request“ and a PRD (Product Requirement
Description / Document). The PO creates a ticket in JIRA with these
details.
• The ticket is then “Prioritized“ for a “Sprint“ and assigned to a
smaller specific team based on the type of requirement (e.g.: Product,
Technology, Marketing, Operations)
• Grooming: Once “Prioritized“, the PO discusses the Ticket details
and requirements with the team. This is called Grooming
• Requirement Analysis: The Team sits together and analyses the
requirement. It further estimates the ticket in terms of Stories and
Story-points. The requirement is divided into smaller deliverable Story-
points.
• The Story is now divided into smaller Subtasks and assigned to
members of the Dev / QA team.
• Every JIRA Ticket (User Story), in the beginning, is in a state of
“Backlog”.
The Procedure or The Ticket Lifecycle using JIRA
Development
• Now, after the ticket is assigned to the dev team, the Developer changes
main ticket’s state to “In-Development” while implementing the changes,
and changes the state of the Subtask to “Closed” after Completion.
• After Completion of all subtasks, the Story is “Unit Tested” and “Buddy
Tested” (Tested by another Dev member of team) on the Dev
Environment.
• Following this, the ticket state is set to “Awaiting Review” and assigned to
a Reviewer for Code-Review.
• The Reviewer will code-review the ticket and change the state to “In-
Review”. After the review is completed, he sets the state to “Ready for
QA” (if it is found satisfactory), and “In-Development” if it is not.
• The QA member of the team then changes the state of the ticket to “In-QA
Testsystem”. If any issue is found, he reopens the ticket by changing the
state back to “In-Development” and assigns the ticket to the Developer.
• Again, after resolving the issue, the ticket goes through the review process
and is assigned to QA in “Ready for QA” state.
The Procedure or The Ticket Lifecycle using JIRA
QA & Test
• The QA changes the ticket state to “In QA – Testsystem”, deploys
and tests the ticket in a QA environment (a dedicated server assigned
for testing purpose only).
• If it passes, changes the state to “Ready for QA – Stage”.
• Also, once the ticket is QA Pass, it has to be integrated with the current
live code. For that, the QA announces on Skype – “INDFAS Releases”
Group chat that the ticket is “Ready for Prepare”
Note:
• If any issue is found, he reopens the ticket by changing the state back
to “In-Development” and assigns the ticket to the Developer.
• Again, after resolving the issue, the ticket goes through the review
process and is assigned to QA in “Ready for QA” state.
The Procedure or The Ticket Lifecycle using JIRA
Integration Testing
• The Release Manager then creates a new “Prepare” branch from
current live code (also called Current TRUNK). The prepare branch is
a common branch in which all the QA tickets in “Ready for Prepare /
Ready for QA-Stage” state are added / integrated.
• Once Prepare branch is ready, it is deployed to one of the Staging
Test Environments and status of the ticket is set to “In QA – Stage”
• The QA team tests the integrated code using ‘Almost Live Data’ to
ensure complete compatibility on the Staging environment.
• If the ticket succeeds in the final QA Tests, the ticket is marked “Ready
for Release”.
The Procedure or The Ticket Lifecycle using JIRA
UAT & Go Live • A PO and Automation Team signoff request email is sent to all the
stakeholders and automation team respectively, which lists out: o All the tickets & POs who will give the signoff for Go-Live for the
ticket. o The Team, Developer, QA & respective Automation POC for
different platforms (eg: Desktop, Mobile Web and Mobile Apps) and impact areas
o URL of staging server where the prepare branch is deployed for verification
• The QA team in parallel runs tests to verify each ticket. • The Sysad Manager provides the ideal time slot for the go live based
on website traffic and expected downtime of website during deployment (eg: in case of high impact changes and more than 5 minutes downtime, the release time is kept between 3 AM and 7 AM); and also the name of the sysad POC who will deploy the build to live servers.
The Procedure or The Ticket Lifecycle using JIRA
UAT & Go Live - continued • Once a Go Ahead is obtained from POs and the automation team, the
QA Team emails “Release Notes” to sysad team (Please refer to glossary for Release Notes definition).
• The Release Manager then verifies the Release Notes for their accuracy and give go ahead for live.
• At the established time, with help from sysad POC, the build is deployed on Live Servers.
• After final tests and verification on Live Environment, the QA changes the ticket status to “Closed”
• The Release Manager now integrates the live “Prepare” branch to current MASTER branch in GIT repository.
Skype – Important Chat Groups & Purpose
• Indfas India : This is the common chat between the Tech Team members and
Sysad Team, for deployment requests to Dev / QA Environments.
• INDFAS Releases : This chat is required for co-ordination with Release
Manager for integration of Tickets with current code.
• INDFAS : This is the common chat between the Tech Team members and
Sysad Team, for deployment requests to Staging & Live Environments.
• QA India Ver 2.0 : This is the common chat between the QA Team members
(for co-ordination of branches going live)
Glossary
• Dev Environment : This is a common server assigned to Development team for
their verification of a ticket before being assigned to QA Team. The Dev Team
can do Unit, Sanity, & Buddy Testing on this environment.
• QA Environment : This is a common server assigned to QA Team members for
their verification of a ticket before going ahead for Integration Testing.
• Staging Environment : This is a common server assigned to QA Team / Tech
Team members for their verification of integrated tickets with Current TRUNK /
Live Code before the changes are sent Live.
• Live Environment : This is the final environment where customers come to
shop on Jabong.
• Prepare Branch : The prepare branch is a common branch in which all the QA
tickets in “Ready for Prepare” state are added / integrated. It is a copy of live
code except for the tickets integrated to it.
• Current TRUNK : It is the current Live Code running on Jabong.com
• Release Notes : This document consists of details of tickets that are ready to go
live. E.g.: Ticket ID, Summary, Developer Name, Tester Name, DB Changes (if
any), Configuration Changes (if any), Pre / Post Release steps (if any), Known
Issues (if any), Sanity Test Cases run, etc. This helps the sysad team to identify
special cases that might need taking care of during Go-Live.
Glossary
• ScrumMaster: The person responsible for the Scrum process, making sure it is used correctly and maximizes it benefits.
• Team: A cross-functional group of people responsible for managing itself to develop the product.
• Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.
• Sprint Backlog: A list of tasks to be completed during the sprint.
• Product Backlog: A prioritized list of high level requirements.
• Sprint: A time period (usually 2 to 4 weeks) in which development occurs on a set of backlog items that the Team has committed to.
• Burn Down Chart: Daily progress for a sprint over the sprint's length.
Thank you