UML for Java Programmers之dx实战

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。