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