敏捷团队工作流

标签: dev | 发表时间:2017-09-20 00:00 | 作者:
分享到:
出处:http://itindex.net/relian

站会

站会中的内容是每天工作的开始,也是对昨天工作的回顾。一般会由团队的某位成员主持,这位主持人有责任让电子系统上的story卡片和看板上的保持一致。站会上,大家依看板从右至左依次更新自己负责story的状态,如果遇到阻碍,应该在站会上及时提出,团队之中的成员如果能提供帮助,应该在站会之后,组织解决方案的讨论。

站会反模式

  1. 站会上由组长一人发言、分配任务;
  2. 一人长篇阔论占据大半时间(合理的发言时间为1-2分钟,总的时间控制在15分钟左右);
  3. 站会上谈论和story卡片无关的内容。

迭代计划会议 (IPM)

迭代计划会议是项目组成员在每一个迭代开始时,聚到一起共同决定这个迭代的 backlog (代办事项) 需要交付的故事卡。
这个会议的产出物包含:

  1. 迭代的 backlog 和用户故事的验收条件
  2. 这个迭代的总体业务目标
  3. 故事点数,也即开发测试人员对用户故事的评估及承诺

参与者包含:

  1. Product Owner
  2. Scrum Master
  3. 开发团队
  4. 其他干系人

日程:

  1. 团队确立这个迭代可以完成的工作量(以点数计),一般从历史迭代中获取
  2. 团队根据定义的顺序讨论故事卡,对于每一张故事卡,需要讨论的内容包含:
    1. 衡量故事的相对大小(以点数计),可能会进行故事卡的拆分
    2. 沟通验收条件
    3. 根据已经讨论出来故事卡的价值、时间和风险,PO重新确定故事卡的优先级
    4. 一旦预先设定的工作量到达,就停止本轮迭代会议
  3. 团队就迭代的业务目标达成共识

用户故事 kickoff 会议

Story kick off,指的是启动一个 Stroy 进入开发阶段。Story kick off的时候,通常需要三种角色参与:BA、QA 以及开发 Story 的 Dev。

会议内容:

  • DEV 自己先完整地过一遍 Story 的描述;
  • DEV 给 BA 和 QA 去讲这个 Story 的功能以及 AC;
  • 要能够清晰的讲出来,并且三者达成一致,如果有疑惑,需要当场得到解决;
  • DEV 开始开发 Story,并自行将 Story 拆分成多个子任务列表,开工。

我在ThoughtWorks中的敏捷实践

Desk Check / Shoulder Check

Desk Check 发生在开发人员确信自己已经完成了故事卡,需要另外的人(BA、QA、Dev)坐到旁边一起帮忙验证是否确实完成。

Desk checklist:
参与者:BA、QA、Dev 或者其他感兴趣的人

  • 故事卡测试覆盖率够吗?
  • 自己本地测过功能么?
  • 自己本地跑过全量的测试么?
  • 所有的 AC 是否都满足了?
  • 做故事卡的过程中是否遇到了理解上的问题?

Defect Prevention Using Agile Techniques

Tech Huddle

开发人员聚到一起就项目中遇到的技术展开讨论
前提条件:
会议之前确定并逐条列出会议讨论的技术主题
产出物:

  1. 一个或多个行动方案,合并到用户故事
  2. 方案的优缺点
  3. 方案的责任人

迭代回顾会议

在每个迭代结束时,Scrum Master会主持该会议,目的是为了确定哪些改变可以提升下个迭代的生产效率。在这个会议当中,每个人都可以开诚布公地提出自己的建议,有利于管理者从反馈中获取团队的现状。

最高指导原则 (Prime Directive):

Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.
无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及手上的状况,我们理解并坚信:每个人对自己的工作都已全力以赴。

内容包含:

  • 上个迭代中做的好的有哪些?
  • 上个迭代中做的不好的有哪些?
  • 我们可以做些什么改善哪些不好的地方?(改善建议)

参与者包含:

  1. Product Owner
  2. Scrum Master
  3. 开发团队
  4. 其他干系人

高效回顾会议的七步议程

