2019-08-12 20:39:23 yjn1995 阅读数 769
  • SCRUM敏捷开发视频教程

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

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

前言

  

迭代开发

  敏捷开发的核心是迭代开发(iterative development)。敏捷一定是采用迭代开发的方式。那么什么是"迭代开发"呢?迭代的英文是 iterative,直译为"重复",迭代开发其实就是"重复开发"。
  对于大型软件项目,传统的开发方式是采用一个大周期(比如半年)进行开发,整个过程就是一次"大开发";迭代开发的方式则不一样,它将开发过程拆分成多个小周期,即一次"大开发"变成多次"小开发",每次小开发都是同样的流程,所以看上去就好像重复在做同样的步骤。
  举例来说,SpaceX 公司想造一个大推力火箭,将人类送到火星。但是,它不是一开始就造大火箭,而是先造一个最简陋的小火箭 Falcon 1。结果,第一次发射就爆炸了,直到第四次发射,才成功进入轨道。然后,开发了中型火箭 Falcon 9,九年中发射了70次。最后,才开发 Falcon 重型火箭。如果 SpaceX 不采用迭代开发,它可能直到现在还无法上天。
  迭代开发将一个大任务,分解成多次连续的开发,本质就是逐步改进。开发者先快速发布一个有效但不完美的最简版本,然后不断迭代。每一次迭代都包含规划、设计、编码、测试、评估五个步骤,不断改进产品,添加新功能。通过频繁的发布,以及跟踪对前一次迭代的反馈,最终接近较完善的产品形态。

增量开发

  迭代开发只是要求将开发分成多个迭代,并没有回答一个重要的问题:怎么划分迭代,哪个任务在这个迭代,哪个任务在下个迭代?这时,一般采用"增量开发"(incremental development)划分迭代。
  所谓的"增量开发",指的是软件的每个版本,都会新增一个用户可以感知的完整功能。也就是说,按照新增功能来划分迭代。
  举例来说,房地产公司开发一个10栋楼的小区。如果采用增量开发的模式,该公司第一个迭代就是交付一号楼,第二个迭代交付二号楼…每个迭代都是完成一栋完整的楼。而不是第一个迭代挖好10栋楼的地基,第二个迭代建好每栋楼的骨架,第三个迭代架设屋顶…
增量开发加上迭代开发,才算是真正的敏捷开发。

敏捷开发的好处

早期交付

  敏捷开发的第一个好处,就是早期交付,从而大大降低成本。
  还是房地产公司为例,如果按照传统的"瀑布开发模式",先挖10栋楼的地基、再盖骨架、然后架设屋顶,每个阶段都等到前一个阶段完成后开始,可能需要两年才能一次性交付10栋楼。也就是说,如果不考虑预售,该项目必须等到两年后才能回款。
  敏捷开发是六个月后交付一号楼,后面每两个月交付一栋楼。因此,半年就能回款10%,后面每个月都会有现金流,资金压力就大大减轻了。

降低风险

  敏捷开发的第二个好处是,及时了解市场需求,降低产品不适用的风险。
  请想一想,哪一种情况损失比较小:10栋楼都造好以后,才发现卖不出去,还是造好第一栋楼,就发现卖不出去,从而改进或停建后面9栋楼?
  对于软件项目来说,先有一个原型产品,了解市场的接受程度,往往是项目成功的关键。有一本书叫做《梦断代码》,副标题就是"20+个程序员,三年时间,4732个bug,100+万美元,最后失败的故事",这就是没有采用敏捷开发的结果。相反的,Instagram 最初是一个地理位置打卡 App,后来发现用户不怎么在乎地理位置,更喜欢上传照片,就改做照片上传软件,结果成了独角兽。
  由于敏捷开发可以不断试错,找出对业务最重要的功能,然后通过迭代,调整软件方向。相比传统方式,大大增加了产品成功的可能性。如果市场需求不确定,或者你对该领域不熟悉,那么敏捷开发几乎是唯一可行的应对方式。

