Agile & Scrum Flashcards
1
Q
motivations and general info
Agile overview
A
- motivation: waterfall problems
- goes one way
- extreme programming
- tries to avoid problems from waterfall model for small projects
- more effective to change strategy in small teams
- idea is to spend more time developing project than documenting what to do
- have a customer representative to communicate with customer
2
Q
Agile risks
A
- relies heavily on accurate assessment of requirements from the very start
- customers only see product at end of life-cycle, little or no interaction or feedback earlier on
- problems found later on are much harder to correct
3
Q
Agile manifesto
A
- individuals and interactions over processes and tool
- working software over comprehensive documents
- customer collaboration over contract negotiation
- responding to change over following a plan
4
Q
Heavy weight disciplined Model
A
- their focuses are detailed documentation, inclusive planning, and extroverted design.
- starting point -> planned result
5
Q
Adaptive, lightweight Agile processes
A
- since project is small, team who built is able to estimate how long it will take to build
- work in collaboration
6
Q
agile development
A
- be able to predict what end result will be
- know what to build so team has a collection of features
7
Q
Extreme programming (XP)
A
- based on ideas and methods from late 1980s
- published in 1999 by Kent Beck
- doesn’t adhere to any particular language but generally more suited to OOP
- no BDUF - big design up front
- design is emergent
- basic principle - keep it simple
- extra functionality is discouraged
- if story takes longer than 3 weeks to develop, customer is asked to split story into smaller stories and cost and value are assigned again
- don’t want to spend too much time on each story
- make us of iterative models to estimate time taken on each story
8
Q
XP in a nutshell
A
- break down program into stories
- customer can look at cards tell you if anything is important/unimportant
- feedback is not for long-run, rather for what to do next
- assign priorities or value to card and developers assign a cost
- write tasks before code
- until you have implemented code, you won’t know what interface you have
- tasks before code is difficult for large
- tests are supposed to be testing everything
- work instead of documentation
- devs write code to test the features
9
Q
Pair programming
A
- most developers are expected to work on their own
- two people working, one person has role of navigation other of driver
- driver implements, focusing on the tactical
- navigator is more objective (strategic), asks why and provides explanation
- one person looks at the details, one person looks at the big picture
- both programmers in pair are familiar with code by either directly writing or watching the code generation
- knowledge transfer amongst pair is advantageous
- code review - another person on team reviews code
10
Q
Refactoring
A
- any change to a computer program’s code which improves its readability or simplifies its structure without changing its results
- changing structure - not behaviour
- can accelerate adding features
- polish existing code to make better
- improve or change design, architecture, efficiency, quality, not functionality
11
Q
Continuous integration
A
- when devs go to release new code, they run all the unit tests not just theirs on the integration machine
- tests must run at 100%
- when a test fails the problem must have been caused by the last change
- reason: developers know the tests are ran at 100% the last time anything was released
- devs dont work in isolation
- careful not to break others’ code
12
Q
XP testing
A
- implementation of unit tests should be such that they can be automated
- as soon as code is modified it can be tested
- integration and validation of the system can occur on a daily basis using inversal test suite
- a continual indication of progress
- acceptance tests are specified by customers to test features and functionality
13
Q
Acceptance Tests
A
- test cases “extracted from” customer
- test system end-to-end
- tells customer and devs if system has the features its supposed to have
- don’t have to run at 100%
- progress used to measure project velocity - what % of the customer’s acceptance test cases run? - way to gauge progress
14
Q
XP 12 practices
A
- the planning game
- small releases
- metaphor
- simple design
- testing
- refactoring
- pair programming
- collective ownership
- continuous integration
- 40 hour week
- on-site customer
- coding standards
15
Q
The planning game
A
- use stories to facilitate knowledge transfer
- put decisions in the hands of the person
- business decisions -> customer
- software decisions -> developer
- plan only as far as your knowledge allows - next iteration or next release
16
Q
small releases
A
- supports quick feedback from users
- simplify the tracking of metrics
- stories per iteration -> project velocity
- increase the manageability of the project for the customer
- don’t have to plan too far ahead
17
Q
Metaphor
A
- ground all discussions in a single shared story of how the whole system works
- provide an overarching view of the project
- connect program to work process
18
Q
Simple design
A
- design embodies only the needed complexities and no more
- simpler designs are easier to modify, maintain and describe
- they decrease the cost of design changes, but give no notion of product line architecture
19
Q
Collective ownership
A
- code belongs to the project, not individual engineer
- anyone can change any code anywhere and no personal ownership of modules
- everyone is permitted access to all the code so everyone has a stake in knowing all of the code
- they are responsible for keeping all the unit tests running (and writing new ones for new functionality) “You break it, you fix it”
- requires deserved trust
20
Q
contiuous integration
A
- the system always words
- there is always something to be released
- similar to rapid releases
- fast feedback to developers on problems
- no “big bang” integration disaster
21
Q
40 hour week
A
- knowledge can only be transferred at a limited rate
- work for sustained speed, not a single sprint
- burning the midnight oil kills performance
- if you mess with people’s personal lives (by taking it over), in the long run the project will pay the consequences
22
Q
on-site customer
A
- a real, live user available full-time to answer questions as they occur
- programmers don’t know everything
- business knowledge is the key to a successful business project
23
Q
coding standards
A
- communication occurs through the code
- common standard promotes understanding of devs’ code
- helps promote team focus
24
Q
What is good software
A
- pleasant user interface - visible to users and customers
- few defects - visible to users and customers
- good design - developments side, how much time it will take to add/modify new features
- goals of software design - decompose system into components (architecture), determine relationship between components (dependencies)
- determine inter component communication mechanisms
- specify component interfaces
25
Q
design stamina hypothesis
A
- by having a design you allow yourself to have more functionality without extra cost
- design might be obsolete by time it is time to add new feature
26
Q
Scrum team
A
- typically 5-9 people
- cross functional - QA, programmers, UI designers, etc.
- team is self-organising
- implicit boundaries of how big groups should be -> not too large
27
Q
Product owner
A
- typically a product manager
- can be developer
- define the features of the product
- decide on release date and content
- responsible for the profitability of the product (ROI, return of investment)
- prioritise features according to market value
- adjust features and priority every iteration, as needed
- accept or reject work results
28
Q
Scrum master
A
- represents management to the project
- responsible for enacting Scrum values and practices
- removes impediments
- ensure that the team is fully functional and productive
- enable close cooperation across all roles and functions
- shield the team from external interferences
29
Q
Scrum iteration
A
- lasts 2-4 weeks
- sprint backglog
- sprint goal
30
Q
sprint goal
A
- important features to implement in particular sprint
- a short statement of what the work will be focused on during the sprint
- expressed in business terms
31
Q
sprint backlog
A
- takes features and turn into tasks
- discuss what is done that day and the next
- task shouldn’t be very long -> in reality don’t know how long it takes, hard to prioritise, break down into multiple small stories
- “technically complex” -> risk involved
- no more than 300 tasks in the list
- if task needs more than 16 hours -> break down
- team can add or subtract items from the list - product owner is not allowed to do it
32
Q
Sprints
A
- scrum projects make progress in a series of “sprints”
- typical duration is 2-4 weeks or a calendar month at most
- constant duration leads to better rhythm
- product is designed, coded and tested during the sprint
- plan according to how much time you have - ie, with sprint backlog spreadsheet/table
33
Q
product backlog
A
- features/functionality that are going to be implemented
- whole collection of features -> owner knows what to implement
- requirements for a system expressed as a prioritised list of backlog items
- is managed and owned by product owner - plans what happens for the iteration
- ie, spreadsheet to map tasks/features
- workers might decide to change plans themselves later
34
Q
sprint planning
A
- team selects item from product backlog they can commit to completing
- sprint backlog is created
- tasks are identified and each is estimated (1-16 hours)
- collaboratively, not done alone by the ScrumMaster
- framework to allow testing your application, can add new features if code runs
35
Q
Estimation
A
- establishes team’s velocity (how much effort a team can handle in one sprint)
- initially slow, since devs might be slow due to language working with new people
- determining units of complexity,
36
Q
Daily Scrum
A
- short 15 minute meeting held everyday before team starts working: stand up
- participants: scrum master (chairman) scrum team
- every team member should answer 3 questions
37
Q
Daily Scrum Question
A
- what did you do since the last Scrum?
- What are you doing until the next Scrum?
- What is stopping you getting on with the work - these are not status for the scrum master, they are commitments in front of peers
38
Q
Sprint review meeting
A
- is held at the end of each sprint
- business functionality which was created during the sprint is demonstrated to the product owner
- informal, should not distract team members of doing their work; no slides; 2 hour prep rule
- whole team participates
- ## invite the world
39
Q
Sprint retrospective
A
- periodically take a look at what is and is not working
- is there something systematically wrong with sprints?
- if there is something that needs changing now is the time to decide
- typically 15-30 minutes
- done after every sprint
- whole team participates
