敏捷開發框架下的軟體工程/第一輪迭代/知識庫
| 知識庫 |
|
|
設計規範是將互動設計中看似模糊的想法細化為詳細的藍圖，以便交給程式設計師。
在敏捷開發框架的第二輪迭代中，設計規範是我們可以給程式設計師的詳細指令（認識到，在許多情況下，這實際上是我們戴著另一頂帽子）。在第二輪迭代中，我們將致力於第一個“功能交付”，並將開發詳細的螢幕介面佈局、資料結構和系統圖表等等。類似地，在第三輪迭代中，其結果是“穩健交付”，我們將擁有所有這些，再加上詳細的測試規範。
那麼，我們在第一輪迭代中做什麼？請記住，第一輪迭代的目的是在團隊（包括客戶）中生成資訊流，並加深對我們正在處理的問題領域的理解。我們即將進行的實施是構建一個原型，以幫助我們實現這些目標。原型，根據定義，具有明確的目的：我們這樣做是為了回答具體問題（而不是第一次嘗試失敗）。
這個原型有兩個主要目的
1. 一個快速實現，用作與客戶和使用者交談的模型，“如果我們構建這樣的東西，它是否符合你的想法？”，“如果我們要構建這樣的東西，它是否能滿足你的業務需求（/機會）？”請注意，我們需要確保這定義了問題，而不是試圖描述解決方案。
這裡有一個類比：對於一個被描述為“幫我找到一種讓一個家庭搬運400英里”的專案，一個原型可能類似於一輛卡丁車。如果客戶然後說“哦，不，我忘了說它必須漂浮？”那麼，我們就避免了一次可能令人尷尬的誤解。
2. 為團隊提供動手操作的機會。這對於學生專案尤其重要，原因有兩個——首先，它為團隊提供了一個瞭解其運作方式的機會（自稱“槍支程式設計師”的團隊成員是夢想家，還是團隊的真正資產？）；其次，它讓團隊有機會體驗他們在進行第二輪和第三輪迭代時可能會遇到的某些方法和工具——我們寧願現在發現某件事在實現方面特別棘手，而不是在交付截止日期臨近時才發現。在上面提到的卡丁車故事中——現在是時候發現團隊中沒有人有焊接經驗了！
因此，在這個設計規範部分，我們正在將我們已經知道的一切，重新表述為我們需要為第一次實現瞭解的東西，或者也許更準確地說：在第一次實現可以設計用來回答的問題方面。我們透過建立一個“知識庫”來做到這一點。這個“知識庫”為我們提供了專案的現狀快照，以及我們對專案瞭解了什麼（以及我們不知道什麼）。透過以結構化的方式完成專案，我們應該已經能夠生成大量關於專案的陳述。我們對其中一些非常確定，對另一些有一些想法，還有一些需要我們自己編造。現在可能是回顧幾個敏捷價值觀的好時機：勇氣和誠實。
我們提出的問題都是我們最終需要了解的，即使不是現在。勇氣價值觀體現在這裡，因為我們認識到這是你的專案，不會有仙女教母出現並提供所有答案。誰編寫功能需求？是你。誰編寫驗收測試？是你。誰編寫使用者手冊？是你。（我可以整晚玩這個遊戲，但你明白我的意思）。誠實價值觀體現在我們認識到我們賦予每個陳述的確定性和重要性。
因此，你應該進行一項練習，寫下你對專案瞭解的一切（或不瞭解的一切）。應檢查每個陳述，以確定你能賦予每個陳述多少確定性。然後，看看它們有多重要。這些度量的矩陣為我們指明瞭下一步應該做什麼。
|
這份問題清單旨在促使你思考專案的方方面面。 |
將答案寫成獨立的陳述，而不是對問題的回答。不要害怕寫下其他由這些問題直接引發的陳述。
每個問題可能會產生多個陳述
客戶是誰？
他們的業務是什麼？（/他們的使命宣言是什麼）
他們的關鍵績效指標是什麼？
他們的問題（或業務機會）是什麼？
他們是如何產生這個業務問題/機會的？
在高層面上：專案成功將如何衡量？（從客戶的角度/從你的角度……）
如果客戶有無限資源，你會如何解決問題？
如果客戶已經決定僱用一個人來解決問題（所以你的工作是找出那個人的職位描述），那個人會做什麼？
你們制定了哪些小組流程（以確保溝通順暢，解決分歧，促進創造力，促進工作質量……）
完成以下內容：“我們的證據組合是……”
完成以下內容：“我們的Scrum會議是……”
專案合適的系統隱喻是什麼？
客戶帶來的利益是什麼？（參與流程；待售產品；開拓新市場；改進業務實踐等）。
哪些因素會限制專案的開發？
目前的實踐是什麼？（人們做什麼？紙質系統是什麼？計算機系統是什麼？）
功能需求是什麼？（“使用者將……”）
系統的系統需求是什麼？
使用者是誰？（/他們的特點是什麼？）
利益相關者是誰？（/他們與系統的關係是什麼？他們會喜歡/不喜歡系統的什麼方面？）
如果你們有無限資源，你會怎麼做來解決問題？
如果指令是不要用計算機解決問題，你會怎麼做？
使用者會非常喜歡這個系統的________
使用者會非常不喜歡這個系統的________
之前做過嗎？之前做過單獨的部分嗎？
獲取它的選擇有哪些？
這個系統的成本是什麼？（不僅僅是財務上的）
這個系統的益處是什麼？
用投資回報率（ROI）來解釋系統
你如何向記者解釋問題/機會？
這個專案是否存在智慧財產權問題（侵犯他人的權利，或有商業化的可能性）
畫一個系統草圖
我們採用排名最高的陳述（確定性最低，重要性最高），並利用它們來推動原型實現。
有些問題不需要詳細的原型。有些問題甚至在開始原型之前就需要得到解答。這裡關鍵的問題是：這個問題之前解決過嗎？有什麼現成的解決方案？我們可以整合哪些元件？
對於學生專案，一個有效的問題是“我們有能力嗎？”。因此，一個有用的第一輪迭代原型可能是“hello world”，使用可能的實現平臺。
例如：在一個團隊向外部行業小組展示他們的專案時，得到了這樣的回應：“雖然我們不介意你重新發明輪子，但你應該知道你已經重新發明過輪子，而且你應該做得更好，相反，你重新發明了輪子，卻沒有參考圓形輪子，而是給了我們一個方形輪子”。
例如：對於一個開發博物館“智慧”機器人頭的專案……
知識庫可以作為整個專案的驅動因素。如果你要在一個白板或一系列卡片上寫知識庫（並在Scrum會議中不斷更新它），每天選擇一個任務就像選擇排名最高的陳述（最重要的/最不確定的）並努力回答它一樣簡單。