關(guān)于敏捷方法論的文章已經(jīng)很多了。其中,相當一部分文章講述了敏捷方法技術(shù)方面的問題,比如測試驅(qū)動開發(fā)和持續(xù)集成。同樣,還有相當一部分文章討論了敏捷 方法論的應用問題,例如發(fā)布計劃,跟蹤生產(chǎn)率,如何使用度量數(shù)據(jù)對過程“調(diào)優(yōu)”,甚至讓公司里的業(yè)務人員確信需要采納一種特別的方法。讀過這些有關(guān)敏捷方 法的文章后,很容易讓人產(chǎn)生一種感覺,即通過購買一套工具并遵從一系列看上去很簡單的實踐,就算采納了像極限編程和Scrum這樣的敏捷方法。然而,現(xiàn)實 世界的經(jīng)驗表明,成功地采納敏捷要比那復雜得多。它涉及到如何培養(yǎng)一些正確的做事態(tài)度來建立信任,鼓勵交流與協(xié)作,最終讓人們更加適應,并產(chǎn)生高效。
敏捷方法常常被描述為以人為中心,而不是強調(diào)技術(shù),并有充分的理由來說明這一點。然而,雖然敏捷宣言強 調(diào)了“個體和交互勝于過程和工具”的重要性,但它并沒有清晰地闡明如何處理這個重要的社會性維度。在強調(diào)技術(shù)的業(yè)務中,這些都太簡單,無法概觀個人態(tài)度在 項目團隊中的強大影響力。要想知道哪種態(tài)度可以促進(或阻撓)敏捷的采納,我們要問一個問題:“在成功的開發(fā)者和管理者之中,我們能發(fā)現(xiàn)那些與眾不同的行 為嗎?”,更重要的問題是 “這些行為是由什么態(tài)度驅(qū)動的呢?”
成長中的敏捷開發(fā)者
很多開發(fā)者習慣于獨立工作,花費大部分的時間來閱讀規(guī)范,并完成設計和編碼。在前敏捷環(huán)境(pre-agile environment)中,一些開發(fā)者甚至戴耳機聽音樂,不聽來自辦公室的“噪音”。采納極限編程的開發(fā)者發(fā)現(xiàn)其自身已經(jīng)融入到更加社會化的環(huán)境了,在 這種環(huán)境下,成功依賴于與同伴和客戶更緊密的協(xié)作。另外,經(jīng)典的前敏捷開發(fā)是個體獨自“擁有”那些設計和編碼。在敏捷環(huán)境下,工作任務由團隊共同決定: 沒有誰能獨自擁有某段代碼。這種態(tài)度的調(diào)整可能特別具有挑戰(zhàn)性。
剛接觸敏捷開發(fā)的人可能習慣于在那種將自身劃分成子系統(tǒng)再進行開發(fā)的項目。他們習慣于依據(jù)各子系統(tǒng)之間互聯(lián)的高層次規(guī)范,獨自負責某個子系統(tǒng)的設計。剛接 觸集體代碼所有制的開發(fā)者很容易被他們不得不掌握的代碼的數(shù)量嚇倒。與此同時,很少的技術(shù)文檔(甚至沒有技術(shù)文檔)和快速變化的代碼基線(包括那些熟悉的 類名和方法名都有可能在短時間內(nèi)發(fā)生變化)很可能加劇這種情況。但是,敏捷方法論(特別是極限編程)要求編程人員有很強的編碼能力。通過對缺乏經(jīng)驗和富有 經(jīng)驗的敏捷開發(fā)人員的觀察,很容易就可以看出不僅僅是技能問題,態(tài)度也是非常關(guān)鍵的。
表一在代碼級別上列出了一些傳統(tǒng)團隊與敏捷團隊的不同。富有經(jīng)驗的敏捷開發(fā)者有不同的編碼方法。他們傾向于靈活編碼,而不是等到整個設計都很完善了再進行 開發(fā)。另外,他們還傾向于把編碼視為學習和探索的機會。例如,遇到一個問題時,他們總是通過編寫一個小的概念驗證模型或“技術(shù)原型(spike solution)”使問題具體化,而不是構(gòu)建一個復雜的模型或者通過自然語言描述來說明各種行為。同樣,敏捷開發(fā)者更愿意去閱讀第三方的代碼。有時候, 他們想做一些力所能及的改進;有時候他們這么做只是為了學習一種新的設計方法。最后,通過盡可能地讓類、方法以及與潛在的方法調(diào)用鏈等相互獨立,以便僅了 解局部代碼就足夠了,這樣就不用去花很多時間去研究整個子系統(tǒng)或應用。所有這些差異能更好地使開發(fā)者發(fā)現(xiàn)并處理編碼中出現(xiàn)的問題,而不是僅僅使用高超的編 碼技能完成任務而已。
此文章共有5頁 1 2 3 4 5 下一頁
文章來源:中國項目管理資源網(wǎng)
|