Learning Agile. Understanding Scrum, XP, Lean, and Kanban Andrew Stellman, Jennifer Greene

Kup polskie wydanie:

Spis treści książki

• Foreword
• Preface
  • Acknowledgments
  • Safari Books Online
  • How to Contact Us
• 1. Learning Agile
  • What Is Agile?
  • Who Should Read This Book
  • Our Goals for This Book
  • Getting Agile into Your Brain by Any Means Necessary
  • How This Book Is Structured
• 2. Understanding Agile Values
  • A Team Lead, Architect, and Project Manager Walk into a Bar...
  • No Silver Bullet
  • Agile to the Rescue! (Right?)
    • Adding Agile Makes a Difference
    • Better-Than-Not-Doing-It Results
  • A Fractured Perspective
    • How a Fractured Perspective Causes Project Problems
    • Why Does a Fractured Perspective Lead to Just Better-Than-Not-Doing-It Results?
  • The Agile Manifesto Helps Teams See the Purpose Behind Each Practice
    • Individuals and Interactions Over Processes and Tools
    • Working Software Over Comprehensive Documentation
    • Customer Collaboration Over Contract Negotiation
    • Responding to Change Over Following a Plan
    • Principles Over Practices
  • Understanding the Elephant
    • Methodologies Help You Get It All in Place at Once
  • Where to Start with a New Methodology
• 3. The Agile Principles
  • The 12 Principles of Agile Software
  • The Customer Is Always Right...Right?
    • Do As I Say, Not As I Said
  • Delivering the Project
    • Principle #1: Our Highest Priority Is to Satisfy the Customer Through Early and Continuous Delivery of Valuable Software.
    • Principle #2: Welcome Changing Requirements, Even Late In Development. Agile Processes Harness Change for the Customers Competitive Advantage.
    • Principle #3: Deliver Working Software Frequently, from a Couple of Weeks to a Couple of Months, with a Preference to the Shorter Timescale.
    • Better Project Delivery for the Ebook Reader Project
  • Communicating and Working Together
    • Principle #4: The Most Efficient and Effective Method of Conveying Information To and Within a Development Team Is Face-To-Face Conversation.
    • Principle #5: Businesspeople and Developers Must Work Together Daily Throughout the Project.
    • Principle #6: Build Projects Around Motivated Individuals. Give Them the Environment and Support They Need, and Trust Them to Get the Job Done.
    • Better Communication for the Ebook Reader Project
  • Project ExecutionMoving the Project Along
    • Principle #7: Working Software Is the Primary Measure of Progress.
    • Principle #8: Agile Processes Promote Sustainable Development. The Sponsors, Developers, and Users Should Be Able to Maintain a Constant Pace Indefinitely.
    • Principle #9: Continuous Attention to Technical Excellence and Good Design Enhances Agility.
    • A Better Working Environment for the Ebook Reader Project Team
  • Constantly Improving the Project and the Team
    • Principle #10: Simplicitythe Art of Maximizing the Amount of Work Not DoneIs Essential.
    • Principle #11: The Best Architectures, Requirements, and Designs Emerge from Self-Organizing Teams.
    • Principle #12: At Regular Intervals, the Team Reflects on How to Become More Effective, Then Tunes and Adjusts Its Behavior Accordingly.
  • The Agile Project: Bringing All the Principles Together
• 4. Scrum and Self-Organizing Teams
  • The Rules of Scrum
  • Act I: I Can Haz Scrum?
  • Everyone on a Scrum Team Owns the Project
    • The Scrum Master Guides the Teams Decisions
    • The Product Owner Helps the Team Understand the Value of the Software
    • Everyone Owns the Project
      • How Product Owners, Scrum Masters, and team members can be better pigs
      • No room for chickens
    • Scrum Has Its Own Set of Values
  • Act II: Status Updates Are for Social Networks!
  • The Whole Team Uses the Daily Scrum
    • Feedback and the Visibility-Inspection-Adaptation Cycle
    • The Last Responsible Moment
      • Wait a minutecant we avoid bottlenecks by planning up front?
    • How to Hold an Effective Daily Scrum
  • Act III: Sprinting into a Wall
  • Sprints, Planning, and Retrospectives
    • Iterative or Incremental?
    • The Product Owner Makes or Breaks the Sprint
    • Visibility and Value
      • Elevating goals motivate everyone on the team
    • How to Plan and Run an Effective Scrum Sprint
  • Act IV: Dog Catches Car
• 5. Scrum Planning and Collective Commitment
  • Act V: Not Quite Expecting the Unexpected
  • User Stories, Velocity, and Generally Accepted Scrum Practices
    • Make Your Software Useful
    • User Stories Help Build Features Your Users Will Use
    • Conditions of Satisfaction
    • Story Points and Velocity
      • Why story points work
    • Burndown Charts
    • Planning and Running a Sprint Using Stories, Points, Tasks, and a Task Board
    • Generally Accepted Scrum Practices
  • Act VI: Victory Lap
  • Scrum Values Revisited
    • Practices Do Work Without the Values (Just Dont Call It Scrum)
    • Is Your Companys Culture Compatible with Scrum Values?
