敏捷能给团队带来什么,不能带来什么

先谈谈需求。

采用敏捷方法的团队,更有可能准确地用软件帮助客户实现脑子里的想法。然 而,除非团队有能力在某一需求领域内给予客户超出其自身现有经验的建议,否 则最终的软件产品不太可能会实现超出客户当前已经识别出来的需求的价值。

敏捷方法主张快速反馈和积极的客户协作。通过客户的积极参与、和团队的面对 面沟通,团队在软件生产周期的各个阶段(分析、开发、测试、验收等)以尽可能 高的频率获得客户的反馈,并迅速调整,使得生产的软件符合客户的期望。例如 在前期需求分析的时候借助UX的wireframe等工具,将大家脑子里的东西尽可能地 可视化展现出来,以达成准确的共识;在开发阶段,也会不断和客户确认需求的 细节,同时会在一部分功能实现后就迅速寻求客户的反馈。这一切活动都保证了 敏捷团队能够更快地和客户达成需求上的准确的共识,同时以尽可能少的返工和 误差实现客户的需求。

然而这些手段的最大效果,是帮助团队准确高效地实现了客户脑子里的想法。当 然,敏捷所帮助团队实现的更高频率的交付,也能够让客户有机会更快收集到最 终用户的反馈,有机会更快地验证他们最初想法的好坏,如果客户有意愿并且有 能力在这些反馈的基础上做出尽快调整,那么从某种程度上讲,敏捷确实能给客 户带来更高的价值。但是如果客户并不具备这个能力,或者忽略了从最终使用者 的快速反馈带来的好处,那么最终交付的软件也只能实现客户已知的价值。对于 那些对自己的行业和业务非常了解的客户来说,这一目的的达成对他们已经具有 无上价值了,然而如果客户脑中的需求本身就不先进,甚至是陈腐的,他们也许 会最终发现敏捷并不能帮助实现自身认识和现有业务的质的飞跃。

虽然在这个过程中,UX方面的一系列手段帮助我们实现了更好的交互体验(并且很 多技术如mental model似乎还能够帮助我们挖掘出更多最终使用者实际需要的东 西),然而这些也并不是敏捷包含的内容。

在这里我们区分这三种能力:运用敏捷方法交付软件的能力、UX方面的能力、在 某一具体的行业或者业务领域(例如保险、电力、互联网)拥有领先的经验和知 识并能够对这方面的软件提供建议的能力,有这样几个意义:

  • 帮助我们更好地分辨问题出在哪方面。缺什么补什么,不要乱补。
  • 理解清楚敏捷能够给你带来什么,不能带来什么,破除银弹式思维。
  • 如果你现在是作为咨询师的角色帮助团队引入敏捷方法,那么准确识别出当前 团队的问题所在,和团队达成共识,有助于改进的进行。如果团队在业务理解 方面是有欠缺的,那么团队必须知道这一点,不能以为敏捷了以后项目就一定 会成功了。即便咨询师在业务领域、UX、敏捷方法都有丰富经验,能够同时提 供这些方面的建议,也最好对各方面的改进内容有清晰认识。还是回到第一 点,团队必须对自己缺什么,接下来要改进什么有清楚的认识。

再谈谈技术。

敏捷方法在技术实践上倡导重构、演进式设计、重视代码内部质量(干净代码、 没有坏味道)、自动化测试、TDD、持续集成(包括自动化构建、乐观锁SCM工具),最 终获得高质量的代码,降低人工测试的成本,让软件在后期也具备以小成本实现 需求变化的能力。

一个团队如果想熟练应用上述实践,首先得具备这样一些能力和条件。必须懂得 高质量的代码不仅仅意味着没有bug,还得没有坏味道;良好的架构必须是具备可 测试性的,不然TDD和自动化测试难以实现。这也就是说,团队可能会需要提升自 身技术能力,能够识别坏味道,并进行重构;能够理解并运用一些简单设计、OO 设计的原则;要熟悉所用语言的最佳实践;要让自己的软件具备可测试性。具备 了这些基础,团队就可以准备好渐渐享受全面的自动化测试覆盖、频繁地集成验 证、干净的代码架构所带来的好处了。

如果说引入敏捷的好处是让团队具备了上述的这些能力,获得了这些敏捷的好 处,那么我们也可以看出,为了享受到敏捷的这些好处而进行的必要程度的能力 提升,不一定能够保证让团队变得有能力解决好所有架构设计方面的问题。

举几个例子。一个团队自己写了一个url解析和dispatch工具,质量良好,测 试全面,没有坏味道。但是实际上已经有一个不错的开源库存在了,团队因为信 息闭塞,所以不知道这个库的存在;你可能REST风格的web service比soap更好 用,但是团队采用soap web service也写出了质量高、测试覆盖全面的代码;你 认为类似于rails中的ActiveRecord的数据库访问封装方式比hibernate式的封装 更好,但是人家用hibernate式的ORM工具也能够写出质量高、测试全面的软件。

举这些例子都是为了说明,作出良好的架构设计所需要的能力和经验,比顺利应 用敏捷技术实践所需要的设计编码能力和经验要多。这些能力需要长时间的不断 学习、实践来积累,同时还必须对新的技术发展保持敏锐。TDD在某种程度上对 于促成良好的局部设计有作用,然而也不足以驱动我们解决全部的架构和设计问 题。

和前面需求部分的分析一样,之所以我们区分团队引入敏捷所需要具备的技术能 力和做出良好架构设计所需要的能力,我认为有这么几个意义:

  • 敏捷对技术能力有要求,但并没有那么高的要求,你不需要具备软家大师的 能力才能享受到这些敏捷技术实践带来的好处。
  • 也不要认为敏捷能够帮你解决所有软件架构和设计上的问题。团队里必须有 有经验的人来帮助把握技术架构的选择、语言框架的选用等等。

- Previous post: 日知其所无,月无忘所能
+ Next post: 持续交付笔记


blog comments powered by Disqus