软件工程的引入:Scrum开发框架总结

  1. 云栖社区>
  2. 博客>
  3. 正文

软件工程的引入:Scrum开发框架总结

ghost丶桃子 2016-05-19 15:43:49 浏览2510
展开阅读全文

俗话说,自己写的代码,6个月后也别人的代码……复习!复习!复习!涉及的知识点如下:

  • 软件工程概念
  • 敏捷开发过程scrum

一、什么是软件工程?请用一句话描述。

  软件工程是一门研究性的学科:它用工程化的方法(联系建筑工程……),构建和维护有效的、实用的,和高质量的软件。简单来说,软件工程有三要素:过程+方法+工具,而软件工程是目标软件过程是步骤,方法和工具是辅助。

 

二、那么,软件过程又是什么?

  软件过程:首先它是一个框架或者说步骤,它是一个为建造高质量软件而所需要完成的任务的框架,即形成软件产品的一系列步骤,包括中间产品、资源、角色及过程中采取的方法、工具等范畴。

 

三、常用的软件开发过程(开发框架)都有什么?选一种做简单介绍。

  1、瀑布模型(Waterfall Model):开发过程是通过设计一系列阶段顺序展开的,过程如下:先明确要做的是什么,然后看用户的需求是什么,分析需求之后简单得出一个demo(画出原型图,草图等),然后进行架构分析和设计,总结出设计文档,之后讨论详细的开发细节,而后实现,最后测试……如图:

 

  瀑布模型的优点:
–为项目提供了按阶段划分的检查点
–当前一阶段完成后,您只需要去关注后续阶段
瀑布模型有以下缺点:

  –各个阶段之间极少有反馈
–只有在项目生命周期的后期才能看到结果
–通过过多的强制完成日期和里程碑来跟踪各个项目阶段
–不适应用户需求的变化

  2、scrum敏捷方法,Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球,Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法。

  3、ICONIX过程,包括愿景分析、业务建模、需求分析、健壮性分析、关键设计、最终设计、实现……

四、什么是敏捷开发过程?

  敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。说白了就是更加灵活!面向人的需求为核心!是一个逐步适应性的过程!敏捷是一种思想敏捷和瀑布模型比较:

那么敏捷是不是就是万能的呢?其他过程都不好?不是的,一定澄清几个误区,对敏捷开发的误解:敏捷固然好,但是其他方法不是都没用。遵循敏捷过程的常见软件开发模型有scrum,xp(极限编程)……其中比较流行的是scrum。

 

五、scrum概念

  Scrum是一个框架,顾名思义scrum是橄榄球运动里带球过人,争球的含义,而带球过人需要计划!在球场上,在比赛每段的开始,双方都要摆开阵势,教练和队长都可以参考计划。而在软件开发公司。敏捷方法的每个迭代的开始,团队领导者都应该做好本迭代的计划,尤其是需求条目的优先级排序、选择本迭代的工作、设定必须完成的内容等。且带球过人需要灵活应变!在球场上,哨声响起,尽管队员们努力按照计划推进,但场上瞬息万发,队员不可能实时按照教练指令亦步亦趋地行事,而是靠平时训练中形成的素养见机行事,达成目标,在软件开发公司,在每个迭代开始后,团队领导不可能也不必需要事必躬亲,而是应该由具体执行的人选择如何去做。团队领导要做好的是协调资源、解决困难、提供指导,以达成目标。

  1、敏捷开发的角色

  产品负责人PO,负责产品的需求提炼、条目化,优先级排序,PO直接和用户以及其他关系人交互。scrum过程管理者scrum master,负责维护scrum方法的秩序,并协调解决非技术问题。最后是team团队,自组织的相对扁平化的管理方式进行项目的开发工作。

  scrum团队结构:

  名词解释:每个迭代的冲刺周期过程又叫sprint,其中贯穿了很多活动……

  sprint计划会议:每次迭代之前召开,时间充足(4-8小时或者……),po,sm,team……都参加po从backlog积压的产品列表里找高优先级任务,并和team商量需要完成多少功能,po把功能分解为小的功能模块,而team要详细讨论如何完成……预估时间。

  backlog(积压的待处理事务):产品的backlog包括了所有需要交付的内容,内容根据业务的需求价值顺序排列,更加需求变化动态的增长或者减少。既定产品的backlog是一个迭代中的产物,定义了team接受的工作量,整个sprint中不变,sprint backlog涵盖了最终版本的既定产品backlog的任务,团队通过它来协调开发进度,障碍backlog列举了所有团队内部和相关的和阻碍项目进度的问题,sm需要确保所有的障碍backlog问题都已经分配并且可以得到解决。

  每日会:早上开比较好,与会人员站立而开,10几分钟足以,任何人都可以参加,sm主持,但只有team能做相关任务的发言,每个team要问三个问题——昨天做了什么?今天要做什么?遇到了哪些问题?然后更新燃尽图

  sprint评审会议:每次sprint结束时召开,时间一般2个小时内控制,team展示本轮迭代完成的任务,不需要ppt,展示demo!此会,客户,po,管理层……都能参与,目的是让po去断定项目开发的进度和迭代目标是否一致。

  sprint回顾会议:sprint结束之后召开,时间一般1-3个小时左右,po,sm,team都参加,目的是对刚刚接受的sprint进行总结,反思,提高适应能力。需要总结分析成功经验和解决的困难。

  2、Scrum主要特征:快速开发尽快交付,团队合作适应变化。

  3、Scrum的适用场景:

