直到實(shí)施了任務(wù)執(zhí)行管理工具DevTrack，Smart先生才逐漸認(rèn)識(shí)到由DevSpec引導(dǎo)的“功能驅(qū)動(dòng)開發(fā)”是如何實(shí)現(xiàn)的。DevPlan中的迭代計(jì)劃、DevTest中的測試任務(wù)和DevTrack中的開發(fā)任務(wù)，都是圍繞DevSpec中的功能展開的。這不僅使整個(gè)敏捷過程都嚴(yán)格圍繞最終產(chǎn)品進(jìn)行，而且其中的可追溯性和可核查性，也正是敏捷開發(fā)思想的有益補(bǔ)充。
現(xiàn)在，當(dāng)項(xiàng)目成員在會(huì)議室和用戶討論得熱火朝天的時(shí)候，Smart先生可以悠閑地在電腦前喝咖啡了，他知道整個(gè)過程都是可以控制的，需求和設(shè)計(jì)變化再多再大，經(jīng)歷再多的迭代和小型發(fā)布，只要所有功能都按照計(jì)劃被開發(fā)和測試，項(xiàng)目還是會(huì)如期完成。
敏捷團(tuán)隊(duì)的成功案例總結(jié)
毫無疑問，DevAgile團(tuán)隊(duì)最終用敏捷開發(fā)方式取得了項(xiàng)目成功。讓我們再來總結(jié)一下，他們是如何具體做到的呢？首先，需求被搜集和整理，產(chǎn)品功能和簡單設(shè)計(jì)產(chǎn)生，將這些結(jié)構(gòu)框架和相關(guān)文檔存入DevSpec之后，開始制定迭代計(jì)劃，并定義模塊接口。緊跟著，針對(duì)接口做出測試代碼。這些知識(shí)文檔全由DevSpec來管理，因此DevSpec中形成了由需求、功能和知識(shí)文檔組成的“概念產(chǎn)品”。
最后，功能點(diǎn)被導(dǎo)入DevTest而產(chǎn)生一個(gè)或多個(gè)測試任務(wù)，每一個(gè)測試任務(wù)都能按照DevTrack中定義的工作流（圖2）進(jìn)行。
圖2的工作流被啟動(dòng)之后，編碼人員在第一狀態(tài)負(fù)責(zé)編寫代碼、重構(gòu)和白盒測試。項(xiàng)目經(jīng)理為了實(shí)現(xiàn)配對(duì)檢入，把第二狀態(tài)設(shè)為需有A和B兩人一起檢入的“配對(duì)檢入”。每一個(gè)狀態(tài)都有明確的負(fù)責(zé)人。A可以是第一狀態(tài)負(fù)責(zé)人，而與A配對(duì)的人員則可以是跟A 所做的任務(wù)有關(guān)的人員。第三狀態(tài)負(fù)責(zé)人可以是測試人員，在單元測試成功后便完成了整個(gè)流程。反之，則重新回到第一狀態(tài)。
以上的案例中，對(duì)所提到的四個(gè)敏捷特點(diǎn)都有所注解。當(dāng)然，這是一個(gè)可行的方案，而絕非唯一。
另外，面對(duì)面溝通也是個(gè)很好的敏捷操作，但是實(shí)際上卻不易實(shí)現(xiàn)�？蛻艋蚴熘虡I(yè)邏輯的同事通常是無法長時(shí)間和開發(fā)設(shè)計(jì)人員在一起工作的。若一定要面對(duì)面，很可能會(huì)以高昂的費(fèi)用為代價(jià)。更實(shí)際的方式是通過一定的溝通平臺(tái)（如一些即時(shí)語音或視頻通訊工具）來達(dá)到類似面對(duì)面的溝通。
無論采用何種方式，溝通后的結(jié)果都要能妥善地記錄下來。知識(shí)的分類和歷史的記錄會(huì)使清晰度達(dá)到最高，進(jìn)而使后來的一切活動(dòng)，包括編碼、測試、分析等，都變得容易。
除了以上所提到的工具，軟件配置管理、單元測試、軟件的基礎(chǔ)架構(gòu)管理等工具，都是決定敏捷開發(fā)項(xiàng)目是否能夠取得成功的關(guān)鍵因素。
總的來說，工具的使用要能幫助敏捷團(tuán)隊(duì)達(dá)到下列幾項(xiàng)目的:能針對(duì)迭代進(jìn)行靈活的計(jì)劃，能管理需求變更，能始終體現(xiàn)最終產(chǎn)品的框架，能將關(guān)鍵過程既用流程固化又隨時(shí)可調(diào)整，能對(duì)需求和供能點(diǎn)排列優(yōu)先級(jí)，能使各方溝通更加便利等等。只有這樣，才能使敏捷方法真正受益于工具，而不是受工具所累。
此文章共有5頁 上一頁 1 2 3 4 5 下一頁
文章來源：中國項(xiàng)目管理資源網(wǎng)
|
Leadge.com首頁 > 知識(shí)庫 
