COMP319 Agile Methodologies: Structured Knowledge Guide¶
Part 1: Introduction to Agile¶
1.1 Historical Context¶
1.1.1 Origin & Timeline - Origin Year: 1999-2000 - Origin Person: Kent Beck (American software developer) - Key Background: Worked extensively with Smalltalk programming language - Formal Documentation: Agile Manifesto published in 2001
1.1.2 Not Entirely New - Pair programming already existed in early 1990s (embedded systems) - Agile formalized practices that were already happening informally - Kent Beck's contribution: Codification and documentation of best practices
1.1.3 Key Contributions by Kent Beck - Created SUnit (unit testing framework for Smalltalk) - Spawned JUnit and other framework family members - Collaborated with Eric Gamma on design patterns - Developed xUnit testing frameworks concept
1.2 What is Agile?¶
1.2.1 Core Definition Agile is an iterative development approach emphasizing: - Rapid delivery of working software - Flexibility in changing requirements - Continuous stakeholder collaboration - Regular evaluation and adaptation
1.2.2 Why Agile Matters - Widely adopted in industry (valuable skill for engineers) - Reduces project overrun risk (time & cost) - Improves code quality (verification & validation) - Addresses process-related project failures
Part 2: Agile Manifesto & Principles¶
2.1 The Four Core Values¶
2.1.1 Individuals and Interactions over Processes and Tools - Focus: Human collaboration, not rigid processes - Implementation: Work together with customers and developers - Interaction Style: Highly interactive manner
2.1.2 Working Software over Comprehensive Documentation - Focus: Functional, deliverable code - Documentation Approach: Embedded through design patterns (e.g., Javadoc) - Code Quality: Self-documenting through clear structure
2.1.3 Customer Collaboration over Contract Negotiation - Perspective: Collaborative process (not adversarial) - Conditions: Most effective when customer is in-house - Modern Reality: Easier with tools showing prototypes via websites
2.1.4 Responding to Change over Following a Plan - Reality: Software requirements are mutable - Key Ability: Respond quickly to changes - Outcome: Produces high-quality code
2.2 The Twelve Agile Principles¶
2.2.1 First Six Principles 1. Customer satisfaction by rapid delivery of useful software 2. Welcome changing requirements, even late in development 3. Working software delivered frequently (weeks rather than months) 4. Working software is the principal measure of progress 5. Sustainable development, maintaining constant pace 6. Face-to-face conversation is best communication (co-location)
2.2.2 Last Six Principles 7. Projects built around motivated, trusted individuals 8. Continuous attention to technical excellence and good design 9. Simplicity - maximize work not done 10. Self-organizing teams 11. Regular adaptation to changing circumstances 12. Best architectures emerge from self-organizing teams
Part 3: Extreme Programming (XP)¶
3.1 XP Overview¶
3.1.1 Definition - Iterative development approach with main focus on code development - Philosophy: Assumes system will have flaws - Feature Implementation: Only when satisfying real business need
3.1.2 Core Concept - Deliver code rapidly with minimal upfront design - Code quality through intensive testing - Design emerges through refactoring
3.2 User Stories: The INVEST Model 🎯 [HIGH FREQUENCY EXAM POINT]¶
3.2.1 Standard Format
3.2.2 Practical Examples - Example 1: "As a registered patient, I want to login with username/password, so I can access records securely" - Example 2: "As a user closing the application, I want to save prompts, so I can preserve useful work"
3.2.3 Independent - Characteristic 1
3.2.3.1 Definition - Each story implementable without reliance on other stories - Stand and fall on their own merit
3.2.3.2 Benefits - Parallel development possible - Faster with more developers - Reduced code coupling - Loosely coupled codebase (good for quality)
3.2.3.3 Practical Application - Login and "Forgot Password" should be separate stories - Password reminder NOT part of login story - Only relationship: URL link between them - No actual coding dependency
3.2.4 Negotiable - Characteristic 2
3.2.4.1 Definition - Not all original spec needs exact implementation - Negotiation between stakeholder and development team
3.2.4.2 Stakeholder Benefits - Software at cheaper price - Useful working product on time - Flexibility in feature set
3.2.4.3 Negotiation Types - Remove/change aspects for quicker implementation - Add/change functionality for more value - Deprioritize difficult but unimportant features
3.2.5 Valuable - Characteristic 3
3.2.5.1 Definition - Each story demonstrates clear stakeholder value - Customer can observe delivered value as project completes
3.2.5.2 How to Handle Supporting Logic - Wrap supporting code into story points - Example: "All user data securely saved after every transaction" - Make infrastructure work visible as customer value
3.2.5.3 Value Metrics - Assign value on 1-10 scale - Core essential features = 10 - Lower priority features = lower value
3.2.6 Estimable - Characteristic 4
3.2.6.1 Definition - Amount of work required must be estimable
3.2.6.2 Conditions for Easier Estimation - Shorter user stories - Well-understood code - Less unknown code involved - Clear developer understanding
3.2.6.3 Strategy - Split large stories for better estimation
3.2.7 Small - Characteristic 5
3.2.7.1 Best Practice - No more than 2 days development per story - If story takes 2 weeks, won't know about overrun for 2 weeks - Early detection of problems critical
3.2.7.2 Benefits of Small Stories - Easier timescale estimation - Risk reduction (early overrun detection) - Clear progress measurement - Simpler, easier-to-test code - Code coherence maintenance - Faster delivery with parallelization
3.2.7.3 Pragmatic Example - Login screen story: separate from password reset - Each can be 1-2 days work - Clear, testable, parallel-able
3.2.8 Testable - Characteristic 6
3.2.8.1 Definition - Must be objectively testable - Quality assurance can be objective
3.2.8.2 Good vs Poor Examples - ❌ Poor: "Login screen must look nice and be liked by users" (subjective) - ✅ Good: "Login screen scores >7/10 when assessed by 20 test users" (objective) - ✅ Automatable: "Username: 8+ chars, 1+ upper/lowercase" → JUnit test
3.2.9 Story Points 📊
3.2.9.1 Definition - Estimate of story size/effort in development time - Relative estimation for specific team/environment - Can be estimated using Planning Poker
3.2.9.2 Calculation Method - A 10-point story = ~2x effort of 5-point story - Conditions: Same team, same conditions, no dependencies
3.2.9.3 Usage Purpose - Useful for whole project planning (not individual stories) - Velocity tracking across sprints
3.3 XP Process Flow¶
3.3.1 Phase 1: Planning
3.3.1.1 User Story Creation - Customers and developers collaborate - Write user stories together - Specify requirements in story format
3.3.1.2 Estimation - Developers estimate each story - Consider effort and complexity
3.3.1.3 Prioritization - Stakeholders prioritize stories - Identify high-priority vs low-priority
3.3.1.4 Project Planning - Create overall project plan - Set delivery schedule - Determine iteration length
3.3.2 Phase 2: Development Ordering
3.3.2.1 Priority Sequence 1. Dependent core code (foundational) 2. Smaller high-priority stories 3. Larger high-priority stories 4. Lower priority small stories 5. Lower priority larger stories
3.3.2.2 Rationale - Allows discarding less important code if time runs out - Ensures critical functionality done first - Minimizes wasted effort on low-value items
3.3.3 Phase 3: Development
3.3.3.1 Release Schedule - Software released regularly (weekly/fortnightly) - Consistent delivery rhythm
3.3.3.2 Testing Strategy
3.3.3.2.1 Unit Tests - Developed by development team - Run as automated testing - Test-Driven Development (TDD) approach
3.3.3.2.2 Acceptance Tests - Specified by customer - Can be script format (user input, expected output) - Ideally automated (e.g., Selenium for web)
3.3.3.3 Code Integration - New code integrated into system - New system release built - Release becomes new working system
3.3.4 Phase 4: Quality Gates 🎯 [HIGH FREQUENCY EXAM POINT]
3.3.4.1 High-Priority Code Testing Requirement - ALL high-priority core code must be fully tested - Testing must be completed before low-priority development
3.3.4.2 Completeness Definition - Code is INCOMPLETE if not fully tested and debugged - Only fully tested code is considered complete - No untested code presented in release
3.3.4.3 Why This Matters - Prevents incomplete work from affecting next iteration - Maintains code reliability - Ensures customer receives quality product
3.4 Pair Programming in XP¶
3.4.1 Definition - Two programmers work together on same task
3.4.2 Role Division - Driver: Writes code at keyboard - Observer: Reviews code, makes suggestions
3.4.3 Practice - Regular role swapping to prevent fatigue - Continuous collaboration on single task
3.4.4 Benefits - Reduces poor-quality code - Spreads code ownership - Increases knowledge sharing
3.5 XP Criticisms¶
3.5.1 Feature Creep Problem
3.5.1.1 Definition - On-site customer requests continuous changes - Scope expansion without control
3.5.1.2 Consequences - Uncontrolled scope expansion - Timeline pressure - Cost increases
3.5.2 Time/Cost Overrun Risk
3.5.2.1 Why It Happens - Flexible requirements make completion unpredictable - Scope changes affect timeline
3.5.2.2 Impact - Budget overruns - Delivery delays - Stakeholder dissatisfaction
3.5.3 No Upfront Design Problem
3.5.3.1 General Issue - Minimal design before coding - Design emerges during coding
3.5.3.2 Database Design Vulnerability ⚠️ - Particularly risky domain - Early coding decisions constrain later development - Changing database structure very expensive - Can lead to design contradictions
3.5.3.3 Refactoring Overhead - Constant code changes require frequent refactoring - Increases development overhead - Risk of breaking existing code - Requires excellent refactoring tools
3.5.4 Other Criticisms
3.5.4.1 On-Site Customer - Ideal but often not feasible - When available, contributes to feature creep
3.5.4.2 Limited Documentation - Lower documentation emphasis - Self-documenting code difficult to achieve - Higher communication overhead - Onboarding new developers challenging
3.5.4.3 Code Quality Trade-off - Design patterns add complexity vs. simplicity goal - Balance needed between flexibility and simplicity
Part 4: Scrum Methodology¶
4.1 History & Origins¶
4.1.1 Timeline - Developed: 1986 by Hirotaka Takeuchi & Ikujiro Nonaka
4.1.2 Inspiration Source - Manufacturing best practices - Examples: Cameras, photocopiers, PCs - Observation of how teams worked effectively
4.1.3 Key Shift - From: Sequential development - To: Iterative development toward final product
4.1.4 Core Concept - Name from rugby: Team works together in structured stages - Each iteration moves team closer to goal
4.2 Scrum Fundamentals¶
4.2.1 Definition - Splits development into sprints (iterations) - Each sprint typically 1-4 weeks - Each sprint produces deliverable, user-testable product
4.2.2 Time-Boxing - Hard end dates for sprints - Fixed duration (no extensions) - Discipline through time constraints
4.2.3 Deliverable Standard - If function incomplete/untested → NOT presented in product - Only complete, tested work included in release
4.3 Scrum Roles 🎯 [EXAM FOCUS]¶
4.3.1 Product Owner
4.3.1.1 Responsibilities - Liaises with all stakeholders - Maintains product backlog - Prioritizes features - Makes feature inclusion decisions
4.3.1.2 Interface Role - Bridge between stakeholders and team - Communicates customer needs
4.3.2 Development Team
4.3.2.1 Characteristics - Self-organizing group - Cross-functional with necessary skills - Responsible for estimation and execution
4.3.2.2 Task Assignment - Volunteer (self-nominate) for tasks - NOT assigned by management - Team decides work allocation
4.3.2.3 Size - Typically 5-9 people - Large enough for complexity, small enough for coordination
4.3.3 Scrum Master 🎯 [CRITICAL EXAM FOCUS]
4.3.3.1 What Scrum Master is NOT - ❌ NOT a people manager - ❌ NOT a traditional project manager - ❌ NOT a task assigner - ❌ NOT a command-and-control leader
4.3.3.2 What Scrum Master IS
4.3.3.2.1 Facilitator Role - Facilitates Scrum process - Ensures day-to-day practices happen
4.3.3.2.2 Obstacle Remover - Removes obstacles blocking team progress - Identifies and eliminates impediments - Clears communication barriers
4.3.3.2.3 Meeting Manager - Manages daily scrum meetings - Ensures 15-minute timeframe - Keeps meetings focused
4.3.3.2.4 Enabler - Enables team self-organization - Supports team autonomy - Protects team from external disruption
4.3.3.2.5 Communicator - Acts as bridge between team and management - Communicates team progress - Represents team to stakeholders
4.3.3.2.6 Planner - Builds release plan - Helps coordinate long-term delivery
4.3.3.2.7 Gatekeeper - Controls sprint commitment - Prevents over-commitment of work - Ensures realistic workload
4.4 Scrum Artifacts¶
4.4.1 Product Backlog
4.4.1.1 Definition - Maintained throughout entire project - Central repository of all work
4.4.1.2 Contents - Product features (functional requirements) - Debugging tasks (bug fixes) - Technical tasks (refactoring, infrastructure) - ANY work needed to complete product
4.4.1.3 Item Components - Description/specification - Business value score - Effort estimate (from development team)
4.4.1.4 Dynamic Characteristics - Continuously updated - Features prioritized by importance - Can grow/shrink based on discovery - Product Owner manages changes
4.4.2 Sprint Backlog
4.4.2.1 Definition - Work selected for current sprint - Subset of product backlog
4.4.2.2 Task Characteristics - Each task typically 4-16 hours - Smaller tasks = better tracking - Larger tasks = risk of spillover
4.4.2.3 Assignment Method - Developers sign up (self-selection) - NOT assigned by Scrum Master/manager - Enables ownership
4.4.3 Burn Down Charts 📊
4.4.3.1 Sprint Burn Down Chart
4.4.3.1.1 Purpose - Track sprint progress over time - Visual indication of productivity - Identify pace issues early
4.4.3.1.2 Components - X-axis: Days in sprint - Y-axis: Remaining effort (story points or hours) - Ideal line: Steady decline from start to zero - Actual line: May show variations
4.4.3.1.3 Typical Pattern - Day 1-3: Steady decline (tasks completed) - Day 4: Spike upward (testing found issues, items back to backlog) - Day 5+: Resume decline - End: May not reach zero (incomplete items acceptable)
4.4.3.1.4 Why Realistic Charts Don't End at Zero - Incomplete items returned to backlog - Testing discovers defects requiring rework - Unexpected complexities emerge - This is normal in agile
4.4.3.1.5 Use for Team - Assess sprint velocity - Identify if on track - Plan corrective action early
4.4.3.2 Release Burn Down Chart
4.4.3.2.1 Purpose - Track progress across MULTIPLE sprints - Visualize journey toward release
4.4.3.2.2 What It Shows - Iterations through weeks/sprints - Overall progress toward completion - Realistic release date prediction
4.4.3.2.3 Utility - Allows interpolation to estimate release date - Shows if team ahead/behind schedule - Guides final delivery planning - Helps stakeholder communication
4.5 Scrum Events¶
4.5.1 Daily Scrum (Daily Stand-up) 🎯 [HIGH FREQUENCY EXAM POINT]
4.5.1.1 Timing - Start of working day - Consistent time daily
4.5.1.2 Duration - 15 minutes maximum (time-boxed strictly) - No longer discussions held separately
4.5.1.3 Participants - Development team members - Scrum Master (facilitator, not participant) - Optional: Product Owner
4.5.1.4 Three Questions Each Developer Answers 1. What did I complete since yesterday? 2. What am I planning to do today? 3. What impediments/stumbling blocks are blocking me?
4.5.1.5 Focus & Purpose - Synchronize team activities - Identify and remove obstacles - Maintain transparency - Plan day's work - NOT detailed technical discussions - NOT status report to management
4.5.2 Sprint Planning Meeting
4.5.2.1 Participants - Product Owner - Scrum Master (facilitator) - Development Team
4.5.2.2 Purpose - Decide scope of work for upcoming sprint - Create sprint backlog
4.5.2.3 Activities
4.5.2.3.1 Backlog Review - Product Owner presents prioritized backlog - Customer review: Add/remove features - Discuss high-level requirements
4.5.2.3.2 Work Selection - Team pulls high-priority items - Amount carefully selected to fill sprint - Based on velocity from previous sprints
4.5.2.3.3 Estimation - Team estimates effort for selected items
4.5.2.3.4 Planning - Create sprint backlog with tasks - Plan sprint execution - Identify dependencies
4.5.2.4 Duration - Typically 2-4 hours for 2-week sprint - Proportional to sprint length
4.5.2.5 Output - Sprint backlog created - Sprint goal defined - Team committed to sprint plan
4.5.3 Sprint Review Meeting
4.5.3.1 Timing - End of sprint - Before retrospective
4.5.3.2 Purpose - Demonstrate completed work - Gather stakeholder feedback - Plan future work
4.5.3.3 Activities - Team demonstrates working product - Customer/stakeholders review - Gather acceptance and feedback - Review product backlog for future
4.5.3.4 Outcome - Updated product backlog - Reprioritized features - Customer acceptance/feedback
4.5.4 Sprint Retrospective
4.5.4.1 Timing - After sprint review - End of sprint cycle
4.5.4.2 Purpose - Team reflection on process - Continuous improvement
4.5.4.3 Discussion Points - What went well in sprint? - What could be improved? - What will we change next sprint?
4.5.4.4 Outcome - Process improvements identified - Action items for next sprint - Team buy-in to changes
4.6 Scrum Workflow Overview¶
4.6.1 Complete Scrum Cycle
1. Product Backlog Created
↓
2. Sprint Planning Meeting
↓
3. Sprint Backlog Created
↓
4. Daily Sprints (1-4 weeks)
- Daily standup meetings
- Team develops features
- Tasks removed from backlog as completed
- Burn down chart updated daily
↓
5. Sprint Review Meeting
- Demonstrate completed work
- Gather feedback
↓
6. Sprint Retrospective
- Team reflects on process
- Identify improvements
↓
7. Product Backlog Updated
- New items added
- Priorities adjusted based on feedback
↓
8. Next Sprint Planning
↓
[REPEAT until release or project completion]
Part 5: Pair Programming 🎯 [PARTICULARLY REQUIRED FOR EXAM]¶
5.1 Definition & Practice¶
5.1.1 Basic Setup - Two programmers work together on same programming task - Single workstation (shared keyboard/mouse)
5.1.2 Role Division
5.1.2.1 Driver - Writes code at keyboard - Focused on immediate implementation - Tactical thinking
5.1.2.2 Observer (Navigator) - Reviews code being written - Makes suggestions for improvement - Thinks about bigger picture - Strategic thinking
5.1.2.3 Role Rotation - Swap roles regularly to prevent fatigue - Prevents single person getting tired - Ensures both maintain engagement
5.2 Benefits of Pair Programming¶
5.2.1 Risk Reduction
5.2.1.1 Design Error Prevention - Chance of design error passing two programmers << one programmer - Two minds catch more issues
5.2.1.2 Code Quality - Pair member less likely to implement structural "hacks" - Pressure to write clean, understandable code - Observer reviews code during production (not after)
5.2.1.3 Impact - Reduces serious flaws - Catches errors early
5.2.2 Code Quality Improvement
5.2.2.1 Poor Code Reduction - Reduces poor-quality, uncommented code - Observer forces code clarity - If observer doesn't understand → driver must improve
5.2.2.2 Commenting & Documentation - Better-commented code (observer asks questions) - Self-documenting through clarity - Professional code quality
5.2.3 Collective Code Ownership 🎯 [IMPORTANT CONCEPT]
5.2.3.1 Definition - Responsibility for code spread across developers - Not "John's code" or "Mary's code" - "Our code"
5.2.3.2 Benefits - Any team member can modify code - Any team member can debug code - Any team member can improve code - Flexibility in work assignments
5.2.3.3 Practical Impact - If programmer ill → partner continues - Reduces project disruption - Increases team resilience
5.2.4 Knowledge Sharing
5.2.4.1 Deep Understanding - Both developers understand code deeply - Not just one person knows details
5.2.4.2 Spreading Knowledge - Spreads expertise across team - Trains developers in company practices - Onboarding new developers faster
5.3 The Bus Factor Problem ⚠️ [CRITICAL CONCEPT]¶
5.3.1 Definition
5.3.1.1 Concept - "How many developers can be hit by bus before project halts?"
5.3.1.2 Examples - Bus factor 1: Only one person knows critical code - Bus factor 2: Two people know critical code - Bus factor 10: Ten people understand critical code
5.3.1.3 Why It Matters - High bus factor = project resilience - Low bus factor = project risk - Pair programming increases bus factor
5.3.2 Why Pair Programming Increases Bus Factor
5.3.2.1 Knowledge Distribution - Two people know code instead of one - Reduces single-person dependency - Spreads understanding
5.3.2.2 When One Person Leaves - Knowledge doesn't disappear - Partner can continue work - Project continues
5.3.3 Other Approaches to Increase Bus Factor
3.3.3.1 Code Documentation - Improve code documentation - Make code self-documenting - Javadoc and comments
3.3.3.2 Design Improvements - Better class design (inheritance hierarchy) - Reduce class size - Clear, modular structure
3.3.3.3 Testing - Implement automated testing - Tests serve as documentation - Tests ensure code reliability
3.3.3.4 Code Review - Use formal code review process - Multiple people see code - Spread understanding
3.3.3.5 Code Movement Between Developers - Rotate code assignments - Developer A: Initial implementation - Developer B: Debug and modifications - Developer A: Continue debugging and enhancements - Over time: Multiple people know all code
5.4 Mentor Pair Programming¶
5.4.1 Definition - Advanced form of pair programming - Used for training/onboarding
5.4.2 Structure
5.4.2.1 Lead Programmer (Mentor) - Solves problems in company domain - Demonstrates best practices - Shows how to approach problems
5.4.2.2 Trainee Programmer - Observes solution process - Asks questions - Makes suggestions - Gradually takes over development - Learns by doing
5.4.3 What Trainee Learns
5.4.3.1 Company Practices - Company coding standards - In-house style guides - Company conventions
5.4.3.2 Company APIs - How to use company libraries - Common patterns in codebase - Where to find documentation
5.4.3.3 Problem Domain - Domain-specific issues - Business constraints - Customer requirements - Industry standards
5.4.4 Value - Rapid onboarding - New developer masters practices quickly - Knowledge transfer efficient - Builds team cohesion
5.5 Pair Programming Criticisms & Challenges¶
5.5.1 Skill Matching Problems
5.5.1.1 Low Skill + Low Skill - Two inexperienced programmers - Limited improvement for each other - May reinforce bad practices - High error rate
5.5.1.2 Low Skill + High Skill - Skill mismatch - Low-skilled programmer may not effectively review high-skilled work - Risk: Low-skilled feels intimidated or bored - Risk: High-skilled programmer loses patience - Difficult dynamic
5.5.1.3 High Skill + High Skill - Skilled programmers may debate design extensively - Protracted discussions delay coding - Over-engineering solutions common - Ego clashes possible
5.5.2 Not Substitute for Code Review
5.5.2.1 Why Different - Timing: Both developers must be available simultaneously - Code review: Can be async, offline - Different review dynamics - Code review catches different issues
5.5.2.2 Practical Issue - Can't force pairing all time - Logistics difficult for large teams - Code review complements but doesn't replace pairing
5.5.3 Personal Issues
5.5.3.1 Common Problems - Personality clashes - Different work habits - Eating habits / hygiene issues - Phone interruptions - Ego conflicts - Comfort with sharing physical space
5.5.3.2 Impact - Makes pairing uncomfortable - Reduces effectiveness - May require personnel changes
5.5.4 Cost Considerations
5.5.4.1 Labor Cost - Doubles labor cost on paired tasks - Two salaries for same output - Budget constraint
5.5.4.2 Opportunity Cost - Could have two developers working on separate features - Parallel development vs collaborative development
5.5.5 Equipment & Space - Requires shared workstation - Physical proximity needed - Remote pairing difficult - Infrastructure cost
Part 6: Pair Programming Research Findings 📊 🎯 [EXAM CRITICAL]¶
6.1 Williams et al. (2000) - University of Utah Study¶
6.1.1 Research Setup - Institution: University of Utah - Year: 2000 - Study Type: Empirical comparison of pair vs solo programming
6.1.2 Key Findings - Time Metrics
| Metric | Finding | Interpretation |
|---|---|---|
| Time to Develop | 15-30% decrease | Coding FASTER with pairs |
| Programmer Hours | 15-60% increase | More total labor invested |
| Net Conclusion | Higher labor cost despite faster completion | Cost-benefit trade-off |
6.1.3 Key Findings - Quality Metrics
| Metric | Finding | Interpretation |
|---|---|---|
| Correctness | 15% improvement | Fewer bugs produced |
| Code Quality | Higher overall | Better code structure |
| Defect Rate | Reduced | More reliable software |
6.1.4 Assessment - Higher quality, higher cost model - Critical for safety-critical projects - Healthcare/vehicle control benefit most
6.1.5 Developer Feedback 🎯 [MUST KNOW EXAM DATA]
| Response | Percentage | Quote |
|---|---|---|
| Problem-solving together | 74% | "Between my partner and I, we could figure everything out" |
| Motivation through accountability | 63% | "It was pair-pressure—I could not let my partner down" |
| Confidence in work | 95% | "I was more confident in our assignments because we pair programmed" |
6.1.6 Exam Relevance - Often asked: "What were Williams findings?" - Must remember: 15-30% time, 15% bugs, 74%/63%/95% quotes - High probability question: Pros/cons with research data
6.2 Arisholm, Gallis, & Sjøberg Study¶
6.2.1 Research Approach - Comparison across different contexts - Complex vs simple problems - Different skill level combinations
6.2.2 Time Findings
| Finding | Value | Context |
|---|---|---|
| Average time difference | 84% | Not significantly different |
| Actual time reduction | ~8% average | Smaller than Williams |
| For junior pairs | Larger time taken | Higher effort required |
| For complex tasks | Mixed results | Depends on problem type |
6.2.3 Quality Findings
| Category | Finding | Significance |
|---|---|---|
| Overall correctness | 7% improvement | Small but consistent |
| Junior correctness | 73% improvement | MAJOR benefit |
| Complex problems | Higher quality | Pairing helps complex tasks |
| Simple problems | Less benefit | Less advantage for easy work |
6.2.4 Effort Findings
| Group | Effort Increase | Issue |
|---|---|---|
| Overall | Moderate | Increased programmer hours |
| Junior pairs | 111% increase | Significant overhead for trainees |
| Mixed pairs | Variable | Depends on skill gap |
6.2.5 Key Conclusion - Particularly valuable for juniors - Higher quality for complex problems - Effort overhead significant for inexperienced pairs
6.3 Jo E. Hannay et al. - Meta-analysis¶
6.3.1 Research Type - Meta-analysis: Combined analysis of many studies - Comprehensive overview of pair programming effects
6.3.2 Time Findings
6.3.2.1 Overall Trend - Small reductions in time - Not consistent across all studies - Task complexity matters
6.3.2.2 Task Complexity Impact - Simple tasks: Greater time improvements - Complex tasks: Smaller time improvements (may increase) - Trade-off: Quality improves more for complex
6.3.3 Quality Findings
6.3.3.1 Key Finding - Higher quality results for complex problems ⭐ - More complex → more benefit from pairing
6.3.3.2 Why This Matters - Complex code → need for review - Pairing provides continuous review - Prevents architectural mistakes
6.3.4 Research Bias Discovery ⚠️
6.3.4.1 Finding - Detected research bias in favor of pair programming - Some leading researchers had bias in methodology - Some published results may be inflated
6.3.4.2 Implication - Some published claims overstated - Realistic benefits more modest - Meta-analysis attempts objectivity
6.3.5 Final Assessment - Results mixed overall - Clear benefits for complexity - Cost-benefit varies by context - Not universal solution
6.4 Molokken-Ostvold & Haugen - Planning Poker Study¶
6.4.1 Research Focus - Planning Poker effectiveness - Comparison with other estimation methods
6.4.2 Key Finding 📊 - Planning Poker estimates less optimistic AND more accurate - Compared to simple combination of individual estimates - Significantly more accurate for same tasks
6.4.3 Exam Relevance - Answers "Why use Planning Poker?" - Provides research evidence - Validates estimation approach
6.5 Research Summary Table 🎯¶
| Study | Focus | Key Finding | Exam Relevance |
|---|---|---|---|
| Williams 2000 | Time/Quality | 15-30% faster, 15% better quality, 74%/63%/95% feedback | ⭐⭐⭐ HIGH |
| Arisholm et al. | Context & skills | 73% improvement for juniors, 8% overall time | ⭐⭐ MEDIUM |
| Hannay et al. | Meta-analysis | Higher quality for complex, research bias detected | ⭐⭐ MEDIUM |
| Molokken-Ostvold | Estimation | Planning Poker more accurate | ⭐⭐ MEDIUM |
Part 7: Planning Poker (Scrum Poker)¶
7.1 Overview & Purpose¶
7.1.1 Definition - Consensus-based estimation technique - Uses collective team knowledge - Group intelligence approach
7.1.2 Usage Context - Integral part of Agile approaches (Scrum and XP) - Used for estimating user stories/features - Estimation team activity
7.1.3 Purpose - Estimate effort for work items - Generate story points for sizing - Create realistic project timelines
7.2 How Planning Poker Works: Step by Step¶
7.2.1 Step 1: Setup
7.2.1.1 Materials - Card pack with numbers for each team member - Typical sequence: Fibonacci (1, 2, 3, 5, 8, 13, 21, 34...) - Alternative: Standard playing cards (with modifications)
7.2.1.2 Preparation - Project manager/product owner prepares - Feature/user story to estimate selected - Team gathered (usually 5-10 people)
7.2.2 Step 2: Discussion
7.2.2.1 Story Presentation - Product owner explains feature/story - Context provided - Requirements discussed
7.2.2.2 Clarification Phase - Team asks clarifying questions - Assumptions discussed and documented - Potential risks identified
7.2.2.3 Technical Discussion - Debate complexity factors - Discuss technical approach options - Consider dependencies - Estimate effort implications
7.2.3 Step 3: Estimation
7.2.3.1 Individual Estimation - Each team member selects card - Represents their effort estimate - Based on their assessment
7.2.3.2 Card Placement - Card placed face down (hidden) - Prevents others seeing estimate - No influence from first person
7.2.3.3 Simultaneous Revelation - All cards revealed at same time - Everyone sees all estimates together - Prevents anchoring effect
7.2.4 Step 4: Consensus Building
7.2.4.1 Initial Discussion - Identify lowest and highest estimates - Estimators explain their reasoning - Why did they choose this number?
7.2.4.2 Group Discussion - Team discusses differences - Explore hidden assumptions - New information emerges
7.2.4.3 Another Round - Team re-estimates based on discussion - Repeat Steps 3-4 until consensus
7.2.4.4 Convergence - Continue rounds until: - All estimates same (perfect consensus) - Estimates converge (acceptable agreement) - Majority agreement reached
7.2.5 Step 5: Decision
7.2.5.1 Voice Distribution - Developers responsible for work get larger voice - Their input weighted more heavily - Expert opinion counts more
7.2.5.2 Final Estimate - May converge on middle ground - May converge on highest estimate (conservative) - Team commits to estimate
7.3 Benefits of Planning Poker¶
7.3.1 Avoids Anchoring Bias 🎯 [KEY CONCEPT]
7.3.1.1 Anchoring Definition - In open discussion, some advocate strongly for estimate - Others follow their lead - Crowd influenced by dominant voice
7.3.1.2 Who Anchors What - Low anchors (optimistic): Sales, marketing, product owners - Want faster delivery, lower cost - Influence others toward optimism - High anchors (pessimistic): Development team - Want buffer for reality - Influence others toward pessimism
7.3.1.3 How Poker Prevents This - Simultaneous card revelation - No discussion during estimation - Strong personalities can't influence - Everyone votes independently
7.3.2 Uses Group Intelligence
7.3.2.1 Concept - Team knowledge > individual knowledge - Combines perspectives - Different experiences help
7.3.2.2 Benefits - Catches overlooked complexity - Identifies risks individual missed - More realistic assessments - Group wisdom effect
7.3.3 Produces Less Optimistic Estimates
7.3.3.1 Research Evidence 📊 - Molokken-Ostvold & Haugen study shows: - Planning Poker estimates LESS optimistic - Planning Poker estimates MORE accurate - Compared to simple combination of individual estimates - Significantly more accurate for same tasks
7.3.3.2 Why Matters - Realistic estimates = better planning - Accurate timelines = better stakeholder management - Reduced surprises and overruns
7.3.4 Reduces Risk
7.3.4.1 Risk Reduction Mechanism - Realistic estimates → better project planning - Avoids over-commitment - Enables realistic scope management
7.3.4.2 Prevents - Unexpected project overruns - Unrealistic timeline commitments - Team burnout from over-commitment
7.3.4.3 Enables - Accurate forecasting - Reliable delivery predictions - Stakeholder confidence
7.4 Comparison with Other Estimation Methods¶
7.4.1 Open Discussion Method
7.4.1.1 Process - Team discusses item openly - Senior people speak first - Others follow lead
7.4.1.2 Problems - Subject to anchoring bias - Personality dominance - Less accurate due to group pressure
7.4.2 Individual Estimates Combined
7.4.2.1 Process - Each person estimates independently - Estimates combined (average/median) - No discussion
7.4.2.2 Issues - May be too optimistic - Influenced by marketing/sales pressure - Less accurate than poker
7.4.3 Planning Poker
7.4.3.1 Advantages - Balanced, consensus-based - Research-validated accuracy - Reduces optimism bias - Group intelligence leveraged
7.4.3.2 Why Better - Prevents anchoring - Includes all voices equally - Produces more realistic estimates
Part 8: Criticisms & Challenges of Agile¶
8.1 Contract and Cost Issues¶
8.1.1 Payment for Changes Problem ⚠️
8.1.1.1 Issue - Who pays when customers continuously modify requirements? - Scope creep → cost increases - Who bears additional cost?
8.1.1.2 Contract Type Problem - Fixed-price contracts clash with agile - Agile assumes changing requirements - Traditional contracts assume fixed scope
8.1.1.3 Solution - Time & Materials (T&M) contracts work better - Customer shares scope change cost - Less suitable for fixed contracts
8.1.1.4 Business Implication - May only be viable for certain contract types - Not suitable for all projects - Negotiation difficult
8.1.2 Cost Visibility Problem
8.1.2.1 Unpredictability - Ongoing changes make total cost hard to predict - Difficult to forecast final budget - Scope creep increases expense
8.1.2.2 Stakeholder Concern - Stakeholders may not accept cost increases - Budget constraints may force incomplete scope - Difficult to justify additional spending
8.2 Code Quality and Design Issues¶
8.2.1 Code Quality Without Upfront Design ⚠️
8.2.1.1 Problem - Working code emphasized over design documentation - Risk of technical debt accumulation - Poor initial architecture costly later
8.2.1.2 Long-term Cost - Design corrections expensive - Refactoring overhead increases - Legacy code problems emerge
8.2.1.3 Skill Requirement - May only work for highly skilled developers - Junior developers may not write quality code - Architecture emerges organically (not always good)
8.2.2 Database Design Particular Risk ⚠️ [CRITICAL EXAM POINT]
8.2.2.1 Why Database Critical - Schema decisions impact everything - Hard to change after implementation - Affects data access patterns - Constrains future development
8.2.2.2 Problems Without Upfront Design - Early coding decisions constrain database schema - Changing structure later very expensive - Data migration complicated - Can lead to design contradictions
8.2.2.3 Examples of Issues - Wrong data types chosen - Index planning missed - Relationship design flawed - Normalization not considered
8.2.2.4 Impact - Severe technical debt - Performance problems - Costly refactoring - Project delays
8.2.3 Documentation Deficiency
8.2.3.1 Lower Documentation Emphasis - Agile prioritizes working code - Documentation often secondary - Minimal documentation culture
8.2.3.2 Self-Documenting Code - Idea: Code structure self-explanatory - Practice: Difficult to achieve completely - Requires excellent coding practices
8.2.3.3 Communication Overhead - Increased communication required - More meetings necessary - Developers spend time explaining code - Higher communication cost
8.2.3.4 Onboarding Difficulty - New developers harder to onboard - Less documentation to reference - Steep learning curve - More dependent on senior developers
8.2.4 Refactoring Overhead
8.2.4.1 Why Refactoring Needed - Continuous code changes - Design improvements necessary - Prevent code decay
8.2.4.2 Cost - Increases development overhead - Takes time from new features - Risk of breaking existing code
8.2.4.3 Requirements - Excellent refactoring tools needed - Strong testing framework essential - Team discipline required
8.3 Managing Large Projects¶
8.3.1 Scalability Uncertainty
8.3.1.1 Question - How does agile scale to large projects? - Many teams coordination - Distributed across locations - Complex dependencies
8.3.1.2 Challenges - Face-to-face communication less effective - Multiple stakeholders conflict - Coordination overhead - Knowledge sharing difficult
8.3.2 Stakeholder Management
8.3.2.1 Multiple Stakeholders - Different stakeholders, different priorities - Conflicting requirements - Difficult to prioritize
8.3.2.2 On-Site Customer - Ideal: Customer always available - Reality: Often impossible for large organizations - Travel/relocation costs - Part-time availability only
8.3.2.3 Control Issue - Who controls prioritization? - Whose voice matters most? - How are conflicts resolved? - Unclear in complex scenarios
8.3.3 Feature Creep Control
8.3.3.1 Problem - Flexible requirements lead to scope expansion - Continuous feature requests - No clear project endpoint
8.3.3.2 Consequences - Time overruns - Cost overruns - Completion ambiguity - Team frustration
8.4 General Concerns¶
8.4.1 Does Agile Actually Work? ⚠️
8.4.1.1 Research Gaps - Limited empirical evidence for all practices - Some practices more proven than others - Context-dependent results
8.4.1.2 Variability - Different contexts produce different results - Not suitable for all project types - Success depends on team/environment
8.4.1.3 Hype vs Reality - Sometimes over-hyped in industry - Not silver bullet - Not appropriate everywhere
8.4.2 Team Composition Dependency
8.4.2.1 Skill Requirements - Success depends heavily on team skill level - Not suitable for junior-only teams - Requires experienced, self-disciplined members - Senior developers essential for guidance
8.4.2.2 Training Overhead - Team needs to learn agile practices - Training costs time - Practice period before effectiveness
8.4.3 Communication Overhead
8.4.3.1 Meetings & Standups - Daily meetings required - Meetings can become excessive - Time away from coding
8.4.3.2 Remote Teams - Face-to-face communication principle fails - Distributed teams struggle - Time zone differences problematic - Communication tools not as effective
Part 9: Key Takeaways & Exam Strategy¶
9.1 When Agile Works Well ✅¶
9.1.1 Project Characteristics - Rapidly changing requirements - Customer closely involved - Need for early feedback valuable - Complex problems needing iteration - Unknown solutions upfront
9.1.2 Team Characteristics - Skilled, experienced developers - Self-motivated team - Good communication - Co-located or close collaboration
9.1.3 Product Type - Web applications - Software products - Cloud services - Frequent updates needed
9.2 When Agile May Struggle ❌¶
9.2.1 Project Characteristics - Fixed requirements upfront - Regulated environments - Strict documentation mandated - Complex upfront design needed
9.2.2 Team Characteristics - Junior-only developer teams - Geographically distributed - Limited communication ability - Large teams (>100 people)
9.2.3 Product Type - Safety-critical systems - Embedded systems - Hardware-dependent systems - Medical devices requiring approval
9.3 Success Factors for Agile Implementation¶
9.3.1 Team Quality ⭐ - Experienced, self-motivated developers - Good communication skills - Problem-solving ability - Commitment to quality
9.3.2 Customer Engagement ⭐ - Available, responsive stakeholders - Clear business goals - Willingness to collaborate - Quick feedback cycles
9.3.3 Technical Practices ⭐ - Strong testing framework - Refactoring discipline - Design patterns usage - Code review process
9.3.4 Tools & Infrastructure ⭐ - Build automation - Testing frameworks (JUnit, etc.) - Version control - Continuous integration
9.3.5 Management Support ⭐ - Trust in team - Acceptance of changing plans - Support for continuous improvement - Resource allocation
9.3.6 Communication ⭐ - Effective collaboration mechanisms - Clear information sharing - Rapid feedback channels - Accessible decision makers
9.4 High-Frequency Exam Points 🎯 - PRIORITY 1: MUST KNOW¶
9.4.1 XP User Stories - INVEST Model - Independent - Negotiable - Valuable - Estimable - Small - Testable - Must be able to explain each characteristic with examples
9.4.2 Pair Programming Research - Williams et al. (2000): 15-30% faster, 15% better quality - Developer feedback: 74%, 63%, 95% key statistics - Hannay meta-analysis: Higher quality for complex problems - Research bias detected: Arisholm shows 73% improvement for juniors
9.4.3 Scrum Roles - Product Owner: Prioritization, backlog management - Development Team: Self-organizing, self-nominating - Scrum Master: Facilitator, obstacle remover, NOT manager - Differences between roles critical
9.4.4 Criticisms of Agile - Cost issues (who pays for changes?) - Database design risk without upfront design - Scalability concerns for large projects - Documentation deficiency
9.4.5 Daily Scrum - 15-minute timeframe - Three questions each person answers - Purpose: Synchronize, not status reporting
9.4.6 User Story Format
9.4.7 Bus Factor Concept - Definition: How many developers hit by bus before project halts? - Why pairing increases bus factor - Alternatives to increase (code review, documentation, testing)
9.4.8 Planning Poker - 5-step process - Avoids anchoring bias - Research shows less optimistic, more accurate estimates - Simultaneous card revelation key
9.5 Priority 2: IMPORTANT¶
9.5.1 Agile Manifesto - Four Values - Individuals & Interactions vs Processes & Tools - Working Software vs Documentation - Customer Collaboration vs Contract Negotiation - Responding to Change vs Following Plan
9.5.2 Burn Down Charts - Sprint: Daily tracking, shows velocity - Release: Multi-sprint, predicts completion - Realistic charts may not end at zero
9.5.3 Scrum Sprints - Duration: 1-4 weeks typically - Time-boxed strictly - Produces deliverable product
9.5.4 XP vs Scrum Comparison - Focus: XP = code quality, Scrum = project management - Primary unit: XP = user stories, Scrum = sprints - Testing: XP = TDD, Scrum = within sprint
9.6 Priority 3: SUPPORTING¶
9.6.1 12 Agile Principles - Nice to know, less frequently tested - Understand overall philosophy
9.6.2 Kent Beck's History - Created Extreme Programming - Developed testing frameworks - Collaborated on design patterns
9.6.3 Specific Research Data - Arisholm 73% improvement - Molokken-Ostvold planning poker study - Historical context of agile movement
9.7 Best Practices for Success¶
9.7.1 Coding Practices - Use pair programming for complex/critical code - Employ TDD consistently - Write self-documenting code - Refactor regularly but carefully
9.7.2 Project Management - Keep user stories small and independent - Use planning poker for objective estimation - Monitor burn-down charts for progress - Conduct regular retrospectives
9.7.3 Team Practices - Daily standups (15 minutes strictly) - Code reviews complement pairing - Collective code ownership - Knowledge sharing emphasis
9.7.4 Tools & Infrastructure - Unit testing frameworks (JUnit) - Automated testing (Selenium) - Version control - Continuous integration
Part 10: Summary Tables & Quick Reference¶
10.1 XP vs Scrum Comparison Table¶
| Aspect | Extreme Programming (XP) | Scrum |
|---|---|---|
| Primary Focus | Code development & quality | Project management & delivery |
| Primary Unit | User Stories | Sprints |
| Iteration | Flexible (usually 1-2 weeks) | Fixed (1-4 weeks) |
| Testing Strategy | TDD, unit + acceptance tests | Testing within sprint |
| Roles Defined | Driver/Observer | PO/SM/Team |
| Pair Programming | Core practice | Optional |
| Design Approach | Continuous refactoring, minimal upfront | Emerges through sprints |
| Best For | Technical quality emphasis | Business value delivery |
10.2 INVEST Model Quick Reference¶
| Characteristic | Definition | Why It Matters |
|---|---|---|
| Independent | No reliance on other stories | Enables parallel development |
| Negotiable | Not fixed, can be adjusted | Provides flexibility |
| Valuable | Delivers customer value | Ensures relevance |
| Estimable | Can estimate work required | Enables planning |
| Small | 1-2 days of work | Early detection of issues |
| Testable | Can be objectively verified | Ensures quality |
10.3 Research Findings Quick Reference¶
| Study | Key Metric | Finding | Exam Impact |
|---|---|---|---|
| Williams | Time | 15-30% faster | HIGH - Must know |
| Williams | Quality | 15% fewer bugs | HIGH - Must know |
| Williams | Confidence | 95% more confident | HIGH - Must know |
| Hannay | Complex tasks | Higher quality | MEDIUM |
| Arisholm | Juniors | 73% better | MEDIUM |
| Planning Poker | Accuracy | More accurate, less optimistic | MEDIUM |
10.4 Scrum Events Timing Reference¶
| Event | Duration | Frequency | Purpose |
|---|---|---|---|
| Daily Scrum | 15 minutes | Every day | Synchronize, remove obstacles |
| Sprint Planning | 2-4 hours | Once per sprint | Plan sprint work |
| Sprint | 1-4 weeks | Repeating cycle | Execute sprint work |
| Sprint Review | 1-2 hours | Once per sprint | Demonstrate, gather feedback |
| Retrospective | 1-1.5 hours | Once per sprint | Reflect, improve process |
Exam Preparation Strategy¶
Phase 1: Priority 1 Content (2 hours)¶
- INVEST model (6 characteristics with examples)
- Williams research data (15-30%, 15%, 74%/63%/95%)
- Bus Factor concept and solutions
- Scrum roles (especially Scrum Master NOT being manager)
- Quality gates (code must be fully tested)
Phase 2: Priority 2 Content (1.5 hours)¶
- Planning Poker 5-step process
- Burn down charts (sprint vs release)
- Daily scrum (15 min, 3 questions)
- XP vs Scrum differences
- Agile criticisms (database design risk)
Phase 3: Priority 3 Content (0.5 hours)¶
- 12 Agile Principles overview
- 4 Manifesto values context
- Kent Beck history
- Specific percentages (73%, 8%, etc.)
Phase 4: Practice & Verification (ongoing)¶
- Default-write Priority 1 content 3x
- Practice exam questions
- Compare answers to textbook examples
- Focus on areas of weakness
Document Status: ✅ Structured & Ready for Study
Version: 3.0 (Numbered Hierarchy Structure)
Last Updated: December 2025
GitHub Path: /notes/大三上/COMP319软件工程II/Agile_Methodologies/