•7人,+or-2
•偏一些会更适合
•最好能坐在一起
•客户参度不高
快速移动互联网项目
自主性研发的产品

六、scrum开发方法的具体流程

  1. 项目的提出(项目的背景,项目的主要朋务对象,目标—愿景,商业价值,服务对象的细分)以Project Owner为主要提出者,team辅助

  项目的背景:“大数据时代已到,数据越来越具有价值,没有数据寸步难行,有了数据可以在诸多领域干很多事,比如互联网金融。从互联网上爬来自己想要的数据,是数据的一个重要来源,而且往往是必不可少的来源。所以……要能稳定的、高效的和实时的带来数据……”。

  项目的主要服务对象:区分客户和用户!客户是系统的购买者,用户则是系统的使用者。知乎爬虫系统服务对象:某论坛-客户

  项目的目标(愿景):愿景就是向往的前景,是人们为止持续奋斗而希望达到的图景!比如社会主义接班人要奋斗终生去努力实现共产主义–没有阶级、没有压迫、没有贫穷、没有失业、人人幸福的共产主义社会!福特汽车让每个家庭都有一辆汽车,微软让每个桌面都有一台计算机……故可以认为:伟大的愿景能成就伟大的事业!具体到软件的愿景,要想找到软件的愿景就要找到项目购买人——老大(专业术语),先找到老大,再得到老大购买该系统的目的,PO去做……我们已经知道软件项目是为了改善某个组织的某些方面,而购买软件的人(老大)毫无例外就是这个组织中最有话语权的干系人。比如企业的财务主管需要提高财务工作的效率,某企业的领导需要占领市场,领先对手,某官员需要彰显政绩……知乎爬虫系统的愿景就是根据论坛主需要,多样化,精确化丰富论坛内容(这里学习为主,模拟为主,故不考虑版权,但实际工作必须有版权意识!),

  项目的商业价值(难分析,很重要):先回答什么是商业价值?通俗地讲,商业模式就是项目通过什么途径或方式来赚钱。而解决别人愿意花钱解决的问题,就是商业价值。po主持挖掘商业价值,如果没挖掘出来……好吧,放弃该项目!

  服务对象细分也就是用户角色建模良好的用户建模,可以保证不同用户都能方便地访问其功能 ,使用产品后也更容易获得其特定的价值,一般由project owner主持,借助团队的力量进行头脑风暴!

  • 哪些用户可能来使用产品(或访问网站)
  • 他们为解决哪些问题而来,or 为达到哪些目的而来

