生命周期法是用于信息產(chǎn)品（軟件、網(wǎng)站、互聯(lián)網(wǎng)產(chǎn)品等）設計和開發(fā)的常用的設計思想。
生命周期法常用的模型有：瀑布模型（文檔驅(qū)動）、迭代式模型（功能驅(qū)動）、快速原型模型等。
問題所在： 隨著各種技術(shù)和市場和環(huán)境的進化，設計開發(fā)的流程也面臨很多問題，一些深植在我們內(nèi)心的看上去很經(jīng)典的流程實際上已經(jīng)不能滿足現(xiàn)在設計和開發(fā)。
所以團隊才經(jīng)常會在項目進行中感覺進度緩慢、沒有共同的交流語言。
首先我先提出兩個現(xiàn)在在業(yè)界對于流程的改造的主流思想。
1、UCD（用戶中心的設計）嵌入傳統(tǒng)軟件設計和開發(fā)流程；
2、敏捷開發(fā)嵌入傳統(tǒng)軟件設計和開發(fā)流程。
一、UCD（以用戶為中心的設計）的興起和流程
首先，我們來看一下，傳統(tǒng)的軟件設計和開發(fā)流程是什么。
經(jīng)典軟件開發(fā)流程（隨便找的，但是基本上大同小異）：
這幅圖中我們看到了很多我們或許誤解但是經(jīng)常掛在嘴邊的概念。而這些概念每個人對他的理解不同從而導致流程沖突。
這幾年，大家都或多或少聽說了”用戶體驗“這個詞。
其實在行業(yè)里邊，”用戶體驗“”交互設計“的概念也很容易混淆。我們不談論太多的概念。因為概念本身就是抽象的，沒有
太多操作層面上的指導意義。
UCD的興起是因為行業(yè)的進步和為了解決新問題的出現(xiàn)。
問題1： 以前，一個項目開始的時候，以開發(fā)者為主的團隊習慣的考慮的視角是程序本身，而甚少關(guān)注市場需求和好不好用。
也就是說，習慣性的只關(guān)注程序本身的性能而容易忽視了這個功能到底客戶需不需要；
問題2：銷售項目或者產(chǎn)品的時候，或者跟客戶交流來定義需求的時候，總是無法將雙方的視角統(tǒng)一?？蛻舨欢夹g(shù)，急需一種
直觀的東西來交流；
問題3：對于團隊內(nèi)部。 也少了一個環(huán)節(jié)來把 最重要的“需求”“好用”來重點進行設計。因為，現(xiàn)在的用戶對于信息產(chǎn)品的好壞已經(jīng)
不是能不能完成功能，而是好不好用。蘋果因為把交互和體驗等用戶分析做的很好，所以才走在了前面。其實這也正是現(xiàn)在用戶體驗這個
詞大熱的主要原因?，F(xiàn)在很多互聯(lián)網(wǎng)產(chǎn)品失敗的重要原因及時所謂”三無“：無設計、無體驗、無目標。
- 概念不重要，只要其本質(zhì)能夠推動團隊前進并且達成結(jié)果就行。
在傳統(tǒng)的流程中，不是沒有分析市場需求、交互設計的過程。只是這些過程被埋沒在了開發(fā)者思想主導的陰影里邊。我們再來看一下
UCD流程是如何嘗試嵌入傳統(tǒng)經(jīng)典的開發(fā)流程的：
首先我想說明的是，這張圖標實際上已經(jīng)是很早之前的成果了。其創(chuàng)作者本身正是ajax技術(shù)的創(chuàng)作者。
這樣的東西其實現(xiàn)在看來也有很多地方需要改進。
- UCD流程的嵌入是對傳統(tǒng)流程的優(yōu)化，并不是推翻。
UCD流程的嵌入，是銜接商業(yè)目標和軟件開發(fā)的一個中間層。
其實狹義的UCD流程也在解決軟件開發(fā)中，設計和邏輯的沖突。即前臺和后臺分割的工作流。比如microsoft blend，adobe 催化劑等。
UCD將整個產(chǎn)品開始的商業(yè)計劃階段、用戶體驗階段從傳統(tǒng)的以開發(fā)視角為導向的混在在不同流程中抽離出來，并加以固化和深化。
將強迫整個團隊，將風險提早暴露，而不能等到最后才發(fā)現(xiàn)問題。
- 商業(yè)價值通過滿足用戶需求（用戶需求）或者制造需求（網(wǎng)站目標）體現(xiàn)，需求通過功能體現(xiàn)，功能通過用戶體驗和交互設計來可視化和優(yōu)化，并最終通過代碼實現(xiàn)。
其實傳統(tǒng)的軟件設計流程有一個大前提，就是商業(yè)需求已經(jīng)確定，甚至不需要確定，因為早期的軟件出來就有市場。所以，傳統(tǒng)的軟件設計流程開始其實
始于一個既定的目標和相對確定的需求。類似于項目的流程。
而現(xiàn)階段，很多團隊問題是，一開始將產(chǎn)品設計和項目混雜在一起。商業(yè)目的沒有確立的情況下直接開始功能的設計。跨度太大導致了團隊的迷茫。原因還是
沒有一個對流程的透徹的理解。
下面的圖表是我對于 商業(yè)開發(fā) UCD流程 和傳統(tǒng)開發(fā)流程的整合的一些對比和思考。
- 商業(yè)開發(fā)系列： BRD（商業(yè)需求文檔） MRD（市場需求文檔） PRD（產(chǎn)品需求文檔）。其實從這三個文檔，就可以看出，不同階段所說的需求是不一樣的，混淆了階段只能讓團隊迷茫，不知道該做什么而雜亂無章。
- UCD流程：戰(zhàn)略層（其實就是商業(yè)計劃等大的戰(zhàn)略層面的確定）（對應的就是BRD）——》范圍層（大的商業(yè)概念下的需求細分以及整合，尋找一個邊界。）（其實對應的就是MRD，旨在市場層面上分析）————》結(jié)構(gòu)層（交互設計等，將前一個環(huán)節(jié)產(chǎn)出的經(jīng)過市場研究的需求轉(zhuǎn)換成的功能，在交互層面上進行設計和優(yōu)化，目的是解決用戶中心理念的好用）（對應PRD）——》框架層（交互做好之后，將形成信息架構(gòu)和導航設計，形成界面以及原型）——》表現(xiàn)層
| 商業(yè)開發(fā) | UCD流程 | 經(jīng)典軟件開發(fā)每個環(huán)節(jié)對應 | 經(jīng)典軟件開發(fā)流程 | 其他開發(fā)流程 |
| BRD（商業(yè)需求文檔） | 戰(zhàn)略層 | 經(jīng)典軟件開發(fā)項目的特性決定了產(chǎn) 品設計已經(jīng)做好，所以不涉及商業(yè)需 求階段的環(huán)節(jié)。 | 市場調(diào)研 | 要件設計 |
| MRD（市場需求文檔） | 范圍層 | 1、市場調(diào)研 2、需求分析 | 需求分析：用戶視圖、
數(shù)據(jù)詞典和用戶操作手冊 |
|
| PRD | 結(jié)構(gòu)層 | 需求分析中的數(shù)據(jù)詞典、用戶操作手冊 | 概要設計：包含了原型設計的內(nèi)容 |
|
| PRD | 框架層 | 需求分析中的用戶視圖；概要設計；詳細設計 | 詳細設計：詳細設計說明書
（包含了界面的部分） |
|
| PRD | 表現(xiàn)層 | 詳細設計 | 編碼開發(fā) |
|
| 無 | 無（UCD流程走完之后，最終產(chǎn)出物交給開發(fā)階段） | 編碼 | 測試 | 項目設計 |
| 無 | 無 | 測試 |
|
|
|
| 上面可以看出經(jīng)典的流程按照UCD
的流程被拆分了。所以才會出現(xiàn)之前
講到的問題。就是沒有足夠重視一些東西。 | 上面可以看出，經(jīng)典開發(fā)流程中設計部分
也占了工作量的70%，所以，我才說，
UCD只是一種優(yōu)化和重構(gòu)，并沒有推翻經(jīng)典模式。 |
|
從圖中可以看出：1、不同的流程有不同的重點，所以有些流程中會出現(xiàn)無的狀態(tài)；
2、經(jīng)典軟件開發(fā)流程有強烈的項目特性，其前提是商業(yè)計劃階段的確定和需求的固化；
3、可以看到，經(jīng)典軟件開發(fā)流程中不是沒有用戶分析等UCD流程，只是被打散了。所以才會導致前面講到的問題；
4、其實概念名字的不同只是名字不同而已，看本質(zhì)實際上解決的問題是一樣的。
問題： 專家告訴我，UCD流程之后的開發(fā)流程被這樣切成了兩端，而將UCD流程和開發(fā)流程銜接起來是件很難得事情。
我的理解是：
1、UCD流程中，是需要開發(fā)人員介入的；
2、這不是一個瀑布模式，不是嚴格的從前到后。后面我將說到基于快速原型和迭代增進的方法。其實流程之間是重疊的，不是絕對分割的。
所以這也不存在一個絕對的一分為二的說法。
二、敏捷開發(fā)嵌入傳統(tǒng)軟件設計和開發(fā)流程研究
我們討論了幾個流程的統(tǒng)一和不同之處。我么在討論一下如何在現(xiàn)實中操作層面有真正借鑒意義的流程。
大家可以發(fā)現(xiàn)，前面講了那么一大堆，無論是UCD流程還是什么，都有著從前到后，從頂層到底層的類似瀑布流的模式。
這正是問題所在。
之前講過，瀑布流模式存在很多問題，所以無論使用任何前面講到的流程，如果還是瀑布模型，將或多或少出現(xiàn)問題。
敏捷開發(fā)出現(xiàn)背景說明：
1、快魚吃慢魚
互聯(lián)網(wǎng)產(chǎn)品更新?lián)Q代非常之快。就不細講了。
2、總想快速完成工作，而無論團隊資源有多少。
我的觀點：原型法又叫快速原型法，主要是用來解決需求問題的。而迭代則是開發(fā)過程中不斷的重復一些過程，是解決開發(fā)過程中的風險控制的。而增量法基本上都是和迭代法配合使用，所以我們平時說迭代法的時候，基本是在說迭代增量法。
所以迭代其實不只是用在開發(fā)過程，每一個環(huán)節(jié)都可以經(jīng)過一次迭代過程。
比如需求確定階段。
常見開發(fā)模型比較
| 概論 | 缺點 | 優(yōu)點 |
| 瀑布模型 | 按照流程或者設定好的里程碑從頂層往下一步一步的開發(fā)。 上一步的產(chǎn)出物（文檔驅(qū)動）沒有結(jié)束之前，下一步處于停滯狀態(tài)。 其思想是認為整個系統(tǒng)若干個環(huán)節(jié)后的狀態(tài)可以再一開始就能加以理解。 | 因為是文檔驅(qū)動的，所以不直觀； 現(xiàn)在的需求分析本身就是一個變數(shù)極大，并且現(xiàn)在的很多產(chǎn)品 更新?lián)Q代很快，所以，指望全盤理解是不可能的；
|
|
| 迭代式模型（敏捷開發(fā)） | 迭代類似于小型的瀑布模型，旨在快速走一遍流程出現(xiàn)一個基本核心功能的原型或者可執(zhí)行版本，然后核實。然后再進行一遍優(yōu)化的迭代過程，其版本號將會增加。如果有新的功能增加，則新的的迭代過程叫做增進迭代。他是功能驅(qū)動的，產(chǎn)出物是為了實現(xiàn)功能，而非文檔。 在每個瀑布模型的環(huán)節(jié)里邊都可以進行一次微型迭代。 | 因為你不基于文檔驅(qū)動，所以熟悉文檔并且嚴謹?shù)膱F隊個性可能會增加文檔控制的難度。 | 及早暴露了風險所在，因為每次迭代的結(jié)果輸出的是原型或者可執(zhí)行文件，更加直觀。 |
| 快速原型模型（敏捷開發(fā)） | 原型設計是一個工具，是為了確定真實的需求，并且提供修改和討論的直觀的載體。其可以和其他流程工具結(jié)合。 |
|
|
敏捷開發(fā)的精髓在于打破僵化的固有流程，一切靈活的為了團隊需要。
故我最終的解決方案是：迭代式的敏捷開發(fā)。流程并進基礎(chǔ)上的修改和優(yōu)化。（即不是一環(huán)扣一環(huán)，而是環(huán)節(jié)需要一起推進，不能等到前一步驟完全確定在開始后一階段）
1、假設商業(yè)需求已經(jīng)確定： 通過網(wǎng)站積聚人氣，滿足創(chuàng)業(yè)群體的需求，盈利來源是線上服務的中介費和線下服務盈利。并且決定產(chǎn)品概念就是一個門戶和社交功能集合的網(wǎng)站；
2、市場需求確立階段，即MRD、范圍層、要點設計、市場調(diào)研和需求階段等。
微型迭代下走過這個流程（包括：領(lǐng)域調(diào)研、用戶分析、主要功能和非主要功能、功能優(yōu)先級、功能規(guī)格整理、業(yè)務邏輯整理等），產(chǎn)出物是快速實現(xiàn)的一個供討論的原型。此原型之對需求定義負責；
3、交互和用戶體驗的階段微型迭代過程： 在前一個原型確立了市場需求之后，開始走用戶體驗流程（交互設計、用戶可用性等），產(chǎn)出原型供討論和修改。
本次迭代之后出來的原型，可以交給開發(fā)組進行開發(fā)階段的設計過程。因為此階段開發(fā)人員一直是介入的所以原型已經(jīng)是符合各方的修改意見；
4、開發(fā)階段進行的同時。 將進行界面相關(guān)控件和組件設計等詳細界面設計、信息設計（控件上的文字）、導航設計、視覺設計等，然后將原型和詳細設計說明書交給開發(fā)階段的前端開發(fā)人員寫前端腳本；
5、開發(fā)階段也將采用迭代增進法。一般在一定時間內(nèi)比如一個月內(nèi)，走一個迭代流程，完成一個功能重點。然后在進行審核，再迭代。
