1:什么是敏捷开发
敏捷开发以人为核心,采用迭代、循序渐进的方法进行软件开发。
我更赞同这个定义,网络上有的定义强调以用户需求为核心,突出不了人在整个敏捷开发过程的作用,后续的阐述也是围绕着人来阐述的。软件开发不以需求为核心,还以什么为核心呢。
2:为什么需要敏捷开发
更快更好完成用户需求,快速试错,及时迭代优化。
3:敏捷开发的分类及差别
现在主流的敏捷开发分为两种:scrum敏捷开发和xp敏捷开发,两者的差别是scrum强调过程,xp强调实践(XP的核心是沟通、简单、反馈、勇气四大价值观,它们是XP的基础,也是XP的灵魂)后面我们的讲解只针对scrum敏捷开发。
4:什么样的团队才能采用敏捷开发
敏捷开发指导思想并不是一把万能钥匙,得看团队情况而定,并不是每个团队采用了敏捷开发方式,团队面临的问题就能解决。那么什么样的团队适合采用敏捷开发模式呢?总结如下
第一:团队成员善于沟通和自我管理。
每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力。
第二:团队成员人数5-10人。
可以是临时从其他团队抽调组建的临时战斗单元(战斗结束随即解散)。短时间内能够完全专注于某一件事。团队必须包含三个角色(政委,长官,战士):
– 产品负责人(Product Owner)
主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。
– 流程管理员(Scrum Master)
负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发,ScrumMaster是Scrum团队中的服务式领导。
–开发团队(Scrum Team)
第三:团队人员稳定。
由于敏捷开发弱化了对项目文档的依赖,如果项目人员不稳定,在交接过程中会出现很大的困难。
5:怎么样做才是敏捷开发(四个会议,三个物件)
5.1:四个会议
以主人翁精神全员参与Sprint计划会议、每日例会、Sprint评审会议和Sprint回顾会议。
Sprint计划会议内容:
1)澄清需求、对"完成标准"达成一致
2)工作量估计、根据团队能力确定本轮迭代将会内容
3)细化、分配迭代任务和初始工作计划
关键点:
1) 充分参与:Scrum Master(项目负责人)确保PO(产品负责人)和Team(开发人员及UI美术)充分参考讨论,达成理解一致
2) PO(产品负责人)承诺在短迭代周期不增加需求(2-4周)
每日例会(不超过15分钟)
聚焦主题:
1)我昨天为本项目做了什么
2)我计划今天为本项目做什么
3)我需要什么帮助以便更高效的工作
每日站立会议好处:
1)增加团队凝聚力,产生积极的工作氛围
2)及时暴露风险和问题
3)促进团队内成员的沟通和协调
Sprint评审会议
Sprint结束时,Scrum团队和相关人员一起评审Sprint的产出。每个人都可以在Sprint评审会议上发表意见。产品负责人会对未来做出最终的决定,并适当地调整产品待办事项列表。
Sprint回顾会议
在每个Sprint结束后,Scrum团队会聚在一起开Sprint回顾会议,目的是回顾一下团队在流程、人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在的改进事项,为将来的改进制定计划。
5.2三个物件(产品待办事项列表(ProductBacklog)、Sprint Backlog和燃尽图)
ProductBacklog – 产品待办事项列表
产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。
SPRINTBACKLOG
Sprint 代办事项列表是一组为当前 Sprint选出的产品代办事项列表条目,外加交付产品增量和实现 Sprint目标的计划
燃尽图(Sprint Burn-down Chart)
Sprint Burndown Chart 显示了Sprint中累积剩余的工作量,它是一个反映工作量完成状况的趋势图。图中Y轴代表的是剩余工作量,X轴代表的是Sprint的工作日。
6:敏捷开发流与传统开发流程的对比
优点:
1. 敏捷开发的高适应性,以人为本的特性。
2. 更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。
缺点:
1. 由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。
(传统开发瀑布模型流程图)
优点:
1. 为项目提供了按阶段划分的检查点。
2. 当前一阶段完成后,您只需要去关注后续阶段.
3. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
缺点:
1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4. 瀑布模型的突出缺点是不适应用户需求的变化。
阶段 | 瀑布模式 | 敏捷开发 |
业务需求 | 强调需求文档 | 注重沟通交流 |
管理进度 | 管理文档(需求计划、进度表) | 看板(任务开发状态是否顺利进展、<br/>有没有阻塞) |
任务分配 | 开发人员被动安排 | 开发人员主动自我管理、责任心强 |
版本迭代 | 产品整体需求计划 | 小版本迭代 |
研发 | 开发人员安照需求文档要求开发<br/>较少沟通业务场景使用情况 | 开发人员站在用户需求角度对接需求 |
研发周期 | 版本周期较长 | 版本周期短(2-3周) |
7:scrum开发流程
1)我们首先需要确定一个Product Backlog(产品需求列表),这个是由PO负责的
2)有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;
3)Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);
4)在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)
5)做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本。
6)当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品。
7)最后就是 Sprint RetrospectiveMeeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;
8:敏捷开发总结回顾
1)参与敏捷开发的项目人员尽可能不被其他工作打扰。当项目中有一员频繁被调动处理项目之外事情,容易造成任务阻塞,会降低整体团队积极性。
2)项目人员,善于沟通,及时反馈,减少中间需求的增加。
3)要求技术人员水平较高,在快速版本迭代的同时,也要注重项目架构设计,应对后续需求变更。
4)产品负责人要及时对开发完成验收,确保开发完成任务符合版本需求目标。
5)项目开发人员要有主动积极性,对自己代码不断完善,及重构,避免重复开发,做到资源复用。