rel="file-list" href="file:///c:%5cdocume%7e1%5ccn1ww2g0%5clocals%7e1%5ctemp%5cmsohtml1%5c01%5cclip_filelist.xml">敏捷方法是相對於傳統軟體過程方法而言是一種輕量級的方法，可以簡化流程，提高效率。這是很多軟體組織青睞敏捷方法的原因，但是敏捷方法不適放之四海而皆準的真理，不是任何組織，任何軟體開發都可以使用xp（
extreme programming
，極限程式設計，敏捷方法的一種）的。敏捷方法有其適用的條件和適用場合，如果在沒有滿足使用條件的情況下使用敏捷方法，可能效果適得其反。因此必須分析組織的現狀和實施敏捷方法的可行性。逐步匯入敏捷方法，才有可能獲得成功。關於敏捷方法的詳細介紹，可以參看本人文章：
大家都知道敏捷方法可以簡化管理，提高效率，快速響應客戶需求，快速推出產品。敏捷方法如何在簡化流程，簡化管理的情況下提高工作效率和提高軟體質量呢？這是敏捷方法的誘人之處，答案就是敏捷方法的核心思想：以人為本。敏捷方法強調以人為本，人是軟體開發中的第一因素。這一方面體現了敏捷方法對人的重視，另一方面又對人提出了很高的要求，要求實行敏捷開發團隊成員具有高水平的程式設計技術，出色的溝通協調能力和積極主動地工作作風。比如敏捷方法取消了文件，那麼軟體組織就必須通過頻繁的，面對面的交流獲知軟體的設計情況。敏捷方法強調簡單設計，這就需要程式設計師在設計之初就要設計出簡單但是基本符合實際需求的設計模型，而不是字面上的單純的簡單設計，否則日後根本無法滿足要求。
xp中的
pair programming
是一種緊密合作的最小開發團隊模式，這也是需要
pair programming
的程式設計師能夠協調彼此關係，互相監督和檢查，互相促進，要知道，讓兩個不同個性的程式設計師親密無間的工作，這本身就是很大的挑戰。
code review例項
簡化流程後留下的大量管理空白需要程式設計師自己主動溝通，協調完成。試舉一例，比如說敏捷開發方法
xp中提到要建立
coding standard
。然後大家要遵守它。但是如何保證大家都遵守
coding standard
呢？傳統軟體過程採用定量測量的方法。首先規定乙個
code review
的評審活動，評審
code
是否符合
coding standard
。但是如何保證大家進行
code review
活動呢？為此還要制定
code review
的活動規範，可能還需要一些技術手段，比如你不進行
code review
活動，你的開發狀態就是「未評審」的狀態，
manager
就會找到你，採用管理手段或者經濟懲罰手段督促你完成
code review
活動；然後還有乙個
code review
的質量如何測量的問題，因此又會開發出來乙個
code review
的review
活動，還要制定
code review
評審結果的檢測規範，這個規範要規定怎樣的
review
的結果是合理的，怎樣的
code review
過程是有效的等等。乙個簡單的
code review
活動，就需要多個不同的相關活動去支援，監測，評估。為了進行這個
review
的review
活動，程式設計師又不得不進行
code review
過程的記錄從而方便以後的追查。為了方便以後的追查，這個記錄最好包括
review
的活動，參與者，
review
的問題，修改情況，再次
review
的情況和最後的結果等等內容。為了方便的統計，瀏覽各個
feature review
的資訊，最好把它放在乙個公共的伺服器上，為了方便統一，還要開發相應的工具軟體查詢和統計
review
的結果。。。。，為了
review 10
行**，你可能需要付出
5倍的時間或者更多。。。但是實際效果呢？我相信很多有實際經驗的程式設計師都知道，收效甚微，代價巨大。為什麼呢？答案就在於人，所有的活動都是人在參與。僅僅依靠嚴密的過程控制和所謂的審查標準是很難定量地評估**質量和評審過程的，或者是很難使用乙個量化的標準評估一種智力活動的質量，是每千行發現5個
bug作為標準呢？還是
10個？評審的時間是
1小時合適呢，還是
2小時？即使在相同的時間內，乙個認真負責的人的
review
效果和乙個漠不關心的
reviewer
的效果是不一樣的；乙個有經驗的程式設計師和乙個初學者
review
的結果也是不一樣的。但是標準肯定不是簡單的時間和數量。
通過流程，文件，各種記錄管理人的生產率也是不切實際的，目前軟體生產率的測量方法還很落後，測量的結果無非是一些簡單的時間和數量的量化指標，有專家論證目前的軟體質量，生產率測量方法是有缺陷的，是不符合實際的，所以並沒有太多實際的效果。
敏捷方法怎麼做呢？他同樣要解決這個問題呢，
1，如何保證大家都遵守它？如果保證大家很好的遵守它並取得了很好的效果？敏捷方法很簡單，取消繁瑣的過程，它可能也會有乙個
code review
過程，但是不需要很多的記錄，也不需要特定的形式。首先程式設計師要自覺地按照
code standard
去寫程式並盡最大努力寫好它。其次採用盡可能簡化的方式請
reviwer
幫助程式設計師發現更多的問題，而不是為了懲罰，或者為了統計測量等其他任何無關的目的和任何與
code review
無關的任何行動。
review
的過程集中於發現問題和解決問題，而不是記錄問題和懲罰措施，這樣就可以做到簡單高效。但是前提是所有人已經適應了敏捷開發的文化和具備了敏捷開發的能力。
敏捷的人
因此，建立敏捷過程必須有敏捷的人。敏捷的人才有敏捷的思想。就像一些實施物件導向設計的組織和個人，對物件導向的設計思想一知半解，似是而非，以為使用了
c++就可以進行物件導向設計了，殊不知，不了解物件導向思想，使用
c++也只能寫出非物件導向的
c++程式，頂多是有類的
c程式而已。
敏捷的人都長什麼模樣呢？首先有敏捷的程式設計技能，敏捷方法採用適應性方法進行設計，通過不斷重構去適應新的需求和逼近設計目標。這就需要程式設計師有高超的設計和程式設計能力，能夠高效率的開發和重構**，並能高效的通過測試。另外，還要有敏捷的思想和個人素質，敏捷的人必須一切從敏捷出發，打破常規，高效率的工作，因此，必須有改變的勇氣和信心，相信自己越變越好，程式越重構越好，而不是拒絕改變。另外，敏捷需要組織內部和組織之間要高效的協調，通訊，專案才能平穩向前推進，這就要求程式設計師要具有高度的自律，高度的責任感，非凡的溝通能力。否則，敏捷無從談起。
敏捷的人在**呢？不多，我估計現在的組織裡能有幾個就不錯了，這些人肯定是開發骨幹，因此，如果想使用敏捷方法，就必須按照開發骨幹的要求培養每乙個人，把大家都培養成敏捷的人，然後這個組織就可以採用敏捷方法了。當組織中的每個人都變成敏捷的人之後，這個組織就是敏捷的組織，這個組織擁有敏捷的文化，他們不懼怕改變，她們不懼怕改變任何東西，包括他們自己，他們願意為了敏捷作任何事情。這就是真正敏捷的組織。
敏捷組織
根據我多年的經驗和觀察，國內沒有幾個有資格可以實施敏捷方法的軟體組織。所以敏捷雖好，但是還要適合自己。當然我們也不必悲觀，我們可以自我改變，從自身做起，首先要把自己培養成敏捷的人，然後把組織改變成敏捷的組織，在此過程中，可以根據組織的實際情況，實際人員的水平，逐步匯入敏捷方法。這個過程可能會很慢，但是不能著急，必須逐步的，持續的改變，最後才能成功。
基於組織目標採用合適的敏捷方法
dan tousignant是cape 專案管理的高管教練及培訓師，他提出了乙個矩陣，幫助組織選擇他們自己的敏捷方法。他說企業需要真正地理解並擁抱他們即將開始的變革。u0026 xd n u0026 xd n dan提到在高層次上，組織需要概述他們的敏捷目標並明確期望，可以詢問如下問題 u0026 ...
敏捷開發 scrum採用的關鍵說法
scrummaster 不是傳統意義上的領導者或管理者，是通過指導，促進以及快速消除任何影響團隊交付交織的障礙來提高團隊對scrum的使用。scrummaster的職責就是確保堅守scrum的基本原則，並使團隊始終遵循他們共同承諾的這些實踐。例如在sprint交付忙的時候，可能會忽略修復bug。這個...
我們的專案採用Scrum敏捷失敗了
首先告訴大家乙個好訊息，我們的專案採用敏捷scrum進行x專案開發宣告失敗，中途不得不轉向傳統過程。為什麼是好訊息？我認為 失敗是成功之母。沒有失敗就發現不到所隱含的實際問題，將實際問題解決才是成功的必經之路。如果第一次成功反而不正常，所以這次的失敗是個好訊息。下面我將結合敏捷scrum在該專案中應...