2018-04-22 08:00:57 g1506490083 阅读数 1344
  • HTML课程

    本课程大纲概述: 1》专业名词解释和环境搭建 2》html标记一 3》html标记二 4》html实现公司成本表--水电财务 5》表单和利用表单实现到货通知单 6》框架集

    1374 人正在学习 去看看 张鹏

敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。

首先了解下SCRUM的工作流程的几个名词

Sprint:一个迭代周期的工作计划。一般需要2-4周时间。

Backlog:一个sprint的需求列表,可以看成是小目标的清单。

Task:具体小目标的开发任务。

Planning Meeting:确定这个迭代周期最终的开发任务和其对应的优先级即Sprint Backlog.

Daily meeting:每天早上的站会,用于讲一下自己工作进度和今天要完成的内容。

review meeting:在测试和修复BUG完成后全体人员开评审会议。

Retrospective Meeting:回顾会议每个人讲下这轮迭代过程中做得好的地方和做得不好的地方。


2019-04-12 22:52:55 y_279611480 阅读数 557
  • HTML课程

    本课程大纲概述: 1》专业名词解释和环境搭建 2》html标记一 3》html标记二 4》html实现公司成本表--水电财务 5》表单和利用表单实现到货通知单 6》框架集

    1374 人正在学习 去看看 张鹏

SCRUM 是什么?

Scrum是敏捷开发中的名词。

敏捷开发是什么?

敏捷开发(Agile Development) 是一种以人为核心、迭代、循序渐进的开发方法。

简单的说的话:

  1. 它只是一种开发思想,而不是开发技术;
  2. 其次,需要明白,通过敏捷开发的项目,包含的诸多子项目,都会带有,已经测试结束,具备了集合和可运行的特征;
  3. 敏捷开发,初始,并不追求完美的设计以及编码,而是,尽可能快的先开发出产品的核心功能,以及发布可用版本。之后,才会在多余的生产周期内,根据需求,不断的完善升级与迭代产品。

eg:对于Java全栈式开发工程师来讲,拿到需求,了解之后,第一件事,并不是先去完善后台代码,而是迅速的先将需求页面(网站),先实现。而后,才开始根据需求一步步实现功能。

以人为核心是什么意思?

一句话概括来讲的话,便是:

不似瀑布开发的思想,往往开发完后,写了一堆的开发文档进行开发、
而是,尽量的少写开发文档,只写一些必要性的文档,因为敏捷开发注重的是人与人面对面之间的交流。所以说它是以人为核心。

迭代 是什么意思?

类似与 单体开发 与 微服务、分布式开发的区别。
一个是,将所有的功能实现后,方可测试与后续操作。
另一个是,将所有的功能分为一个个服务或小功能,完成一个便可开发,测试,上线一个小功能。慢慢的完成总体。

循序渐进自然,也可由上明白。

SCRUM 与 敏捷开发思想有什么关系?

Scrum是敏捷开发之后的方法的一种。

敏捷开发的模式分类(摘抄至互联网):

敏捷开发的实现主要包括 SCRUM、XP(极限编程)、Crystal Methods、FDD(特性驱动开发)等等。其中 SCRUM 与 XP 最为流行。

同样是敏捷开发,
XP 极限编程 更侧重于实践,并力求把实践做到极限。这一实践可以是测试先行,也可以是结对编程(eg:多人协调开发)等,关键要看具体的应用场景。

SCRUM 则是一种开发流程框架。
SCRUM 框架中包含三个角色,三个工件,四个会议,听起来很复杂,其目的是为了有效地完成每一次迭代周期的工作。

SCRUM 的工作流程(摘抄至互联网)

学习 Scrum 之前,我们先要了解几个基本术语:

Sprint:冲刺周期,通俗的讲就是实现一个“小目标”的周期。一般需要 2-6 周时间。
User Story:用户的外在业务需求。拿银行系统来举例的话,一个 Story 可以是用户的存款行为,或者是查询余额等等。也就是所谓的小目标本身。
Task:由 User Story 拆分成的具体开发任务。
Backlog:需求列表,可以看成是小目标的清单。分为 Sprint Backlog 和 Product Backlog。
Daily meeting:每天的站会,用于监控项目进度。有些公司直接称其为 Scrum。
Sprint Review meeting: 冲刺评审会议,让团队成员们演示成果。
Sprint burn down:冲刺燃尽图,说白了就是记录当前周期的需求完成情况。
Release:开发周期完成,项目发布新的可用版本。

开发模型:
流程图

