【更新】Individual Homework Agile Development reading

閱讀材料來源：Martin Fowler:  http://martinfowler.com/agile.html

Tips：這是比較高度歸納的版本，詳細剖析過程，在文章的最後~

軟件開發的主要難點在於，想要達到高質量的開發結果以及高效率的開發過程同時成立。

高質量的開發結果：軟件質量好壞的衡量方法主要在於用戶是否滿意。

高效率的開發過程：有一個較爲有條的開發流程，來保證開發的完成率和高效性。

兩者不能同時成立的主要緣由：

用戶需求的變化性過大，固定的開發流程阻礙用戶需求變化的知足，從而二者看起來矛盾。

（用戶需求的變化性過大的緣由：

1.PM與用戶的溝通不充分，即使溝通充分了，用戶有時候也不知道本身的需求究竟是什麼，什麼功能是最重要的；

2.用戶的需求自己隨着軟件開發過程是在不斷地變化的。）

 

各類開發的比較：

code and fix：開發自由，一片混亂，以犧牲軟件的完成率爲代價；

高質量：不必定；高效率：不是；

計劃驅動開發：貌似層次分明，但從本質上違背了軟件的評價標準，以一個模糊的、不許確的、過期的用戶需求做爲軟件開發目標，即使層次分明也沒有意義；

高質量：通常不是；高效率：好像是；

敏捷開發：不過分地苛求軟件的步驟規範，經過自適應地尋找適應於具體狀況的開發過程；不一開始就限定用戶的需求，經過快速迭代來不斷獲取用戶的需求，所以用戶的需求，既由程序員根據實際迭代過程來確立，又由公司的遠瞻性的目標影響。

因此敏捷開發的步驟既能夠較爲有條，使開發效率較高。又能夠更準確地把握客戶的需求，從而使開發結果——軟件的質量更高。

高質量：基本能夠；高效率：基本能夠；

 

也就衍生出了敏捷開發的兩個特色，自適應和以人爲本。

自適應主要包括用戶需求的適應，和開發過程的適應；

用戶需求的適應：是用戶需求在不斷地迭代（開發--用戶反饋+程序員觀察--再開發）中肯定化，以及需求自己變化的適應。保證了開發方向的正確性，保證了開發結果的高質量。

開發過程的適應：是開發過程當中經過隊員的不斷磨合，具體的環境，最新的用戶需求，來不斷改善開發的過程。保證了開發過程高效和完成率。

以人爲本主要包括以用戶爲本，以程序員爲本。

以用戶爲本：用戶的滿意是軟件開發的目標。要不斷了解用戶的需求，主要利用保證用戶需求的適應性；

以程序員爲本：程序員能夠接觸到最真實、最具體的用戶反饋，而管理層每每都是脫離實際來作決定的。同時，程序員因爲接觸過於具體，而致使目光較短；而管理層每每能夠作出更有遠見的決定。所以，要打破以管理層目標爲開發目標的局面，要使程序員的決定和管理層的決定處於同等地位，這樣才能揚長避短，使軟件開發作得更好。

 其實自適應與以人爲本不是相互獨立的，兩者相互配合才能作好軟件開發，也是敏捷開發的實質。例如，要作好用戶需求的自適應，就要以用戶爲中心，提升程序員的決策份量，也就是以人爲本。要作到以用戶爲中心，就要用自適應的方式來不斷地修正用戶的需求，真正地作到以用戶爲中心。

 

Agile development的分類

其實分類不少，由於它是自適應的，因此方法並非一成不變，應該有機地、視狀況地進行選擇。

 

How to Start Agile development?

選一個風險程度較小的項目，可是不能低於你無所謂的程度，進行實踐。並不斷地體會，反思，調整。理論結合實踐。

若是有經驗者的指導會更好。

軟件工程課就是這樣一種平臺，So Lucky~

 

My ideas:

什麼是用戶的需求：

其實用戶的需求首先用戶也不是很清楚，要經過不斷地迭代，不只僅要經過單純用戶作出的反饋來獲取，更重要的是，程序員要有敏銳的觀察力，觀察用戶究竟須要什麼。也許這個功能，原先用戶並無要求，可是在觀察中發現，用戶其實很須要，作出產品後，用戶也很驚訝，哦，我原來想要這個功能。其實不少的IT公司的創新，都源於對用戶行爲的觀察。

適應的高效性：

人體自己就有不少反饋機制，因此使得人體是一個獨立而又統一的系統。有很強的適應性。人的強大，每一個人均可以理解。機器學習，也是一種適應的過程，是一種人類適應性的計算機應用。敏捷開發很是強調適應性，從這一角度看，是很是科學而天然的。

敏捷開發難點：對程序員的要求很高

敏捷開發，在迭代過程當中。每次要基於上一次的開發進行修改。那麼，每一次設計都要考慮到易於修改性，這對程序員的設計能力，挑戰很是大。

在開發過程當中，程序員有權利控制開發的目標，這使得每一個程序員都要有必定的經驗和能力作出較爲正確的判斷，才能使得最終目標的正確性。

敏捷開發的其餘應用場景：