迭代review会议 (Showcase)

Showcase 就是开发团队把开发好的功能给客户的 Product Owner(以下简称PO)等业务相关人员演示,以获取他们对所开发系统的反馈,是敏捷开发流程中的一个实践,一般的频率是一个迭代一次,也可以根据项目具体情况做调整。

内容包含:

敏捷实践Showcase的七宗罪
Retro 破冰游戏

用户故事

故事基础

用户故事是指在软件开发和项目管理中用日常语言或商务用语写成的句子。这个句子反映一个用户在其工作职责的范围内要达到的某个目的, 以及此目的所需要的功能。

例子

为了避免遗漏附件延误工作
作为邮件发送者
我希望邮件系统能够在我忘记带附件的时候提醒我

格式

      
1
2
      
为了<某个目的或价值>, 作为<某类利益相关者>, 我想要<某个功能>
作为<某类利益相关者>, 我想要<某个功能>, 以便<达到某个目的或获得某种价值>

要点

重点描述商业的价值不只是功能

  • 帮助团队了解需求背后的意图,利于开发团队协同客户、业务部门设计出更好的解决方案

用业务语言描述

  • 利于客户、业务部门理解并区分优先级

利益相关者不仅包含用户

  • 系统拥有者的角度也是需求的重要来源

CCC 组件 (The three ‘C’s)

Card (卡片)

  • 业务价值 remainder
  • 做计划和沟通业务时的 token

Conversation (交流)

  • 用于在做计划和沟通业务时引发沟通,制造共同话题(收敛)
  • 需求文档的生成方式

Confirmation (确认)

  • 将细节以验收测试的方式检测功能的完整性和准确性

划分原则 INVEST

Independent (独立性)

故事和故事之间尽量保持独立,互相依赖的故事对于估算工作量、确定优先级和安排计划都带来很多不便。通常我们可以通过组合和拆分的方式减少依赖性(去除重复)。
独立性更多的指的是实现要完整。前后端拆分通常不是很好的拆分方法

Negotiated (可协商的)

一个故事是可以协商的,故事卡不是合同,它只是包含对一个需求的简短描述。具体的细节在沟通阶段产出,以验收测试的方式。如果带有太多的细节,反而限制了和用户的沟通。

Valuable (有价值的)

每个故事都必须对客户有价值(无论是用户还是客户)。一个让用户故事有价值的好办法就是客户写下它们。

Estimable (可评估的)

开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。如果难以估计故事的时间, 意味着:

  • 领域知识的缺乏: 这种情况下需要更多的沟通
  • 技术实现的模糊: 这种情况下要做试验, 做原型
  • 或者故事太大了: 这时需要把故事切分成小些的
  • 还有对其它团队的依赖…

Small (短小的)

一个好的故事在工作量上应该是尽量短小的,至少确保能在一个迭代或 Sprint 中能够完成。用户故事越大,在估算、计划安排等方面的风险就越大。

Testable (可测试的)

一个用户的故事必须是可被测试的,以便它是可以完成的。如果一个故事无法测试,那么就无法知道它何时可以完成。一个不可测试的例子:为了节省时间,作为用户,我希望软件是易用的。

判断标准 (经验准则)

  • 可以写在 Release Notes 里
  • 值得讲给其它行业的人听
  • 可以写在市场宣传材料中

验收条件

捕获预期的行为

一般验收条件都会在开发之前准备好,用于捕获预期的系统行为,同时作为故事卡业务描述的一部分,定义了故事卡的 DoD(Definition of Done)。

格式

  • Given前置条件,告诉我们在进行操作之前,需要设置和完成什么;
  • When触发结果的操作
  • Then操作之后的预期结果

最佳实践模式

1. 可读的

我们希望业务人员审阅和修正验收条件,如果写的内容只有开发人员能懂,我们就失去了获得反馈的机会。使用上述书写格式,可以提高可读性。

       
1
2
3
4
5
6
7
8
9
       
Given:thatmymobile phoneisswitchedon
And: I have sufficient signaltomake a call
When: I dial anumber
Then: I am connectedtotheperson I wanttotalkto
And: incoming calls are divertedtomyvoicemail