流程:

  1. 由产品的负责人,按照需求的优先级,优先取出一部分Backlog(需求清单)。
  2. 在每个Sprint(冲刺周期),开发团队根据计划,确定好每个周期的需求清单(Backlog)。既,在每段时间内需要完成的工作任务是什么。
  3. 对团队成员进行任务的分配开发。每天,团队都会开启Daily meeting(每天的站会)【既,明白自己之前完成了什么】。
    而后团队成员调整自己的Task状态【既,每个小任务的完成时间又该控制在什么时间内】,整个团队便更新自己的Sprint burn down(冲刺燃尽图)。
  4. 当这份Backlog(需求清单)完成之后,便会开启团队的Sprint Review meeting:(冲刺评审会议)。没问题的话,便会发布出发此阶段产品的发型版本(Release),且进行Sprint review meeting(回顾会议)

写在最后,PS:此文内容,部分摘抄至互联网,如若,原文博主介意,可私聊。谢谢。
自然,此文并不完善,欢迎各位点评。

2010-10-27 16:43:00 woshicolorwolf 阅读数 352
  • HTML课程

    本课程大纲概述: 1》专业名词解释和环境搭建 2》html标记一 3》html标记二 4》html实现公司成本表--水电财务 5》表单和利用表单实现到货通知单 6》框架集

    1374 人正在学习 去看看 张鹏

    敏捷开发。至今不是真正的明白什么是敏捷开发,但是也经历了将近4个月的所谓敏捷开发过程了。
就先记录下自己的一些想法吧。
    刚听到这个敏捷开发的名词时感觉很玄乎的开发模式,网上大家都在讨论。可是实际到了项目中,却
没有那么神秘了。每天早上会有15分钟的晨会,先复述下昨天的工作内容,然后用最简练的话语描述今天
要做的事。具体的遇到的问题不会在晨会中进行讨论,避免时间的流失。鼓励问题产生方与问题的处理方
直接在会下沟通,这样可以有效的节省其余人员的时间。
     以上就是敏捷的开发每天的过程。敏捷的具体工作内容是什么呢?PM会建好feature,PG自己根据自己
情况去拿这些feature,然后给拿到的feature估计下完成时间很进度。这个估计的过程我感觉没有一定的开发
经验是很难准确的估计出来的。关键是feature的建立,这种逐步的开发模式可能的目的之一就是为了解耦,而
能不能解耦关键是要看这些feature的水平了。如果feature之间可以很好的解耦那么目的算是达到了。所以我个
人的感觉就是建feature才是敏捷开发的关键所在。怎么建feature,如何建feature。如果真的可以做到像搭积木
那样随意的加减feature的话,那样就最圆满了。可是究竟又有多少可以达到呢?

2014-10-23 18:27:47 xmt1139057136 阅读数 2467
  • HTML课程

    本课程大纲概述: 1》专业名词解释和环境搭建 2》html标记一 3》html标记二 4》html实现公司成本表--水电财务 5》表单和利用表单实现到货通知单 6》框架集

    1374 人正在学习 去看看 张鹏

敏捷、敏捷开发这类词最近很火!敏捷开发,就是指能够在需求迅速变化的情况下快速开发软件。我们接触最多的和敏捷相关的名词是:极限编程(XP)、结对编程、测试驱动开发(TDD)等。

敏捷建模(Agile Modeling,AM),的价值观包括了XP的四个价值观:沟通、简单、反馈、勇气。此外,还扩展了第五个价值观:谦逊。
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。除了原则和实践,模式也是很重要的,多研究模式及其应用可以使你更深层次的理解敏捷开发。

SCRUM敏捷开发规则一栏,我们看看图表吧,下载下来看着更清楚!!!


原图下载地址:http://download.csdn.net/download/xmt1139057136/8074061

点击下载           推荐原图浏览

如有疑问,请加qq群:135430763 共同学习!

2019-06-05 15:19:03 ZYD45 阅读数 5229
  • HTML课程

    本课程大纲概述: 1》专业名词解释和环境搭建 2》html标记一 3》html标记二 4》html实现公司成本表--水电财务 5》表单和利用表单实现到货通知单 6》框架集

    1374 人正在学习 去看看 张鹏

开发过程管理,主要面向开发人员的管理。其核心目的,是通过一个项目管理软件,来管理不同项目,然后通过项目的里的工作项,了解开发人员的工作量,效率,从而来管理开发人员,合理调配开发人力。

名词解释

