Skip to content

Latest commit

 

History

History
77 lines (66 loc) · 2.51 KB

agile.md

File metadata and controls

77 lines (66 loc) · 2.51 KB
Raw

Agile Development

Stand-up meeting

Purpose is to drive communication and promote discussions inside the team

  • Start at a fixed time. Don't delay for late comers
  • Timebox the meeting to 5-15 minutes
  • Team members take turn to speak
  • Keep it short
    1. What did I do yesterday?
    2. What will I do today?
    3. What are the impediments?
  • Asking for clarification is OK, but discussions are to be held after the stand-up.

Scrum

Sprint Planning

  • lock requirements during sprints
    • changes in mid-sprint jeopardize work investment
      • planning isn't free
      • work toward discarded/delayed feature isn't free
    • increases risk
      • other features may not get delivered
      • other features may get delivered with defects
  • time boxing
    • easier planning
    • detects problems with features sooner
    • detects problems with development method sooner
    • known end date lends sense of focus and urgency
    • prevents feature creep
    • it's OK to let stories fail
  • only the team estimates
    • only people actually doing the work should estimate effort
    • they have unique insight on obstacles
    • need additional hardware
    • estimates can reveal incorrect assumptions
  • product owner availability
    • product owner has unique domain knowledge
    • needed for clarification during estimation
    • at first stories will be missing details too implement
    • it's a full time job

Feedback

  • demo every sprint
    • alternative is progress reports, which ca be misinterpreted
    • stakeholders need to see product early
      • they don't have time to read detailed specs
      • working software offers clearer picture
      • a clearer picture allows better panning
      • better planning means less wasted work
  • make feedback easy
    • you need feedback from users too
    • but they're busy people
      • make it difficult, and issues will go unreported
      • make it easy, and their feedback will boost product quality
    • don't ignore what you get - read it in standup
      • good feedback boosts morale
      • bad feedback is a chance to improve

Testing

  • test at development time

    • separate test phase discovers bugs after they're easy to fix
    • incurs dangerous technical debt
      • lowered velocity
      • compounding defects
      • rising support costs
    • if testers are at capacity, developers should help
      • if testing is a pain, developers will automate more of it

  • shared definition of "done"

    • avoids miscommunication
    • keeps testing from slipping through cracks

  • Codeschool, Agile Best Practices by Jay McGavren