如何进行每一次迭代

  虽然敏捷开发将软件开发分成多个迭代,但是也要求,每次迭代都是一个完整的软件开发周期,必须按照软件工程的方法论,进行正规的流程管理。

 &emssp;具体来说,每次迭代都必须依次完成以下五个步骤。

  • 需求分析(requirements analysis)
  • 设计(design)
  • 编码(coding)
  • 测试(testing)
  • 部署和评估(deployment / evaluation)
    每个迭代大约持续2~6周。

敏捷开发的价值观

《敏捷软件开发宣言》里面提到四个价值观。

  • 程序员的主观能动性,以及程序员之间的互动,优于既定流程和工具。
  • 软件能够运行,优于详尽的文档。
  • 跟客户的密切协作,优于合同和谈判。
  • 能够响应变化,优于遵循计划。

十二条原则

该宣言还提出十二条敏捷开发的原则。

  • 通过早期和持续交付有价值的软件,实现客户满意度。
  • 欢迎不断变化的需求,即使是在项目开发的后期。要善于利用需求变更,帮助客户获得竞争优势。
  • 不断交付可用的软件,周期通常是几周,越短越好。
  • 项目过程中,业务人员与开发人员必须在一起工作。
  • 项目必须围绕那些有内在动力的个人而建立,他们应该受到信任。
  • 面对面交谈是最好的沟通方式。
  • 可用性是衡量进度的主要指标。
  • 提倡可持续的开发,保持稳定的进展速度。
  • 不断关注技术是否优秀,设计是否良好。
  • 简单性至关重要,尽最大可能减少不必要的工作。
  • 最好的架构、要求和设计,来自团队内部自发的认识。
  • 团队要定期反思如何更有效,并相应地进行调整。
2018-08-28 15:32:07 u010856276 阅读数 1376
  • SCRUM敏捷开发视频教程

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

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

什么是敏捷?(Agile)

从本质上讲,敏捷(Agile)并不是开发方法,而是一种理念。对于项目管理而言,敏捷是一个全新的术语,敏捷强调在软件研发过程中持续性的根据用户反馈和需求优先级来发布新版本,不断进行迭代,让产品逐渐完善。

在数十年前,瀑布式项目管理是软件研发的主流方法,在研发过程中,团队成员将会花大把的时间和精力在项目前期去收集资源和信息,然后基于这些去做产品设想和研发规划。

到了70年代,有先觉的研发人员发现瀑布式研发不仅在执行中各处受限,研发速度还很慢,显然Out了。尤其到了90年代末期,开始出现黑客来捣乱,这就意味着前功尽弃、全部推倒重来,这简直是研发的噩梦。

相比瀑布基于线性、可预测性地去开发产品,研发人员更想要能够灵活管理用户反馈、Bug和需求的方法。这也就是敏捷方法出来以后受欢迎的原因。

另外,你也可以通过这个视频学习什么是敏捷(Agile)

在2001年,17位研发人员共同探讨出了《敏捷宣言》这份文档,阐述了他们对于软件研发的看法。文中他们定义了敏捷开发需要遵守的四项价值观

我将之总结为:

以人为本:重视个体间的合作互动
目标导向:我们最终交付的是“可使用的软件”,而不是一堆繁重的文档
客户为先:理解客户需求,与客户合作
拥抱改变:客户会在不断变化需求的过程中明晰真正需要的,因此敏捷需要拥抱变化

尽管如此,这四项价值观并不意味着我们就该放弃工具、文档和计划。因为它们对研发结果依然有非常重要的价值,只是相比之下,我们应该关注更核心的事物:人、产品模型、协作和迭代。为了让这四项原则变得简单易懂好执行,他们又将写了敏捷开发12项原则作为指导:

我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
业务人员和开发人员必须相互合作,项目中的每一天都不例外。
激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
以简洁为本,它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期地反思如何能提高成效,并依此调整自身的举止表现。

如果我们把这些原则和遇到的问题对号入座,很快我们就会发现,这12项原则正是对应了客户期望。比如,客户不会关心开发文档写的怎么样,他们更感兴趣交付的成品能干什么;他们不在意你的开发计划,他们希望你能立马交付;昨天他们想要修个BUG,而不是等到下次版本更新。

