Home Tags Posts tagged with "敏捷开发"

敏捷开发

0 47

一个应用敏捷开发的小组日常

这个小组是做网站开发的,基于微服务负责网站的某一个小模块。标准配置 7 人左右,4 个程序员(至少有一个资深程序员,有架构能力),1 个产品经理(Scrum 里面叫 Product Owner),1 个测试,1 个项目经理(Scrum 里面叫 Scrum Master)。主要负责网站某模块的日常维护。

在分工上:

产品经理:写需求设计文档,将需求整理成 Ticket,随时和项目成员沟通确认需求;

开发人员:每天从看板上按照优先级从高到低领取 Ticket,完成日常开发任务;

测试人员:测试已经部署到测试环境的程序,如果发现 Bug,提交 Ticket;

项目经理:保障日常工作流程正常执行,让团队成员可以专注工作,提供必要的帮助,解决问题。

在敏捷开发框架下,已经形成了一些很好的敏捷实践,这个小组也是基于 Scrum 方法做过程管理,基于极限编程做工程实践,看板可视化。每周一个 Sprint。如何完成需求和修复 Bug?

Scrum:Scrum是迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法:Scrum of Scrums.)

极限编程(Extreme Programming,XP)是一门针对业务和软件开发的规则,它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为目标而产生的一种方法论,XP使开发者能够更有效的响应客户的需求变化,哪怕是在软件生命周期的后期。它强调,软件开发是人与人合作进行的过程,因此成功的软件开发过程应该充分利用人的优势,而弱化人的缺点,突出了人在软件开发过程中的作用。极端编程属于轻量级的方法,认为文档、架构不如直接编程来的直接。

 

如何完成需求和修复Bug?

日常工作围绕 Ticket 来开展。

所有的需求、Bug、任务都作为 Ticket 提交到项目的 Backlog,每个 Sprint 的任务都以看板的形式展现出来。每个人手头事情忙完后,就可以去看板上的“To Do”栏,按照优先级从高到低选取新的 Ticket。选取后移动到“In Progress”栏。

 

每周一部署生产环境

上半周部署,部署很简单,按照流程执行几个命令就可以完成生产环境部署。部署完成后,需要对线上监控的图表进行观察,如果有问题需要及时甄别,必要的话对部署进行回滚操作。但轻易不会打补丁马上重新上线,因为仓促之间的修复可能会导致更大的问题。

像敏捷开发这样一周一个 Sprint 的好处之一就是,即使这一周的部署回滚了,下周再一起部署也不会有太大影响。

每周二开迭代回顾会议,总结上个 Sprint

日常站会后,迭代回顾会议 (Sprint Retrospective) 会议,目的是回顾一下在迭代中,团队有哪些做的好的地方,有哪些做的不好的地方。对于需要后续改进的,需要创建相应的 Ticket,加入到 Backlog 中,在后续迭代中改进完善。

涉及到决策,最好使用集体表决的方式,避免独裁

 

每周四迭代规划会,计划下周工作

迭代规划会(Sprint Planning Meeting)。这个会议是要大家一起讨论下一个 Sprint 的内容。

 

每周五分支切割

周五标志着一周的工作要结束了,所以下班之前(4 点左右),要做 branch cut(分支切割),也就是要把当前主干上的代码,克隆到一个分支(branch)上。

问题

1. 一周一个迭代怎么保证质量?

以前我在使用迭代模型开发时,一般是 4 周左右的迭代周期,2 周就是极限了,所以最开始看敏捷开发用 1 周的迭代周期,心中也有疑惑,1 周时间又要开发又要测试,怎么保证质量?实际实践下来,发现 1 周一个 Sprint 确实可行,而且质量也可以有保障,这里面有几个因素:

(a) 有足够比例的自动化测试代码,可以很好地保证质量。当用户的主要功能都通过自动化测试覆盖时,基本可以保证主要功能流程不会出问题。

(b) 一个 Sprint 开发完成后,并不马上部署生产环境,而是先部署到测试环境,会有 1 周时间测试。

(c) 有专业的测试人员进行测试,并非完全依赖自动化测试。有时候一些大的功能更新,甚至会组织全组成员一起测试,以弥补测试人员不足的情况。在一个 Sprint 开发结束后,并不马上部署生产环境,而是先部署测试环境测试。

也就是说,虽然是 1 周的 Sprint,但是其实还有 1 周的时间进行测试。每个 Sprint 不仅开发新功能,还要同步修复以前版本的 Bug。这样基本上可以保证有好的质量。而且这种 1 周的迭代,可以保持每周都有内容更新,还有个好处就是每周更新的内容不多,出现问题的话,很容易就定位到是什么地方导致的问题。