用户建模的步骤,四步曲

  • 尽可能多的列出用户
  • 找出关键用户——购买的决策者,主要的使用者
  • 分类,合并次要用户
  • 添加虚拟的和极端的用户,虚拟用户——假想的用户角色的代表。比如 “ Mario在SpeedyNetworks的人事部门负责招聘工作,该公司是一个高端网络组件制造商。他已经在该公司工作了6年。Mario有弹性的时间安排,每周周五他在家工作。Mario对电脑相当在行,他觉得对于自己所使用的软件产品,他几乎都是超级用户。Mario的妻子Kim,正在斯坦福大学化学系攻读博士。由于SpeedyNetworks几乎一直在扩张,Mario总是在物色优秀工程师。” 极端用户——很可能让你编写出原本可能遗漏的故事。

  2、产品功能列表的定义,所谓产品功能列表是一个需求、or 特性等组成的列表-产品backlog是Scrum的核心,是一切的起源,按照重要性的级别进行了排序,里面包含的是客户想要的东西,使用用户客户的术语加以描述。产品功能列表主要是Product Owner写,Team也有权利,但最终由PO进行取舍。

  产品功能列表写成什么形式——用户故事user stroy的形式!因为在产品定义阶段我们很难全面描述出来我们项目的需求,我们需要一种方法去探讨需求——用户故事。传统的需求说明书是这个阶段的结果。  PS:产品功能列表格式

ID(统一标识符) Name(标题)–简短的、描述性的故事名 Story(故事)–故事内容描述 Priority(重要性)–产品负责人评出一个数值,指示这个故事有多重要 Initial estimate(初始估计)–团队的初步估算,表示和其他故事相比,完成该故事所需的工作量 How to demo(如何做演示)–它大略描述了这个故事应该如何在sprint 演示上进行示范 Notes(注解)–相关信息、解释说明和对其它资料的引用等等  
               
               

额外的字段(非必需)

•Track(类别)–当前故事的大致分类
•Components(组件)–通常在Excel文档中用“复选框”实现
•Requestor(请求者)–这项需求的提出者
•Bug tracking ID(Bug跟踪ID)–故事与bug间的直接联系

  那么用户故事又是什么鬼?
用户故事是一种敏捷的需求挖掘方式,其侧重点不是将需求书写出来,而是将需求讨论出来。基本的叙述格式为:“作为一个……,可以……,以便……” 的样式和思路写成的用户需求,就是用户故事。作为一个网站站长,我希望能通过xx爬虫系统抓取xx数据,以便于我的网站用户能方便的得到某些信息、作为一个网上商城的买家,我希望通过QQ号可以登录商城,以便于买东西……

  用户故事三要素:角色、功能、客户价值,角色来源于用户角色建模的结果!功能使用主语-谓语叙述原则,动宾词组原则.比如针对显示xx数据:作为一个系统管理员,我希望可以显示xxx数据,以便vip用户……注意:角色和功能之间是主语-谓语关系;功能本身是动宾词组。我们一般把用户故事的标题写为功能的形式。关于客户价值,看似简单,其实很难写,我们先体验一下;“作为一个网友,我希望能够有个快速通知可以提醒我有新的新闻更新,以便于节省我浏览网站寻找新闻的时间,从而有更多时间做其他的事情。”、“作为一个站长,我希望爬虫系统能有效,快速的抓取xxx数据,并进行一些列分析……以便于我得到xxx信息。”

  用户故事也是用来被卖掉的东西,看不到价值的故事不是用户故事。

     让故事停留在业务层面,避免技术性故事,Eg:给xxxx表添加索引,它的真正目标是什么?当然是为了提高在后台系统中搜索事件表单的响应速度,最开始的技术描述只会作为一个注解存在(“为事件表添加索引可能会解决这个问题”)

  好故事的准则

  •独立的(Independ)避免故事间的相互依赖性。

–用户可以用Visa信用卡充值。
–用户可以用万事达信用卡充值。
–用户可以用美国运通卡充值。
思考:如何消除依赖?

合并故事——用户可以用信用卡充值。