项目:一系列独特的、复杂的并相互关联的活动,这些活动有着一个明确的目标目的,必须在明确的起止时间、预算、资源限定内,依据规范完成

迭代:重复反馈过程的活动,其目的通常是为了逼近所需目标或结果。是产品开发时,对项目的拆分。每一次对过程的重复称为一次“迭代”,而每一次迭代得到的结果会作为下一次迭代的初始值。开发项目中的迭代,往往是指产品版本的迭代,比如要实现一个产品最终版可能要三次迭代,第一次迭代实现基本原型,第二次迭代实现能用,第三次迭代的目标就是好用,这种情况下,迭代就和阶段、冲刺类似,而大多情况下,一个迭代,往往指一个产品已经具备了1 2 ..5...项功能,下一次迭代就是优化或追加功能。

冲刺:敏捷开发里的名词,和迭代类似。时间周期更短的阶段,一般在开发中为了快速出部分原型效果。

积压板:微软的tfs里的工具,主要可以用于在项目里存放idea,各种需求或想法。简单来说,记录一些idea的便签。

工作项:将需求分拆为一个个小的具体工作名词,开发任务。比如 “首页-导航栏”,“首页-登录按钮”。基本工作项就是一个开发的最小单元,当然这是理想化的时候,很多时候分不到这么细。简单来说,就是一件件要做的事。

一个项目,可能被拆分为多个冲刺,每个冲刺里的需求,被拆分为多个工作项。

项目>冲刺>工作项。(需求可被直接存放在项目里,也可以在冲刺里)

生命周期

UML-Sequence-for-UserStory-and-Tasks

 项目干系人:参与该项目工作的个体和组织。简单来说,就是项目里干活的,和管理干活的那拨人。

一次冲刺的相关流程

某一次冲刺里的流程

 

整个敏捷开发思想核心,是为了快。

快速的迭代,快速出一个版本,先用一个有核心功能的版本出来,然后再在后面的冲刺里,丰富这个功能。每次聚焦一个核心,然后不断迭代,扩充这个核心。

有的公司团队,使用的敏捷开发是按照,功能点拆分的方式,不同团队开发不同模块之类的,最后拼装在一起,类似于拼图模式。

而我们采用的是一种滚雪球的方式:把所有需求列出来后,抓住最核心的需求优先开发。到了下一冲刺,再根据已开发的核心需求,看其周边需要或配套的需求进行开发。在冲刺1,团队开发出一个,基础可以用的产品,冲刺2后,弄出一个略微丰富的产品。到了冲刺3,开发出一个好用的,功能丰富的产品。


个人经验

以下这些经验,主要偏向作为项目经理的思考的。

不过现在是这些想法,过个一段时间,可能我就不这么想了。

在冲刺或迭代启动会时,那份启动文档,一定要写明此次迭代(或冲刺)的目标。比如:为了让XX功能使用起来、将XX页面展示、显示xx信息等。这么做的好处是,在冲刺总结会时,可以用来评审此次的冲刺是否成功,也有利于总结文章。

偏差管理。如果项目组员在执行工作项(尤其是开发人员),后来发现和项目指定计划有偏差,不要立即“批评”组员的开发错误。而是,先询问其处理偏差的原因,若是反馈因为沟通理解的原因,可以记录下来(主要记录在哪个点上沟通出现问题),防止下次项目再犯。若是由于组员有自己的思考理解,“有意”处理成这样。要先鼓励他,项目经理表明自身的态度,欣赏他有独立思考能力,然后再沟通,进行“纠偏”。若是当时不小心气上头,骂了组员,后面私下抽空(最好是次日),可以沟通下“自己回去又想了下,你说的也有道理。不过,目前的项目应该是xxx”。道理很简单,每次做完一个项目,项目成员都应该有成长,无论是你引导的,还是他自发的,否则他永远不成长,你就永远要每次划分很细工作项,时刻盯着他。

以下是我们在执行敏捷开发时,遇到的问题:

        1. 工作项在实际开发拖拽使用时,由于开发人员对单独模块不了解,所以几个项都一并开发(比如,把一个页面拆分成了四个工作项:顶部工具栏、中部banner显示、左侧tab面板、中间状态列。开发人员,在开发时,非先单独开发完【顶部工具栏】,再去开发【中部banner显示】,而是在搭建整个页面时,每项都有涉猎)。造成项目经理在看迭代版(故事墙)时,看到某个开发人员有好几项都在并线开发,然后这几项周期显得很长。

