“你有了解哪些開發模式？” “你瞭解的這幾種模式有哪些不同” “測試方法與目的是什麼？”
帶着這些問題，我們來看看Agile 中的Scrum 與 TDD
Agile
敏捷開發模式，實質是一種以人爲本的開發理念，重視團隊溝通，重視客戶反饋，重視產品迭代。
根據Agile的思想，我們主要有Scrum和XP兩種開發實踐，XP中又以TDD較爲流行。
Scrum
項目經理從客戶（產品經理）獲取初步的需求，建立需求列表；
項目經理（可以分爲PO與ScrumMaster）定一個sprint的週期（4周例如），按需求列表分配優先級，以此爲前提，與開發小組討論工作量backlog；
技術總監按backlog分配任務；開發小組集中速度開發。
項目經理每個sprint向客戶遞交可視化產品，評審並討論迭代需求。
循環迭代，直至遞交完整需求的產品。
優點：有效提升用戶滿意度，產品成功率；量化，透明的開發任務，增加效率；不同開發崗位之間的互動，培養了團隊凝聚力，減少技術代溝產生的摩擦。
缺點：項目經理要求極高，對外部客戶的需求更變所帶來的backlog，經費以及質量控制要有明確的量化能力。對產品迭代需求的優先級劃分要合理。對內部開發人員/QA的信息互換要即時。
對開發人員有更高的要求，沒有完善的設計文檔（UI/原型）約束，容易產生理解誤差，不能解決反覆修改需求帶來的工作量積壓問題，即遞交產品前的開發工程量不變甚至更多。
Scrum小結： “敏捷”實質上是對產品需求完善的速率，不是加快工程速度，而是產品後續打入市場的速度！
正如微信等產品，通過用戶反饋後迭代部分業務功能並及時更新即是agile的思想。
由上可知，Scrum對開發人員個人也提出了更高的要求，尤其是對需求的認識。
此時我們需要引入TDD的開發模式了，即先寫測試後寫業務代碼。
T實際上能映射現實業務的需求，在“莽”代碼前，開發人員先分析需求，完善測試，再按照測試要求完成代碼書寫。這樣的功能模塊跑起來纔是有效的，這樣的集成系統跑起來纔是有質量，少返工，真前進的工程。
經過一些網絡資源的閱讀與大佬經驗談，TDD給我的第一印象是，前期引入較爲困難，測試例的推導不全，後期補測試例的情況較多。如若在Scrum中引入TDD，開發人員Sprint工作量積聚上升，抱怨與牴觸聲隨着backlog增加而來。
可以推斷，TDD對技術總監的要求更高，需要對開發成員進行思想的指導與實踐的論證，團隊熟練掌握後，後期對於產品的質量的確會有進一步的保證。
總結：Scrum與TDD近幾年的普及與實踐都順應了互聯網瞬息萬變的節奏，這兩種開發模式都對開發人員個人，提出了更高的要求。
OK~屁文寫完，繼續補技術知識去了。