現(xiàn)在的商業(yè)環(huán)境復(fù)雜多變，從IT系統(tǒng)項(xiàng)目管理的角度來(lái)說(shuō)，存在著多種模式的項(xiàng)目管理。敏捷開(kāi)發(fā)的概念已經(jīng)不新鮮，但是在實(shí)踐中還是沒(méi)有得到廣泛應(yīng)用。

在我們最近做的一個(gè)項(xiàng)目中，就引入了敏捷開(kāi)發(fā)的一些思想。本文以這個(gè)項(xiàng)目為例，介紹了一些敏捷開(kāi)發(fā)項(xiàng)目管理的實(shí)踐經(jīng)驗(yàn)，希望為大家提供一些思考和借鑒。

    項(xiàng)目要求，不到4個(gè)月的時(shí)間內(nèi)，要完成PC端，APP的產(chǎn)品開(kāi)發(fā)，并且在6月30日上線。為了應(yīng)對(duì)未來(lái)大數(shù)量高并發(fā)的需求，項(xiàng)目采用分布式開(kāi)發(fā)和分布式部署方式。在開(kāi)發(fā)模式上，采用了敏捷開(kāi)發(fā)的模式。  
  

下面就具體講講我們是怎么完成這個(gè)項(xiàng)目的。

  遇到的第一個(gè)問(wèn)題：需求的問(wèn)題。

    由于項(xiàng)目不是標(biāo)準(zhǔn)的瀑布式開(kāi)發(fā)模式，而且類似互聯(lián)網(wǎng)公司的產(chǎn)品化開(kāi)發(fā)。一開(kāi)始，只有一個(gè)需求列表。我們沒(méi)有專門的需求人員，客戶充當(dāng)需求人員。然后我們的UI人員就和客戶一起設(shè)計(jì)APP的頁(yè)面，之后我們根據(jù)demo頁(yè)面進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)和系統(tǒng)詳細(xì)設(shè)計(jì)。

    由于系統(tǒng)整體的組織架構(gòu)，以及數(shù)據(jù)權(quán)限的問(wèn)題，導(dǎo)致項(xiàng)目的組織權(quán)限體系比較復(fù)雜。另外，由于不熟悉業(yè)務(wù)，程序員在理解上有困難，接收起來(lái)比較慢。

    對(duì)策：

1. 強(qiáng)化業(yè)務(wù)培訓(xùn)和主數(shù)據(jù)結(jié)構(gòu)關(guān)系培訓(xùn)。這個(gè)的實(shí)現(xiàn)效果不是很好，畢竟主數(shù)據(jù)的邏輯關(guān)系比較復(fù)雜。

2. 沒(méi)有需求文檔就用設(shè)計(jì)文檔代替。在demo制作的同時(shí)，確立主數(shù)據(jù)設(shè)計(jì)思想和實(shí)現(xiàn)方式，明確主數(shù)據(jù)的業(yè)務(wù)架構(gòu)；進(jìn)行主體流程的確定，數(shù)據(jù)流轉(zhuǎn)的確認(rèn)，狀態(tài)轉(zhuǎn)換的確認(rèn)。Demo定版之后，編寫(xiě)詳細(xì)設(shè)計(jì)文檔，包括詳細(xì)的實(shí)現(xiàn)邏輯，以及關(guān)鍵SQL。涉及到主數(shù)據(jù)的查詢一律提供標(biāo)準(zhǔn)方法，同時(shí)在詳設(shè)中說(shuō)明用到具體哪個(gè)方法。

