从持续交付看敏捷开发的自相似性（敏捷开发的心跳）

       作者：陈勇

       出处：blog.csdn.net/cheny_com

      

自相似性是指一个事物的局部与其更大的局部乃至整体具有相似性。

从大的方面看，敏捷开发具有重视客户价值，提倡持续交付等思想。但一般而言，Product Owner常常具备相当好的客户价值意识，而一线开发人员则比较关注技术本身，所以一旦仅仅停留在思想层面，在实际工作的时候就会发现有所背离。因此应该从自相似性的眼光看待敏捷开发的整体思想与局部实践，从而做到年年月月日日事事均符合敏捷开发的思想。

本文只从“持续交付”这一个敏捷开发思想来分析敏捷开发的自相似性。

“持续交付？是不是就是每个冲刺结束都要有一个可运行的版本？”是，也不是。

 

冲刺末尾的持续交付

敏捷最大的特色之一，就是阶段性地交付可运行的软件，而不是一堆暂时无法使用的文档。按照精益生产的思想，文档只是一种“中间产物”，不但不容易写好，还很难评审；即使在初期看到了完美的需求文档，也很难保证最后能看到完美的软件。因此敏捷开发决定只要可能（不是绝对的），就尽量绕开这个中间产物，而用可运行的软件来表明软件的进度和质量。

在冲刺的末尾，Product Owner和干系人们不是看着文档，而是看着一个可运行的软件进行评审，是这里持续交付的核心目的。为了方便评审，被交付的往往是一组相关的故事群，而不是“当前最重要的需求”。

 

冲刺内的持续交付

冲刺期内看平静，大家忙忙碌碌只待最后交付，其实不然。如果每个迭代都始自“需求分析”而终于“系统测试”，敏捷开发就变成迭代开发了。然而即使每个用户故事都独立开发，仍可能发生一堆故事都在“开发中”，但因为这些故事无法独立成章因而无法形成可运行软件的状态。为了防止这种情况，好故事一般都独立、可测试、完整地交付某个客户价值，因而每当完成一个故事，都能形成一个临时的可运行软件。

若能遵循MoSCoW方法（另有博文详述），则可以保证即使冲刺结束时无法完成所有Sprint Backlog项，仍能向Product Owner交付一个可用的软件。

 

“日创建”的持续交付

“日创建（Daily Build）”因能在每天结束时都能交付软件而闻名（这是微软在开发Windows时的创举），但对于小型软件开发，已经能做到每人每次提交代码在10分钟后就能看到结果的能力。1000人在开发了1000天的软件里边定位1，000，000个缺陷是不可思议的（平均1人1天1个缺陷），但每人在自己每天的代码中定位一个缺陷却是很现实的，前提是你能找到它，日创建就是这个逻辑。

一般常常提到的持续集成+自动化测试指的就是这个层面的持续交付活动，其目标是在提交代码后最短的时间内形成可运行软件，并确认是否存在问题。

 

版本间的持续交付

很多软件看似越来越强大，但市场反响却并不好（比如很多人安装的“免费”Office都是2003的，也就是7年间完全没有和MS做生意的打算），原因就在于这些软件并没有解决好一个问题：“下个版本到底面向哪个市场的哪类客户？他们为什么购买它？”这时软件很容易跟随公司领导的思绪梦游，或者被一两个大客户牵着鼻子走，或盲目地试图覆盖竞争对手的所有功能而迷失本性。

还是之前那句话：按照商业步调计划版本内容，也就是每个版本出来后，都要满足某些需求、获取某些客户、打败某些对手、取代某些产品……如果能持续找到这些“某些”是谁，那么下一个版本就能成功，如果找不到，兴许产品已经到达退出市场的阶段。如果不能持续找到市场和客户，怎样持续交付可运行的软件都是一件没有意义的事情。

 

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》