©2016-2024 Matools All rights reserved,
粤ICP备17059708号
敏捷软件开发最近几年越来越火。跟传统软件开发相比有什么优点呢。今天我们就来聊一聊。
首先我们来看下什么叫做敏捷。
敏捷软件开发过程
软件开发过程是指设计软件开发过程中涉及的一系列活动，指导开发组一步一步的进行软件开发。
包括传统的瀑布过程、螺旋过程、原型过程、敏捷过程等。
敏捷则是一类过程的统称。之所以把他们都称之为敏捷，是因为它们有共同的特点。
敏捷过程讲究快速迭代快速试错，将一个大的项目分解成一个一个独立的小项目，每个项目实现一定的功能，每个项目的成果物
都是可以运行的软件。经过多次迭代之后完成整个项目。
这里有两个关键点：
1.独立的小项目
2.每次交付可以运行的软件。
与瀑布开发方法的对比：
1.粒度更小，更容易施加控制，降低复杂度。
2.更好的适应需求的变化。传统瀑布方法需要经历需求获取、需求分析、设计、开发、测试、交付、运维等。上下步存在严格的依赖关系。一旦中间有任何一步出现问题则会导致难以估量的错误，越到后期修改的成本越大。而敏捷方法及时的引用开发和测试以及客户参与，可以及时调整偏差。及时出现问题也只需要付出很小的代价。因此更灵活。
3.人的认知过程是循序渐进的，敏捷方法推崇增量式需求获取。符合人类的认知习惯。经过多次迭代对需求认识越来越清晰，可以及时纠正原有的认知错误。而瀑布方法妄图在开始时一次性花费巨大的代价获取所有需求。而且获取的需求也不一定是准确和完整的。
4.瀑布方法上下步是串行的，具有严格的次序关系。因此在执行前面的步骤时负责后面任务的人员都处于闲置状态。人员利用率不足。
敏捷宣言
1.个体和交互胜过流程和工具
面对面沟通是最有效率的方式，人才是最重要的。胜过繁琐的流程和工具。
2.可以运行的软件胜过面面俱到的文档
文档只是工具不是结果。不能为了文档而文档。而应该将主要精力放在如何构建正常运行的软件上。
3.客户参与胜过合同谈判
多和客户沟通，让客户参与到项目中来，有助于交付满足客户期待的软件。
4.响应变化胜过遵循计划
拥抱变化，面对变更应及时调整策略
敏捷方法是一系列过程的统称，都包括哪些过程呢？
XP(极限编程)、RUP(统一软件过程)、Scrum等。
其中scrum在近些年越来越流行。因此我们专门介绍下。
Scrum英文意思是橄榄球，这里用橄榄球运动来代表这种开发方法激烈、刺激。
Scrum是敏捷的一种，因此符合敏捷过程的所有特点。但是敏捷中的每种方法在具体实施时还是有一些不小的差异。
这里我们着重介绍Scrum。
Scrum讲究以人为本，采用迭代方法、循序渐进的开发软件。
具有三种角色：
Product Ower：产品owner，类似于产品经理。负责收集需求，定义优先级，确定需求实现程度
Scrum Master:
Scrum教练，负责项目按照scrum流程执行，处理在项目执行中遇到的各种困难和阻力，把控质量、跟踪进度。类似于传统PM的角色但又有比较大的差异。
Scrum Team:Scrum开发组，在scrum的框架下执行项目开发工作。
Sprint
英文是冲刺的意思，代表一次迭代过程。每次迭代２－４周。
几种活动：
Sprint plan meeting：冲刺计划会议，在每次冲刺前进行。由scrum master product ower、scrum
team和高层参加，时间一般为
4-8小时。Product owner将product
backlog中的任务划分优先级，同时进行需求澄清。scurm团队成员对本次sprint要完成的user
story进行分解成task，挑选感兴趣的任务并接进行工期估算。
Sprint daily meeting: 每日站会，两个主题：昨天做了什么，今天计划做什么。进度如何。
Sprint review :sprint 评审，每次冲刺结束时由Scrum
team将本次冲刺完成的任务进行展示，检验执行情况和质量。长度控制在两个小时左右，不需要ppt。与会人员根据sprint计划会议的目标来评审目标的完成情况。
Sprint 回顾会议：回顾整个冲刺，总结和反思，促进团队持续成长。
燃尽图：横轴表示sprint花费的时间，纵轴表示sprint中所有的任务。燃尽图可以体现sprint的进度。
User Story:sprint backlog中的每一项都使用一个User Story来描述。一个User
Story就是站在用户的角度对系统的每一项功能的一项简短描述。User Story粒度不要太大，一般需要在一个sprint内完成。Scrum
team会将User Story拆分成一个或多个task。
scrum开发流程。
Product Owner在项目开始时将任务放进Product backlog，由于需求是增量式获取的，因此这个过程也是增量式的向Product
backlog中添加任务。
在每次sprint开始时，进行sprint plan meeting，会议上由product owner确定product
backloug中任务的优先级，scrum团队决定本次sprint要完成的任务，将任务分解成工作项并进行工期估算，同时将任务从product
backlog转移到sprint backlog。冲刺阶段每日进行sprint daily
meeting，每次在15分钟左右。两个主题：昨天完成了什么，今天计划做什么。有困难提出但会后和相关干系人讨论，不占用会上时间。冲刺结束时进行冲刺评审，对本次冲刺完成的任务进行演示。检查完成情况。冲刺评审之后进行冲刺回顾，回顾过去的冲刺存在的问题，提出改进方案。重复以上过程，直到完成所有任务。
Scrum与加班的关系
敏捷不提倡加班。敏捷的开发不是一直以冲刺的力量奔跑，而是要求团队成员密切配合步调一致，使整个项目有序的向前推进。
加班从长远来看对整个团队的士气和战斗力是不利的。
加班的源头，一是因为计划不充分、不准确，中途有不可预料的变化。scrum的流程、每日sprint会议、sprint计划会议等都是为了克服传统软件开发的弱点。这些弱点包括：流程无序、管理困难、难以变更、难以拥抱变化。另一个原因是文化氛围或者观念，认为只有
加班才能体现对工作的热情，这是很幼稚的。对一个人来说，长时间的工作和生活的不平衡都会导致一些问题。敏捷开发讲究以人为本，对于团队来说如果人出了问题项目失败的可能性就可能达达增加。
几种中国式的敏捷：
极限编程：每天只工作8小时，还没有达到极限，工作不饱和。来来来多给你分配点任务。
拥抱变化：产品、需求频繁变更，朝令夕改，昨天说好的今天又变卦。
迭代式开发：做完了赶紧上线，出了问题再修复一版更新上去。
持续集成：每天提交几百行代码，不用编译不用自测不用测试用例。
测试驱动：点了两下没发现问题就可以发布了。
迭代回顾：新版本刚上线肯定有很多问题，这两天辛苦一下。24小时待命。
sprint冲刺：明天版本上线，大家辛苦通宵冲刺一下。
结对编程：开玩笑，一个人的任务两个人轮流干，每人只领一半工资行不行。
热门工具 换一换