敏捷开发一千零一问系列之二十四： UI设计怎么做到敏捷呢？（兼谈对UI热的理解）（下）

这是敏捷开发一千零一问系列的第二十四篇。（在这里提问，之一，之二，之三，问题总目录）

续上文

陈勇-咨询-北京(139107533)13:27:03
这个是我们的组织结构维护视图，本来是一个很简单的树控件，但就Domain而言，一个人只有看到长相如此的东西，才会理解它是一个组织结构图（尽管M就是树）

但是，V里边的代码，不过如此：

真正的代码，被放到M里边了。

如果从这个案例分析，就会看到至少三个人都参与了：

１.产品经理，他要求不要搞一个树控件，要做一个和平时纸上印刷的一样的组织结构图

２.UI设计，开始设想了一个方案

３.但最后实现它的，是程序员。

这也是我为什么最后兼任产品经理、UI设计、程序员的原因。

如果分开三个人，还能实现，但必须有相同的价值观，不要各干各的。

问：13:30:54
不要各干各的指的是什么？

陈勇-咨询-北京(139107533)13:30:55
其实，我们有一个纯Html版本的组织结构图，后来封装到C#里边了。

各干各的，就是程序员说：“哪，你看这是数据读取接口，你自己画你那个组织结构图去吧”

我们有3个地方用到组织结构图，都是这三行代码搞定。如果各干个的，就需要把大约200行Html重新拷贝三遍。

但由于程序帮助封装了ViewModel和View的Helper，一切就这么简单了。

回到问题本身，UI设计怎么敏捷？

陈勇-咨询-北京(139107533)13:34:03
首先，应该有一个人作为打通跨职能部门的纽带，应该是产品经理。
他综合提出对UI的最终设想，基于的是，用户如何与产品交互，才能最好地完成业务（这个好，不完全是方便、美观这些，而是直接和业务切合）

其次，UI和程序应该是跨职能的，或至少处于一个跨职能团队中，不要分到两个部门或团队里边，这样大家才会集体思考最佳做法（比如前面程序帮助UI封装Html为Helper）。

以我三位一体的体会，很难想象如果有三个思想不统一的人做这件事情，最后结果是什么。

问：13:37:51
达成共识

陈勇-咨询-北京(139107533)13:38:48
是的。

要把UI长到客户的心里边，而不是展示在眼前而已。

我们现在还有几个页面不太满意，感觉看到以后，还要思考一下：这是什么……这样的UI，就有问题。

看到后应该是：哇塞居然可以这样！

或者：你看，就是我上次说的那样

有一次在之前的公司去做售前讲解方案，对方老总就一个劲地捅旁边另外一位，指着屏幕窃窃私语。我就知道那个单子成了。

陈勇-咨询-北京(139107533)13:46:30
总之，用户看不到M，看不到D，看不到C，只能感受到V

另外一位QQ成员：13:50:47
勇哥，你说的客户感受V，能否说的具体点。是不是说除了用户体验，还要业务体现出来，让客户觉得咦~~这就是我所要的。对吧。

陈勇-咨询-北京(139107533)13:51:50
是的，V不要只图做得漂亮、方便，要理解用户来这里干什么，他看到这些，是否真的知道自己应该干什么了。

另外一位QQ成员：13:52:05
明白了，谢谢~~

（问题讨论结束了，下面是关于MVCD中D的来历，一般只说MVC）

陈勇-咨询-北京(139107533)13:53:38
MVC说法比较多，D是我自己说的，因为我发现D比较独立。

我把数据的读写和缓存都归结为D。

另外一位QQ成员：13:55:44
由M到D，我理解就是数据持久化到数据库

陈勇-咨询-北京(139107533)13:56:30

外加应用缓存吧，
比如火星人里边，史诗故事-用户故事-增强-缺陷……这些，有父子关系，表面上看，是属于Model的行为。
但我们发现，部门-团队-小组，产品线-产品-版本-Release……也有父子关系

所以，后来“父子关系”，被从Model的层面，挪到Data的层面

所以，我们的部门/产品/用户故事……（一共7种）东西，是存储在一张数据库表里边的，因为他们被从D的层面抽象过了（注：被抽象成为了“有父子关系的数据）。

但是，这种存储会造成性能恶化，所以，又做了应用缓存，把他们拆开。

从父子关系看，他们是iheritable-item

从数据的差异看，他们是udcable（user-defined-column-able可定义字段的)我们用这两个类来管理他们。
这些都是和M没什么关系的，用D来维护更好。