我们总会遇到需求多样化的客户,而这时,敏捷能够确保你在研发过程中始终将用户需求作为核心。

怎么知道敏捷(Agile)和团队成员是否三观相合

敏捷虽然听起来光鲜亮丽,但不是所有项目都能用敏捷来做。

敏捷在公司里投入使用后可能与预想的结果背道而驰。敏捷意味着快速推进项目,也就是说并不是所有事情都是按部就班。因此,我们得知道在这种快速变化的环境下,团队是否能够适应变化。

所以在我们部署使用敏捷前,先来点前戏试试看。在使用前,我们可以先问自己5个问题:

1.你是否会愿意接手目标不明确的项目?

敏捷项目管理中有句话叫做:快速失败。比如我们接手了一个连最终产出都不明确的项目,首先我们会先交付最小模型产品,这时我们得做好被质疑的准备。毕竟没人知道要做出怎么样的产品,所以我们的最小模型的产品很可能是个怪胎。在与客户反复测试后,我们会才会逐步了解他们的真实需求,这时候我们离成功又近了一步。

2.你会如何规避项目风险?

就像我们前面提到的,敏捷提倡不断从犯错中积累学习并持续迭代。如果我们走老路,用传统项目管理的方法来推进的话,我们会要承担更大的风险。当然就算我们开始敏捷之后,也要准备好随时响应未知问题。

3.你的团队能有多灵活?

作为项目经理,我们的责任是和客户一起把产品做的更好。这么做很可能和设计、研发、其他成员的想法背道而驰。这时我们需要找主心骨聊一聊,是否愿意放下老套路,根据用户需求来调整想法、重新规划方向。

4.公司阶层制度严格吗?

敏捷的其中一项原则不仅是和用户一起工作,研发成员的身份也会发生变化。你们公司的文化开放吗?是否能接受扁平和开放的管理方法?

5.你怎么衡量进度?怎么定义成功?

用敏捷来管理项目能够帮我们逐渐进步的同时也督促我们将产品做得更好。如果因为突发灵感而放弃正在执行的任务,那么敏捷将毫无意义。我们先花些时间来看看团队是怎么看待进步和成功。然后再来看我们是不是离最终目标一步步的更近了?

研发团队如何使用敏捷

读到这儿,我想你已经跃跃欲试,准备踏上敏捷之路了。

敏捷非常注重节奏,当你有多个任务要交付,团队更需要注重节奏的把握。而身为项目经理,我们的职责是让整个团队通过协作最终交付产品。

敏捷是不断规划、执行、学习和迭代的过程,敏捷项目通常可以分解为一下7步:

第1步:通过战略会议定义你的愿景

每当开始新项目时,第一件要做的事情是定义产品的业务需求,或者说想要达到的愿景。事实上,我们只需要回答一个问题:你为什么想要做这个产品。这是我们心中的蓝图,时时提醒我们不要跑偏。

作为一家产品公司,定义愿景的最佳方法之一是电梯演讲:

用于:(哪部分目标客户)
需求:(用户的需求)
类别:(我的产品是哪种类型)
功能:(产品的价值、客户为什么选我们)
竞品:(主要的竞争对手有哪些)
差异化:(和竞品的差异化描述)

即使我们做的不是软件产品,我们也可以根据项目的目标来调整上述内容。

战略会议的参与角色都有谁?

此时我们要让更多人认同这个项目,所以很多关键的利益相关者自然不能缺席,包括相关主管、经理、主任和产品经理。

战略会议该什么时候召开?

项目开始前我们就该来开战略会,或者至少每年一次的定期会议来保证愿景依然不过时

战略会议要召开多久?

这个就由你主观来决定了,一般来讲,花4-16小时来探讨战略已经足够了。

第2步:绘制产品路线图

当我们开完战略会后,就该轮到产品经理把愿景变成产品路线图。产品路线图能帮助我们纵观全局、理清思路,让我们有宽松的时间来开发每个产品需求。“宽松”并不是说我们可以花数天或是数周的时间来推进每步计划,而是轻量级的去定义产品、理清需求优先级和粗略估算产品每个需求的时间。

