Agile Principles

Asfar K
 Agile principles
Individuals and Interactions over Processes and
Tools
Working Software over Comprehensive
Documentation
Responding to Change over Following a Plan
Maintain simplicity
Incremental delivery
Individuals and Interactions over
Processes and Tool
self-organization and motivation
Interactions like co-location and pair
programming.
Responsibilities are not assigned individuals, but
are communicated to the team as a whole.
The team determines the best way to fulfill those
responsibilities.
collective ownership of the system code.
 The best architectures and designs emerge from
self-organizing teams. No single team member is
solely responsible for the architecture or the
requirements or the tests.
let the team configure the environment on the
basis of need.
a sustainable development process that does not
involve excessively long working hours.
An agile project is not run like a 100m run; it is run like a
marathon.
Work at a rate that allows them to maintain the highest-
quality standards for the duration of the project.
Working Software over Comprehensive Documentation

Working software is the primary measure of

progress.
Demo working software is considered the best
means of communication with the customer to
understand their requirement
Too much documentation is worse than too little.
Write and maintain a short high level
design/architecture document is good idea.
 Responding to Change over Following a Plan
Expect the system requirements to change and so
design the system to accommodate these
changes.
Keep the structure of its software flexible, so that
when requirements change, the impact to the
system is minimal.
Use Object-oriented design principles, patterns,
and practices help us to maintain flexibility.
Retro - The team reflects on how to become more
effective, then tunes and adjusts its behavior
accordingly.
 Maintain simplicity
Focus on simplicity in the product and in the
development process.
Design should be easy to modify and maintain.
simple designs that do not unnecessarily
anticipate future changes to the system.
Continuous attention to technical excellence and
good design
Clean any messes as they are made.
Don't tolerate duplication of code. Wherever find
it, eliminate it.
Self-Documenting Code
 Incremental delivery

The software is developed in increments with the

customer specifying the requirements to be included
in each increment.
Satisfy the customer through early and continuous
delivery of valuable software.
Evolutionary (Incremental) Design and Architecture
Deliver stories every week without compromising design
quality.
Build domain models and persistence frameworks
incrementally, in small pieces, as you deliver stories.
 Incremental design
No need to skip coding for an iteration for
refactoring or design.
Every sprint, the quality of the code is better
than it was the sprint before.
As time goes on, the software becomes
increasingly easy to maintain and extend.
Nothing clarifies a design issue like working
code.
See this in action in Test Driven Development
 Incremental Design
When you first create a design elementwhether its a new
method, a new class, or a new architecturebe completely specific.
Create a simple design that solves only the problem you face at the
moment, no matter how easy it may seem to solve more general
problems.
The second time you work with a design element modify the design
to make it more general
but only general enough to solve the two problems it needs to solve.
Review the design and make improvements. Simplify and clarify the code.
The third time you work with a design element generalize it further
but again, just enough to solve the three problems at hand. A small tweak
to the design is usually enough. It will be pretty general at this point. Again,
review the design, simplify, and clarify.
 Its Not Just Coding
Design is so important in agile that we need to do it all the time.
Incremental design focuses on
test-driven development
Refactoring
Pair discussion(lots of conversation about design)
Some of the design discussions
What should we name this method?
These two classes share some responsibilities. We should split them apart
and make a third class.
Have design discussions away from the keyboard if necessary
Use modelling techniques you find helpful.
Use Sketches on a whiteboard or CRC (Class, Responsibility,
Collaborator) cards if necessary.
 Technical debt
known as
design debt
code debt
Total amount of less-than-perfect design and
implementation decisions in your project.
This includes quick and dirty hacks intended just to get
something working right now!
The extra development work that arises when code that
is easy to implement in the short run is used instead of
applying the best overall solution.
when we take shortcuts today at tomorrows expense.
 Nave Technical Debit

Caused by
Team member immaturity and process
deficiencies that lead to sloppy design, poor
engineering practices, and a lack of testing.
This kind of debt can be eliminated through
Proper training
a good understanding of how to apply technical
practices
sound decision making.
 Unavoidable Technical Debt

usually unpredictable and unpreventable.

We cant perfectly predict up front how our
product and its design will need to evolve over
time.
Third-party component for use in our product
and the interfaces to that component evolve
over time.
 Strategic(deliberate)
