擁抱變化 敏捷開發

二弟的一篇介紹 敏捷的文章，希望有機會在 GBS 的系統實施中能夠早日用上 敏捷


關於敏捷
2008-08-27 10:02 | (分類:默認分類)
今天寫實習總結，描述了一下這幾個月的收穫。截取其中的一段關於敏捷的感想。

Scrum對於我這樣的開發人員來說，讓我可以直接參與到整個開發週期的各個階段。在評估會議時，團隊中的每個成員都有權對產品的需求項進行評估，確定需求的工作量大小。在Sprint 計劃會議1中，由Product owner對該Sprint中的需求項進行需求描述，明確具體的需求。在Sprint計劃會議2中，Scrum master組織團隊對既定產品backlog的需求項進行任務劃分，將每個任務細化到每天的工作中，確保在Sprint週期中，每個人的任務分工明確。

在Sprint每日的例會中，每個開發人員報告自己的工作進度，並明確下一天的任務，遇到障礙，可以及時找到相應的人員開會解決。在Sprint的評審會議中，對Sprint的完成的任務進行提交演示，並可以增加新的需求項。在Sprint的回顧會議中，確定這個Sprint的成功和失敗的經驗，及時總結。

我們開發人員在整個Sprint週期中，可以明確需求，並自主地安排工作進度，在技術增長的同時，也增加自己的工程管理的經驗，有利於個人職業生涯的發展。Scrum相比於其他的過程模型，更加註重團隊個人素質的提高，並且能夠快速的應對變化。

TDD也是一種敏捷開發的方法。它的主要思想是通過建立一套可執行的測試用例，保證代碼的實現與具體的需求的一致性，以測試用例作爲中介，建立一個有序的工作方式：從需求用例中導出測試用例，從測試用例中導出代碼的接口和實現。

在我平時的開發過程中，嚴格的遵守了TDD的指導。拿到一個具體的Use case時，先測試幾組測試數據，然後用JUnit建立一個Test case與Use case對應，在Test case中採用Mock對象，先虛擬地對測試方法進行實現，等測試通過之後，再抽取出具體的接口，然後實現。

我覺得TDD的好處是在產品的開發過程中建立了一套可運行的Test case，讓需求變得具體，可控。一旦需求發生了變化，可以從Test case 入手，然後再修改實現代碼。使需求的變更在代碼的級別變得可控。

我還學習了基於Java平臺的動態語言Groovy。這是一種敏捷的開發語言，比Java語言具有更高的抽象性，用少量的代碼表現更多的功能。

在IBM的收穫是讓我體驗到了“敏捷”無處不在。從敏捷軟件過程的Scrum方法，到測試驅動的開發方式，到敏捷的開發語言，整個軟件工程的各個方面都有敏捷的出現。我考慮過這個問題，爲什麼這兩年敏捷變得如此的流行。我覺得一個原因是讓需求的變更變得可控。軟件工程發展了10多年，積累的大量的原始資源，各種平臺，中間件林立。客戶對軟件的需求從最初的簡單發展到如今的非常複雜，業務變更非常頻繁。過去那種僵硬的，按步就搬的開發方式和管理方式已經不再適應變化。比如採用瀑布模型，開發了幾個月客戶纔看到最終產品，但是最初的需求已經改變地面目全非了。Scrum的好處是它把“變”與“不變”控制地很好，在Sprint進行中Sprint backlog是不應發生改變地，保證了工作的有序。在Sprint的開始和結束之後可以進行需求的變更。由於Sprint的週期長度較短，這種短暫的穩定，可以讓團隊在正確的道路上持續的前進，而不是全程的變化，找不到正確的道路。

敏捷是軟件工程的發展方向，讓我們擁抱變化，讓生活變得更美好一點。