2023年07月03日 18:35:00
一、需求分析和管理
1、xp中採用"使用者故事"和"現場客戶"來收集需求和分析需求，原文中作者提出了一些質疑和一些改進建議，如客戶可能編寫不出足夠明確清晰、好的"使用者故事"，可以使用用例來替代"使用者故事"，無論哪種形式，關鍵是一種足夠清楚的簡單機制來完成需求的收集和分析。
2、如何控制和管理需求：需求一開始不必太細節，留到迭代中再精化。
1). 先把握系統的全貌。需求是不斷變化的，一開始定義乙個精確的包括全部功能定義的計畫，到迭代開發時可能這個需求已經開始變化，或者隨著業務領域的不斷熟悉，發現以前對這個需求的定義是錯誤的，就會造成了時間成本的浪費。這個我倒是深有體會，前乙個銷售管理系統專案，在專案開始時，開發小組花費了兩個多星期對整個系統進行詳細的分析試圖評估出"精確"的開發周期和詳細的開發計畫。事實上，到了各個迭代中，隨著我們對需求的理解和業務的深入，不斷的和使用者溝通收集需求反饋，很多需求都重新定義了，之前辛辛苦苦制定的開發計畫僅僅提供了乙個迭代內容劃分和週期的參考，其詳細需求內容的定義以及功能定義基本上毫無用處，白白浪費了很多時間。雖然說也並不是全無用處，不過這個成本未免也高了點。其實那個時候只需要花時間分析需求的主幹部分，並且把握主要風險作為考慮時間成本的參考，將詳細的需求分析分布到各個迭代中去，那麼專案拖延的時間可以更少。引用原文作為這個小段的結尾："不要在一開始就精化需求，一開始的工作重點應該是放在盡可能全面的收集用例，了解整體的業務流程，分析主體業務流程等工作上。在獲得了系統的全貌之後，你會發現你原先對系統的認識是不充分的，用例需要根據新的思路進行重新排列，用例的優先順序需要調整，在uml圖中，往往有一張系統的用例概覽圖，這張圖所表示的就是系統行為的乙個概述。"
2). 迭代精化，這個就不多說了，前面已經講過了。
3). 用迭代的思路來管理需求。如果迭代中原有需求發生了改變如何處理？一種情況是同一增量過程中（一次小發布）則直接在原有需求上進行補充，另外一種情況是不同增量中，這時候往往會加入新的需求、新的情境，一般來說，有兩種方法，一種是對原有的需求進行增補，增補的部分用不同的顏色或標記。另一種方法是為需求建立版本，如為用例建立版本，不同版本的用例對應於不同的增量週期。這樣，對應對n個增量週期就有了n個不同版本的用例（n≤n）。
4). 尋找優先順序高的用例進行精化。專案的前幾次迭代的主要目的是要識別出專案風險。因此，尋找有代表性、優先順序高的用例進行精化，能夠幫助開發人員更快的理解領域知識，構建起初步的領域模型。
5). 形式不是最重要的，採用用例或者使用者故事都可以，關鍵是需求要足夠清楚和易於理解。
3、關於業務知識（領域知識）的管理，我覺得可以用wiki來進行分類管理。這樣的好處在於專案組所有人都可以進行檢視以及增加修改這些業務知識，萬一不記得相關業務知識了就可以馬上進行溫習，這個對於沒有條件擁有"現場客戶"的專案很有用。我們公司的技術經理採用論壇的形式來保證業務知識的積累，使用者和開發人員都在論壇上進行需求溝通，這個也不錯，不過這種方式有一種缺點，由於論壇的形式的發散型的，所以如果沒有乙個彙總的機制，很容易造成業務知識的海量堆積，而且各個知識點都分布在乙個乙個的帖子中沒有集中管理，不便於檢視。可行的一種方式是一段時間中就將業務知識從各個帖子中匯集起來，集中儲存在乙個或者幾個置頂的帖子中，便於開發人員檢視。不過個人感覺這種方式還是沒有將業務知識彙總到wiki中直觀。
二、迭代過程管理
1、簡單設計，增量開發。初期不要花太多時間到框架設計上，理想的情況是，你已經擁有了乙個可重用的框架（或是架構），這樣，可以將專案的需求對映到框架上，而不是在專案一開始的時候花時間來開發框架。如果沒有框架，在專案一開始的時候，花費一定的時間來開發架構，但是這個時間不宜過長，這個完全可以在後續的增量中對架構進行改進，所以不用急於一時。
2、盡可能早的發現所有的問題。這個問題似乎原文作者也沒解釋清楚如何進行，如何在"盡可能早"的發現"所有的問題"似乎很難有具體方法實踐。
3、結合上次專案實施過程中遇到的問題我的關於迭代概念的疑惑
1). 老大要求在專案需求分析完成後提供乙個內容包括整個發布的迭代劃分以及每個迭代的週期的發布計畫，這也就是為什麼在專案開始的時候花了很多時間來做需求的詳細分析和系統詳細的功能定義，就是為了得出乙份足夠準確的發布計畫。但結局如上面所說的，實際開發超出了發布計畫很多。xp提倡在一開始只是粗略的計畫，只要求能夠大概的分析出迭代劃分和週期，在後面乙個乙個的迭代中逐漸完善計畫，從而得到較為準確的發布週期。這樣有必要在一開始花上比較多的精力制定乙個後面不能修改調整的發布計畫麼，這樣不是和敏捷思想背道而馳了麼？似乎這個發布計畫應該是個粗略的計畫，應該隨著前面幾個迭代的進行不斷的調整，如根據前幾次迭代所花費的時間評估出後面迭代所需要的時間，隨著迭代的進行發布計畫也越來越準確，使用者也就越來越了解專案進展情況和把握總體進度了。
2). 如果在某個迭代中，由於內部原因或者技術原因導致本應該在此次迭代中完成的功能沒有完成怎麼辦，是延長本次迭代時間還是推遲該功能到下個迭代？xp提倡當到了乙個小發布 dead line後就停止所有工作，將可以發布的功能先發布，將未完成的功能延遲到下個迭代。但是事實上，在我們專案中，由於專案組成員還有來自客戶公司的職員，出勤率很不穩定，所以他們的工作經常不能按時完成，並且，由於他們沒完成導致可發布的內容很少（因為他們都是做使用者層的介面，所以即使業務邏輯完成了沒有介面也不能發布），我們不得不採取延長迭代時間，由專案組的其他成員來完成未完成的工作。這樣做導致了專案進度非常不可控，使得專案經理無法有信心的把握整體進度，專案經理甚至無法正確的評估出這個專案什麼時候可以結束，怎樣處理這種情況？
三、測試管理
1、測試應該貫穿專案的整個過程
1). 需求階段就開始搭建測試環境，所有的需求是可測試的（比如可測試的用例），準備測試資料；這個不清楚如何具體操作。
2). 精益程式設計要求全面質量管理，即生產過程的每乙個環節都需要為質量負責，而不是將質量問題留給最後的質檢員
2、測試優先（tdd）
1). 使得系統結構為可測試的架構，適合於測試的**，這個可以使得後期維護簡單
2). 堅持測試優先的實踐，可以使你從乙個外部介面和客戶端的角度來考慮問題，這樣可以保證系統各個模組之間能夠較好的連線在一起
3). 測試優先的好處在於由於先必須寫測試，而測試的難點往往在於難於模擬出環境，因此可以迫使開發人員在測試階段就考慮將環境因素和業務模型隔離開來，提高業務層的可測試性，設計出與環境低耦合的設計。還可以借助 mock object 對一些非主幹的領域模型與主幹業務邏輯的互動和協作進行測試，降低編寫測試用例的成本。原文中提到的"有時候，單元測試或是元件測試是很難進行的。因此，我們需要專門針對類或元件的可測試性進行測試。例如，對於乙個實現企業流程的元件，之間涉及到大量的狀態、事件、分支選擇等等因素。對這樣的元件進行元件測試的代價是非常高的。如果能夠在元件設計的時候，能夠考慮到測試性，例如，將元件拆分為粒度更小的子元件，或是在元件中內嵌供測試使用的方法，能夠直接操縱元件的狀態。在設計時充分考慮可測試性，是降低測試成本的關鍵。"蠻有道理的。
4). 嚴格按照先改測試**然後維護設計**，關鍵是養成這種測試優先習慣，或者說一種思維方式。
5). 完善測試網，一開始採用測試驅動的專案，隨著專案的進展，後期的測試**越來越優秀，這時有必要重構以前的測試；如果一開始沒有採用測試驅動的專案，在專案的中期也很有必要投入人力將現有的**加上測試。在這些重構過程中還可能會發現原來**中一些bug或者說不合理的設計，這樣的好處是明顯的。
6). 現實開發過程的測試資料通常比較複雜，有必要準備單獨的資料提供類，當測試用例很多的時候，有必要專門的機制來生成和管理測試資料；甚至花點時間構造乙個測試框架也是很有必要的。
7). 自動化測試，有了自動化測試就可以實現回歸測試（版本2出現了版本1不存在的行為稱之為回歸），持續整合和每日構建必須要加入自動化測試，否則則失去其一大半的意義。
3、結合上次專案實施過程來談談我對測試管理的看法
1). 沒有單元測試，黑盒測試如噩夢一般。專案為c/s三層介面，使用者層是用.net的winform開發的，業務邏輯層主要集中在oracle儲存過程，web服務只是一層包裝，測試的目標鎖定在使用者層的winform和oracle的儲存過程上，由於專案比較緊，又沒有找到合適的winform和oracle儲存過程的單元測試框架，加之客戶公司的專案組成員以往沒有這種程式設計經驗，所以沒有加入單元測試，更別說自動化測試了，質量是通過專案組成員之間的結對審核和開發人員、測試人員的手工測試來保證的。如上所說的，專案組成員能力和素質的良莠不齊，噩夢開始了。在前幾個迭代，專案經理忙於需求分析和主要框架設計，其他成員的能力缺陷體現出來了，已經準備發布的**，到最後發布測試的時候全部出現了問題，專案經理到最後成了捉蟲專家，這個bug解決了那個bug又出現了，最後所有人的信心降到谷底，迭代被一次又一次延長。到專案的中後期，為了保證交付的**的質量以及發布過程的順利，專案經理在所有人完成整合測試後加班再測試一遍，儘管如此，系統在每個發布後還是存在很多bug。所以，由此我深深的感到，單元測試非常重要，自動化測試非常重要，完整的測試可以使得質量變得可控，否則僅僅通過黑盒測試一些隱藏的bug很難發現。單元測試是測試的乙個最小單位，最小單位的測試能夠做好，全系統的測試就能夠做好。
2). 測試要自動化，持續整合和每日構建中一定要加入自動化測試
3). 在有能力的情況下專案一開始就要引入測試驅動，任何學習成本的前期投入是值得的，因為這對於後期維護來說的好處是明顯的，而且可以更好的對迭代過程中質量進行控制。可測試的設計其實就是松耦合的設計，引入測試驅動可以使得系統架構低耦合，也可以使得開發人員在過程中由單純實現編碼變為理解系統設計、完善設計。
（未完，待續）
Scrum心得以及實踐
一 學習scrum心得 作為乙個並未有過太多專案經驗的準程式設計師，也是第一次接觸到scrum敏捷軟體開發。以下是個人對其的看法 從乙個scrum開發團隊成員來看，也確實很合理。分工明確，豬 和 雞 的角色將開發人員與使用者拉近距離，方便產品的功能友好 完善和人性化。加強產品的市場競爭力。迭代週期縮...
學習陣列心得以及初識物件
在呼叫函式階段學習後，發現很多算式都是幾個條件就能完成的，然後巢狀一下，達到目的，比如36人搬36石頭的案例 public class homework7 在對陣列的實現熟悉後，就是乙個個的迴圈，難點在於巢狀迴圈的次數，要盡量在腦子裡演練，每次迴圈，函式做出的事情，以及迴圈次數的減少和增加，很容易繞...
Unity中prefabs的學習心得以及應用理解
最近這段時間一直在自學unity，作為乙個零開發經驗的小白來說，除了對遊戲的熱愛之外，基本上沒有什麼能拿得出手的東西了。因為時間有限，零零散散地起了個步，每天都感覺能有所收穫就很知足。那麼為了防止自己健忘，就順手寫了個心得體會，對不對的大家多指正批評。話不多說，先記錄一下prefabs的用法。pre...