3. 如果有超出功能列表范圍的，就和客戶討論優(yōu)先級(jí)，因?yàn)樯暇€日期是確定的，有些功能不重要可以后續(xù)再開(kāi)發(fā)。

   遇到的第二個(gè)問(wèn)題：團(tuán)隊(duì)協(xié)作的問(wèn)題。

    本項(xiàng)目的交付團(tuán)隊(duì)包括3個(gè)團(tuán)隊(duì)，一共15個(gè)人，如果加上短期駐場(chǎng)和已離場(chǎng)的人員，得有20多個(gè)人。項(xiàng)目組分為服務(wù)端團(tuán)隊(duì)、主數(shù)據(jù)團(tuán)隊(duì)、APP團(tuán)隊(duì)。各團(tuán)隊(duì)之間有協(xié)作關(guān)系。服務(wù)端團(tuán)隊(duì)不僅要開(kāi)發(fā)PC端的業(yè)務(wù)，還要給APP提供接口。

    團(tuán)隊(duì)來(lái)自于不同的部門，彼此之間的關(guān)系并不緊密。怎樣讓這只隊(duì)伍凝聚起來(lái)，完成目標(biāo)，是有些難度的工作。

    我們采取了分級(jí)管理的做法。主數(shù)據(jù)團(tuán)隊(duì)、APP團(tuán)隊(duì)各自有負(fù)責(zé)人，他們負(fù)責(zé)下面團(tuán)隊(duì)的開(kāi)發(fā)管理。主數(shù)據(jù)團(tuán)隊(duì)人比較少，就由項(xiàng)目經(jīng)理直接管理。UI也是PM直接管理。

    我們每周五召開(kāi)項(xiàng)目例會(huì)，項(xiàng)目總監(jiān)、PM、團(tuán)隊(duì)負(fù)責(zé)人、客戶方項(xiàng)目經(jīng)理一起參加，總結(jié)本周的工作，討論問(wèn)題，并確定下周的工作計(jì)劃。

    從實(shí)際結(jié)果來(lái)看，雖然一開(kāi)始經(jīng)歷了動(dòng)蕩期，但是后來(lái)還是到了成熟穩(wěn)定的階段，大家彼此合作愉快，進(jìn)展順利。

    敏捷開(kāi)發(fā)經(jīng)驗(yàn)分享

一、   tower上進(jìn)行工作任務(wù)的跟蹤。

Tower是一款多人協(xié)作工具，從界面設(shè)計(jì)到功能實(shí)現(xiàn)都遵循了“大道至簡(jiǎn)”的原則，主要面向20人以下的小團(tuán)隊(duì)。在Tower中，你可以在里面創(chuàng)建項(xiàng)目，并基于項(xiàng)目發(fā)起討論、創(chuàng)建并管理任務(wù)、上傳并共享相應(yīng)文件。Tower作為一個(gè)“輕量級(jí)”的工具，可以協(xié)助我們完成項(xiàng)目管理日常70%-80%的工作。

通過(guò)Tower，可以掌控你的項(xiàng)目。告別冗長(zhǎng)的會(huì)議、拖沓的進(jìn)度和繁復(fù)的郵件，快速、高效地完成任務(wù)。我們將project的計(jì)劃細(xì)分到人，在Tower上列舉每一個(gè)任務(wù)，明確責(zé)任人并跟蹤進(jìn)展情況。Tower還可以關(guān)聯(lián)微信端，這樣，我們?cè)谖⑿派弦部梢苑奖愕夭榭慈蝿?wù)，分派任務(wù)等。并且微信端的Tower還提供了代辦任務(wù)和任務(wù)過(guò)期提醒功能，非常方便好用。

Tower還可以查看項(xiàng)目進(jìn)度版，可以一覽項(xiàng)目的整體情況。

二、   敏捷開(kāi)發(fā)最少需要維護(hù)哪些文檔？

軟件或者系統(tǒng)產(chǎn)品終歸是人來(lái)維護(hù)的，業(yè)務(wù)知識(shí)和技能的傳遞就成為產(chǎn)品可持續(xù)發(fā)展的一個(gè)重要因素，這就需要有知識(shí)性的沉淀，需要有文檔的產(chǎn)出。

