2019-12-28 20:32:40 Su_Levi_Wei 阅读数 36
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10436 人正在学习 去看看 CSDN讲师

建议先阅:https://blog.csdn.net/Su_Levi_Wei/article/details/89313778

建议先阅:https://blog.csdn.net/Su_Levi_Wei/article/details/94206222

 

无数疑问

在互联网行业中,我们常常会听到敏捷开发这个词,但敏捷开发是什么,我们是否真的需要敏捷开发这个东西?即便真的需要敏捷开发这东西,要怎么去用好这个东西?用这个东西之前有没有条件?和以前的瀑布流开发有什么区别?

       最重要的是这东西是否真的适合当前的团队?

       ……

 

瀑布流开发(传统)

       在这种管理方式中,可以发现,就跟工厂的流水线那样,一环扣一环,因此我更喜欢称为流水线。

       在这种管理方式中,可以发现有着很严重的问题。后面的人要等待前面的人做完,在前面的人没有做完时,后面的人就会一直空闲着,前面的人做完了,后面的人就会很忙碌,这时就变成前面的人很空闲。

       有人会想,这个问题很好解决。

       前面的人做完了,就给下一个项目的任务给他,或者是给别的任务给他,问题在于这个人做完了,空闲下来了,此时你分配别的任务给这个人时,测试刚好测出了问题,这时又问题,刚分配的这个新的任务如果没有做完,后面的人又要等待。如果测试测出的问题不去解决,在这个问题涉及的流程中就要停下来了,因为测不了了……

       就这样一直循环时,就会造成测试很累、开发很累。

       随着如此循环的次数越多,等待的时长也相应的增加,最后项目顺理成章的延期了。        项目管理者很头疼,要去忽悠忽悠客户,解释解释原因。

       当然了,一个项目造成延期的因素是由很多,这里只讨论管理模式的不同造成的问题。

 

       在来看看一个开发的例子:

       需求:在年底时统计过去一年的信用卡账单时。

       环境:单月的账单存储在MongoDB数据库,双月的存储在MySQL数据库。

       最简单的实现:如果是先查询出第一个月的,再查询出第二个月的账单,第三个月……如此循环。这种实现方式的问题在于每次都要等待,12月要查询12次,会产生12次的等待间隔时间。

       优化:采用多线程工作的方式,开12个线程同时进行查询,只有12个线程都执行完了,在执行12个月的累加逻辑。(JavaAPI:CountDownLatch)

       现实生活:企业年底财务报告,一个财务人员要先计算出过去每一个月的开销,最后累加得出结果。这样的效率自然是很慢,如果是让12个财务人员,每个人都负责计算出那一个月的,最后把大家计算出来的数值进行累加,这样总比一个人来统计要快。

       需求变更:

       在现实生活的例子,如果在统计到一半时,财务主管说,企业年底财务报告中不需要统计今年企业开销的总金额了,改为统计企业今年在出差补贴中的总金额。

       如果是一个财务人员的话,假设此时统计到了三月份的企业开销总金额,只需要重新来过就可以了,只影响到她一个人。

       如果是12个人来统计的,影响的是12个人。

      

       在这些例子中,我们可以发现,效率很低下,已经无法适应现在节奏越来越快的商业环境了。特别在互联网企业中,对企业内部管理运营效率的要求性是非常高,因互联网企业中,人员就是最大的成本。(一家200人的互联网企业中,每年的固定支出最少是5000万)

      

在类这些情况下,作为项目管理者自然会想,既然这样,是否可以用类似开发的这种多线程的方式的呢?

       很快就有人提出了敏捷开发,我更喜欢称为快节奏管理模式或敏捷管理方式。因为这是针对一个互联网项目的全生命周期的一种管理方式,难道一个互联网项目的全生命周期的关联仅仅只有开发?

       或许有人说,这只是一个名词。不需要在意,但作为一个项目管理者,科学性、严谨性是非常重要,这将是你能否掌控好一个项目的基础。

 

敏捷管理方式

      

       在这张图中,似乎就跟上面的例子那样,变成同步去做一件事。

       上面那张看的大家可能会有点懵,那么看下面那张,在统计一年的账单中可以发现,每个月的账单计算是同步进行,最后做一个总金额的累计。不在向之前那样,是一个月计算完了,在计算下一个月的。这样的速度自然是快了。

       所以,一直在说的敏捷开发就是把一个项目进行拆分,尽量的以小任务同步进行,减少中间等待和停顿时间

       敏捷管理方式会导致的问题有哪些?为什么会导致这些问题?

       没有什么比实际项目应用更有趣的,下面我们就用一个模拟项目实例来看看。

 

商城项目

 

项目计划(以下仅为模拟,实际的项目计划中是细到如添加、更新等功能的开发时间):

负责人

功能模块

时间

说明

前端人员A

订单管理

20191111 ~ 20191113

1、按照与后端人员A约定的接口进行开发,20191115进行联调

后端人员A

订单管理

20191111 ~ 20191116

1、按照约定提供数据给前端人员A,20191115与前端人员进行联调

2、20191116这一天需要与后端人员B进行联合调试,走通订单流程

后端人员B

支付与物流

20191111 ~ 20191116

1、先模拟假定数据进行开发

2、20191116这一天需要与后端人员A进行联合调试,走通订单流程

测试人员A

订单管理UAT用例文档

20191111 ~ 20191113

1、按照产品要求编写测试用例(预知条件、验证步骤、期望结果等等)

2、编写的测试用例需要产品、开发保持信息同步

测试人员B

支付、物流UAT用例文档

20191111 ~ 20191113

1、按照产品要求编写测试用例(预知条件、验证步骤、期望结果等等)

2、编写的测试用例需要产品、开发保持信息同步

 

