敏捷開發(fā)之12條敏捷原則

1、敏捷開發(fā)之12條敏捷原則.txt愛空空情空空，自己流浪在街中；人空空錢空空，單身苦命在打工；事空空業(yè)空空，想來想去就發(fā)瘋；碗空空盆空空，生活所迫不輕松?？傊?，四大皆空！敏捷開發(fā)之12條敏捷原則敏捷開發(fā)中有12條原則，它們是敏捷實踐區(qū)別于重型過程的特征所在。在AgileSoftwareDevelopmentPrinciples,Patterns,andPractices（中文書名：敏捷軟件開發(fā)原則、模式與實踐）中對這12條原則分別進行了闡述，這里我就不重復解釋書本的內(nèi)容了，將從我個人的理解去講解這些原則，希望大家多多補充獨到見解。我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。

2、規(guī)劃迭代故事時必須按照優(yōu)先級安排，為客戶先提供最有價值的功能。通過頻繁迭代能與客戶形成早期的良好合作，及時反饋提高產(chǎn)品質(zhì)量。敏捷小組關注完成和交付具有用戶價值的功能，而不是孤立的任務。以前我們都用需求規(guī)格說明書或者用例來編寫詳細的需求，敏捷使用用戶故事來羅列需求。用戶故事是一種表示需求的輕量級技術，它沒有固定的形式和強制性的語法。但是有一些固定的形式可以用來參考還是比較有益的。敏捷估算中使用了這個模板：“作為【用戶的類型】，我希望可以【能力】以便【業(yè)務價值】“。使用基于用戶故事的需求分析方法時，仍可能需要原型和編寫文檔，只是工作重點更多的轉(zhuǎn)移到了口頭交流。即使到了開發(fā)的后期，也歡迎改變需求。敏

3、捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。敏捷過程參與者不怕變化，他們認為改變需求是好事情，因為這些改變意味著我們更了解市場需求。經(jīng)常性的交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。迭代是受實踐框限制的，意味著即使放棄一些功能也必須按時結(jié)束迭代。只要我們可以保證交付的軟件可以很好的工作，那么交付時間越短，我們和客戶協(xié)作就越緊密，對產(chǎn)品質(zhì)量就更有益。雖然我們多次迭代，但并不是每次迭代的結(jié)果都需要交付給用戶，敏捷開發(fā)的目標是讓他們可以交付。這意味著開發(fā)小組在每次迭代中都會增加一些功能，增加的每個功能都是經(jīng)過編碼、測試，達到了可發(fā)布的質(zhì)量標準的。另外敏捷開發(fā)項目中對開發(fā)階段沒

4、有什么重要的分割，沒有先期的需求階段，然后是分析階段，架構(gòu)設計階段，編碼測試階段等，在項目真正開始后，每次迭代中都會同時進行所有的上述階段工作。在整個項目開發(fā)期間，業(yè)務人員和開發(fā)人員必須天天都在一起工作。軟件項目不會依照之前設定的計劃原路執(zhí)行，中間對業(yè)務的理解、軟件的解決方案肯定會存在偏差，所以客戶、需求人員、開發(fā)人員以及涉眾之間必須進行有意義的、頻繁的交互，這樣就可以在早期及時的發(fā)現(xiàn)并解決問題。圍繞被激勵起來的人個來構(gòu)建項目。給他們提供所需要的環(huán)境和支持，并且信任他們能夠完成工作。業(yè)務和技術是引起不確定的二個主要方面，人是第三個方面。而業(yè)務和技術又必須由人來執(zhí)行，所以能夠激勵人來解決這些問題

5、是解決不確定性的關鍵。只要個人的目標和團隊的目標一致，我們就需要鼓舞起每個人的積極性，以個人為中心構(gòu)建項目，提供所需的環(huán)境、支持與信任。在團隊內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談。在十幾或者二十幾個人組成的大團隊中，文檔是一種比較合適的傳遞知識和交流的途徑。而敏捷團隊一般不會很多人（大團隊實施敏捷時也會分成多個小的敏捷團隊），所以大量的文檔交流其實并不是很經(jīng)濟的做法。此時面對面的交談反而更快速有效。工作的軟件是首要進度度量標準。一般的工作都比較容易衡量任務進展，比如讓你去搬運1噸的石頭，我只要去稱一下你已經(jīng)搬運的石頭重量就知道你完成多少了。而對于軟件來說，在軟件沒有編