實(shí)際情況是大多數(shù)人都不喜歡編寫(xiě)文檔、也不太喜歡研讀文檔，因此太多的文檔只會(huì)消耗團(tuán)隊(duì)有限的時(shí)間，并不能帶來(lái)多大的好處；敏捷開(kāi)發(fā)照樣重視文檔的作用，也重視文檔的維護(hù)。

文檔宜少且精煉，需要根據(jù)實(shí)際情況確定需要編寫(xiě)哪些文檔，比如：

《產(chǎn)品需求規(guī)格說(shuō)明書(shū)》

也即PRD：定義產(chǎn)品應(yīng)該具有的功能、邊界描述等，它作為產(chǎn)品團(tuán)隊(duì)之間共同的討論基礎(chǔ)，并在設(shè)計(jì)和開(kāi)發(fā)過(guò)程中不斷的更新維護(hù)，并記錄所有的需求變更；

我們這個(gè)項(xiàng)目比較特殊，實(shí)際并沒(méi)有一個(gè)需求文檔存在，只有需求跟蹤矩陣。具體的需求主要是通過(guò)demo頁(yè)面體現(xiàn)。

《系統(tǒng)設(shè)計(jì)說(shuō)明書(shū)》

開(kāi)發(fā)人員編寫(xiě)的技術(shù)設(shè)計(jì)，包含數(shù)據(jù)庫(kù)E-R圖，架構(gòu)設(shè)計(jì)等：說(shuō)明產(chǎn)品如何實(shí)現(xiàn)，內(nèi)部之間是什么關(guān)系;

本項(xiàng)目由于沒(méi)有完整的需求文檔，所以設(shè)計(jì)文檔也充當(dāng)了需求文檔的作用。另外，我們還是堅(jiān)持如果有需求變更或設(shè)計(jì)變更，先改設(shè)計(jì)，然后落實(shí)開(kāi)發(fā)的過(guò)程控制。

雖然這一點(diǎn)不太像敏捷的做法，但是為了避免設(shè)計(jì)開(kāi)發(fā)的失控，我們還是要堅(jiān)持的。

《測(cè)試用例》

由測(cè)試人員編寫(xiě)：設(shè)計(jì)所有功能的測(cè)試用例，指導(dǎo)測(cè)試工作；

針對(duì)我們項(xiàng)目的特殊情況，交互系統(tǒng)繁多，接口交互復(fù)雜，所以針對(duì)集成測(cè)試，我們專門編寫(xiě)了集成測(cè)試用例，用以整體指導(dǎo)集成測(cè)試工作，避免遺漏。

三、   敏捷開(kāi)發(fā)是否需要系統(tǒng)設(shè)計(jì)？

一個(gè)完整的項(xiàng)目包括：需求、設(shè)計(jì)、開(kāi)發(fā)、測(cè)試、發(fā)布各個(gè)過(guò)程。

我們先做大力度的概要設(shè)計(jì)，然后根據(jù)迭代計(jì)劃，做每個(gè)迭代的詳細(xì)設(shè)計(jì)，然后在逐步實(shí)現(xiàn)的過(guò)程中逐漸深入展開(kāi)、細(xì)化。

傳統(tǒng)的一些設(shè)計(jì)方法比如結(jié)構(gòu)化設(shè)計(jì)、快速原型法都是可以融入敏捷開(kāi)發(fā)過(guò)程中加以使用的。

四、   敏捷開(kāi)發(fā)是否需要項(xiàng)目計(jì)劃？

敏捷開(kāi)發(fā)把整體拆分成許多個(gè)體，產(chǎn)品的開(kāi)發(fā)實(shí)現(xiàn)過(guò)程對(duì)產(chǎn)品的功能完整性、穩(wěn)定性、即時(shí)性等都有較高的要求。

我們需要有一份總體的項(xiàng)目計(jì)劃，先按照大的迭代分開(kāi)，然后逐步細(xì)化每一個(gè)迭代的內(nèi)容。每個(gè)迭代的推進(jìn)情況都會(huì)影響到后續(xù)迭代的任務(wù)安排。

