2023年11月開始了休長假回來後的第乙個專案。也是我職業生涯中的第乙個敏捷專案。本人在專案中擔任需求分析。 專案啟動已經五個多月，目前一切執行樂觀。閒來覺得有必要總結下人生中第乙個敏捷專案，於它人可以取良去莠， 於自己可以沉澱一二。
回想一下之前做過的專案都是用瀑布+迭代。 需求收集用瀑布。即盡量在需求收集時期定義到所有需求的所有細節，產出產品需求說明書。開發階段採用迭代。即把需求劃分為多個模組，分sprint 開發。所以不同之處主要在於需求收集和需求管理，其次是才是開發，再次是測試。下文將在需求，開發和測試三個方面總結。
在這個敏捷專案裡，我們棄用了之前公司專案一直在用的產品需求說明書。直接用乙個個使用者故事來呈現功能需求。 這點到是為我省了很多事。 之前我們產出需求文件的過程如下：
1. 和客戶溝通，產出功能點列表。(這個列表一般在銷售階段會由銷售團隊完成，用來做專案估算。後期需求細化也是以這個列表作為基準。)
2. 根據功能列表溝通詳細需求。期間產出使用者介面，多個產品功能需求規格書。
3. 將功能需求規格書拆分成便於開發任務分派的使用者故事。
現在，需求收集階段直接產出乙個乙個相對獨立的使用者故事就省去了絞淨腦汁分割需求的過程。尤其當需求規格說明書章節沒分配好，各個章節相互牽連重複時，分割需求的過程就會尤其痛苦。儘管如此，在專案開始前期，團隊對用使用者故事管理需求上有很大的爭議。對使用者故事管理需求提出的問題、最終討論出的解決方案及實際操作後的效果如下：
問題一：
乙個個使用者故事太散。 新人沒有系統的需求文件學習系統的需求 (話說實際情況也沒哪個新人進專案後會系統的學習需求。都是只看自己負責那部分) 需求查閱也不方便。比如想起來要查閱某個需求點，在使用者故事的茫茫大海裡怎麼找？
解決方案：
用記故事地圖。 繪製乙個使用者故事地圖大概相當於需求文件的章節索引。找某個需求點或想系統學習需求時可以從使用者地圖裡找。
實際效果及問題總結：
問題二：
使用者故事直接建到工作系統(jira) 裡作為ticket使用，沒有用文件記錄。使用者故事的狀態反應對其進行開發的狀態。如開發完成，那使用者故事的狀態會被置為關閉。如果乙個使用者故事關閉後發生需求變更，該怎麼處理？
解決方案：
如果需求變更時使用者故事還沒有關閉，那就在原始使用者故事上改需求描述並進行開發。如果使用者故事已經關閉，那就建立新的使用者故事描述新的需求。
實際效果及問題總結：
對正在開發過程中的使用者故事進行修改，要事先和開發溝通好。避免造成修改的部分沒被開發注意到。同意也要通知到正在準備測試用例的同學， 以便測試用例同步更新。
問題三：
如何統計需求變更? 比如某天專案要求統計出專案的需求變更(做了五年的專案貌似只被要求過一次)。對於新建的需求變更使用者故事上加乙個標籤就很容易被統計出來。但是對於在原始使用者故事上進行改動就統計不出來。因為在整個原始使用者故事上加標籤不合理，尤其當只有很小的一部分使用者故事需求發生發動時。
解決方案：
需求變更控制沿用非敏捷時期的變更控制流程。控制流程圖附入下文。該流程中會使用需求變更表單文件記錄需求變更內容和實現變更需要時間和客戶應該付的額外經費。需求變更文件配合變更列表就能很好的追蹤和統計需求變更。
實際效果及問題總結：
任何流程都是為了有章法地解決問題。不能被流程綁架。比如在該專案實際執行過程中pm這段基本是由ba來完成。
判斷是否是乙個收費的cr的標準有些是用審批過的需求文件作標準，有時是用項簽訂專案合同時的功能列表作為標準。
問題四：
在系統中檢視使用者故事查閱需求時如何時知道這是不是最新的需求？
解決方案：
使用者故事可能在關閉後發生需求變更。這種情況下已關閉的使用者故事裡的描述是不允許更改的。
jira 系統裡的ticket 有相互鏈結的功能。如果乙個使用者故事在關閉後發生變更，必然會有新的使用者故事ticket 產生。把新的使用者故事鏈結到已關閉的使用者故事即可解決。
需求變更產生的使用者故事在ticket 在使用者故事名稱上加明顯標識有助於快速找到需求變更對應的使用者故事。如change - [story name]
問題五：
專案要求用文件記錄需求。方便某些人不想用使用者地圖+jira 系統檢視需求時可以直接用文件搜尋。
解決方案：
把使用者故事按故事地圖為章節複製到文件裡。
實際效果及問題總結：
文件生成後並和系統裡的使用者故事同步更新耗費時間。目前為止，沒有任何專案成員去看過這個文件。暫時沒看出來這個文件存在的意義。如果專案不要求在某階段必須產出這個文件，可以在每個sprint 結束時把sprint 裡關閉的story 複製到文件裡。乙個sprint 乙個sprint 地去做。這樣可以節約更新文件的時間。因為關閉的story 需求變動的可能性比較小。
開發方面我們並沒有嚴格按敏捷的定義做法。比如估算story point, 我們並沒有讓幾個開發坐在會議室大家亮出自己的估算，最高和最低的分別解釋估算的理由，然後協商達成一致。story point 估算基本都是team leader 在sprint 開始前自行決定。
測試流程和之前一樣，沒什麼影響。
附圖：search / browsing 功能點劃分(tbd表示除search 和browsing 以外的功能點 )
我的第乙個專案 迭代開發總結
思考總結 設想和目標 1 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？我們軟體很明確的定義為，製作乙個變電站向量圖形編輯器 典型使用者 變電站管理員 典型場景 2 我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到...
我的第乙個hbulider專案
7月3日實訓第一天 實訓內容 五子棋遊戲 達州的天氣真的不是一般的熱，分分鐘就可以把人熱化，就這樣我們帶著沉重的腳步開始了我們第一天的實訓，老師叫李胤，剛開始我還不知道這個字怎麼讀，很尷尬啊，是乙個比較幽默的老師，希望和老師有乙個愉快的實訓。我們學習h5，說實話我們之前還沒有接觸過h5 學的還是基本...
我的第乙個PyQt專案
環境 python 3.6.0 pyqt5.9.1 pycharm 功能 1.選單欄 有control和help兩個選項 2.狀態列 3.退出詢問 import sys from pyqt5.qtgui import from pyqt5.qtwidgets import class mainwin...