背景

        自從我們使用scrum進行專案開發後，出現了這樣那樣的問題，有些是因為我們對scrum的理解不到位，有些則是客觀因素導致的，針對這些問題，在每次迭代的總結會上，我們進行了反思，並根據具體環境對scrum進行了一一調整，想通過幾篇文章和大家分享一下我的經驗。

我說的不一定正確，只是描述問題，然後說說我對問題的看法，採取的解決方案，希望使用敏捷開發的大牛提供寶貴意見。

到底要不要文件？ 以前我們做專案多采用傳統的瀑布模型，前期有詳盡地需求文件，設計文件，如果發生變更，還要遵循複雜地變更流程，很多時候文件得不到及時地更新，專案做完了，但是專案跟文件根本對不上，而且偏差很大，給維護人員造成了很大的麻煩，所以弱弱地說一句，瀑布模型不太適應變化。文件成了讓我們頭痛的問題。 從去年開始，我們開始採用scrum開發，讓我們眼前一亮的是，“scrum不提倡寫文件”（真的嗎？）。所以我們在得到基本地需求後，就開始上馬開發了，但開發了一段時間後，被一個領導L叫停了，他讓我們準備整個專案的wbs，甘特圖，搞清楚我們到底要完成哪些任務，這些任務的輕重緩急，有個整體地規劃。而另一個領導X，也就是我們scrum的領路人並不提倡我們寫這些文件。我們夾在兩個領導之間，著實鬱悶了幾天，最後我們遵循了領導L的意見。 但專案進行中，我們並沒有寫需求文件，只是根據簡單地需求描述，就開始實施設計，開發。開發過程中，發現設計不合理，改設計，發現需求理解不到位，接著該設計，在開發人員頻繁地修改中，總算是滿足了基本的需求。不可否認，遇到問題，能夠及時解決問題，scrum的確能快速地響應變化，但這樣真的沒問題嗎？我們遇到了兩次這樣的衝突，“你當初就是這麼設計的，是你讓我這麼開發的”，“我絕對沒有這樣設計，我當時的意思是……”，“你做的根本不能滿足需求”，“需求就是這麼說的”。好吧，需求，設計，開發之間地扯皮，推卸責任開始了。 面對這種情況，scrum master該如何處理？我繼續翻閱相關資料，發現我們犯了一個致命地錯誤，scrum並不是不提倡寫文件，而是不提倡冗雜過度地寫文件。回想起領導L說的那句話，“我感覺，你們有用敏捷開發當擋箭牌，拒絕寫文件的味道”（大概是這麼個意思吧，懶得再查閱email了），現在看來，當時剛接觸scrum，如獲至寶，感覺終於可以擺脫文件了，一激動，就理解片面了。發現問題後，我們決定採用wiki工具（後面會單獨寫篇部落格，談談敏捷開發的工具）對文件等進行管理，對需求（使用者故事）等核心文件進行逐步完善，使變化可追溯，不至於出現需求，設計，開發互相互相扯皮的情況，少了很多爭吵，說好聽點，讓專案組更和諧了。 ------------------------------------------------------------------------------------------------------------------ 查閱scrum資料的時候，發現了一些大牛部落格中說得很有道理，列在下面，供大家參考： 大型專案尤其是系統工程級別的專案，比如軍工、航空類專案，設計的工作量很大，原因是這種投入畢竟是可控的；而一旦由於設計工作不充分，導致嚴重的返工，則往往不是簡單的費用問題，還往往造成專案被終止。因而在這類專案中推廣敏捷，應該適當增加文件的數量，以便長期專案能夠按計劃完成。在網際網路、消費電子行業則正好相反，返工主要是由於業務變化而不是錯誤或不足的設計引起的；相反過度設計往往在未被付諸實現之前就已經過時，反而形成浪費。因此在這類專案中推廣敏捷，應當適當降低文件的數量，以便在業務變化時輕裝上陣，而不需要同步修改大量設計文件。 應當理解敏捷開發的出發點不是不寫文件只寫程式碼，而是減少浪費，以便能按照自己專案的特點，靈活選擇文件的數量及其形式， 在過度設計和返工之間找到平衡。                              --------------摘自火星人，陳勇http://blog.csdn.net/cheny_com 忽視文件的另一大原因，是將敏捷思想中的“可工作的軟體重於面面俱道的文件”理解為“軟體開發可以不寫文件”（敏捷宣言中用的是“面面俱道的文件”，而不是“言簡意賅的文件”）。相信不少團隊正是將這一敏捷思想當作不寫文件的“擋箭牌”。                                                                                     ------------李雲 http://blog.csdn.net/hzliyun/article/details/7880217 ------------------------------------------------------------------------------------------------------------------ 回頭最初領導L要求的wbs，甘特圖，其實他的初衷並不是讓我們寫繁雜地文件，只是讓我們有個全域性觀，分清任務地輕重緩急，有個整體的計劃，有計劃總比沒計劃要好。直到後來，因為專案之初沒有把系統介面放在網路圖的關鍵路徑上，導致後續開發延誤，我才真正意識到領導L當時的苦衷，其實領導L要求的文件，在scrum上就是一個具有優先順序的backlog，而當時我們並沒有對此足夠重視，我們的backlog不斷更改，也給我們的工作造成了不少麻煩，感觸很深，如果能找到一個既有非常熟悉需求、又有資格和權力設定Story優先順序的產品負責人，真的不容易。在我們專案組是採用幾個人一起扮演產品負責人的角色。 寫不寫文件？答案已經很明瞭了，文件要寫，根據專案特點有所取捨。 我有一個沒有實踐的想法，如果在專案團隊中增加一個專職的文案，這個文案必須懂技術，雖然增加了溝通成本，會不會進一步減少團隊成員的文件負擔，提高效率？不成熟的想法，有待以後實踐。