由於此次有了我的做業,讀書方面相對較少。不過,軟工這門課就應該這樣以實踐爲主,理論都是架空的理想,實際的鍛鍊纔是最重要的。編程
有這番感想主要仍是由於,作了我的做業以後再看書上寫的內容,簡直就是不謀而合,雖然說我的任務相對於團隊任務或者一個項目的開發簡直就是小巫見大巫,可是這些道理都是相同的,畢竟這些都是一個程序的開發過程。框架
1·Scrum測試
雖然,看書上說的增量式增量式,不實際幹就是沒有體會到它的意義。Scrum就是一種增量式和迭代的開發管理框架。由於,只是我的做業,因此並不能徹底與之重合。Scrum有四個基本元素:時間盒(Sprint),Scrum團隊,製品,規則。設計
時間盒感受更像是一個週期,這樣子就應和它是迭代框架的意思。在每一個週期裏面,咱們關注與咱們接下來要作的增量功能,對這個功能進行必要的分析,計劃,開發,測試。通常來講,這種週期是一個月或者更短,可是個人做業給的時間也就一個星期,考慮到實際狀況,我還有別的功課,其實也就只有四天時間,因此以一天爲週期比較合適,每一天都會有計劃增長的功能。排序
Scrum中最核心的製品是指潛在的可交付產品的增量,就像咱們做業裏面提到的程序要求,每過一個週期咱們按照其要求和本身的計劃實現各個功能,固然也還有本身獨特的一些小功能會是很搶眼的。開發
規則是整個過程的監督者,有了強有力的規則,才能更好的管理,更高效的實現軟件開發。例如:Scrum團隊要求在每一個Sprint的交付物都應該是達到實現規定的「完成」狀態。這樣有了清晰的目標和標準才能提升團隊的動力。文檔
總而言之個人理解就是,一個Scrum團隊在一個Sprint內思考這一階段的製品,而且按照既定的規則高效的工做。產品
2·極限編程軟件
瞭解到它的重要的五個價值觀:溝通,簡單,反饋,勇氣,尊重。引用
成功的軟件開發和編程做業的關鍵要素既不是撰寫文檔,也不是一直碼,而是可否掌握正確的信息。只有得到了正確的用戶需求信息,才能知道咱們的目標是啥,否則就像算是再厲害的編程高手也會像失去照明指示塔的強勁艦隊,始終在一篇未知的或者自覺得已知的海域飄蕩~飄蕩~,及時的溝通才能及時地調整咱們開發的方向,力爭作到不浪費每一分鐘的努力,這樣才能在極限短的時間內完成用戶的需求任務,呈現一個滿意的可交付的產品。
簡單的原則要求團隊在任什麼時候刻僅作當前最必要的工做。簡單直接也是最好的,像是拓撲排序那樣,關注與那些最重要的環節,一切的任務的優先級都會次於它們。同時減小了沒必要要的開發浪費!讓咱們開發的時候不會陷入某些性價比極低並且沒必要要的工做,也讓咱們內心知道,咱們走的每一步都是必須的繞不開的,每一步都是徑直地通向咱們的最終產品。沒有了猶豫,也就能夠全心全意的發揮每一個成員的獨特能力。
書中引用了一句名言來巧妙的說明了反饋的重要性,「盲目樂觀是設計的敵人,而反饋是避免盲目樂觀的藥方」。極限編程中充滿了大量的反饋迴路,鼓勵每一個人利用一切機會來發現開發中的問題,這樣子來縮短反饋的週期,減小反饋以後的調整工做量和工做時間,省去了不少可避免的時間浪費,人力物力的浪費。
軟件開發的過程和編寫程序的過程是一個未知的不肯定的世界,在不肯定的世界作出正確的決策是困難的,沒有了全局觀,沒有了詳盡的分析材料,沒法作到每一步都依靠存粹的理性。勇氣的存在使得團隊傾向於作出正確的決策——即便是一個十分困難的決策,而不是選擇看起來容易,其實是錯誤的決策。在軟件開發中,正確遠遠重於困難程度。勇氣也不會是一味的冒險,而是須要和其餘的價值觀相互結合。
在一個團隊中,每一個人的努力都關乎最後產品問世的價值,團隊應該尊重每一個人的專業技能,構建整個團隊的共同目標,讓整個團隊和氣團結互幫互助,團隊的力量必定遠超單純的幾個高手力量的總和,才能完成每一個看似不可能的任務!