Hegel2011的博客

读书 - 工作 - 生活 - 笔记

Learning Agile: 理解Scrum, XP, Lean and Kanban

初次接触敏捷的概念是很早的事情了,可能始自于Uncle Bob的那本ASD。 其后,因为一直以来认为的软件开发很多事情在做之前其实很多是不确定的,因此日常的开发中虽然没有采用站会之类的形势,也没有单独的产品经理, 但实际上是按照敏捷的精神在进行开发。这些精神包括:

  • 个体和互动高于流程和工具(不过我认为工具十分重要)
  • 可工作的软件高于详尽的文档
  • 客户协作高于合同谈判
  • 响应变化高于遵循计划

这些都是在多年开发实践中所坚持的原则。但是,一直以来忽略了其中最重要的一点:人。

因为之前工作的单位,从客户、领导到同事、下属都是合作多年,彼此也知道对方的能力以及可以信赖的程度,所以敏捷的精神得以贯彻。 然而在两年前去到新环境后,身边合作人员的水平较以往参差不齐的多,主要是上游的产品、BA等怎么合作都没有及时地确立或调整出新的办法, 导致敏捷的原则压根没法贯彻。
直到大约一年半以前,才发现敏捷的形式(实践)其实已较为普及。今年在新单位,有专职的敏捷教练和产品经理,在一年的实践中,体会了不少敏捷的好处,但也 发现了不少问题,尤其是随着时间的流逝敏捷实施似乎越来越难了。而问题依然很类似:

  1. 人员水平参差不齐,其实不是每个人都知道怎么配合
  2. 上游虽然有产品经理,但公司还会安排其他人来提需求,但很可能完全不懂软件开发,导致沟通合作困难

所以,下决心利用假期好好弄明白当前的敏捷到底指什么,然后再看看怎么结合现在面临的情况进行调整。

简单的说,一般的敏捷方式和Scrum是同义词,而XP(极限编程)是软件开发中的一种敏捷模式,Scrum则更偏向项目管理以及集体协作方面。 至于Lean,则只是一种思想,没有具体的形式,Kanban也是来自于日本汽车制造商,其核心作用是找出整个流程中的瓶颈。

与Scrum对应的是上令下行的管理方法,这种方法下需要较完善的需求规格(极难),较强的PM规划设计(很可能是瞎计划)和计划重构能力, 而Scrum则要求团队的主人翁精神(也很难)。但本质上,Scrum把决策和风险都放给了整个团队,基于软件开发很多只有事到临头对着代码 才能明确什么方法最好,因此这种下放或者说要求一线成员能力更大、承担更多责任和决策的模式是有其道理的。整个团队中,开发、产品、PM都能拥有平等的发言权。

Scrum

在项目开始时,只是确定要做的任务(用户故事)有哪些,也会拆分任务,但不一定要完成所有任务的分配。即要有任务清单,但不全部确定计划完成者。 细节在例会后讨论,每天例会可以由不同的人轮流讲3个问题:

  1. 我昨天干了什么?
  2. 我将要干什么?
  3. 我遇到了什么困难?

本质上是让团队成为项目的主人,齐心协力去寻找更有效的工作方式,找到了整个团队就一起成长了。而告诉团队工作成果的价值要好于告诉团度业务收入的价值,对团队而言, 有价值的是软件能带来什么?让用户生活更美好是一种真实、真诚、鼓舞人心的目标。 自我管理集体承诺是Scrum的魂(精神),要求每个人都成为猪而不是鸡,每日例会和积压工作表是Scrum的形式(实践)。产品所有者是Scrum的产物,但实际上也 很难区分和传统的业务分析人员的区别。

Scrum用到的概念还包括用户故事,满意条件,故事点和速度
燃尽图表示随着时间的流逝,还剩多少任务。

Scrum的价值观:

  • 承诺
  • 尊重
  • 专注
  • 开放
  • 勇气

极限编程(XP)

极限编程强调结对以及测试驱动,一切的目的是为了方便自动化测试,比如避免过深的调用栈。着力于消灭代码异味。
有时候过多的边界情况考虑和处理也是过度设计,是某种框架陷阱误区。

作者还提到了反模式的概念。 所谓反模式就是会给项目带来麻烦和问题的行为模式,比如解决某人只有95%的时间在干活,喜欢称人为资源。

代码异味和反模式都是人制造出来的,又是人识别出来的,并且可以由人来防止或修正。所以解决方案一定是技术和团队两方面一起努力。

然而,测量什么就会得到什么。瀑布式开发的目标也不是文档,但最终会得到很多文档,可运行的软件反而变成了副产品。TDD的目标也不是文档或测试,但最终得到了很多测试,可运行的软件本身反而也成了副产品。

精益

精益针对的反模式就是浪费,目标就是减少浪费。包括无用的功能和形式。同时提到了工作进度面积图,这种图的作用可以反应当前处于各个状态的任务数量及比例。其表示状态的词汇如下:

  • Muda 徒劳无益
  • Mura 不均衡
  • Muri 不合理或不可能

衡量是否精益的一大指标是从需求提出到上线发布的间隔时长,即交付时间,这里是借用了丰田生产汽车的概念。强调0或者低库存。

日常项目中容易遇到两个反精益的模式:

  • 老板的神奇思维(Magic thinking):只要我想要,只要我施压,团队就一定会做出来。
  • 英雄员工:十分肯加班加点的员工

敏捷是无法同上面两个共存的。

神奇思维和英雄员工制造的最大问题是会导致软件产品的质量和测试都很差,最终开发速度会变的慢上2倍以上。因为欠的债太多最终都会变成成本。

Kanban

看板可以让经理不再动不动就分配新功能。比任务处理的内容要更“大”一些。看板中的每个栏目表示工作流程中的容器,是一种分析问题出在哪个环节的可视化分析方法。

Shuhari,借用武学概念,守破离。

  • 守:按套路来
  • 破:打破套路
  • 离:自成一派

小结: 确实如一个十分能干的小朋友曾经跟我交流的,中国的企业没有真正实行敏捷开发的。其实敏捷本身和中国大部分软件企业的文化并不兼容,因此大部分只是具备了敏捷的一些实践,而没有敏捷真正的灵魂。至于我司到底是否能敏捷起来,也只能把决策留到最后再说了。