A tool that can be used to help organizations better quantify and
leverage the economics of important, often time-sensitive,
decisions.
For example, an organization might deliberately make a strategic
decision to take shortcuts during product development to achieve
an important short-term goal, such as getting a time-sensitive
product into the marketplace.
Also, for a capital-strapped organization that is at risk of running out
of money before it can complete its product, getting a product with
technical debt to market at a reduced initial development cost and
then generating revenue to self-fund ongoing development may be
the only way for the organization to avoid death before deployment.
 Technical Debt
Raises awareness of and provides visibility into an
important issue.
Like financial debt, technical debt requires interest
payments, which come in the form of extra future
development effort.
We can choose to continue paying the interest (by
working around the problems), or
we can pay down the debt principal (by refactoring
the code to make it cleaner and easier to modify).
 Causes of Technical Debt
Pressure to Meet a Deadline
Attempting to Falsely Accelerate Velocity
Less Testing to Accelerate Velocity
Debt Builds on Debt
 Use a Strong Definition of Done
Properly Understand Technical Debt
Economics
Making Technical Debt Visible
Business Level
by tracking velocity over time
Technical Level
Add Technical Story in product backlog.
 Servicing the Technical Debt
Not All Technical Debt Should Be Repaid
Product Nearing End of Life
Throwaway Prototype
Product Built for a Short Life
Service Debt When You Happen Upon It
Repay Technical Debt Incrementally
Repay the High-Interest Technical Debt First
Repay Technical Debt While Performing
Customer-Valuable Work
Managing the Accrual of Technical Debt

Use Good Technical Practices

simple design,
test-driven development
continuous integration
automated testing
refactoring
 Continuous Integration
The ultimate goal is to be able to deploy the code at any
time.
Integrate your code as often as possible (every few hours).
Keep your build, tests up-to-date.
Most software development efforts have a hidden delay
between when the team says were done and when the
software is actually ready to ship.
Merge request are most likely when youre making wide-
ranging changes.
When you do, let the rest of the team know beforehand so they
can integrate their changes and be ready to deal with yours.
 Appropriate Uses of Branches
Useful for continuous integration and other code
management tasks.
These private branches live for less than a day.
To eliminate the need for a branch entirely, automatically
migrate your customers and users to the latest version
every time you release.
Can create a branch in preparation for a release. The team
continues to perform new work, and few team members
stabilize the old version.
Bug fixes to release branch needs to be migrated to new
development branch immediately.
 If it's not broken, don't fix it!"?
Every software module has three functions.
1. Function it performs while executing.
This function is the reason for the module's existence.
2. To afford change.
changes should be as simple as possible.
3. Communicate to its readers.
Developers who are not familiar with the module should
be able to read and understand it without undue
mental gymnastics.
 Why Refactoring
In principle the software should always be easy to understand and
change as new stories are implemented. In practice, this is not
always the case.
Incremental development tends to degrade the software structure,
so changes to the software become harder and harder to
implement.
The need to make the change quickly for a release means that you
may not be able to follow the formal change analysis process or
give best possible design.
Emergency system repairs usually have to be completed as quickly
as possible. You chose a quick and workable solution rather than
the best solution as far as system structure is concerned.
Changes become difficult and maintenance costs increase.
 Preventative maintenance by refactoring

Process of changing a software system in such a way that it does

not alter the external behavior of the code yet improves its internal
structure.
It means modifying a program to improve its
structure,
to reduce its complexity,
to make it easier to understand.
Through refactoring, continuously keep the code as clean, simple,
and expressive as it can be.
Refactoring is done continuously rather than at the end of the
project or the end of the release
Obviously, this means additional costs, over and above those of
implementing required system changes.
 Test-driven development
(Executable requirement Spec)

Identifying the functionality(user story/task) to implement. This

should normally be small and implementable in a few lines of code.
Write a test for this functionality and implement this as an
automated test.
Run the test, along with all other tests that have been
implemented. Initially, you have not implemented the functionality
so the new test will fail.
Implement the functionality and re-run the test. This may involve
refactoring existing code to improve it and add new code to whats
already there.
Once all tests run successfully, you move on to implementing the
next chunk of functionality.
 Test-Driven Development

The tests tell us that the program is behaving properly after

some changes.
We are thus much freer to make changes and improvements to our
program.
Writing tests before code improves our designs.
By writing the test first, we design the software to be conveniently
callable.
We force ourselves to design the program to be testable.
In order to be callable and testable, the software has to be decoupled
from its surroundings.
Thus, the act of writing tests first forces us to decouple the software!
Tests act as an invaluable form of documentation
This documentation is compilable and executable. It will stay current.
 Pair programming
