上接：
scrum節外生枝（二） 3.
乙個程式設計師卡殼了
有了一些工作經驗的程式設計師（也許可以擴充套件到所有的技術人員），都遇到過這樣的情況：在乙個本以為容易的技術實現上遇到未能**到的難關，長時間無法逾越。本來乙個小時能完成的feature，可能因為乙個severe 0 的bug，折騰得一天下來也無法完成，而後的一段時間，可能還在這個問題上繞來繞去，後續的工作都因此停滯，更糟糕的是，別人的任務也會因為依賴於他的任務而被拌住（blocked）。
相對於程式設計師的「順流」狀態，我稱這時候的程式設計師「卡殼」了。乙個程式設計師卡殼了，是個微觀問題。但是，你卡殼耽誤3天時間，過兩天他卡殼耽誤2天時間，整個專案的交付在不知不覺中就被拖延了。在scrum開發中，如果因為乙個人的卡殼，致使其本人的任務，甚至其他人的任務被拖延2到3天完成，在短至2周的sprint中，是一種極其令人沮喪的體驗。
在scrum的教科書中，很少有提到這種情況該如何辦？（可能我讀的書太少。如果有，請告訴我。）我們只有再讀讀scrum的原則，看看哪一條能給我們指條明路。還好，我們發現了「集體所有權（collective ownership）」這一條（見《scrum敏捷軟體開發》第9章）：
「所有的開發人員共同負責開發過程中的所有產出內容，特別是**和自動化測試。」
好吧，不要再讓卡殼的程式設計師，看到自己和別人被拌住，而急得冒汗了。來吧，所有被絆住的人，或者此刻閒下來的人，都請聚過來，我們可以結對程式設計，一起分析**，解決bug。「我不太懂這部分**。」那也沒關係，了解出現的問題，開啟乙個google，搜搜看有沒有別人遇到過同樣的問題。總之，不要在那裡打遊戲了，過來幫幫忙，咱們都是一條繩上的螞蚱。不要將scrum理解為：在sprint中每個人都有各自的任務。要理解為：所有人都有共同的目標。
集體所有權是個好東西，但是這個氛圍的培養談何容易。很多企業中，每個程式設計師都只負責各自管轄的那些**，好學一點的，能看看別人的程式，大多數都是馬路警察，懶得看其他人的「爛」**。我們的經驗是，每個成員加入團隊的那一刻起，他的manager或者lead，就要要求他盡量多地熟悉每乙個模組，每乙個元件，每乙個層次的**，不斷地分配給其不同部分**的編寫和修改任務，不讓其在腦子裡出現「哪段**是他的，哪段**是我的」的想法。我們還曾嘗試經常交叉變換程式設計師負責開發的功能模組，以促使他們學習系統中的新東西。原來我們分server和client兩個行政上的team以分別負責2端的**，後來這個也取消了，當乙個程式設計師實現乙個功能時，它既能改ui和客戶端的邏輯**，也能改伺服器端對request的處理**。
要想不讓「卡殼」影響進度，努力是從新人剛剛加入團隊的那一刻開始的。
（待續……下一節：太多的外界干擾）
SCRUM節外生枝（五）
上接 scrum節外生枝 四 5.bug！bug！bug！理想中的scrum世界，不需要驗收測試階段，因為每個sprint結束，都會交付乙個可發布的版本。但是，現實中每個sprint結束後都會不斷湧現新的bug。所以 硝煙中的scrum和xp 說 你大概沒法取消驗收測試階段 但正是這sprints之...
SCRUM節外生枝（四）
上接 scrum節外生枝 三 4.太多的外界干擾 很多公司，都面臨乙個問題，在研發新產品的同時，還要應付對舊產品的維護任務。另外，來自市場 客戶服務 人力資源等部門的事情不斷地打斷專注於研發的scrum團隊。比如 市場部門需要技術人員參加展覽展示會做技術後備，客戶服務部門要請技術人員到現場解決在客戶...
SCRUM節外生枝（一）
每個接觸 scrum 的人，可能很快被 scrum 框架所描繪出的美好景象所吸引，scrum 所運用的方法和流程不難被理解，很容易被擁戴者拿來試驗或實施。但當到達某個微觀步驟時，一些節外生枝的事情總會發生，scrum 的聖經裡沒有藥到病除的良方，有的只是過來人親身體驗的痛苦和有關成敗的感慨。1.牴觸...