我們比較熟知的軟體專案管理方法是瀑布。其基本流程是需求-> 設計->開發->測試。基本假設只要把每乙個環節都做正確，那麼最終得到的結果也是正確的。瀑布開發有非常成功的案例，比如微軟。但從總體來講，瀑布專案失敗率比較高。國外的軟體先行者們針對瀑布開發中暴露出來的問題進行了一系列的探索、思考和總結，提出了agile dev的概念，中文翻譯為敏捷開發。
敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。
換言之，就是把乙個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。相對於瀑布開發模式，敏捷開發更加靈活可操作。
敏捷開發有很多種方式，如scrum,xp,lsd，fdd等，其中scrum是非常流行的一種。
scrum將產品的開發分解為若干個小sprint(迭代)，其週期從1周到4周不等，但不會超過4周。參與的團隊成員一般是5到9人。每期迭代要完成的user story是固定的。每次迭代會產生一定的交付。
scrum的基本流程如圖所示：
敏捷流程中的三個關鍵要素是：
product backlog（產品需求）
sprint backlog（本期迭代任務）
burn-down chart（燃盡圖，進度的體現）
呈現了任務下達-拆分-推進的整個過程。
我們知道，瀑布開發是以文件為驅動，文件是一切工作的核心，po需要寫非常多而複雜的文件，例如：需求文件、設計文件、api文件、驗收文件等等。
敏捷宣言說，「可工作的軟體勝於詳盡的文件」。敏捷反對這種 「重文件」的方法，而是強調成員之間的緊密協作、面對面的溝通、頻繁交付的新版本、緊湊而自我組織型的團隊。可見，敏捷開發是更實際，更注重操作性的開發方式。
但這並不意味著敏捷開發完全拋棄文件，敏捷開發遵循「輕文件，重溝通」的原則。
「輕文件」體現在，敏捷開發只關注文件中的重要點，盡可能的簡化文件，或者用軟體工具呈現另一種形式的文件。
以傳統文件來說，乙個prd（產品需求文件）中包含對多個成員的訴求，比如前端工程師、後端工程師、測試人員。眾多的產品需求導致文件厚重繁瑣，而且在實際工作中，很多開發人員並不喜歡看文件。因為常常乙個prd中可能有好幾頁內容都是與自己無關的，但是要看過才知道是否與自己有關，這在無形中就造成了時間的浪費。
敏捷管理中採用了使用者故事的方式進行product backlog的呈現，「使用者故事（稱作user story）」是採用使用者熟悉的術語來表達需求的一種方法，是使用者講給開發人員的故事（實際由po蒐集使用者需求並整理成使用者故事）。
例如「作為禪道 使用者，我希望能實現自動登陸功能，這樣能更方便的登陸系統。「這就是乙個具體的需求描述。
在這個需求描述中，涉及到三個要素「使用者角色（禪道使用者）」、「達成的目的（自動登陸功能）」、「開發價值（更方便的登陸系統）」
當然除了這三個要素，還需要涉及到驗收標準、優先順序、評審人等。
借助軟體工具實現product backlog的資訊傳達是敏捷開發最普遍的做法。po把功能點拆分，匯入到專案管理軟體中，相關人員只需要按照需求目錄一條條執行即可，不再需要一頁一頁的看prd了。後端只需要與提供介面相關的，前端主要看與功能相關的部分，而不需要檢視與自己無關的內容。如果開發人員在具體的sprint backlog開發中存在問題和疑問怎麼辦呢？溝通！
「重溝通」體現在以結果為導向，以人為核心。通過面對面溝通的方式快速反應，推動進度。
你可以隨時一對一溝通po解除疑問。而且整個敏捷團隊還需要召開發布計畫會議、迭代計畫會議、演示會議等內部會議及每日站立會議。每日站立會議上，團隊成員依次回答昨天做了什麼今天計畫做什麼，有什麼問題，發現問題及時提出和解決。每個人發言完後，要走到任務看板前更新自己的燃盡圖。這也是敏捷流程中不可缺少的環節。
任務看板一般包含未完成、正在做、已完成的工作狀態，假設你今天把乙個未完成的工作已經完成，那麼你要把小卡片從未完成區域貼到已完成區域。每個人的工作進度和完成情況都是公開的，如果有乙個人的工作任務在某乙個位置放了好幾天，大家都能發現他的工作進度可能出現了什麼問題。
如今的任務看板和燃盡圖已經由實物形式轉變為專案管理軟體。表現形式基本延續實體看板的形式，禪道中分為未開始、進行中、已暫停、已完成、已取消、已關閉幾種狀態。在看板頁面，成員完成某項任務後即可從進行中拖拽到已完成列，跟實體看板的作用如出一轍。
比起傳統開發模式，敏捷更加強調去流程化，文件不再必須，變得可以簡化和被取代。因為在敏捷開發中，最簡單的解決方案就是最好的解決方案，最高效的工作方式就是最好的工作方式。
專案管理 敏捷開發 到底要不要寫文件？
最近第二次迭代時，我們帶領的開發小組長文哲，這兩天在補需求文件 部署文件 二次迭代完成了哪些客戶需求？未完成的？在迭代開發之前就應該有乙個文件即是不全，那該多好啊，不用現在這麼著急的補充啦。思考 倘若沒有文件，給客戶迭代完後，如何表明我們所做的內容呢？客戶是否滿意呢？如果沒有文件，和客戶的交流驗收時...
三月，躁動的季節。要不要跳槽？怎麼跳？
三月份，躁動的季節，都想出去看看。當你想離開一家公司的時候，你會發現，對公司各種不滿意。總覺得，別人的公司好。離開公司，無外乎幾個原因 公司摳門，福利各種不爽，別人都是15 16 17薪，而你才12薪。幹的不開心。感覺學不到啥東東，沒有晉公升空間。對領導不滿意，啥都不懂，整天各種瞎指揮。幹兩年了，沒...
到底要不要給開發人員管理伺服器的許可權03
1 考試題描述 問題場景 假如某it公司cto有這樣的困惑，到底要不要給開發人員管理伺服器的許可權?1 公司的運維人員和cto提出，不要給開發人員管理伺服器的許可權，尤其是超級管理員的許可權，因為那樣會影響整個伺服器系統的穩定，造成運維工作難以管理。2 但是，公司的開發總監確要求開放給他們管理伺服器...