通过不同的维度分割故事!——用户可以用一种信用卡充值,用户可以用另外两种信用卡充值。

  •可讨论的(Negotiable)不要包含过多的细节

  •对用户or客户有价值的(Valuable)
•可估计的(Estimatable)一般有以下3个原因会导致故事不可估计

–开发人员缺少领域知识。
–开发人员缺少技术知识。
–故事太大了。
解决方案
–PO讲解/和客户讨论。
–分解为更小的故事

  •小的(Small)刚刚好的,比如:用户可以完成一次购物——大故事不好!

  •可测试的(Testable)故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。通常,不可测试的故事发生在一些非功能性的需求上,这些需求和软件有关,但不直接和功能有关。

–用户必须觉得软件很好用。
–用户绝不需要花很长时间等待窗口出现。在95%的情况下,新窗口会在2秒内打开

  用户故事的好处
•用户故事强调对话交流而不是书面沟通。
•用户故事可以同时被po和开发人员理解。
•用户故事的大小适合做计划。
•用户故事适用迭代开发。


3、产品发布和迭代周期:常见两种方式

  每次迭代发布,移动互联网项目,自主性研发产品……

  多次迭代发布,传统项目、大型项目

  前面说了,迭代之前要开sprint计划会议,但是在冲刺计划会议之前要:

  • 确保产品 backlog 的井然有序,产品 backlog必须存在,只能有一个产品 backlog和一个产品负责人,重要的 backlog 条目都已经根据重要性被评过分,PO应当理解每个故事的含义!
  • 确定Sprint 计划会议日程
    -13:00 – 17:00 (每小时休息 10分钟)
    -13:00 – 13:30。产品负责人对 sprint 目标进行总体介绍,概括产品 backlog。定下演示的时间地点
    -13:30 – 15:00。团队估算时间,在必要的情况下拆分 backlog条目。产品负责人在必要时修改重要性评分。
    -15:00 – 16:00。团队选择要放入 sprint 中的故事
    -16:00 – 17:00。为每日 scrum会议安排固定的时间地点

  • 会议由Product Owner、Scrum Master、Scrum Team参加,产品负责人必须参加

  • 确保质量不能让步:外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣,内部质量一般指用户看不到的要素,它们对系统的可维护性有深进影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。

  在冲刺计划会议中

  

 

  • 确定Sprint目标及长度,半死不活的目标也比啥都没有强。
  • 讲解Story:讲解故事就是要明确故事内容,决定spring包含的故事,使用故事索引卡,哪些故事需要从产品 backlog 拷贝到sprint backlog 中,在sprint中包含多少故事由团队决定 ,而不是产品负责人or其他人
  • 估算时间;估算时间就是对故事的估算,估算的单位——故事点(理想化的人-天),可以使用计划牌

  我们在这里使用以下几种技术:
–本能反应
–昨日天气,昨日天气(yesterday’s weather)——查看团队的历史

  –生产率计算:用生产率计算来估算,这项技术包括步骤如下:

–参考实际生产率
–得出投入程度
–得出估算生产率
–计算在不超出估算生产率的情况下可以加入多少故事。

  实际生产率:把上一个 sprint 中完成的所有故事的原始估算加起来,得到的和就是实际生产率

 

    “投入程度(focus factor)”,以上一个例子为基础,团队的投入程度为:


18/50=36%

    估算生产率:Eg:假设下个Sprint我们有30个人天,则生产率=30×36%=10个故事点

    一些其他问题:如果没有历史数据怎么办?在新团队中使用的“默认”投入程度通常是 70%。

           实际过程中我们用的是哪种估算技术?一般我们都是结合起来用

            –审视上个sprint的投入程度和实际生产率
–估算一个投入程度
–再进行“直觉反应”的检查

           产品负责人如何对 sprint 放哪些故事产生影响?
调整优先级

 

             缩小范围

  • 任务分解;“任务”和“故事”的区别是什么呢?——故事是可以交付的东西,任务是不可以交付的东西

  spring计划会议中:定下每日例会的时间地点,一般是9:00,9:30 or 10:00,必须是每个人都能完全接受的时间。定义“完成”,产品负责人和团队需要对“完成”有一致的定义,

  Sprint计划会议之后:Sprint 计划会议会产生一些实实在在的成果

    –sprint目标
