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