Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

com1001 > Agile & Scrum > Flashcards

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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Heavy weight disciplined Model

A
  • their focuses are detailed documentation, inclusive planning, and extroverted design.
  • starting point -> planned result
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
  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
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

com1001 (5 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions