CS312 - Spring 2012 - Class 12
administration
- midterms
- assignment 3 grades e-mailed
- assignment 4 grades back soon
- assignment 5 grades semi-soon
project management
- so far, much of what we have focused on in this class (and in your college career) has been focused on the individual skill sets
- this is important for you as an individual
- however, an important part of any project is deciding:
- the steps that will be taken for the project to evolve
- how people will interact with eachother
- how you'll do QA/testing
- project management, deals with the group/project level and looks at techniques/approaches for managing the a project over its lifetime
project lifecycle: describe the steps/your process when you work on a project. Be realistic.
traditional project planning
- followed a number of steps
- requirement gathering, specifications, etc.
- planning and design
- implementation, testing and documentation
- deployment and maintenance
- sometimes called the "waterfall" method
- sequential set of steps
- once you moved on the the next step you were not supposed to revisit the previous steps
- having a process in place
- helped everyone understand what they were supposed to be doing
- created a concrete specification
- reduced uncertainty
- tried to avoid missteps
- the challenges were:
- each of these steps took weeks or months
- took a long time for a release
- in particular, planning and design was an important and time-consuming step
- but specifications change and then a lot of the time spent on design was lost
agile project development
- agile manifesto:
http://agilemanifesto.org/
- key ideas
- early and regular customer involvement
- short, iterative development cycles
- adaptive
- regularly produce working software
why is agile better?
- many surveys and studies
-
http://www.researchandmarkets.com/reports/660321/how_agile_projects_measure_up_and_what_this.pdf
-
http://davidfrico.com/rico08b.pdf
- more productive: faster development and shorter time-to-market
- employees are happier
- tends to fit better with what software developers want to naturally do
- salesforce.com
- before agile: 40% "good time" at work
- after agile: 86% "good time" at work
- 92% said they would recommend
- many other examples
- more flexible/adaptable to changes
- more adaptable
- tends to mesh better with what software developers want to do
many variations on agile project management
- agile is a high-level theme, the techniques below are particular instantiations
- extreme programming (XP)
- scrum
- feature driven development
we're going to use scrum for our projects
scrum basics
key players
- customer
- product manager
- helps define user stories (i.e. functionality)
- prioritizes user stories/functionality
- software developers
- scrum master
- manages the scrum process
- may or may not be part of the software developers
sprints: project is broken into fixed time chunks called sprints
- a sprint is generally between 1-4 weeks, though they can be shorter
- we'll use ~2 week sprints for our projects
- a sprint is a self-contained project cycle
- a sprint consists of the following key parts:
- sprint planning: plan what will be accomplished during the spring
- sprint stand-up meetings
- meet for 15 minutes everyday (in our case 3 times a week)
- each person should discuss
- what they accomplished since the last meeting
- anything "blocking" them, i.e. keeping them from moving forward on their task
- used to setup follow-up meetings for longer issues
- sprint demo: a demo of the features that were accomplished during the sprint
- a sprint is a self-contained cycle so each sprint should see a new release
- can only demo completed tasks
- sprint retrospective
- what went well
- what didn't go well
- consider possible changes to the process
user stories
- one of the key differences between agile methods and traditional methods are user stories
- A user story is a short, simple description of a feature told from the perspective of the customer
- Often it is written in something along the lines of:
As a <type of user>, I want <something> so that <why I want it>
- for example:
- As a customer I want the website to have a card feature so that I can store the things I plan on buying.
- As a shipping manager I want to be able to print all address labels so that I can attach them to all outgoing packages.
- As a system administrator I want a error log of all of the website issues e-mailed daily so that I can review it for major issues.
- User stories can (and should) have more information, but shouldn't be too bogged down with detail
- If you need more detail, talk to the person who created the user story (or who it's for)
- User stories should be lightweight and shouldn't take too long to create
- in particular, this is not a full design!
- User stories can (and should) change over time
backlog
- user stories define the features that we want to implement for our product
- the backlog is where the user stories are managed and stored
- the backlog:
- consists of a prioritized list of user stories
- things with higher priority should be accomplished first by the team
- the priorities are generally managed by the product manager
- the user stories will contain a difficulty score
- the team determines this score based on their best guess
- many ways of scoring a user story
- time (e.g. hours, days, weeks to complete)
- scale 1-5
- scale 1-?
- the backlog is used to decide what tasks will be tackled next during sprint planning
- the backlog will change over time
- the priority will change
- more user stories will get added
life of a sprint revisited
- before the sprint
- the product manager (and others) populate the backlog with user stories
- the product manager prioritizes the backlog
- the team assigns scores to the user stories
- sprint planning
- based on prior experience (this gets better over time) the team commits to some user stories
- as a team, they are committed to finishing these items by the end of the sprint
- initial assignment of who will be working on what
- this is only an initial assignment and people will (and should) move around as the sprint moves along
- this will likely not cover all of the items in the sprint. When a user story is finished, then that person/group can start working on the next item on the list
- sprint stand-up meetings
- progress/blockers on your particular user story
- should generally be done "standing up" to avoid meeting lasting too long
- demo
- at the end of the sprint show off what has been accomplished!
- anyone can attend, including people outside the team
- sprint retrospective
- were all the tasks completed?
- if not, why not?
- changes for next time?
teamwork: although individuals and pairs often work on particular user stories, the team as a whole is committed to completing the sprint on time
completion
- completing a user story does NOT just mean finishing coding
- it means
- feature is finished
- unit tests are written and all pass
- someone (often the creator of the user story) signs off that the task is complete
project idea voting
e-mail me your preferences
scrum video:
http://www.youtube.com/watch?annotation_id=annotation_650246&src_vid=Q5k7a9YEoUI&feature=iv&v=XU0llRltyFM
project overview
TODO before next class
- meet as a group
- flush out the scope of the project a bit
- create a backlog with user stories
- do this in some tangible/editable media so that you have record of it over time
- remember, they should be specific but not too detailed
- you're going to need enough things to get your team started for at least 2 weeks
- the more effort/thought you put into this now, the better off you'll be down the road