使用敏捷開發模型的敏捷程序員的一天

　　大家敏捷開發，每天開發人員的日程是如何安排的?本文討論的是一個需求子任務的開發過程，相當于軟件開發的微循環、微迭代。

　　其實敏捷開發的幅度很寬，有多種靈活、實用的做法，并非只有 Scrum+XP 一種唯一、正確的做法。下面介紹太極敏捷推薦的實踐，幾種可行敏捷開發模式中的一種，并比較與 Scrum+XP 做法的不同。

　　太(泰)極敏捷以下用 Tai-ji 或 TP(Tai-ji Programming)代稱。

　　上午

　　每日例會

　　Daily Scrum or Daily Stand-up Meeting

　　Scrum 的每日站會通常安排在早上(例如 9:30-10:00 之間)，規定不能超過 15 分鐘，會上不討論如何解決問題，通常這么短時間的例會是不夠的。

　　Tai-ji 建議采用 DTM(Daily Team Meeting)，一般 30-40 分鐘，最長不超過 1 小時。這是對 Daily Scrum 的擴展，以便大家更深入地討論和交流技術問題。

　　如果大家覺得每日例會過于頻繁，也可以采用 WTM(周三例會)。

　　挑選任務

　　例會上由程序員主動挑選當天的開發任務，或者由 PM、架構師等分配任務(若無人認領)。在 Tai-ji 中這叫雙向任務分配(BTA)。

　　狀態更新

　　...

　　需求細化-狀態

　　程序員和用戶、BA、RA 一起細化當前任務的需求，確認 UML 模型和 Use Case 文本中待實現的需求是相對準確和穩定的。

　　當前任務的需求明確后，Tester 可以立即開始編寫相關的測例(Test Cases)和自動測試程序。

　　Tai-ji 采用 UDD 和 PPoD 開發模式，開發與測試工作是并行的。

　　XP

　　XP 采用用戶故事，需求細化涉及到把粗粒度的用戶故事分解為多個細粒度的用戶故事，一個用戶故事可能需要幾天時間完成，可以再把該用戶故事分解為若干(開發)任務。

　　XP 的需求細化主要通過故事卡片分解，口頭溝通完成，未強調書面記錄、分析需求的細節，這是一個主要的缺陷。

　　很多人以為 XP 開發是 TDD，一上來就是對著故事卡片寫單元測試代碼，這是誤解。XP 也有需求細化的環節，由于有 Onsite Customer，需求任務一旦溝通明確后，現場客戶就開始在開發人員的幫助下寫自動驗收測試了(ATDD)。

　　TP 建議需求細化，主要是對用例文檔與模型中的需求細節的分析和更新，包括各種功能需求和非功能需求(如業務規則)。

　　盡早開始編寫自動驗收測試是個最佳實踐，但與 XP 不同的是，TP 提倡 UDD over ATDD over TDD，用 Use Case 來指導編寫系統驗收 Test Case 是更好的做法。

　　設計建模-狀態

　　程序員針對當前的需求任務，進行必要的架構和模塊概要設計，畫 UML 靜態圖和活動圖，更新系統設計文檔和模型。

　　設計建模的內容還包括：UI 原型設計，數據庫/表設計，算法設計，數據結構設計等等，可能涉及到多人。

　　此時的設計，主要是做一種概念性設計，在實際編碼(相當于詳細設計)之前獲得一種基本可行的開發思路和方案，包括模塊劃分和職責分配(在 TP 中叫預構-Prefactoring)，預估開發中可能存在的風險和問題... 所以此時的設計，不應該追求完美、成熟，而基本保證邏輯上的合理、正確即可。

　　敏捷設計與建模的時間，一般不要超過一小時。

　　在敏捷開發實踐中，事先不做基本和必要的需求分析、概要設計，上來直接寫代碼的做法，往往是一種差實踐。

　　建立分支(checkout and branch)

　　程序員為當前開發任務(需求、特性、用例)建立一個獨立的代碼分支。

　　Tai-ji 采用 AI(自適應集成)開發方式，一般情況下建議不要直接在主干上工作，以免相互產生干擾。

　　XP 的 CI 鼓勵大家都在主干上開發，好處是隨時隨地可以更新，獲得主干的最新代碼，省去了 branch and merge 的麻煩。CI 同時也有些缺點。

　　代碼開發，是都在主干上好，還是在獨立分支上好?這其實是一個需要根據實際情況進行權衡、取舍的問題。

　　下午

　　編程開發-狀態

　　完成當前開發任務，實現系統需求。

　　一個具體的開發任務通常由程序員一人、雙人或多人聯合開發完成，在 Tai-ji 中這叫 PPoD(按需結伴開發)。

　　通常在程序員編寫實現代碼的同時，至少有一個 Tester 同時為其編寫測例和測試程序。

　　完成當前任務開發，通常需要 1-2 天時間。若當天無法完成，此開發狀態將延續到第二天。

　　復雜軟件開發，是一個不斷探索、試錯、迭代的過程。在此開發過程中，有可能要不斷地澄清、更新需求，更新架構和模塊設計，更新測試程序，更新相關文檔和模型...

　　分支測試-狀態

　　程序員在自己的分支上，完成必要的測試(單元測試、功能測試、非功能測試等)。

　　糾錯(Debug)-子狀態

　　測試發現錯誤，程序員要不斷進行查錯、定位、改錯、再測試的開發循環。

　　重構優化-狀態

　　測試通過、確認功能實現后，程序員對已有代碼進行必要的重構優化，改進代碼質量。

　　重構代碼后，仍需要進入測試、糾錯、重構、再測試的循環。

　　checkin

　　程序員一天之內應該多次 checkin 自己的代碼，這個 checkin 是檢入到自己的任務分支上，而不是團隊主干。

　　合并(merge)-狀態

　　程序員把自己分支上達到提交質量的新代碼合并到團隊主干上。

　　合并到主干的操作，對于某一位程序員來說，并非每天都發生。程序員完成開發任務，一般需要一至兩天時間，這是正常的。

　　系統集成與測試-狀態

　　當天代碼全部合并后，進行系統集成測試、冒煙測試、單元測試等。

　　通常整個團隊一天可以設置中午、下午和晚上兩至三個合并窗口。

　　晚上

　　你司加班是否家常便飯?

　　敏捷開發反對無節制的、長期高強度加班，但“每周 40 小時工作”只能是理想口號，不解決任何現實問題。

原文轉自：http://www.anti-gravitydesign.com