現在這家公司的開發流程很奇怪，和以前的公司很不一樣
一、首先拿到乙個客戶需求，這個客戶需求（or）可能就只有一句話：「做***x運維成本太高了，管理也很混亂，能不能給做個管理系統給控制一下」
由於這個客戶很重要，所以雖然需求很不明確，連系統該做成啥樣都不知道，但是領導還是決定要做。於是專案組就啟動了。這個時候所有已知的東西，就只有這個一句話的or
二、第一階段，叫chart開發，這個階段找了很多業務專家，以及有現場運維實際經驗的人來。一邊猜想，一邊問。這個階段主要解決以下問題：
1、這個系統做出來要解決什麼問題
2、這個系統大概是啥樣的
3、這個系統做出來以後，使用者要怎麼用
然後這個階段專案組分成3個小組：「業務分析組」、「競爭分析組」、「技術預研組」，來並行工作。業務分析組就是和業務專家在一起，「猜測」系統應該是怎麼樣的，回答前面的3個問題。競爭分析組把同類的產品拿來看，自己邊用邊分析，其實就是模仿。技術預研組則是把有風險的技術先研究研究，免得到時候做不出來
這個階段結束以後，輸出了一堆文件。最重要的就是乙個叫「包需求」的東西。把前面的一句話or擴大了很多，變成乙個很長的需求列表。這個輸出是後面所有工作的起點。
我感覺這裡就有點問題了：
1、為啥叫包需求，我看了這麼多書，就沒見過有這麼乙個名詞，再說也很難聽
2、這個包需求，根據多個專案的經驗，相當不準確。遺漏或者瞎猜的情況很嚴重
三、不管怎樣，然後就進入第二階段了。這個階段叫「需求分析」，但是分析的不是原始需求了，而是上個階段輸出的「包需求」。這個階段把包需求分解了，也加了很多人進來。每天大家就對著包需求「想象」場景，輸出「場景分析」，這個場景分析之後，又把包需求分解成了一大堆「設計需求」（dr），這個dr也是乙個長長的列表，作為下一階段工作的起點
我感覺這裡又有問題了：
1、本來包需求就是有偏差的，經過進一步想象，或者說瞎猜，這一階段輸出的設計需求，已經和原始需求有了更大的偏差
2、很多人沒有經歷過上一階段，在這個階段空降加入，效率很低，溝通成本很高
3、實際的開發人員到這個階段還是沒有全部參與，這個階段的輸出傳遞會有問題
四、不管怎樣，接下來該進入第三階段了。這個階段的起點就是上個階段的「設計需求清單」，這個階段叫「設計階段」，把設計需求，再進行乙個「概要設計」，最後輸出乙個「使用者故事清單」（story list）。好吧，敏捷開發的名詞終於出現了，在經過了這麼久的瀑布之後。。
五、然後進入了迭代開發階段，這個階段才開始實際編碼。工作的起點是上個階段輸出的「story list」，每個開發小組對story進行迭代的簡單設計、開發、測試、整合測試。這個階段有點像敏捷開發了，包括站立會議、持續整合、交叉檢視等等手段都會引進來
六、總結，個人感覺，這個開發流程，前面是瀑布，後面是敏捷，我猜到了開頭，卻猜不到結局。。。
1、前面花了很大的力氣（至少3個月），進行需求分析和設計，但是這個需求分析和設計的結果，往往在開發階段發現有很多問題，部署後使用者表示和最初的想法有差距
2、前期的工作成果，傳遞得很不好，沒有參加前3個階段的開發人員，在開發階段基本不會去看前期的輸出，但實際編碼的又是這些人，這樣前期的工作意義又被削弱了
總之，我覺得還是我以前那個公司，開發流程更像真正的敏捷。雖然沒有站立會議、結對開發這種手段上的東西。但是出可執行交付的週期更短，使用者可以更快的反饋結果，浪費在需求分析和設計階段的時間更少
不過。。。體驗一下現在這種流程也不壞，有比較才有想法嘛~~
敏捷開發和瀑布開發的區別
個人覺得 敏捷開發強調以人為中心,快速迭代，客戶參與多溝通，減少不必要的文件,包括scrum和xp 優點 快速適應變化,做出的專案比較接近客戶需要的 缺點 文件不多，如果人員流動大，維護相對更難 瀑布開發強調文件，就是不同階段按照順序自上而下而來，如需求 設計 編碼 測試 單元測試 系統測試 維護，...
敏捷開發和瀑布開發的區別
最近和朋友談起敏捷開發和瀑布開發模式，很多人認為敏捷開發是未來的專案實施的趨勢，瀑布實施太老土已經過時了。另外確實一些跨國企業如索尼，聯想也在使用敏捷的方式實施一些專案。但實際上我們看到絕大多數公司還是依然在採用瀑布的方式實施專案。我之前參與過敏捷開發的專案，但當時比較 年輕 認識不是很深刻，於是最...
瀑布式開發和敏捷開發的對比
瀑布模型開發 嚴格把軟體專案的開發分隔成各個開發階段 需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出，下一階段的工作就不展開。強調文件，在開發的後期才會看到軟體的模樣。在這種情況下，文件的重要性彷...