顯示具有 需求管理 標籤的文章。 顯示所有文章
顯示具有 需求管理 標籤的文章。 顯示所有文章

2023年11月2日 星期四

《你問對問題了嗎?》金句

 1. P11 問題找上你時往往已經有預設立場。現實生活中多數問題都是如此,早有人為你訂下框架。

2. P12 重組問題框架,這套方法的核心就是要你違反直覺:面對困難問題時,先別急著找解決方案。你該做的是把注意力放到問題本身,不僅要分析問題,更要改變思考問題的方式。

3. P20 願意試著解決問題的人,往往有著「樂觀」的基本特質。他們遇到困難時不會直接任命,相信一定還有更好的解決方案,也相信自己有能力把它找出來。

4. P21 想擁有強大的重組問題框架能力,重點不在於注意細節,而在於能夠看到全局、有能力從多個不同的觀點來思考。

5. P27 在絕大多數案例中(特別是日常生活的問題),解決問題的重點並不在於科技,而是在於心理上的突破。因此,解決棘手問題的關鍵未必是那些細節,而是詮釋與意義建構的能力:我們要觀察已經存在的東西,並重新思考它的意涵。重點在於要對自己的信念提出質疑、對長期以來的假設提出挑戰,不論是關於同事、客戶、朋友、家人,或者我們自己。

6. P27 「重組問題框架」...具體好處...:

  • 你能夠避免去解決「錯的問題」
  • 你會找到創新的解決方案
  • 你能做出更好的決定
  • 你能拓寬自己的職涯選項
  • 你能協助創造一個更健康的社會
7. P28 問題不一定只能這樣解決。如果認定問題只有一個「根本原因」,就可能造成誤導。問題的成因多半不只一個,解決方式更是不勝枚舉。

8. P28 「重組問題框架」並非為了找出「真正的問題」,而是要找出一個「更好的問題」來解決。

9. P28 研究顯示,若你想解決問題,最好的辦法就是找出更多選項。...如果只已是非題的角度來思考,做出壞決定的機率會超過一半。...如果是以選擇題角度來思考,做出壞決定的機率就會降到 1/3。...只要帶進更多選項,就有助於讓你做出更好的判斷。...多個選項必須真正有所不同。

10. P30 如果想要真的解決衝突、讓大家長久和平,就需要幫衝突各方找到共同的立足點。這得先搞清楚大家到底是在吵什麼,而不是直接吵要怎麼解決。

11. P31 如果能提升對問題框架的理解,就更能察覺是否有人在試圖操控你。

12. P33 想有效解決問題,需要不斷循環重複三個步驟:
  • 建立問題框架(以及重組框架):決定該把焦點集中在哪裡
  • 分析問題:深入研究以選定的問題框架,試著加以量化並了解進一步的細節。
  • 解決問題:實際開始處理問題;內容包括進行實驗、製作原型、最後實施完整的解決方案。

13. P33 想找出對某個問題的新觀點,有兩種方法:
  • 深究框架:想重組問題框架的時候,先深入研究原本的框架細節。
  • 打破框架:直接跳出原本的框架,採取完全不同的觀點。

14. P33 解決問題的重點不一定都在於科技。有時候無需找到新的科技,只要質疑自己過去所相信的概念,就有可能找到新的解決方法。

15. P33 找出不同的選項,就能提高決策的品質;但前提是這些選項必須確實不同。

16. P41 (重組問題框架中找出其他問題框架的策略:)
  • 跳出框架:我們缺了什麼?
  • 重新思考目標:有沒有更好的目標?
  • 檢視亮點:有哪些地方沒遇到這種問題?
  • 照照鏡子:在這個問題的形成中,我/我們扮演什麼角色?
  • 以他人觀點思考:他們的問題是什麼?
17. P42 重組問題框架的時候,你確實可以一切都自己來(有時候這也是很好的起點,可以先整理自己的思緒),但通常還是該盡快讓其他人也參與。讓其他人(特別是想法與你不同的人)也參與,就等於找到一條通往不同觀點的強大捷徑,能讓你更快找出自己思維的盲點。

18. P45 大家通常都以為自己的問題需要詳細解釋才說得清楚,但為了要快速告訴別人自己的問題,就只能提出更高層次的問題框架,因此反而不回對後續的提問造成限制或引導。

19. P45 如果一開始就先顧慮利害關係人,最大的問題在於可能會完全搞錯到底誰算是利害關係人。

