ASP.NET Core分布式项目实战

默认教学计划
1094人加入学习
(33人评价)
价格 ¥398.00
教学计划
Scrum
 
然后呢,我们再来看一下敏捷呢,它是一个抽象的概念,也就是说在敏捷的下面呢它有好几个分支,
它有一个叫看板,还有一个叫Scrum,这个都是敏捷呢抽象出来下面的一个具体的一些实现,
它会给一些更具体的一些指导原则,那么其中Scrum也是比较典型的,所以,
我简单给大家讲一下,然后大家可能会,因为你自己现在不会开始,
你如果真正要做这个项目管理的话,可能还需要做一些正规的培训,而这个时候你大概可以看,
就是你现在的团队当中的项目经理或者是如果在做这个Scrum开发的话,他们是如何运转的,
你们开始要去思考一下整个团队的这个效率,他们所开发的这个效率,我是高还是低,
或者是说整 个开发团队的效率是否还能够改善,我们通过什么样的方式去改善,
是改善流程还是改善工具或者是说平台,这个东西,如果大家有思考,就会去找到一些解决方法来去实践,
这个也是你能力提升以及在公司和团队当中得以加薪升职的一个机会,
 
在这个Scrum模式下呢,会有一个叫角色,一些角色,这些角色其中一个呢叫产品负责人,
这个负责人一般是这个产品的一个老板,或者是主要提需求的人,就是希望这个产品达成什么样子的这个人,
 
第二个是Scrum Master,主管,这个主管有时候会由那个项目经理来承担,或者是有时候由一个企业它的人,
不在这个项目里的这个人来承担,这个Scrum Master的角色呢,
就是他的主要的作用是为了保证整个团队以Scrum Master的形式来工作,
比如说在进入开发模式的时候,不让产品经理改需求,这个也是他的职责之一,
同时呢,比如说召开每日的这个会议,让大家定时去参与,让大家不要在会议上说一些多余的话,
这个都是他的一些角色
 
然后最后一个角色就是开发团队,那这个里面其实不分开发、测试或者是谁,整个所有的这个开发的Team的团队,
大家会一起去把整个事情完成,
 
那么,在工作当中呢我们主要会涉及到的一些是用户故事,那么这个用户故事就是其实是我们之前所讲的需求,
但是呢我们没有描述的这么清楚的需求文档,给大家来举个简单的例子就是,这个用户故事可以是一句话来描述清楚他的需求,
主要来说你可以从角色和行为来表现,比如说我们要做一个登录,
这个登录就可以说是我们注册用户和未注册用户都可以通过手机验证短信来实现登录,这就是一个简单的需求,
那这个作为一个用户故事呢,我们开发人员会开始对它进行一些任务的拆解和编码测试,上线之类的,
 
那么后面的产品订单呢就是所有的一些待开发的一些用户故事都会放到这个里面,放到Backlog就是产品订单里面,
 
然后还有一个冲刺订单,也就是说我们会分迭代周期,比如说我们是一周一个迭代周期的话呢,
会把所有的这一周内要开发的用户故事放到这个一个桶里面,叫做冲刺订单,也就是这些需求是我们这一个星期要做的,
而Scrum Master在这里会体现出来就是我们在迭代开始之前我们会先确定这一个周内我们要开发的用户故事是哪一些,
然后定好之后就不再允许发生变化,我们就保证这一周把这一些用户故事开发完成就可以了。
 
而这个冲刺燃尽图就是说,我们会在最开始的时候评估一下每一个,再把用户故事拆成细分,细的一些任务,
而这些任务数量以及时间的一些评估呢,最开始会有一个总和,然后在燃尽图上就是每天会去更新你到底还剩余多少,
每天剩余,大家看到下面这个图就是,从开始到结束,开始是最多到最后是变成0,也就是说我们全部完成,
而每天的变化呢都会体现在这个上面,大家可以看到这个蓝色的线,它是说理想的情况下应该是这个样子,
也就是说每天以一定,这个下滑的趋势呢是很均衡的,而这个红色就是实际的,就是越跟这个蓝色越贴合,
也就是团队工作的越好,也不会出现特别大的波动,就一直很平稳,
而出现上下乱窜的这种就是往往来说你对于用户故事的评估以及任务的评估都不是非常的合理,对,
 
