書摘《Executable Specifications with Scrum》

Chapter 1 Solving the Right Problem

Both, R&D and agile tackle the uncertainties in a nontraditional manner influenced by the trial-and-error process. _{p. 9}

Chapter 2 Relying on a Stable Foundation

Here is the list of guardrails to put in place to provide the basis for tackling uncertainties:
- A healthy team
- The involvement of all stakeholders
- A shared vision
- A meaningful common goal
- A set of high-level features
- A “can-exist” assumption _{p. 14}

This short, one-line summary should provide a shared understanding of what the software is supposed to be and do. A clear vision provides context for making better decisions and taking responsibility throughout the course of the software development life cycle, _{p. 18}

Furthermore, when a new member joins the team, one of the first duties of the Scrum master is to communicate, in a one-on-one conversation, the vision, the meaningful common goal. and the high-level features of the software. _{p. 22}

Chapter 3 Discovering Through Short Feedback Loops and Stakeholders’ Desirements

Therefore, fail early and offten. _{p. 25}

Keep in mind that there are no real mistakes, just learning opportunities. Each and everything you do, whether you achieve your goal, leads you to another place. When there are no instructions to follow, trial and error is an efficient path to discovery. _{p. 27}

This problem-solving approach enables you to find what works and eliminate what doesn’t. Deliberate discovery does not happen from the failure itself but rather from understanding the failure, making an improvement, and then traying again. _{p. 28}

Chapter 4 Expressing Desirements with User Stories

A user story describes functionality that will be valuable to either a user or purchaser of a system or software. _{p. 36}

A well-written user story follows the INVEST mnemonic developed by Bill Wake. It fulfills the criteria of Independent, Negotiable, Valuable, Estimable, Small, and Testable. _{p. 37}

User stories encourage a process whereby software is iteratively refined based on conversation and confirmation between stakeholders and the team. The details are worked out in the conversation, and the success criteria are recorded in the confirmation. _{p. 37}

Chapter 5 Refining User Stories by Grooming the Product Backlog

Grooming is the act of ranking, illustrating, sizing, and splitting user stories. _{p. 45}

The product owner is responsible for ensuring that the product backlog is always in a healthy state. …(skipped)… The development team activly takes a hand in backlog management. _{p. 46}

When dealing with emerging needs, it is impossible to keep the entire backlog in a ready state; only the top elements need to be. A healthy backlog provides a set of high-value, ready desirements, about equal in size, that are small enough so that the team can deliver them in the upcoming sprints. To obtain desirements that are ready to iterate, you need periodically groom the backlog. _{p. 48}

The meeting is then time-boxed, at usually one hour, and each story is considered. Don’t worry if you don’t have time to discuss all the stories in the backlog. They will be addressed in future meetings. _{p. 56}

Stop measuring absolute values and start comparing relative values. When estimating, you should not measure effort but instead compare efforts using a reference point.
Humans are poor at estimating absolute sizes. However, we are great at assessing relative sizes. _{p. 57}

A rule of thumb used to determine whether a story is small enough is to take the average velocity of the team per iteration and divide it by two. _{p. 61} (so a team may be able to do two or more stories, not just a very large story)

Chapter 6 Confirming User Stories with Scenarios

Success criteria establish the conditions of acceptance from the stakeholder's point of view. _{p. 74}

The reality is these two techniques (FIT tabular format and BDD Given-When-Then syntax) are equally effective. _{p. 80}

A concept is a unit of meaning that expresses the behavior of the problem’s domain. Each concept within a precondition, an action, or a consequence should have a unique name that follows the domain’s terminology. … (skipped)… If in doubt, do not invent a new term; always use the language of the domain and seek agreement between stakeholders so that everyone uses a consistent vocabulary. _{p. 81} (so that that becomes a domain-specific language, DSL)

Try to limit the meeting (specification workshop) to no more than two hours because after that much time, people tend to be less productive. _{p. 88}

A good practice, during the specification workshop, is to name an analyst for each user story, The analyst is always a member of the development team. _{p. 88}

Because designing the technical solution is not the purpose of the specification, you should focus only on writing scenarios that relate to the business rules. This does not mean you should not focus on the user experience; storyboards are used for that. _{p. 89}

Chapter 7 Automating Confirmation with Acceptance Tests

As we all know, when there is more than one version of the truth, there are synchronization issues. _{p. 98}

Unfortunately, unit tests do not help in this matter (confirm stakeholders’ desirements). Unit tests always pass because they test against the programmer’s assumptions. _{p. 99} (unit tests are still important for iterative development)

The development cycle must help synchronize the development team’s assumptions early. The team needs faster feedback loops for discovering whether an implementation is correct for the scenario’s assumptions. _{p. 100}

TDD places constraints on programmers; it requires that they define the interface before deciding on the implementation. TDD tends to lead better designs. It makes code inherently reusable because programmer must use it in both tests and production circumstances. _{p. 102}

Finally, in a more complex case, the testers can decide to bypass the user interface and connect the test directly to the application’s controller (if it exists). In all cases, the real challenge is to properly design the programming interface. _{p. 110}

As a minimum, daily confirmation is what you should aim for. Testing the “executable” scenarios during the nightly build ensures that every morning the team can easily confirm that the software under construction still meets the evolving specifications. _{p. 118}

All this work was done with one goal in mind: to easily identify which previously successful tests are now failing. _{p. 119}

Chapter 8 Addressing Nonfunctional Requirements

The architect leads the design of the structural foundation upon which the solution is built by the team. This leadership is not done in isolation. The architect works collaboratively with every team member to remove accidental complexity and pursues simplicity in the design. _{p. 126}

Deferring the meeting of a restriction can lead to a large amount of reworking in future sprints, due to architectural considerations. _{p. 136}

When looking at examples of Definition of Done (not acceptance criteria) in various teams, they usually include points like
- Code completed.
- 0 (known) bugs.
- Passed unit tests.
- Code peer-reviewed or paired.
- Code checked in.
- Deployed to test environment and passed tests.
- Documentation updated.
The benefit of having an explicit set of practices is that after it is defined, the team can apply those practices, story after story, spring after sprint. _{p. 138}

Jul 19, 2020