agile development 之 scrum

所谓的 agile development(敏捷开发方法)是许多“轻量级软件开发模型”的统称,这是相对于重量级的,例如 waterfall 开发模型而言的。

Waterfall 开发模型

waterfall 开发模型是一个顺序开发模型,经历需求分析、设计、实现、验证和维护这么几个阶段,每个阶段达到的目标都非常明确。这个模型来自于建筑业、手工业。该方法看起来似乎没啥大的问题,但是其灵活性不够:如果用户的需求是随时间变化的,那么今年做的需求分析等到按照瀑布模型的流程走完可能已经到了半年甚至一年以后,那时候的需求已经与现在的完全两样,结果可能许多工作必须重新实施。

Agile Software Development

敏捷开发模型最早是 2001 年发起的,包含有很多种能够快速适应市场需求的软件开发流程,我们这里主要讨论现在不少公司流行的 scrum

Scrum

scrum 差不多也是 2001 年间成型的,其流程大致如上图所示包含四个 artifact,

  • product backlog 是一个产品特性集合,几乎所有人都可以向里面添加,每个 item 对应一个 user story,这可能是某个比较 high level 的东西,比如实现这个东西可能需要大量 FE/BE 的协同工作,很多时候每个 story 可能还伴随有一定的点数(开发者就像在玩 RPG 一样…)
  • 在每个 sprint 开始前(sprint planning meeting),都会从 product backlog 里面选出 development team 觉得可能完成的优先级最高的一些 story,放在所谓的 sprint backlog 中,sprint 结束后(sprint review meeting),也会将一些没有能解决掉的放回 product backlog;
  • 一个 sprint 一般长度是 1 周到 4 周,但是一般给定 scrum 这个长度是固定的,一个 sprint 里面之前有 planning meeting,每天有 daily scrum,之后有 review meeting 和 retrospective meeting;
  • 解决掉的一般就会进入 working increment 里面

参与 scrum 的角色有 pig(core role)和 chicken(ancillary role),pig 包括

  • product owner 是代表 customer,其主要任务是确保项目能够为客户带来价值,他们是主要“维护” product backlog 的人(即他们可以贡献内容,但是更重要的是决定哪个 story 更重要),一般最好不要让 scrum master 与之是一个人担当;
  • development team,这个不必多说,主要是执行任务的人,往往是各个功能性的人员都有;
  • scrum master 是扫清阻碍 sprint 的事物(包括要求 resource、解决疑难问题等等)使之能够顺利进行的人。
  • burndown,指任务完成的表。

chicken 包括那些不是长期对此 project 有贡献的人,如客户、经理等。

scrum 的会议前面也提到过一些,如 daily scrum:

  • 时间短(15min)
  • 参与人员多
  • 搞定三个问题:你昨天做了什么;你今天准备做什么;有没有阻碍进展的事情;

story time,这一般是一个 brain storming 的过程,时间不易超过一小时,进行相对自由,主要是为 product backlog 提供新的元素,常见于 project 开始前或者某些转折点。

scrum of scrum,如果 dev team 组成分成几个部分(如 FE/BE/QA),那么这个一般是在 daily scrum 之后解决 cross team 的问题,如整合、协调等,一般只需要相关人员参加。不大正规的话我觉得可以弄成 on demand 的。

sprint planning,一般主要是选择需要干啥(product own 的半场),(后面是 dev team 的半场)怎么样 decompose 任务,,谁来做,需要多少时间,准备 sprint backlog。这个时间一般比较长。

sprint review,看看什么干了,什么没干,如果某个 story 完成进行 demo。这个时间可能相对较短。

sprint retrospective,主要是“思过”,什么做得好,什么做的不好,这个 sprint 流程有没有问题。一般一开始可能需要这个会,随着 team member 的熟悉,这个应该可以缩短时间或者取消。

题外话