窥见:

       项目开始时间几乎都是同步进行的(这只是模拟,一般项目会分期进行)。

       需要时刻的保持信息同步,即每个人都需要知道对方的进度,这也是为什么会有晨会的原因(建议争取10分钟内结束晨会)。

       项目所有成员需要不止需要了解自己的功能需求,还需要了解项目内其他成员的需求

       对每一位成员都要求有清晰的沟通能力,及对成员之间的默契(建议阅:https://blog.csdn.net/Su_Levi_Wei/article/details/103276666)。

       每一位成员之间的关联度非常高,项目成员可能都会异常的紧张,这可能会导致团队内部和谐问题或个别问题

       ……

 

影响:

       需求更改:由于已提前分配好任务了,在这个过程中出现的需求更改将会影响到涉及这个业务的所有人员(前端、后端、测试),甚至是整个项目团队,而后各自还要进行信息同步,及确认项目计划是否变更,计划变更的影响范围……因此对产品经理有较高的要求,需对项目行业市场、背景、需求理解需要较为深刻

       休假/出差:人员休假/出差,将会影响整个项目计划,如有必要需要进行整个项目团队的计划变更,并进行信息同步(目前大部分都是让请假的开发周末跑回去加班)。项目经理在进行项目计划规划设计时,就需要充分考虑这方面的问题,建议在做项目计划时每周预留出空闲的一天(提前完成还可以领工)。

       其他事故:开发数据库服务器出问题了,修复花了某位开发人员半天的时间,目前大部分都是让这位开发加班去完成当天的任务。这体现出对项目经理的要求更高了,因此这也是为什么谷歌在招募产品经理时会要求产品经理必须有编码经历(对于整个项目周期和某需求周期产品经理了解是最清楚的,产品经理通常会担任项目经理)

       任务拆分的不够细:将会导致项目计划所设定的时间与实际需要的完成的工时是不一致的,这种情况通常是发生在项目经理没有对团队人员有充分的认识、认知,对领取到这个任务的成员的能力不够了解(每家企业评级标准不一),或是对需求理解偏差。也进一步解释了为什么产品经理会担任项目,产品经理最好是有过编码经历,及需要对项目每一位成员的能力非常清楚。

       标准不明确:没有标准,即没有方向。开发人员和测试人员是否可以理解为只是做了这个功能就可以?不需要去考虑效率等其他问题?可能有的会说这也是成员个人积极性的问题,但这难道不是产品经理及架构师与项目方沟通时,忽略了性能标准?项目经理对缺少的这部分也不觉得疑惑吗?作为一名管理者,反省自身问题比寻找他人问题更重要。

       ……

 

敏捷管理方式模板

 

基本功课:

       每日晨会(建议争取10分钟内结束晨会):对昨日的工作进度、问题的总结,也是了解其他成员的工作进度机会(特别是这种团队同步进行的工作),及清晰的描述今日工作。

       每周周列会:对这种的工作进度、问题的总结,也是了解其他成员的工作进度机会(特别是这种团队同步进行的工作),及清晰的描述下周工作

       成员周报:清晰的描述这周及下周的展望。

       清晰的里程碑目标:每一位成员都要清楚的知道自己做的事情有什么意义?

       清晰的项目目标:每一位成员都要清楚的知道这个项目的目标?在这个目标面前,自己能够做的了什么?自己能够有什么成长?只有自身获益,才能令自身全身心的投入。

       ……

 

敏捷管理方式-需求下放涉及内容

总结

       敏捷开发就是一个不断拆分需求任务,尽量让每一个需求任务能够同步进行。

       产品经理的要求较高,不仅只是出个高保真和PRD文档,还要求对此产品市场、背景及对产品、市场的敏感度都有一定的要求。

       项目经理的涉及的知识面要求较广,对项目的把控灵活度能力较高。

       团队的默契,及对团队每个成员都有需要具备一定的要求(如沟通能力、清晰的文档撰写表述能力)。

       团队每位成员都需要清楚、清晰的知道项目计划的弹性,及项目方在实施、运营此项目时的过程。

       在如此紧张的情况下,对整个项目团队内部气氛的调和,更显得异常重要。

 

       在国外和国内都有很多敏捷管理方式的成功案例,但只要仔细观察,可以发现这些成功案例的共同点,都在于团队的兼容性、默契性、成员素质高。

       作为一名基层人员,常常看到很多文章,某某大牛又在说敏捷管理方式的好处了,但敏捷管理方式是否真的适合你们的团队,这个有待商榷。目前为止看到过的大牛在讲敏捷管理方式时,都没有讲到怎么去判断这个管理方式是否适合你的团队。

因此,我认为如果你把仅仅是以上列出来的问题解决了,那么你可以尝试去使用。否则在这些显性问题都无法解决的情况下去使用,在使用过程中在去解决,可能整个团队的心都散了。

2012-06-25 18:21:54 iteye_14109 阅读数 319
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10436 人正在学习 去看看 CSDN讲师

     软件开发方法一直处在不断发展过程中。在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升势头明显。那么,敏捷开发有什么好处呢?

 

    在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。在欧美软件企业中,有近半数企业已采用敏捷方法进行开发,而近几年受软件外包和外企的带动,敏捷开发在中国也出现了日渐普及的态势,如腾讯内部几乎所有的开发团队都在实施敏捷方法。敏捷开发的流行绝非偶然,其最大的推动力是采用这种方法所能带来的受益。相关统计表明,敏捷开发可以将效率提高3~10倍,软件的质量也有更加可靠的保证; 同时,还给团队内的每个成员提供了良好的发展机会,技术和合作水平都能得到相应提高。当然,敏捷的成功前提是其方法本身的适用性和团队对它的深入理解和合理运用。
 
    敏捷开发由几种轻量级的软件开发方法组成,包括极限编程、Scrum、精益开发(Lean Development)、动态系统开发方法、特征驱动开发(Feature Driver Development)、水晶开发(Cristal Clear)等等。所有这些方法都具有以下共同特征,它们也是敏捷开发的原则:

    1. 迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期持续的时间一般较短,通常为1到6周。

    2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,每次交付的都是可以被部署、能给用户带来即时效益和价值的产品。

    3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。

    4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。有些是在每个迭代周期结束的时候集成, 有些则每天都在这么做。

    5. 开发团队自我管理。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。
 
    敏捷开发的优势:

    满足用户不断变化的需求是软件开发的长期无法解决的难题之一,经典的瀑布模式在一个迭代周期内表现优异,但一旦需求变化,瀑布模式却显得无能为力。敏捷方法满足需求的办法主要通过迭代。在每一次迭代周期结束时,都能交付用户一个可用的、可部署的系统,用户使用并体验该系统并反馈意见,在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应尽可能短,以便能及时地处理需求变化和用户反馈。
 
    敏捷开发方式能给企业和用户带来以下好处:

    1. 精确。瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑,每走完一步再调整并为下一步确定方向,直到真正的终点。

    2. 质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等,甚至使用测试驱动开发(test-driven development),即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。

    3. 速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外,较短的迭代周期使团队成员能迅速进入开发状态。

    4. 丰厚的投资回报率。在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率。

    5. 高效的自我管理团队。敏捷开发要求团队成员必须积极主动,自我管理。在这样的团队中工作,每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。
 
    主要的敏捷方法:

    敏捷开发方法是一组开发方法的统称,主要包括以下几种:

    极限编程其主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法,并将它们发挥到极致,结对编程(pair-programming)就是其中比较知名的方法之一。除此之外, 其核心做法还有小规模、频繁的版本发布、短迭代周期、测试驱动开发、持续集成、每日站立会议、共同拥有代码、系统隐喻等。

    Scrum Scrum是一个敏捷开发框架,它由一个开发过程、几种角色以及一套规范的实施方法组成。在Scrum中,产品需求被定义为产品需求积压(product backlogs)。所有的产品需求积压都是从一个简单的想法开始,并逐步被细化,直到可以被开发的程度。Scrum将开发过程分为多个Sprint周期,每个Sprint代表一个2~4周的开发周期,有固定的时间长度。

    精益开发精益开发的核心思想是查明和消除浪费。在软件开发过程中bug、没用的功能、等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明,然后设法消除。精益开发的其他原则包括强调学习、在最后时刻做决定、用最快的速度交付用户等。

    其他敏捷方法还包括动态系统开发方法(DSDM)、特征驱动开发(FDD)、Crystal Clear等,各种敏捷方法的区别在于它们对敏捷的不同阐释和不同侧重。理解这些方法可以帮助我们从多个角度理解敏捷开发,并且了解更多的最佳应用。
 
 
如何选择一种敏捷方法:

    选择一种合适的软件开发方法取决于多种因素。在做出决定之前,我们需要充分考虑以下这些方面:

    1. 方法的复杂度。确保你的团队或组织能够应付这种复杂度。

    2. 社区和业界支持。有较多的社区及行业支持可以使你受益匪浅。

    3. 实用工具。一个良好的软件工具可以帮助团队有效地处理日常工作,促进团队协作,并减少管理成本。

    4. 对敏捷方法的认识程度。选择一些与你当前开发方式比较接近的敏捷方法将有助于推动该方法的实施。

    5. 你的团队规模。较小规模的团队最好从简单的方式入手。

    6. 你不需要只遵从一种方法。你可以为团队选择一个主要的方法(如Scrum),然后借鉴其他方法。

 

2019-04-12 22:52:55 y_279611480 阅读数 561
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10436 人正在学习 去看看 CSDN讲师

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:此文内容,部分摘抄至互联网,如若,原文博主介意,可私聊。谢谢。
自然,此文并不完善,欢迎各位点评。

2019-01-08 03:16:49 weixin_34059951 阅读数 99
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10436 人正在学习 去看看 CSDN讲师

敏捷软件开发

敏捷是世界上使用最广泛,最受认可的软件开发框架之一。大多数组织已经以某种形式采用了它,但是在采用计划的成熟度方面还有很长的路要走。本系列教程的唯一目的是将技术和非技术专业人员融入敏捷世界。

我们将逐步引导您完成敏捷之旅,直到您了解使用敏捷背后的理念,优势以及如何实践它。本系列旨在使读者能够将敏捷和Scrum学习应用到他们的工作中。这个特别的教程专门向您解释为什么需要敏捷以及如何创建它。这里的基础是让您了解软件开发行业中敏捷采用的概念。

敏捷的历史

敏捷出生在一个晴朗的日子,当时有17个人具有不同的开发方法背景,在一起探索可能的替代软件开发解决方案,可以共同进行头脑风暴,寻求可能会缩短开发时间并减少文档的需求量。

当时,软件开发过去发生的时间太长,以至于当项目准备交付时,业务已经向前发展,需求已经发生变化。因此,即使项目能够实现其既定目标,也无法满足业务需求。

因此,这些不同软件工程技术的精英聚集在一起,他们会议的最终结果就是他们所谓的“敏捷宣言”,我们将在本系列的下一个教程中详细讨论。

但是那天出生的敏捷并不是我们今天在组织中看到的。专家们同意的方法被称为“轻量级”且速度快。但是,本次会议的主要成果是认为更快的产品交付和持续的反馈是实现软件开发成功的关键。

现有的瀑布技术过于繁琐,在最终产品准备交付之前没有提供反馈。这意味着没有进行要求修正的余地,并且在整个产品准备好之前,客户对进度没有任何看法。这就是这些专家想要避免的。他们想要一个能够持续反馈的解决方案,以避免后期返工的成本。

clipboard.png

敏捷挑战

当时现有的瀑布技术过于繁琐,在最终产品准备交付之前没有提供反馈。它被称为开发的瀑布模型,因为团队首先完成了一步,然后才进入下一步。

这意味着没有进行要求修正的余地,并且在整个产品准备好之前,客户对进度没有任何看法。这就是这些专家想要避免的。他们想要一个可以持续反馈的解决方案,以避免在以后阶段返工的成本。这就是为什么敏捷也是关于自适应和持续改进的原因,同时也是关于持续反馈和交付速度的原因。

clipboard.png

什么是敏捷承诺?

敏捷承诺

敏捷不仅仅是在开发软件时应用设定的实践。它还带来了团队思维方式的变化,这促使他们构建更好的软件,协同工作并最终让他们成为一个满意的客户。

敏捷的价值观和原则使团队能够转移他们的注意力并改变他们构建更好软件的思维过程。

敏捷到底是什么?

clipboard.png

敏捷不是一套规则。敏捷不是一套指导方针。敏捷甚至不是一种方法论。相反,敏捷是一套原则,鼓励灵活性,适应性,沟通和工作软件超越计划和流程。它在所谓的敏捷宣言中非常简洁地被捕获。

敏捷软件开发使团队能够在开发复杂项目时更有效地协同工作。它由练习迭代和增量技术的实践组成,这些技术很容易被采用并显示出很好的结果。

在将敏捷应用于行动中,我们有各种基于敏捷的方法去满足软件开发行业的所有需求,从软件设计和架构,开发和测试到项目管理和交付。

不仅如此,敏捷方法和方法还为流程改进打开了一个范围,作为每个交付的一个组成部分。

敏捷是一种软件开发的实践理念,建构一个自给自足且跨职能的团队致力于通过迭代进行持续交付,并通过收集最终用户的反馈在整个过程中发展。

如何练习敏捷?

各种多样化行业都有各种敏捷方法论。

clipboard.png

然而,所有这些方法中最流行的方法是:

  • Scrum
  • 看板 (Kanban)
  • 极限编程 (XP)

所有这些方法都侧重于精益 (Lean) 软件开发,并有助于有效和高效地构建更好的软件。

这就是敏捷引言的全部内容。该部分的结构旨在帮助您了解团队在敏捷模式和思维模式下工作时应采用的核心价值观和原则。


敏捷方法论和模型

敏捷方法论简介:

众所周知,敏捷是一种软件开发方法。我们还了解了敏捷创始人在敏捷宣言中提到的价值观和原则。在我们最初的讨论中,我们还避开了敏捷和传统瀑布模型之间的差异。在本教程中,我们将了解敏捷方法的优缺点。

我们会看到什么是scrum?它与敏捷有何不同?然后我们将了解不同组织正在使用的各种敏捷方法,以及如何使用它们实现敏捷。您还将能够理解这些方法的不同之处以及优缺点。

敏捷方法论的优点

下面给出了敏捷方法的各种优点:

  • 客户在每次迭代 (iterative) /冲刺 (Sprint) 结束时不断获得项目进度的外观和感觉。
  • 每个sprint都为客户提供了一个工作软件,该软件根据他们提供的完成定义满足他们的期望。
  • 开发团队对不断变化的需求做出了很好的响应,即使在开发的高级阶段也能适应变化。
  • 持续的双向沟通​​ (feedback) 使客户参与其中,因此所有利益相关者 (Stakeholders) - 业务和技术 - 都能清楚地了解项目的进展情况。
  • 产品设计高效,满足业务需求。

敏捷方法论的缺点

虽然敏捷方法有几个优点,但它也有一些缺点。

他们是:

#1)不希望使用全面的文档,这会导致敏捷团队错误地解释这一点,因为敏捷不需要文档。因此严谨性会因文档而丢失。应该通过不断询问自己这是否是足够的信息来避免这种情况。

#2)有时,在项目开始时,要求并不十分清晰。团队可能会继续发现客户的愿景已经重新调整,在这种情况下,团队需要整合许多变更,而且很难衡量最终结果。

敏捷方法的类型

世界各地都有几种敏捷方法。我们将详细了解最受欢迎的四个。

clipboard.png

#1)Scrum

Scrum很容易被认为是最流行的敏捷框架。“scrum”一词被大多数从业者认为是“敏捷”的同义词。但这是一种误解。Scrum只是您可以实现敏捷的框架之一。

Scrum这个词来自体育橄榄球 (Rugby)。球员们在一个互锁的位置挤在一起推着对手。每个球员在他们的位置上都有明确的角色,并且可以根据情况的需求发挥进攻和防守的作用。

同样,IT中的Scrum相信赋予自我管理的开发团队有三个具体且明确定义的角色。这些角色包括 - 产品负责人(PO),Scrum Master(SM)以及由程序员和测试人员组成的开发团队。它们在迭代时间盒装持续时间中一起工作,称为冲刺。

第一步是PO创建产品待办事项。这是scrum团队要做的事情的待办事项列表。然后scrum团队选择优先级最高的项目并尝试在称为sprint的时间框内完成它们。

记住所有这一切的更简单方法是记住3-3-5框架。这意味着scrum项目有3个角色,3个工件,5价值 和5个事件。

这些是 -

3 角色: PO,Scrum master和开发团队。

3 工件:产品Backlog,Sprint Backlog和产品增量。

5 价值: 集中,勇气, 开放性,承诺,尊重。

5 事件: Sprint,Sprint计划,Daily Scrum,Sprint评论和Sprint回顾。

clipboard.png

我们将在后续教程中更详细地了解每个内容。

#2)看板 (Kanban)

看板是日语术语,意思是卡片。这些卡包含要在软件上完成的工作的详细信息。目的是可视化。每个团队成员都了解通过这些视觉辅助工作要完成的工作。

团队使用这些看板卡进行持续交付。就像Scrum一样,看板也可以帮助团队有效地工作,并促进自我管理和协作的团队。

但是这两者之间也存在差异 - 比如在scrum sprint期间,团队正在处理的项目是固定的,我们无法向sprint添加项目,而在看板中,如果有可用容量,我们可以添加项目。当需求经常变化时,这尤其有用。

同样,另一个区别是,虽然scrum已经定义了PO,Scrum master和开发团队的角色,但是在Kanban中没有这样的预定义角色。

另一个不同之处在于,尽管scrum建议对产品待办事项进行优先排序,但看板没有这样的要求,而且完全是可选的。因此,看板需要较少的组织并避免非增值活动,并且适用于需要对变化做出响应的过程。

#3)精益 (Lean)

精益是一种专注于减少浪费的理念。它是如何做到的?

在精简中,您将流程划分为增值活动,非增值活动和基本的非增值活动。任何可归类为非增值活动的活动都是浪费,我们应该尝试在过程中消除这种浪费,使其更加精简。

更精简的流程意味着更快的交付和更少的工作浪费在任务上,这无助于实现团队目标。这有助于优化软件开发周期中的每个步骤。这就是精益原则从精益制造转变为软件开发的原因。

通过应用以下所示的七项精益原则,可以在任何IT项目中使用精益软件开发:

clipboard.png

正如他们的名字所暗示的,这些都是不言自明的。消除浪费是第一个也是最重要的精益原则,我们看到了如何做到这一点,我们只是将活动分类为价值和非增值。

非值添加活动可以是代码的任何部分,可能使其不那么健壮,增加所涉及的工作量并占用大量时间而不添加合理的业务价值。它也可能是模糊的用户故事或不良测试或添加大图中不需要的功能。

第二个原则放大学习再次易于理解,因为团队需要各种技能,以在快速变化的环境中提供产品,新技术可以在短时间内出现。

做出迟到的决定可以在减少返工的情况下获得回报,就像预期会有任何变更,然后更好地延迟,以便团队不必在业务需求变化时重做工作。

但是这里总是存在一种权衡,因为团队需要平衡这一点与提供更快速的第四个原则。推迟决策不应影响整体交付,也不得减少工作节奏。一只眼睛应该始终在完整的画面上。

赋予权力的团队现在也非常普遍,这甚至是敏捷的建议。赋权团队更负责任,可以更快地做出决策。拥有权力的团队的所有权意识可以带来更好的结果。为了赋予团队权力,应该允许他们自己组织并自己做出决定。

因此,我们看到精益和敏捷有很多共同之处,只有一个明显的区别 - 精益团队可以帮助改进产品,敏捷团队就是实际构建产品的团队。

#4)极限编程(XP)

clipboard.png

极限编程是另一种最流行的敏捷技术。根据extremeprogramming.org,第一个XP项目于1996年3月6日开始。他们还提到XP以五种不同的方式影响软件项目开发 - 沟通,简单,反馈,尊重和勇气。这些被称为XP的值。

其中,一切都始于沟通。XP团队定期与业务团队和其他程序员协作,并从第一天开始构建代码。这里的重点是在其他视觉辅助工具的帮助下尽可能地进行面对面的交流。

极端程序员还会构建一个简单的代码,并从第一天开始获得反馈。重点是不要过分或预测尚未共享的要求。这使设计简单,只生产出满足要求的最小产品。

反馈有助于团队改进并提高工作质量。这有助于他们在彼此学习的过程中建立对彼此的尊重,并学习如何分享他们的观点。

这也给了他们勇气,因为他们知道他们已经收集了每个人的最佳想法,并根据其他人的反馈产生了一个好的产品。因此,他们也不害怕包含变更或收到有关其工作的进一步反馈。

这在需求经常变化的项目中特别有用。持续的反馈将帮助团队以勇气包含这些变化。

因此,我们已经看到了不同的敏捷方法,如Scrum,XP,看板和精益,以及它们各自的优缺点。

现在,我们可以轻松区分它们,也欣赏它们之间的微妙差异。我们还了解了每种方法的基本原理,并了解了如何在需要时将它们应用于我们的项目中。

在下一部分中,让我们了解Scrum的一切。


Scrum框架 (Scrum Framework)

SCRUM是敏捷方法中的一个过程,它是迭代模型和增量模型的组合。

传统瀑布模型的主要障碍之一 是 - 在第一阶段完成之前,应用程序不会移动到另一阶段。而且,如果在周期的后期阶段发生一些变化,那么实施这些变化就变得非常具有挑战性,因为这将涉及重新审视早期阶段并重做变更。

SCRUM的一些关键特性包括:

  • 自我组织和专注的团队。
  • 没有巨大的要求文件,而是有一个非常精确和重点的故事。
  • 跨职能团队作为一个单元一起工作。
  • 与用户代表密切沟通以了解功能。
  • 有一个最长一个月的明确时间表。
  • Scrum不是一次完成整个“事物”,而是以给定的间隔做一些事情。
  • 在提交任何内容之前,会考虑资源功能和可用性。

要很好地理解这种方法,理解SCRUM中的关键术语非常重要。

重要的SCRUM术语

1)Scrum团队

