【摘要】隨著互聯(lián)技術(shù)的發(fā)展，特別是進入21世紀以后，互聯(lián)網(wǎng)技術(shù)的應用也越來越廣泛，從事互聯(lián)網(wǎng)創(chuàng)業(yè)的公司也如雨后春筍般應運而生，可是如果大家還是按照以往的軟件開發(fā)模式來管理項目，當軟件產(chǎn)品開發(fā)完成時也許市場上已經(jīng)沒有你的位置了，所以對于軟件產(chǎn)品需要快速迭代，縮短開發(fā)周期、并推向市場驗證可行性的項目管理模式。

【關(guān)鍵詞】互聯(lián)網(wǎng)企業(yè) ?項目管理 ?敏捷思維

一、傳統(tǒng)項目管理思想

傳統(tǒng)軟件項目開發(fā)管理方法主要強調(diào)軟件項目過程的規(guī)范化與工程化，其中最為典型的代表方法就是瀑布模型方法。瀑布模型法實際上源自一種軟件開發(fā)架構(gòu)，它于1970年被溫斯頓□羅伊斯（Winston Royce）提出。

瀑布模型將軟件生命周期劃分為制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

在瀑布模型中，軟件開發(fā)的各項活動嚴格按照線性方式進行，當前活動接受上一項活動的工作結(jié)果，實施完成所需的工作內(nèi)容。當前活動的工作結(jié)果需要進行驗證，如驗證通過，則該結(jié)果作為下一項活動的輸入，繼續(xù)進行下一項活動，否則返回修改。

從本質(zhì)來講，它要求軟件開發(fā)過程通過一系列階段嚴格按照順序展開，從系統(tǒng)需求分析開始直到產(chǎn)品發(fā)布和維護，依次通過。即是每個階段每個活動都只進行一次，最后得到軟件輸出產(chǎn)品。上一個階段產(chǎn)生的輸出結(jié)果被作為下一個階段的輸入對象，并且在利用上一階段輸出結(jié)果的基礎，對該結(jié)果進行評判，若是符合標準，就實施下一階段活動;若是得不到確認，則返回上一階段，重新執(zhí)行操作直到結(jié)果得到確認。

總而言之，瀑布型的開發(fā)模式開發(fā)周期太長;需求變更時會需要重新返工，增加開發(fā)成本和風險;在項目末期才可以看到成果，不易及時發(fā)現(xiàn)問題等缺點。

然而當下互聯(lián)網(wǎng)軟件項目期望開發(fā)周期不要太長，開發(fā)成本不要太高，能迅速應對變化，傳統(tǒng)的項目管理模式與人們的期望是南轅北轍的，因此需求新的項目管理思維成為了必然選擇。同時對于當下瞬息萬變的市場，以及不斷革新的互聯(lián)網(wǎng)技術(shù)，“變”成了常態(tài)，因此傳統(tǒng)的項目管理思想瀑布模型也需要革新。

二、敏捷思維

（一）敏捷的定義

在軟件開發(fā)領域，“敏捷”有時被人們等同于某種具體的敏捷方法如Scrum和極限編程（XP）。Scrum是一種軟件開發(fā)模型，它是建立在多個小型團隊緊密合作基礎上的一種模型。

戴維·里克（ David rico）博士對敏捷性有一個更通用的解釋：在變化無常的全球商業(yè)環(huán)境中，能夠快速響應變化并做出改變以獲得收益;當需求、技術(shù)和知識發(fā)生變化時，能夠快速地重新調(diào)整資源配置;通過充分地與客戶互動，對突如其來的市場變化和新的競爭做出快速反應;通過發(fā)展的、漸進的和不斷迭代的發(fā)布以整合成最優(yōu)的解決方案通過恰當、不過分的和及時的流程和文檔來實現(xiàn)最大的業(yè)務價值。

戴維·里克（ David rico）博士的解釋可以突出說明敏捷的最大優(yōu)點就是為了應對變化而生。

（二）Scrum角色分配