6、碼、測試完成之前，我們都不能因為代碼編寫了多少行，測試用例跑了多少個就去度量這個功能是否完成了。衡量這個功能是否完成的首要標準就是這個功能可以工作了，對用戶來說已經(jīng)可以應用了。敏捷過程提可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應該能夠保持一個長期的、恒定的開發(fā)速度。很多人都認為軟件開發(fā)中加班是很正常的，不加班反而不正常，我對此有點不理解，這個可能是國情所致吧。敏捷過程希望能夠可持續(xù)的進行開發(fā)，開發(fā)速度不會隨著迭代的任務不同而不同，不欣賞所謂的拼一拼也能完成的態(tài)度，開發(fā)工作不應該是突擊行為。我們不能指望說突擊這個項目后就可以輕松了，因為完成一個項目后會接踵而來下一個項目，而只要還是拼拼的態(tài)度，下一

7、個項目依舊會讓你的組員再次突擊。這時不知道有人會不會說，那我們就一直加班，也是“持續(xù)的開發(fā)速度”啊，這時可要注意了，持續(xù)加班智慧導致人疲勞、厭倦，保持長期恒定的速度也只是一種理想而已。不斷地關注優(yōu)秀的技能和好的設計會增強敏捷能力。敏捷過程有很多好的技術實踐可以加強產(chǎn)品敏捷能力，很多原則、模式和實踐也可以增強敏捷開發(fā)能力。敏捷軟件開發(fā)原則、模式與實踐一書中介紹了很多設計，感興趣的可以去仔細看看。簡單使未完成的工作最大化的藝術是根本的。我們不可能預期后面需求會如何變化，所以不可能一開始就構(gòu)建一個完美的架構(gòu)來適應以后的所有變化。敏捷團隊不會去構(gòu)建明天的軟件，而把注意力放在如何通過最簡單的方法完成現(xiàn)在

8、需要解決的問題。這時有人會說，我已經(jīng)預計到了肯定存在哪些需求擴展點，我們在一開始是否需要考慮呢？這時團隊需要根據(jù)自己的理解去決定是否考慮，如果深信在明天發(fā)生了這個問題也可以輕易處理的話，那么就最好先不考慮。最好的構(gòu)架、需求和設計出自與自組織的團隊。敏捷中有很多種實踐，大家都知道，迭代式開發(fā)是主要的實踐方法，而自組織團隊也是主要的實踐之一。在自組織團隊中，管理者不再發(fā)號施令，而是讓團隊自身尋找最佳的工作方式來完成工作。要形成一個自組織團隊其實比較難。CSDN采訪MishkinBerteig中說到自組織團隊的第一個要素就是必須有一個團隊，而不僅僅是一群人。一群人是一幫在一起工作的人，他們彼此之間并

9、沒有太多的溝通，他們也并不視彼此為一體。項目一開始，我們就會組建“團隊”，但很多時候由構(gòu)架師、需求人員、開發(fā)人員和測試人員組成的是一群人而已。他還認為，團隊的形成必須經(jīng)歷幾個時期。在經(jīng)歷了初期的磨合后，成員才會開始對團隊共同的工作理念與文化形成一個基本的認識和理解。團隊內(nèi)會逐漸形成規(guī)矩，而且這些規(guī)矩是不言而喻的。比如，每個人都知道上午九點來上班，都會主動詢問別人是否需要幫助，也都會去主動和別人探討問題。如果團隊成員之間能夠達成這樣的默契，那么這個團隊將成為一個真正高效的工作團隊。在這樣的團隊中，成員之間相互理解，工作效率非常高。在自組織團隊中，團隊成員不需要遵從別人的詳細指令。他們需要更高層次

10、的指導，這種指導更像是一個目標，一個致力于開發(fā)出更好的軟件的目標?？傊?，自組織團隊是一個自動自發(fā)、有著共同目標和工作文化的團隊，這樣的團隊總是在向它的組織做出承諾。但是，實現(xiàn)這些承諾對于自組織團隊來說非常重要。否則，一旦出現(xiàn)問題，團隊成員之間就會出現(xiàn)信任危機。雖然敏捷開發(fā)小組是以小組為整體來工作的，但是還是有必要指明一些承擔一定任務的角色。第一個角色是產(chǎn)品所有者(ProductOwner)o產(chǎn)品所有者的主要職責包括：確認小組所有成員都在追求一個共同的項目前景，確定功能的優(yōu)先級以便總是在處理最具有價值的功能，以及作出決定使得對項目的投入可以產(chǎn)生良好的回報。可以對應為以前開發(fā)中的“產(chǎn)品經(jīng)理”。另一角色是開發(fā)團隊(developer)，這里的開發(fā)人員包括了架構(gòu)師、設計師、程序員、需求人員、測試人員、文檔編寫者等，有時產(chǎn)品所有者也可以被看作是開發(fā)人員。還有一個重要角色就是項目經(jīng)理(projectmanager)。敏捷開發(fā)的項目經(jīng)理會更多的關注領導而不是管理。在某些項目中，項目經(jīng)理可能同時也是開發(fā)人員，少數(shù)時候也會擔任產(chǎn)品所有