SWEN 302: AGILE METHODS Roma Klapaukh & Alex Potanin.
-
Upload
neil-gilmore -
Category
Documents
-
view
215 -
download
1
Transcript of SWEN 302: AGILE METHODS Roma Klapaukh & Alex Potanin.
SETTING UP
• Backlog – this is a list of user stories. These can be pretty course grained.
• Roles / personas – you want a clear idea of who you are targeting
SCRUM BOARD
• Scrum boards vary – but the general idea is:
• Other possible columns include: blocked, testing
Backlog To Do In Progress Done
BUT WHAT GOES ON IT?
• User stories• These should be coarse grained if they are a long way away• Fine grained if they are coming up
• Tasks• These may occur when you are breaking down a specific story to actually do
• Spikes• Uncommon and short• Don’t provide clear value to the client (e.g. research)
A CLOSER LOOK
• Front: As a <persona>, I want to <do> [so that <bacon>]
• Back: Acceptance test – how do I know I did it?
• In contrast a task is more: do X (still need a test [is possible])
• Though it is nice to avoid tasks where possible
• Spikes are for anomalous odd things that need doing
• E.g. Go read about Ruby and Python and then report back
SIZING
• Everything accessible should be sized (things on the tail of the backlog don’t need to be)
• The size reflects how long it will take to complete
• Can be very precise (e.g. hours, story points) or vague (e.g. S/M/L)
• Common Schemes:• T-Shirts• Fibonacci
HOW TO SIZE
• There’s an app for that…
• Everyone just picks a value and the team works it out
• Everyone must reveal their choice at exactly the same time (why?)
• If everyone agrees good. Otherwise highest and lowest value explain their choice and you get to discuss it. Repeat until you all agree.
SIZING FOR THE FIRST TIME
• Sizing can be hard to start with. So the sensible technique for picking some baseline values is:
• Find the smallest looking job you have in your entire list
• Assign it a size (probably the second smallest size if you have a wide range)
• Rate everything else in comparison
BACKLOG GROOMING
• Need to prioritise the stories
• Break up and size stories near the top – note that size can impact priority
• Add anything that has come up
• Ensure that stories have acceptance tests
MOVING INTO TODO - SCRUM
• Choose what you will do in advance
• Break up your time into fixed length sprints
• Have a fixed number of sizing units you can do per sprint (determined by experience)
MOVING INTO TODO - KANBAN
• Choose a maximum number of tasks to do simultaneously
• Make sure that you have more than enough work properly ranked
• When you need more work – move more into in progress from the backlog
PLANNING
• Planning is key
• Plan for testing!
• Plan only what you need to – don’t plan things you aren’t up to
RESPONSIBILITY• Own your work
• You can ask for help
• If you find bugs fix them
• Refactor when you need to, as you go
• Work is assigned to specific people – Write your name on the task when you do it
MEETINGS
• Scrum has a set of meeting that are common
• Team stand up
• Sprint review
• Sprint planning
SPRINT PLANNING
• This is essentially just deciding with the product owner what you will do this sprint
• Work doesn’t get changed within a sprint – once you commit you finish it
TEAM STANDUP
• Done standing (why?) and 15 minutes long
• All members day• What I did yesterday• What I will do today• What problems do I see that will prevent us doing what we set out to do
• No detail discussion. Problems can be added to the board and someone can be assigned to look at them
SPRINT REVIEW / RETROSPECTIVE
• Review• What did we accomplish?• What did we not finish?• Demonstrate the completed work to the client
• Retrospective• What went well?• What could be improved?
• A very short version of this is what you write about in your weekly reports