Scrum Master（Scrum推動者）： 是Scrum教練和團隊帶頭人，確保團隊合理的運作Scrum，并幫助團隊掃除實施過程中遇到的障礙。

Owner（產(chǎn)品負責人）：確定產(chǎn)品的方向和愿景，定義產(chǎn)品發(fā)布的內(nèi)容、優(yōu)先級及交付時間，為產(chǎn)品投資回報率負責。

Developer（開發(fā)者們）：由開發(fā)者組成，人數(shù)5-9人，團隊擁有交付可用軟件需要的各種技能。

（三）Scrum的四個會議

Sprint計劃會（Sprint Planing）

每日站會（Daily Scrum）

Sprint評審會（Sprint Review）

Sprint回顧會（Sprint Retrospective）

（四）敏捷的開發(fā)的優(yōu)點

提高可交付產(chǎn)品的質(zhì)量;快速適應變化;提供更好的計劃并且花費更少的時間創(chuàng)建它們;更好地控制項目進度和狀態(tài)。

（五）敏捷開發(fā)的特點

統(tǒng)一團隊：跨部門、跨職能溝通、提升協(xié)調(diào)和溝通能力;迭代開發(fā)：小步、快跑;用戶故事：盡早發(fā)現(xiàn)小問題，杜絕大問題;站立會議。

（六）總結(jié)

敏捷開發(fā)通過逐步細化、迭代前進的方式，分階段地將需求予以實現(xiàn)。在敏捷開發(fā)中，軟件項目的構(gòu)建被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。

敏捷軟件開發(fā)要注意項目規(guī)模，規(guī)模增長，團隊交流成本就上去了，因此敏捷軟件開發(fā)暫時適合不是特別大的團隊開發(fā)，比較適合一個組的團隊使用。對于一個創(chuàng)業(yè)公司一個小的團隊也可以考慮優(yōu)先選擇敏捷的方式管理項目。

總之，敏捷思維是進行最小可行性（Minimum Viable Product，MVP）研究最方便的項目管理方式，快速迭代開發(fā)，推向市場聽取用戶反饋，然后及時調(diào)整功能規(guī)劃。

三、敏捷思維在中項目管理的應用

（一）項目介紹

“馬踏飛燕”app是一款比價產(chǎn)品軟件，目前已經(jīng)上線的業(yè)務線有：機票、酒店、門票、火車票、出行、電影院、租車、醫(yī)美（美容產(chǎn)品），共8條業(yè)務線。作為一款比價產(chǎn)品的app從0到1 的過程之中并不是所有業(yè)務一起開發(fā)上線的，不同業(yè)務線不同時間的開發(fā)和上線也就是一個敏捷思維在項目管理之中的應用。

對于一個創(chuàng)業(yè)公司而言，重要是快速推出產(chǎn)品，到市場上去驗證可行性，如果等全部的業(yè)務線都開發(fā)完成上線，不知猴年馬月了，，市場也可能被人占領，也許到時你做出來的再好也無濟于事，其實對于互聯(lián)網(wǎng)的軟件創(chuàng)業(yè)項目而言，有太多失敗的案例了。

一款app有一個0到1的過程，對于其中一個業(yè)務線也是一個從0到1的過程，一條業(yè)務線的開發(fā)上線一開始并不是完美的，也是一個不斷完善和迭代的過程，由于自己開始負責機票業(yè)務線時，機票已經(jīng)經(jīng)歷了0到1這個階段，而是從1.1起步的。我所做的工作就是一個不斷完善的過程。以下僅從機票業(yè)務線版本的迭代來說明敏捷思想對于項目管理的應用與分析。

（二）版本迭代

對于每一次功能的迭代安排以及項目管理，我是根據(jù)項目的需求類別來換分的，不同的需求點，放在不同的項目版本之中，比如：機票的退票、機票的改期、延誤險、訂單頁面優(yōu)化等等，當然有時可能不是相關(guān)的功能，這類每次迭代都是按照項目需求功能的異同來進行迭代，或者根據(jù)優(yōu)先級來劃分。