其實在生活中，不少合同的死板，使用戶的權益不能良好的保障。用戶在提要求的初期，可能沒有對事物的全面認識，從而使得合同目標的誤差。而服務者由於要一味地履行合同條款，徹底不理會合同目標的正確與否。最後服務者辛苦，用戶不滿意。其實這一過程，應該是服務者與用戶不斷地交流，互相信任的過程，才能作到最好的合做。

感想：

此次看Martin Fowler的博客，以爲很神奇。方法的提出過程，讓我以爲本身平時應該多思考，多質疑，多些創新思惟。

會在團隊項目中，不斷地繼續閱讀，不斷地實踐，思考。

 

較詳細分析過程：

軟件工程的特色

對於軟件開發，與其餘工程類的項目（特別是土木工程類）最大的區別在於，沒有一個具體地，成功率很高的可遵循的規章制度（執行步驟）。縱觀各大IT公司，能夠發現IT業的成功主要在於科技的創新，軟件的開發重點在於靈活地進行創新，從而使客戶滿意，而不是像蓋樓同樣保證能夠建出一個大樓。同一類軟件，它的用戶滿意度，也就是軟件好壞的重要評價標準，有很大的差距。而同一類大樓，例如寫字樓，用戶的滿意度很大程度上與這個樓是否建的好沒什麼關係。因此，蓋樓能夠有很詳盡的規範步驟，而軟件開發須要靈活地進行創新，而規範步驟是這種創新最大的阻礙。

軟件開發的主要方式：

最先的軟件開發是一種code and fix的模式，這徹底就是一種混亂的狀態，既不能保證成功率，也不能保證客戶的滿意度，開發成功與否可能有很大的運氣成分。以後，軟件開發效仿工程類項目，產生了計劃驅動方法，這就出現了讓不少人頭疼的文檔，花很大氣力去完成，以後幾乎沒有什麼效用。分析其中最主要的緣由，就在於軟件的靈活性沒法被拘泥在一塵不變的步驟中。以後就出現了，在散漫和嚴苛制度的中間態，敏捷開發。之因此敏捷開發較好，主要在於它既能夠減小風險，減小混亂，又能夠較大限度地保持靈活性，提升軟件的質量。

敏捷開發主要有兩個特色，用適應性來保證軟件的靈活創新，用以人爲原本減小風險與混亂，這二者共同保證軟件的質量。

適應性： 包括需求的自適應，開發過程的自適應。

需求的自適應：對於現今互聯網、大數據時代，事物的變化速度是很是快的，甚至幾個月前的軟件需求已經不能符合如今的需求，要在較短的時間內快速應對變化，這在任何一個產業中都是很是難的。軟件開發要作到這些，要找到一種很好的方法，來預見人們的需求。靠程序設計者們去苦思冥想顯然是不可能的，一個最直接的方法，就是用實踐來檢驗軟件，讓用戶們進行使用，根據使用的結果來判斷須要作哪些改變。傳統的發佈軟件的方式，幾乎沒有可能讓用戶使用後進行改變，由於它到用戶的手中時，已經開發完了。因此，敏捷開發用快速地迭代，先開發出原型，在用戶反饋之後，作出修改進行迭代，以較小的代價來快速的改變。

開發過程的自適應：要保證開發過程的層次分明，就要以必定的規範制度。若是制度是固定的，那麼就不能很好地適應不一樣環境以及變化。但也不能沒有制度，一切事物都徹底地混亂下去，很低效。若是在開發過程當中，經過程序員、用戶（需求）、管理層以及他們自身不斷地進行磨合，來決定較好的規範制度，就既高效又靈活了。

以人爲本：我以爲這裏的以人爲本主要包括以用戶爲本和以程序員爲本。

以用戶爲本：傳統的軟件開發主要是以項目書的目標爲本，達到了文檔的目標，okay，無論用戶是否滿意，軟件開發就視爲成功。但這樣，很不易於軟件開發的發展，軟件的好壞應該由用戶的滿意度來決定，而非是否達到了一個目標，而用戶目標的制定，每每因爲PM（應該是吧，不肯定）和用戶溝通不夠充分，而致使目標的不清晰，更別說用戶想要更換目標了。而敏捷開發，經過迭代過程當中多個版本，不斷地獲取用戶的需求，雙方共同確立軟件開發目標，從而使軟件開發出現共贏的良好結局。這是一種軟件開發的理想狀態。

以程序員爲本：在大多數行業中，每一個職員對於一個公司，機構只是一個產業鏈上的螺絲釘，他沒有本身的思想，只要按照公司的要求進行正常運轉就好。而軟件開發的要求，首先確立時就是模糊的，再加上又要不斷地變化。要定義軟件的要求是什麼，顯然不實際。那麼，程序員由於沒有要求就天天無所事事了嗎？首先，敏捷開發要把程序員團隊當作一個有機的總體，他們是有創造力，有思想的人，而非工具。每位程序員要有高度的自律來保證，作好最好地軟件；每位程序員要有高度的自主選擇權，不能是公司的機器人，要將本身對於軟件發展最好的見解與看法結合到公司的目標中去，公司的目標與程序員的選擇是同等重要的。每每公司的目標是缺少脫離實際，但有必定的遠見性；而真正接觸到工程的程序員的目標是真實具體的，但又一方面容易迷失遠見。因此兩者的結合將是軟件的質量有很好的保障。