20. P46 如果企業太過專注於了解與服務現有客戶,就會在無意間使自己的產品對非客戶來說變得沒那麼好用,於是讓競爭者獲得進入市場的機會。

21. P47 提問之所以重要,是因為它反映出一顆好奇的心靈。會問問題,代表你知道這個世界遠比目前自己的心智模式(mental model)所暗示得更深、更複雜。

22. P47 請試著去思考每項策略背後的本質:「提出這些問題背後的目的是什麼?」請把重點放在「該怎麼想」,而不是「該怎麼講」。

23. P61 真正開始設法重組問題框架之前,最好先針對問題陳述,重新全面檢視一次。
  • 陳述是否真時?
  • 問題框架本身是否自我設限? (有時你只要讀讀自己的問題陳述,就會發現問題本身已經造成許多不必要的限制。)
  • 問題框架是否「預設」某種解決方案?
  • 問題夠清楚嗎?
  • 目前認定問題出在誰身上?
  • 問題陳述是否帶有強烈的情緒?
  • 是否帶有錯誤的妥協?
24. P80 犯罪推理小說家 Rita Mae Brown 曾說:「所謂精神錯亂,就是把同樣的事做了一遍又一遍,卻期待能有不同的結果。」(Insanity is doing the thing over and over again, but expecting different result.)

25. P88 面對每個問題時,記得要跳出框架:
  • 不要拘泥在明顯的細節
  • 想想看目前的問題框架可能遺漏什麼

26. P89 別忘了槌子定律:我們思考問題時,常常會遷就於自己心有所屬的解決方案。

27. P98 高層次的目標將會很有幫助,然而就算只是個人問題,「提出較高層次的目標」也能有所助益,原因就在於人們常常不完全了解自己想要什麼。

28. P116 從平凡中找答案,而不要從特例中找答案。

29. P125 將問題公告周知的三個技巧:
  • 避免使用技術語言:這樣一來,就算不是你這一行的人,也能聽懂問題
  • 提供大量情境脈絡資訊:為什麼解決這個問題很重要?目前的主要難處為何?你試過那些方案?
  • 不要把解決方案說得太明確:與其說:「我們需要更便宜的鑽井方法」,不如說:「我們需要為120萬人提供乾淨的飲用水」(實現這個目標不一定要有井)。
30. P125 我們往往會有「負向偏誤」(negativity bias)的陷阱,傾向關注壞事並忽略好事。所以一旦遇到問題,我們天生會將注意力集中在事情出錯的地方,也就無法從當時做得好的地方學習。

31. P140 哥倫比亞大學心理學家 Adam Galinsky 等人已經證實,擁有權力的人理解他人觀點的能力會下降。如果想讓眼前的問題得到真正準確的觀點,就可能需要引進外部人士。

32. P143 把重點放在各種貢獻,而不要去急著指責某人。各種問題可能是因為眾人所導致,其中也可能包括你在內。

33. P156 鎖定使用者「感受到的問題」。受眾在乎的不是你提出什麼解決方案,而是他們面對著怎樣的問題。

34. P161 記得要考慮其他人。不要把自己的喜好誤認為他們的喜好。對了,還得考慮他們會不會其實是個好人、只是想盡力把事做好。

35. P186 檢視問題框架時,請特別注意有沒有以下特色:
  • 令人意外
  • 簡單
  • 是真的就太不得了了
36. P187 就本質而言,「重組問題框架」就是要挑戰你對問題的假設和信念。

37. P220 一旦你過度迷戀自己所提出的理論,就會對其中的缺點視而不見。



2023年10月31日 星期二

《Specification by Example 中文版:團隊如何交付正確的軟體》金句

 1. P3 在實作敏捷開發的程序中,團隊碰到的問題通常都很少用文字記載下來,所以每一個受挫的團隊都認為,自己遇到的問題比較特殊,而這些理念無法在他們的「現實世界」裡發揮作用。

2. P5 比爾·蓋茲說過:「在企業中應用任何一項技術時,首要的法則是,在有效率的系統中導入自動化,將使效率倍增。第二條法則是,在缺乏效率的系統中導入自動化工具反而導致他們的程序更於低效。」

3. P7 Eric Evans 跟別人爭論說敏捷作為一個術語已經失去了一切意義,因為現在什麼都可以稱為敏捷。(skillsmatter.com/event/design-architecture/ddd-exchange-2010)

