敏捷设计的关键在于处理变化时的快速迭代,而不是在前期花很长时间做需求分析和文档编写。它要求你专注于快速的迭代,由低质量到高质量,并从得到的反馈中改善你的设计。
敏捷设计更加高效的10个方法:
1.避免BUFD–避免前期过度设计。不管在设计、实现、测试之间有多少时间都应该避免过度设计,它会打破你的反馈回路,使你的设计得不到反馈,从而慢慢陷入危险中。所以你只需要“刚刚足够的设计”,这样就有时间来测试什么行,什么不行,并作出相应的反应。
2.避免YAGNI–你不会需要它. 就尽量避免掉。于此同时也要避免范围蔓延 “保持系统的整洁,你认为稍后会使用的东西其实只有10%才会用到,这就浪费了90%的时间” – Extreme Programming.org
3.尽量简化和简洁(Keep It Simple Stupid)。从长远看使用最简单的解决方案无疑是比较好的方法. 它会帮助你在前期跟上不断变化的需求。
4.“测试第一”–如果你不知道好看的标准,完成它就比较艰难了. 如果你清楚实际测试的是什么,你就不会在设计中迷失方向。一个小而有用的测试在各种各种设计帮助会很大。
5.提供迭代和增量的解决方案–迭代方案就像装饰客厅,增量方案就像增加房子的门廊。有效的迭代能够从反馈中改善你的设计。
6.使用替代方案–快速失败常常失败,这是能够做到快速原型和由低到高质量原型的一个很好的方法。 通过替代方案来找到满意的解决方案。做A / B测试。并创建3个替代方案。不要视图寻找“最好的解决方案。”在许多情况下,你最好的解决方案也只能是“满意”,替代方案会让你应对新的需求。
7.跟用户保持联系–跟那些使用你做的东西的人保持联系. 而不是忽视他们。
8.着眼于全局–先解决全局问题,而不是那些细节
9.及早的获得反馈–这些反馈有助于改善你的设计
10.尽早及经常Spike–使用技术Spike,功能的Spike,用户体验的Spike 来解除风险
最不适宜的事情,就是把一个方案抛过需求的墙(没有人想这样),或者你错过了最基本的场景。这是为什么尽早发布会帮助免除风险,并且帮助验证你的途径。
如果你曾经观察到人们争论如何“满足需求”,却没有人想使用它的话,你会确切的明白我的意思。人们并不总是确切清楚他们想要的是什么,或者,甚至他们想做的是什么,某种意义上,你很难说清楚让每个人都明白。但是人们对有些事要好一些,如识别出来什么才是他们喜欢的,并且在他们实际使用的时候知道他们是否喜欢一些东西。
拥抱它。
这就是敏捷设计所做的——它包含了人们长期以来对什么才是好的设计变得越来越清晰这样一个现实。
建立一个早期的反馈回路也会强迫你保持你的解决方案简单好维护,并且很容易的演进。不然的话,加固你的设计,并对浮现的需求不再响应,这是非常容易的。持久设计的关键在于它们是响应变化的。
这是一个不断学习与持续交付的过程。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
DevOps和敏捷相结合 改进软件质量
DevOps实际上是打破了开发人员和运维人员之间的壁垒。在运维团队,你所考虑的方面可能与开发团队不同。但如果我们能更加了解相互的工作,将会更为深入得理解所需的工具和设备。
-
协作对敏捷方法的重要性
协作的意思说是一起工作,而不是单独去完成某项任务。敏捷方法强调了与跨功能团队合作的好处,大大加强了业务负责人之间的沟通。
-
敏捷扩展的九条原则
对于敏捷扩展,并没有按部就班的方法,但有了固定的原则,软件开发团队将会有据可依地创建高质量的企业软件。
-
敏捷式 vs. 瀑布式:软件需求最佳方式
确定软件需求很困难。很好地理解客户需求,在改变发生时维护文档和需求都不是容易的事情。