現(xiàn)在的商業(yè)環(huán)境復(fù)雜多變，從IT系統(tǒng)項目管理的角度來說，存在著多種模式的項目管理。敏捷開發(fā)的概念已經(jīng)不新鮮，但是在實(shí)踐中還是沒有得到廣泛應(yīng)用。
在我們最近做的一個項目中，就引入了敏捷開發(fā)的一些思想。本文以這個項目為例，介紹了一些敏捷開發(fā)項目管理的實(shí)踐經(jīng)驗(yàn)，希望為大家提供一些思考和借鑒。
項目要求，不到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頁面進(jìn)行數(shù)據(jù)庫設(shè)計和系統(tǒng)詳細(xì)設(shè)計。
由于系統(tǒng)整體的組織架構(gòu)，以及數(shù)據(jù)權(quán)限的問題，導(dǎo)致項目的組織權(quán)限體系比較復(fù)雜。另外，由于不熟悉業(yè)務(wù)，程序員在理解上有困難，接收起來比較慢。
對策：
強(qiáng)化業(yè)務(wù)培訓(xùn)和主數(shù)據(jù)結(jié)構(gòu)關(guān)系培訓(xùn)。這個的實(shí)現(xiàn)效果不是很好，畢竟主數(shù)據(jù)的邏輯關(guān)系比較復(fù)雜。
沒有需求文檔就用設(shè)計文檔代替。在demo制作的同時，確立主數(shù)據(jù)設(shè)計思想和實(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è)計文檔，包括詳細(xì)的實(shí)現(xiàn)邏輯，以及關(guān)鍵SQL。涉及到主數(shù)據(jù)的查詢一律提供標(biāo)準(zhǔn)方法，同時在詳設(shè)中說明用到具體哪個方法。
如果有超出功能列表范圍的，就和客戶討論優(yōu)先級，因?yàn)樯暇€日期是確定的，有些功能不重要可以后續(xù)再開發(fā)。
本項目的交付團(tuán)隊包括3個團(tuán)隊，一共15個人，如果加上短期駐場和已離場的人員，得有20多個人。項目組分為服務(wù)端團(tuán)隊、主數(shù)據(jù)團(tuán)隊、APP團(tuán)隊。各團(tuán)隊之間有協(xié)作關(guān)系。服務(wù)端團(tuán)隊不僅要開發(fā)PC端的業(yè)務(wù)，還要給APP提供接口。
團(tuán)隊來自于不同的部門，彼此之間的關(guān)系并不緊密。怎樣讓這只隊伍凝聚起來，完成目標(biāo)，是有些難度的工作。
我們采取了分級管理的做法。主數(shù)據(jù)團(tuán)隊、APP團(tuán)隊各自有負(fù)責(zé)人，他們負(fù)責(zé)下面團(tuán)隊的開發(fā)管理。主數(shù)據(jù)團(tuán)隊人比較少，就由項目經(jīng)理直接管理。UI也是PM直接管理。
我們每周五召開項目例會，項目總監(jiān)、PM、團(tuán)隊負(fù)責(zé)人、客戶方項目經(jīng)理一起參加，總結(jié)本周的工作，討論問題，并確定下周的工作計劃。
從實(shí)際結(jié)果來看，雖然一開始經(jīng)歷了動蕩期，但是后來還是到了成熟穩(wěn)定的階段，大家彼此合作愉快，進(jìn)展順利。
Tower是一款多人協(xié)作工具，從界面設(shè)計到功能實(shí)現(xiàn)都遵循了“大道至簡”的原則，主要面向20人以下的小團(tuán)隊。在Tower中，你可以在里面創(chuàng)建項目，并基于項目發(fā)起討論、創(chuàng)建并管理任務(wù)、上傳并共享相應(yīng)文件。Tower作為一個“輕量級”的工具，可以協(xié)助我們完成項目管理日常70%-80%的工作。
通過Tower，可以掌控你的項目。告別冗長的會議、拖沓的進(jìn)度和繁復(fù)的郵件，快速、高效地完成任務(wù)。我們將project的計劃細(xì)分到人，在Tower上列舉每一個任務(wù)，明確責(zé)任人并跟蹤進(jìn)展情況。Tower還可以關(guān)聯(lián)微信端，這樣，我們在微信上也可以方便地查看任務(wù)，分派任務(wù)等。并且微信端的Tower還提供了代辦任務(wù)和任務(wù)過期提醒功能，非常方便好用。
Tower還可以查看項目進(jìn)度版，可以一覽項目的整體情況。
軟件或者系統(tǒng)產(chǎn)品終歸是人來維護(hù)的，業(yè)務(wù)知識和技能的傳遞就成為產(chǎn)品可持續(xù)發(fā)展的一個重要因素，這就需要有知識性的沉淀，需要有文檔的產(chǎn)出。
實(shí)際情況是大多數(shù)人都不喜歡編寫文檔、也不太喜歡研讀文檔，因此太多的文檔只會消耗團(tuán)隊有限的時間，并不能帶來多大的好處；敏捷開發(fā)照樣重視文檔的作用，也重視文檔的維護(hù)。
文檔宜少且精煉，需要根據(jù)實(shí)際情況確定需要編寫哪些文檔，比如：
《產(chǎn)品需求規(guī)格說明書》
也即PRD：定義產(chǎn)品應(yīng)該具有的功能、邊界描述等，它作為產(chǎn)品團(tuán)隊之間共同的討論基礎(chǔ)，并在設(shè)計和開發(fā)過程中不斷的更新維護(hù)，并記錄所有的需求變更；
我們這個項目比較特殊，實(shí)際并沒有一個需求文檔存在，只有需求跟蹤矩陣。具體的需求主要是通過demo頁面體現(xiàn)。
《系統(tǒng)設(shè)計說明書》
開發(fā)人員編寫的技術(shù)設(shè)計，包含數(shù)據(jù)庫E-R圖，架構(gòu)設(shè)計等：說明產(chǎn)品如何實(shí)現(xiàn)，內(nèi)部之間是什么關(guān)系;
本項目由于沒有完整的需求文檔，所以設(shè)計文檔也充當(dāng)了需求文檔的作用。另外，我們還是堅持如果有需求變更或設(shè)計變更，先改設(shè)計，然后落實(shí)開發(fā)的過程控制。
雖然這一點(diǎn)不太像敏捷的做法，但是為了避免設(shè)計開發(fā)的失控，我們還是要堅持的。
《測試用例》
由測試人員編寫：設(shè)計所有功能的測試用例，指導(dǎo)測試工作；
針對我們項目的特殊情況，交互系統(tǒng)繁多，接口交互復(fù)雜，所以針對集成測試，我們專門編寫了集成測試用例，用以整體指導(dǎo)集成測試工作，避免遺漏。
一個完整的項目包括：需求、設(shè)計、開發(fā)、測試、發(fā)布各個過程。
我們先做大力度的概要設(shè)計，然后根據(jù)迭代計劃，做每個迭代的詳細(xì)設(shè)計，然后在逐步實(shí)現(xiàn)的過程中逐漸深入展開、細(xì)化。
傳統(tǒng)的一些設(shè)計方法比如結(jié)構(gòu)化設(shè)計、快速原型法都是可以融入敏捷開發(fā)過程中加以使用的。
敏捷開發(fā)把整體拆分成許多個體，產(chǎn)品的開發(fā)實(shí)現(xiàn)過程對產(chǎn)品的功能完整性、穩(wěn)定性、即時性等都有較高的要求。
我們需要有一份總體的項目計劃，先按照大的迭代分開，然后逐步細(xì)化每一個迭代的內(nèi)容。每個迭代的推進(jìn)情況都會影響到后續(xù)迭代的任務(wù)安排。
每個迭代的計劃是一個短程計劃，根據(jù)未實(shí)現(xiàn)的功能情況、前一個迭代或版本的反饋和組織目標(biāo)制定開發(fā)計劃；唯有這樣才能不斷的融入新的需求變更；
Project上的計劃顆粒度可以較粗，比如一周。但是細(xì)分的計劃必須體現(xiàn)到tower上。周五的時候，我們對總體計劃做回顧。
一方面，通過Tower的項目看板，可以知道當(dāng)前已布置的工作的完成情況。
另一方面，對于本期迭代的進(jìn)度情況或總體開發(fā)計劃的進(jìn)度情況，我們可以在Project上進(jìn)行跟蹤查看。
當(dāng)然，如果說項目比較小，或者運(yùn)維階段，沒有Project的計劃，有任務(wù)的計劃安排也是可以接受的。
小版本的目的就是分解復(fù)雜度、降低風(fēng)險，改善團(tuán)隊士氣等；小版本有眾多優(yōu)勢：
1、總體風(fēng)險比較少：小版本變化小，總是在上一個版本基礎(chǔ)上局部調(diào)整和增加，技術(shù)復(fù)雜度低；由于規(guī)劃的功能較少，工作量也易于估算，所以其總體風(fēng)險比較少，常常能如期發(fā)布；
2、需求的接納能力強(qiáng)：由于小版本快速實(shí)現(xiàn)并發(fā)布測試，然后就進(jìn)入下一個版本的規(guī)劃實(shí)現(xiàn)周期，這樣新需求一旦提出就能快速進(jìn)入開發(fā)視野，就能盡快實(shí)現(xiàn)；
3、測試和開發(fā)高效協(xié)作：開發(fā)和測試可以并行工作，當(dāng)開發(fā)實(shí)現(xiàn)第一個版本時，測試設(shè)計測試方案和用例；發(fā)布第一個版本后，開發(fā)就進(jìn)入下一個版本輪次，測試就應(yīng)用測試方案測試剛才發(fā)布的版本，提交Bug；開發(fā)在下一個版本結(jié)束時修正所有上一輪發(fā)現(xiàn)的Bug，然后發(fā)布新版本，如此循環(huán)往復(fù)，開發(fā)和測試實(shí)現(xiàn)高效協(xié)作；
敏捷開發(fā)的迭代周期沒有硬性的規(guī)定，結(jié)合項目里程碑、目標(biāo)、功能實(shí)現(xiàn)情況、產(chǎn)品穩(wěn)定性綜合決定，如果產(chǎn)品用戶活躍、功能實(shí)現(xiàn)難度小、維護(hù)復(fù)雜度低，建議以周為周期。
對于規(guī)模比較大、維護(hù)復(fù)雜度高的產(chǎn)品，考慮以2周-6周為周期發(fā)布較為合適；頻繁的發(fā)布會降低用戶的期望并提高用戶成本，也會給項目組帶來更高的成本。
在本項目中，產(chǎn)品發(fā)布前我們分成了3個迭代，每個迭代2-3周。在產(chǎn)品發(fā)布后，我們基本上采用了一周一個迭代的方式。迭代太頻繁會極大降低項目組的開發(fā)效率，開發(fā)、測試、發(fā)版交雜會讓項目組人員不知所措或者打亂原有的開發(fā)計劃。
敏捷開發(fā)以重構(gòu)為基礎(chǔ)，時時刻刻處于重構(gòu)過程中；
由于一開始項目組在趕進(jìn)度，重構(gòu)的工作不多。在后續(xù)迭代開發(fā)過程中，我們逐漸抽出時間對關(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)的時間。
敏捷強(qiáng)調(diào)團(tuán)隊成員的高度參與就是要統(tǒng)一認(rèn)識，把團(tuán)隊的目標(biāo)變成每個人的工作目標(biāo)，使之為每個團(tuán)隊成員的認(rèn)同，形成高度的凝聚力，以達(dá)到群策群力、高效協(xié)作的效果。
良好的團(tuán)隊氛圍和協(xié)作關(guān)系可以促進(jìn)團(tuán)隊之間的溝通，并使消息有效傳達(dá)。
有客戶參與的溝通，一方面客戶對于整體進(jìn)度情況也更了解，能夠站在項目組的角度上考慮問題，為整體進(jìn)度推進(jìn)出謀獻(xiàn)策或幫助內(nèi)部協(xié)調(diào)解決問題；另一方面，也有利于項目組成員工作的責(zé)任感和緊迫感。
一個項目是否可以采用敏捷，首先還是要看項目的立項基礎(chǔ)：合同及客戶需求。
如果是一個固定總價的合同，同時，時間、范圍不能調(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)今中國的形勢下，也許ODC項目或者甲方自主開發(fā)的項目，采用敏捷開發(fā)方式才是最佳的選擇。
全套的敏捷管理方式也許不可用，引入一些敏捷的思想，采取一些敏捷的做法，是較好的選擇。
沒有一成不變的項目管理，只有人品、能力的錘煉，以及技巧、工具的巧妙應(yīng)用。
因時因地因人而變，最大程度上減小風(fēng)險，保證成功交付，是項目管理永遠(yuǎn)的追求。
來源：網(wǎng)絡(luò)
