《敏捷软件需求》阅读笔记03

今天我阅读了《敏捷软件需求》的第三章《团队的敏捷需求》。在敏捷方式中,对需求工作的组织和对团队本身的组织不是彼此独立的。相反,敏捷团队是围绕需求进行组织的,以便优化代码的定义、构建与测试以及向终端用户交付价值的效率。敏捷团队的基本工作单位是用户故事,团队的目标是在迭代时间盒内,定义、构建和测试一定数量的用户故事,在迈向发布的过程中逐渐实现更大的价值。  对每个故事的实现可以采用相同的模式:定义故事、编写代码和测试用例、针对代码运行测试。

在每支敏捷项目团队中有三种角色:产品负责人、Scrum Master和其他团队成员,主要包括编写和测试代码的开发与测试人员。产品负责人主要负责确定定义需求、维持代办事项并基于代办事项的相关用户价值设定其优先级、设定迭代目标、细化故事、参与进度评审并接受新的故事。Srcum主要负责推动团队向目标前进、领导团队的持续改进、推行敏捷的过程规则、消除阻碍。开发人员主要负责开发正确代码、写和执行单元测试、根据需要写方法以支持自动的验收测试和其他的自动化测试、每天把代码签到代码库。测试人员从新代码开始产生时,测试人员即开始参与团队活动,并且这种参与贯穿整个发布过程。在每个新故事到达迭代边界时,都要立即检查分析对其验收的可测试性。敏捷团队中除了这几种角色还有架构师、质量保证的角色、其他专业人员与支持的人员。

在敏捷团队中,团队代办事项是团队唯一的正式工作来源,它记录了需要完成的所有工作(主要是用户故事),代办事项中包含团队已识别的所有工作项。代办事项包括一些用户故事和其他工作项。其他工作项包括诸如重构、缺陷、支持与维护、以及工具和基础设施工作等。团队的任务是一种为了完成故事所必需的小的工作单元。

原文地址:https://www.cnblogs.com/wl2017/p/8504277.html

时间: 2024-10-06 06:50:06

《敏捷软件需求》阅读笔记03的相关文章

掌握需求过程阅读笔记01

掌握需求过程 第一章什么是需求 阅读笔记 我们为什么要进行需求呢? 这样是为了使效率更高,并且减少错误步骤所不必付出的代价. 在我们构造产品之前就要知道客户的需求是什么,大多数的组织都是通过系统分析来进行的,但是需求过程与系统分析并不是一回事,虽然他们之间有联系,但并不完全相同.除了系统分析以外,需求也是很有必要的.他可以对你的分析师生涯有更进一步的促进.当我们接触到一个新的产品时,业务事件和使用情况逐渐清晰了起来,系统分析可以对产品进行更清楚的建模,并为需求过程提供有价值的反馈.对需求的了解增

掌握需求过程阅读笔记—2

通过对事件驱动的用况.网罗需求.功能性需求这三个章节的阅读.使我们明白了在事件的驱动用况上,我们需要通过一些经验法则来定义用况,发现合适的用况:在网罗需求上,我们最需要做的就是进我们的一切可能去罗列用户的需求,并能及时的与用户沟通交流,确保产品符合最新的要求:在功能性需求方面上我们应当明白它是因为产品的存在的根本原因而存在的需求,它描述的是产品的动作,并能够形成一份完整的尽量避免二异性的功能描述. 事件驱动的用况是业务实践相应(活动和数据)的一部分,这些事件响应有产品来执行.用况成为了需求的锚,

《掌握需求过程》阅读笔记03

我们都知道要站在用户的角度考虑问题,可是作为用户的我们也是存在思考的缺口的,那些根深蒂固的东西会使我们忘记了它们的存在,这就是未意识到的需求.还有未梦想过的需求,我们习惯了类似软件拥有的功能,未曾想过一些新的功能,在我们看来,技术还没有成熟.作为软件工程师,我们一定要在初期让这种需求浮现出来,否则后续阶段发现会付出太多代价. 开始阶段我们会画上下文范围图,输入输出流表示数据的流向,如果画图过程中有不知去向何处的数据流,那正是我们需要向用户询问的地方.需求调研是主动的,用户在工作的时候才能精确描述