開發(fā)流程：

以機票“延誤險”版本為例說明敏捷思想的應用。

（1）市場分析：機票產(chǎn)品與延誤險一起銷售可以說是市場的需要，其實就目前國內(nèi)各地旅游的平臺也都有這塊的業(yè)務，可以說是市場是成熟的，對于我們自己的app而言，別人有，我們沒有的話就是我們的不足，與別人對比就是我們的劣勢來，因此對于開發(fā)上線此功能顯得尤為重要。

（2）業(yè)務分析：既然決定開發(fā)延誤險功能，就需要有對接的第三方保險服務商，因為對于保險業(yè)務我們本身是沒有資源的，所以也就只有選擇第三方對接了，與第三方對接延誤險但需要切合我們本身機票業(yè)務，對方的延誤險只支持國內(nèi)機票，我們也就優(yōu)先給我們國內(nèi)機票增加延誤險產(chǎn)品了。

（3）需求分析：主要分析延誤險的相關(guān)屬性，例如：有效期、投保狀態(tài)以及與下單流程。

（4）原型設計。搞清楚需求，以及了解清楚第三方提供的接口文檔內(nèi)容，就進入原型設計階段了。此階段主要是完成下單的設計和后臺訂單的展示，以及對于異常情況的處理，比如：購買失敗等。

（5）ui設計。產(chǎn)品經(jīng)理完成原型設計由ui同事根據(jù)原型圖設計效果圖，即產(chǎn)品最終長成的樣子，顏色也好，文字樣式也罷，都由ui同事來負責。

（6）開發(fā)。ui設計效果圖的同時，開發(fā)同事已經(jīng)根據(jù)需求文檔進行數(shù)據(jù)庫等基礎功能的開發(fā)，ui完成頁面設計后，開發(fā)同事在進行頁面的開發(fā)。

（7）測試。開發(fā)的同事完成功能開發(fā)后交給測試的同事進行功能的測試。

（8）驗收。產(chǎn)品經(jīng)理負責驗收需求是否都已經(jīng)實現(xiàn)，ui同事負責驗收ui設計稿，即視覺層面的驗收。

（9）上線。大家都確認沒有問題后，由項目經(jīng)理來發(fā)布上線通知，安排項目上線。

（10）反饋。項目上線后，運營的同事根據(jù)用戶反饋以及市場反饋的結(jié)果在進行需求的整理，反饋給產(chǎn)品經(jīng)理，然后再進入下一個循環(huán)，對不足進行彌補。

一個個小的循環(huán)，組成了一個完成的項目開發(fā)周期，提高了開發(fā)速度，縮短了開發(fā)周期，降低了成本。

（三）會議

早會：每天的早上10：00項目組的成員都會開一個早會，主要交流是否遇到了問題，以及今天的主要工作內(nèi)容;周會：每周一的下午四點項目組的所有成員都會開周會，主要討論現(xiàn)階段的工作內(nèi)容，以及下一個階段的安排，以及遇到的問題;總結(jié)會：項目上線后一方面總結(jié)在本次迭代之中需要吸取的經(jīng)驗和教訓，另一面方面收集該功能上線后運營和用戶的反饋，方便不斷優(yōu)化。

敏捷思維在項目管理的每個階段的應用前景越來越廣泛，以上僅從敏捷對于項目管理開發(fā)的角度來闡述，也許還有不足，希望指正。

四、結(jié)語

當今不斷變化的互聯(lián)網(wǎng)環(huán)境下，互聯(lián)網(wǎng)企業(yè)的項目管理方式也在不斷革新，由于當下軟件產(chǎn)品差異性、個性化增加，在項目管理中需要靈活應用各種技術(shù)，提高軟件開發(fā)效率、降低軟件開發(fā)成本，保證軟件的產(chǎn)品質(zhì)量。

作者簡介：：雷棟（1989-），男， 山東省濟南市平陰縣人，學士，中國社會科學院研究生院，研究方向：項目管理。