–团队成员名单(以及他们的投入程度,如果不是 100%的话)
–sprint backlog(即 sprint 中包括的故事列表)
–确定好 sprint 演示日期
–确定好时间地点,供丼行每日 scrum会议

     让别人了解我们的Sprint
•sprint信息页;sprint 目标和演示日期

    •经过团队认可、要添加到这个 sprint 中的故事列表
•Sprint 中每个故事的估算值
•明确每日例会固定丼行的时间地点
•把故事拆分成任务

 

 

  4、scrum每次sprint设计的过程

  不好的,引发风险,产品不能满足客户需求变化,bug率标高,代码质量堪忧

  好的:

  1. 先界面原型设计,PO主持,那什么是界面原型?

  界面原型指使用工具根据客户需求及软件分析人员的理解,将头脑中的界面快速的反映到介质上。将需求转化为可视画面以及人与系统的交互!

  界面原型的好处:Prototype不仅仅可确定需求,它更可赢得顺客的心—阿伦 M.戴维斯 和 迪安 A. 莱芬韦尔,《用需求管理快速交付高质量的软件》的作者(Rational软件公司/IBM)

  界面原型的目的:
•尽早验证需求
•尽早明确不确定性的因素
•方便便沟通交流
•为后续界面设计提供基础

      界面原型的目的是需求验证,不必太纠结细节。

  如果原型设计都没通过,就没有必要进行下去,如图:

 

  画界面原型的工具;白纸、铅笔、橡皮、橡皮+铅笔+白纸、Axure、MS OFFICE、PS、Viso……工具只是工具,任何一种方法or工具都是为我们开发、生产过程服务的,我们不能成为工具的奴隶。根据实际以及环境选择合适的工具绘制。

  2、数据库设计。这里主要讲解范式——”数据库的三范式

    •第一范式
–关系R中的属性都是不可分割的项.
•第二范式
–在1N的基础上,每个非主属性完全函数依赖码.
•第三范式
–在2N的基础上,每一个非主属性既不部分依赖码也不传递依赖码.

  从1范式到2范式
•1N | 消除非主属性对码的部分凼数依赖 2N
•假定选课关系表为
–SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)
–存在如下决定关系: (学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
–规范化 学生:Student(学号, 姓名, 年龄); 课程:Course(课程名称, 学分); 选课关系:SelectCourse(学号, 课程名称, 成绩)。

   从2范式到3范式

  •2N | 消除非主属性对码的传递凼数依赖 3N
•假定学生表为
–Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)
–规范化 学生:(学号, 姓名, 年龄, 所在学院); 学院:(学院, 地点, 电话)。

  对于三范式的理解
–每一列只有一个值
–每一行都能区分。
–每一个表都不包含其他表已经包含的非主关键字信息

  3、系统设计

 

  5、产品实施(监控过程),管理sprint backlog最有效的形式—挂在墙上的任务板!在每日例会的时候(or 会议开始前)更新任务板

    在首次每日例会以后,任务板可能会变成这样

    几天以后,任务板可能会变成这样

 

  还有使用燃尽图(burn down chart):是在项目完成之前,对需要完成的工作的一种可视化表示。Sprint燃尽图和迭代燃尽图,Sprint燃尽图展示了以故事点表示的在本轮迭代中剩余的工作量;

-y:预估剩下的故事点
–x:日期(非工作日除外)
–y/x=生产率

   计划速率和实际速率:监测实际速率和计划速率的偏差

  还有累计故事点图:表明了在每轮迭代结束时总共完成的故事点数。

  每日燃尽图显示了团队在某轮迭代中的进度,你可以用这个信息判断计划的工作能否在迭代结束时都能完成。

 

辛苦的劳动,转载请注明出处,谢谢……
http://www.cnblogs.com/kubixuesheng/p/5172245.html

网友评论

登录后评论
0/500
评论
ghost丶桃子
+ 关注