2. 基于敏捷开发如何做计划?

大厂里面通常会在上一年底确定第二年整年的大的开发计划,并确定上线的时间范围,每个季度再根据情况做一些调整。

这些大的计划最终会变成具体的开发任务,一个大的开发任务,会分拆到各个部门,各部门再将任务分拆到各个项目组。基于敏捷开发的话,主要就是看把这些开发任务放到哪几个 Sprint 去做,并且确保在规定的时间范围内完成。

至于工期的估算,在迭代规划会上会对每个 Ticket 进行打分,根据分数可以预估有多少工作量,要花多少时间。

3.上述案例与标准Scrum有什么不同?

首先是角色名称不一样,在 Scrum 里面是分 Product Owner、Scrum Master 和 Team 三种角色,而在这个案例中是产品经理、项目经理和团队成员,但其实只是名字叫法不一样。

还有要注意一点,就是传统的项目经理,会是偏控制型角色,Scrum Master 则更多是一种服务型的角色,主要职责是保障敏捷流程的执行,以及提供必要的帮助,很多团队的决策就是采用集体决策的方式。

另外,Scrum 有四种会议,除了前面介绍的三种:每日站会(Daily Scrum)、Sprint 计划会(Sprint Planning)和 Sprint 回顾会议(Sprint Retrospective),其实还有一种会议是 Sprint 评审会(Sprint Review)。Sprint 评审会的作用是让客户审查 Sprint 的完成结果。因为上面这个小组并没有直接的客户,都是完成产品经理提交的需求,而且沟通紧密,所以没有安排专门会议。

这个小组的站立会议并不是“标准”的站立会议,Scrum 的站立会议通常只有 15 分钟,并且只有轮流发言环节。这里增加的每天审查 Ticket 环节,主要是为了将优先级高的 Bug 修复之类的 Ticket 放到当前 Sprint,及时响应,及时处理。

有的项目组没有这个环节,是由测试人员或者 Scrum Master 直接将 Ticket 放到看板。这个小组并没有使用用户故事来开发需求,而是由产品经理事先写好需求文档。

在上一篇文章里面,提到了 Scrum 采用用户故事的方式,分拆需求,减少繁重的需求文档,在实现的过程中再沟通确认需求。这是 Scrum 推荐的一种方式,也是一种高效的方式,但并不代表这是唯一的方式。如果有产品经理,可以提前几个 Sprint 就将需求文档写详细,一样可以达到高效的理解需求的效果。

0 55

一、什么是敏捷开发?

敏捷不是一种方法论,也不是一种软件开发的具体方法,更不是一个框架或过程,而是一套价值观和原则。

也就是说,当你开发做决策的时候,遵守了敏捷开发的价值观和原则,不管你是不是用 Scrum 或者极限编程,那么都可以算是敏捷开发。

敏捷开发就是快速迭代、持续集成、拥抱变化。

 

二、敏捷开发想解决什么问题?

如果你仔细读了敏捷宣言,你会发现,宣言中右边的内容其实都是瀑布模型核心的内容:流程和工具、详尽的文档、合同谈判、遵循计划。

虽然敏捷开发并未对瀑布模型的价值进行否定,但也表明了瀑布模型做的还不够好,同时提出了一套自己的价值观。

比如说,我们开始做一个新项目,需要从客户那里收集整理需求,如果按照传统的软件开发模式,我们需要在开发前获得所有需求然后和客户签订合同,在发布前都不会轻易修改需求。

但是如果我们采用敏捷开发模式来开发项目,那这样做显然违背敏捷的价值观:“客户合作高于合同谈判”。所以如果是敏捷开发,在每个迭代后,都应该向客户收集反馈,然后在后面的迭代中,酌情加入客户反馈修改的内容。

结合敏捷开发提出的背景,你其实不难发现,敏捷开发就是想解决瀑布模型这样的重型软件开发方法存在的问题,用一种轻量的、敏捷的方法来改善甚至是替代它。这些年敏捷开发也是一直这么做的。

瀑布模型的典型问题就是周期长、发布烦、变更难,敏捷开发就是快速迭代、持续集成、拥抱变化。

 

三、如果用敏捷的方式盖房子

在讲瀑布模型的时候,我拿盖房子举了个例子,