4. P8 一個好的名稱能夠將預期的結果說明的更好,而且還能清楚指出這些實踐作法的關鍵差異。

5. P13 變化速率如此之高,說明文件總是很快就過時。不斷更新詳細的Spec.(Specification,需求規格)和測試計畫(Test Plan)需要投入大量精力,相當浪費。以此維生的人們(例如:業務分析師或測試人員),在這個每周更新的環境中經常會無所適從。

6. P23 加快循環並不能避免錯誤。

7. P31 許多團隊在開始實作軟體之前(在此之前所發生的一切往往會被軟體開發團隊所忽略),總期望客戶、產品負責人或商務使用者能先確定工作的範圍。...若軟體交付團隊依賴客戶給出使用者故事(user story)、使用案例(use case)清單或其他相關資訊,那麼他們其實是在『讓客戶設計解決方案』。但是商務使用者不適軟體設計師。如果我們讓客戶去界定範圍,專案就無法從交付團隊已有的知識中獲益。這樣開發出來的軟體是客戶所要求的,『卻步是他們真正想要的』。

8. P31 成功的團隊不會盲目地接受軟體需求,並將其當作是未知問題的解決方案,相反的,他們會從目標中獲取範圍。他們以客戶的業務目標為起始,接著經由協作來界定可以達成的目標範圍。團隊與商務使用者一起工作確定解決方案。商務使用者則專注於傳達所需功能中希望達到的目的,以及他們期望由此帶來的價值,這樣有助於所有人了解所需的功能。然後再由團隊提議一個解決方案,這要比商務使用者想出來的方案更實惠、更快,並且更容易交付或維護。

9. P31 設計Spec.的階段,如果開發人員和測試人員都沒有參與,我們就必須單獨將Spec.傳達給他們。這在實踐上會很容易造成一些誤解,尤其是資料遷移期間會遺失很多細節。...成功的團隊不會依賴某個獨自去收集正確的Spec.,而會與商務使用者一起協作制定解決方案。

10. P32 過多的細節會讓實例更難溝通和理解。有用的關鍵實例必須要精簡。...提煉好的實例可以當作交付的驗收標準。只有當所有實例在系統中都可以正常工作時,開發才算完成。

11. P36 可執行的Spec.可以很容易地驗證系統。如果能頻繁地驗證就能信任可執行的Spec.,就如同信任程式碼一般。

12. P36 最成功的團隊部會滿足於頻繁驗證一組可執行的Spec.。他們能確保Spec.清楚明確,便於尋找和獲取,而且還具有一致性。...Living documentation(活的說明文件)對於系統功能而言,是個可靠且權威的資訊來源,任何人都能夠讀取它。

13. P37 商業目標是專案或專案里程碑的潛在原因。它是指導企業專案關係人(無論是內部的還是外部的)決定是否投資軟體開發的因素。商業組織應當能清楚地看到這些目標能如何賺取、節省或保障財富。....可衡量的目標能夠確認專案的成敗、追蹤進度和改善優先順序的排序。

14. P39 當整個使用者故事完成時,需要進行首次驗證來確保其確實完成,並重組Spec.證實它和已時做功能的Spec.一致。

15. P43 注重編寫和執行測試的團隊往往會編寫出不易維護的測試。隨著時間的推移,許多問題會迫使這類型的團隊去尋求制定測試並將測試自動化的方法,以便讓測試更容易更新。

16. P84 從目標中獲取正確範圍的好方法之一,就是堅定不移地把提供解決方案的責任交付給開發團隊。

17. P85 我們應該詢問高層次的實例,來說明某個功能要如何產生實際價值,而不是去詢問技術上的功能Spec.。這才能指引我們找到真正的問題。

18. P86 有時候,要人們解釋某個功能的價值時,仍會發生困難(即便可能僅是要求提供實例)。更進一步,我會請他們舉例說明,如果系統不提供某個功能,他們該怎麼辦(臨時解決方案)。通常這會幫助他們表達出特定功能的價值。

19. P86 較低層次的Spec.和測試可以告訴我們已經交付部分的邏輯是否正確;而較高層次的驗收測試則可以告訴我們那些部分的元件是否按預期方式工作。

20. P93 讓團隊全體參加大型的『Spec.的Workshop』是建立共識並獲取可解釋功能之實例最有效的途徑之一。

