現(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定版之后，編寫詳細(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ù)人都不喜歡編寫文檔,、也不太喜歡研讀文檔，因此太多的文檔只會(huì)消耗團(tuán)隊(duì)有限的時(shí)間,，并不能帶來(lái)多大的好處,；敏捷開(kāi)發(fā)照樣重視文檔的作用，也重視文檔的維護(hù),。

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

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

也即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ō)明書》

開(kāi)發(fā)人員編寫的技術(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è)試人員編寫：設(shè)計(jì)所有功能的測(cè)試用例,，指導(dǎo)測(cè)試工作,；

針對(duì)我們項(xiàng)目的特殊情況，交互系統(tǒng)繁多,，接口交互復(fù)雜,，所以針對(duì)集成測(cè)試，我們專門編寫了集成測(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)的追求,。