最近第二次迭代時，我們帶領的開發小組長文哲，這兩天在補需求文件、部署文件（二次迭代完成了哪些客戶需求？未完成的？），在迭代開發之前就應該有乙個文件即是不全，那該多好啊，不用現在這麼著急的補充啦。
思考：倘若沒有文件，給客戶迭代完後，如何表明我們所做的內容呢？客戶是否滿意呢？如果沒有文件，和客戶的交流驗收時就很難辦了？
記得合作開發的時候，前期花費了很長時間，我們是採用了傳統的瀑布模型，需求文件、概要設計、詳細設計、資料庫設計、甘特圖等文件都是前期設計全了，遵循著文件驅動開發，當我們開發過程中到最後，發現文件、圖、解決方案根本對不上了，中間修改了很多，相差很多，再驗收以前我們三個是餓補啊，在整個開發的過程中由於前期的設計不可能考慮的很詳細，每一步不可能考慮的很清楚，最後的文件成了我們頭大的問題。
自從接觸了敏捷開發，我們就體會到這個開發思想不提倡寫文件（很爽啊，先開發，當初理解的淺顯）我們現在根據客戶的需求拿來就開始幹了，在這個過程中確實使用著禪道等專案管理工具，但是現在體會還是有些亂，規劃的還有很多不合理的地方，給大家的每天的目標還不是很明確（時間段、任務、彈性時間、困難、該完成什麼功能？）沒有明確的規劃，可能會引發專案拖延，時間一長大家會有懈怠心裡啦。
專案一開始，根據客戶的需求我們就開始幹了，設計、開發、等真正給客戶架過去之時發現需求理解的不是很到位、使用還有常見的bug（測試文件沒有）等，造成了沒有給客戶部署成功、我們浪費時間、給客戶留下不好印象等等一系列問題，敏捷開發確實可以應對一些變化，但是因為文件不全的問題又一些給大家帶來了苦惱。
今天抽些時間查了敏捷開發的相關資料，敏捷並非不寫文件，而是重視文件的作用，也重視文件的維護；它認為文件宜少且精煉，不需要冗餘的文件；文件也是作為細化部分，在每個迭代過程中不斷重構；一般需求文件、概要設計、詳細設計、資料庫設計、專案管理文件（甘特圖等等）都是必須的，在許多外企的迭代開發中都是這樣的，倒是國內的公司確實提倡一種：敏捷無文件，開發效率慢， 基本的文件都是必須的；敏捷開發中的寫文件，有了方向性的指導。
開發要有開發文件（需求文件、資料庫設計、概要設計）、開發計畫（甘特圖、燃盡圖）、測試計畫（時間、地點、人員、任務模組分配、禪道bug提交管理）都應該有乙個時間段，在大家的一起商量之下可以每個人做到心中有數，對任務整體有個全域性觀，我們每天該幹什麼？緊急重要的需求？客戶迫切需要上線的功能？都有乙個好的規劃，避免在不必要的文件上（官話、客套話）浪費更多的時間，勁使在刀刃上，提高我們的開發效率，有明確的目標、去按照我們的計畫一步步的完成。
各個工作流自有它的價值……努力吧，繼續深入理解敏捷開發理念！
到底要不要考專案管理證書？
專案管理屬於管理學範疇，發展數十年，已形成多套成熟的專案管理體系，包括pmp prince2等。專案管理作為一種職業，有多種職業資格證書，包括國產的資訊系統專案管理師 一級建造師，泊來的pmp prince2 acp pgmp等。國產的專案管理學起來較難，知識量大，貼近國情，考試費用低。pmp等泊來...
敏捷開發中的問檔 要不要寫？怎麼寫？
我們比較熟知的軟體專案管理方法是瀑布。其基本流程是需求 設計 開發 測試。基本假設只要把每乙個環節都做正確，那麼最終得到的結果也是正確的。瀑布開發有非常成功的案例，比如微軟。但從總體來講，瀑布專案失敗率比較高。國外的軟體先行者們針對瀑布開發中暴露出來的問題進行了一系列的探索 思考和總結，提出了agi...
短期工作經歷到底要不要寫到簡歷上？
短期工作經歷到底要不要寫到簡歷上？建議三個月的工作經歷不要寫，企業看中穩定性。如今這個時代，跳槽已經是乙個非常常見的事情，而且跳槽已經成為了職場人晉公升加薪的常見方式之一，但是過於頻繁的跳槽反而特別容易被面試官覺得你是乙個職業方向不明確 缺乏穩定性的員工。很可能是一些客觀因素導致了之前的頻繁離職，但...