21. P94 《Practices for Scaling Lean and Agile》一書中,Bas Vodde和Craig Larman建議PBR的Workshop應該佔每個Iteration中 5%~10%的時間。

22. P95 若領域的邏輯很複雜,程式設計師和測試人員需要頻繁釐清,...。《Agile Testing》一書中提到一個類似的協作模型,叫做「三個人的力量」。...舉辦小型的Workshop,由一個開發人員,一個測試人員和一個業務分析師參與。...想要有效地舉辦一場「神勇三劍客」會議,與會的三個人必須在該領域上有相似的理解。如果他們沒有達到相似的理解,可以考慮讓大家在會前做好準備,而不是隨時舉辦。...「神勇三劍客」會議的結果是一份實際的功能檔案--Given-When-Then。

23. P105 確定初始的實例能說明我們獲得Spec.的基本結構,並可以讓討論更有效率。

24. P113 舉例說明,範例必須精確、範例必須完整、範例必須真實、範例應該易於理解。

25. P129 Edward Jay Epstein,The Diamond Invention:「原鑽飾無光澤的、半透明的晶體,類似於玻璃碎片。為了加工成首飾,必須把它切割成特定的寶石形狀,再一面一面的拋光。」

26. P130 成功的團隊不會直接使用原始的例子,他們會從中提煉Spec.(Refining the specification)。他們會從關鍵實例中提取精華,將其轉化成清楚且明確的定義,並去除不相關的細節,讓實作變得完整。

27. P130 附帶實例的Spec.即為驗收測試。一個良好的Spec.,再與實例結合後,其實就是有效的驗收測試所描述的功能。

28. P142 Spec.只需列出關鍵且具有代表性的實例。這有助於Spec.保持簡短易懂。關鍵實例通常具備以下特點:

  • 它是一個具有代表性的實例,其描述了業務功能中的每一個重要觀點。通常商務使用者、分析師或客戶會對其進行定義。
  • 它會描述每個重要技術的邊緣情況,例如:技術上的邊界條件。通常當開發人員擔心功能分期或不一致時,他們會使用這類的範例。商務使用者、分析師或客戶則會對其定義正確的預期行為。
  • 它會描述愈其實作中每一個棘手之處,例如,過去曾導致缺陷的情況,或以前的實例中未描述清楚的邊界條件。通常測試人員會列舉出這種範例,而商務使用者、分析師或客戶則會定義其正確的行為。

29. P144 在需求規則中使用「Given-When-Then」語言,目的為讓測試更容易理解。一般來說,一個Spec.應該要聲明背景環境,指定一個單一的動作,接著定義預期的後置條件。...Given-When-Then市定易系統行為的一種常見格式,它由早期關於BDD的文章推廣而來。它要求我們分成3個部份來編寫系統行為的場景:

  • 假設(Given)一個前提;
  • 當(When)某個行為發生時;
  • 接著(Then)後置條件就會得到滿足。
一次只會觸發一個動作是置關重要的。這可以確保Spec.只聚焦於該動作。

30. P150 問題的癥結不在於工具;同時,解決方案也與工具無關。問題主要是團隊未曾努力於讓Spec.變得更易於理解。提煉Spec.無須花費太多努力,卻可以帶來更多的價值。

31. P157 務必為生產力的降低做好預先計畫。為了在當前 Iteration 內完成自動化,團隊必須減少交付範圍。

32. P160 剛開始使用 Spec.實例化時,如果團隊成員質疑自動化的必要性,那你們可以嘗試透過UI來執行Spec.。請注意,不要修改Spec.用描述與UI交互作用之處,但你可以在自動化層(Automation layer)裡隱藏這些動作。

33. P162 追根究柢,要取得成功,更重要的是要解決如何建置正確的東西,而不是正確地建置。

34. P162 附帶實例的Spec. (Specification with example) -- 最終會以 Living documentation形式存在 -- 比生產程式碼存在更久。

35. P171 如果你的可執行的Spec.是以與UI元素的交互作用來描述的,那Spec.中請只敘述UI的功能。

《OKR:做最重要的事》金句

金句列表 美國洋基隊傳奇捕手 Yogi Berra:「如果你不知道自己的目的地,就可能無法抵達。」 點子不值錢,執行才是關鍵。(p.16) 「OKR」,全名是「目標與關鍵結果」(Objectives and Key Results)。它是一套設定目標的守則,適用於公司、團隊和個人...