如果改成用敏捷开发的模式盖房子,则会是这样子的:

  • 客户想要盖一栋房子(初步的想法)
  • 产品经理和客户进行了初步的沟通,把用户的需求写成了一个个用户故事(用简单的用户故事代替繁重的需求文档)
  • 例如:作为一个上班族,我想要一个卧室,以便于休息;作为一个家庭主妇,我想要一个厨房,以便于做饭。
  • 施工人员根据用户故事和客户进一步沟通(客户合作高于合同谈判),然后对用户故事进行设计和实现;
  • 每个用户故事开发时,还要给一个测试机器人编写测试脚本,让机器人可以自动测试(大量采用自动化测试),并且做好的用户故事可以随时被测试验收(随时发布,持续集成)
  • 每个 Sprint 四个星期时间(时间盒子,迭代时间固定)
  • 第一个 Sprint 搭了个草棚,一张床就是卧室,厕所就挖了一个坑,厨房还来不及搭建(每个 Sprint 会选择高优先级的用户故事),屋顶还在漏水(每个 Sprint 会定期发布,客户可以随时看到可用版本,即使还不完整)
  • 第二个 Sprint 有了简易厨房,同时修复了屋顶漏水的毛病(每个 Sprint 不仅完成用户故事,还会修复 Bug)
  • 第三个 Sprint 升级成了小木屋,但是忘记加上窗户(敏捷推崇自动化测试,但可能会测试不完备)
  • 第四个 Sprint 升级成了砖瓦房,窗户也开好了,客户可以入住。但是这时候客户发现一家三口的话,完全不够用,需要扩建到 3 个卧室。于是决定下个迭代改成 3 个卧室(响应变化高于遵循计划)
  • 第五个 Sprint,升级成了 3 个卧室,升级过程中把厨房下水道弄坏了(迭代过程中可能会导致质量不稳定)
  • 第六个 Sprint,修复了下水道的问题,房子也装修好了(迭代中不断完善);
  • 客户验收使用(上线)。

用敏捷开发的方式,不再像瀑布模型那样有严格的阶段划分,会在迭代中不断完善;不再写很多文档,而是和客户一起紧密合作;不再抵制需求变更,而是即时响应变更;不再等到测试阶段才发布,而是随时发布,客户随时可以看到东西。

当然,采用敏捷开发的模式也存在一些问题,例如全程需要客户参与,由于测试相对少一些 ,问题也会相应多一些。

 

四、敏捷开发和瀑布模型的差异

这些年敏捷开发,已经逐步发展出一套 “Scrum + 极限编程 + 看板” 的最佳实践,Scrum 主要用来管理项目过程,极限编程重点在工程实践,而看板将工作流可视化。

我将基于 Scrum 和极限编程的实践,来对比一下敏捷开发模型和瀑布模型的差异。

1. 敏捷开发是怎么做需求分析的?(用户故事)

瀑布模型要求产生详尽的需求分析文档,敏捷开发的需求来源于一个个的用户故事:

  • 作为用户,我想登录网站
  • 作为客人,我想有个卧室休息

在Sprint的开发中再去确认具体需求的细节。

好处:减少了大量需求文档的编写,可以早些进入开发;

但对开发人员在需求理解和沟通的能力上要求更高了。

2. 敏捷开发是怎么做架构设计的?(一部分需求,渐进式架构,会产生技术债务)

瀑布模型在需求分析完了以后,就需要根据需求做架构设计。

而在敏捷开发中,并不是基于完整的用户需求开发,每个 Sprint 只做一部分需求,所以是一种渐进式的架构设计,当前 Sprint 只做适合当前需求的架构设计。

这种渐进式的架构设计,迭代次数一多,就会出现架构满足不了需求的现象,产生不少冗余代码,通常我们叫它技术债务,需要定期对系统架构进行重构。

3. 敏捷开发怎么保证项目质量?(编写开发功能时编写单元测试和集成测试,自动化测试)

瀑布模型在编码完成后,会有专门的阶段进行测试,以保证质量。

在敏捷开发的 Sprint 中,并没有专门的测试阶段,这就依赖于开发功能的同时,要编写单元测试和集成测试代码,用自动化的方式辅助完成测试。

相对来说,这种以自动化测试为主的方式,质量确实是要有些影响的。

4. 敏捷开发是怎么发布部署的?(持续集成,每完成一个任务构建部署,测试)

瀑布:编码–>测试环境–>生产环境

瀑布模型通常在编码结束后,开始部署测试环境,然后在测试阶段定期部署测试环境。测试验收通过后,发布部署到生产环境。

敏捷开发:持续集成

在敏捷开发中,这种持续构建、持续发布的概念叫持续集成,因为整个过程都是全自动化的,每次完成一个任务,提交代码后都可以触发一次构建部署操作,脚本会拿最新的代码做一次全新的构建,然后运行所有的单元测试和集成测试代码,测试通过后部署到测试环境。

