XP and Agile Flashcards
1
Q
Why is Agile’s constant review process useful?
A
it’s more likely to produce a requirements analysis that is accurate to the customers desires
2
Q
What is the Agile approach?
A
Put emphasis on the production of the code as opposed to creating vast amounts of documentation.
3
Q
What are the 4 core values of the agile manifesto?
A
- Individuals and interactions over processes and tools
- People and their interactions drive success more than the strict of tools/adherence to processes. - Working software over comprehensive documentation
- Delivering functional software more valuable than producing extensive documentation that may not be directly useful. - Customer collaboration over contract negotiation
- Engaging with customers and responding to their needs is prioritised over sticking rigidly to initial agreements. - Responding to change over following a plan
- Adapting to changes, even late in the development process, is more important than adhering to a fixed plan.
4
Q
What is XP?
A
Extreme programming (XP) is an Agile development approach that focuses on code development
5
Q
What are the core features of XP?
A
- Requirements are expressed as ‘user stories’
- pair programming (programmers work in pairs)
- Tests are developed before code is written (test driven development)
- all tests must be successfully executed before code is released
- new code is then integrated and a new system release is built
- the new release becomes the working system
- Then you start this process again for each user story
6
Q
What are the features of requirements analysis when using an Agile approach?
A
- User requirements are defined by user stories.
- User stories have to be independent, small, estimatable, testable and valuable to the customer.
- Independence means the stories can be developed in parallel.
- Small user stories means that progress can be measured more easily.
- Testable means that quality can be assured objectively.
7
Q
What are user stories?
A
short descriptions of program functionality which allows the user to ‘do something’
8
Q
What features should user stories have?
A
- Independent (should be implementable without reliance on other user stories, in practice this is difficult)
- Negotiable (Not all requirements written in original spec. always needs to be developed)
- Valuable (to the customer)
- Estimable (should be relatively easy to estimate them)
- Testable (in an objective fashion)
- Small ()
9
Q
What are the advantages of user stories being independent:
A
- Low coupling
- Allows for concurrent development
- Scalable development (adding more developers)
10
Q
What are the advantages of user stories being negotiable:
A
- By negotiating, a stakeholder may get
- Software at a cheaper price
- A useful working product developed on time
- Removing/changing aspects of story to make it easier quicker to implement
- Add/change functionality to make it more useful
- Something may be very difficult to implement but not very important
11
Q
Why do user stories have to be valuable and how is this useful?
A
- Each user story needs to show value to the stakeholder, the value is visible to the customer
- It’s worth putting a metric on value
- if you give a value between 1-10 to each user story, it’s easy to decide which order to develop in.
- core essential story points can get a 10. If you run out of time, the most valuable user-stories will be completed. The value for each user story will be dependent on the customer.
12
Q
What are the advantages of user stories being estimable
A
- Useful for scheduling
- Shorter user stories are easier to estimate
- User stories with less unknown code are easier to estimate (use popular APIs)
- User stories understood clearly by developer are easier to estimate
- Big user stories can be split to make this easier
13
Q
What does agile use generally for estimation?
A
- Generally use poker planning to do estimation.
14
Q
Why do user stories have to be small?
A
- Smaller modules are easier to estimate duration
- Reduces the risk
- Gives clear measure of progress
- Keep code simpler and easier to test
14
Q
Why do user stories have to be testable?
A
Makes testing easier, as testing is not subjective but is quantifiable
- The login screen must look nice and be liked by most of the users
- hard to test whether this has been achieved as like is “subjective”
- The login screen must look nice and must score greater than 7/10 when we assess the screen using a random group of 20 patients
- Easier, as this is a quantifiable number and it’s objective if we’ve achieved this.
15
Q
What are story points?
A
- Each user story has a defined size, measured in story points
- they help to estimate the size of user story in development time
16
Q
Why are story points useful?
A
- They provide a relative estimation time (we can relatively measure a task by comparing it to other tasks)
- For a given team
- Using a particular programming environment
- Can be estimated using planning poker approach
- This is useful for whole project estimations
example: A user story of 10 points should take on average twice the time of one measured as 5 points but
- With the same level of developer
- Given the same conditions
- Given no dependency issues
17
Q
What is the format for user story?
Give an example of a user story:
A
Uses format of “As a [user] i want to be able to [action] so i can [reason]”
- As a [registered patient] of the system I want to be able to [login] into the system. So I can [access my records]
18
Q
What are criticisms of user stories?
A
- Generally capture functional instead (not non-functional requirements)
- They are too vague for a basis of contract
- Only suitable for highly experienced developers
- Size estimation ignores non functional requirements
19
Q
Describe the agile XP planning process:
A
1) User stories are written by customers and developers
2) User stories are estimated by developers
3) User stories are prioritised
4) Project plan: When features be delivered and how often the project be iterated.
20
Q
What is the XP agile development hierarchy?
A
- small user stories with high priority
- large user stories with high priority
- small user stories with low priority
- large user stories with low priority
21
Q
What are the features of XP planning and testing?
A
- all high priority code needs testing properly before development of low priority code starts
- only code that has been fully tested is complete
22
Q
What are the features of XP development?
A
- In each iteration a working copy of the code is developed for evaluation.
- software is released on a regular schedule (weekly, fortnightly)
- unit tests are developed by the development team
- acceptance tests, specified by the customer, can be script (user input, acceptable output), ideally automated
23
Q
What are the issues with Agile development?
A
- feature creep can arise
- less documentation, meaning high communications overhead and more assumptions, more design contradictions
- onsight customers might want to keep adding functionality
- high risk of time or cost overrun
24
What is pair programming?
- two programmers work together to complete a programming task
- one programmer writes the code aka the driver
- one programmer reviews the code aka the reviewer
- the reviewer makes suggestions and comments on the approach
- the two programmers swap roles regularly
25
What are the benefits of pair programming?
- reduces chance of driver writing poorly commented or low quality code, as the reviewer will catch with and ask for it to be corrected
- reduces risk as errors are less likely to pass unnoticed by two programmers over one
- increases collective code ownership, as responsibility is spread between both programmers. If one is off sick the other can continue development
26
What is the bus factor?
- the smallest amount of people who can be run over by a bus before it stops
- the minimal amount of people that are needed to develop code. E.g.
- 1 developer run over by a bus will halt project = bus factor of 1, 2 = bus factor of 2
27
How can the bus factor be improved?
- By improving collective code ownership
28
What are some methods for widening code ownership?
- improve code documentation: helps as more people can understand the project
- improve class design: helps if people understand the class you inherit from
- reduce class size: single responsibility, less code to understand
- use code reviewing in your development team
29
What is mentor pair programming?
- a lead programmer aka the mentor, solves a problem in the company's problem domain
- a trainee programmer learns company practices (i.e. coding standards, company APIs, and other issues of problem domain)
30
What are 3 issues with pair programming?
1) problem with skills matching: two inexperienced programmers may not make much progress, one low and one high skilled programmer: low skill may frustrate the high skill, or high skill make low skill feel inadequate. Two high skills egos may clash
2) there's not substitute for code review, both developers need to be available
3) eating habits, bad breath, interruptions
31
Give a summary of Agile:
- Designed to reduce risk and be a realistic approach
- various parts of agile are used in practice
32
What does the research on pair programming show:
It's inconclusive as to whether pair programming is beneficial
33
What are the two case studies about pair programming:
- University of Utah: Williams et al. 2000
- Arisholm, Gallis and Sjøberg
34
What does the Williams et al. 2000 study show about pair programming?
- using pair programming there was a decrease in development time between 15-30%
- but this required an increase in programmer effort (hours) between 15-60%
- correctness of code increased by 15%
35
What does the Arisholm, Gallis and Sjøberg study show about pair programming?
- looked into pair programming effectiveness in different contexts of simple to complex project difficulties
- on average project duration was only decreased by 8%
- if juniors were paired together time and effort increased a lot, however there was an increase in correctness by 7% for 73% of the juniors
36
Describe the SCRUM development approach?
- A lightweight approach, that involves working together/in a team to complete a task, doing the development in a series of steps called sprints
- focuses on managing the workflow
- an iterative (not sequential approach). Each iteration moves towards the goal of producing the final product
37
What are the SCRUM team roles?
- product owner: liaises with stakeholders
- developers: develop the code
- SCRUM master: enables day to day SCRUM practise (not a people/project manager)
- the team is self organising
38
Describe the SCRUM process or lifecycle:
Development split into a series of efforts called sprints. Each sprint lasts 1-4 weeks and is preceded by a sprint planning meeting.
- At the start of the project and as the project moves forward, the total work needed to complete the project is contained within a document called the product backlog.
- As tasks are completed they are removed from the product backlog. This can include anything from product features to debugging tasks and technical tasks.
- Each task in the product backlog has a description/specification as well as a score in terms of its business value. Each task in the backlog is also given an estimate by the development team in terms of the effort required to complete it.
39
What do sprints consist of?
Development work or other related work that goes towards finishing the product
40
What is the sprint backlog?
- typically defined in user stories
- this is work that needs to be completed within the sprint
- requirements that haven't been implemented
41
When and only when can something be removed from the sprint backlog?
When it's been developed and FULLY tested
42
What happens if a part of the sprint backlog needs more development?
It's pushed back into the product backlog
43
What are the 4 parts of the SCRUM process?
- product backlog
- sprint backlog
- sprint
- working increment of software
44
What is the daily SCRUM?
- short meeting (usually 15 minutes) at the start of the day where developers answer questions
- person speaking should stand up to discourage them from talking too long
- What have you done since yesterday?
- What are you planning to do today?
- Any impediments/stumbling blocks?
45
What is a the product backlog?
- Shows what work is outstanding for the project as a whole
- describes of all the features required and which features are prioritised
- Each item/feature in the product backlog is time/cost estimated
- This can be trimmed back/have features removed, and priorities of tasks can be changed.
46
What is sprint planning?
during this meeting:
- what work will be done is decided
- the customer prioritises work from the work backlog and reviews current work backlog (may decide to drop/add features)
- what goes into the new sprint backlog is decided
- try to select work so that it fills the duration of the sprint
47
What happens to work that is not completed at the end of a sprint?
- it's places back into the product backlog
48
What estimation technique is used by SCRUM?
- Poker planning also know as scrum poker estimation
- developers have to explain why their estimate is the lowest or highest
- reduces anchoring
49
What is the sprint backlog
- All tasks to be worked on in the current sprint
- each task should be doable in a short length of time (4-16 hours)
- developers sign up for tasks
- tasks are removed from the sprint backlog when completed
50
Describe what takes place in a sprint:
- iteration of 1-4 weeks, where coding/implementation of sprint backlog takes place
- Produces a user testable version of the product
- if you reach end of sprint and there's outstanding tasks, these are returned to the product backlog
51
Why don't you want to have too short of duration sprints?
sprints require admin/overhead of sprint planning before every sprint, so you don't want to have to do this too often if unnecessary
52
How is progress measured for the SCRUM process?
Using a SCURM burn down chart
- this gives a clear indication of how much has been completed.
53
Describe a burn down chart:
- every time a task is completed, the number of hours of the allocated amount of time is taken off
- the remaining effort line may go up, if bugs are discovered that need to be fixed or there's scope creep, or down
- if you still have remaining tasks after the deadline, it indicated you need to put less in your sprint
54
What is a release burn down chart?
- points are created from the size of the backlog
- tells you how much is left in the product backlog (not sprint backlog)
- axis is from first to last iteration (so until there's nothing left in the product backlog
- At any point you can decide there's a release product to pass to QA for beta testing.
55
Describe SCRUM review meetings:
- take place at the end of sprint
- review what was completed
- a demonstration of the product
- review of product backlog
56
What is the job of the scrum master?
- they build up release plan, so contents of sprint backlog
- in scrum meetings they deal with obstacles expressed by developers
- communicate between team and management