从管理者的角度,软件开发模型之所以重要是因为从“工程”的角度来说,我们需要对某些进度有明确的估计与预期,这样对获得的 business 上的收益才可能有 justify 的材料。因此好的模型一方面需要能够最大程度的把参与者的能力、精力发挥到现有项目中去,一方面也会给管理者明确的进展分析。但是我个人的感觉还有一点,现在这些模型不是太关注的是“人性”:模型往往是机械的,比如什么时候开会、每天需要解决什么问题、走通 sprint 流程,每一个都是条条框框。参与其中的人很容易感到“机械性”完成一个一个的任务,尽管像 daily scrum 里面我们是可以有一定的 interaction,但是这种 interaction 很容易变成肤浅的、形式上的任务。同时由于 peer pressure,参与者如果实力相差较大也很可能在一段时间里感到挫折和尴尬。个人感觉,很多问题并不是“循规蹈矩”就能发挥人的最大的潜能。换言之,软件开发模型只是“管理者的一种愿景”。

还有一个比较有意思的问题是 scientific research 可不可以通过 scrum 来做。很多公司的 engineering 团队都会使用某种 development model,那对应的 research 机构是否也应该采用某种模型来进行管理呢?就我看到的情况,似乎都是没有采用的。那么是否就不能 run scrum?我个人觉得可以,但是“开发模型”只是对管理者有意义,对 researcher 往往价值不大。怎么说,一个 scrum 或者别的什么模型的核心是“如何将一个具体的问题拆分成为可以管理的部件”,像 scrum 会有 product backlog 里面收集各种 user story,然后每次取一些放到 sprint backlog 里面,供 development team 进一步分拆变成一个一个的 task(通过 ticket 的形式分发到每个人)。scrum 的好处是由于周期短,可以随时把一些细粒度的需求加入到 product backlog 从而在 re-prioritize 的时候反应到下一开发周期里面。那么好了,一个 research problem 很自然也能分解成为很多个小部分,比如分析数据本身有些什么样的特性,猜测什么样的模型可能是合适的,实现一些模型进行比较实验,对现有模型进行修正,调节参数… 那么很自然我们也可以把这些写成一个一个的 story,然后 decompose 成为一个一个的 task。如果出现了新的问题,我们也能很快的加入 backlog 里面… 所以说要 run scrum 是 OK 的。但是对研究人员来说,往往并没有实际的意义:第一做过研究的人一般有一定的策略来解决一个未知的问题,但是却不能很好的估计每个 task 解决的时间(往往一个 task 到实际做的时候会展开变成很多 task 甚至新的 research problem);第二尽管研究人员可能互相之间能够 share 一定的结果,那往往是在实验结束以后,也就是非常后期的阶段,过早的讨论有时非但不能帮助研究人员继续手头的工作,还可能被一些别的思维诱导偏离原先的问题或者被其他人的第一眼感觉所欺骗,也就是说我挖一个坑,你也在挖一个坑,我什么都没挖到的时候跟你说什么都很没意义,兴许说着说着我就跑去挖你的坑了,只有要么我挖到什么东西了(嗯这个方法好用),或者挖到硬硬的岩石动弹不了的时候(这个问题似乎是 NP hard…)我跟你谈,才有一定的价值。

最后一个问题是 agile development model 用上之后,是不是真的就能 agile 呢?我觉得不是,就算是软件开发,能够实现某种程度 agility 的基础还有很多别的因素:一个就是 infrastructure,这个的一个基本表现就是所选择的“工具”与“问题”本身匹配程度,新手比较容易倾向选择自己熟悉的工具,因为上手快,高手感觉能找到“合适”的工具,所谓合适指不仅仅能够解决当前问题,还能够游刃有余,即问题变得复杂的时候仍然能够通过这个工具 scalable 的解决新的问题;另一个就是 design pattern 或者我们说更加直白一点 interface 是否足够的 powerful 和 flexible,说 design pattern 的意思某些实际问题求解的思路其实历史上曾有人考虑过了,如何设计这些东西交互的方式才能实现一些软件工程的特性,很多时候新手也知道这些名词,但是高手却能轻松的将这些 pattern 用在实际问题中。这两点或多或少都有人的因素,模型是死的,如果用的人不够灵活,开发仍然不是 agile 的。个人感觉,这两点上我仍然是新手,相关经历太少,也没有一个学习的机缘。

——————
And he said to him, Oh let not the LORD be angry, and I will speak: Peradventure there shall thirty be found there. And he said, I will not do it, if I find thirty there.

Advertisements
agile development 之 scrum

一个有关“agile development 之 scrum”的想法

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s