Date post: | 18-Jul-2015 |
Category: |
Software |
Upload: | laurynas-antanavicius |
View: | 76 times |
Download: | 0 times |
ABOUT US• 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,
France…
OUR TEAM
• 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
http://www.theonion.com/video/hp-on-that-cloud-thing-that-everyone-else-is-talki,28789/
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
good.
The client wants to know how long something is going to take, and how much it will cost at the
beginning.
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.
The project is planned for months / years until it’s perfectly describing all the functionality.
The development is painfully pushed through, with numerous bugfixing, until finally delivered.
And the final 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. ”
iterative development - code vs feedback. keep iterating until it’s done
incremental development - build what is needed right now then refine
“based on iterative and incremental development”
requirements evolve - I will tell what I need when I see itsolutions evolve - minimum fit to requirements then refine
“requirements and solutions evolve”
collaboration - plan together, share workself-organising team - common pool of work
cross-functional team - everyone can do everything
“collaboration between self-organising, cross-functional teams”
single location & teamworksingle tool for managing process
Individuals and interactions over Processes and tools
working demos - don’t break it if you make itdocumented parts - parts that will be done must be specific
Continuous Delivery and Continuous Integration are essential for the success of the project.
Working software over Comprehensive documentation
project owner requirements - user storesflexible outcome - customer gets what he asked for
flexible contract - defined in increments
Customer collaboration over Contract negotiation
respond - yes, I heard the customerreact - yes, I will change itplans help - manage chaos
Responding to change over Following a plan
Developers are supposed to choose an amount of work on and forecast what can be
accomplished in that time.
Defects should not be piled up, but cleaned periodically.
If you wait for a release until the end of the project, you’re gonna have a bad time.
It’s less stress for you as a developer and as a team member
More comitment to work as you choose it yourself
Immediate results for you and the client
Read about Agile, understand it, memorise it, sleep with it…
Until you are 100% confident with using Agile methods
XP
“Extreme Programming”byRon Jeffries,Ann Anderson,Chet Hendrickson
http://xprogramming.com/
AGILE
“Agile Manifesto”byAgile Alliance
http://agilemanifesto.org/iso/lt/
SCRUM
“Scrum Guide”byJeff Sutherland,Ken Schwaber
http://www.scrumguides.org/