Scrum团队由7人组成,其中包括+或 - 两名成员。这些成员是能力的混合体,由开发人员,测试人员,数据库人员,支持人员等组成,还包括产品所有者和Scrum主管。

所有这些成员通过紧密协作一起工作,以递归和确定的间隔,开发和实现所述特征。SCRUM团队的坐姿安排在他们的互动中起着非常重要的作用,他们从不坐在小隔间或小木屋里,而是一张巨大的桌子。

2)冲刺 (Sprint)

Sprint是预定义的时间间隔或时间范围,其中必须完成工作并使其准备好进行审查或准备进行生产部署。这个时间框通常在2周到1个月之间。

在我们的日常生活中,当我们说我们遵循1个月的Sprint周期时,它只是意味着我们在任务上工作了一个月,并准备好在该月底之前进行审核。

3)产品负责人 (Product Owner)

产品所有者是要开发的应用程序的主要利益相关者或主要用户。产品所有者是代表客户方的人。他/她拥有最终权力,应始终为团队提供。

当任何人有任何需要澄清的疑问时,他/她应该可以到达。对于产品所有者而言,了解并且不在sprint中间或sprint已经开始时分配任何新要求非常重要。

4)Scrum Master

Scrum Master是Scrum团队的推动者。他/她确保Scrum团队富有成效和进步。如有任何障碍,scrum master会跟进并为团队解决问题。SCRUM Master是PO和团队之间的中介。

