Мета закинута
Автор не відписував в цілі 10 років 5 месяців 12 днів
Read 3th part "Teams" of the book "Succeeding with Agile"
I must to read Read 3th part "Teams" of the book Succeeding with "Agile Software Development using scrum" and clear understand the meaning with advice from this guideline and use it.
175-324 pages of the book.
-
10. Team Structure (177-200)
It is perhaps a myth, but an enduring one, that people and their pets resemble one
another. The same has been said of products and the teams that build them.
The system being produced will tend to have a structure which
mirrors the structure of the group that is producing it, whether
or not this was intended. One should take advantage of this fact,
and then deliberately design the group structure so as to achieve
the desired system structure. (Conway 1968; commonly referred
to as “Conway’s Law”)Chapter Contents
- Feed Them Two Pizzas
- Why Two Pizzas Are Enough
- Small Team Productivity
- Favor Feature Teams
- Use Component Teams Sparingly
- Who Makes These Decisions?
- What’s Right Today May Be Wrong Tomorrow
- Self-Organizing Doesn’t Mean Randomly Assembled
- Getting the Right People on the Team
- Put People on One Project
- Time on Task Decreases with Too Many Tasks
- When Multitasking Is OK
- The Corporate Form of Multitasking
- Stopping the Treadmill
- Guidelines for Good Team Structure
- Onward
- Additional Reading
- Feed Them Two Pizzas
-
11. Teamwork (201-218)
Teamwork is at the heart of every agile process. The Agile Manifesto proclaims
that we are to favor “individuals and interactions over process and tools” (Beck et
al. 2001), meaning great software comes from great teams. Scrum itself derives its
name from the view that a product development team should behave much like a
rugby team—a group of individuals moving the ball down field as a unit. Considering
the central importance of teams to successful agile development, it should
be no surprise to encounter a chapter called “Teamwork.”Chapter Contents
- Embrace Whole-Team Resposibility
- Nurture Whole-Team Commitment
- Rely On Specialists But Sparingly
- Do A Little Bit Of Everything All The Time
- Don’t Wait Until the End of the Sprint to Finish Everything
- Mix the Sizes of the Product Backlog Items You Commit To
- Foster Team Learning
- Ensure Learning Conditions Exist
- Eliminate Knowledge Waste
- Encourage Collaboration Through Commitment
- All Together Now
- Additional Reading
- Embrace Whole-Team Resposibility
-
12. Leading a Self-Organizing Team (219-234)
One of the earliest models for organizational change was put forth by Kurt
Lewin in the 1940s. In Lewin’s model, change is a three-step process: “unfreezing”
the current situation so that change may occur, transitioning to a new state, and
then “refreezing” the new state so that it persists. Many subsequent organizational
change models are similar to Lewin’s in depicting extended periods of relative
stability punctuated by brief times of transition.
Although this may have been Lewin’s worldChapter Contents
- Influencing Self-Organization
- Containers, Differences, and Exchanges
- Influencing Evolution
- Select the External Environment
- Define Performance
- Manage Meaning
- Introduce Vicarious Selection Systems
- Energize the System
- There’s More to Leadership than Buying Pizza
- Additional Reading
- Influencing Self-Organization
-
13. The product Backlog (235-256)
The biggest question looming at the start of a project is, what exactly are we
building? We know the general shape of the system to be built. We may know, for
example, that we are building a word processor. But there are always dark corners
yet to be explored or issues yet to be settled about how specific features will work.
Will our word processor include an interactive table design feature, or will tables
be designed by entering values into a series of screens?Chapter Contents
- Shift from Documents to Discussions
- Don’t Throw the Baby Out with the Documentation
- Use User Stories for the Product Backlog
- Progressively Refine Requirements
- Emergent Requirements
- The Product Backlog Iceberg
- Why Progressively Refine Requirements?
- Progressive Refinement of User Stories
- Learn to Start Without a Specification
- Specify by Example
- Cross-Functional Teams Reduce Documentation Needs
- Make the Product Backlog DEEP
- Don’t Forget to Talk
- Additional Reading
- Shift from Documents to Discussions
-
14. Sprints (257-284)
Like all of the agile processes, Scrum is an iterative and incremental approach
to software development. Although the terms iterative and incremental each have a
unique meaning, they are often used together. Let’s briefly tease them apart so we
can better understand their meanings.Chapter Contents
- Deliver Working Software Each Sprint
- Defining Potentially Shippable
- Identifying Potentially Shippable Guidelines
- Deliver Something Valuable Each Sprint
- Prepare in this Sprint for the Next
- Billiard Ball Sprints
- Only Pull into a Sprint What Can Be Completed
- Work Together Throughout the Sprint
- Avoid Activity-Specific Sprints
- Replace Finish-to-Start Relationships with Finish-to-Finish Ones
- Overlapping User Experience Design
- Think Holistically, Work Incrementally
- Architecture and Database Design
- Keep Timeboxes Regular and Strict
- Never Extend a Sprint
- Don’t Change the Goal
- Break the Habit of Redirecting a Team
- Get Feedback, Learn, and Adapt
- Additional Reading
- Deliver Working Software Each Sprint
-
15. Planning (285-306)
“We’re agile, we don’t plan” and “We’ll be done when we’re done” were common
statements in the early years following the publication of the Agile Manifesto.
I suspect that many people on some of the early agile teams that took this stance
knew that they were giving up something valuable when they threw planning out
the window. But, theirs was a natural reaction to the prior cultures in which they’d
worked. Too many developers hated planning because the plan had never been of
any personal benefit to them. Instead, plans were often weapons used against the
developers: “You said you’d be done by June; it’s June. Make it happen.”Chapter Contents
- Progressively Refine Plans
- Don’t Plan on Overtime to Salvage a Plan
- Learning the Hard Way
- Getting There
- If Not Overtime, What?
- Favor Scope Changes When Possible
- Considering the Alternatives
- Project Context Is Key
- Separate Estimating from Committing
- The Right Data to Do This
- Going from Estimate to Commitment
- Historical Velocity Forms the Basis for Committing
- Summary
- Additional Reading
-
16. Quality (307-324)
Early into my career as a programmer, I left my large, stable employer for an
eight-person start-up. I went from a well-funded environment where we had a
separate testing and quality assurance organization to a company where I was only
the second programmer; there was not a tester in sight. Sometime during my first
week at my new job, it hit me: I would be responsible for my own quality. There
were no testers who would check my work or who would be a safety net for my
meager attempts at unit testing. And then the bigger realizations hit: Without a
tester, I would look like a fool to our customers (although none would know me
personally) and I would also look like a fool to my boss, which could cost me my
jobChapter Contents
- Integrate Testing Into the Process
- Why Testing at the End Doesn’t Work
- What Building Quality In Looks Like
- Automate At Different Levels
- The Remaining Role of User Interface Tests
- The Role of Manual Testing
- Automate within the Sprint
- Sampling the Benefits
- Do Acceptance-Test-Driven Development
- The Right Level of Detail
- Pay Off Technical Debt
- Paying Down Testing Debt in Three Steps
- Quality Is a Team Effort
- Additional Reading
- Integrate Testing Into the Process
Не пропустіть нові записи!
Підпишіться на ціль і стежте за її досягненням