Programmers work in pairs to develop the
software. They actually sit together at the
same workstation to develop the software.
However, the same pairs do not always
program together. Rather, pairs are created
dynamically so that all team members work
with each other during the development
process.
 Pair programming advantages
The number of errors avoided by the informal
inspection is such that less time is spent repairing
bugs discovered during the testing process.
Improved design/code quality.
The sharing of knowledge that happens during pair
programming is very important as it reduces the
overall risks to a project when team members leave
It helps support refactoring, which is a process of
software improvement.
 Root-Cause Analysis
When mistakes occur, blame your process, not people.
What allowed the mistake to happen?
What will prevent them in the future?
Assume people will continue to make mistakes and build fault-
tolerance into your process improvements.
One approach: ask "why" five times. Use it for every problem
you encounter, from the trivial to the significant. You can apply
some solutions yourself.
When mistakes become rare, avoid over-applying root-cause
analysis.
Balance the risk of error against the cost of more process
overhead.
 Stories

Stories represent self-contained, individual

elements of the project.
Individual features
Typically represent one or two days of work.
Stories are customer-centric, describing the
results in terms of business results.
Not
implementation details
full requirements specifications.
 Velocity

Its the total of the estimates for the stories

finished in an iteration.
The team should be able to achieve the same
velocity in every sprint.
This allows the team to make sprint
commitments and predict release dates.
The units measured are deliberately vague.
Has no relation to productivity.
 Daily Stand-Up Meetings

We know what our teammates are doing.

Not a status meetings.
How to Hold a Daily Stand-Up Meeting
In the Daily Scrum, participants specifically
answer three questions:
1. What did I do yesterday?
2. What will I do today?
3. What problems are preventing me from making
progress?
 Retrospectives

We continually improve our work habits.

No process is perfect.
Your team is unique, as are the situations you
encounter, and they change all the time.
Continually update your process to match your
changing situations.
Retrospectives are a great tool for doing so.
Never use a retrospective to place blame or
attack individuals.
 How to manage
Nonfunctional Requirements(Quality)
Desirable characteristics of the software.
known as
technical requirements,
quality attributes,
quality of service requirements
Enforce the structural quality of the software
These quality requirements can be divided into two
main categories:
1. External quality
2. Internal quality
 External Quality
External quality consists of those highly desirable
attributes perceived during the execution of the
software.
They are highly visible and rarely requested.
But, their absence quickly causes dissatisfaction.
Fortunately, not all of them are of equal importance.
Ignoring those nonfunctional requirements is one of
the shortcomings found abundantly in many software
applications.
The lack of expertise regarding architecture.
Affect the entire system and difficult to isolate.
 Dependability
The dependability of systems is more important than
their detailed functionality
Availability - up and running and able to deliver useful
services to users at any given time.
Reliability - over a given period of time, the system will
correctly deliver services as expected by the user.
Robustness to cope to with errors during execution.
Safety - how likely it is that the system will cause damage to
people or its environment.
Security - how likely it is that the system can resist accidental
or deliberate intrusions.
 Other External qualities
Accessibility
Ease with which software can be accessed by as many people as
possible
Performance
Measured as response time or throughput
Scalability
Capability of the software to handle growing amount of work in
graceful manner.
Usability
Ease with which the software can be used by specified users to
achieve specified goals.
 Architecture
The issue is so critical that teams should formalize the
role of the architect and ensure that at least one team
member takes ownership of this role.
The architect specifies an emergent architecture in
two ways:
By addressing nonfunctional requirements in small chunks
and in a timely manner
By designing technical abstractions through thoughtful
reduction and organization. The architect leads the design
of the structural foundation upon which the solution is built
by the team. The architect works collaboratively with every
team member to remove accidental complexity and
pursues simplicity in the design.
 Architect
Correctly addressing quality attributes is one of the most
visible areas of architects work.
Learning to master the nonfunctional requirements is a
skill that architects acquire with experience.
Translate nonfunctional requirements into restrictions
and make them explicit knowledge shared by the whole
team.
A factor often underestimated is that explicit and highly
visible elements are always taken into consideration by
the team. As such, restrictions are the visible elements
that guide the work and help determine whether the
team has satisfied the nonfunctional requirements.
Improving External Quality Using Restrictions

