書摘《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

52會員
102內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
留言0
查看全部
發表第一個留言支持創作者!
Spirit的沙龍 的其他內容
User Story Refinement
閱讀時間約 9 分鐘
軟技能
閱讀時間約 2 分鐘
書摘《全員敏捷》
閱讀時間約 10 分鐘
書摘《原來你才是絆腳石》
閱讀時間約 9 分鐘
你可能也想看
書摘《聯盟世代》:新世代勞資關係思維的典範轉移本書重點 1.企業如何與員工建立信任與忠誠的關係 2.聯盟關係應該運用在不同類型的員工和種類 3.企業如何與創業型員工建立關係 4.企業應該允許員工做那些拓展人脈和塑造個人品牌故事 5.運用企業校友會的網絡關係
Thumbnail
avatar
鄭智維 Wesley
2023-02-28
書摘《忘形流簡報思考術》:做簡報時千萬不要想怎麼做簡報簡報已經變成職場必學求生術。我過去雖然曾經有到過教育部、社會局、法院做簡報的經驗,但是說到真正的「做簡報」這檔事卻是從進到企業開始學起。曾經有一次在企業簡報的經驗讓我自己意識到不同的場域對於簡報的重要性。在剛轉職到業界時,我高興的拿我製作好的簡報給Mentor確認。沒想到我的Mentor卻說..
Thumbnail
avatar
鄭智維 Wesley
2023-02-25
書摘《歡迎進入管理階層》:成為優秀主管必經的學習任務本書作者萊恩・霍克在高中、大學及職業美式足球隊擔任四分衛和隊長,當他轉戰企業界,也一路從獲獎的個人貢獻者,晉升為一家數十億美元企業的銷售副總。霍克累積超過300位思想最具前瞻性的領導者的深度訪談,融入自己從出色個人貢獻者蛻變為新手主管的經驗,提出一個務實、多面向、兼具內外的卓越主管養成三部曲架構
Thumbnail
avatar
鄭智維 Wesley
2023-01-31
書摘-《孤獨的冷漠:逃避型依戀障礙的分析與修復》前言   活了30幾年終於要正式自身的問題,於是大量的找這類型的書籍來了解。看到書中許多有共鳴的分析句子或情境,心臟會隱隱的抽痛;我想,那會不會是身體在告訴我,過去真的積壓太多情感。   只有我自己才能成為自己最堅強的後盾!現在的我,是這樣想的。於是,正式開起了這段探訪自我之旅。
Thumbnail
avatar
川流大海
2022-08-30
書摘-《情緒的驚人力量》前言   前陣子又迎來新一輪的"心理低潮",開啟了自我否定及頹喪的模式。這種輪迴模式持續多久了呢? 似乎從幼稚園、國小、國中...出了社會,直到現在快35歲了,模式仍然持續著。每次只要一但開啟這個模式,迎面而來的就是不可自控的焦慮、惶恐、絕望、失落、無望,連呼吸都覺得費力。 讓感覺變成指引。 結語
Thumbnail
avatar
川流大海
2022-08-27
書摘《遠距團隊的高效領導法則》:遠距工作是組織文化與個人紀律的試煉受到疫情的影響,許多企業嘗試遠距工作、在家工作或是混合辦公方式持續維持營運,但疫情逐漸消退後的「後疫情時代」,卻發現員工已回不了辦公室。過去我們的生活是圍繞著工作所建構,例如交通、住屋、生活圈都以工作為考量遷移。然而疫情期間,生活反倒成為了重心,各式工具滿足在生活中工作的需求,人們關注工作生生活
Thumbnail
avatar
鄭智維 Wesley
2022-05-31
書摘《生存的12條法則》你可以思考這句話:人生沒有什麼問題......或許你想要的東西阻擋你看到別的可能性
Thumbnail
avatar
司馬儀
2021-08-11
書摘《訂閱經濟》將顧客轉換為訂戶(subscriber),以創造經常性收入。稱為「訂閱經濟」(Subsrciption Economy)。
Thumbnail
avatar
two
2019-10-17