项目管理专家Roman Pichler认为:目标导向的产品线路图能够聚焦于目标和产出结果(比如:获客、增加活跃度、满足客户需求)。而产品特性来自于这些目标,所以我们在制定目标时应谨慎,每个目标对应3-5个产品特征。

而每个目标,我们需要包含5个关键信息:时间、名称、目标、产品特征和衡量标准,有了这些,我们就能清楚知道哪些该做、什么时候算做成功了以及我们如何取得了成功。
这里写图片描述
产品线路图谁来画?

当然是产品经理,但我们也该听听其他利益相关者的想法,比如:客户、市场、销售、支持和研发团队的代表。

产品路线图什么时候来画?

路线图自然是要在开始实施迭代之前,当然最好是能在战略会后就着手开始。

绘制产品路线图要多久?

尽早实施,不是在前期纠结。虽然线路图看起来有点纸上谈兵,但当你的路线图能涵盖所有的目标时,我们也会更有信心去做好。

第3步:制定发布计划

当我们有了战略和计划,下一步我们就可以暂定几个时间节点。

这个阶段产品经理要严格按照计划发布新版本。我们也不用担心功能不齐全的问题,敏捷项目都会有多次发布的过程,所以我们只要优先发布核心功能的版本即可。

举例来说,你的项目要在11月交付,而你可能在2月初就已经做好了最小模型,打算在5月左右发布完整版。这些时间节点的安排都将由你的项目难度和每次迭代时长(或者说每次达成目标需要的工作时长)决定。通常每次发布新版本都需要经历3-5次迭代。

谁来制定发布计划?

产品经理、项目经理和所有团队成员都该来参与其中。当然,邀请少数利益相关者来加入其中也是对其他成员的鼓励,让团队能够尽早开始。

发布计划什么时候来做?

越早越好,你的发布计划应该在确认新产品后的第一天开始制定。在随后的每个季度中至少记录一次。

制定发布计划要多久?

一般来说会需要4-8小时,实际时长由具体情况决定,但不能因为它拖进度。

第4步:制定迭代(Sprint)计划

迭代(Sprints),我将其理解为通过短期研发完成具体任务来达到目标的一个过程,也是帮助产品经理和研发团队逐渐切入项目细节的方法。

通常情况下,每次迭代大约要花费1-4周。具体的时长我们需要根据团队过往的表现情况来制定,同时尽量保持每次迭代的时长相同。

哪些角色参与制定迭代计划?

迭代是整个团队的活,因此,产品经理、项目经理以及其他所有成员都该积极参与其中,表达自己的声音和想法。

迭代计划什么时候来制定?

在每次迭代周期开始前,我们就需要做好迭代计划。比如说,你的计划是每周迭代,那么就你就需要在每周一(或者你选好的某一天)告诉其他人迭代计划。

制定迭代计划要多久?

迭代计划是迭代周期的基石,虽然如此,我们也不要在这上面浪费过多的时间,通常2-4小时足够了。写好了迭代计划也就意味着我们已经踏上了正轨。

第5步:每日站会

在每次迭代过程中我们需要有时间来确认项目组没有遇到阻碍,同时保证能准时完成既定目标。这时候我们就需要使用每日站会。

每日站会,如同字面意思一样通俗易懂,每天花15分钟左右的时间来讨论下面3件事:

昨天我完成了哪些事情
今天我打算做哪些事情
我有遇到哪些问题,如何解决

或许讨论这3件事,可能让团队的一部分人的脸挂不住。但这对推动敏捷项目管理的沟通有积极意义。敏捷之所以能够跨团队协作,主要依靠的就是团队快速响应和有让成员发声表达的空间。

第6步:迭代(Sprint)结束了?那就进入评审阶段吧

如果迭代中一切顺利,那么迭代周期结束后,我们需要来检测下软件的功能。我们可以借评审的机会来向团队成员和利益相关者展示成果。

作为产品经理,你对产品功能有选择的权利。如果有哪步错误,尝试多问几个为什么?下次迭代时我该怎么调整才能让团队达成目标?敏捷是不断学习和迭代的过程,你的流程管控和最终产出也是同一道理。