持续集成是一个非常好的实践,极大的缩短和简化了部署的流程,而且自动化测试的加入也很好的保证了部署产品的质量。前期搭建整个持续集成环境需要一定技术要求。

5. 敏捷开发的 Sprint 和迭代模型的迭代有什么区别?

增量模型和迭代模型,这两种也是一种快速迭代的方式,那么敏捷开发和 迭代模型的区别是什么?

迭代模型本质上是一个小瀑布模型,所以在一个迭代里面,需要完整的经历从需求分析,到设计、编码、测试这几个完整的阶段。

所以像瀑布模型一样,刚开始测试的时候是不稳定的,到测试后期才逐步稳定下来,一般迭代前期也会相对轻松一点,而后期测试阶段可能会时间很紧张。

敏捷开发的 Sprint 中,没有像瀑布模型那样严格的开发阶段划分,而是一个个循环迭代的 Sprint

举例来说,一个瀑布模型的项目,可能会按照阶段分成:2 周需求分析,2 周设计,4 周编码,2 周测试,然后上线发布,一共 10 周。如果用敏捷开发的方式来进行,那么可能会是每 2 周一个 Sprint,每个 Sprint 结束后,都会发布上线,每次发布的可能只是完整功能的一部分,但是每次发布的都是一个可用的版本,通过多个 Sprint 的迭代,最终完成项目开发。具体到每一个 Sprint 的开发周期中,在一个 Sprint 中会有多个小的开发任务,这些开发任务主要是新功能的开发和 Bug 的修复。

由于每个 Sprint 周期很短,所以不能像瀑布模型那样有充足的时间去做需求分析、设计和测试,那么敏捷开发中怎么保证质量呢?在敏捷开发中,通常用“用户故事”这样的方式来代替传统的需求分析,也就是以用户故事的形式,对一个需求进行简单的描述,配合关键的测试用例,并且和需求方的紧密沟通,让开发人员可以理清楚需求;通过“只做刚刚好的设计”来节约设计上的时间;通过“自动化测试”、“持续集成”来提升测试效率。

相对来说,敏捷开发中,整个 Sprint 的节奏是比较恒定,产品也是相对稳定的,即使用户故事没有完成,也不影响版本的发布。因此,敏捷开发更注重软件开发中人的作用,需要团队成员以及客户之间的紧密协作。

五、什么时候选择敏捷开发?

条件:

  • 团队要小,人数超过一定规模就要分拆;
  • 团队成员之间要紧密协作,客户也要自始至终深度配合;
  • 领导们的支持。敏捷需要扁平化的组织结构,更少的控制,更多的发挥项目组成员的主动性;
  • 写代码时要有一定比例的自动化测试代码,要花时间搭建好源码管理和持续集成环境。

因为敏捷开发对项目成员综合素质要求更高,做计划要相对难一些。如果团队大、客户不配合、领导不支持,再好的敏捷方法也很难有效实践起来。

如果你要实践敏捷开发,建议先找个小项目进行试点,能证明可行了,再进一步推广。

有条件的话,可以和一些顾问公司合作,请人做专门的培训和指导。如果不具备条件,应该考虑先把其中一些好的实践用起来,比如说持续集成、每日站会、自动化测试等。

 

六、总结

流程、工具、文档、合同、计划都是工业化的标志。它们带来了稳定的质量、惊人的效率、超大规模的协作,对于软件工业也是如此。

然而软件工业具备轻资产、知识密集型、从业人员素质高等特点,充分发挥人的创造力和价值,是其相较传统工业更高阶的要求。加之软件工程面对的不确定性与复杂度更显著。于是“个体和互动高于流程和工具,工作的软件高于详尽的文档,客户合作高于合同谈判,响应变化高于遵循计划”的敏捷思想应运而生。

通过用户故事,理解用户需求。在迭代中采用渐进的架构设计。定期重构解决技术债务。功能开发的同时编写自动测试代码。自动化持续构建。

由于淡化了部分工业思维中兼顾稳定、质量、效率、成本的传统手段,敏捷思想的最终落地,需要素质极高的从业人员参与其中,且数量不宜过多,以此来弥补流程上的缺失。同时要团队与客户紧密协作,上级的充分信任,才能够有效发挥其灵活应变,又万变不离其宗的优势。这是大胆的返璞归真,好似回到了瀑布模型前的蛮荒时代,实则是更高级的打法,就像独孤九剑一般。所以,敏捷开发“道”的属性更浓。

敏捷开发具有快速迭代、持续集成、拥抱变化等诱人的特点,但也有苛刻的条件要求。不过,即使无法推行完整的敏捷开发,依旧可以在传统模式下,有针对性的应用敏捷开发的实践方法。