每個(gè)迭代的計(jì)劃是一個(gè)短程計(jì)劃，根據(jù)未實(shí)現(xiàn)的功能情況、前一個(gè)迭代或版本的反饋和組織目標(biāo)制定開(kāi)發(fā)計(jì)劃；唯有這樣才能不斷的融入新的需求變更；

Project上的計(jì)劃顆粒度可以較粗，比如一周。但是細(xì)分的計(jì)劃必須體現(xiàn)到tower上。周五的時(shí)候，我們對(duì)總體計(jì)劃做回顧。

一方面，通過(guò)Tower的項(xiàng)目看板，可以知道當(dāng)前已布置的工作的完成情況。

另一方面，對(duì)于本期迭代的進(jìn)度情況或總體開(kāi)發(fā)計(jì)劃的進(jìn)度情況，我們可以在Project上進(jìn)行跟蹤查看。

當(dāng)然，如果說(shuō)項(xiàng)目比較小，或者運(yùn)維階段，沒(méi)有Project的計(jì)劃，有任務(wù)的計(jì)劃安排也是可以接受的。

五、   敏捷開(kāi)發(fā)為何提倡小版本？小版本有哪些優(yōu)勢(shì)？

小版本的目的就是分解復(fù)雜度、降低風(fēng)險(xiǎn)，改善團(tuán)隊(duì)士氣等；小版本有眾多優(yōu)勢(shì)：

1、總體風(fēng)險(xiǎn)比較少：小版本變化小，總是在上一個(gè)版本基礎(chǔ)上局部調(diào)整和增加，技術(shù)復(fù)雜度低；由于規(guī)劃的功能較少，工作量也易于估算，所以其總體風(fēng)險(xiǎn)比較少，常常能如期發(fā)布；

2、需求的接納能力強(qiáng)：由于小版本快速實(shí)現(xiàn)并發(fā)布測(cè)試，然后就進(jìn)入下一個(gè)版本的規(guī)劃實(shí)現(xiàn)周期，這樣新需求一旦提出就能快速進(jìn)入開(kāi)發(fā)視野，就能盡快實(shí)現(xiàn)；

3、測(cè)試和開(kāi)發(fā)高效協(xié)作：開(kāi)發(fā)和測(cè)試可以并行工作，當(dāng)開(kāi)發(fā)實(shí)現(xiàn)第一個(gè)版本時(shí)，測(cè)試設(shè)計(jì)測(cè)試方案和用例；發(fā)布第一個(gè)版本后，開(kāi)發(fā)就進(jìn)入下一個(gè)版本輪次，測(cè)試就應(yīng)用測(cè)試方案測(cè)試剛才發(fā)布的版本，提交Bug；開(kāi)發(fā)在下一個(gè)版本結(jié)束時(shí)修正所有上一輪發(fā)現(xiàn)的Bug，然后發(fā)布新版本，如此循環(huán)往復(fù)，開(kāi)發(fā)和測(cè)試實(shí)現(xiàn)高效協(xié)作；

六、   敏捷開(kāi)發(fā)的迭代周期大概多長(zhǎng)？

敏捷開(kāi)發(fā)的迭代周期沒(méi)有硬性的規(guī)定，結(jié)合項(xiàng)目里程碑、目標(biāo)、功能實(shí)現(xiàn)情況、產(chǎn)品穩(wěn)定性綜合決定，如果產(chǎn)品用戶活躍、功能實(shí)現(xiàn)難度小、維護(hù)復(fù)雜度低，建議以周為周期。

對(duì)于規(guī)模比較大、維護(hù)復(fù)雜度高的產(chǎn)品，考慮以2周-6周為周期發(fā)布較為合適；頻繁的發(fā)布會(huì)降低用戶的期望并提高用戶成本，也會(huì)給項(xiàng)目組帶來(lái)更高的成本。

