深入敏捷框架--公司级Story培训指导书(一)

阅读导航 本文分四个章节:
第一章是Story基础知识,阐述Story是什么,怎么开发,为什么使用Story。
第二章是Story写作指导,阐述Story的写作步骤,写作标准,写作技巧。
第三章是实施指导,阐述在基于Story的开发中,怎么制定计划,怎么验收等。
第四章是FAQ。

1 Story基础知识

1.1 从问题谈起

软件需求分析中最大的问题是人与人之间的沟通问题。敏捷框架开发过程中,那些想要购买和使用软件的人(客户和用户)和开发软件的人必须进行充分的沟通。一个项目是否成功,很大程度上依赖于大家的理解是否一致。这些人,一个是业务层面,包括客户和用户,分析师,领域专家,以及这个层面的利益相关人,另一个是实现层面,就是这个软件的项目开发人员。

任何一方占据绝对主导地位,忽略另一方的信息,项目都会失败。如果是业务层面绝对主导,他们在规划需要交付的功能特性和交付日期的时候,就会很少考虑开发人员是否有能力同时满足这两个目标,或者开发人员能否确切地理解真正需要的是什么。相反,如果是实现层面绝对主导,他们会更习惯于用技术上的语言和思考方式,如果业务人员在交流的时候一头雾水,开发人员就失去了在交流中获取真正需求的机会。

如果双方分属不同的部门,在资源有限的情况下很容易引发情绪化的争论。如果业务方过于强势,开发人员很可能会接收到这样的任务,“我不管你们怎么做,反正到六月份所有特性必须开发完成”,在这种情况下,只有牺牲质量来换取正常情况下无法完成的特性。有些特性可能无论如何还是做不完,因为没有时间,对需求进行澄清和分析变成了赶任务的过程,本应和客户和用户沟通的问题也只有自行决策。相反,如果开发方过于强势,就会看到迟迟无法决策的情况,在项目开始前进行无休止的讨论,害怕无法如期完成而砍掉越来越多的特性。等到软件最终交付的时候,可能会缺少很多必要的特性。我司可能第一种情况比较常见。

我司还存在另外一种问题,业务方由于抢占市场的需要,很多没有分析清楚的特性就要求开发仓促上马,导致大量的版本废弃,产生的浪费非常巨大。所以我们需要双方在一起工作,不要让任何一方处于绝对主导地位。将双方的利益和目标对齐是解决这个问题的最有效的手段。

我司非常强调计划的准确性,但是从多年以来实际的经验来看,我们必须承认这样一个事实,在飞速发展变化的外部环境中,想要完美地预测一个软件开发项目几乎是不可能的。一方面,客户会不断产生新的想法,需求会发生变化,大家的理解也不可能完全一致;另一方面,随着软件规模和复杂度的增加,我们很难把所有的需求和约束分析清楚。因为各种因素,我们无法做出一个完美的计划,能够展示在项目开发中需要做的所有的事情。

问题是,我们应该怎么办?

我们应该基于手头能够掌握的信息来做决策,并且加快决策的频度。与其在项目开始的时候就做出巨细无遗的完美决策,不如把做决策的时机分散在整个项目开发周期中。为了做到这一点,必须确保有方法在适合的时间获取到尽可能准确的信息,这就是Story的由来。

1.2   Story是什么

1.2.1 Story定义

Story是使用一两句基于用户语言描述的软件需求,描述的是对客户或用户有价值的功能。Story由三个方面组成:

l 一个书面的Story描述,用来做计划并在开发过程中起到提醒作用

l 针对Story描述进行的交流,用来澄清Story的细节

l 记录和传递细节的测试要点,用来确定Story是否开发完成

Story的两个定义:

A user story is a software system requirement formulated as one or two sentences in the everyday or business language of the user. 

A user story describes functionality that will be valuable to either a user or purchaser of a system or software.

