Please add your notes here.
As a (role) I want (something) so that (benefit).
I took a lot of notes. I'm too lazy to integrate them with what's here. If someone else would do that, that would be great. I figure it's better to have this dump of info at the bottom of the page than a dearth of info. If a lot of people feel otherwise, you can delete my stuff.
agile development with pivotal labs
prioritized backlog - client writes user-oriented story of what web app will do - client prioritizes these stories/features - client understands that lower priorities will come like 2 months later - pivotal gives time estimates for different priority levels - features are always end-to-end involving back end and user - all programmers share this priority list. when one finishes a task, h/she grabs the next one on the list. - identify a “product owner” role. this person manages the priorities. ex for consulting the client, for Microsoft the PM. then others execute the priorities.
release planning - inception: all stakeholders (devs, designers, UI, everyone) discuss users and needs and how users will accomplish their needs. this creates prioritized backlog. plan about 2-3 months in advance; any more and things will have changed. set expectations with client of what can be accomplished in this time period.
iteration planning - break 2-3 months down into 1-week “sprints” aka “iterations” - each week discuss specs (“acceptance criteria”) for the story you're working on. have discussion for each week at beginning of week, then you can work independently that whole week. defer detail planning as late as possible to avoid wasted time planning details and then having things change. - 15 minute daily stand up meeting (all standing to make things go quickly). share what you did yesterday with group, what you will do today, and any roadblocks you need cleared from devs or others. - works best on ⇐ 10 people teams. amazon coined “2 pizza” team size rule. 4 devs, a PM, a visual designer, and UX (user experience) person.
retrospectives - every 2-3 weeks whole team (dev, designer, UI, UX, client, PM) has open meeting to talk about what's working and what's not - don't introduce hierarchy in this, everyone has equal voice
www.pivotaltracker.com - tool for managing backlog - devs can have a hard time estimating how much time something will take. comparing it to other tasks (ex. that's twice as hard as what i did yesterday). 0,1,2,4,8 where 0 is five minutes, 1 is twice as hard as 0, 2 is twice as hard as 1, etc… estimate for everything you do, use historical averages to get estimates of how long new tasks will take. make each week about 8 worth of work. - using actual time estimates tends to make harsher deadlines (ex. exactly an hour) - groups estimate times together. if they have very different estimates, they can discuss. - transparent tracking of
- story format: As a _ (user) I should (be able to) (functionality) so that _ (value)
- shorten feedback loop so you don't waste time doing something that isn't right.
- you aren't going to need it. do the simplest thing for what you want right now (the current task on backlog), don't worry about dependent tasks that are much lower priority because you might never end up doing those (might be abandoned).
pair programming - two devs at a single machine on a single problem collaboratively - continuous code review (catch typos, checking all cases) - prevents distraction (text messages, facebook for a second) - prevents boredom by switching off who types - they estimate that the pair is more productive than two people working individually - promotes communication so there's no redundant work done - switch pairs every day - collective code ownership. not “i wrote this, this part is mine, you wrote that bug” - every coder feels comfortable with every piece of code - no “oh he's on vacation need to wait till he returns to fix his bug” - prevents feeling burnt out and socially isolated - all sitting at big tables in a big open room
test driven development - red, green, refactor process. first write a test that tests what you wish your code did even though you code doesn't yet (test everything it should do in all cases). it should fail. then change/write bare minimum implementation code to get test to pass. don't introduce complexity that you aren't testing. then when test passes, refactor code to write it the way you wish you'd written it all along. - run all the tests before you check in to make sure your code never regresses.
continuous integration - always integrating code as you go - run all tests before you check in your code - switching off pairs - continuous integration servers - they have a red/green test status display on tv screens in big office room where everyone works, so when your code goes red you want to fix it as quickly as possible. - every time you have a bug, start by writing a test that confirms that that bug is there. helps understand when bug occurs (could be like 3 things coming together)
automated deployments - acceptance staging: a place you can push code to, PMs can test it - APIs that can be broken and reset - intermediate environment for deployment to make sure it works before actually deploying it - arrange for one button deployment - deploy early and often
version control - pivotal uses git - push to it early and often - integrate with each other
cucumber & test driven development - (cucumber is a test framework for ruby) - behavior driven development, not test driven development - write tests in plain English! using cucumber - write the test of the whole user story - red, green, refactor. - test after every line. respond to each new error
robolectric - test framework for android
inception planning meeting - goals (launch site, business thingies, everyone on team should know) - risks, constraints that could prevent meeting goals - roles (ex. visitor to site, member of site, admin of site) - stories for what each role would want to do - stories should be
Independent (stories are each independent things to do) Negotiable Valuable Estimatable (how long will it take to implement) Small (concise, takes no longer than a week to do, break into smaller piece) Testable
- prioritize stories
- after inception, can add a story at any time - also prioritize bugs. each bug is 0 points' worth of work (0,1,2,4,8) - changing SQL to other database structure is also 0 points' worth of work b/c doesn't add value to user
then also the weekly meetings - compare to inception planning - reorder priorities, discard or add
release planning: I N C E P T I O N
when the backlog ran out, client didn't have any options
need a project manager to own prioritization
PIVOTAL TRACKER website
Defer things to a later date:
Test-driven development: red-green refactor
rails environments: development, test, and production
yellow/green cards: mark chang?
cucumber: runs test suite for html testing robolectric: test android code
TEST I N C E P T I O N: goals, risk constraints roles: visitor, member, action, chef
acronym: INVEST Independent [user goals] Negotiable [what can we simplify] Valuable [show that user needs are important] Estimatable [break them down so you can have a sense of when they will get done] Small Testable
create stickies on whiteboar,d prioeritize with index cards requirements may be remembered at any time, throw items into icebox
Intro to Agile Development -Pivotal Labs Overview Prioritized Backlog -Put all the work you do in a queue so that the top thing is the most important thing and the bottom thing is the least. -Pivotal Tracker is how they manage the prioritized backlog -Clients make the tradeoff of what they want prioritized and finished now vs. what will be finished in two months from now. -Staff works on things at the top of the list. When they finish something, they grab the next thing that needs to be finished. -Allows product owners to own the product and engineers to own the engineering. Release Planning
Pivotal Tracker Demo Pair Programming
Test Driven Development
Continuous Integration -Constantly run tests on everything that gets added to the project to ensure that a new feature doesn’t mess up everything made earlier. Automated Deployments