用例之父称敏捷需要更加明智

  • Shane Hastie
  • 李剑

2009 年 4 月 12 日

话题:敏捷方法论架构文化 & 方法

在上周举行的Software Education SDC大会上,Ivar Jacobson——用例、UML 和 RUP 的作者——说道,敏捷开发需要“明智”。

他提到,信息技术行业是比较容易追求时尚的,而且总想去发现银弹。他举出了下面的例子:

  • 十五年前,大家全都在谈 OO
  • 十年前,就都变成了组件、UML、统一过程
  • 五年前是 RUP 和 CMMI
  • 两年前是 XP
  • 今天是 Scrum

这些都有好的地方——但无一是我们所需,我们需要的是更加明智的工作过。他说,“明智是敏捷的进化”。

  • 敏捷意味着灵活和适应
  • 敏捷提供了简单、轻量级的出发点
  • 明智意味着知道什么时候超越敏捷
    • 知道什么时候服从规则,什么时候打破规则
    • 知道什么时候按老样子做事,什么时候做出革新
    • 知道什么时候增长,什么时候退缩

按照 Jacobson 的话说,“明智就是敏捷 ++” 。他接着给出了一些明智(和不明智)实践和过程的例子,这些都是他在过往这些年里发现的。其中包括:

  • 人(不明智)——把过程和工具看的比人更重要
  • 人(明智) ——理解软件是人构造的,而不是过程和工具!



    “有工具的蠢货依然是
    蠢货,但是是更危险的蠢货!”
  • 团队(不明智) ——把团队做职责分离(需求、分析、设计等),分成烟囱管一样的小组
  • 团队(明智) ——跨功能的小型(一般是 10 个人,或者更少)自组织团队,拥有混合技能,可以承担工作。



    “软件团队就像运动队,拥有一切所需的能力去赢得成功”

  • 项目(不明智——试着遵守瀑布流程
  • 项目(明智——先做一个“皮包骨的系统”起来,证明你已经排除了所有核心风险,然后再在需要的时候往这个皮包骨的系统上加肉。



    “做远景思考,分步实施”

  • 需求(不明智)——想着一开始就把所有需求都定义出来(软件开发中有一点是不变的,那就是需求总是会变)
  • 需求(明智)——在轻量级的需求上做先期决策,在需要的时候再增加细节——需求是可以协商的,优先级是可以变化的。

    “在设计项目时考虑到需求变化”

  • 架构(不明智)——预先把所有设计都做好,没有比这更糟糕的架构了。
  • 架构(明智 ——架构够用就好,架构必须来自于可以执行的代码。

    “先把皮包骨的系统弄起来,一步步添肉”

  • 测试(不明智——把人分成两种,一种是开发,一种是测试。不明智的测试就是“软件世界中的清洁工”——给开发收拾残局。、
  • 测试(明智 ——整个团队都为质量负责,测试也是一等公民。

    “不管你做什么,在验证你确实做了想做的事情之前,这事情就没算做完”

  • 文档(不明智 ——机械式的填写文档模板,只是因为一些过程规则是这样规定的。
  • 文档(明智——了解“自然规律:人们不读文档”。只在必须的时候才写文档。

    “关注最根本的东西——给谈话占个位子——人们会自己找出剩余的部分”

  • 过程(不明智——不断追逐最新时尚,要求你按照最新的规则手册把一切重写。
  • 过程(明智 ——不要把孩子直接扔到浴缸里:

    1. 先从现有的工作方式开始



    2. 找出问题所在

    3. 每次只改一个实践

    “人们不读过程方面的书,所以还是只做最关键的部分,其他方面大家会自己做好的。”

明智的关键因素还是关注人,正如 Jacobson 所说,“这终归还是你的事”。

查看英文原文Father of Use Cases Says Agile Needs to Get Smarter

敏捷方法论架构文化 & 方法