开发人员习惯于将Story描述写在卡片或者便签纸上,Ron Jeffries使用非常精炼的三个单词总结Story的本质,叫做“卡片,交流和确认”。因为这三个词都是以字母C开头,又简称为“3C”。卡片是Story的一种简单的表达形式,但不是3个C中最重要的。Rachel Davies认为卡片“用来标识客户需求而不是写需求文档”。可以这样来理解Story的概念:把需求的主题写在卡片上,通过交流澄清需求细节,并作为确认信息记录下来。

1.2.2 细节在哪里

敏捷框架开发中划分的Story太大了,不足以指导开发,大的Story需要拆分成多个小的Story。但我们也不需要将Story拆分到包含所有的细节,

关键的是面对面的交流,而不是Story卡上的注释。Story不是合同,只是个提醒,将来可以变化。

1.2.3 需要做到什么程度

回想一下小时候上语文课的情形,当老师布置写作文的作业,我们通常会问“应该写多长啊?”,老师一般会给一个字数限制,比如“300字以上”。现在想来,用长度来衡量作文是否完成似乎有些怪异,但好像也没有什么更好的办法。实际上这个字数要求是验收工作的人(老师)对这个工作的期望,用一种简洁的方式表明这个工作什么情况下算完。我们开发产品的时候,也需要符合产品用户的期望。捕获产品用户期望最好的方式就是验收测试

1.3 Story怎么开发

1.3.1 开发过程

基于Story的开发过程示意图如下所示。使用过程示意图而不是流程这个词,是因为这里只是阐述大致的工作过程,而不是一个完整的流程。

Story过程

1.3.2 谁负责写作Story

Story需要从客户的角度,描述对客户有价值的功能。负责写作Story的人,应该是客户或者能够代表客户的人。

谁是客户??

在《敏捷软件开发:原则、模式与实践》中有这样一段话:谁是客户?XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团体。有时,客户是和开发人员同属一家公司的一组业务分析师或市场专家。有时,客户是用户团体委派的用户代表。有时,客户事实上是支付开发费用的人。但是在XP项目中,无论谁是客户,他们都是能够和团队一起工作的团队成员。 在理想的敏捷项目中应该有一个专人来明确开发任务和优先级,这个人应该能够回答关于业务方面的所有问题,负责编写所有的Story,并且在软件完成的时候进行验收。但事实上,大多数项目无法找到这样一个人,通常情况下,我们会建立一个客户组。客户组包括那些能够保证软件满足用户需求的人,如真正的用户,市场人员,SE,测试人员,应用领域专家,用服人员,交互设计人员等。对于平台或者组件开发团队,还包括使用这个平台或组件的开发人员。

1.4   为什么使用Story

1.4.1 便于沟通,各种沟通方式的效率和流行度

沟通效率分析

1.4.2 Story易于理解

1.4.3   Story适合迭代计划

Story代表了客户价值。Story表达了一个相对独立的功能片段,是可以达成客户某个目的一组操作和交互。根据Story制定迭代计划,很容易评估每个迭代给客户带来的价值。

2 Story写作指导

2.1  Story写作步骤

对于比较简单的特性,大家在一起,头脑风暴一下,就可以写出Story。对于复杂一些的特性,可以按以下几个步骤写作Story:
识别用户角色
根据用户角色分析业务流程
根据业务流程提取Story
整理Story

2.2 Story写作标准

一个好的Story,需要满足以下六个方面(INVEST)的要求:
独立的(Independent)
便于协商的(Negotiable)
体现客户价值的(Valuable to Purchasers or Users)
易于估计的(Estimable)
足够小的(Small)
可测试的(Testable)

3 Story实施指导

待续。。。

网站&系统开发技术学习交流群:463167176

本站文章除注明转载外,均为本站原创或翻译,欢迎任何形式的转载,但请务必注明出处,尊重他人劳动,共创和谐网络环境。
转载请注明:文章转载自:华晨软件-云微开发平台 » 初识敏捷框架--公司级Story培训指导书(一)
本文标题:初识敏捷框架--公司级Story培训指导书(一)
本文地址:http://www.hocode.com/OrgTec/Agile/0002.html">

相关文章: 敏捷框架原创系列1 ¦

电话
电话 18718672256

扫一扫
二维码