哪些角色参与评审?

团队全员和利益相关者都应该参加迭代评审会来确认项目进度和表达他们的观点。

什么时候执行评审?

每次迭代结束后就可以开始。

评审阶段要多长久?

无需特意去准备PPT、功能说明,审查会最多1-2小时就够了。

第7步:下一步?迭代(Sprint)回顾总结

为了让敏捷项目管理能顺利运作,我们在每个阶段结束后需要知道下一步要做什么。这是我们在迭代回顾阶段要做的事。当迭代和审查结束后,接下来该去决定下次要做哪些工作。我们需要回顾下,在迭代中是否发生了些事情改变了你的既定时间,甚至是项目愿景。

谁来参加回顾总结会议?

回顾总结是审查的延伸,这时利益相关者离开也没有关系,而其他团队成员则加入其中,给出自己的意见。

什么时候来做?

当然最好是在审查阶段结束后,立刻开始迭代回顾总结。

这会花多长时间来做?

概括下来大概几个词:简短明了、甜蜜温馨,最多花1-2小时来总结和大致规划下次计划。

整个过程都结束了,接下来干啥?

这时候我们可以选择发布新版本、获取用户反馈、规划新功能或者修复bug。持续性的发布、学习、再建,这一系列过程让敏捷在管理方法中异军突起。

比起单纯的靠产品需求清单来执行项目,在敏捷指导下,我们可以通过不断发布新版本来看看客户的反馈。相比花一年时间来开发和发布,然后发现缺失核心功能的传统方法,敏捷能在每次迭代后迅速发现问题,并在下次迭代中及时调整。
这里写图片描述
如何实施敏捷方法:Scrum和看板

我想此时你已经跃跃欲试想把敏捷带给团队。但还有重要的一步,正如我们前面所说的,敏捷是项目管理的全新理念。为了能更好的执行,有些人研究出了一些敏捷方法。这些方法相似度很高,但从实施的角度来看,两者各有不同:

Scrum

Scrum应该是最广为人知的敏捷方法,与看板并驾齐驱。其受欢迎的原因归功于操作简单、高效以及极高的可复制性。你可以观看这个7分钟视频,学习如何使用Scrum。

我们来看下Scrum的工作原理:

在Scrum中,产品经理和项目团队紧密协作,一起定义目标、梳理产品需求清单。清单中通常会包含产品特性、修复bug、非必要功能需求以及其他要在交付时完成的工作。

有了产品清单,产品经理就会开始确定需求优先级,研发团队通常会在接下来30天左右的迭代中产出“潜在可交付版本”。当研发团队制定了迭代清单后,除了团队成员外,任何人都不能再加入需求。当一轮迭代完成后,全员再次分析需求清单、划分需求优先级,然后进入下一轮迭代。

看板(Kanban)

看板作为敏捷方法的一种,提倡化繁为简,不让研发团队超负荷工作。因此它和Scrum有一定相似,都强调持续性交付,这个视频解释了看板管理项目的原理。

当然看板也会有自己的三原则:

1.工作流可视化

当项目逐渐复杂的时候,看板工具用“白板”帮我们理清所有项目的进度和归属:代办、进行中、已完成,洞悉项目的关联信息,让事情逐步变得简单清晰。
这里写图片描述
2.WIP原则

WIP类似于Scrum的迭代清单,一旦制定后就不再加入新的需求(研发团队除外),团队需要依靠看板来了解他们在每次迭代具体的任务量。

3.明确规划下一步

为了更好的实施看板,我们需要知道下一个任务是什么。这也就意味着我们需要实时更新产品需求,重新确定需求优先级。

实施敏捷管理最后的建议

恭喜!你现在应该已经学会了敏捷的概念,和如何实施敏捷开发的方法,现在可以再自己的团队内推广了。

但是值得提醒的是,由于敏捷开发中涉及到大量的计划、开发任务管理、时间进度和负责人,你需要使用一个项目管理工具,让整个管理过程更可控。一个项目管理工具可以这样帮助你做好敏捷开发:

