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
design stamina hypothesis
- 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
Scrum team
- 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
Product owner
- 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
Scrum master
- 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
Scrum iteration
- lasts 2-4 weeks
- sprint backglog
- sprint goal
30
sprint goal
- 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
sprint backlog
- 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
Sprints
- 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
product backlog
- 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
sprint planning
- 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
Estimation
- 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
Daily Scrum
- 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
Daily Scrum Question
1. what did you do since the last Scrum?
2. What are you doing until the next Scrum?
3. 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
Sprint review meeting
- 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
Sprint retrospective
- 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