2. 可测试的

反模式1 - 模棱两可的陈述
      
1
2
3
4
5
      
Given: that I have the search page loaded
When: I perform a search
Then:thesearch results come backwithinareasonable periodoftime

这里的 reasonable period of time 就是不可测试的,因为没有人可以决定什么才是 reasonable.

合理的改法是:

       
1
2
3
4
5
       
Given: that I have the search page loaded
When: I perform a search
Then:thesearch results come backwithin5ms

5ms 之内,这是一个标量,完全可以衡量。

反模式2 - 非系统输出
      
1
2
3
4
5
6
7
      
Given: that I am on the home page
And: I am logged in
When: I navigate to account preferences
Then: I can see my account preferences

这里的 I can see my account preferences 是无法进行断言的,因为这是系统无关的,说得极端些,假如用户闭上眼睛,这个功能就没法通过验收了。

合理的改法是:

       
1
2
3
4
5
6
7
       
Given: that I am on the home page
And: I am logged in
When: I navigate to account preferences
Then: my account preferences are displayed

这个时候,我可以检查系统展示了我的用户页面。

反模式3 - when 隐藏到 given
      
1
2
3
4
5
6
7
      
Given: that I am on the homepage
And: I navigate to the search
When: I look at the page
Then: the searchoptionsare displayed

基本上,这是团队编写 AC 时最容易犯的错误,操作出现在前置条件中, when反而不是系统行为了。

合理的改法是:

       
1
2
3
4
5
       
Given: that I am on the homepage
When: I navigate to the search
Then: the searchoptionsare displayed

3. 实现无关的

验收条件应该是实现无关的,它和用户故事一样,是给业务和开发人员提供交流凭证的一种工具,所以它应该聚焦于功能,而不是功能的展现形式。

       
1
2
3
4
5
6
7
8
9
10
11
12
13
       
Given: that I am on the home page
And: I am logged in
When: I navigate to advanced search
Then: the advanced search web page must be displayed
And:atext box labelled"Name"is displayed
And:atext box labelled"Description"is displayed
And:acommandbuttonnamed"Search"is displayed

这里已经框死了必须要使用 text box 实现展示功能,而实际上其背后真正的意图是通过属性字段进行搜索,隐藏了业务含义的验收条件是不可取的。

合理的改法是:

       
1
2
3
4
5
6
7
8
9
10
11
12
13
       
Given: that I am on the home page
And: I am logged in
When: I navigate to advanced search
Then: the advanced search is displayed
And: anoptiontosearchbynameisdisplayed
And: anoptionsearchbydescriptionisdisplayed
And: the advanced searchisdisplayedinaccordancewiththe attached wireframe

换句话说,验收条件本身不应该关注于展现形式,当然,为了便于理解,wireframe 是提供直观素材的更好的方式。

代码评审

代码评审是团队针对今天一天 提交过的代码的评审会议。这样做的目的是去除代码的坏味道,减少累积的技术债。

团队成员使用版本控制工具,轮流展示自己一天的编码成果并且说明代码的用途。这期间,其他的成员不仅要评审代码的逻辑是否正确(满足验收条件),还必须思考是否有更优雅的方式实现这段功能。大家可以随意表达自己对这些代码的好恶,代码所有者也可以据理力争,所有者一旦被说服就必须无条件地按意见修改。为防止遗忘,可以使用便笺纸记录下来。

结对编程

通俗地讲,结对编程就是两个人同时工作在同一个 Story 上,一起讨论 Story 的解决方案,并编写代码实现功能,一个人敲键盘,一个人看屏幕,穿插着进行。Pair的双方在快速敲击键盘的时候会伴随一些交流。能力相当的两人,可以一人写测试,一人写实现代码。

测试驱动开发 (TDD)

TDD,即测试驱动开发,强调的是测试先行,跟我们先实现功能代码后添加测试的过程恰恰相反。测试驱动开发是一种驱动代码实现和设计的过程。我们说要先有测试,再去实现;保证实现功能的前提下,重构代码以达到较好的设计。整个过程就好比演绎推理,测试就是其中的证明步骤,而最终实现的功能则是证明的结果。

