1. 需要有全職的有威信，有能力的產品負責人（PO-Product Owner).
2. PO要和Scrum Team、其他的利益相關者（stakeholder)一起工作
3. 有PO來創建和管理產品backlog.
4. Scrum每日站會必須的3個問題（完成了什么，準備做什么，有什么障礙）。
5. Scrum每日站會要在固定的地方時間不要超過15分鐘。
6. 有規律的Sprint長度(不超過30天)
7. 在Sprint計劃會議上創建Sprint Backlog和經過詳細估算的任務列表。
8. 一定要有Sprint的燃盡圖。
9. Team必須的設備及相關的供應要齊全。
10. 使用回顧會議確保過程在不斷提升。
11. 有明確的對于“任務完成”的定義。
12. 按照合理的速率給出承諾（根據Sprint的工作量估計)。
13. 團隊大小在7 +/- 2,最多不能超過12人
14. 跨職能的團隊包括Scrum Master和PO.
15. 自組織的團隊 - 團隊成員志愿挑選任務。
16. Scrum master要跟蹤進度，并且為團隊掃清障礙。
17. 確保Team不被外界干擾。
18. Sprint之間不能間斷。
19. 合理的節奏 - 根據固定時間段來確定任務量, 不只是一個進度表。
20. 質量是第一，不需要在質量上討價還價 - 代碼缺陷永遠位于Backlog的最上層。
javaeye上一篇文章不錯，介紹
Linux文件系統簡介的，講解比較基礎，遺忘的時候看下不錯的，記錄一下～！～http://www.javaeye.com/topic/816268
轉載于：http://www.infoq.com/cn/articles/skills-for-scrum-agile-teams
敏捷項目的工程獨特性
1.
設置開發環境
在傳統項目中，團隊可以投入充分的時間來設置開發環境；而在敏捷團隊里面，他們需要從第一刻時間起就能產出。根據我們的經驗，我們認識到缺乏設置開發環境的相關文檔是設置環境如此耗時的一個關鍵原因。第二個關鍵原因是在設置過程中涉及的手工步驟數。在第0次sprint，我們必須記錄每一件開發人員必須做了才能開始編寫代碼，并集成團隊其他人工作的小事。
2.
自動構建
讓我們盡早失敗！我們領悟到，手工構建可能既脆弱，又特定于某一臺機器，而且當時間耗費在手工構建的基礎工作上面時，開發和測試的時間就被擠占掉了。除去最小的項目，自動構建過程對于每一個項目都是必不可少的。我們認識到，即使需要抽出時間來創建自動構建的環境，你以后是能把這些時間賺回來的。這也使得我們更易于確保項目有一個人人共有的標準化構建。
3.
持續集成
根據我們過去的經驗，我們領悟到，等到最后的幾個星期才去把不同團隊成員的代碼集成到一起是一個災難。如果你已經擁有了自動構建，接下來的事情就是持續集成。當然，版本控制（或者軟件配置管理——另一個更為正式的和令人印象深刻的名字）是自動構建和持續集成環境的前提。我們學到的一個重要教訓是，你越快識別出集成的錯誤，你就能越快地解決這些問題。我們曾經使用過的主要工具包括
CruiseControl、
CruiseControl.Net和
Bamboo。 hadson，基礎集成還是不錯的。
4.
單元測試
在高度流動的環境中，隨著多個開發人員一起工作、需求的變更和優先級的不斷變化，確保昨天可以運行的東西今天也能運行，這是至關重要的。此外，我們還要與集成出現的錯誤為戰。一種方法（我們從艱難歲月中學習得來）是使用單元測試，這樣代碼的更改不會破壞現有的功能。我們也開始在開發編碼之前編寫單元測試用例。我們曾經使用過的主要工具包括
JUnit（以及其他的xUnit工具如
NUnit、
HttpUnit等）和
MockObjects。
5.
重構
在傳統的項目中，通常有一個人保護他們的代碼庫，直到代碼集成階段。但是在敏捷里面，我們持代碼集體所有制的觀點——所有的代碼屬于所有的開發人員，只要開發人員認為有必要，每個人都能不受約束地去改善代碼。在一段時間里面，我們的代碼庫開始出現奇怪的行為——解決辦法就是重構（感謝Martin
Fowler在他的同名著作中把重構一詞推廣開來）。重構的本質歸結為修改代碼以改善代碼的結構和清晰度，但不改變代碼的功能。我們學到的一個重要教訓是在重構代碼之前使用單元測試作為安全網，我們曾經使用過的一些主要工具包括Eclipse、NetBeans、IntelliJ IDEA的和Visual
Studio.NET。
在敏捷團隊之中工作所必備的行為特征
由于敏捷團隊不同于普通的團隊，并且非常倚賴于有效果和有效率的溝通和快速執行，敏捷團隊更需要使用軟技能。如果我們意識到這一點，并積極鼓勵使用這些特征和技能，我們可以使得敏捷團隊更有價值和富有成效。
自組織往往倚賴于諸如正反饋、負反饋、深度探索和廣度調研之間取得平衡以及多重互動的基本要素。根據我們的經驗，團隊可能由于許多文化和社會因素無法給予正確的反饋或者回避人與人之間的互動。
根據我個人的經驗，這仍然是一個“神話”。我們總是傾向于患有“可預測性綜合癥”——如果我們做更多的規劃，我們將更加功能預測。
團隊需要有良好的紀律、有能力承擔責任、盡忠盡責以及承擔職責和所有權。
團隊需要擁有的關鍵技能之一是有能力尋求幫助，并尋求他人的評價。在某些情形下，我們已經看到了“自我”因素表現為一個主要的障礙。
有些時候，承擔責任，盡忠盡責和協作精神是理所當然的，但是根據以往的經驗，為了這些能夠出現，我們有時需要外部干預。
有些我們常常傾向于忽視的關鍵技能是積極主動、在激烈的環境中享受工作和易于適應新的形勢和框架。
我們的大多數項目都是分布式的，這意味著在客戶和服務供應商之間將會共同使用Scrum。在這種情況下，諸如管理多樣化團隊、時間管理、外交技巧和領導力等技能是非常關鍵的。
敏捷團隊的成功“咒語”
對于任何一個希望成功和高效的敏捷項目，團隊需要對向同儕學習（不管資歷和專業知識）表現出更大的熱情和正確的態度。必須保證一個無畏表達的安全網，這樣才會展現出真正的友情，而這反過來會增強團隊成員對團隊目標的關注，而不是“哪些由我來做”？
結論
根據我個人的經驗和觀察，對于提高生產率所需的技能，敏捷項目與傳統項目有所不同。本文定義了團隊提高生產率所需的行為和技術技能。具有這些“delta”
特征的人應該具備了合適的行為和技術技能，這些技能使得他們在敏捷項目中的工作能夠富有成效。對于這些技能的總結請見下表。
技能表
|
角色
|
技術技能（在不同的方面）
|
行為技能
|
|
開發人員
|
CRUD操作，開發框架不同層之間的調用
單元測試（工具——NUnit、JUnit）
代碼覆蓋率的概念和工具
代碼審查的概念和工具
持續集成工具
重構的概念
代碼味道的概念
Scrum過程
|
溝通
合作
時間管理/計劃
思維
沖突管理
處理更改/靈活性
決策
團隊合作/團隊建設
處理壓力
問題解決
領導
外交
|
|
QA
|
“完成”的定義 —> 驗收標準
測試管理
自動化/腳本
環境設置
數據庫概念
|
與開發人員相同
|
|
Scrum Master
|
Scrum過程
模板和使用
項目管理工具
持續集成工具
設置開發環境
|
開發人員的技能+推動力
|
作者簡介
Prasad，擁有10年的IT服務行業經驗，他第一次接觸敏捷項目是在2005年微軟的一個項目；從那時起，他為許多公司如GE、思科、可口可樂等，針對敏捷及其變體提供了解決方案開發、培訓、咨詢以及指導。目前他正在Symphony
Services的敏捷實驗室擔任經理。Symphony40％的項目都是關于敏捷或其不同的形式，并且自2004年起就通過敏捷為客戶提供商務的關鍵價值。你可以通過pprabhak@symphonsysv.com與他聯系。
查看英文原文：Skills for
Scrum Agile Teams
敏捷最大的特點是：不但快，反應要更快。
最終的目的是：提升效率。
敏捷是一種思想:
溝通：個體交互
簡單：快速交付
反饋：客戶合作
勇氣：響應變化
關鍵條件還是目標一直的團隊
共同愿景
高效溝通
互相信任
嚴格執行
迅速迭代，越變越美，允許試錯
敏捷精華： 小勝+ 反思
想法是：
1.現在列出你認為你能完成的一件事。
比如我認為每天30分鐘的話，下一周我能讀一本書:書名叫《人人都是產品經理》
2.每天把進度記錄到地下
我會把讀完的頁數寫出來，加上一點點感想
看完后，總結下。
任何一個有經驗的程序員都知道，軟件開發遵循著一些不成文的法則。然而，如果你不遵循這些法則也并不意味著會受到懲罰；相反，有時你還會獲得意外的好處。下面的就是軟件編程中的21條法則：
- 任何程序一旦部署即顯陳舊。
- 修改需求規范來適應程序比反過來做更容易。
- 一個程序如果很有用，那它注定要被改掉。
- 一個程序如果沒用，那它一定會有很好的文檔。
- 任何程序里都僅僅只有10%的代碼會被執行到。
- 軟件會一直膨脹到耗盡所有資源為止。
- 任何一個有點價值的程序里都會有至少一個bug。
- 原型完美的程度跟審視的人數成反比，反比值會隨著涉及的資金數增大。
- 軟件直到被變成產品運行至少6個月后，它最嚴重的問題才會被發現。
- 無法檢測到的錯誤的形式無限多樣，而能被檢測到的正好相反，被定義了的十分有限。
- 修復一個錯誤所需要投入的努力會隨著時間成指數級增加。
- 軟件的復雜度會一直增加，直到超出維護這個程序的人的承受能力。
- 任何自己的程序，幾個月不看，形同其他人寫的。
- 任何一個小程序里面都有一個巨大的程序蠢蠢欲出。
- 編碼開始的越早，花費的時間越長。
- 一個粗心的項目計劃會讓你多花3倍的時間去完成；一個細心的項目計劃只會讓你多花2倍的時間。
- 往大型項目里添加人手會使項目更延遲。
- 一個程序至少會完成90%，但永遠完成不了超過95%。
- 如果你想麻煩被自動處理掉，你得到的是自動產生的麻煩。
- 開發一個傻瓜都會使用的軟件，只有傻瓜愿意使用它。
- 用戶不會真正的知道要在軟件里做些什么，除非使用過。
[英文出處]：
21 Laws of Computer Programming
public class CheckQueryParams {
private static interface Validation{
void check(QueryInfo query);
}
private static List<Validation> validations = new ArrayList<Validation>();
static {
validations.add(new Validation() {
public void check(QueryInfo query) {
if(StringUtils.isEmpty(query.getStartKey()) && StringUtils.isEmpty(query.getEndKey()))
throw new RuntimeException("Both keys can not be null or empty at the same time");
}});
}
public static void check(QueryInfo query) {
for(Validation validation : validations) {
validation.check(query);
}
}
}
public class LRUCache<K,V> {
final private int capacity;
final private Map<K,Reference<V>> map;
final private ReentrantLock lock = new ReentrantLock();
final private ReferenceQueue<Reference<V>> queue = new ReferenceQueue<Reference<V>>();
public LRUCache(int capacity) {
this.capacity = capacity;
map = new LinkedHashMap<K,Reference<V>>(capacity,1f,true){
@Override
protected boolean removeEldestEntry(Map.Entry<K,Reference<V>> eldest) {
return this.size() > LRUCache.this.capacity;
}
};
}
public V put(K key,V value) {
lock.lock();
try {
map.put(key, new SoftReference(value,queue));
return value;
}finally {
lock.unlock();
}
}
public V get(K key) {
lock.lock();
try {
queue.poll();
return map.get(key).get();
}finally {
lock.unlock();
}
}
public void remove(K key) {
lock.lock();
try {
map.remove(key);
}finally {
lock.unlock();
}
}
}
1．同步對象的恒定性
對于局部變量和參數來說，java里面的int, float, double, boolean等基本數據類型，都在棧上。這些基本類型是無法同步的；java里面的對象（根對象是Object），全都在堆里，指向對象的reference在棧上。
java中的同步對象，實際上是對于reference所指的“對象地址”進行同步。
需要注意的問題是，千萬不要對同步對象重新賦值。舉個例子。
class A implements Runnable{
Object lock = new Object();
void run(){
for(...){
synchronized(lock){
// do something
...
lock = new Object();
}
}
}
}
run函數里面的這段同步代碼實際上是毫無意義的。因為每一次lock都給重新分配了新的對象的reference，每個線程都在新的reference同步。大家可能覺得奇怪，怎么會舉這么一個例子。因為我見過這樣的代碼，同步對象在其它的函數里被重新賦了新值。這種問題很難查出來。所以，一般應該把同步對象聲明為final。 final Object lock = new Object();
使用Singleton Pattern 設計模式來獲取同步對象，也是一種很好的選擇。
2．如何放置共享數據,粒度，跨類的同步對象
實現線程，有兩種方法，一種是繼承Thread類，一種是實現Runnable接口。
首先，把需要共享的數據放在一個實現Runnable接口的類里面，然后，把這個類的實例傳給多個Thread的構造方法。這樣，新創建的多個Thread，都共同擁有一個Runnable實例，共享同一份數據。如果采用繼承Thread類的方法，就只好使用static靜態成員了。如果共享的數據比較多，就需要大量的static靜態成員，令程序數據結構混亂，難以擴展。這種情況應該盡量避免。編寫一段多線程代碼，處理一個稍微復雜點的問題。兩種方法的優劣，一試便知。
線程同步的粒度越小越好，即，線程同步的代碼塊越小越好。盡量避免用synchronized修飾符來聲明方法。盡量使用synchronized(anObject)的方式，如果不想引入新的同步對象，使用synchronized(this)的方式。而且，synchronized代碼塊越小越好。
對于簡單的問題，可以把訪問共享資源的同步代碼都放在一個類里面。
但是對于復雜的問題，我們需要把問題分為幾個部分來處理，需要幾個不同的類來處理問題。這時，就需要在不同的類中，共享同步對象。比如，在生產者和消費者之間共享同步對象，在讀者和寫者之間共享同步對象。
如何在不同的類中，共享同步對象。有幾種方法實現，
（1）前面講過的方法，使用static靜態成員，（或者使用Singleton Pattern.）
（2）用參數傳遞的方法，把同步對象傳遞給不同的類。
（3）利用字符串常量的“原子性”。
對于第三種方法，這里做一下解釋。一般來說，程序代碼中的字符串常量經過編譯之后，都具有唯一性，即，內存中不會存在兩份相同的字符串常量。
（通常情況下，C++，C語言程序編譯之后，也具有同樣的特性。）
比如，我們有如下代碼。
String A = “atom”;
String B = “atom”;
我們有理由認為，A和B指向同一個字符串常量。即，A==B。注意，聲明字符串變量的代碼，不符合上面的規則。
String C= new String(“atom”);
String D = new String(“atom”);
這里的C和D的聲明是字符串變量的聲明，所以，C != D。
有了上述的認識，我們就可以使用字符串常量作為同步對象。比如我們在不同的類中，使用synchronized(“myLock”), “myLock”.wait(),“myLock”.notify(), 這樣的代碼，就能夠實現不同類之間的線程同步。本文并不強烈推薦這種用法，只是說明，有這樣一種方法存在。本文推薦第二種方法，（2）用參數傳遞的方法，把同步對象傳遞給不同的類。
3．線程之間的通知
這里使用“通知”這個詞，而不用“通信”這個詞，是為了避免詞義的擴大化。
線程之間的通知，通過Object對象的wait()和notify() 或notifyAll() 方法實現。
下面用一個例子，來說明其工作原理：
假設有兩個線程，A和B。共同擁有一個同步對象，lock。
1．首先，線程A通過synchronized(lock) 獲得lock同步對象，然后調用lock.wait()函數，放棄lock同步對象，線程A停止運行，進入等待隊列。
2．線程B通過synchronized(lock) 獲得線程A放棄的lock同步對象，做完一定的處理，然后調用 lock.notify() 或者lock.notifyAll() 通知等待隊列里面的線程A。
3．線程A從等待隊列里面出來，進入ready隊列，等待調度。
4．線程B繼續處理，出了synchronized(lock)塊之后，放棄lock同步對象。
5．線程A獲得lock同步對象，繼續運行。
例子代碼如下：
public class SharedResource implements Runnable{
Object lock = new Object();
public void run(){
// 獲取當前線程的名稱。
String threadName = Thread.currentThread().getName();
if( “A”.equals(threadName)){
synchronized(lock){ //線程A通過synchronized(lock) 獲得lock同步對象
try{
System.out.println(“ A gives up lock.”);
lock.wait(); // 調用lock.wait()函數，放棄lock同步對象，
// 線程A停止運行，進入等待隊列。
}catch(InterruptedException e){
}
// 線程A重新獲得lock同步對象之后，繼續運行。
System.out.println(“ A got lock again and continue to run.”);
} // end of synchronized(lock)
}
if( “B”.equals(threadName)){
synchronized(lock){//線程B通過synchronized(lock) 獲得線程A放棄的lock同步對象
System.out.println(“B got lock.”);
lock.notify(); //通知等待隊列里面的線程A，進入ready隊列，等待調度。
//線程B繼續處理，出了synchronized(lock)塊之后，放棄lock同步對象。
System.out.println(“B gives up lock.”);
} // end of synchronized(lock)
boolean hasLock = Thread.holdsLock(lock); // 檢查B是否擁有lock同步對象。
System.out.println(“B has lock ? -- ” +hasLock); // false.
}
}
}
public class TestMain{
public static void main(){
Runnable resource = new SharedResource();
Thread A = new Thread(resource，”A”);
A.start();
// 強迫主線程停止運行，以便線程A開始運行。
try {
Thread.sleep(500);
}catch(InterruptedException e){
}
Thread B = new Thread(resource，”B”);
B.start();
}
}
原文地址：
http://coolszy.javaeye.com/blog/588627 作者：
coolszy
1，朋友請你吃飯，不要覺得理所當然，請禮尚往來，否則你的名聲會越來越臭。
2，給自己定目標，一年，兩年，五年，也許你出生不如別人好，通過努力，往往可以改變70(百分號)的命運。破罐子破摔只能和懦弱做朋友。
3，這是個現實的社會，感情不能當飯吃，貧窮夫妻百事哀。不要相信電影，那只是個供許多陌生人喧囂情感的場所。
4，好朋友里面，一定要培養出一個知己，不要以為你有多么八面玲瓏，到處是朋友，最后真心對你的，只有一個，相信我。
5，不要相信星座命理，那是哄小朋友的，命運在自己手中。難道你想等出棟房子或是車子？
6，不喜歡的人少接觸，但別在背后說壞話，說是非之人，必定是是非之人，謹記，禍從口出。
7，少玩游戲，這不是韓國，你打不出房子車子還有女人。
8，學好英語，那些說學英語沒用的暫時可以不去管，他們要么年紀大了，要么就是自己早過了CET6準備托福了，在這里嘩眾取寵。你可以不拿證，但一定要學好。
9，知道自己要干什么，夜深人靜，問問自己，將來的打算，并朝著那個方向去實現。
10，偶爾翻翻時尚類的雜志，提高一下自己的品位。
11，盡量少看OOXX，正常的男人即使是單身，也不會成天迷戀OOXX。而每次你SY后都會有大量鋅元素流失，此元素與你大腦活動有密切聯系。
12，每天早上一杯水，預防膽結石。睡前一小時不要喝水，否則會過早出現眼袋。
13，空閑時間不要全拿去泡BAR，讀點文學作品，學習一些經營流程，管理規范，國際時事，法律常識。這能保證你在任何場合都有談資。
14，大家都年輕，沒什么錢，不用太在意誰誰又穿AD ，NIKE ，或者其他。而GF對于PRADA，蘭蔻，CD，LV，的熱戀，你也不必放在心上，女人天生和美掛上了勾，她們只是寧愿相信你能夠為她們買一樣昂貴的禮物，以滿足她們的虛榮心，然后在同伴面前炫耀一番。實則她們也是熱愛生活的，而當你有能力完成時，也會覺得把她包裝得漂漂亮亮的很是欣慰。
15，要做一件事，成功之前，沒必要告訴其他人。
16，頭發，指甲，胡子，打理好。社會是個排斥性的接受體，這個星球所需要的藝術家極其有限，請不要冒這個險，就算你留長頭發比較好看，也要盡量給人干凈的感覺。
17，不要以為你是個男人，就不需要保養。至少飲食方面不能太隨便，多吃番茄，海產品，韭菜，香蕉，都是對男性健康有益處的食物。你要是看不到價值，我可以告訴你。至少你能把看病節約下來的錢給你的女人多買幾個DIOR.
18，力求上進的人，不要總想著靠誰誰，人都是自私的，自己才是最靠得住的人。
19，面對失敗，不要太計較，天將降大任于斯人也，必先苦其心志，勞其筋骨，餓起體膚……但要學會自責，找到原因，且改掉壞習慣。 二十歲沒錢，那很正常；三十歲沒錢，那是宿命；四十歲沒錢，那是你已經成為女人了。