然后,后面会有一些活动,计划会议呢就是我们每周会做一些关于迭代的一些计划,也就是我们会在迭代里面做什么,
所有的会议都是所有人一起参加,包括产品负责人,Scrum Master和整个开发团队,
我们需要了解我们这个迭代去开发哪些内容,
 
然后呢每日会议就是每天大家会需要整个团队碰在一起来看一下我们现在的进度是什么,
这个每日会议呢大概会有三个话题,一个是今天做了什么,昨天做了什么,就是,然后我现在遇到的问题,
所以它会把这个时间控制得非常短,整个会议会在15分钟之内,只讲这三件事情,
如果大家有遇到什么具体可以到会议下再去聊,最重要的是在这个会议上呢能够让每一个开发团队,每一个成员,
都能够了解我们的这个进度是什么样子的,
 
然后这边呢还有一个评审会,这个评审会呢就是我们会评审我们的这个User Story,以及它的一些时间的评估等等,
 
然后最后一个反思会议呢,就是在每一个迭代之后,在每一个迭代上线,这个迭代就是我们任务上线之后,
整个迭代上线之后,大家坐下来一起,可以用匿名的方式,然后用纸条写出每一个人所看到的优点和缺点,
就是以及好的地方和我们可以改进的地方,那好的地方我们继续保持,不好的地方呢整个开发团队商量如何去解决,
并且呢我们找到一个跟踪问题的人,持续去把这个问题给解决掉,一般在软件开发过程当中呢是不可能团队是没有问题的,
包括人的问题也好,流程上面的问题也好,都会有,但是最重要的是团队能不能够面对这些问题,共同去解决,
这个才是问题的关键,而在这整个过程当中,能够主导整个一切发生,带领团队向更好的方式去运作的这个人呢,
就可能是这个团队的Leader,就是大家首先不要在自己心理上给自己设限说,我只负责写代码,
而在这个开发项目过程当中你所掌握的其它的一些方面呢,能够涉及到的比较全面的话,
对将来我们每个人的发展都是非常有帮助的
 
Scrum流程
 
 
好,我们再来看一下大致的流程,在最开始的时候就是我们大概会有一个产品功能列表,这个是已经排出来的产品功能列表都会堆在这个地方,
然后在,它其实就是我们讲的用户故事,有很多的用户故事,
 
然后呢,在计划会议的时候呢,整个团队包括Scrum Master以及开发团队呢会对这个,从我们这个功能列表里边拿出一些优先级别比较高的,
作为一周的迭代或者是两周的一个迭代的开发任务,比如说是我们这一两周开发哪一些功能,按照这个团队能力,我们来开发这些功能,
就把这些需求挑出来,而挑出来后这个迭代就不可以再变动了,我们就是开发这些功能,直到完成上线。
 
而这个迭代过程当中呢,我们就会进行开发、测试、发布,不断地开发、测试、发布,在测试环境也好,就是不断地去工作,整个团队在一起
 
然后,到最后其实迭代上线,发布给用户之后,我们再进行回顾,我们看我们这个燃尽图上的一些表现,以及对于我们这个团队当中,
做的好和不好的呢,我们来进行一些总结,也可以叫做复盘,因为你如果不去复盘,不去总结的话,这个团队是很难去改进的
[展开全文]

软件开发模式

1、瀑布

里程碑、强调文档、强调分工、避免变化、谈判与计划

2、敏捷开发

迭代、文档要求低、协助和沟通、拥抱变化、与客户合作

[展开全文]

1. 瀑布模式,更适合需求变动小的项目。在实际项目中,把控好里程碑,防止流程间脱节。

2. 敏捷模式,更适合快速演化的项目。在实际项目中要加强交流,共享知识。提升自身拥抱变化。同时要避免抛弃架构,好的架构是演进的支持迭代的。

3. 无论项目组采用什么模式,要积极参与主动承担责任,项目成功是终极目标。

 

 

[展开全文]

 瀑布式开发:严格按照流程,规范化的开发过程,强调组织性,但后期无法轻易改动(涉及面很广)

 

[展开全文]

瀑布:里程碑,强调文档、分工,避免变化,谈判与计划

敏捷:

[展开全文]

授课教师

程序员

课程特色

下载资料(2)
视频(144)
讨论(1)
图文(2)