实践方法:

  • Given:初始状态或前置条件
  • When:行为发生
  • Then:断言结果

单元测试和测试驱动开发

测试的价值表现在两个方面:

  1. 防止已有的功能被破坏
  2. 驱动出功能实现

从测试金字塔描述的层级来看,单元测试是基座。这类测试数量应该是非常多的,而且还有一个显著特征——运行速度特别快。一般违反快速这个标准的,基本上可以肯定这不是单元测试。

基于以往带团队的经验,我给出一些写单元测试时常犯的错误和好的实践:

常犯的错误

  1. 覆盖率100%,却没有任何断言
  2. 使用Java反射setAccessible(true)访问私有属性
  3. 依赖某些地方产生的数据才能运行
  4. 单元测试运行速度超级慢
  5. 开始测试之前,准备巨量的数据
  6. 测试之间必须以特定顺序运行
  7. 上帝类(God Object)导致数以千行的测试代码

好的实践

  1. 绝对不测试私有的方法
  2. 当方法没有返回值,可以通过测试异常或者其委托对象的方式
            
    1
    2
            
    1. @Test(expected = RuntimeException.class)
    2.Mockito.verify(mockObj).doSomething(args…)

3. 静态方法调用是强耦合的信号。需要重构待测类依赖新接口,新接口定义的方法由子类实现,实现方法中包装这些静态方法。

什么时候写单元测试?

  1. 新的需求,首先写单元测试(保证功能实现)
  2. 已经存在的代码,补充单元测试 (保证功能不被破坏)
  3. 发现Bug,首先加测试(保证缺陷不再出现)

自动化测试

测试金字塔和 DOT(Depth of Test)

持续集成/持续交付

再次强调一下,持续集成是一项团队务必遵守的实践。

开发过程中,我们鼓励小步提交的代码控制方式。即当开发人员对story的部分功能编码完成之后,如果 确认可以提交到代码仓库(如果是分布式的Git,可以考虑提交到本地仓库),应该尽早提交。开发人员的每日工作可以遵循7步提交法,如下:

  1. 更新代码;
  2. 本地编码;
  3. 本地构建(使用 mvn test);
  4. 再次更新代码;
  5. 本地构建;
  6. 提交到代码仓库;
  7. CI上构建。

既然是实践(规矩),就有几项有效的纪律需要遵守:

  • CI红的时候不能提交代码
  • CI红着不能过夜(不能等到第二天才去修复)
  • 任何人提交后CI失败,无论原因,都有责任跟进修复
  • 在提交代码前运行所有测试
  • 不注释掉或删除失败的测试

这也就意味着开发人员需要密切关注CI的状态。CI持续反馈着软件的可工作状态,所以团队应该把CI的健康状况列为项目的最高优先级,甚至高于开发新特性。

相关 [敏捷 团队 工作流] 推荐:

敏捷团队工作流

- - IT瘾-dev
站会中的内容是每天工作的开始,也是对昨天工作的回顾. 一般会由团队的某位成员主持,这位主持人有责任让电子系统上的story卡片和看板上的保持一致. 站会上,大家依看板从右至左依次更新自己负责story的状态,如果遇到阻碍,应该在站会上及时提出,团队之中的成员如果能提供帮助,应该在站会之后,组织解决方案的讨论.

敏捷团队的人员分布

- - InfoQ cn
许多考虑采用敏捷的组织没有把团队迁移到开放式环境就尝试创建项目团队. 敏捷价值和原则中,当团队成员可以随时接触到所有其他团队成员、易于获得所有的项目进度图表、在鼓励交流的环境中时,团队可以更好地工作. 敏捷测试专家Lisa和Janet 分享了敏捷测试团队的人力资源经验. 测试人员和客户与程序员坐在一起可以促进必要的交流.

敏捷项目管理实战之团队自我管理