他/她让PO了解Sprint的进展情况。如果团队存在任何障碍或问题,​​请与PO讨论并解决问题。就像团队的每日站立时一样,每天都会有一个关于PO的SCRUM Master的站立。

5)业务分析师(BA)

业务分析师在SCRUM中扮演着非常重要的角色。此人负责完成要求并在需求文档(基于其创建用户素材)中起草。

如果用户故事/接受标准中存在任何含糊之处,他/她是技术(SCRUM)团队接洽的人,然后他将其接收到PO或者如果可能的话自行解决。在大型项目中,可能有超过1个BA,但在小规模项目中,SCRUM Master也可能作为BA。

项目启动时获得学士学位总是一个好习惯。

6)用户故事 (User Story)

用户故事只不过是必须实现的要求或功能。

在scrum中,我们没有那些巨大的需求文档,而是需求在一个段落中定义,通常具有以下格式:

作为<用户/用户类型>
我想<一些可实现的目标/目标>
实现<做某事的某些结果或理由>

例如

作为[管理员],我想[要密码锁],实现[以防用户连续3次输入错误的密码以限制未经授权的访问]。

应该遵守用户故事的一些特征。用户故事应该简短,逼真,可以估计,完整,可协商和可测试。用户故事永远不会在Sprint中间被更改或更改。