1.进度报告:你可以看到还有多人任务等待完成、有多少延期任务

2.沟通:让每个人反馈任务中遇到的问题和进展

3.分配:项目下的任务应该支持分配到具体的负责人

2018-11-15 12:00:39 love_hot_girl 阅读数 118
  • SCRUM敏捷开发视频教程

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

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

作者:付聪
链接:https://www.zhihu.com/question/19645396/answer/16635773
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
 

首先,敏捷开发是一种过程控制论,通俗的说,就是一种做事情的方法。

1. 它适用于软件,因为软件是软的,可以改。要是硬件,改起来就没那么方便了
2. 它适用于客户不知道自己要啥的情况,其实,这样的客户占绝大多数。因为客户不知道要啥,所以你需要不断帮客户弄明白他到底想要啥。。。换句话说,你需要和客户沟通,合作,倾听反馈,持续改进。。。
3. 它适用于竞争激烈的市场,这样的情况下,赶在竞争对手前交付一个不完美但至少能用的产品非常重要。
4. 它适用于快速变化的市场,你在埋头造一辆汽车的时候,客户已经想开飞机满天飞了,这就需要你能一步步的把汽车改成飞机,还能按时交付。
5. 它适用于在一个地方办公的小团队,一般10个人以内。这样能使敏捷中主要的沟通方式“Face to Face” 是可行的。

其次,敏捷开发是一套工具集,里面有形形色色的工具,你可以不搞敏捷,但可以用那么一两个来提高工作效率。

比如:
1. 站会:三个问题,简洁有效的小团队沟通方式
2. 看板:直观反映工作进度,反映流程遵守情况,反映流程缺陷
3. 演示,计划,反思会:适合于小团队的协作和优化反馈方式
4. 用户故事:站在用户的角度讲需求
5. 持续集成:随时高质量交付的基础,有利于应对变化剧烈的市场

再其次,敏捷开发是一种企业管理方式

比如:
1. 一线员工可以同时是架构师,Scrum Master,开发工程师,测试工程师,发挥了他的主观能动性,有利于创新和效率
2. 敏捷不专注于敏捷团队中个人的绩效考核,而更多的侧重于整个团队的绩效,更好的避免了KPI驱动模式。
3. 把大项目拆分成小项目去做(每个Sprint都是一个迭代,需要输出一个高质量的版本,相当于完成一个小项目),把bug的生存期控制在一个迭代以内,降低了风险,也减少了后期改bug的工作量。
4. 把数十人的大team 分成几个敏捷团队,这几个敏捷团队的Scrum Master/PO再组成一个更高一级的敏捷团队,利用站会,反思,看板等等敏捷元素,可以避免数十份邮件也不能解决一个小问题,大家互相踢皮球,沟通不畅的大企业病。
5. 老板可以是最大的PO,他给下面的高管讲idea(User Story),定期检查Demo,把控产品用户体验,负责和外界的沟通合作-----比如乔布斯,360的周鸿祎等

2019-05-11 19:34:29 jnshu_it 阅读数 1617
  • SCRUM敏捷开发视频教程

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

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

这里是修真院后端小课堂,每篇分享文从

【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】

八个方面深度解析后端知识/技能,本篇分享的是:

【什么是敏捷开发流程 】

这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。
一. 先说一下官方的定义:

敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括:极限编程(XP),Scrum,精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。所有这些方法都具有以下共同特征:

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

  2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

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

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

  5. 开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。

二. 然后是我理解的敏捷

主要说一下我们公司自己的开发流程,因为接触时间尚浅,所以有点地方可能说的不是很到位,希望大家多多包含。

需求评审(参与人员是 客户+产品+UI+开发+测试,也就是所有人员)
主要是产品人员讲解需求,用户需要给出反馈或者提出意见,其他人员可以相应的提出自己的见解。

Story划分(产品+UI+开发)
产品根据UI做出来的原型图给开发人员讲解系统构成和运行,将整个网站按照功能划分成一个个细粒度的story来说明,开发人员(前端和后端)也需要明白自己应该关注那些关键点。

