Agile Principles:
1.
Satisfy customer
through early and continuous delivery
2.
Welcome changing requirement, even late
in development
3.
Deliver working software frequently with shorter timescale
4.
Business Peoples
and Developers must work together
daily throughout the project
5.
Build projects with
motivated individuals. Give them
environment and support they need to get job done
6.
The most efficient & effective method of
conveying information within team is face-to-face
conversation
It has only
three team roles, five events and three artifacts (deliverables).
1.
Product Owner (PO)
·
PO represents Business stakeholders. It is
an individual and not a committee
·
PO defines, what needs to be build and in what order,
which is defined in the Product Backlog
·
Anyone in scrum
team can change the product backlog but must
be done with PO’s knowledge. PO is accountable
for the contents and the order
of the items in the Product Backlog
·
PO is responsible
for communicating backlog items clearly. S/He works with Development team to
define what needs to be built in Sprint Planning, Refine Product Backlog Items
and provide clarifications on the same
2.
Development Team Member (TM)
·
TM defines how items of the Product Backlog will be
converted into an iteration of the working product. S/He write code,
design, test, produce documentation and do
whatever is necessary to convert
a set of Product Backlog items into a potentially shippable product at the end of each stage.
·
Recommended size is
between 3 to 9. Sometimes PO and
Scrum Master performs the duties of
Development team member. There is no
Team Lead or Manager is the team.
·
TM works closely
with PO to estimate and clarify the
Product Backlog Item and works with SM to address
impediments that prevents progress
3.
Scrum Master (SM)
·
SM is Scrum Expert. They are the Scrum and Agile coach for PO and
Development team
·
SM helps to resolve any issue experienced by the
Development team or Product Owner
·
Works closely in Planning process
Sprint is the work period to
produce an iteration of a workable product, which is time boxed to 30 calendar days or less. Sprint is the
container event for rest of the four
events. Sprint Planning is the first
event of the sprint. It is the event in which scrum team defines what the
Development team works on and how they will execute the plan.
Development team meets every day to inspect their work and adapt it to be more efficient,
it is called Daily Scrum. Sprint
ends with two events Sprint Review
and Sprint Retrospective. In Sprint
Review, team reviews their work and
progress occurred during the sprint. In Sprint Retrospective team gets together to discuss how they can be more efficient.
The sprint only
can be cancelled by the Product Owner if sprint goal is no longer valid,
because of outside factors like budget cuts, mergers
Cancelling a sprint because the development team
is behind schedule is not a valid reason.
Scrum Artifacts:
1.
Product Backlog is the to-do list for the Development team
which contains Requirements, Enhancement Requests, Defects, User Stories, New
Features. Product Backlog looks like iceberg
where the smaller items are at the top and the larger ones are at the bottom. Larger items need to be refined.
2.
Sprint Backlog is the subset of the Product Backlog items
selected for the sprint plus the Development team’s plan
3.
Product Increment is the current
‘done’ version of product itself. It
should be usable and provide some business value.
·
Daily scrum is not a status
meeting. It is an opportunity for the development team to sync up on their goal towards the Sprint
Goal. They can conduct it in whatever way they want. While it is a common
practice to conduct the Daily Scrum as a standup meeting, it is not required to be a standup meeting per
Scrum Guide. The Product Owner and Scrum Master are not required to attend this meeting.
·
Sprint Review include an informal product review by external
stakeholders which includes showing to the stakeholders what has been built.
The Product "Demo" is
generally not scripted and it is not the only item included in the Sprint
Review. A general guideline is to let
the stakeholders try product features instead of just watching a demo of
the product. Sprint Review also includes future
planning based on latest market conditions and enterprise goal.
XP –
Extreme Programming
XP uses weekly
iterations. Each iteration/cycle starts with the customer providing a list of requirements, which they would like to
deliver at the end of the week. Developers breaks the requirements/stories into
tasks and estimates it.
XP also has a Quarterly Cycle which is like a container for the weekly cycle. Quarterly Cycle enables team for
the high level planning.
XP team members do not work overtime and only work the number of hours that they can be productive and sustain for a
long period of time.
XP team works in an environment where all the information like work status, process is
quickly available using digital screens,
dashboards, wall charts etc.
XP team do test-first
development; means they do not write a code before a test for that code is
written. XP team spends a good amount of time on refactoring the code.
XP team uses pair
programming; means each workstation
has two persons working together on the code. One person types the code while other person
provides instant code review. These
two persons switch their roles periodically.
Concerns in
Pair Programming:
1.
It’s like reducing team size by 50%
2.
Some individuals
can work more productively alone;
they don’t need other person to work with him
Benefits of
Pair Programming:
1.
It provides immediate and constant peer review feedback which improves the
Code quality
2.
Pairs are
frequently changed so improve team
communication
3.
It facilitates knowledge sharing between the pair.
4.
There are two types
of individual:
a.
I-Shaped people – Deep knowledge
with narrow are of skills
b.
T-Shaped people – Deep knowledge
in certain range of skills and also possesses knowledge of wider skills E.g. A
person good a Business Analysis and also has useful knowledge of Software
Design and Test Automation
5.
So Pair Programming
helps people to be T-Shaped
6.
In Pair
Programming, less time spent in personal
distractions like checking emails, stock market, sports score or social
media. Less personal distraction means more
productive and focused.
XP follows Test
Driven Development (TDD)- Thinking about the test scenarios before the
implementation.
Steps in
TDD:
1.
Write test for the
code that is yet to be written
2.
Write a function so
you have enough code to be compiled. Test should be failed. If test passes,
means test is inadequate to verify functionality
3.
Complete code to
meet the requirement of the test
User Story is a simple way of defining the product requirement which is
typically written on index card, sticky notes or any other digital tools.
An Epic
is a large User-story which represents a business
work flow or process and is large to be estimated. Steps in the Epic may be
User stories or Epic themselves.
Agile
Estimation:
It does not consider only coding and testing, it
is more of refining Product Backlog
Items into smaller implementable items and then estimating what it takes to
convert that backlog item into done item.
Estimates are given by the team member not by the managers.
Traditionally we were using Absolute units for the estimation like hours, days or weeks. These
estimates can be vary significantly based upon individual’s skills, experience etc.
Agile suggest estimation using Relative Units. Agile team uses two
series of numbers for ranking the user stories – Fibonacci series (0, 1, 2, 3, 5, 8, 13), Exponential Series (0, 1, 2, 4, 8, 16)
Agile teams also use T-shirt sizing method for estimation. XS > S > M > L >
XL
DevOps:
The
Problem:
As agile process needs frequent builds/releases to deliver new ‘done’ version of product, Operations team is more worried about the service agreements and the failure at the production environment due to different external factors. So Operations team follows different processes like checklists, certain approvals etc. which slowdown the deployment process.
The
Solution:
DevOps is the culture and practice of closer co-operation between Developers and
QA teams (Dev) and Operations team (Ops). It is supported by various processes
and tools E.g. Build Automation, programmatically
configuring infrastructure, automated monitoring deployed applications etc.
It enables organizations to deploy fixes and new
features quickly and keep deployment more stable.
Key Aspects
of DevOps:
1.
Continuous Integration (CI) is the
practice of frequently committing
changes to the source code and trigger
an automated build that validates the code base for compilation errors,
code quality matrix, Automated tests, Missing dependencies etc. Developers get quick feedback on any issue and fix
them on priority.
2.
Continuous Delivery (CD) is the
capability to keep the product always stable after every change so that it is
always shippable
3.
Continuous Deployment means automatically deploying the product
incremental to production or production-like environment. Continuous Deployment
may or may not follow Continuous Delivery