SCRUM Master和BA(如果适用)负责确保PO使用适当的“验收标准”正确起草用户故事“。如果要进行任何会影响sprint发布的更改,那么这些故事将从sprint中撤出,或者按照可用时间完成。

每个用户故事都有一个验收标准 (Acceptance Criteria),应由团队明确定义和理解。

验收标准详细说明了提供支持文档的用户故事。它有助于进一步完善用户故事。团队中的任何人都可以写下验收标准。测试团队根据这些验收标准确定测试用例/条件。

7)史诗 (Epic)

史诗是模棱两可的用户故事,或者我们可以说这些是未定义的用户故事,并保留用于未来的冲刺。

试着把它与生活联系起来,假设你要去度假。当你下周去的时候,你已经准备好了所有的东西,比如你的酒店预订,观光,旅行支票等等。但是你明年的假期计划呢?你只有一个模糊的想法,你可能会去XYZ的地方,但你没有详细的计划。

史诗就像你明年的假期计划一样,在那里你只知道你可能想去,但是在这个时间点你不知道所有这些细节的地点,时间,对象。

以类似的方式,存在将来需要实现的特征,其细节尚不清楚。大部分功能都以Epic开头,然后分解为可以实现的故事。

8)产品积压 (Product Backlog)

产品待办事项是一种存储所有用户故事的存储桶或源。这由产品负责人维护。产品待办事项可以设想为产品所有者的愿望清单,产品所有者根据业务需求对其进行优先级排序。