《探索需求》阅读笔记二

在任何相当规模的开发项目当中,孤军奋战显然是像是一种幻想,为了获得一个团队所能提供的容量和差异性,我们必须放弃任何个人英雄主义的幻想,为和他人合作付出代价.而这种人际的花费在会议中体现的最为明显,会议也是一种工具,一种社交工具.很多人都会感觉会议是很可怕的,它有的时候并不会产生什么效果,但是我们离不开它,一旦离开会议,就只能开发出最简单的产品.每一个会议能达到的结果是度量需求工作的健康状态,一个糟糕的会议,说明了需求过程的不完善.要想每一个参与者都完全的参与进会议中,这个会议就必须是稳定的,我们

《探索需求》阅读笔记一

这本书主要讲述关于开发项目的问题,讨论的主题是问题陈述或需求集合,需求在很多方面都是非常重要的.我们通常使用的是需求映射图而不是需求本身,所以我们需要探索许需求. 一旦在探索需求过程中使用了忽略了人的因素的工具,就不可能完美的描述需求,这会造成含混性,同时当需求被明确说明,但是使用了含混的词语也导致含混性问题的出现.含混性需要成本而且对于我们解决问题产生巨大影响,即可以发现需求含混性的重要性,所以在探索需求过程中要及时尽早地消除含混性,使用一些可以很好的抑制含混性的探索需求工具.许多含混性不一定

《软件需求模式》阅读笔记03

在对需求模式的概念和内容方面有了深刻的了解之后,我将学习各类不同的需求模式. 基础需求模式是所有种类的系统都可能需要的一些东西,它包括了:技术.遵从标准.参考需求.文档.系统间接口.系统间交互.系统间需求模式是用来定义被定义的系统和任何与之交互的外部系统或组件之间的接口的基本细节,它包含了以下内容:接口名称.接口标识符.两端的系统.接口的目的.接口的所有者.定义接口的标准.用于接口的技术.在开发测试的时候,我们应该明确交互需求,找到隐含的交互以帮助满足间接陈述的目标.系统间交互需求模式是用来定义

《软件需求》阅读笔记之二

这次阅读的是这本书的第二部分,这部分内容相对较多,所以还没有看完.这部分介绍了一些文档的主要内容.首先是项目视图和范围文档的模板,书中一一介绍了这个文档中应该包括的内容.主要就是业务需求,项目视图的解决方案,范围和局限性,业务环境,产品成功的因素.所以,我们在做项目的时候,无论如何都要注意这个项目的范围,所想到的不要超出范围.有时候你感觉好的功能用户可能并不需要.所以,明白项目范围,并在范围内进行工作相当重要.我们所用到的需求基本全部来自于用户,获取用户需求的方式也相对较多,在获取某用户群体的需

构建之阅读笔记03

1.我认为在团队合作的过程中,编写程序之前,应该要首先规范命名,通过第四.五章我知道了,作为一个软件工程师不仅要有出色编程能力还要有对代码注释的意识,因为在团队工作中,你如果不注释你写的代码,那么当你有事,别人接手你的代码时,就会遇到很大的问题,他需要一点一点读懂你的代码,这会对团队的进程造成影响.我们还要在编写程序前先要对代码的命名和缩进等问题进行同一的规定,这样会使得团队的进程得到很快的发展. 2.在团队合作中,刚开始也许我们并不知道应该怎样进行合作,通常我们都是自己编程,没有和其他人合作的

《构建之法》阅读笔记03

我一直认为软件工程就是用很好的方法设计出很好的软件.那么这个过程从头到尾都要好好研究,然而刚开始的阶段并不是软件开发的开端,而是对用户的需求分析,是想,如果我们都没有把用户内心里真正想要的东西搞清楚,怎么能够开发出来令用户满意的软件呢? 软件的需求共有三类: 获取和引导需求:软件团队要找到软件的利益相关者,了解和挖掘他们对软件的需求,引导他们表达出对软件的需求. 分析和定义需求:对各个方面的需求进行规整,定义需求的内涵,从各个角度将需求量化. 验证需求:软件团队用各种形式向用户验证软件团队对需求