UI驱动的开发

Question

UI驱动开发的想法有意义吗？我们的大多数客户喜欢以屏幕的形式表达他们的需求。例如，我想要一个屏幕来做这个和那个。有时他们甚至自己决定屏幕的布局(这可能是因为今天的客户已经将软件应用程序用于他们的大多数任务)。

此外，这种需求收集方法似乎可以自动传递数据和相关行为。

你们觉得怎么样？

Answer 1

实际上，在这方面它是有意义的。用例的不同之处在于它们不能以相同的方式使用。用例对于提取和形式化需求非常有用。

不久前，我在一个UI实验室工作，我们玩弄着这个概念，尽管我们并不这样叫它。这里的基本想法是，我们将使用敏捷迭代方法进行开发，其中我们将使用可用性测试来帮助收敛到所需的解决方案。

典型的周期是：

• 起草了一些要求和用例，范围非常有限，非常适合收集有关此功能(可用性、易用性、接受度、性能等)的测试协议。
• 创建或扩展应用程序以包括此功能
• 让少数用户使用可用性测试的敏捷改编(请参阅Ruben's Handbook of Usability Testing)测试应用程序，其中我们将测试会话限制为15分钟，15分钟内使用全部数据从测试中注入到未来的迭代中。

当用户不能确切地知道他们想要什么或者不能告诉我们时，这种方法非常有用。因此，我们必须设计测试，收集关于软件对用户的实际有用性的客观数据，并尝试调整下一次迭代。(我们的许多“客户”，如果我可以这么叫他们的话，他们是严重残疾的，不能说话，所以我们必须有创意)。

这种工作方式迫使我们在软件开发生命周期的早期就让GUI对客户端可用，并且因为它是我们直接测试的中心点，所以可以说它是GUI驱动的设计，因为融合的驱动力是用户与系统的交互。

尽管我们主要针对非常特定的情况开发了这项技术，但我们在一个普通软件上对普通用户进行了一些测试，并获得了非常积极的结果。设计将很快地向用户的需求收敛。此外，他们参与这种设计方法的事实也对目标社区对产品的接受度产生了非常积极的影响。

不幸的是，在我们发布我们的结果和扩展这一研究领域之前，内部斗争已经拆除了实验室，这真是一种耻辱。

因此，UIDD (请原谅这个糟糕的首字母缩写)将成为TDD软件开发方法家族的成员，在TDD家族中，迭代取决于用户交互。

关于这个主题的额外阅读：

http://www.codinghorror.com/blog/archives/001091.html

http://cakebaker.42dh.com/2007/07/07/usability-driven-development/

http://www.springerlink.com/content/l413k76812896gnt/

http://www.agilemodeling.com/essays/agileUsability.htm

http://www.uxbooth.com/blog/how-test-driven-development-increases-overall-usability/

Answer 2

你在做什么类型的开发？当我开发web应用程序(flex或php)时，我会处理绘图(线框)，这样我就可以让客户了解应用程序的流程/外观，而无需编写任何代码。

没有适合每个人的“正确的开发方式”，你只需要找到最适合你的方式。干杯!

Answer 3

我发现这是一种收集需求的合理方式。我会小心地实际构建屏幕，然后直接开发功能。你会发现代码的重用性很低，你会得到一个看起来很漂亮的应用程序，速度很慢，或者不能完全正确地工作。它将在一些项目上工作，而不是在其他项目上工作，这取决于需求的复杂程度以及在预测数据瓶颈、缓存问题等问题时的表现。

这听起来像是类似于行为驱动开发、线框图和用户故事。