開始本篇之前先來大致看看敏捷開發的內容：
首先敏捷開發的宣言：
個體和互動 勝過 過程和工具
可以工作的軟體 勝過 面面俱到的文件
客戶合作 勝過 合同談判
響應變化 勝過 遵循計畫
再來看一下，敏捷開發需要遵循的一些原則：
以上那麼多內容，簡言一下， 相對於標準化的cmmi開發， 敏捷開發的優勢是快速和變化。至於質量、客戶滿意度等這個本身就是軟體開發不可少的要求。
雖然agile 開發方法有以上的一些優點，但是不同的軟體開發方法適用於不同的專案實際的狀況 。連agile 的創始人之一 martin fowler也認為：
新方法不是到處可適用的。在以下情況下，適合採用agile方法：
專案是乙個大型的企業級應用系統基於某個平台的二次開發(系統主要是用來做生產、研發、等填單、流程以及對相關的智力資料進行管控)
專案的是給公司的全球使用者來使用(使用者超過6000)
雖然之前也有類似的系統在做管控， 但是基本上參考意義不大。 因為環境在變化、需求的變化也很快。使用者需要快速的就用到系統。
開發團隊有2位需求分析人員、4位經驗豐富的開發人員和2-3位測試人員
團隊的組建大概有6年時間，雖然大家能力和合作都還不錯， 但是缺乏激情和主動改進的動力。團隊之前的開發基本上是標準化流程開發居多。
使用者都很忙。
開發使用 jira 來進行任務分派。
系統分模組、分階段上線。
基於以上的描述狀況， 專案交付需要快速、變化比較多，看上去比較適合agile 的開發。其實，實際中也是自然而然的就使用了這種開發方法，因為如果再標準化的開發流程，就會面臨著很多的問題。慢慢的就形成了這樣的開發流程（針對某個模組）：
sa 與使用者進行需求的收集， 與使用者進行確認和溝通(ppt)
sa 拆分user case , 並撰寫規格(excel)
sa向ap解說規格並進行任務分派、時程規劃和需要demo prototype的安排。
ap 根據規劃，分階段進行開發，交付。
sa 對開發的功能進行測試。
sa 與 user 進行demo , 收集意見，分發ap 進行修改
4和 5 的步驟會重複多次
全部開發完成， qa 進入測試
測試完成， 進行模組的上線
以上流程仔細看， 很容易發現兩個問題：
沒有sd 的工作
測試看上去做的有欠缺
針對第乙個問題： 沒有sd的工作
首先， 時間比較緊， 再有， ap都比較資深， 所以大部分sd的工作都被省略了。但也因為這， 導致了一些後續的問題：
開發時間估計不足
sa 對**的估計always 總是樂觀，乙個頁面上欄位聯動的功能， 對於sa 來說，從功能層面上來說或許很簡單， 但是從開發層面來說， 需要考慮的部分卻更多，或者是有跨瀏覽器相容的考慮；或者是對既有元件進行擴充修改； 這個時間上的消耗遠遠超過了sa的預估。
另外， **層面上的一些相互影響也是ap 人員最為清楚， 所以sd 的工作， 有些部分是必不可少的。而且對於這部分工作不能單單是開個task 給某個sd進行完成， 應該有這樣乙個快速的會議， 讓相關的sd一起來風暴一下。對於估時以及時程的部分， sd也是要負一半的責任的。
**重用度不高， 堆砌嚴重。結構混亂
sa 與ap 單線聯絡， ap 開發的功能 sa 來驗證， 時程上有很敢， 導致ap 以最快的速度來完成功能的開發， 什麼**風格、**質量、**重用性、**維護性通通先放一邊， 先完成sa對於demo 的要求。 另外一方面， 這裡說了是demo 的要求， 所有的這些功能，有可能在demo 之後會被推掉重來， 所以花過多的時間去考慮功能之外的部分在ap 的角度看來，的確有一些得不償失， 慢慢的也就形成了堆砌嚴重甚至結構混亂。
追求速度不能丟掉質量， 針對特定的情況， 可以使用不同的方式來保證質量， 可以在系統稍微穩定一些的時候做一些**重用和**重構的工作， 但是必不可少。
針對第二個問題： 測試看上去做的有欠缺
從上面的流程可以看出：
sa 有在做類似的單元測試， qa 最後階段會做sit和uat合二為一的測試。
這樣的話，問題又來了
sa 的測試不充分
sa 為什麼要測試？ 原因是功能的變化很快， 每次的demo 總有一些變化， 大的可能要推到重來， 如果qa 過早進來測的來， 第乙個是bug 數量會很多， 再乙個是針對同樣的功能， qa可能會測試到一些不成熟的版本，浪費時間。由此， 穩定之前 sa 先進行測試。
但是sa 的測試是粗粒度的， 因為功能是sa 開出來的， 所以sa不需要參考規格來做測試。 sa 測試覺得有一些改動也會隨時找ap 來進行修改， ap 發現一些改進的部分也與sa 確認來進行一些修改。在這個過程中， 系統的功能總是在逐步的變化著的， 而sa 關注的只是某個點的功能， 而且sa 基本上不會做回歸測試。 改動後影響的部分怎麼樣了， 沒有人知道， 只能扔給最後一輪的qa 了。
qa 的測試總是緊急。
qa總是在最後階段才進入測試， 多的話， 可能預留1個月時間， 少的話也就半個月。 而qa 因為進入的時間晚，對系統的功能了解不多，光熟悉就要花費一段時間。熟悉之後的測試也是磕磕絆絆。時間上很難保證完成。
qa可以在晚點介入測試， 但是介入系統的時間應該要早些， 參與sa 與ap 的會議，參與user demo 的會議。
測試的質量不高， bug 漫天飛舞(真的？ 假的？)
以上也提到了，功能的改動會很多， 但是規格基本山很難與之同步改動, 這樣的話， qa進入測試的話，依據規格來測， 勢必出現很多問題。 有的是bug , 有的是規格未修改的部分。總之， 結果就是bug 漫天飛，平均的話乙個小功能產生兩個 bug。
ap 需要花時間看， 還要與sa check , 然後再與qa 說明，節省的一些時間終於被耗費掉了。
另外， 頻繁的改動後， 有時間甚至sa 自己對規格都不甚清楚了。 甚至出現要確認規格的時候，會出現sa 要ap 來說明的狀況。
後期需規格和補充規格及資料
清晰而正確的規格必不可少， 不然所有的都沒有依據了。 但是規格的完善可以放晚一些， 比如：放在qa 開始測試之前進行。
sd 某些工作必不可少(時間的double confirm 一級大體的設計)
所謂「先謀而後動」， 沒有設計的行動， 往往盲目或是在做一些重複功和無用功。sd可以簡化， 但是有些工作是不能剔除的，像時間和時程確認以及總體設計。
regular 收集需改進部分及定期的重構
系統需要持續改進，任何角色，sa, sd, ap,qa 只要發現系統有需要改進的部分都可以提出來， 統一安排進行改進。
定期code review
自律是乙個範疇的詞彙， 在不同的狀況下， 自律的程度不同，需求層次論可以很好的說明這個。所以， 定義的code review 對與提公升**質量的用處不僅僅是在code review 本身meeting 所發現的問題上。
需增加開發人員的測試和單元測試
黑盒測試的同時， 適當的補充一些白盒測試， 最好的就是ap 自己編寫的單元測試。準確、高效。
增加自動測試的部分， 規範qa測試的標準和流程。
加速測試的速度、提示測試的質量在agile 開發中應該起著該有的作用。
提公升qa 測試的能力， 區分bug的能力， 歸類bug, 完善測試流程與ap 互動， 對於加速開發不無益處。
除此， 匯入自動化測試來做一些重複的測試部分， 減輕qa 負擔， 加快測試。
樸素的Agile觀
去年，對門部門的同事喊我一起去開scrum的研討會，分享一些他們的經驗。雖然他們確實在用scrum的流程和方法，但是我發現他們還是沒有看到問題的本質 1 關注人，別只關注專案。2 雖然流程可以阻礙生產力，但是流程不能提高生產力。提高生產力唯一的方法是請好的人 3 軟體行業中，沒有用的文件和ppt最浪...
敏捷開發，英文是Agile，我所理解的敏捷
理論上的知識我看的不多，沒有很準確的概念，我想無論哪種開發方式都有自己的理論基礎，和相應的方法步驟，比如 瀑布模型，增量模型，迭代模型，敏捷方法等，並且由於專案不同，比如是否是新專案，二次開發專案，或者是維護專案，採用的方法也不盡相同，沒有固定不變的，不同的公司也可能不一樣，所以我只是說說我所理解的...
末日帝國 Agile公司的困境
接下來的幾天，阿捷滿懷信心地等待著agile的 等袁郎通知自己去拿offer，想象 著自己在座位旁的小白板寫些什麼，畫些什麼。可乙個禮拜很快就過去了，還是沒有任何資訊，阿捷幾乎想主動打 過去問問到底結果如何？但最終還是放棄了這 種念頭，因為如果agile公司想要自己的話，肯定會主動跟自己聯絡的。沒辦...