在计划会议期间(参见下一节),从产品待办事项中获取一个用户故事,然后团队进行头脑风暴,理解并完善它,并在产品所有者的干预下共同决定要采取哪些用户故事。

9)Sprint Backlog

根据优先级,用户故事一次一个地从Product Backlog中获取。Scrum团队的头脑风暴决定了它的可行性,并决定了在特定冲刺上工作的故事。Scrum团队在特定sprint上工作的所有用户故事的集合列表称为Sprint backlog。

clipboard.png

10)故事点 (Story Point)

clipboard.png

故事点是用户故事复杂性的定量指示。基于故事点,确定故事的估计和努力。

故事点是相对的而不是绝对的。为了确保我们的估计和努力是正确的,检查用户故事并不重要是很重要的。用户故事越精确,越小,估计就越准确。

每个用户故事都根据Fibonacci系列(1,2,3,5,8,13和21)分配到故事点。数字越高,复杂就是故事。

确切地说

  • 如果你给出1/2/3的故事点,那就意味着故事很小而且复杂度很低。
  • 如果你给分数为5/8,它是一个中等复杂的
  • 13和21非常复杂。

这里的复杂性包括开发和测试工作。

为了确定一个故事点,头脑风暴发生在Scrum团队中,团队共同决定一个故事点。

开发团队可能会为特定故事提供3个故事点,因为对于他们来说可能有3行代码更改,但测试团队给出了8个故事点,因为他们觉得这个代码更改会影响更大的模块所以测试工作量会更大。无论你给出什么样的故事,你都必须证明这一点。

因此,在这种情况下,头脑风暴发生,团队集体同意一个故事点。

无论何时决定故事点,请记住以下因素:

  • 故事与其他应用程序/模块的依赖关系。
  • 资源的技能组合。
  • 故事的复杂性。
  • 历史学习。
  • 用户故事的接受标准。

如果您不了解特定故事,请不要调整大小。

每当故事大于或等于8分时,它就被分解为2个或更多故事。

11)烧掉图表

刻录图表是一个图表,显示了scrum任务的估计v / s实际工作量。

它是一种跟踪机制,通过该机制,对于特定的冲刺,跟踪日常任务以检查故事是否正在朝着完成提交的故事点的方向前进。

示例:要了解这一点,请查看下图:

烧掉图表1

我假设:

  • 2周冲刺(10天)
  • 2个实际在冲刺上工作的资源。

“故事” - >此列显示为sprint拍摄的用户故事。

“任务” - >此列显示与用户素材关联的任务列表。

