Download as ZIP, PPTX
Uploaded byguy_davis
Agile Software Development Methodologies
The document discusses several agile software development frameworks including the Agile Manifesto, eXtreme Programming (XP), Scrum, and hybrid methods. The Agile Manifesto values individuals, working software, customer collaboration, and responding to change. XP focuses on communication, simplicity, feedback, and courage. Key practices include planning game, small releases, refactoring, and collective code ownership. Scrum emphasizes empirical process control, self-organizing cross-functional teams, and delivering working software frequently in short iterations. Hybrid methods combine different agile approaches to suit various project needs.
More Related Content
Similar to Agile Software Development Methodologies
Editor's Notes
- #2 Welcome to Tech Talks. Hoping to have participants present on interesting topics in software development. Goal: Further our programming practice as Software Engineers. Art, Craft, Science, Engineering question -> good topic :) “Revenge of the Programmers” : Phrase coined by Bertrand Meyer upon learing of Agile methodologies. What are programmers getting revenge against? Development Methodologies: 1) Lightweight: agile world 2) Heavyweight: RUP, CMM, MILSTD world 3) Ad-hoc: What's a methodology? 4) Tailored: Take the best of all worlds to suit your situation...
- #3 Agile is a group of lightweight software development methodolgies. “Agile Alliance” created by representatives from various methodologies in 2001 on a ski trip in Utah. Fancy term for light weight. Includes: Extreme Programming: Beck (1996) Scrum: Sutherland, Schwaber, Beedle (1996) Crystal: Alistair Cockburn (1995) DX: Robert Martin (1998) Feature drvien design (FDD): Coad, Lefevbre, Deluca (1997) Adaptive Software Development (ASD): Peter Highsmith (1994) Dynamic systems development method: ??? (1992) Pragmatic Programming: Thomas, Hunt (1999)
- #4 Not to say that things on the right are never done or are completely useless, just that agile processes have a preference for the items on the left. Basically about empowering the individual developer improves communication with customer improves time estimates through measurement of velocity improves testing (TDD, automated); better software quality attempts to reduce the pain caused by rapidly changing requirements no more death marches to meet arbitrary deadlines
- #5 Communication: Most problems traced to miscommunication between team members. Simplicity: What's the simplest thing that could possibly work? Feedback: Rapid releases, automated unit testing Courage: Admit failure, to refactor, to pair program XP defines four project variables that affect the outcome of all software projects. Management can pin down any three of the variables, but not the fourth. Any software project were all four are dictated by management without developer feedback are likely to fail. Good example: Fred Brooks classic “Mythic Man Month” describing the a death march to release IBM OS/360, added more junior programmers
- #6 Customer Satisfaction On-site customer: answer questions, define needs, prioritize features Small, frequent releases: early, constant feedback, easier to plan Software Quality Metaphor: Overall idea of the system, consistent naming scheme Testing: test first design; automated unit, regression, and acceptance tests Simple design: design for today, not for the future Refactoring: goal is to keep design simple Pair programming: peer review is good so do it all the time Project Management Planning game: determine user stories, priorities, release schedule Sustainable development: Never more than two weeks of OT in a row Collective code ownership: Keeps code clean, discourages “experts” Continous integration: avoids traditional big bang integration problems Coding standards: Easier for all developers to understand whole system
- #7 User stories (requirements) from customer; input for acceptance tests Spikes: a throw-away test program that addresses major uncertainties Release planning: Overall project schedule meeting, based on user story estimates, move user story cards around on big table to set releases Iterations: plan each iteration just before entry; follows from release plan; consider current project velocity (total of story estimates completed in an iteration), generate acceptance tests Acceptance tests are black box system tests. Customer responsible for verifying correctness.
- #8 Roughly 1-3 weeks long Initial planning meeting: Choose user stories to complete based on customer priority Handle failed acceptance tests from last iteration Estimates for stories must equal project velocity of previous iteration Break user stories down into programming tasks - developers choose and estimate their tasks (1-3 days of ideal time) - total estimates for tasks can't exceed project velocity (snow-plowing) All estimates are encouraged to be accurate, low-balling doesn't help May need to re-estimate all user stories and redo release plan every 3-5 iterations depending on requirements flux.
- #9 Daily stand up meeting Short (no chairs) Communicate problems and solutions Promote team focus Encourages communication between whole team Replaces tedious meetings (can determine if private meetings are necessary, can remove need to even schedule official meetings) Nearly immediate heads-up if individual is overloaded Promotes collective understanding of system, sharing
- #10 Any developer can add functionality, fix bugs, or refactor Reduces chance of one person becoming a bottle-neck - Move people around to promote cross-training Pair programming (proactive peer review) - One thinks tactically about method, other strategically about system Requires unit testing - drives design; test first design ensures the simplest solution is built - results in higher quality software, easier to refactor safely Requires continous integration - ensures unit tests are passing, catches problems fast! - only one pair integrates at a time (sequential integration) Allows constant refactoring to improve system (no more crusty code!) Class, Responsibilities, Collaboration (CRC) cards are used find simple solutions to complex problems; use cards in informal design meetings
- #11 Don't plan with too much detail too far out. Set the right scope. Feedback is critical to ensure the project is on track. Most effective for responding to changing requirements and project conditions.
- #12 These are not necessarily separate people; can wear multiple hats. Programmer: code, refactor, unit-test; strive for simplicity, communicate Customer: domain expert, able to make decisions, write user stories Tester: liase with customer to write, run, and report functional tests Tracker: track estimates and schedule, log defects, provide feedback Coach: responsible for process as a whole, steer the team (hands off) Consultant: XP doesn't create specialists, hire them to teach team Big Boss: courage, communication, occasionally oversight
- #13 Consultants love it because it leads to higher customer satisfaction by involving customer throughout project. Same thing with custom software or in-house development. But shrink wrap software usually has diverse customer base Already do insane peer review & quality control -> space shuttle coders Nailing down all four project variables, no place for XP feedback Most experience indicates 20-30 is upper limit on team size - Servidium had 30+ , New Architect article two teams of 50+ total - Can you split up a big team into XP sub-teams? Issues? Anecdotal evidence indicates that XP requires an experienced group of coders; junior teams don't do as well with XP What is the affect on traditional architecture and design process? What is the affect on traditional quality assurance process? Currently research at the U of C on Distributed XP (Frank Mauer)
- #14 Refers to scrum from rugby (team working to common goal) Originated in Japan in 1987 (Nonaka and Takeuchi) Mentioned in software context by Degrace and Stahl in 1990 Applied to software by Schwaber and Sutherland in mid-1990's Undefined (unpredictable, complex, dynamic) processes require different manage & control than defined (which CMM assumes) Concepts: Product Backlog: master list of all functionality (tasks and stories) - in order of priority with time estimates for each Sprint: an iteration (30 days) in which team has total freedom/responsibility to accomplish the goals Sprint Backlog: The portion of the Product Backlog the team selected for completion during the Sprint Tasks: Breakdown of items to complete to finish a sprint backlog item
- #15 Note absence of traditional roles like programmer, tester, architect, etc. Leads to discussion of Scrum team in next slide.
- #16 Like XP, Scrum uses cross-functional teams whose members have various strengths. All contribute. Like XP, requires a small team to enhance communication Inside sprint, team decides who will do which tasks, not dictated from management Important point: During a sprint, the team has full authority to make any decision to meet sprint goal (within org conventions and budget) Also have responsibility to meet the goal they have set for themselves. Scrum doesn't dictate engineering processes that team must use, could do XP, RUP, whatever as long as produce results. Use metascrums or “scrum of scrums” approach to scaling. Diagram shows 243 people in a number of scrum teams This approach has be scaled to over 800 people by Jeff Sutherland.
- #17 Really two separate meetings... First between team and product owner (and other observers): Product owner presents high priority items from product backlog With input from all, the team selects the backlog it can do in next sprint Identify a “sprint goal”: a short theme for the sprint (like XP's metaphor) Team publicly commits to completing backlog in coming sprint Second just the team and scrum master (product owner can observe): As a whole the team creates a Sprint Backlog of tasks based on the Product Backlog items committed to. Tasks should 4-16 hours of “ideal work” to accomplish (estimates) Team self-organizes to assign the tasks to each other Can modify sprint backlog throughout the sprint
- #18 Why daily? Brooks: “How does a project get to be a year late? A day at a time.” Short (~15 minute) meeting held each morning at same time (stand-up?) Only “pigs” can speak or ask questions, “chickens” just observe - Joke: A chicken asks pig to start a restaurant called “Ham 'n Eggs”. Pig says “No thanks. I'd be commited, but you'd only be involved!” Decisions: team has full authority to make any decision required to convert product backlog into product increment. Any items requiring further discussion should fork off follow-up meetings of just those involved. Scrum master plays role of meeting facilitator Create peer pressure to accomplish what you commit to...
- #19 Main project metric is hours remaining to complete in a sprint. This provides a good measure of team progress. If team finds itself overloaded in a sprint, it can call a meeting with the Product Owner to reduce that amount or scope of product backlog selected (like XP's snow-plowing) A sprint can be abnormally terminated: Management can decide sprint goal is no longer necessary Team can cancel sprint if they face major roadblock or sustained outside pressure to modify sprint goal from external sources
- #20 A Sprint Review Meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the Sprint.
- #21 Empirical process control: better suited to complexities inherent in software development (more agile than CMM for example) Team controls their destiny: team sinks or swims together, have full authority and responsiblity -> allows good teams to be very productive Socialization and knowledge transfer: team develops strong ties, open environment and scrum meeting lead to good knowledge transfer, pecking order in team changes minute to minute based on knowledge/expertise Risk management: reduces risks of poor estimation, low customer satisfaction, not meeting commitments, not resolving issues, contanstly changing requirements Management: requires management sponsorship and buy-in Result varies between teams -> assumes you have good people who can work more productively (always hire the best you can get)
- #22 XP and Scrum are complementary: XP is an engineering methodology (propeller heads) Scrum is a project management methodology (PHBs) XP@Scrum Ken Schwaber Applied by TransCanada Pipelines on their development projects - 300 people working on three large projects Scrum manages project while XP ensures high quality XBreed Mike Beedle Evolved from supporting multiple projects which resused components Can bridge gap caused by splitting up XP teams?
- #23 Alistair Cockburn Hired as a consultant to IBM in '90s to determine best methodology: - found successful teams apologizing for not following the process - found failed teams thinking they didn't apply process correctly Devised a family of Agile Methodologies for different projects Reliance on people, communication, and frequent delivery of running code. The methodology for 2-6 person projects is Crystal Clear, for 6-20 person projects is Crystal Yellow, for 20-40 person projects is Crystal Orange, then Red, Magenta, Blue, etc.
- #25 Does more in the way of documentation (particularly UML) as done by Peter Coad of TogetherSoft.
- #26 Three non-linear, overlapping phases in ASD. Highsmith views planning as a paradox in an adaptive environment. (Draws heavily from chaos theory for his work)
- #27 Calgary is hot-bed of Agile development right now both in industry and at the U of C. Next presentation: November 21 (6 -7 pm ) Agile Methods and Design: is software a big enough town for both of them? Martin Fowler (ThoughtWorks guru)
- #28 Tracks: User stories Iterations Project velocity Developer tasks