O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
Product Manager @ Data Dog
• Custom web development and support
• Cloud-based application and software development
• B2B, B2C eCommerce solutions
• Specialised in PHP
• Over 35 developers
• Wide base of clients: UK, US, UAE, Canada, Luxembourgh,
• Crypto-Currency exchange / Forex market
• 6 members in the development team
• Agile - Scrum, TDD, CI, CD
• PHP & GO
HOW WE WORK
• Prioritise features with the PO
• Work in short iterrations 1-2 weeks
• Development team chooses the features
• Write tests before each line of code (TDD & CI)
• Ship the feature as soon as it is ready (CD)
• Focus on performance & quality
BEFORE STARTING WITH IT
let’s look how Agile has evolved in response to
standard development issues
Most of us were taught to write down all our
requirements at the very beginning of the project.
There are only three things wrong with this:
“requirements”, “the very beginning,” and “all.”
There is a very strong “80-20” rule in software
development requirements lists.
Most of the business value comes from a very
small subset of the so-called requirements.
So these other things aren’t “requirements” at all.
They’re ideas, and some of them are not very
The client wants to know how long something is
going to take, and how much it will cost at the
But how can we say how long it will take if he does
not know what he wants?
Then we come to a situation where a development
contract is based on an unrealistic list of
requirements, using weak estimates, made at the
moment of maximum ignorance, by people who are
always optimistic about their own abilities.
It’s all right, though.
We’ll just keep the pressure on, and it’ll be ﬁne.
The project is planned for months / years until it’s
perfectly describing all the functionality.
The development is painfully pushed through, with
numerous bugﬁxing, until ﬁnally delivered.
And the ﬁnal launch day comes…
“Agile software development is a group of software
development methods based on iterative and
incremental development where requirements and
solutions evolve through collaboration between self-
organising, cross-functional teams. ”
Or whatever else we call it..
“a group of software development methods”
iterative development - code vs feedback. keep iterating until it’s
incremental development - build what is needed right now then reﬁne
“based on iterative and incremental
requirements evolve - I will tell what I need when I see it
solutions evolve - minimum ﬁt to requirements then reﬁne
“requirements and solutions evolve”
collaboration - plan together, share work
self-organising team - common pool of work
cross-functional team - everyone can do everything
“collaboration between self-organising,
It is not exactly brain surgery, is it?
single location & teamwork
single tool for managing process
Individuals and interactions over Processes
working demos - don’t break it if you make it
documented parts - parts that will be done must be speciﬁc
Continuous Delivery and Continuous Integration are essential for
the success of the project.
Working software over Comprehensive
project owner requirements - user stores
ﬂexible outcome - customer gets what he asked for
ﬂexible contract - deﬁned in increments
Customer collaboration over Contract
respond - yes, I heard the customer
react - yes, I will change it
plans help - manage chaos
Responding to change over Following a plan