• 6. XP and Embracing Change
  • Act I: Going into Overtime
  • The Primary Practices of XP
    • Programming Practices
    • Integration Practices
    • Planning Practices
    • Team Practices
    • Why Teams Resist Changes, and How the Practices Help
  • Act II: The Game Plan Changed, but Were Still Losing
  • The XP Values Help the Team Change Their Mindset
    • XP Helps Developers Learn to Work with Users
    • Practices Only Stick When the Team Truly Believes in Them
  • An Effective Mindset Starts with the XP Values
    • The XP Values
    • Paved with Good Intentions
  • Act III: The Momentum Shifts
  • Understanding the XP Principles Helps You Embrace Change
    • The Principles of XP
    • XP Principles Help You Understand Planning
    • XP Principles Help You Understand Practicesand Vice Versa
    • Feedback Loops
• 7. XP, Simplicity, and Incremental Design
  • Act IV: Going into Overtime, Part 2: Second Overtime
  • Code and Design
    • Code Smells and Antipatterns (or, How to Tell If Youre Being Too Clever)
    • XP Teams Look for Code Smells and Fix Them
    • Hooks, Edge Cases, and Code That Does Too Much
      • Wait a minute, whats wrong with reusable frameworks?
      • Whats the difference between a library and a framework?
    • Code Smells Increase Complexity
  • Make Code and Design Decisions at the Last Responsible Moment
    • Fix Technical Debt by Refactoring Mercilessly
      • Isnt refactoring rework? And isnt rework one of the biggest sources of bugs?
      • Isnt it better to prevent this sort of problem by doing good design up front, at the beginning of the project? Isnt it safer to build the code right the first time?
    • Use Continuous Integration to Find Design Problems
    • Avoid Monolithic Design
  • Incremental Design and the Holistic XP Practices
    • Teams Work Best When They Feel Like They Have Time to Think
    • Team Members Trust Each Other and Make Decisions Together
    • The XP Design, Planning, Team, and Holistic Practices Form an Ecosystem That Spurs Innovation
    • Incremental Design Versus Designing for Reuse
    • When Units Interact in a Simple Way, the System Can Grow Incrementally
    • Great Design Emerges from Simple Interactions
  • Act V: Final Score
• 8. Lean, Eliminating Waste, and Seeing the Whole
  • Lean Thinking
    • You Already Understand Many of These Values
    • Commitment, Options Thinking, and Set-Based Development
      • Scrum teams commit to delivering value, but give themselves options for how to do it
      • Incremental design, set-based development, and other ways to give your team options
  • Act I: Just One More Thing...
  • Creating Heroes and Magical Thinking
  • Eliminate Waste
    • Use a Value Stream Map to Help See Waste Clearly
  • Gain a Deeper Understanding of the Product
    • See the Whole
    • Find the Root Cause of Problems That You Discover
  • Deliver As Fast As Possible
    • Use an Area Chart to Visualize Work in Progress
    • Control Bottlenecks by Limiting Work in Progress
    • Pull Systems Help Teams Eliminate Constraints
• 9. Kanban, Flow, and Constantly Improving
  • Act II: Playing Catch-Up
  • The Principles of Kanban
    • Find a Starting Point and Evolve Experimentally from There
      • Wait a minute. So Kanban doesnt tell me how to run my project?
    • Stories Go into the System; Code Comes Out
      • Every software team follows a system, whether they know it or not
      • Kanban is not a software methodology or a project management system
  • Improving Your Process with Kanban
    • Visualize the Workflow
      • Use a kanban board to visualize the workflow
    • Limit Work in Progress
      • Why not make the WIP limit 1 and meet all the time? Arent shorter feedback loops better?
  • Measure and Manage Flow
    • Use CFDs and WIP Area Charts to Measure and Manage Flow
      • How to build a cumulative flow diagram and use it to calculate the average lead time
      • Use a CFD to experiment with WIP limits and manage the flow
    • Littles Law Lets You Control the Flow Through a System
      • If the team still has to do all of that production support work, then what happened to the other work they were doing? Wont it accumulate somewhere else?
    • Managing Flow with WIP Limits Naturally Creates Slack
    • Make Process Policies Explicit So Everyone Is on the Same Page
  • Emergent Behavior with Kanban
• 10. The Agile Coach
  • Act III: Just One More Thing (Again?!)...
  • Coaches Understand Why People Dont Always Want to Change
    • Coaches Listen for Warning Signs That the Team Is Having Trouble with a Change
  • Coaches Understand How People Learn
    • Use Shuhari to Help a Team Learn the Values of a Methodology
  • Coaches Understand What Makes a Methodology Work
  • The Principles of Coaching
• Index

pokaż cały spis treści

ukryj recenzje