在本項(xiàng)目中，產(chǎn)品發(fā)布前我們分成了3個(gè)迭代，每個(gè)迭代2-3周。在產(chǎn)品發(fā)布后，我們基本上采用了一周一個(gè)迭代的方式。迭代太頻繁會(huì)極大降低項(xiàng)目組的開(kāi)發(fā)效率，開(kāi)發(fā)、測(cè)試、發(fā)版交雜會(huì)讓項(xiàng)目組人員不知所措或者打亂原有的開(kāi)發(fā)計(jì)劃。

七、   敏捷開(kāi)發(fā)與重構(gòu)的關(guān)系

敏捷開(kāi)發(fā)以重構(gòu)為基礎(chǔ)，時(shí)時(shí)刻刻處于重構(gòu)過(guò)程中；

由于一開(kāi)始項(xiàng)目組在趕進(jìn)度，重構(gòu)的工作不多。在后續(xù)迭代開(kāi)發(fā)過(guò)程中，我們逐漸抽出時(shí)間對(duì)關(guān)鍵的代碼進(jìn)行了重構(gòu)。優(yōu)化了代碼結(jié)構(gòu)，進(jìn)行統(tǒng)一的業(yè)務(wù)收口。

盡早進(jìn)行重構(gòu)，可以節(jié)約后續(xù)的業(yè)務(wù)優(yōu)化和改進(jìn)的時(shí)間。

八、   敏捷開(kāi)發(fā)為何強(qiáng)調(diào)團(tuán)隊(duì)人員的參與、用戶的參與？

敏捷強(qiáng)調(diào)團(tuán)隊(duì)成員的高度參與就是要統(tǒng)一認(rèn)識(shí)，把團(tuán)隊(duì)的目標(biāo)變成每個(gè)人的工作目標(biāo)，使之為每個(gè)團(tuán)隊(duì)成員的認(rèn)同，形成高度的凝聚力，以達(dá)到群策群力、高效協(xié)作的效果。

良好的團(tuán)隊(duì)氛圍和協(xié)作關(guān)系可以促進(jìn)團(tuán)隊(duì)之間的溝通，并使消息有效傳達(dá)。

有客戶參與的溝通，一方面客戶對(duì)于整體進(jìn)度情況也更了解，能夠站在項(xiàng)目組的角度上考慮問(wèn)題，為整體進(jìn)度推進(jìn)出謀獻(xiàn)策或幫助內(nèi)部協(xié)調(diào)解決問(wèn)題；另一方面，也有利于項(xiàng)目組成員工作的責(zé)任感和緊迫感。

九、    敏捷開(kāi)發(fā)對(duì)于傳統(tǒng)的瀑布式開(kāi)發(fā)管理，有哪些借鑒意義？

一個(gè)項(xiàng)目是否可以采用敏捷，首先還是要看項(xiàng)目的立項(xiàng)基礎(chǔ)：合同及客戶需求。

如果是一個(gè)固定總價(jià)的合同，同時(shí)，時(shí)間、范圍不能調(diào)整，客戶的IT系統(tǒng)建設(shè)經(jīng)驗(yàn)不是很成熟，那么建議還是采用傳統(tǒng)的管理方式，嚴(yán)格進(jìn)行需求管理和變更控制。合同中約定的里程碑節(jié)點(diǎn)和交付物及驗(yàn)收標(biāo)準(zhǔn)，很大程度上約束了我們采用哪種管理方式。在現(xiàn)今中國(guó)的形勢(shì)下，也許ODC項(xiàng)目或者甲方自主開(kāi)發(fā)的項(xiàng)目，采用敏捷開(kāi)發(fā)方式才是最佳的選擇。

全套的敏捷管理方式也許不可用，引入一些敏捷的思想，采取一些敏捷的做法，是較好的選擇。

沒(méi)有一成不變的項(xiàng)目管理，只有人品、能力的錘煉，以及技巧、工具的巧妙應(yīng)用。

因時(shí)因地因人而變，最大程度上減小風(fēng)險(xiǎn)，保證成功交付，是項(xiàng)目管理永遠(yuǎn)的追求。