舉報 
會員
The Agile Developer's Handbook
Ifyou’reasoftwaredeveloperoraprojectmanagerwithlittletonoexperienceofAgile,butyouwanttoefficientlyimplementit,thisisthebookforyou.
最新章節
- Leave a review - let other readers know what you think
- Other Books You May Enjoy
- Summary
- Further reading
- Organizational styles for flatter structures
- Experiment – Communities
品牌：中圖公司
上架時間：2021-06-24 17:57:07
出版社：Packt Publishing
本書數字版權由中圖公司提供，并由其授權上海閱文信息技術有限公司制作發行
- Leave a review - let other readers know what you think 更新時間：2021-06-24 18:48:05
- Other Books You May Enjoy
- Summary
- Further reading
- Organizational styles for flatter structures
- Experiment – Communities
- Experiment – Creating informal networks as a nervous system
- The art of Agile leadership
- Performance Review 360 – Advanced level
- Performance review 360 – Intermediate level
- Example – Changing up the performance review
- Creating engagement
- Feeling successful
- Feeling relevant
- Feeling recognized
- Ensuring team engagement
- Cultivating culture
- Setting the challenge
- Implementing a fly-by-wire approach
- Changing to a fly-by-wire system
- Modern leadership
- Further reading
- Self-selection to create a true-self organization
- A network of teams
- The Big Agile board
- From a hierarchical organization to collaborative governance
- How an Agile approach will organically flatten an organizational structure
- Moving Beyond Isolated Agile Teams
- Summary
- Fostering a learning habit
- How can we embrace a growth mindset?
- An example of a fixed mindset behavior versus a growth mindset behavior
- Growth mindset versus fixed mindset
- The growth mindset
- The problem with "rockstars"
- The team player
- The entrepreneurial developer
- Why are intrinsic drivers important?
- Activity – moving motivators
- Purpose
- Autonomy
- Mastery
- Intrinsic drivers
- Extrinsic drivers
- The power of motivation
- The Ultimate Software Team Member
- Summary
- No more estimates
- Refactoring our environment
- Bugs caused by the nature of the problem changing
- Bugs caused by our understanding of the problem
- Bugs caused by the way we write code and design our software
- No more bugs
- Ergonomics
- How does mob programming work?
- Why does mob programming work?
- Mob programming
- Cross-pollination of skills
- Baking Quality into Our Software Delivery
- Summary
- Google's 20% time and other alternatives
- Running a hackathon or innovation day
- Innovation Days
- Hackathons
- Learning by practicing
- Helping our team process this phase
- Stage 5 – adjourning/mourning
- Activity – 360 team review
- Helping our team process this phase
- Stage 4 – performing
- Activity – improve the team's ability to self-assess
- Activity – experiments in process
- Helping our team process this phase
- Stage 3 – norming
- Coach – giving feedback
- Coach – conflict protocols
- Coach – focus on the task not the person
- Group decision making
- Activity – process the conflict
- Positivity and successful relationships
- Coach – conflict happens how to navigate it
- Coach – diversity is a good thing
- Helping our team process this phase
- Stage 2 – storming
- Relationship-building games
- Helping our team process this phase
- Stage 1 – forming
- The stages of team formation
- Further reading
- Psychological safety – what it is and how to create it
- Communication lines
- Knowledge work and high-bandwidth communication
- Collaboration is the key
- How to create high-performing teams
- Improving Our Team Dynamics to Increase Our Agility
- Summary
- Using Rolling Wave Planning for adaptive delivery
- Using Spikes to reduce business and technical unknowns
- Working collaboratively with the team to create a shared understanding
- Leveraging an Impact Map
- Question 4 – What will we do?
- Question 3 – How will they help us?
- Question 2 – Who will help us?
- Question 1 – Why are we doing this?
- Activity – Creating an Impact Map
- Impact Mapping
- Leveraging the User Story Map
- Step 4 – Naming the activities
- Step 3 – Alternative paths sub-tasks details and business rules
- Step 2 – The first User Journey
- Step 1 – User roles
- Activity – creating a User Story Map
- User Story Mapping
- Product Discovery to create roadmaps
- The importance of Product Roadmaps
- Using Product Roadmaps to Guide Software Delivery
- Summary
- Telling our team "the why" not "the what"
- How to seek value
- Seeking value
- Data Insights Beliefs Bets (DIBBs)
- Hypothesis-Driven Development (HDD)
- Using Objectives and Key Results (OKRs)
- Setting objectives to create alignment of purpose
- Moving from project to product
- The advantages of a product team
- Cynefin – A sense-making framework
- Moving from project to product thinking
- Seeking Value – How to Deliver Better Software Sooner
- Summary
- Learning rapidly by doing and failing fast
- Approach
- Hypothesis
- Background
- An example of Lean Startup MVP
- Build Measure Learn
- Adopting Lean Startup methods to validate ideas
- Root cause analysis with the Five Whys method
- Fail Cake
- Kaizen and developing a small continuous improvement mindset
- Changing our workflow
- Systems thinking – Optimizing the whole
- The coin game results
- Introducing some Lean thinking to improve flow
- Shifting right
- Shifting left
- The importance of User Experience (UX)
- Inspection and adaption
- Working with software in small manageable chunks
- Implementing incremental delivery in Agile
- Tightening Feedback Loops in the Software Development Life Cycle
- Summary
- Things to try
- How does this keep us Agile?
- Continuous Deployment
- Things to try
- How does this keep us Agile?
- Continuous Delivery
- Things to try
- How does this keep us Agile?
- Continuous Integration
- The DevOps culture
- Activity – emergent design discussion
- Things to try
- How does this keep us Agile?
- Emergent design
- Activity – pair programming ping pong
- Things to try
- How does this keep us Agile?
- Pair programming
- Things to try
- How does this keep us Agile?
- Test-Driven Development
- Things to try
- How does this keep us Agile?
- Refactoring
- Building the thing right versus building the right thing
- Software Technical Practices are the Foundation of Incremental Software Delivery
- Summary
- User Happiness Index
- Using our Team Success Indicators
- Defining our success
- Defining what success looks like
- Qualitative metrics
- Code complexity
- Code quality
- Enhanced Release Burndown chart
- Simple Release Burndown chart
- Release burndown charts
- Sprint Burndown chart – TEAM
- Team velocity
- Quantitative metrics
- Negative versus positive metrics
- Qualitative versus quantitative measurements
- Understanding measurements
- A brief introduction to measurements for Agile software delivery
- Metrics that will Help your Software Team Deliver
- Summary
- References
- Step 3 – Team calendar
- Step 2 – Working agreement
- Step 1 – Defining done
- Activity – Forming a team charter
- Defining success metrics
- Step 5 – Define success
- Step 4 – The current mission
- Step 3 – The product vision
- Step 2 – The company purpose
- Step 1 – Meet the sponsors
- ACTIVITY – Sharing the vision
- ACTIVITY – Agile training
- What's a team liftoff?
- Bootstrap Teams with Liftoffs
- Summary
- References
- Playing Planning Poker
- Planning Poker
- Estimating Agile user requirements
- Brainstorming a bunch of User Stories
- Telling the team "what" not "how"
- Acceptance criteria versus the Definition of Done (DoD)
- Card conversation confirmation
- Notes
- Story size
- Acceptance criteria
- The stub
- Additional story card elements
- The User Story format
- What a User Story is and how to use it
- Why User Stories produce results
- The pitfalls of traditional big upfront requirements
- Gathering Agile User Requirements
- Summary
- The importance of team retrospectives
- Event – Sprint Retrospective
- Event – Sprint Review
- The last day of the Sprint
- Managing delivery as a team sport
- Removing impediments
- The importance of visible workspaces
- Sprint Goal confidence
- Burndowns
- Done stickers
- Avatars
- Measuring and reporting progress with visualization
- A day in the life of a Scrum team
- Event – first Daily Scrum
- The Sprint Goal
- How will we achieve it?
- What can we achieve in this Sprint?
- Event – Sprint Planning
- Day one of the Sprint
- Discussion – Sprint Zero
- Activity – setting up the Scrum Board
- Activity – estimating User Stories on the backlog
- Activity – introducing the Product Backlog
- Activity – release planning
- Activity – defining the Product Backlog
- Preparing to Sprint
- Prerequisites
- Starting a new Scrum team
- Iterations and iteration length
- Why Scrum is an excellent place to start
- Introducing Scrum to your Software Team
- Summary
- Mixing and matching Agile methods
- There are similarities with subtle differences
- Not all frameworks prescribe technical practices
- They don't include product discovery phases
- Designed for small teams
- Choosing the right framework
- Step 4 – Kaizen or continuous improvement
- Step 3 – Improve flow
- Step 2 – Make the work policies of the team explicit
- Step 1 – Make the team's work visible
- Getting started with Kanban
- Introduction to the mechanics of Lean/Kanban
- How Kanban/Lean fit into the Agile movement
- Single-piece flow
- Reducing waste
- Background
- Kanban and Lean Software Development
- Iteration retrospective
- Iteration demo
- Implementing the iteration plan
- Part 2 – Iteration planning
- Part 1 – Release planning
- The planning game
- Introduction to the mechanics of XP
- Background
- XP - Extreme Programming
- Additional events
- The Sprint Retrospective
- The Sprint Review
- The Daily Scrum
- Sprint Planning - part 2
- Sprint Planning – part 1
- Introduction to the mechanics of Scrum
- Background
- Understanding Scrum
- Agile Software Delivery Methods and How They Fit the Manifesto
- Summary
- Our response
- Scenario
- An Example of "Being Agile"
- Agile is a mindset
- Incremental delivery and adaptive planning
- The Waterfall process and predictive planning
- Incremental – adaptive versus waterfall – predictive
- The Agile principles
- The Agile values
- So the project mindset isn't good?
- Where's the business value?
- And then there's missing the point entirely
- Variability in our estimates
- Estimates became ironic
- Uncertainty buffers
- Estimates
- Scope was the priority
- Product versus project
- Delivery as a software project
- Delivery as a software product
- Why the software industry needed to change
- The Software Industry and the Agile Manifesto
- Reviews
- Get in touch
- Conventions used
- Download the color images
- To get the most out of this book
- What this book covers
- Who this book is for
- Preface
- Packt is searching for authors like you
- About the reviewer
- About the author
- Contributors
- PacktPub.com
- Why subscribe?
- Packt Upsell
- Title Page
- coverpage
- coverpage
- Title Page
- Packt Upsell
- Why subscribe?
- PacktPub.com
- Contributors
- About the author
- About the reviewer
- Packt is searching for authors like you
- Preface
- Who this book is for
- What this book covers
- To get the most out of this book
- Download the color images
- Conventions used
- Get in touch
- Reviews
- The Software Industry and the Agile Manifesto
- Why the software industry needed to change
- Delivery as a software product
- Delivery as a software project
- Product versus project
- Scope was the priority
- Estimates
- Uncertainty buffers
- Estimates became ironic
- Variability in our estimates
- And then there's missing the point entirely
- Where's the business value?
- So the project mindset isn't good?
- The Agile values
- The Agile principles
- Incremental – adaptive versus waterfall – predictive
- The Waterfall process and predictive planning
- Incremental delivery and adaptive planning
- Agile is a mindset
- An Example of "Being Agile"
- Scenario
- Our response
- Summary
- Agile Software Delivery Methods and How They Fit the Manifesto
- Understanding Scrum
- Background
- Introduction to the mechanics of Scrum
- Sprint Planning – part 1
- Sprint Planning - part 2
- The Daily Scrum
- The Sprint Review
- The Sprint Retrospective
- Additional events
- XP - Extreme Programming
- Background
- Introduction to the mechanics of XP
- The planning game
- Part 1 – Release planning
- Part 2 – Iteration planning
- Implementing the iteration plan
- Iteration demo
- Iteration retrospective
- Kanban and Lean Software Development
- Background
- Reducing waste
- Single-piece flow
- How Kanban/Lean fit into the Agile movement
- Introduction to the mechanics of Lean/Kanban
- Getting started with Kanban
- Step 1 – Make the team's work visible
- Step 2 – Make the work policies of the team explicit
- Step 3 – Improve flow
- Step 4 – Kaizen or continuous improvement
- Choosing the right framework
- Designed for small teams
- They don't include product discovery phases
- Not all frameworks prescribe technical practices
- There are similarities with subtle differences
- Mixing and matching Agile methods
- Summary
- Introducing Scrum to your Software Team
- Why Scrum is an excellent place to start
- Iterations and iteration length
- Starting a new Scrum team
- Prerequisites
- Preparing to Sprint
- Activity – defining the Product Backlog
- Activity – release planning
- Activity – introducing the Product Backlog
- Activity – estimating User Stories on the backlog
- Activity – setting up the Scrum Board
- Discussion – Sprint Zero
- Day one of the Sprint
- Event – Sprint Planning
- What can we achieve in this Sprint?
- How will we achieve it?
- The Sprint Goal
- Event – first Daily Scrum
- A day in the life of a Scrum team
- Measuring and reporting progress with visualization
- Avatars
- Done stickers
- Burndowns
- Sprint Goal confidence
- The importance of visible workspaces
- Removing impediments
- Managing delivery as a team sport
- The last day of the Sprint
- Event – Sprint Review
- Event – Sprint Retrospective
- The importance of team retrospectives
- Summary
- Gathering Agile User Requirements
- The pitfalls of traditional big upfront requirements
- Why User Stories produce results
- What a User Story is and how to use it
- The User Story format
- Additional story card elements
- The stub
- Acceptance criteria
- Story size
- Notes
- Card conversation confirmation
- Acceptance criteria versus the Definition of Done (DoD)
- Telling the team "what" not "how"
- Brainstorming a bunch of User Stories
- Estimating Agile user requirements
- Planning Poker
- Playing Planning Poker
- References
- Summary
- Bootstrap Teams with Liftoffs
- What's a team liftoff?
- ACTIVITY – Agile training
- ACTIVITY – Sharing the vision
- Step 1 – Meet the sponsors
- Step 2 – The company purpose
- Step 3 – The product vision
- Step 4 – The current mission
- Step 5 – Define success
- Defining success metrics
- Activity – Forming a team charter
- Step 1 – Defining done
- Step 2 – Working agreement
- Step 3 – Team calendar
- References
- Summary
- Metrics that will Help your Software Team Deliver
- A brief introduction to measurements for Agile software delivery
- Understanding measurements
- Qualitative versus quantitative measurements
- Negative versus positive metrics
- Quantitative metrics
- Team velocity
- Sprint Burndown chart – TEAM
- Release burndown charts
- Simple Release Burndown chart
- Enhanced Release Burndown chart
- Code quality
- Code complexity
- Qualitative metrics
- Defining what success looks like
- Defining our success
- Using our Team Success Indicators
- User Happiness Index
- Summary
- Software Technical Practices are the Foundation of Incremental Software Delivery
- Building the thing right versus building the right thing
- Refactoring
- How does this keep us Agile?
- Things to try
- Test-Driven Development
- How does this keep us Agile?
- Things to try
- Pair programming
- How does this keep us Agile?
- Things to try
- Activity – pair programming ping pong
- Emergent design
- How does this keep us Agile?
- Things to try
- Activity – emergent design discussion
- The DevOps culture
- Continuous Integration
- How does this keep us Agile?
- Things to try
- Continuous Delivery
- How does this keep us Agile?
- Things to try
- Continuous Deployment
- How does this keep us Agile?
- Things to try
- Summary
- Tightening Feedback Loops in the Software Development Life Cycle
- Implementing incremental delivery in Agile
- Working with software in small manageable chunks
- Inspection and adaption
- The importance of User Experience (UX)
- Shifting left
- Shifting right
- Introducing some Lean thinking to improve flow
- The coin game results
- Systems thinking – Optimizing the whole
- Changing our workflow
- Kaizen and developing a small continuous improvement mindset
- Fail Cake
- Root cause analysis with the Five Whys method
- Adopting Lean Startup methods to validate ideas
- Build Measure Learn
- An example of Lean Startup MVP
- Background
- Hypothesis
- Approach
- Learning rapidly by doing and failing fast
- Summary
- Seeking Value – How to Deliver Better Software Sooner
- Moving from project to product thinking
- Cynefin – A sense-making framework
- The advantages of a product team
- Moving from project to product
- Setting objectives to create alignment of purpose
- Using Objectives and Key Results (OKRs)
- Hypothesis-Driven Development (HDD)
- Data Insights Beliefs Bets (DIBBs)
- Seeking value
- How to seek value
- Telling our team "the why" not "the what"
- Summary
- Using Product Roadmaps to Guide Software Delivery
- The importance of Product Roadmaps
- Product Discovery to create roadmaps
- User Story Mapping
- Activity – creating a User Story Map
- Step 1 – User roles
- Step 2 – The first User Journey
- Step 3 – Alternative paths sub-tasks details and business rules
- Step 4 – Naming the activities
- Leveraging the User Story Map
- Impact Mapping
- Activity – Creating an Impact Map
- Question 1 – Why are we doing this?
- Question 2 – Who will help us?
- Question 3 – How will they help us?
- Question 4 – What will we do?
- Leveraging an Impact Map
- Working collaboratively with the team to create a shared understanding
- Using Spikes to reduce business and technical unknowns
- Using Rolling Wave Planning for adaptive delivery
- Summary
- Improving Our Team Dynamics to Increase Our Agility
- How to create high-performing teams
- Collaboration is the key
- Knowledge work and high-bandwidth communication
- Communication lines
- Psychological safety – what it is and how to create it
- Further reading
- The stages of team formation
- Stage 1 – forming
- Helping our team process this phase
- Relationship-building games
- Stage 2 – storming
- Helping our team process this phase
- Coach – diversity is a good thing
- Coach – conflict happens how to navigate it
- Positivity and successful relationships
- Activity – process the conflict
- Group decision making
- Coach – focus on the task not the person
- Coach – conflict protocols
- Coach – giving feedback
- Stage 3 – norming
- Helping our team process this phase
- Activity – experiments in process
- Activity – improve the team's ability to self-assess
- Stage 4 – performing
- Helping our team process this phase
- Activity – 360 team review
- Stage 5 – adjourning/mourning
- Helping our team process this phase
- Learning by practicing
- Hackathons
- Innovation Days
- Running a hackathon or innovation day
- Google's 20% time and other alternatives
- Summary
- Baking Quality into Our Software Delivery
- Cross-pollination of skills
- Mob programming
- Why does mob programming work?
- How does mob programming work?
- Ergonomics
- No more bugs
- Bugs caused by the way we write code and design our software
- Bugs caused by our understanding of the problem
- Bugs caused by the nature of the problem changing
- Refactoring our environment
- No more estimates
- Summary
- The Ultimate Software Team Member
- The power of motivation
- Extrinsic drivers
- Intrinsic drivers
- Mastery
- Autonomy
- Purpose
- Activity – moving motivators
- Why are intrinsic drivers important?
- The entrepreneurial developer
- The team player
- The problem with "rockstars"
- The growth mindset
- Growth mindset versus fixed mindset
- An example of a fixed mindset behavior versus a growth mindset behavior
- How can we embrace a growth mindset?
- Fostering a learning habit
- Summary
- Moving Beyond Isolated Agile Teams
- How an Agile approach will organically flatten an organizational structure
- From a hierarchical organization to collaborative governance
- The Big Agile board
- A network of teams
- Self-selection to create a true-self organization
- Further reading
- Modern leadership
- Changing to a fly-by-wire system
- Implementing a fly-by-wire approach
- Setting the challenge
- Cultivating culture
- Ensuring team engagement
- Feeling recognized
- Feeling relevant
- Feeling successful
- Creating engagement
- Example – Changing up the performance review
- Performance review 360 – Intermediate level
- Performance Review 360 – Advanced level
- The art of Agile leadership
- Experiment – Creating informal networks as a nervous system
- Experiment – Communities
- Organizational styles for flatter structures
- Further reading
- Summary
- Other Books You May Enjoy
- Leave a review - let other readers know what you think 更新時間：2021-06-24 18:48:05
