Agile certified practitioner Exam Notes
Download as PPTX, PDF3 likes1,631 views
The document provides information about the Agile Certified Practitioner (PMI-ACP) certification exam. It discusses the adoption curve for Agile practices based on Geoffrey Moore's Technology Adoption Life Cycle Curve. It also outlines the knowledge areas covered in the exam, including Agile frameworks, values and principles, tools and techniques, as well as the percentage of the exam dedicated to each area. Finally, it gives a brief history of Agile development origins and principles.
Agile certified practitioner Exam Notes
- 1. AGILE CERTIFIED PRACTITIONER (PMI-ACP) Gobi Durairaj, PMI-PMP, ACP, PBA, SAFe Agilist.,
- 2. 2 Based on Geoffrey Moore’s Technology Adoption Life Cycle Curve PMI-ACP AND ADOPTION CURVE The chasm PMPACP We are here!
- 3. 3 KNOWLEDGE & SKILLS (50% OF EXAM) Percentage of Knowledge and Skill Content / % of Exam Level 1 (66% / 33%) (18 knowledge/skills) Level 2 (24% / 12%) (12 knowledge/skills) Level 3 (10% / 5%) (13 knowledge/skills) Active listening Agile frameworks and terminology Agile contracting methods Agile Manifesto values & principles Building high-performance teams Agile project accounting principles Assessing and incorporating community and stakeholder values Business case development Applying new Agile practices Brainstorming techniques Colocation (geographic proximity)/distributed teams Compliance (organization) Building empowered teams Continuous improvement processes Control limits for Agile projects Coaching and mentoring within teams Elements of a project charter for an Agile project Failure modes and alternatives Communications management Facilitation methods Globalization, culture, and team diversity Feedback techniques for product (e.g., prototyping, simulation, demonstrations, evaluations) Participatory decision models (e.g., input based, shared collaboration, command) Innovation games Incremental delivery PMI's Code of Ethics and Professional Conduct Principles of systems thinking (e.g., complex adaptive, chaos) Knowledge sharing Process analysis techniques Regulatory compliance Leadership tools and techniques Self assessment Variance and trend analysis Prioritization Value-base analysis Variations in Agile methods and approaches Problem-solving strategies, tools, and techniques Vendor management Project and quality standards for Agile projects Stakeholder management Team motivation Time, budget, and cost estimation Value-based decomposition and prioritization
- 4. 4 TOOLS & TECHNIQUES (50% OF EXAM) Communications •information radiator, team space, agile tooling, osmotic communications for colocated and/or distributed teams, daily stand-ups Planning, monitoring, and adapting •retrospectives, task/Kanban boards, timeboxing, iteration and release planning, WIP limits, burn down/up charts, cumulative flow diagrams, process tailoring Agile estimation •relative sizing/story points, wide band Delphi/planning poker, affinity estimating, ideal time Agile analysis and design •product roadmap, user stories/backlog, story maps, progressive elaboration, wireframes, chartering, personas, agile modeling Product quality •frequent verification and validation, test-driven development/test first development, acceptance test-driven development, definition of done, continuous integration Soft skills negotiation •emotional intelligence, collaboration, adaptive leadership, negotiation, conflict resolution, servant leadership Value-based prioritization •return on investment (ROI)/net present value (NPV)/internal rate of return (IRR), compliance, customer-valued prioritization, minimally marketable feature (MMF), relative prioritization/ranking Risk management Metrics •risk- adjusted backlog, risk burn down graphs, risk-based spike Metrics Including but not limited to: velocity, cycle time, earned value management (EVM) for agile projects, escaped defects Value stream analysis •value stream mapping
- 6. 7 • ON FEBRUARY 11-13, 2001, AT SNOWBIRD SKI RESORT, SEVENTEEN PEOPLE MET TO TALK, SKI, RELAX, AND TRY TO FIND COMMON GROUND. • REPRESENTATIVES FROM EXTREME PROGRAMMING, SCRUM, DSDM, ADAPTIVE SOFTWARE DEVELOPMENT, CRYSTAL, FEATURE-DRIVEN DEVELOPMENT, PRAGMATIC PROGRAMMING, AND OTHERS SYMPATHETIC TO THE NEED FOR AN ALTERNATIVE TO DOCUMENTATION DRIVEN, HEAVYWEIGHT SOFTWARE DEVELOPMENT PROCESSES CONVENED. • WHAT EMERGED FROM THIS MEETING WAS A SYMBOLIC MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT, SIGNED BY ALL PARTICIPANTS. AGILE MANIFESTO
- 7. 8 AGILE IS NOT NEW 1943 1950 - 1960 s 198 5 199 0 199 5 199 6 199 7 199 8 200 0 200 1 USAF & NASA X-15 hypersonic jet Iterative Incremental Delivery Hirotaka Takeuchi & Ikujiro Nonaka The New New Product Development Game 1990 - Sutherland & Schwaber Scrum Framework DSDN Consortium Dynamic System Development Method 1996 - Beck, Cunningham, Jeffries Extreme Programming Jeff de Luca Feature Driven Development Alistair Cockburn Crystal Methodologies Robert Charette Lean Development Agile Manifesto Taiichi Ohno Toyota Production System Kanban Hardware Software
- 8. 9 AGILE PRACTICES Lean Kanban PMBOK Agile is an umbrella term for a group of iterative and incremental software development methods.
- 9. 10 AGILE TOOLS Process Tools VersionOne Rally Software JIRA + GreenHopper Team Foundation Server Excel Kanban AgileZen LeanKit Kanban Kanbanery Engineering Tools Continuous Integration http://jenkins-ci.org/ http://hudson-ci.org/ http://cruisecontrol.sourceforge.net / Engineering Tools Ruby Cucumber for ATDD/BDD: http://cukes.info/ RSpec: http://rspec.info/ Java http://www.junit.org/ http://www.jmock.org/ .Net http://www.nunit.org/ BDD for .NET: http://www.specflow.org/ http://www.nmock.org/
- 10. 11 AGILE MANIFESTO VALUES Individuals & interactions Processes & toolsover Working software Comprehensive documentation over Customer collaboration Contract negotiationover Responding to change Following a planover That is, while there is value in the items on the right, we value the items on the left more. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Source: www.agilemanifesto.org
- 11. 12 AGILE MANIFESTO PRINCIPLES Satisfy the Customer Welcome Change Deliver Frequently Collaborate Daily Support & Trust Motivated Teams Promote Face-to-Face Conversations Deliver Working Software Promote Sustainable Pace Promote Technical Excellence Maximize Through Simplicity Have Self-Organized Teams Reflect & Adjust Regularly Source: www.agilemanifesto.org
- 13. 14 FLIPPING THE IRON TRIANGLE Features Cost Date Cost Dat e Features Source: DSDM Plan- Driven Value- Driven $
- 14. 15 AGILE METHODS SUPPORT EXPERIMENTATION & ADAPTATION BY REDUCING THE COST OF CHANGE. THIS IS DONE BY EMPLOYING MANY CONCURRENT, RAPID FEEDBACK LOOPS TO SURFACE AND ADDRESS RISKS EARLY. REDUCING THE COST OF CHANGE Source: Examining the Cost of the Agile Change Curve by Scott Ambler
- 15. 16 COMMON UNDERSTANDING A document can’t generate the meaning in others that conversations can. There is a reason “Individuals and Interactions” is first in the Agile Manifesto. ? ? ! We don’t need an accurate document, we need a shared understanding - Jeff Patton / Agile 2012
- 16. 17 Deploy Documen t $ INCREMENTAL VALUE DELIVERY Agile Concurrent Development • Fund incrementally – opt to extend, redirect or cancel at a very granular level • Deliver & realize value steadily • Validate designs with users & customers • Continuously adapt to risk and change • Integrate early & often Waterfall Serial Development Invest up front, only realize value at end, assuming value proposition hasn’t changed Test Code Design Analyze $$ $ Analyze Design Code Test Deploy Document Analyze Design Code Test Deploy Document Analyze Design Code Test Deploy Document $ $$
- 17. 18 COLLABORATION AND FEEDBACK LOOPS Traditional methods only work for so long because… • No or little feedback before delivery. • Change not expected. Why are agile methods being considered? • Constant feedback loops. • Change is expected.
- 18. 19 PROCESS BURDEN OR LACK OF DISCIPLINE • HISTORICALLY DEVELOPMENT TEAMS HAVE FACED A FALSE CHOICE IN RESPECT TO PROCESS o OVERLY COMPLEX AND BURDENSOME o OR, UNDISCIPLINED WITH NO CONTROLS • AGILE PROVIDES A LIGHTWEIGHT, BUT DISCIPLINED APPROACH FOR SPEEDING TIME TO MARKET, IMPROVING QUALITY, AND INCREASING PREDICTABILITY AGILE IS DISCIPLINE W/O UNDUE BURDEN
- 19. 20 FOUR VOLUNTEERS, PLEASE! TIME IS SET AT 2 MINUTES ESTIMATE THROUGHPUT ROUND 1 (MEASURE FIRST AND LAST DELIVERY TIME) • FIRST PERSON FLIPS 50 COINS • WHEN DONE WITH ENTIRE BATCH, PASS TO NEXT PERSON ROUND 2 • FIRST PERSON FLIPS ONE COIN OF HIGHEST VALUE AND PASSES TO NEXT PERSON • KEEP FLIPPING AND PASSING UNTIL DONE ROUND 3 • EACH TABLE CREATES THEIR OWN RULES TO MAXIMIZE COIN FLOW/THROUGHPUT IN LEAST AMOUNT OF TIME RETROSPECTIVE EXERCISE – BATCH VS FLOW THROUGHPUT
- 20. 21 Key Agile Principles Traditional Waterfall Focus on Highest Value First Align project, product and team visions by prioritizing by business needs, and using well architected code, to deliver better quality products faster and cheaper. All or nothing Tight coupling & bias toward building out internals in a breadth first fashion means that nothing can be delivered in isolation, even if it’s valuable. Responding to Change Acknowledge uncertainty & adapt to both external (market) and internal changes, by modifying plans & approach. Use engineering principles to make code base easy to modify. Baseline & Change Control Constrain or even completely eliminate any significant change other than dropping features. Work to initial plans, even when they are proven to be invalid. Iterative Use short time boxes to provide a rhythm, continually flow of value to the customer, and refine deliverables over time. Phased No rhythm as project is executed using long phases. Feedback & Continuous Improvement Use continual feedback to inform plans and modify approach. Lessons Learned at the End Feedback is rarely given in time for it to be applied towards improving processes and project execution. Small, Integrated Teams A small team size, and overlap in skills sets, simplifies communications, allows everyone to see the big picture, creates self discipline and provides flexibility. Silo Teams with Handoffs Staff works in functional oriented groups, throwing documentation and code over the wall. Technical Excellence / Bake Quality In Use TDD , ATDD, refactoring, and other strong engineering principles to ensure quality. Inspection Attempt to ensure quality by after the fact inspection. AGILE PRINCIPLES COMPARED
- 21. 22 AGILE IS EMPIRICAL, NOT DEFINITIVE Agile assumes that baselines may change significantly during the project. In such an unpredictable environment, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.
- 22. 23 ROLLING WAVE PLANNING, USED IN AGILE PROCESSES, EMBRACES THE LEAN IDEAL OF MAKING DECISIONS AT THE LAST RESPONSIBLE MOMENT, WHEN THE MOST POSSIBLE INFORMATION IS AVAILABLE. THIS MAXIMIZES FLEXIBILITY AND PLANNING ACCURACY. AGILE USES ROLLING WAVE PLANNING Level of Planning Planning Approach Strategic product line goals Strategic Planning Strategic product goals Product Planning Specific problems to solve Lean / Six Sigma Large functional goals Release Planning Small, defined work items Iteration Planning Tactical organization & execution Daily Standup
- 23. 24 LAYERS OF PRODUCT PLANNING Product / Project What business objectives will the product fulfill? Product Goals Product Charter Elevator Pitch Release How can we release value incrementally? What subset of business objectives will each release achieve? What user constituencies will the release serve? What general capabilities (big stories) will the release offer? Release Roadmap Release Plan Iteration / Sprint What specifically will we build? (User Stories) How will this iteration move us toward release objectives? Iteration Plan Development Tasks Story (Backlog Item) What user or stakeholder need will the story serve? How will it specifically look and behave? How will I determine if it’s completed? Story Details Acceptance Tests
- 24. 25 • TOP LEVEL GOAL(S) MUST BE COMMUNICATED TO ALL LEVELS OF THE ORGANIZATION • MEMBERS OF THE ORGANIZATION OFFER CANDID INFORMATION UP THE MANAGEMENT LADDER. • LEADERS/MANAGERS OFFER GUIDANCE (WHY AND WHAT ≠ HOW) PRINCIPLE - SELF-ORGANIZED AND EMPOWERED info guide info guide info guideinfo guide
- 25. 26 SOME BASIC TERMINOLOGY Scrum Extreme Programming (XP) Definition Sprint Iteration Fixed-length period of time (timebox) Release Small Release Release to production Sprint/Release Planning Planning Game Agile planning meetings Product Owner Customer Business representative to project Retrospective Reflection “Lessons learned”-style meeting ScrumMaster Coach Agile project manager Development Team Team Empowered Cross-Functional team Daily Scrum Daily Standup Brief daily status meeting
- 26. 27 SOME MORE AGILE TERMINOLOGY Term Definition Spike Something cannot be estimated until a development team runs a timeboxed investigation. The spike itself is a throw- away. Can include risk, architectural, or any unknown. Tracer Bullet An experimental solution that cuts through all the "layers" of the architecture. It is not necessarily time-boxed. It is not intended to be thrown away. Kaizen Continual improvement of all areas of a company not just quality. Value Stream An end-to-end business process which delivers a product or service More terms… Go to the Community Guide of the PMI-ACP at http://agile.vc.pmi.org/
- 27. 28 Session Purpose Timing/Durati on Attendees Iteration 0 Orient Team to project’s business value and analytical background, the process, and one another. Start of project Approximately 1- 3 weeks of 2-4 hr workshops Team, PO, SM, Key Stakeholders & users Release Planning Determine what a Release should include and when it should be delivered. Start of Release 2-4 hours PO, SM, Key Stakeholders, optionally Team Daily Standup Facilitate rapid coordination between Team members, and with PO. Daily 10-15 minutes Team, SM, PO Iteration Planning Elaborate, estimate and prioritize highest-value Product Backlog items for an Iteration. Start of each Iteration 2-4 hours Team, SM, PO Iteration Retrospective Reflect on project & process issues and take action as appropriate. End of each Iteration 30-45 minutes Team, SM, PO Iteration Review Demonstrate completed functionality to interested stakeholders & users to show progress and gain feedback. End of each Iteration 1-1½ hours Team, PO, SM, Key Stakeholders & users MEETINGS SUMMARIZED
- 28. 29 SMALL TEAMS WITH EVERYTHING NEEDED TO DELIVER AN INCREMENT OF VALUE BACKLOG PRIORITIZED BY VALUE BEING DELIVERED INCREMENTALLY AT SCALE, THE BACKLOG AND PRODUCTS FOR THESE TEAMS NEED TO BE COORDINATED AND TECHNICAL PRACTICES MUST ADDRESS THE CHALLENGES OF INTEGRATION HOW DOES AGILE WORK?
- 29. 30 Deploy Documen t $ INCREMENTAL VALUE DELIVERY Agile Concurrent Development • Fund incrementally – opt to extend, redirect or cancel at a very granular level • Deliver & realize value steadily • Validate designs with users & customers • Continuously adapt to risk and change • Integrate early & often Waterfall Serial Development Invest up front, only realize value at end, assuming value proposition hasn’t changed Test Code Design Analyze $$ $ Analyze Design Code Test Deploy Document Analyze Design Code Test Deploy Document Analyze Design Code Test Deploy Document $ $$
- 30. 31 INCREMENTAL AND ITERATIVE DELIVERY Incrementing is more about delivery. 1 2 3 4 5 1 2 3 4 5 Iterating allows you to move from vague idea to realization. Going from rough to polished Image Credit: Jeff Patton
- 31. 32 • ITERATIONS ARE REGULARLY SCHEDULED, PRE-PLANNED, RECURRING TIME BOXES. PROVIDE A CADENCE / RHYTHM THAT PROVIDES PREDICTABILITY AND SYNCHRONIZATION POINTS FOR PLANNING. THE MORE MATURE YOUR PROCESS, THE SHORTER THE ITERATIONS. • THINGS WE TIME-BOX: o SPRINTS (OR ITERATIONS) - LENGTH OF TIME IN WHICH WORK IS DONE o RELEASES - PRODUCTION AND MAINTENANCE o WORKING SESSIONS - RELEASE PLANNING, SPRINT PLANNING, SPRINT REVIEW, RETROSPECTIVE • ITERATIONS FACILITATE INCREMENTAL DEVELOPMENT (BUT INCREMENTAL DEVELOPMENT DOESN’T REQUIRE ITERATIONS). ITERATIONS
- 33. 34 “A PRODUCTION PRACTICE THAT CONSIDERS THE EXPENDITURE OF RESOURCES FOR ANY GOAL OTHER THAN THE CREATION OF VALUE FOR THE END CUSTOMER TO BE WASTEFUL, AND THUS A TARGET FOR ELIMINATION.“ WHAT IS LEAN? Source: Wikipedia
- 34. 35 KANBAN (看板) LITERALLY MEANING "SIGNBOARD" OR "BILLBOARD", IS A CONCEPT RELATED TO LEAN AND JUST-IN- TIME (JIT) PRODUCTION. TAIICHI OHNO IS CONSIDERED TO BE THE FATHER OF THE TOYOTA PRODUCTION SYSTEM WHAT IS KANBAN? Kanban is a scheduling system that tells you what to produce, when to produce it, and how much to produce.
- 35. 36 • A SOFTWARE DEVELOPMENT METHODOLOGY WHICH IS INTENDED TO IMPROVE SOFTWARE QUALITY AND RESPONSIVENESS TO CHANGING CUSTOMER REQUIREMENTS. • IT ADVOCATES FREQUENT "RELEASES" IN SHORT DEVELOPMENT CYCLES, WHICH IS INTENDED TO IMPROVE PRODUCTIVITY AND INTRODUCE CHECKPOINTS WHERE NEW CUSTOMER REQUIREMENTS CAN BE ADOPTED. WHAT IS EXTREME PROGRAMMING?
- 36. 37 SCRUM IS AN ITERATIVE AND INCREMENTAL PROJECT DELIVERY FRAMEWORK. WHAT IS “SCRUM?” Source: Wikipedia
- 37. 38 Iteration 0 Brief orientation to the project’s business value and analytical background, the Agile process, and the Team. Project Orientation • Business case overview • Business process analysis • Project scope & objectives • Initial Product Backlog Process Orientation • Agile process training • Sprint/Release cycles • Definition of “Done” Team Orientation • Team room artifacts • Team norms • Technical environments, design, architecture, etc INITIATING AN AGILE PROJECT Release Planning Session Initial project planning, to review initial Product Backlog and set production Release dates. Release Schedule Product Backlog List of desired functionality prioritized by business value by Product Owner. Allow a user to create a free account. (Priority 1) Allow subscribers to purchase music. (Priority 3) Allow user to personalize store experience. (Priority 9)
- 38. 39 A USEFUL PROJECT CHARTER CONTAINS THREE KEY ELEMENTS: 1. VISION: THE VISION DEFINES THE “WHY” OF THE PROJECT. THIS IS THE HIGHER PURPOSE, OR THE REASON FOR THE PROJECT’S EXISTENCE. 2. MISSION: THIS IS THE “WHAT” OF THE PROJECT AND IT STATES WHAT WILL BE DONE IN THE PROJECT TO ACHIEVE ITS HIGHER PURPOSE. 3. SUCCESS CRITERIA: THE SUCCESS CRITERIA ARE MANAGEMENT TESTS THAT DESCRIBE EFFECTS OUTSIDE OF THE SOLUTION ITSELF. ADDITIONAL ELEMENTS: WORKING PRACTICES – PLANNING, ESTIMATING, DEFINITION OF DONE, TRACKING PROGRESS, TDD METHODS CONTINUOUS INTEGRATION – INTEGRATION TIME LIMITS, BREAKING THE BUILD, CODE CHECK- IN CODE – PAIRED PROGRAMMING, OWNING THE CODE, DOCUMENTATION ITERATIVE AND INCREMENTAL DEVELOPMENT – ITERATION CYCLE AND DEPLOYMENT CYCLE AGILE PROJECT CHARTER
- 39. Lean
- 40. 41 LEAN PORTFOLIO MANAGEMENT • Corporate strategy operates over years with direct line of sight to priorities • Optimize the whole • Manage internal and external dependencies • Focus on quickly delivering minimal marketable features • Clear feedback mechanism between business and development • Creates alignment beyond single teams Year(s): Set corporate goals and strategies Quarter(s): Discover and create innovative product strategies from corporate goals Month(s): Update Release Plans, Product Backlogs and Roadmaps Week(s): Decompose features from Product Backlog into tasks and deliver working code
- 41. 42 THE 7 PRINCIPLES OF LEAN 1. ELIMINATE WASTE 2. CREATE KNOWLEDGE 3. BUILD QUALITY IN 4. DEFER COMMITMENT 5. OPTIMIZE THE WHOLE 6. DELIVER FAST 7. RESPECT PEOPLE 7 PRINCIPLES OF LEAN Source: Mary and Tom Poppendieck
- 42. 53 PROCESS CYCLE EFFICIENCY IS THE KEY MEASURE OF LEANNESS PROCESS MAP ENTIRE VALUE-STREAM AT A HIGH LEVEL, DRILLING DOWN INTO MORE DETAIL ONLY AS POTENTIAL AREAS OF INTEREST ARE IDENTIFIED • VALUE-ADDED: THIS STEP IN THE PROCESS ADDS FORM, FUNCTION, AND VALUE TO THE END PRODUCT AND FOR THE CUSTOMER. • NON-VALUE-ADDED: THIS STEP DOES NOT ADD FORM, FUNCTION, OR ASSIST IN THE FINISHED GOODS MANUFACTURING OF THE PRODUCT. • NON-VALUE-ADDED-BUT-NECESSARY: THIS STEP DOES NOT ADD VALUE, BUT IS A NECESSARY STEP IN THE FINAL VALUE-ADDED PRODUCT. LEAN PROCESS CYCLE EFFICIENCY PCE = (sum of time for Value Added process steps) (sum of time for All process steps)
- 43. 56 THE “KAIZEN” MINDSET: 1. EVERYTHING, NOT JUST SOFTWARE DEVELOPMENT, CAN AND SHOULD BE IMPROVED 2. IMPROVEMENTS SHOULD BE MADE DAY TO DAY 3. THE BEST IMPROVEMENTS COME FROM TAKING THE CUSTOMER’S POINT OF VIEW 4. MOVE FROM CRITICISM TO SUGGESTION 5. KEEP IMPROVING, EVEN IF THINGS ARE WORKING CONTINUOUS IMPROVEMENT 改善
- 44. Kanban
- 45. 60 1. VISUALIZE YOUR WORKFLOW 2. LIMIT YOUR WORK IN PROCESS EXAMPLE: MATURE REQUIREMENTS SEPARATELY • INSTEAD OF FIGURING EVERYTHING OUT FOR A USER STORY JUST IN TIME AT SPRINT PLANNING, WE CAN READY THEM IN ADVANCE • THE SPECIFIC PROCESS VARIES, BUT THERE IS A SET OF STEPS TO GET A REQUIREMENT READY KANBAN – HIGH LEVEL New Candidates PO Approved Decompose d Acceptance Criteria Testable Example Dev Review Ready for Sprint 10 cards 6 cards 4 cards 4 cards 4 cards 8 cards 12 cards
- 46. AIRPLANE GAME PAPER AIRPLANE GAME • TEAM OF 5 MAKES 21 AIRPLANES • 1ST RUN: FAST AS YOU CAN • 2ND RUN: FLOW, BATCH SIZE OF ONE • CONSISTENTLY BETTER RESULTS • LEAD TIME: 3X IMPROVEMENT • THROUGHPUT: 10-20% BETTER
- 47. 62 EVERYTHING AT ONCE = MANY STARTED FEW FINISHED COSTS OF OVER-UTILIZATION Develop Test In Process Ready In Process Ready 4 slots 3 slots 4 slots 3 slots WIP Limits = Fast “A system of local optimums is not an optimum system at all” - Eli Goldratt
- 49. 64 AGILE ENGINEERING PRACTICES ALLOW TEAMS TO MOVE FAST, BE FLEXIBLE AND DELIVER HIGH QUALITY SOFTWARE: • AUTOMATED BUILDS & CONTINUOUS INTEGRATION REDUCE TIME AND EFFORT ASSOCIATED WITH MANUAL BUILDS, AND RISK FROM BIG-BANG INTEGRATIONS • SIMPLE DESIGN & REFACTORING KEEP INCREMENTAL DEVELOPMENT FROM LEADING TO POOR ARCHITECTURES • MULTI-LEVEL/AUTOMATED TESTING & TEST-DRIVEN DEVELOPMENT REDUCE TESTING TIME AND EFFORT AND ALLOW DEVELOPERS TO MAKE CHANGES WITH CONFIDENCE • PAIR PROGRAMMING INCREASES SOFTWARE QUALITY WITHOUT IMPACTING TIME TO DELIVER. AGILE ENGINEERING PRACTICES Source: Bill Wake, http://www.xp123.com
- 50. 65 XP COACH • THE XP COACH ROLE HELPS A TEAM STAY ON PROCESS AND HELPS THE TEAM TO LEARN. A COACH BRINGS AN OUTSIDE PERSPECTIVE TO HELP A TEAM SEE THEMSELVES MORE CLEARLY. THE COACH WILL HELP BALANCE THE NEEDS OF DELIVERING THE PROJECT WHILE IMPROVING THE USE OF THE PRACTICES. A COACH OR TEAM OF COACHES SUPPORTS THE CUSTOMER TEAM, THE DEVELOPER TEAM, AND THE ORGANIZATION. • THE DECISIONS THAT COACHES MAKE SHOULD ALWAYS STEM FROM THE XP VALUES (COMMUNICATION, SIMPLICITY, FEEDBACK, AND COURAGE) AND USUALLY MOVE TOWARD THE XP PRACTICES. AS SUCH, FAMILIARITY WITH THE VALUES AND PRACTICES IS A PREREQUISITE. THE COACH MUST COMMAND THE RESPECT REQUIRED TO LEAD THE RESPECTIVE TEAMS. THE COACH MUST POSSESS PEOPLE SKILLS AND BE EFFECTIVE IN INFLUENCING THE ACTIONS OF THE TEAMS. • THE XP COACH USES MANY DIFFERENT TECHNIQUES. THE COACH IS A MENTOR, WORKING SIDE BY SIDE WITH TEAM MEMBERS ON THEIR TASKS. THE COACH IS A FACILITATOR, HELPING ACHIEVE MORE EFFECTIVE TEAM PERFORMANCE. THE COACH IS A CONDUIT, REINFORCING COMMUNICATION WITHIN THE TEAM AND ACROSS TEAMS. XP ROLES - COACH
- 51. 66 XP CUSTOMER • THE XP CUSTOMER ROLE HAS THE RESPONSIBILITY OF DEFINING WHAT IS THE RIGHT PRODUCT TO BUILD, DETERMINING THE ORDER IN WHICH FEATURES WILL BE BUILT AND MAKING SURE THE PRODUCT ACTUALLY WORKS. • THE XP CUSTOMER WRITES SYSTEM FEATURES IN THE FORM OF USER STORIES THAT HAVE BUSINESS VALUE. USING THE PLANNING GAME, HE CHOOSES THE ORDER IN WHICH THE STORIES WILL BE DONE BY THE DEVELOPMENT TEAM. DEFINES ACCEPTANCE TESTS THAT WILL BE RUN AGAINST THE SYSTEM TO PROVE THAT THE SYSTEM IS RELIABLE AND DOES WHAT IS REQUIRED. XP ROLES - CUSTOMER
- 52. 67 XP PROGRAMMER • THE XP PROGRAMMER IS RESPONSIBLE FOR IMPLEMENTING THE CODE TO SUPPORT THE USER STORIES. XP ROLES - PROGRAMMER
- 53. 68 XP TESTER • THE PRIMARY RESPONSIBILITY OF THE XP TESTER IS TO HELP THE CUSTOMER DEFINE AND IMPLEMENT ACCEPTANCE TESTS FOR USER STORIES. THE XP TESTER IS ALSO RESPONSIBLE FOR RUNNING THE TESTS FREQUENTLY AND POSTING THE RESULTS FOR THE WHOLE TEAM TO SEE. AS THE NUMBER OF TESTS GROW, THE XP TESTER WILL LIKELY NEED TO CREATE AND MAINTAIN SOME KIND OF TOOL TO MAKE IT EASIER TO DEFINE THEM, RUN THEM, AND GATHER THE RESULTS QUICKLY. XP ROLES - TESTER
- 54. 1. ______ IS RESPONSIBLE FOR IMPLEMENTING THE CODE TO SUPPORT THE USER STORIES. 2. ______ HELP THE CUSTOMER DEFINE AND IMPLEMENT ACCEPTANCE TESTS FOR USER STORIES 3. ______ HELPS A TEAM STAY ON PROCESS AND HELPS THE TEAM TO LEARN. IS A MENTOR, WORKING SIDE BY SIDE WITH TEAM MEMBERS ON THEIR TASKS 4. ______ WRITES SYSTEM FEATURES IN THE FORM OF USER STORIES THAT HAVE BUSINESS VALUE AND DEFINES ACCEPTANCE TESTS. XP ROLES – QUICK QUIZ a) XP COACH b) XP CUSTOMER c) XP PROGRAMMER d) XP TESTER 1(c)2(d)3(a)4(b)
- 55. 72 SIMPLE DESIGN: • CODE IS ALWAYS TESTABLE, BROWSABLE, UNDERSTANDABLE, AND EXPLAINABLE • DO THE SIMPLEST THING THAT COULD POSSIBLY WORK NEXT. COMPLEX DESIGN IS REPLACED WITH SIMPLER DESIGN • THE BEST ARCHITECTURES, REQUIREMENTS, AND DESIGNS EMERGE FROM SELF- ORGANIZING TEAMS REFACTORING: • REMOVE REDUNDANCY, ELIMINATE UNUSED FUNCTIONALITY, AND REJUVENATE OBSOLETE DESIGNS • REFACTORING THROUGHOUT THE ENTIRE PROJECT LIFE CYCLE SAVES TIME AND INCREASES QUALITY • CODE IS KEPT CLEAN AND CONCISE SO IT IS EASIER TO UNDERSTAND, MODIFY, AND EXTEND SIMPLE DESIGN AND REFACTORING
- 56. Risk
- 57. 80 CREATE A RISK CENSUS DURING THE FIRST SPRINT PLANNING MEETING AND THEN UPDATE IT QUICKLY DURING SUBSEQUENT PLANNING MEETINGS AS NEW RISKS ARE IDENTIFIED OR AS THE PROBABILITIES OR SIZES OF KNOWN RISKS CHANGE. RISK BURNDOWN As with a regular release burndown chart, we should see a linear drop in risk over the course of the project. Plot your project risk exposure and display it with other big visible charts in your team area. Source: Managing Risk on Agile Projects | Mike Cohn - Mountain Goat Software
- 58. 81 RISK MANAGEMENT Traditional Risk Management Agile Risk Management Prepare formal risk management plan Educate the team. Invite them to determine best approach to manage Formal risk identification meetings and then create Risk Register Team identifies risks in all meetings and add to information radiators Conduct qualitative and quantitative analysis. Determine how to respond Facilitate the team in a qualitative analysis, determine how to respond, post results Periodically review Risk Register and make updates as needed Constantly review risk and responses as part of all meetings, reviews and retrospectives Source: Sliger & Broderick (2008),The Software Project Manager's Bridge to Agility, Addison- Wesley
- 59. 82 IMPLICITLY MANAGING RISK: • USER STORIES ARE PRIORITIZED BY THE PRODUCT OWNER o HIGHEST VALUE ITEMS ARE ATTACKED FIRST o HIGHEST RISK ITEMS ARE ALSO ATTACKED EARLY • ITERATIVE DELIVERY ENSURES THAT INTEGRATION AND ROLLOUT RISKS ARE ATTACKED VERY EARLY IN THE PROJECT LIFECYCLE • TECHNICAL DISCIPLINE HELPS KEEP A TIGHT REIN ON DEVELOPMENT RISK o AUTOMATED BUILDS AND CONTINUOUS INTEGRATION KEEP CODE INTEGRATION AND CODE QUALITY RISK TO A MINIMUM IMPLICIT RISK MANAGEMENT
- 60. 83 EXPLICITLY MANAGING RISK: • REVIEW THE PRODUCT BACKLOG • IDENTIFY AND LIST RISKS BY IMPACT (HIGH/MEDIUM/LOW) AND PROBABILITY (HIGH/MEDIUM/LOW) • PROVIDE A MITIGATION PLAN WITH CLEAR RESPONSIBILITY • CREATE TASK CARDS FOR RISK MITIGATION ITEMS • INSERT INTO PRODUCT BACKLOG AND/OR SPRINT BACKLOGS; OR TRACK ON RISK BOARD EXPLICIT RISK MANAGEMENT Agile Risks, Agile Rewards, Smith and Pichler, Dr. Dobb’s 2005
- 62. 85 User Interface Layer Business Logic Layer Persistence Layer WORK IN AGILE PROJECTS IS ORGANIZED BY UNITS OF VALUE, RATHER THAN BY ARCHITECTURAL LAYER. WORK ORGANIZED BY VALUE Feature / User Story 2 Feature / User Story 1 Feature / User Story 3
- 63. 86 KEY CHARACTERISTICS • HIGH-LEVEL DESCRIPTIONS OF DESIRED FUNCTIONALITY AND GOALS • IMPLEMENT “VERTICAL SLICES” OF THE SYSTEM’S FUNCTIONALITY • “CONTRACTS FOR CONVERSATION,” NOT ALL- INCLUSIVE REQUIREMENTS • USER STORIES WAIT IN THE PRODUCT BACKLOG UNTIL PULLED INTO THE SPRINT BACKLOG • CONTAIN ACCEPTANCE CRITERIA TO DEFINE “DONE” USER STORIES AT A GLANCE As a user I can create an account. Estimate 21 Points Priority 1 (High) As a user I can enter a user name. Estimate 4 points Priority 1 (High) As a user I can enter password. Estimate 8 points Priority 1 (High) Product Backlog User Story Sprint Backlog User Stories
- 64. 87 FROM USER STORIES TO TASKS Tasks As a user I can enter a password. Estimate 8 points Priority 1 (High) Acceptance Criteria User Story On back… • Design user interface • Develop CSS/HTML • Create database fields • Develop validation criteria • Write test cases • Code test fixtures • Unit testing • Acceptance testing • Usability testing • Write online help text • Password match validated • Contains special characters • Minimum 10 digits • Cannot be text only
- 65. 88 AS A <TYPE OF USER>, I CAN <IMMEDIATE GOAL> SO THAT <BUSINESS OUTCOME>. USER STORY TEMPLATE User Role (Who?) Desired Function (What?) End Result (Why?) Who, What, Why… what’s not here?
- 66. 89 ACCEPTANCE CRITERIA HELP TO SET SCOPE AND DEFINE WHAT DONE MEANS FOR A GIVEN USER STORY. USER STORY ACCEPTANCE CRITERIA •Verify that a premium member can cancel the same day without a fee. •Verify that a non-premium member is charged 10% for a same-day cancellation. •Verify that an email confirmation is sent. •Verify that the hotel is notified of any cancellation. As a user, I can cancel a reservation.
- 67. 90 CIRCLE WHICH ATTRIBUTES MAKE A GOOD STORY AND THEN DISCUSS AS THE GROUP WHAT MAKES A GOOD STORY? Independent Valuable Testable CreativeEstimatabl e Small Negotiable Source: Bill Wake
- 68. 91 PRE RELEASE LIFE OF A USER STORY • Phone # in US format, contains no alpha characters, minimum 10 digits • First name, Last name and email address required • Email specified in standard format • Etc. Acceptance Criteria Created Prior to Release Planning As a user I want to create an account User Stories Created Prior to Release Planning Sprint Tasks Created at Sprint Planning • Design UI Mock Up • Write online help text • Develop CSS/HTML • Develop validation criteria • Create database tables • Code test fixtures • Code • Perform testing Name Phone Email Valid John Smith 215-555- 1212 jsmith@ls.co m TRUE Smith 215-555- 1212 jsmith@ls.co m FALSE John 215-555- 1212 jsmith@ls.co m FALSE 215-555- 1212 jsmith@ls.co m FALSE John Smith jsmith@ls.co m FALSE Smith jsmith@ls.co m FALSE John jsmith@ls.co m FALSE Testable Examples (ATDD) Created Prior to Sprint Planning Estimate 5-Points Priority 1 -High (Created at Release Planning)
- 69. 92 USER STORIES AREN’T THE ONLY WAY TO DEVELOP, EXPRESS AND ELABORATE REQUIREMENTS IN AGILE. SOME COMPLEMENTARY TOOLS & METHODS INCLUDE: • ESSENTIAL USE CASES • LOW-FIDELITY PROTOTYPING • HIGH-FIDELITY PROTOTYPING THE BEST APPROACH WILL BE DETERMINED BY YOUR TEAM AND THE PROBLEMS AT HAND. BEYOND USER STORIES
- 70. 93 LOW-FIDELITY PROTOTYPING IS A FAST, CHEAP, EASILY ITERATED, COLLABORATIVE WAY TO TEST VARIOUS CONCEPTS & APPROACHES. LOW-FIDELITY PROTOTYPING IN AGILE Tools • Paper sketches and collages • Whiteboard drawings Applications • Concept design: to explore different metaphors and design strategies • Interaction design: to organize screen structure & flow • Screen design: for initial screen layout & design • Screen testing: to refine screen layoutSource Adaptive Path for Sketchboard example
- 71. 94 HIGH-FIDELITY PROTOTYPES ARE DETAILED, INTERACTIVE AND REUSABLE MEANS OF SIMULATION. TOOLS: • PHOTOSHOP, VISIO, POWERPOINT • FLASH, IRISE STUDIO, SERENA PROCESSVIEW • WPF, XAML, XUL… APPLICATIONS: • WHEN STABLE REQUIREMENTS SUPPORT REUSE • TO TEST COMPLEX INTERACTION SCENARIOS • TO FINALIZE DETAILED DESIGNS • AS INPUTS TO A SPRINT HIGH-FIDELITY PROTOTYPING IN AGILE Source: iRise Studio, www.irise.com
- 72. 1. IN GENERAL, WE CAN VIEW THE MATURATION OF A NEED (EXPRESSED AS A USER STORY) AS HAVING ENOUGH INFORMATION TO PRIORITIZE, __________ AND ___________. 2. THE USER STORY FORMAT HAS THREE PARTS: “AS A”, “I WANT TO” AND “_________.” 3. ACCEPTANCE CRITERIA IS WRITTEN FOR TEAM MEMBERS AND, AS SUCH, ASSUMES A LEVEL OF EXISTING ___________. 4. ACCEPTANCE CRITERIA IS INCREDIBLY USEFUL BUT A ___________ WILL OFTEN PROVIDE SIGNIFICANT ADDITIONAL CLARITY. AGILE REQUIREMENTS a) BUILD b) DOMAIN KNOWLEDGE c) ESTIMATE (TEST) d) OUTSIDERS e) SO THAT f) TESTABLE EXAMPLE 1(c)(a)2(e)3(b)4(f)
- 73. 5. A ___________ DEFINES HOW THE SOFTWARE WILL BE IMPLEMENTED; IT CAN DEFINE THE EXTERNAL BEHAVIOR, ___________ DESIGN, OR BOTH. 6. AS DEFINED IN THIS TRAINING, A SPECIFICATION BUILDS ON A REQUIREMENT WITH ADDITIONAL CONTEXT, CONVERSATIONS AND ___________. 7. A SPECIFICATION SHOULD BE ___________, DEFINING JUST ENOUGH TO HELP THE TEAM BUILD CONFIDENTLY WITHIN THE SPRINT. 8. THE APPROPRIATE LEVEL OF DETAIL REQUIRED IN A SPECIFICATION WILL ___________, DEPENDING ON, AMONG OTHER THINGS, THE ___________ OF THE REQUIREMENT, THE DOMAIN KNOWLEDGE OF THE TEAM, AND THE REQUIREMENTS’ SIMILARITY TO WHAT HAS ALREADY BEEN BUILT. AGILE REQUIREMENTS g) COMPLEXITY h) DESIGNS i) INTERNAL j) LIGHTWEIGHT k) SPECIFICATION l) VARY 5(k)(i)6(h)7(j)8(l) (g)
- 74. Agile Estimation
- 75. 98 HIGH LEVEL – AFFINITY STORY LEVEL – PLANNING POKER STORY POINTS o PURELY RELATIVE MEASURE OF COMPLEXITY (2 IS HALF AS HARD AS 4) o VARIABILITY AVERAGES OUT ACROSS MANY STORIES o DON’T DECAY OVER TIME SCALES WITH INCREASING GAPS BETWEEN ELEMENTS ARE PREFERRED o FIBONACCI: 1, 2, 3, 5, 8, 13 o DOUBLES: 1/2, 1, 2, 4, 8, 16 o “T-SHIRT SIZES:” S, M, L, XL, XXL AGILE ESTIMATION LEVELS, UNITS AND SEQUENCES Traditional project estimation approaches may be necessary for initial scoping, but should rapidly be replaced by empirical observation of Team output capacity (velocity). Avoid false precision to avoid false expectations.
- 76. 99 1. USE MORE THAN ONE PERSON. BY ENGAGING THE TEAM IN THE ESTIMATION PROCESS, WE GAIN THE BENEFITS OF ADDITIONAL INSIGHTS AND CONSENSUS BUILDING. 2. USE MORE THAN ONE APPROACH. USE MULTIPLE ESTIMATION APPROACHES (COMPARISON TO SIMILAR PROJECTS, BOTTOM UP, USER STORY POINTS, ETC.) AND LOOK FOR CONVERGENCE BETWEEN MULTIPLE APPROACHES TO REINFORCE LIKELY ESTIMATE RANGES. 3. AGREE ON WHAT “IT” AND “DONE” MEANS. MAKE SURE EVERYONE IS ESTIMATING IN THE SAME UNITS, HAVE THE SAME ASSUMPTIONS AND ARE BASED ON STANDARD DEVELOPER ABILITY/EFFORT. 4. KNOW WHEN TO STOP. BALANCE ESTIMATION EFFORT AGAINST THE DIMINISHING RETURNS AND FALSE ACCURACIES OF OVER ANALYSIS. 5. PRESENT ESTIMATES AS A RANGE. ESTIMATES ARE OFTEN POOR PREDICTIONS, AND SHOULD BE NOTED AS SUCH. 6. DEFEND/EXPLAIN ESTIMATE RANGE PROBABILITIES. EDUCATE STAKEHOLDERS ABOUT THE RELATIVE LIKELIHOOD OF HITTING OPTIMISTIC/PESSIMISTIC ESTIMATES. 7. DON’T RESERVE ESTIMATING FOR WHEN YOU KNOW LEAST ABOUT THE PROJECT. ESTIMATION SHOULD NOT BE RESERVED FOR ONLY THE BEGINNING OF PROJECTS. 8. BE AWARE OF COMMON ESTIMATION OMISSIONS. DON’T OVERLOOK COMMONLY MISSED TASKS, AND USE RETROSPECTIVES TO INSPECT PROJECT-SPECIFIC ISSUES. 9. EMBRACE REALITY EARLY. DON’T UNDER-ESTIMATE THE LOAD OF MAINTAINING AND REFACTORING A GROWING CODEBASE. 10.REVIEW, REVISIT, REMOVE HEAD FROM SAND, REPEAT. ADJUST PROJECT FORECAST BASED ON EMPIRICAL AGILE ESTIMATION ESSENTIALS
- 77. 100 PARTICIPANTS: WHOLE TEAM MULTI-TEAM ENVIRONMENT: WORK TOGETHER! PROCESS: CARDS ARE PLACED IN A STACK ON THE TABLE • PRODUCT OWNER EXPLAINS THE TOP CARD • FIRST TEAM MEMBER PLACES THIS CARD ON TABLE BY SIZE (LEFT SMALLER, RIGHT LARGER) • NEXT TEAM MEMBER EITHER REPEATS PROCESS WITH NEXT CARD, OR MOVES AN EXISTING CARD TO A NEW POSITION, WITH AN ASSOCIATED EXPLANATION • PROCESS REPEATS UNTIL ALL CARDS ARE PLACED AND GROUPED, AND NO MORE MOVEMENT IS DESIRED • EACH GROUP IS LABELED WITH ITS ESTIMATE AFFINITY ESTIMATING Smaller Larger
- 78. 101 • CLIFFORD THE BIG RED DOG • MARMADUKE • ENGLISH BULLDOG • CHIHUAHUA • PUG • SCOOBY-DOO • GREAT DANE EXERCISE – RELATIVE DOG SIZING Rules Point Estimating: Team decides scale Discuss criteria for complexity Find the reference point Estimate size for remaining items Based on Mike Cohn’s dog points
- 79. 102 “PLANNING POKER” IS BASED ON “WIDEBAND DELPHI” CONVERGENT ESTIMATION TECHNIQUES. HOW TO DO IT: 1. EACH ESTIMATOR (SOMEONE WHO COULD POSSIBLY BE DOING THE WORK IN QUESTION) IS GIVEN A DECK OF CARDS, EACH CARD HAS A VALID ESTIMATE WRITTEN ON IT 2. A MODERATOR READS A STORY AND IT’S DISCUSSED BRIEFLY 3. EACH ESTIMATOR SELECTS A CARD TO REPRESENT HER ESTIMATE 4. CARDS ARE TURNED OVER SO ALL CAN SEE THEM 5. DISCUSS DIFFERENCES (ESPECIALLY OUTLIERS) 6. RE-ESTIMATE UNTIL ESTIMATES CONVERGE (OR DON’T!) AGILE ESTIMATION – PLANNING POKER
- 80. 103 5 PLANNING POKER EXAMPLE 55Bill (Dev) 52Ann (BA) 58Vijay (QA) 33Susan (Dev) Round 2Round 1Estimator
- 81. Scrum
- 82. 105 SCRUM – 50,000 FOOT VIEW Release Planning Sprint Planning Sprint Review Sprint Retrospectiv e
- 83. 106 THERE ARE ONLY THREE ROLES DEFINED IN SCRUM: SCRUM ROLES & RESPONSIBILITIES Product Owner •Owns Product vision •Defines features, decides on release date and content •Responsible for market success •Prioritizes features according to market value •Can change features and priorities every Sprint ScrumMaster •Responsible for facilitating process •Focuses Team and protects them from external interruption •Looks for ways to enhance productivity •Assists Product Owner in leveraging Scrum The Team •Small group containing all necessary project skills •Focuses on steady delivery of high quality features •Generates options for delivery •Manages own work within Sprints
- 84. 107 • PRODUCT BACKLOG PRIORITIZED LIST OF VALUABLE ITEMS TO DELIVER DURING THE PROJECT. • SPRINT BACKLOG LIST OF COMMITTED ITEMS TO BE ADDRESSED WITHIN A SPRINT. • BURNDOWN/BURN-UP CHART VISUAL AID FOR TRACKING TEAM PROGRESS AND FORECASTING EXPECTED COMPLETION DATES. • VELOCITY CHART TRACKS RATE OF FEATURE COMPLETION. ARTIFACTS OF SCRUM
- 85. 108 SCRUM MILESTONES Product Backlog • ____________ • ____________ • ____________ • ____________ • ____________ F3 F6 Release 1 F1, F2, F3 Release 2 F1, F2, F3 F4, F5, F6 Initial Planning Release Planning Release Planning F1 F2 F2 F1 F4 F5F3 U S 1 U S 2 U S 3 U S 4 U S 5 U S 6 U S 7 U S 8 U S 1 U S 2 U S 3 U S 4 U S 5 U S 6 U S 7 U S 8 Release Planning Sprint Backlo g • ______ • ______ Sprint Backlo g • ______ • ______ Sprint Backlo g • ______ • ______ Sprint Backlo g • ______ • ______ Sprint Backlo g • ______ • ______ Sprint Backlo g • ______ • ______ Sprint Planning Sprint Planning Sprint Planning Sprint Planning Sprint Planning Sprint Planning
- 86. AGILE PRINCIPLES (1/2) 1. Value oriented: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Flexibility: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Iterative: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Team: Business people and developers must work together daily throughout the project. 5. Team: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. Team/Communication: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- 87. AGILE PRINCIPLES (2/2) 7. Communication: Working software is the primary measure of progress. 8. Communication: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Quality: Continuous attention to technical excellence and good design enhances agility. 10.Quality: Simplicity-the art of maximizing the amount of work not done-is essential. 11.Team: The best architectures, requirements, and designs emerge from self-organizing teams. 12.Retrospective: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
- 89. AGILE METHODOLOGY - SUMMARY Strengths Weaknesses Scrum Complements existing practices. Priorities based on business value. Self organizing teams and feedback. Customer participation and steering. Only approach that has a certification process. Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement. Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach in the US Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns. FDD Supports multiple teams working in parallel. All aspects of a project tracked by feature. Scales to large teams or projects well. Design by feature and build by feature aspects are easy to understand and adopt. Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models. 看板 Kanban Changes can be made any time Remove activities that don’t add value Scalable No prescribed roles No time boxing notion Limit WIP Based on what you do today Cross-functional teams. Complements existing practices. Does not specify technical practices. Requires constant gathering of metrics which may be
- 90. AGILE METHODOLOGY - SUMMARY Strengths Weaknesses AUP Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. Higher levels of ceremony may be a hindrance in smaller projects. Documentation is much more formal than most approaches mentioned here. Minimal attention to team dynamics. Crysta l Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. An emphasis on testing is so strong that at least one tester is expected to be on each project team. The "human" component has been considered for every aspect of the project support structure. Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible. DSDM An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Specific approach to determining how important each requirement is to an iteration. Set stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. Probably the most heavyweight project Defines several artifacts and work products for each phase of the project; heavier documentation. Expects continuous user involvement. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
- 91. METHODOLOGIES MOTTO Methodology Summarizing Phrase Scrum Prioritized Business Value XP Simplicity FDD Business Model AUP Manage Risk Crystal Size and Criticality DSDM Current Business Value Lean Return on Investment (ROI) – Eliminating waste Kanban Work In Process (WIP)
- 92. ROLES 3 MAIN ROLES • TEAM LEAD (SCRUM MASTER) • PRODUCT LEAD • THE TEAM OTHER PERIPHERAL ROLES • SPONSOR • EXPERTS Team Lead Product Lead The team Scrum Scrum Master Product Owner Different roles XP Big boss Customer Programmer, Tracker, Tester AUP Project Manager architect Crysta l Project Manager Business expert lead enginneer, designer, programmer, tester, writer DSDM Project Manager ambassador User Advisor User, Technical coordinator, Team leader, tester, scribe, facilitator, FDD Project Manager Chief programmer, programers, testers, Class Owner, Domain expert, chief architect
- 93. AGILE PROCESS OVERVIEW Envision •Vision •NPV •ROI Initiation •Identify Personas •Create backlog •High level estimates •Create roadmap Release Planning •Slicing stories •Stories estimatio ns •Create release plan Iteration 0 •Spikes •Detailing Next iteration stories Iteration •Iteration planing •Coding •Testing •Daily stand- ups & Updating burn-ups •Iteration review •Retrospective •Preparing stories for Next iteration Closing •Project close out •Finishing contracts •Resource release IT Edge 116PMI-Pub 3 December 2014
- 94. 117 AGILE MANIFESTO PRINCIPLES Satisfy the Customer Welcome Change Deliver Frequently Collaborate Daily Support & Trust Motivated Teams Promote Face-to-Face Conversations Deliver Working Software Promote Sustainable Pace Promote Technical Excellence Maximize Through Simplicity Have Self-Organized Teams Reflect & Adjust Regularly Source: www.agilemanifesto.org