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

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

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

下面就具體講講我們是怎么完成這個項目的。

  遇到的第一個問題：需求的問題。

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

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

    對策：

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

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

3. 如果有超出功能列表范圍的，就和客戶討論優(yōu)先級，因為上線日期是確定的，有些功能不重要可以后續(xù)再開發(fā)。

   遇到的第二個問題：團隊協(xié)作的問題。

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

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

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

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

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

    敏捷開發(fā)經(jīng)驗分享

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

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

通過Tower，可以掌控你的項目。告別冗長的會議、拖沓的進度和繁復(fù)的郵件，快速、高效地完成任務(wù)。我們將project的計劃細分到人，在Tower上列舉每一個任務(wù)，明確責(zé)任人并跟蹤進展情況。Tower還可以關(guān)聯(lián)微信端，這樣，我們在微信上也可以方便地查看任務(wù)，分派任務(wù)等。并且微信端的Tower還提供了代辦任務(wù)和任務(wù)過期提醒功能，非常方便好用。

Tower還可以查看項目進度版，可以一覽項目的整體情況。

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

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

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

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

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

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

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

《系統(tǒng)設(shè)計說明書》

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

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

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

《測試用例》

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

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

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

一個完整的項目包括：需求、設(shè)計、開發(fā)、測試、發(fā)布各個過程。

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

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

四、   敏捷開發(fā)是否需要項目計劃？

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

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

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

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

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

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

當(dāng)然，如果說項目比較小，或者運維階段，沒有Project的計劃，有任務(wù)的計劃安排也是可以接受的。

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

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

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

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

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

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

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

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

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

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

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

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

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

八、   敏捷開發(fā)為何強調(diào)團隊人員的參與、用戶的參與？

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

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

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

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

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

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

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

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

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