dx是一套簡單的開發規則。它說白了就是迭代開發，在短周期內迭代處理”所有事情“，這里所指的”所有事情“包括需求、分析、設計、實現、測試和文檔等等。

它的大概流程是這樣：
1. 初始探索
? ? 跟客戶坐下來一起討論系統到底是做什么的。在這個過程中，識別出系統的use-case也就是我們所說的user-story。一般花兩到三天的時間做這件事。
2. 功能特征評估
　　對于每個story，我們給個時間評估，這只是一個純數字的評估，我們不關心數字的具體單位是什么，對每個story之間的比例的評估才是我們真正關心的。就是說一個8個點數的story是一個4個點數的story的兩倍。
　　在評估這個過程中，就是用一個很完美的時間里作一件事情。比如，頭一天晚上準時上床睡覺，第二天起來后吃了像樣的早餐，然后上班路上也不塞車，在工作過程中沒有電話騷擾，整天沒有會議，電腦也不死機，網絡也很快，你的搭檔跟你合作的時候也出奇的機敏，考慮又周全，而且也很有耐心，在這樣的情況 下工作一天的我們就稱為進行了一天”完美編程“。然后在這樣的情況下去評估每一個story需要多少天可以完成。
3. 探究
　　根據上面的探索，我們就可以驗證我們的評估。比如完成一個7個點的story需要5人天的話，就意味著5天內快速的粗略地完成7個點。也許保質保量的完成這樣的工作需要3倍的時間。因此調整一下我們的評估為15天完成7個點，大概1天完成半個點，這個數字就是我們的初始速度。
4. 計劃
　　有了story，評估，速度我們都有了，可以開始迭代了。計劃要做的其實就是用我們當前的速度作為標準算出每次迭代里做的story。
? 4.1 發布計劃
　　根據我們團隊的人數，發布周期，確定發布周期內的迭代次數（一般是6次或者說三個月），然后根據我們每次迭代能完成的點數，然后讓客戶根據他的優先級挑選一批差不多數量的story作為我們的發布計劃。
? 4.2 迭代計劃
　　根據每次迭代能完成的工作量，挑選出本次迭代需要完成的story。然后把這里story再細化任務，這任務比story要小很多，它以4-10小時為單位的。在分配任務 時，每個人在自己的任務上簽下名字。在簽名字時候，每個人心里都有一個預算，每簽一個任務就在自己的預算里減去相應的數字，直到自己的預算花光為止。
5. 中點
　　在迭代周期內開發時間過了一半的時候，看看完成了幾個stoy，如果比原計劃快了，就讓客戶多增加幾個story，然后慢了，就讓客戶把其中的一些story移到下一個周期。
6. 速度反饋
　　在一個迭代結束時候，我們進行速度反饋。比如本次迭代完成了23點story點，那么這個就作為下一次迭代可以完成的story數的依據。

一次迭代包括了什么？
結對開發
　　兩個開發人員用同一臺機器一起工作，一起處理他們負責的任務。兩個程序員都完全忙玩寫代碼，他們的眼睛都關注著屏幕。
可驗收測試
　　每次dx迭代開始的時候，客戶和QA把user-story充實到use-case里面，并為之編寫可驗收測試 案例。然后把這里測試案例交給開發人員，這些測試是真正的需求文檔。
單元測試
　　為寫的代碼編寫單元測試。
重構
　　因為有單元測試在撐腰，所以可以放心地去重構，測試的結果會告訴你重構后的正確性。絕不能把爛代碼留到第二天。
開發式辦公室
　　所有工作都在一個房間進行，即使客戶也不例外。
持續集成
　　不管有沒有其他人check out過，你都可以進行check out。然后只要手快就可以check in。而第二個check in 的人就要負責合并代碼。這里有一個原則，負責合并代碼的人必須確保測試是通過的。

特別提醒，這里沒有提到UML，也沒有提到JAVA。UML不是一個方法，而一種圖示，JAVA出不是一個方法，而一種工具。

最近，dx其實就是xp。

轉載于:https://www.cnblogs.com/vinson1816/p/3754300.html

總結

以上是生活随笔為你收集整理的UML for Java Programmers之dx实战的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。