1.時間表的三分法：設計、coding、測試。
2.時間表的問題清單：
（1）時間表中是否以某種形式把所有參與者的生病和渡假時間包含進來？
（2）是否有國定長假或一年中德主要其他時間影響？這些期間內特別難在主要期限達成。
（3）個人是否看得到時間表？是否需定期回報進度？
（4）是否有人每日或每週監看整體時間表？這個人是否有足夠的權位提出好問題，並做調整？
（5）團隊是否對時間表有歸屬感和承諾感？如果沒有，原因何在？團隊是否對時間表的制定以及要做的事情有所參與？或者只是把時間表交給他們而已？
（6）團隊領導者添加的功能要求，是否比他們協助削去的還要多？團隊領導者是否曾對新工作說不，而且對團隊提出合理的哲學觀，以便於團隊回應新的要求？
（7）團隊的人是否受到鼓舞力挺，對無法和目標及願景相符合的新工作要求說不？
（8）做估算實用的是什麼機率？機率有在主要高層次時間表中表述出來嗎？客戶 / VP / 顧客是否知道這件事？是否討論過另一個提案，會花比較多時間，但機率比較高？
（9）時間表中是否有定期的時間，可以讓領導者和管理者進行時間表調整和重新審查？
（10）時間表是否有假設假期季節的工作時間較少？
（11）規格書或設計規劃，是否好到足以讓工程師做出良好的工作估算？
（12）工程師在做出良好工作估算上，是否受過訓練或經驗老道？
2.時間表有三種功能：做承諾、鼓勵每人將其工作視為對整體的一部份貢獻、追蹤進度。
3.大時間表應該切成小時間表，把風險減到最小，並增加調整的頻率。
4.常見的規劃產出物：
（1）行銷需求文件（Marketing requirements document，MRD）：說明存在哪些商業機會，以及專案該如何利用這些機會。它用於協助定義專案的「內容」。
（2）願景 / 範疇文件（vision / scope document）：定義專案的目標、為何目標有意義、以及專案有哪些高層次功能、需求、日期。願景文件把所有關於可行專案的有效想法，都放進單一構圖中。若有 MRD 存在，願景文件應該延續並大量引用它。它直接定義了專案的「內容」
（3）規格書（specifications）：定義要做的工作。良好的規格書是衍生自一組需求，然後透過反覆設計工作而繼續發展。規格書應大量繼承自願景文件。它定義了專案的「做法」。
（4）工作分解結構（work breakdown structure，WBS）：定義如何去做、什麼工作要先做、由誰來做、所有個別工作有哪些、如何追蹤。它定義了專案的「做法」。
5.規劃專案牽涉到三種對等觀點的運用：
- 商業
（1）為何我們的生意需要這個專案？
（2）我們的顧客有哪些未滿足的需求或渴望？
（3）我們可以提哪些功能或服務，以滿足這些渴望和需求？
（4）根據什麼基礎認為顧會購買這項產品或服務？什麼會讓他們有動機如此做？
（5）專案成本多少（人 / 資源）？要多少時間？
（6）潛在的收益有多少（或組織營運成本會減少多少）？要多少時間？
（7）要放棄哪些項目，才能做這件事？
（8）這專案對我們長期商業策略有貢獻嗎？或者保護了其他可產生收益的資產？
（9）這專案如何協助我們比得上、趕過或打敗競爭對手？
（10）這專案應該鎖定哪個行銷時段？
- 技術
（1）專案需要什麼？
（2）怎麼運作？每個元件怎麼運作？
（3）要怎麼建造？怎麼查核是否按我們所要的方式運作？
（4）對目前系統或我們能做到的系統而言，能達到多少可靠度、效率、擴充性、以及效能？這點和專案所要求的是否有落差？
（5）我們隨時可用的技術或架構有哪些？我們是否要賭一賭，試用任何即將可用的新科技？
（6）團隊及專案適用哪些工程流程及手段？
（7）我們的人有哪些可用的知識和專業？他們如果不參與這個專案該怎麼辦？
（8）我們能填補專業上的漏洞嗎？
（9）要花多少時間建造？要做到什麼程度的品質？
- 顧客
（1）人們實際上都在做什麼？
（2）試著做這些事時，他們會碰上什麼問題？在哪裡受阻、感到困擾或沮喪？
（3）他們需要或想做什麼，卻完全做不到？
（4）讓事情變得更簡單、安全、快速或可靠的特定基會在哪裡？
（5）就改良事情做法而言（第一點的觀點來看），有什麼樣的設計想法，是最有潛力可以改善顧客經驗的？
（6）如何探索這些想法？有什麼原型、草圖或其他做法必須研究，才能協助我們瞭解專案在這方面的潛力？
（7）專案應該使用什麼核心想法和概念，以表達資訊給使用者？
6.專案規劃問題清單：
（1）為什麼有這個專案存在？我們為何是做這件事的正確人選？目前需要先完成什麼？
（2）有哪三、四個有用的編組，可以討論我們現有的不同類型顧客？他們的需求與行為有何差異？
（3）有哪些人口統計資訊，可以協助我們瞭解這些顧客是誰？
（4）每個使用者群體使用我們的產品從事哪些活動？他們購買產品的用意，與所從事活動之間的關係為何？我們行銷產品的方式，與他們所從事活動之間的關係為何？使用產品滿足他們的需求時，是否遇到什麼問題？
（5）誰是我們前在新顧客？需要什麼功能、使用場景（scenarios）、或產品類型，才能使他們成為顧客？（這些新顧客的人口統計資料是什麼？）
（6）我們是否有這樣的技術和專業，足以建立滿足這些需求和問題的東西？
（7）我們能否建立這樣的技術或取得這樣的專業，以建立滿足這些需求和問題的東西？
（8）新產品或產品線中是否有重大機會？或者需求直接和現行產品或產品線綁在一起？
（9）是否有可行的營運模式，可以使用我們的專業和技術，以解決這些已知的問題或需求？（在可預期的時限內，利潤是否大於成本？）
（10）下一版或產品上市的行銷時限是什麼？哪些機會與時機對達成目標最具體意義？
7.規劃日常工作應謹記三件事：
（1）流程中最重要的部分就是眾人應該扮演的角色。誰具有需求授權？設計？如果有太多人參與，要如何做決策？如何打破各種束縛？
（2）每個人都應該知道中間點是什麼。規劃開始的那一天，以及專案定義要完成的那一天之間，有哪些里程碑？產出物的時程應該儘早列出，同時定義出負責單位。「規劃」究竟何時結束，而設計或實作又何時開始？
（3）討論每種觀點時，應該時常開會。新資訊或想法的報告應該展示出來，而新的問題或結論應該提出來。
8.優質願景的五項品質指標：簡化、意圖明確（以目標為準）、統合、鼓舞人心、容易記住。
9.專案願景的核心必須回答下列問題：
（1）這個專案的這個版本，如果以一句話來定義，該怎麼寫？
（2）這個專案對組織的目標有何貢獻？為什麼這個專案比其他對組織目標同樣有貢獻的專案，更有意義？
（3）對顧客而言，哪些使用場景 / 功能是專案不可或缺的？（優先順序 1）
（4）對顧客而言，哪些使用場景 / 功能是最想要的，但不是絕對必要的？（優先順序 2）
（5）誰是顧客？這個專案替他們解決什麼問題？有什麼證據或研究支持這些說法？如果沒有這個專案，顧客會怎麼做他們的事？
（6）組織中，誰是此專案的利害關係人？他們在專案中的角色為何？
（7）為什麼這些顧客會購買或訂購這項服務？
（8）誰是競爭對手，以及這個專案和他們的比較起來如何？
（9）有哪些顧客相關的解決方案曾經被要求或建議過，但確定不會是這個專案的一部分？
（10）如果在問題的搜尋中沒有這項技術，該怎麼辦？
（11）哪些是專案不會達成的？
（12）這個專案有什麼可能的情況會失敗？如鵝避免或盡量縮到最小？
（13）專案要成功，有什麼其他公司或群體是必須配合的？
（14）從高層次來看，工作怎麼在團隊中分配？誰是專案中每個主要子區域的領導者？他們擁有什麼樣的授權？
（15）專案仰賴的假設有哪些？這個專案又仰賴什麼其他專案、公司或組織？
10.在專案進行中，於每個狀態報告會議或領導統御會議上，都要問下列問題：
（1）願景有無精確反應出此專案的目標？
（2）願景是否有助於引導個別貢獻者做決策，並拒絕超出專案範疇的請求？
（3）我們是否應該考慮對願景做什麼修改，使得問題 1 和問題 2 成真？
11.撰寫需求的初步指南：
（1）要有對需求進行交涉和反覆研討的打算。
（2）抓出不正確的假設。
（3）抓除遺漏的資訊。
（4）替每個需求定義相對的優先順序。
（5）把無意間造成的模糊語言改正消去。
12.對所有專案管理、創意性思考、以及解決問題而言，最有力的問題：
你要解決什麼問題？
13.腦力激盪的四條規則：
（1）當某人提出構想時，唯一接著的回應就是「對，而且...」。你的目的是讓他的構思能持續發展下去。
（2）提出想法後，不能接著否定自己。提出想法的目的在於引導別人說出更好的東西。
（3）不能提阻撓性問題。思考怎麼把他們的初步想法引導成有用的東西。不管要做什麼假設，態度要大轉變，只要能讓某人的陳述有意義就行。
（4）讓他人滿面春風。沒人應該記錄誰說了什麼。功能應該歸給那些協助小組其他人把最佳想法放大、表達出來、或引導出來的人。
14.設計想法的最佳起始點就是顧客經驗。
15.設計階段的階段查核點：
（1）願景文件和概念原型的論證。
（2）想法分組 / 清單。
（3）三個替代方案。目標把可能設計的方向縮小成 3 到 5 個替代方案。
（4）兩個替代方案。調查、研究、原型，以及提問，直到有信心可以縮減到兩個替代方案。應該要有明確的方向，以定義剩下來最重要的決策點。
（5）一個設計。調查、研究、原型，以及提問，直到可以做出最後的方向選擇。
（6）規格書。寫下單一選擇出來的設計文件。寫下單一選擇出來的設計文件。使用剩餘的時間調查、瞭解、並決定低層次設計議題。
16.選擇要做什麼原型的方式：
（1）從每群組中找出最有希望的想法，試著將這些想法結合成單一設計。
（2）替每個群組做小型原型，以觀察它們走向何處。所有必須解決的問題是否只須重塑架構或增加客制化功能就能解決？要瞭解每種方向的設計結果。
（3）設計師的判斷：讓設計師以其經驗和直覺，決定第一步要使用什麼。
（4）把最難或最重要的設計問題列成清單，並作出原型，以協助找出答案。
17.程式設計師應回答的原型清單：
（1）從高層次來看，我們怎麼建立呈現在設計原型中的東西？是否有可用 / 應該使用的現存程式碼或技術？
（2）有無合理的設計變更是設計師應該注意的，以減少建造成本？
（3）需要哪五個或六個主元件？它們彼此間有何關係？從最高層次來看，這些元件的建立有多昂貴？
（4）最大的技術風險為何？哪些元件在建立上最困難或最複雜？
（5）元件之間有哪些介面是最複雜或最可能失敗？
18.針對早期原型反覆的問題：
（1）這滿足了哪些需求？我們可以確認嗎？（可用性，使用案例等）
（2）就應該解決的問題來看，這樣的設計有哪些好處和壞處？（每種設計的可用性、商業、技術、考量的優缺點）
（3）評估這種設計需要什麼資料？
（4）我們從此設計中可學到什麼，是在下次嘗試時應該保持或消除的？
（5）在下一輪反覆中，我們要做什麼嘗試，才會更好？
（6）想法群組或其他原型中，是否有其他想法是我們應該包含進來的？
19.針對晚期原型反覆的問題：
（1）這可以協助我們做什麼決策？
（2）這可以協助我們結束哪個開放議題？
（3）這種設計是否確認了有個我們必須研究的問題？是否解決了我們必須解決的問題？
（4）在下一輪反覆中，我們要做什麼嘗試，好讓我們更接近撰寫規格書？
二. 技巧
1.五種規格書：
（1）需求：在設計流程前定義好，且從願景文件推衍而來。需求應配合功能規格書，以便於檢閱。
（2）功能：從顧客觀點描述某個場景的行為。從使用者介面描述軟體功能，並且從非技術的觀點，詳細說明事情應如何運作。功能規格書應該描述當顧客工作完成時，其經驗會有何改變；同時應該包含一份簡短清單，列出為實現此情景，工程師所定義的工作項目－和需求清單不同，因為它定義的是滿足需求的特定設計，包括使用者介面等設計要素。
（3）技術：說明實現功能規格書所需的工程手法。只有針對最複雜的元件，或其他程式設計師可能使用的可再用元件，才需要做足夠詳細的描述。此外，對功能規格書所需的工作項目，也必須提供輔助證據。
（4）工作項目清單：實現功能規格書所需的每項程式設計指派任務的說明，應該做到把不同重要等級的項目分開的細分程度，同時以天數估計時程。清單的建立是程式設計師的工作，檢閱與控管清單是專案經理的工作。
（5）測試準則以及里程碑完成標準：包含針對新功能、具優先順序的使用案例，同時列出目標，指出在這些案例上，程式碼的表現應當如何，才能滿足里程碑的品質目標。
2.規格書撰寫的技巧：
（1）從其它規格書借用優良的使用說明。
（2）避免行話和模糊不清的語言。
（3）當你受困於不知如何才是表達概念的最佳方式時，應參考舊規格書。
（4）當你撰寫時，心中要有特定的讀者群。最簡單的方式，就是在規格書中把行為或功能的說明，和對現行描述內容相關的議題或問題給分隔開來。因此，在規格書結尾應該有一份開放議題清單。
（5）不要愛上 Visio 或流程圖。應對工具和圖表保持客觀。
（6） 規格書不用完整列出 API 參考資料，或描述每個實例或可能的行為。把焦點集中在 10 或 15 個常用或最重要案例，然後再以另一份文件將其他剩餘的部分都列出來。
（7）深入研究前，使用虛擬程式碼（pseudocode）或甚至用英文，從高層次來描述複雜演算法。
3.管理開放議題的技巧：
（1）這個議題何時必須解決？誰是做決策解決該議題的最佳人選？
（2）這個議題能否以某種方式獨立出來，也許做成特定元件或使用場景？或者這個議題是否會衝擊整個功能或專案？
（3）此問題有哪些可能的解法尚在考慮中？每種替代方案對規格書有什麼衝擊？
（4）我們可以刪掉這個議題嗎？在優先順序 1 的使用者場景中，這個議題對顧客的衝擊如何？
（5）這個議題能否切割成可以委托給其他人的更小議題？
（6）阻礙此議題解決的問題是誰或是什麼事？該做什麼才能把阻礙移除掉？
4.終止設計 / 規格書差距應考慮的問題：
（1）無論選擇的替代方案是哪一個，是否有必須完成的工作項目？如果有，就應該做估計，加進規格書中。必要時，這些工作項目可在規格書定案前就開始。
（2）PM 或設計師能解決這個議題嗎？解決這個議題是否會引出新的工作項目？
（3）在解決此議題上，有哪些可能的替代方案尚在考慮中？
（4）在這些可行的替代方案中，哪一個是最昂貴的？對這個方案牽涉的工作項目做估計，讓規格書和工作項目清單有個最壞打算的設計計劃。
（5）這是主要或核心元件嗎？程式設計師何時必須實作此元件？這個元件可以日後在實作階段實再設計嗎？是否有其他元件仰賴這個元件？
（6）這個議題能否被包含、縮小、切割、或刪掉？如果不能，就放到順序清單的頂端。
5.規格書檢閱時的問題清單：
（1）程式設計師的工作項目清單和規格書相符嗎？規格書中的每項重要元件和每個工作項目的關係為何？設計過程中的哪個地方最有可能找到漏掉的工作項目？
（2）這樣的設計最可能以什麼方式出錯？最弱的元件或介面是什麼？為何無法改善？
（3）這樣的設計，哪一方面最強健？哪一方面最弱？我們最有信心和最沒信心的是什麼？我們的力量和信心是否以最重要元件為中心？
（4）我們有適當層度的品質嗎？這樣可以做到專案願景所需的可靠性、效能、以及可用性嗎？測試的估算實際嗎？
（5）為何簡單一點的設計不會更好？我們真的需要這麼多的複雜度或功能嗎？我們有什麼證據或紮實的論點，說明簡單一點是不可行？
（6）這樣的設計和什麼有相依關係？有沒有什麼技術、公司、專案、或其它規格書失敗時，會破壞或阻礙工作的進行？我們有任何緊急應變計劃嗎？
（7）設計中的哪些元素最可能改變？為什麼？
（8）指派給這個專案的測試、說明文件、行銷、以及其他專家，是否都有做出最佳工作所需的資訊？他們最關心的是什麼事？這些事該如何解決？或者有沒有紮實的理由可讓我們忽視？
（9）就此規格書或功能而言，PM、程式設計師、以及測試員最關心的是什麼？
（10）是否有機會共用或借用此專案正在建造之其它功能的程式碼？
（11）我們是否滿足 UI 所需的存取性和區域化需求？
（12）這樣的設計有什麼安全防護風險？為何不可把它刪除？有在規格書中說明嗎？有包括潛在的補救方法嗎？
（13）我們有沒有可信賴的證據指出，特定使用者可以利用此 UI 設計，成功地做到他們想做的事？
6.規格書應做到的三件事：
- 確保建造的是對的產品。
- 作為進度里程碑指出專案規劃階段告終。
- 在專案進程中，讓不同的個人可以做深度檢閱和回饋。
7.衡量決策的問題：
（1）決策核心的問題是什麼？（探索性的問題）
（2）這項決策對專案的衝擊有多久？衝擊有多深？（重大決策最好儘早做）
（3）如果你錯了，衝擊 / 成本為何？哪些決策也會連帶受到衝擊？（考慮此項決擇是否獨立，如果不是，應一次做好幾項決擇）
（4）機會之窗出現在什麼時候？（決策的速度比決策的品質更重要）
（5）我們以前做過這種決策嗎？
（6）誰具有專家觀點？這真的是我該做的決策嗎？
（7）我們需要誰的核准？我們做決策前，需要 / 想要誰的回饋？
8.優缺點清單應考慮的事項：
（1）一定要包含「什麼也不做」選項。不是每項決策或問題都需要行動。
（2）你怎麼知道你認為你知道？要尋找資料和研究，以協助回答重要問題或主張。
（3）問艱難的問題。直接追問決策的衝擊。
（4）要有異議。
（5）考慮混合式抉擇。
（6）包含任何相關觀點。
（7）從紙上作業或白板開始。
（8）精煉直到穩定。
9.檢閱決策的問題清單：
（1）這項決策有解決核心議題嗎？
（2）是否有更好的邏輯或資訊，能加快決策？決策時的時間都花在哪裡？是否有什麼知識或建言，是你之前可以拿來加快尋找或探索替代方案的過程？之前用了什麼研究工具？
（3）願景、規格書、或需求有所助益嗎？這項決策是否揭露出願景的弱點或缺失？決策之後，願景 / 規格書 / 需求是否有更新，並消除疏失之虞？
（4）這項決策有助於專案進展嗎？
（5）是否有重要人士參與過程，卻無法參與決策？有沒有任何人的輔助和事業是必須的，但卻沒參與？你是否試著和他們聯繫而找不到人，或者你根本沒試過？是否有其他方式比起你以前做過的，可讓他們更有效參與？
（6）這項決策有防止或引發其它問題嗎？當前議題也許解決了，但其它問題卻引發了？士氣是否大降？合伙公司或團隊是否被彼此決策激怒？這項決策的副作用是什麼？能否避開？這些人有參與或不知情？
（7）事後來看，當你想把決策做對時，有哪些事是你應該擔憂的？誰的意見或影響力造成了扭曲？誰試著讓它減到最小卻被忽略了？
（8）你是否有足夠授權做對的事？
（9）做此決策所學到的事，如何應用到專案提阿地方？
三. 管理
1.優先順序的問題清單：
（1）我們試圖解決的問題是什麼？
（2）如果問題有好幾個，哪一個最重要？
（3）這個問題和我們的目標有何關聯，或者會如何衝擊我們的目標？
（4）修正此問題使目標能滿足的最簡單方式為何？
2.里程碑應設定的標準：
（1）完成的規格書 / 設計 / 工作項目清單。
（2）實際完成的工作項目。
（3）特定程度的臭蟲數目。
（4）通過指定的測試案例。
（5）效能或可靠度的數據標準。
（6）時間或金錢。
3.有效管理臭蟲的核心屬性：
（1）優先順序（Priority）。盡量保持簡單。優先順序 1 = 必須修正。2 = 找機會修正。3 = 想修正，但未必發生。4 = 不大可能發生。
（2）嚴重性（Severity）。臭蟲的衝擊有多嚴重？優先順序 1 = 資料遺失、系統當機、或安全議題。2 = 主要功能未如預期（指定）般運作。3 = 次要功能未如預期（指定）般運作。
（3）指派（Assigned to）。把所有臭蟲都應該指派給個人。新臭蟲可以先指派給一個別名（alias），但臭蟲分類的一部分目標，是儘快把臭蟲指派給個人。為了讓 beta 版本的臭蟲能進入分類程序，可以建立名為「作用中」的值，讓臭蟲可以被指派給這個值。有被指派給這個值的臭蟲就能進行分類，然後指派給真正的人。
（4）重視（Reproduction）。讓其他人能重現此臭蟲的一連串動作。
（5）區域（Area）。臭蟲應根據在專案中的發生之處進行分門別類。
（6） 發現者（Opened by）。發現這個臭蟲的人的姓名，以及聯絡資訊。
（7） 狀態（Status）。臭蟲只有四種狀態：作用中（activity）、已修正（fixed）、已解決（resolved）、或結案（closed）。作用中是指臭蟲尚未修正，仍在考量中。已修正是指程式設計師認為已經解決。或同意延後處理，臭蟲才算解決。結案指該臭蟲的生命已結束，而且測試團隊以確認它的終止。
（8）解決方法（Resolved as）。臭蟲解決方式有幾種：修正、遞延到下個里程碑或版本、和現存臭蟲重複、或者不會被修正。
（9）類型（Type）。有兩種臭蟲類型：缺陷（defect）和復發（regression）。缺陷是平常的普通臭蟲。復發是已修正過的臭蟲，現在又因為其他變動的負面邊際效應而再度出現。
（10）分類（Triage）。指出臭蟲是否已被分類，以及結果為何。此欄有三種狀態：已核准、已駁回、或調查中。
沒有留言:
張貼留言