Agile development Flashcards
what is agile SW development
put software being developed first
acknowledge that use requirements change
respond to changing needs quickly
advocates for regular software releases - users respond to these releases
Agile manifesto key points
individuals and interactions over process and tools
working software over hella documentation
customer collaboration over contract negotiation
responding to change vs following a plan
12 agile principles
satisfy the customer give workers the support they need and trust them technical excellence welcome changing requirements face=to=face conversation simplicity self-organizing teams working software deliver frequently business peolpe and devs work together maintain constant pace reflect on how to be more effective and adjust behavior
Explain the 80/20 rule (Pareto’s Law)
80% of results come from 20% of your effor and focus on the important 20%
how to deal with requirements in agile
capture requirements at a high level and on a piecemeal basis
- just in time for each feature to be developed
-the minimum to enable development and testing
understand enough to determine the scope and for high level budget estimates
captured in collaborative workshops so taht all team members understand the requirements - allows everyone to contribute
what are user stories
represent each user requirement as a user story
- more light weight and simpler than use cases
simple statement about what the user wants to do with a feature
business language and understandable to everyone
form of user stories
As a (user role)
I want to (goal)
so i can (reason)
focus on who what and why NOT HOW
How long should requirements (tasks) take
less than 16 hours
preferably 8 hours so progress can be measured daily
three basic steps in agile life cycle
analyse
develop
test
benefits of agile approach
reduced risk
increased value
more flexibility
better cost management
What does DONE mean in agile
shippable
- unit tests passed
- code reviewed
- acceptance criteria passed
- non-functional requirements met
- functional tests passed
- product owner accepts user story
two main classes of prototypes
true prototype - test implementation to understand a problem before it is implemented for real
tracer bullets - intended to gradually turn into the final solution
continuous integration
continuously integrate changes - ensure that modules will fit together - product continues to work with all the changes
ensure that problems or regressions are caught early on
nightly builds
software should be rebuilt from scratch daily
and the result of the build should be an installable product image
build should include as many automated tests as possible to catch integration problems early
- if tests/build fail - fix first thing
- dont let anyone integrate changes after build succeeds again
- risk of bad changes accumulating
what is pair programming
programmers work in pairs, sit together to write every line of code - 2 coders and 1 computer - 1 person at keyboard and one suporting - pairs created dynamically egoless development