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