“努力” - >此栏显示了努力。现在,这项措施是完成任务的总工作量。它没有描述任何特定个人的努力。

“第1天 - 第10天” - >此列显示完成故事的剩余时间。请注意,小时不是已经完成的小时,但仍然是剩下的小时数。

“估计的努力” - >是努力的总和。对于“开始”,它只是整个单独任务的总和:SUM(C5:C15)

必须在1天内完成的总工作量是70/10 = 7.因此在第1天结束时,努力应该减少到70 - 7 = 63.以类似的方式,计算所有的直至第10天,估计的努力量应为0(第16行)

“实际努力” - >顾名思义,实际上是完成故事的努力。也可能发生实际努力增加或减少的估计值。

您可以使用内置函数和Excel中的图表来创建此燃尽图表。

刻录图表步骤将是:

  1. 输入所有故事(A5列 - A15列)。
  2. 输入所有任务(B5 - B15列)。
  3. 输入天数(第1天 - 第10天)。
  4. 输入起动工作(总结任务C5 - C15)。
  5. 应用公式计算每天(第1天至第10天)的“估计工作量”。在D15(C16- $ C $ 16/10)输入公式并将其拖动一整天。
  6. 对于每一天,输入实际的努力。在D17(SUM(D5:D15))输入公式,用于总结剩余的实际工作量,并将其拖动到所有其他日期。
  7. 选择它并按如下方式创建图表:

烧掉图表2

12)速度

Scrum团队在sprint中归档的故事点总数称为Velocity。Scrum团队通过其速度来判断或引用。话虽如此,但应该记住,这里的目标不是达到最大的故事点,而是要获得高质量的交付,尊重Scrum团队的舒适程度。

例如:对于特定冲刺:用户故事总数为8,故事点如下所示。

Scrum Velocity

所以这里的速度将是故事点的总和= 30

完成的定义:

当所有故事都完成后,Sprint被标记为完成,所有开发,研究,QA任务都标记为“已完成”,所有错误都是固定关闭的,否则可以在以后完成(如不完全相关或不太重要)在备份日志中提取并添加代码审查和单元测试,估计的小时数已经达到了任务中的实际小时数,最重要的是,已经向PO和利益相关者提供了成功的演示。

在SCRUM方法论中完成的活动

clipboard.png

#1)规划会议

计划会议是Sprint的起点。这是整个Scrum团队聚集的会议,SCRUM Master根据产品积压和团队头脑风暴的优先级选择用户故事。

根据讨论,Scrum团队根据Fibonacci系列决定故事的复杂程度并根据其进行调整。团队确定任务以及完成用户故事实施所需的工作(以小时为单位)。

很多时候,计划会议之前都是“预先计划会议”。这就像scrum团队在参加正式计划会议之前所做的一项功课。团队试图在计划会议中写下他们想要讨论的依赖关系或其他因素。

#2)执行Sprint任务

顾名思义,这些是scrum团队完成任务并将用户故事带入“完成”状态所做的实际工作。

#3)每日站立

在冲刺周期中,scrum团队每天都会遇到,不超过15分钟(可能是一个直接的电话,建议在一天开始时)和状态3点:

  1. 昨天团队成员做了什么?
  2. 团队成员今天计划做什么?
  3. 任何障碍(障碍)?

促进这次会议的是Scrum大师。如果任何团队成员遇到任何困难,scrum master会跟进以解决问题。在Stand ups中,董事会也会进行审核,并自行显示团队的进展情况。

#4)审核会议

在每个sprint周期结束时,SCRUM团队再次会面并向产品所有者演示实现的用户故事。产品所有者可以根据其验收标准交叉验证故事。Scrum大师再次负责主持这次会议。

同样在SCRUM工具中,Sprint关闭,任务标记完成。

#5)回顾会议

回顾会议在审议会议之后召开。

SCRUM团队会见,讨论并记录以下几点:

  • Sprint(最佳实践)期间进展顺利?
  • 什么在Sprint中表现不佳?
  • 得到教训
  • 行动项目。

Scrum团队应该继续遵循最佳实践,忽略“不是最佳实践”,并在随后的冲刺中实施经验教训。回顾会议有助于实施SCRUM流程的持续改进。

流程如何完成?一个例子!

阅读了SCRUM的技术术语。让我试着用一个例子来演示整个过程。

例:

步骤1:让我们拥有一个由9人组成的SCRUM团队,其中包括1个产品所有者,1个Scrum master,2个测试人员,4个开发人员和1个DBA。

步骤2:Sprint决定遵循4周的周期。所以我们从6月5日到 7 月4 日开始为期一个月的Sprint 。

步骤3:产品所有者在产品待办事项中具有优先级的用户故事列表。

步骤#4: 团队决定于 6月4 日举行“预先规划”会议。

  • 产品所有者从产品积压中获取1个故事,描述它并留给团队进行头脑风暴。
  • 整个团队直接与产品所有者讨论并进行沟通,以便清楚地了解用户故事。
  • 以类似的方式,采用各种其他用户故事。如果可能的话,团队也可以继续调整故事的大小。

在所有讨论之后,个人团队成员回到他们的工作站和

  • 确定每个故事的各自任务。
  • 计算他们将要工作的确切小时数。让我们来看看会员如何结束这些时间。

总工作小时数= 9
减1小时休息,减1小时会议,减去1小时电子邮件,讨论,故障排除等
所以实际工作时间= 6.Sprint
期间的总工作天数= 21天。
总可用小时数= 21 * 6 = 126.
该成员休假2天= 12小时(每个成员有所不同,有些可能请假,有些可能不休。)
实际小时数= 126 - 12 = 114小时。

这意味着该成员实际上可以在此sprint中使用114小时。所以他将打破他的个人冲刺任务,总共达到114小时。