人员划分(leader+开发)
主要是项目小组的leader 根据story划分,给前端和后端开发人员划分story,开发人员根据自己的情况去估算所需时间。

方案设计(数据库设计文档、接口设计文档、方案设计文档)
先根据系统的实际情况去设计DB,包括数据库和表的名字,以及具体的字段。
然后设计接口文档,按照页面和功能进行设计,包括具体的请求地址和入参出参。
最后是根据接口文档中出现的疑难点去做方案设计文档,对遇到的问题进行分析并拿出至少两种具体的解决方案。

方案评审(所有人员)
对前端和后端给出的方案评审其它人员给出各自的意见,有问题的话下次再次开始。

禅道任务拆分(开发人员)
方案评审通过以后开发人员就需要按照预估的总开发时间去拆分story,可以分成多个小的任务,但是一个任务的时间最好不要超过4个小时。

开发(项目日报+工作日报+进度邮件)
每天实际开发过程中遇到问题可以写成项目日报;每天的任务完成情况写成工作日报;相比较整个系统的进度完成情况需要写进度邮件。

端对端(接口)测试(开发人员)
前端写好了页面,后端完实现了接口,就可以进行端到端的测试,可以远程测试,也可以本地测试。

压力测试+集成测试
系统完成以后需要用Jmeter 进行模拟用户访问,通过设置线程来提高并发量的方式达到一定的效果,测试生成的数据需要总结成测试报告。

Demo
对于复盘来说,这就是最后一个程序了,在前后端大师兄的评审下,主要是前端人员进行系统演示,各个功能是否实现、页面是否达到用户要求、有没有什么需要完善的地方。点评过之后如果有问题那就修改之后再次评审;如果没有问题那就算完成复盘项目了。

这么一个流程走下来,特别期间各个环节的良好运行以及团队合作的情况都是确保项目能够正常实现并交付的重要因素,敏捷开发强调的是人的充分能动性,通过这种相互合作的开发模式,相信在前后端分类开发的盛行时代,公司或者团队可以在约定的时间内较好地完成用户委托的项目。

 

 



 

【欢迎加IT交流群565763832与大家一起讨论交流】

2019-05-31 10:49:56 csdn15556927540 阅读数 7332
  • SCRUM敏捷开发视频教程

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

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

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

在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。

简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品。

是谁这么厉害,提出了敏捷开发思想?是一位名叫 Martin Fowler 的美国大叔。

大叔不但是敏捷开发的创始人之一,还在面向对象开发、设计模式、UML 建模领域做出了重要贡献。目前担任 ThoughtWorks 公司的首席科学家。

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

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

SCRUM 则是一种开发流程框架,也可以说是一种套路。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:开发周期完成,项目发布新的可用版本。
在这里插入图片描述
如上图所示,在项目启动之前,会由团队的产品负责人(Product owner)按照需求优先级来明确出一份 Product Backlog,为项目做出整体排期。

随后在每一个小的迭代周期里,团队会根据计划(Sprint Plan Meeting)确定本周期的 Sprint Backlog,再细化成一个个 Task,分配给团队成员,进行具体开发工作。每一天,团队成员都会进行 Daily meeting,根据情况更新自己的 Task 状态,整个团队更新 Sprint burn down chart。

当这一周期的 Sprint backlog 全部完成,团队会进行 Spring review meeting,也就是评审会议。一切顺利的话,会发布出这一版本的 Release,并且进行 Sprint 回顾会议(Sprint Retrospective Meeting)。

那么,现实中的 Scrum 是什么样的情景呢?看看下面的照片就知道了:
在这里插入图片描述
敏捷开发与 DevOps
DevOps 是 Development 和 Operations 的合成词,其目标是要加强开发人员、测试人员、运维人员之间的沟通协调。如何实现这一目标呢?需要我们的项目做到持续集成、持续交付、持续部署。

时下流行的 Jenkins、Bamboo,就是两款优秀的持续集成工具。而 Docker 容器则为 DevOps 提供了强大而有效的统一环境。
在这里插入图片描述
在这里插入图片描述

敏捷开发是个啥

阅读数 846

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