1．當開始研發新產品或者已有產品的新模組時，由於各方面的原因，整個團隊
沒有能力在sprint 的開始就做出乙份非常詳實的計畫，因此，採用「照明彈」策略
絕對不失為乙個好辦法。
2．對於每乙個story，要盡可能了解它的需求。
3．在開發過程中，為了提高交流的效率，要盡量避免把精力浪費在不必要的文
檔上，取而代之的是要提倡團隊之間面對面的直接交流。
4．在實際工作中，scrum 提倡團隊自我管理，在任務分配時每個人都可以按自
己的興趣來選擇任務。
5．團隊成員的技能培訓是要在做sprint 計畫時就考慮在內的。
6．雖然每日scrum 會議的持續時間會根據整個團隊的大小而有所不同，但是，
請不要超過15 分鐘。
7．經理應該充分信任開發團隊，不該把每日scrum 會議當成每日匯報。
8．在scrum 工具的使用上，一定要確保每天都進行準確的更新，只有這樣才能
讓團隊的其他成員以及專案經理掌握及時、準確的專案進度資訊。
9．通過burndown chart，scrum 將給專案帶來更多的可視性。
10．每日scrum 會議舉行的時間應該在早晨還是下午？
11．在每日scrum 會議上不要過多地討論技術難題的細節，如果有團隊成員遇
到無法解決的困難時，scrum master 應該將其記錄下來，會後再調配資源去解決。
12．scrum 如何解決開發與測試工作同步的問題？
13．每個sprint 結束後，最基本的目標是得到乙個可以工作的產品。sprint 結束
時的sprint 評審會議和sprint 回顧會議都至關重要。
14．在sprint 計畫會議中，scrum master 應該主動與product owner 一起制定和
討論這個sprint 的工作。
15．在sprint 計畫會議中，scrum master 不應該拋棄團隊成員，團隊成員必須全
體參與到計畫的討論中去，並且及時對不明白的地方以及使用者需求等進行提問。
16．採用wiki 進行文件管理。
17．在sprint 計畫會議中應該如何制定具體的計畫？
18．在sprint 進行過程中，遇到臨時的員工變化，比如請假，應該怎麼辦？
19．在sprint 計畫會議中，應該如何更準確地估計每個task 的時間？應該怎樣
用計畫撲克來估計時間？
20．在scrum 中，例如除錯機器、準備開發環境這樣的任務的工作量也應該體
現在sprint 的工作分配中。
21．關於scrum 團隊大小的討論。
22．scrum 與xp 以及其他一些敏捷方法的關係是怎樣的？
23．每日scrum 會議為什麼需要團隊成員站著開，而不能坐著？
24．每日scrum 會議需要每天進行，而不能因為每天的任務相似就不召開。scrum
master 應該在每日會議中敏銳地發現問題，並積極地鼓勵團隊成員進行討論。
25．作為乙個scrum master，對於自己上司臨時安排的非sprint 計畫的任務，應
該盡量提前在sprint 的計畫階段就留出一定的緩衝時間用於處理這些事情，並應該
盡量協調安排好，避免過多非sprint 計畫的任務出現。
26．作為乙個scrum master，應該如何有效地向經理匯報專案程序？
27．scrum 不鼓勵加班。
27228．對於不好演示的功能，可以用執行測試用例等其他方式在 sprint 評審會議
中進行展示。
29．創造乙個敏捷的工作環境，讓每個scrum 團隊成員都坐在一起工作。
30．敏捷開發的思想之一也包括避免不必要的浪費，在做sprint 計畫時應該放
棄實現一些不必要的功能。
31．如何制定乙個sprint 的目標？
32．sprint 計畫會議需要團隊成員事先進行很充分的準備。
33．測試應如何介入sprint 中？
34．嘗試「結對程式設計」。
35．在敏捷開發中，應該盡可能地尋找有效的工具提高效率。「工欲善其事，必
先利其器。」
36．對於異地團隊，增強溝通是最關鍵的。初期最好的溝通方式是面對面的交
流。核心人員最好能進行一些面對面的接觸。
37．scrum master 的職責之一是在完成日常工作的同時，還需要隨時幫助團隊
成員排除障礙。
38．測試人員應該融入scrum 團隊，這樣做有利於開發團隊與測試團隊之間的
溝通，以共同保證產品的質量。
39．scrum 強調團隊協作，並且在業績評定上一直都是以整個團隊的成果來衡
量的，這似乎對團隊中的某些成員不太公平，畢竟術業有專攻。這種情況下應該怎
樣衡量每個人的績效價值呢？
40．由於團隊成員的每個個體在技能、精力、經驗上的差別，所以必然會導致
效率的差別。那麼，應該如何消除這種差別帶來的問題？
273案例索引
41．對於專案進行中有可能影響專案結果和交付日期的突發事件，絕不能隱瞞，
而是應當從客戶的立場出發，告訴客戶實情，並在現有的條件下盡可能滿足客戶的
需求，同時為客戶提供多個解決方案作為備選。
42．在乙個sprint 結束和新乙個sprint 開始的中間，應該有一定的緩衝時間。
43．採用scrum 回顧模板「團隊聽診工具」進行scrum 回顧。
44．利用演示工具有效地傳遞sprint 需求。
45．採用scrum 後的新部門組織結構。
46．推薦敏捷工具ibm rational team concert。
47．如果測試人員不習慣自身的角色轉換，應該鼓勵他們轉變思維方式，主動
參與開發過程。
48．關於效能測試的介入時機問題，常見的做法是在第n+1 個迭代測試第n 個
迭代的功能。
49．測試新功能前要對老功能做回歸測試，以保證新功能不會破壞老功能。
50．關於自動化測試，應該盡力而為，但不能急於求成。
51．乙個產品的成功與否需要市場來檢驗。在產品正式發布之前，如果能有客
戶盡早地參與到開發過程中進來，無疑會增加成功的砝碼。
52．scrum 強調在乙個sprint 中團隊的穩定，乙個sprint 中間的人員變動會對
sprint 不利，即使加進來足夠多的人往往也不能起到提高效率的作用。
53．如何管理素質較低的團隊？
54．傳統的軟體管理體系cmm/cmmi 的理念與scrum 的關係。
55．持續整合的實踐。
js學習過程備忘
var firstnamelength 0 var firstname ada firstnamelength firstname.length 運算結果 firstnamelength 8var firstletteroffirstname var firstname ada firstlette...
PL SQL儲存過程備忘
嗯，好久不寫儲存過程了，最近有乙個業務用資料庫的儲存過程來實現比較妥當，於是再次接觸了一下，下面是一些記錄，以便以後翻查 1 如何定義乙個儲存過程 下面是乙個簡單的儲存過程定義，實現了將 hello 列印出來 create or replace procedure p test p start ti...
讀敏捷過程有感
在閱讀敏捷開發過程中，發現乙個很有意思的地方，就是敏捷提倡程式設計師開始預估自己的開發速度，再後來的迭代中得到乙個真實的速度，那麼下次的迭代計畫則根據上次迭代的得到的速度數值來計畫。這樣就可以使計畫始終按照最真實的開發速度來制定。敏捷開發通過這麼乙個簡單的方法就實現了cmmi5的不斷優化。我就將這種...