A:我们考虑,在开发某些工作项时,尤其是有关联关系的工作项,优先将目前手上,正主力开发的工作项拖动到【开发中】   故事列,等这一项完成了,又着手关联的那个工作项时,再将其拖入到【开发中】

         2.工作项优先级和开发顺序的理解。在分析阶段,某个工作可能就是一个需求点A,觉得比较重要就会用高优先级标识。而在后面开发时,为了实现【工作项A】,要先去开发优先级低的【工作项B】。如果一个冲刺里,有大量的这种A/B矛盾,后面在时间点不够下,对于需求砍断很棘手

A: 在将需求点进行设计,并拆分为工作项时,要有个技术把关,知道哪些工作项要拆分的重点。并且,在项目时间不充裕的情况下,要进行每日站立会议,目的就是为了及时反馈开发人员,真正在开发的工作项,帮其处理这些A/B优先级问题。

       3.前期项目经验不足,或者对开发人员能力评估不够,冲刺里工作项如何合理安排?才能按时高质量完成项目?

A:进行冲刺安排工作项时,优先安排一整个完整业务单元的相关工作项。如果时间点确定(基本也是冲刺的出发点,短时高效),那工作项安排上宁多勿少,可以将下轮冲刺的部分工作项安排进来。因为安排工作项也是个费时费力的活,宁可到时间点,开发人员对于部分工作项未完成,也不可提前完成冲刺(除非该冲刺是最后一轮)。

      4.项目报告该怎么写?中期报告关心哪些内容?

A:这里提供一个我使用的范本。总共就报告三个方面:1.目前项目进度 2.后续计划 3.总结。其实和像老板汇报工作差不多,具体怎么汇报,有在如何向老板汇报工作?介绍过。这里说下,项目经理在汇报时,总结可以当部分问题反馈写,但是在你写问题反馈时,如果是具体的问题,一定要将自己的处理方案写入

     5.在敏捷开发过程中,前期的分析时,对于一些很细小的操作业务点可能没有提及,开发时才暴露这个业务问题。而且询问时,也是琐碎的询问。可能是问题类别也可能是询问时间,东一榔头,西一棒槌的。

A:问题的产生,由于分析时没有分析那么透彻,详细。当然要想避免这个问题,就要很牛逼的分析师,庖丁解牛的那种。不过,大多数情况下,都难以做到。我们采取的方案就是,将问题先记录下来,每个冲刺里都建立一个业务问题的记录文档,出现的问题记录后,在回答,同时再在文档里记录处理方案,等到站立会或中期汇报时再讨论。简单来说就是,(如果问题很小)先拿出一套解决方案,把项目继续进行下去,后期再细究这种问题。如果是很核心业务,那一定要验证真正需求,征求拍板人意见。

    6.敏捷开发的项目看板里,要把缺陷独立循环在体外吗?

A:原本在初版设计时,我们也是这么想的。像很多SASS产品一样,把缺陷独立于敏捷开发的项目看板外,项目看板仅是开发需求。但是,在实际使用过程中,如果一开始做了足够的分析,或者把工作项拆的合理点,那 看板中的工作项,就是当前迭代(冲刺)的功能说明列表,测试人员也仅需根据此列表比对测试,并在里面填写测试描述就行了。

所以,一个工作项就三种类别:开发、缺陷、改进整个团队人员只要关注一件事务即可,相关人员也可以直观地看清,哪些有缺陷,哪些要改进,在站立会议上,也不用切来切去了。 但是,这样也有缺陷,在不以缺陷为绩效考核的公司,可以这么干,如果涉及到 缺陷跟绩效挂钩,那这相关,在后面统计绩效时,就可能比较麻烦。

禁止转载使用

       7.在敏捷开发的过程中,优先关注哪些?是bug?是需求?还是用户反馈? 

 A: 大多数人第一反应是 【需求】,包括我自己,第一反馈也是如此。但经过这次我们自己去做敏捷开发的工具(加上听了某大厂产品经理的分析),感觉用户反馈真的是第一位。首先,做出产品就是给用户用的(无论2C,还是2B,亦或是自己家用的)。因为是给自己做工具(自己做,更顺手),所以对公司内使用员工感受,信息反馈更注重。根据他们的反馈即时调整下一轮冲刺的开发方向,才会使产品做出来的,让大家觉得更方便,好用。

部分参考资料:

arnoldwang,《创业团队的项目管理,如何面向开发人员优化》 

Scrum敏捷开发简介

阅读数 18064

.NET的几个名词解析

阅读数 1492

没有更多推荐了,返回首页