書摘《Executable Specifications with Scrum》

閱讀時間約 18 分鐘

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 teamp. 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 thatp. 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 circumstancesp. 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 interfacep. 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 considerationsp. 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

這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
Spirit的沙龍 的其他內容
User Story Refinement
閱讀時間約 9 分鐘
閱讀時間約 2 分鐘
閱讀時間約 10 分鐘
閱讀時間約 9 分鐘
書摘《聯盟世代》:新世代勞資關係思維的典範轉移本書重點 1.企業如何與員工建立信任與忠誠的關係 2.聯盟關係應該運用在不同類型的員工和種類 3.企業如何與創業型員工建立關係 4.企業應該允許員工做那些拓展人脈和塑造個人品牌故事 5.運用企業校友會的網絡關係
鄭智維 Wesley
鄭智維 Wesley
鄭智維 Wesley
書摘-《孤獨的冷漠:逃避型依戀障礙的分析與修復》前言   活了30幾年終於要正式自身的問題,於是大量的找這類型的書籍來了解。看到書中許多有共鳴的分析句子或情境,心臟會隱隱的抽痛;我想,那會不會是身體在告訴我,過去真的積壓太多情感。   只有我自己才能成為自己最堅強的後盾!現在的我,是這樣想的。於是,正式開起了這段探訪自我之旅。
書摘-《情緒的驚人力量》前言   前陣子又迎來新一輪的"心理低潮",開啟了自我否定及頹喪的模式。這種輪迴模式持續多久了呢? 似乎從幼稚園、國小、國中...出了社會,直到現在快35歲了,模式仍然持續著。每次只要一但開啟這個模式,迎面而來的就是不可自控的焦慮、惶恐、絕望、失落、無望,連呼吸都覺得費力。 讓感覺變成指引。 結語
鄭智維 Wesley
書摘《訂閱經濟》將顧客轉換為訂戶(subscriber),以創造經常性收入。稱為「訂閱經濟」(Subsrciption Economy)。