第五步: 6月5 日,整个Scrum团队召开“规划会议”。

  • 产品待办事项中的用户故事的最终判决已完成,故事将移至Sprint Backlog。
  • 对于每个故事,每个团队成员都会声明他们确定的任务,如果需要,他们可以讨论这些任务,可以调整大小或调整大小(请记住Fibonacci系列!!)。
  • Scrum主人或团队在工具中输入他们各自的任务以及每个故事的小时数。
  • 完成所有故事后,Scrum主人注意到了最初的Velocity并正式启动了Sprint。

步骤#6:Sprint启动后,根据分配的任务,每个团队成员开始处理这些任务。

第7步:团队每天开会15分钟并讨论3件事:

  • 他们昨天做了什么?
  • 他们今天打算做什么?
  • 任何障碍(障碍)?

步骤#8:Scrum master在“Burn down chart”的帮助下每天跟踪进度。

步骤#9:如果遇到任何障碍,Scrum主管会跟进解决这些问题。

步骤#10: 7 月4 日,团队再次召开审查会议。成员向产品所有者演示实现的用户故事。

步骤#11: 7 月5 日,团队再次召开会议,讨论回顾

  • 什么进展顺利?
  • 什么不顺利?
  • 行动项目。

步骤#12: 7 月6 日,团队再次召开下一次冲刺的预先计划会议,并继续进行循环。

推荐阅读

Scrum Artifacts

Agile & Scrum Basis

Agile & Scrum Principles

Scrum Roles

2018-10-09 17:08:50 u014526891 阅读数 831
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10436 人正在学习 去看看 CSDN讲师

上面一篇文章我们提过为什么分布式需要做前后端分离,今天这篇我们从开发模式来详解为什么互联网项目使用于敏捷开发?

因为笔主经历过瀑布开发模式和敏捷开发模式这两种开发模式,所以存在有一些自己的见解跟大家交流。

下面所以我们这边先来简单介绍下这两种模式:

瀑布开发模式:

瀑布开发模式是由W.W.Royce在1970年最初提出的软件开发模型,瀑布式开发是一种老旧的计算机软件开发方法。
瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行
步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。 总的来说,迭代周期长一些,一次性解决所有的任务,一次上线。

下面我们说说瀑布开发模式的几个特点

1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一阶段的工作就不展开。

2.重视和强调过程文档,在开发的中后期才会看到软件原型,早起只能通过文档来了解系统的模样。在这种情况下,文档的重要性仿佛已经超过了代码的重要性。

3.瀑布模型每个阶段的人员只关心自己阶段的工作,不需要关注其他阶段的工作。

优点:

1、可以让开发人员能够更专注于本职工作,提高阶段效率

缺点:

1、在项目各个阶段之间极少有反馈,风险往往迟至后期才显露,失去及早纠正的机会。

2、项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂

3、测试人员最后才参与到项目中来,后期风险较大。

4、只有在项目生命周期的后期才能看到结果。

 

敏捷开发模式:

敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不 尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织 型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。

在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。总的来说,拆分成多个小迭代,多次上线。

下面我们说说敏捷开发模式的几个特点

1、最核心的功能最先完成,容易出成果。

2、小步快跑,尽早交付,拆分各个小迭代(spring),一定的迭代周期内需要确保开发的完成,规避了一定的上线风险。

3、各组人员分迭代来有序工作,比如:设计人员出一个模块RP,开发人员完成这个模块编码,测试人员完成这个模块测试。

4、敏捷的管理是团队的自我管理和项目经理的服务式管理,项目经理需要根据当前开发资源确保每个迭代的的可完成性,团队成员需有良好的自我管理能力,来确保小迭代内功能的完善;项目经理需要对整体启到把控作用,迭代中可以根据开发进度进行各成员工作的微调,保证迭代进度的完成

优点:

1、容易出成果,可以快速提高软件发布周期,敏捷确实是项目进入实质开发迭代阶段,用户很快可以看到一个基线架构版的产品

2、测试人员能够尽早参与进项目中来,规避了一定的风险。​​​​

3、每次迭代周期应尽可能短,以便能及时地处理需求变化和用户反馈​​​。

缺点:

1、迭代周期端,为了不影响迭代完整,需要项目中存在经验较强的人,要不大项目中容易遇到瓶颈问题,延误迭代进度。

2、敏捷开发要求各员工自我管理要强,所以对人员素质和稳定性的要求又更高。

 

那为什么互联网项目要用敏捷开发呢?

1、出成果(版本)快,互联网就是以快吃慢,一般都是迭代发布的,追求创新,说明了需要快速响应用户的变化,时间就是一切,需求不确定性高,这个在软件行业也很常见;关注用户行为,倡导以用户为中心的产品设计。很典型的例子微信,腾讯一个月开发出来的产品,根据用户体验和反馈,通过反复的小迭代来优化。

2、互联网项目中市场反响和客户体验尤为重要,需要有一个快速迭代来响应客户的需求,确保客户的满意度。如果是瀑布式开发,迭代慢,更改的成本也比较高。

3、随时应对变化,因为迭代周期的减小,使得项目的弹性更足,可以更好的适应互联网项目上更多的不确定性。

 

那如何从瀑布开发模式往敏捷开发模式切换?

任何开发模块的切换都是存在风险点的,包括我们前面介绍的前后端分离模式,那我们需要做什么来减少这些风险呢?

1、优先选择周期比较长的项目,资源较充足、素质较高的团队来试行。

2、需要制定一套较为完整的敏捷体系,从产品到开发到测试,选型敏捷工具

3、刚切换过来的迭代,可以适当减少迭代内容,切换过程需要缓冲时间,避免因为试行阶段出现的问题,从而团队的整个心态。

4、项目经理需要把控好任务进度,需要在迭代的中间,每天了解迭代运行情况,最好是每天团队可以有晨会。

 

 

敏捷开发

阅读数 2946

什么是敏捷开发?

阅读数 4524

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