敏捷界面重构

敏捷界面重构 — initial idea

很多人都觉得界面的事情是细枝末节,等功能做好了,找个时间一起清理一下就好,不会占用太多工夫。很多人也都是这样做的。

这里说的界面开发是指系统的交互设计和界面可用性及易用性设计,也包括CSS的界面布局、颜色、字体等基本的视觉元素。这些问题的重要性不用多谈。

我在项目中期加入过几个项目,这时候最令人头疼也最令人兴奋的莫过于在开发中期对于界面和UI进行变更了。一个项目在初期如果没有做良好的界面设计,想要在中间来进行大的变更简直是噩梦一般。在一个敏捷团队中,做这样的事情尤其困难。

敏捷开发中的一个实践,是需要客户的协作和参与,及时由客户认可做完的需求以及由客户决定下一步的开发。这种客户享有决定权能够使开发变得更顺畅,客户关系变得更融洽,是一个很好的实践。

但是,这种实践给界面的改进带来很大的麻烦:如果在项目中期打算进行界面的变更,自然要写出很多跟界面相关的需求,而客户按照需求的价值决定优先 级,他们有时候不理解这样的界面改进如何带来价值,为什么改善一些文字描述和交互方法还要占用开发时间,他们更希望在有限的时间内增加更多的功能和修复更 多的BUG。这时候,这些界面调整的优先级就被排的很低,在几个开发周期内都没有得到采纳。

我们先后尝试了几种方法来改进这个过程,例如给客户培训交互设计和可用性知识;将开发人员分为两组,其中一组专职负责界面改进;或者将界面改进需求单独分成一组,要求客户每个迭代从其中选择一部分等等。但这些办法都不是很理想,没有达到预期效果。

事后总结原因,觉得最大的原因还是在于:客户不是用户。他们虽然负责对项目功能验收,但他们并不最终使用系统。系统使用上的问题不是他们最关心的。他们需要得到投资回报,因此选择了回报更快的功能开发。从这方面看,客户的选择是无可厚非的。

理想的解决方案应当是在一开始就对界面及UI进行控制和把握,并进行持续的度量和改进,或者称为:界面重构。将界面重构和代码重构等同到同样地位,在开发过程中持续随时的进行改进。

我们都知道,代码重构是在不改变代码行为的基础上,改变其内部的结构。通过一系列小的步骤进行重新构造,系统不会因为这些小步骤的改变而停止运转, 仍然会保持顺利正常的运行。重构的结果是一套良好可读的代码,它不仅能够对我们扩展功能有帮助,也是我们适应变化的基本手段之一。

我们将其类比到界面的开发过程中:我们需要在不改变界面功能的情况下,通过一系列细小的步骤,来改变界面的交互行为和可用性。最终结果,不仅仅是一套良好的界面,也是保证我们扩展新的功能和适应变化的基础。

重构的一个要点是测试。测试可以保证重构的正确。而界面开发的过程中,测试工具的缺乏导致我们不得不采用其他的方式来保证功能的正确。一种可行的办 法是维护一个界面原型,纸质或电子形式均可。在不停地开发过程中,不断的维护这个原型,使之先于实际实现被用户感知和体验,提前获得用户的反馈和客户的认 可,并将原型用于指导团队的开发。这种不断的用户体验和用户测试过程,可以在一定程度上保证界面重构的正确性。BA阐述需求或QA进行验收测试的时候,也 不妨考虑使用界面原型作为一个验收条件来展现给开发者。

重构的另一个要点是要经常不断的进行,每当写新代码之前,先进行一点重构,使旧的代码更好阅读。界面重构也应该是这样。对每一个开发完成的需求,提 高界面验收的标准。不仅仅是完成功能就可以,还需要达到一定程度的可用性和可维护性要求。例如必须遵循提前制定的UI Guideline等等。避免因为界面开发的涣散导致的破窗户,这种疏于整理的小细节可能最终成为最头疼的问题。

比如,我们在开发的过程中,以前只以60分作为界面的验收标准,等积累一段时间后再批量修改界面一次,但可能这次修改只能达到80分。现在我们需要 改为以80作为验收标准后,在开发的过程中多花点时间来重构一点点,一直保持80的水平。这样如果我们需要进行更大的改进,可能很容易就能改到90或 100分,从而达到我们最终的目标。

由于开发团队的人员多数不太擅长界面的知识,并且界面的测试和度量工具缺乏所致,界面的持续改进在项目中较难做的很好。这些实践又要求BA或QA能 够有相应的交互设计能力和可用性工程的经验,也限制了其在项目中的实践。但这些确是在一个项目中长期被忽视地方,应当进行一些加强和发展。

总而言之,敏捷过程和界面设计并不是矛盾的,将敏捷的思想应用于界面开发和交互设计的过程中,我们可以获得更多更广泛的想法。

4月23日,和Erik谈 了谈这个想法,他也认同这类做法,但觉得由于目前没有一个显然的Vision,或者说,不像Code Refactoring那样有良好的OO设计准则和可读性在前方可以到达,这样的UI重构的准则不是很明显。原因可能还是由于Developer大多缺乏 这方面的Sense。路还很长。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值