The most common mistake when specifying software

requirement is
the lack of a clearly defined set of restrictions that summarize
the required quality.
A restriction imposes conditions that set a limit to comply
with.
This simplifies the design by setting a goal that will be
recognized and shared by the whole team.
When this step is done correctly, those restrictions can
guide the team to successfully address nonfunctional
requirements.
Restriction
 SMART principle
A restriction should be:
Specific: It should target a piece of functionality that is
small, consistent, and simple.
Measurable: It imposes a limit that is measurable;
otherwise, how would you know when youve addressed it?
Attainable: It is recognized as achievable by the team.
Relevant: It is directly related, connected, and pertinent to
the nonfunctional requirement.
Traceable: It is linked with a functional requirement that
justifies why it exists. Explicitly setting restrictions is a simple
and obvious step to start with.
 Examples
Given the buyer is a student,
Restrict with response time less than 5 seconds.
Given the buyer is user 'KnownBuyer'
Restrict with the buyer to be authenticated positively
Given the buyer is user 'UnknownBuyer'
Restrict with the buyer to be authenticated negatively Then issue is
saved in security database and user is redirected to "Login" page
Imagine that the software should not handle more than 10,000
concurrent users. You could express the restriction as this:
Restrict after 10001 occurrences with a failed login Then user is
redirected to page "Server unavailable. Please try later.
 Testing Restrictions with Proven Practices
Non functional Requirement Testing practice
Correctness Acceptance testing
Performance Measure response time and inspect throughput
Reliability Seek extraordinary resource conception over a
specified time (CPU, memory, disk space)
Robustness Test for invalid input and stressful environment
condition (stress testing)
Scalability Verify software behavior under anticipated peak load
conditions (Load Testing)
Security Perform intrusion detection and vulnerability scanning
Usability Consistency inspection, activity analysis to verify user
has achieved their specified goal.
Restriction it takes more effort/time
Confirming restrictions with proven practices
can be expensive in terms of effort.
Question every nonfunctional requirement to
validate whether it is actually required.
Often people underestimate the work to be
done for Nonfunctional requirements.
Deferring the restriction can lead to a large
amount of reworking in future sprints, due to
architectural considerations.
 Internal Quality
Not visible to stakeholders but simplify how to build and
evolve the software.
The team must always deliver a sprint with enough
internal quality so that it can easily continue to extend it
in future iterations.
If the nonfunctional requirements that affect the
internal quality are successfully met, the software under
construction is not only simplified, but its sustainability
is also preserved for future changes.
Use sound software engineering practices to ensure
the software construction is done correctly.
 Internal Quality
Name Definition
Simplicity Ease of understanding and explaining
Maintainability Ease of changing and evolving with minimal effort
Testability Ease of confirming conformance by testing
Portability Ease of reuse by multiple platform
Extensibility Ease of feature additions and future changes
(Many teams consider fictitious extensibility requirements at the
expense of the stakeholders immediate needs. Extensibility requires
the team to anticipate and predict the future, which is precisely
what agile software doesnt do in development. This is significant
because whatever you build upfront, as a response to an anticipated
future, will have to be refactored to fit the final requirements.)
Improving Software Construction with
Explicit Practices
Non functional Practices
Requirement
Simplicity Self documenting code: naming convention, code layout, logic
structure, useful and up to date comments.
Code metrics: measure complexity of the source code
Maintainability Continuous Integration: Immediately tested and reported one
developer check-in
Branching and merging: Tagging with the user story or scenario
or tractability.
Testability Red-green-refactor: TDD, write test first from spec and code for
tests written to pass.
Code coverage: measure test code coverage
Portability Multi-target compiling
 In contrast to the external quality, you can
hardly postpone the work required to ensure
simplicity, maintainability, testability, or
portability. Postponing creates a technical
debt that can cripple the teams ability to add
new functionality.
It is therefore important for the team to
master the engineering practices and apply
them on a daily basis.
 Definition of Done checklist
It is current practices and standards of the team.
This is the checklist team members complete when producing
software.
Code completed.
0 (known) bugs.
Passed unit tests.
Code peer-reviewed or paired.
Code checked in.
Deployed to test environment and passed tests.
Documentation updated.
Evolve Over Time
From time to time practices should be revised in response to
retrospective and continuous improvement.
Thank You