書摘《Executable Specifications with Scrum》

閱讀時間約 18 分鐘
raw-image


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

53會員
102內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
留言0
查看全部
發表第一個留言支持創作者!
Spirit的沙龍 的其他內容
這本書其實是參加 Agile Taipei 2018 時買的,還跟作者簽名合照,回到家後很『不』快地看完,大概是因為自己喜歡待在新創公司,有點難體會『大』企業的轉型困難點,現在回頭看一下當年畫的筆記,多了不少感受。
工作中,Scrum 跑的對不對,不是最重要的事了。在看這一本書時,想到的大多是 2016 在某公司推廣 Scrum 的經歷,很多是在這本書都提到了,很適合想要推廣敏捷前,先讀的一本好書。
會後,我與其中一位創辦人聊聊他們 scrum 怎麼跑,以及程式、美術與企劃,這三種技能差異甚大的成員怎麼合作,他也苦笑,其實他們也花了很多時間磨合,但我們都提到,要引導團隊需要的不是 process,而是很多的軟技能,讓團隊自己能夠成長。
老實說,從中文書名無法聯想回原文書是《The Elements of Scrum》,雖然書名翻譯沒有太離譜(和內容無關之類的),但總覺得貼近原意會好一點。『Scrum團隊週記』這一章,整個讀完,其實就差不多可以了解Scrum的大部分,所以,若要讀這本書,又沒有太多時間,就先看這一章吧!
創業團隊就會很在意story的內容,會有相當多的意見,refinement meeting就是一個很好的場合讓大家把對需求的想法提出來,否則讓成員失去參與感,這對創業團隊是很大的傷害。
這本書其實是參加 Agile Taipei 2018 時買的,還跟作者簽名合照,回到家後很『不』快地看完,大概是因為自己喜歡待在新創公司,有點難體會『大』企業的轉型困難點,現在回頭看一下當年畫的筆記,多了不少感受。
工作中,Scrum 跑的對不對,不是最重要的事了。在看這一本書時,想到的大多是 2016 在某公司推廣 Scrum 的經歷,很多是在這本書都提到了,很適合想要推廣敏捷前,先讀的一本好書。
會後,我與其中一位創辦人聊聊他們 scrum 怎麼跑,以及程式、美術與企劃,這三種技能差異甚大的成員怎麼合作,他也苦笑,其實他們也花了很多時間磨合,但我們都提到,要引導團隊需要的不是 process,而是很多的軟技能,讓團隊自己能夠成長。
老實說,從中文書名無法聯想回原文書是《The Elements of Scrum》,雖然書名翻譯沒有太離譜(和內容無關之類的),但總覺得貼近原意會好一點。『Scrum團隊週記』這一章,整個讀完,其實就差不多可以了解Scrum的大部分,所以,若要讀這本書,又沒有太多時間,就先看這一章吧!
創業團隊就會很在意story的內容,會有相當多的意見,refinement meeting就是一個很好的場合讓大家把對需求的想法提出來,否則讓成員失去參與感,這對創業團隊是很大的傷害。
你可能也想看
Google News 追蹤
Thumbnail
接下來第二部分我們持續討論美國總統大選如何佈局, 以及選前一週到年底的操作策略建議 分析兩位候選人政策利多/ 利空的板塊和股票
Thumbnail
🤔為什麼團長的能力是死亡筆記本? 🤔為什麼像是死亡筆記本呢? 🤨作者巧思-讓妮翁死亡合理的幾個伏筆
Thumbnail
本書前半段說如何面對職場的微壓力,後半段說如何經營一個有意義的人生,我想每一個在工作的人都可以閱讀,不管是如何面對職場或是如何尋找有意義人生,都能找到自己能學習的部分 過去人類在危機來臨時會決定戰或逃,而現代人類沒有戰或逃的危機,取而代之的是24小時環繞在心頭的微壓力
Thumbnail
這本頁頁重點,我讀很久,絕對值得買回來細細研究。
/沒人喜歡焦慮,但沒人能拒絕焦慮,甚至“拒絕“這個舉動,就是最大的妄念,試著“淡化“而不是死死的握緊它刺傷自己的手心,這是我在無數黑夜裏反覆播片焦慮後,最大的感觸。/
Thumbnail
書店是一個很棒的地方,可以翻閱感興趣的書籍,吸收大家的故事和經驗。這篇文章分享了練習寫書摘的放鬆方式,並提到了在壓力中找到跟自己對話的方式的重要性。
Thumbnail
本書重點 1.企業如何與員工建立信任與忠誠的關係 2.聯盟關係應該運用在不同類型的員工和種類 3.企業如何與創業型員工建立關係 4.企業應該允許員工做那些拓展人脈和塑造個人品牌故事 5.運用企業校友會的網絡關係
Thumbnail
簡報已經變成職場必學求生術。我過去雖然曾經有到過教育部、社會局、法院做簡報的經驗,但是說到真正的「做簡報」這檔事卻是從進到企業開始學起。曾經有一次在企業簡報的經驗讓我自己意識到不同的場域對於簡報的重要性。在剛轉職到業界時,我高興的拿我製作好的簡報給Mentor確認。沒想到我的Mentor卻說..
Thumbnail
本書作者萊恩・霍克在高中、大學及職業美式足球隊擔任四分衛和隊長,當他轉戰企業界,也一路從獲獎的個人貢獻者,晉升為一家數十億美元企業的銷售副總。霍克累積超過300位思想最具前瞻性的領導者的深度訪談,融入自己從出色個人貢獻者蛻變為新手主管的經驗,提出一個務實、多面向、兼具內外的卓越主管養成三部曲架構
Thumbnail
接下來第二部分我們持續討論美國總統大選如何佈局, 以及選前一週到年底的操作策略建議 分析兩位候選人政策利多/ 利空的板塊和股票
Thumbnail
🤔為什麼團長的能力是死亡筆記本? 🤔為什麼像是死亡筆記本呢? 🤨作者巧思-讓妮翁死亡合理的幾個伏筆
Thumbnail
本書前半段說如何面對職場的微壓力,後半段說如何經營一個有意義的人生,我想每一個在工作的人都可以閱讀,不管是如何面對職場或是如何尋找有意義人生,都能找到自己能學習的部分 過去人類在危機來臨時會決定戰或逃,而現代人類沒有戰或逃的危機,取而代之的是24小時環繞在心頭的微壓力
Thumbnail
這本頁頁重點,我讀很久,絕對值得買回來細細研究。
/沒人喜歡焦慮,但沒人能拒絕焦慮,甚至“拒絕“這個舉動,就是最大的妄念,試著“淡化“而不是死死的握緊它刺傷自己的手心,這是我在無數黑夜裏反覆播片焦慮後,最大的感觸。/
Thumbnail
書店是一個很棒的地方,可以翻閱感興趣的書籍,吸收大家的故事和經驗。這篇文章分享了練習寫書摘的放鬆方式,並提到了在壓力中找到跟自己對話的方式的重要性。
Thumbnail
本書重點 1.企業如何與員工建立信任與忠誠的關係 2.聯盟關係應該運用在不同類型的員工和種類 3.企業如何與創業型員工建立關係 4.企業應該允許員工做那些拓展人脈和塑造個人品牌故事 5.運用企業校友會的網絡關係
Thumbnail
簡報已經變成職場必學求生術。我過去雖然曾經有到過教育部、社會局、法院做簡報的經驗,但是說到真正的「做簡報」這檔事卻是從進到企業開始學起。曾經有一次在企業簡報的經驗讓我自己意識到不同的場域對於簡報的重要性。在剛轉職到業界時,我高興的拿我製作好的簡報給Mentor確認。沒想到我的Mentor卻說..
Thumbnail
本書作者萊恩・霍克在高中、大學及職業美式足球隊擔任四分衛和隊長,當他轉戰企業界,也一路從獲獎的個人貢獻者,晉升為一家數十億美元企業的銷售副總。霍克累積超過300位思想最具前瞻性的領導者的深度訪談,融入自己從出色個人貢獻者蛻變為新手主管的經驗,提出一個務實、多面向、兼具內外的卓越主管養成三部曲架構