- 沈蚊 - IBM developerWorks 中国 : 文档库
自我管理是敏捷开发中的重要管理思想,但是鲜有文献提及相关实践. 本文将以笔者的管理实践为基础,探讨自我管理的具体实践.

专家建议:以特性团队扩展敏捷项目

- - InfoQ cn
敏捷实践在由 5到9个人组成的小型团队里面实施得很好. 但是如果客户希望得到更多的软件功能,并且准备好了为之付出更多的钱,又会如何. 你如何能够安全地增长敏捷团队的规模,从而提升生产率. Martin Fowler警告了 未及成熟就增长敏捷团队规模的行为,因为那可能会导致沟通的破坏,而且可能会破坏代码库本身的内聚性.

敏捷团队应对打扰的七种方法

- - InfoQ cn
每个团队都必然会遇到工作被干扰的情况,如果不能合理应对,那么很可能会影响到团队的交付能力. 最近,在 Agile Advice网站上, Mishkin Berteig发表了一篇文章,讲述了当Scrum或者其他一些采用迭代方式的敏捷团队遇到工作被干扰的情况时,可能可以采用的七种应对方法. 承诺速率(Commitment Velocity).

敏捷团队如何设计办公室

- - InfoQ cn
在上周召开的scrumgathering 2012会议上,来自Thoughtworks的胡凯和大家分享了他在设计敏捷团队使用的办公室的经验. 其中很多特点都体现了敏捷的原则,有利于敏捷开发的开展,并且他在设计过程中也应用了敏捷的思维. 胡凯的演讲主题是《设计拥抱敏捷环境的办公室》,在演讲开始之时,他调侃说,自己是敏捷圈里面最懂装修的,也是装修圈里面最懂敏捷的人.

敏捷实施的障碍——缺少凝聚力的团队

- - InfoQ cn
迅思威尔公司的资深敏捷咨询顾问袁斌在微博上提到了Bas Vodde的观点,他认为分离、缺少凝聚力的个人组成的团队是敏捷实施的障碍. 这样的开发团体无法以一个整体团队集体行动,无法开展彼此的结对工作和相互学习. 该观点引发了大家对敏捷团队的讨论. 袁斌_AgileDo发表的微博内容如下:. Bas Vodde认为敏捷实施的一个障碍是:一些团队实际上由许多分离的、缺少凝聚力的个体组成,却伪装成一个团队,表面上实施了 Scrum,心里想的却是" A做A的工作,B做B的工作,等等".

TFS团队的敏捷转变:向三周一个Sprint进军

- - InfoQ cn
Buck Hodges认为,过长的发布周期导致TFS(Team Foundation Server)团队养成了不良的开发习惯,然而光靠生搬硬套sprint来缩短发布周期是不够的,还需要配合其他一些软件计划和软件开发方面的改进. 起初,TFS要好几年才发布一次. 微软的Buck Hodges说,这曾让TFS的开发人员养成了不良的习惯.

阿里内贸团队敏捷实践(二)自组织管理

- - 并发编程网 - ifeve.com
本文是作者原创,原文发表于《程序员》杂志 2013年3月刊. 实现团队的自组织管理,非常有助于团队形成合力,极大地提升团队整体的工作效率. 本文结合原阿里ITU内贸团队的敏捷实践经历,阐释了从何为自组织管理、为什么进行自组织管理、如何进行自组织管理等内 容,同时给出了团队实施自组织管理的效果. 在《射雕英雄传》里,以全真七子的武功是打不 过东邪黄药师的,但当他们摆出了“天罡北斗阵” 时,却能和黄药师打成平手.

[原]敏捷开发团队管理系列之七:大型研发管理团队的切分(二)

- - 陈勇的博客 - Scrum 敏捷开发培训咨询,绩效管理,团队管理,《火星人敏捷开发手册》
这是敏捷开发团队管理系列的第八篇( 团队管理栏目目录). 还是敏捷开发一千零一问的第二十八篇( 在这里提问, 之一, 之二, 之三, 问题总目录). 还是敏捷开发松结对编程系列的第十三篇( 松结对编程栏目目录),与之前系列 第六篇139团队、 第九篇微软TechED上的讲座有密切关系.