一、什么是敏捷?
敏捷开发以实现最高的业务价值为核心,
通过不断梳理需求的优先级来消除在低价值需求上的资源浪费,
通过提高沟通效率来消除团队沟通上的资源浪飞,
鼓励团队在一起工作,使得团队信息更加紧密、更透明。敏捷开发通过细分项目的交付目标灵活轻便的管理方式,让团队能够及时市场急业务需求的变化,提高研发效率和生产力。
一种以人为核心,迭代,循序渐进的开发方法。
聚焦价值、应对不断变化的需求
敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品。
1.1-敏捷开发的优点
敏捷(AGILE):
- 需求逐步完善;
- 信息沟通透明;
- 交付品客户满意
- 可以满足不断变化的需求
- 聚焦价值
- 提升团队竞争力
1.2-传统开发和敏捷开发的区别
传统开发方式是计划驱动,用可变的时间和资源实现功能
敏捷开发方式是客户价值驱动的,用确定的资源和稳定的交付时间不断满足动态变化的业务需求,对整个项目有一个粗略的估计,每一次迭代都有详细的计划。业务人员,需求规划人员,开发人员紧密合作。问题发现早,修复成本低。
我们分别从计划、变更、管理透明度、交付、风险和团队合作方面
瀑布+迭代开发:
- 项目专注于遵循计划;
- 团队对变更态度较保守、有严格流程控制;
- 项目过程对业务部门不透明;
- 专注于遵循计划、交付即结束;
- 项目风险较高、软件越晚交付风险影响越大、缓释风险或问题修复成本高;
- 仅对自己的工作负责、依赖文档沟通。
敏捷开发:
- 对整个项目做一次粗略的估计、每一次迭代都有详细的计划;
- 允许并鼓励需求变更、用业务价值驱动;
- 业务人员、需求规划和开发人员之间的合作关系紧密;
- 专注于对交付软件的不断修正和打磨;
- 风险发现早、问题修复成本低;
- 注重团队融合、面对面沟通、团队共同为最终交付的软件负责。
1.3-敏捷的定义
敏捷开发Agile Development:一种以人为核心、迭代、循序渐进的开发方法。
1.4-敏捷宣言:
- 个体和互动胜流程和工具
- 工作的软件胜过详尽的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
- 尽管右项有其价值,我们更重视左项的价值
1.5-敏捷包括了具体的方法:
- 极限编程(Extreme Programming XP)
- SCRUM
- 动态系统开发(Dynamic Systems Development Method DSDM)
- 看版管理(kanban)
- 测试驱动开发(Test-Driven Development TDD)
- 精益软件开发(Lean Software Development)
- Scrumban
- 大规模(Scrum Large Scale Scrum LeSS)
- 规模化敏捷框架(Scaled Agile Framework SAFe)
- 自适应软件开发(Adaptive Software Develop ASD)
- 水晶方法
- 特征驱动开发(Feature Driven Development FDD)
1.6-敏捷宣言遵循的原则
- 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意;
- 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化;
- 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期;
- 业务人员和开发人员必须相互合作,项目中的每一天都不例外;
- 激发个体的斗志,以他们为核心搭建项目;提供所需的环境和支援,辅以信任,从而达成目标;
- 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈;
- 可工作的软件是进度的首要度量标准;
- 敏捷过程倡导可持续开发;责任人、开发人员和用户要能够共同维持其步调稳定延续;
- 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强;
- 以简洁为本,它是极力减少不必要工作量的艺术;
- 最好的架构、需求和设计出自自组织团队;
- 团队定期地反思如何能提高成效,并依此调整自身的举止表现。
二、什么是SCRUM——一个打造产品的方法
来自橄榄球运动中的争球的动作:公开(OPENNESS)、勇敢(COURAGE)、尊重(RESPRECT)、专注(FOUCUS)、承诺(COMMITMENT),他是一个团队流程。
2.1-迭代
迭代是把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程,同时每一次迭代都可以开发出一个可以交付的软件产品。
Sprint迭代
2.3-用户故事
用户故事是以一种形式简洁的、面向验收展开的功能或特性的描述。敏捷开发将用户需求被拆分为故事,以此作为团队交流、开发、测试和获得反馈的工作单元。
通过用户故事团队的客户角色、实现功能和业务价值这三个去修要素达成共识。
其完成的定义(Definition of Done):让所有干系人对交付的最终目标建立共识。
2.4-用户故事地图
用户故事地图是一门在需求拆分过程中保持全景图的技术,可以将你的待办事项清单(backlog)变成一张二维地图
使得大家对项目从共享文档变成对产品取得共识
好的用户故事应该遵循INVEST规则:
- 独立的(Independent)
- 便于沟通的(Negotiable)
- 有价值的(Valuable)
- 可估计的(Estimable)
- 短小(Small)
- 可测试的(Testable)
2.5-Scrum软件开发流程
产品负责人(Product Owner)————>产品代办事项列表Product Backlog(特性、功能、需求、改进、修复;会随着产品需求和项目的改变而不断的丰富)
迭代计划会议Sprint Planning————>迭代代办事务列表Sprint Backlog
三、Scrum的三个角色
开发团队(Team)、产品负责人(Product Owner)、敏捷教练(Scrum Master)
3.1-产品负责人(Product Owner):
- 对产品负责,确定产品愿景及产品规划和所有产品需求相关的事项;
- 建立产品愿景,产品待办事项的唯一负责人;
- 负责定义产品功能,管理产品待办事项列表并保证其对于业务部门和团队保持透明度;
- 对产品待办事项进行优先级排序;
- 接受/拒绝工作成果;
- 对项目的成功负责并保证投资回报率;
- 不可以由多人负责,不可由敏捷教练代替
3.2-敏捷教练(Scrum Master):
- 对团队资源及团队管理负责,于产品负责人一同把控产品质量;
- 保证团队可以遵守Scrum的价值、实践和规范;
- 指导高效,高质量工作;
- 保证团队不受外界因素的干扰;
- 保证各个不同的角色之间的良好协作,消除障碍;
- 帮助PO更好的利用团队的能力;
- 保证团队实现价值的增量;
- 不能代表团队做决定;
- 不能同时担任产品负责人;
- 可以由团队成员担任;
- 与团队成员无上下级差异;
3.3-开发团队(Team):
- 通过讨论用户故事,团队对细分需求的客户角色、实现功能和业务价值这三个需求要素达成共识。一般5-9人;
- 决定一个迭代周期中完成的工作量;
- 共同对迭代目标负责;
- 管理跟进迭代任务;
- 不断自我改进;
- 不可等待分派任务;
- 不可等待项目经理解决问题;
- 不可依赖队友的决定;
- 对团队资源及团队管理负责,与产品负责人一同把控产品质量。
四、Scrum的五个活动
所有事件都是有时间盒限定的事件,也就是说每一个事件限制在最长的时间范围内。一旦 Sprint 开始,它的持续时间是固定的,不能缩短或者延长。而其他事件则可以在该事件的目标达成之后可以立即终止,如此确保时间被适当地使用而不会造成过程中的浪费。
Sprint 除了本身作为一个事件以外,它还是其他所有事件的容器,在 Scrum中的每个事件都是用来进行检视和适应的正式机会。这些事件都是被特别设计用来确保达成透明和检视。如果 Sprint不能成功地包含这些事件中的任何一个事件,导致透明化的降低,同时也会丧失进行检视与适应的机会。
4.1-产品待办事项列表:
发生在下个迭代开始前,一般是对下个迭代需求的讨论、澄清、细化,以保团队成员对需求的理解一致,帮助团队在下个迭代更快地进入到开发工作中。
- 对需求进行梳理,排序、拆分、细化和澄清;
- 进行需求的拆分,生成用户故事,使得优先级高的需求被团队成员理解;
- 能够支撑后续敏捷开发活动的开展
4.2-迭代计划会议:
发生在迭代的开始,PO、ScrumMaster和开发人员一起规划这个迭代的内容,即这个迭代完成哪些故事,预测在一个合理的条件范围内承诺能完成的工作量。
- 迭代目标以及迭代待办事项;
- 拆分每个迭代的需求,生成Sprint迭代待办事项列表;
- 帮助团队对细化后的需求的理解达成一致。
- 成熟的敏捷团队可以将产品待办列表梳理会和计划会议合在一起。
4.3-每日站立会议:
- 保证成员对现状、问题和风险有一致的了解;
- 确保迭代目标得以实现;
- 固定时间,固定地点,15分钟。全员参与(5-9人);
- 了解当前迭代周期内各项任务的进展,以确保任务都能按时完成,同时站会也能有效地提高团队成员工作的主观能动性。
团队成员主要回答以下三个问题:
1、昨天完成了什么帮助团队完成冲刺?
2、今天打算做什么帮助团队完成冲刺?
3、什么因素阻碍了团队的前进之路?
若有遇到障碍,在找到对应的解决/协助人后,应在会后讨论具体的解决方案,这是一个很好的控制站会时间的方法。
4.4-迭代评审会议:
迭代评审会议是在当前迭代结束前开发团队给用户(业务、产品负责人、利益相关者、管理人员等)展示成果的过程,团队展示的成果是符合事先约定好的“完成定义”的,展示的成果不一定是完整的产品,但需是一项可以使用的功能。
- 确认系统功能和用户期望是否一致;
- 收集用户反馈,明确后续目标;
- 检查和调整正在构建的产品是否为客户真正想要的(确保开发沿着正确的方向走);
- 经常受到反馈消息可以让Scrum团队更好的理解产品与业务需求。
这个会议和迭代回顾会都是“检查与调整”的活动。
4.5-迭代回顾会议:
这个会议出现在迭代演示会后,下一个迭代开始前。在进行迭代回顾会时,开发团队、PO、ScrumMaster一起来对当前迭代哪些实践是做得好的(Scrum、技术、工作环境/氛围等)、哪些实践是可以做得“更好的”,对于哪些可以做到更好的要制定好相应的解决方案,并指定相应的任务跟踪人。
- 使整个团队回顾整个迭代的过程和结果;
- 总结经验,寻找最佳的工作方式,自我改进。
迭代演示会一样也是“检查与调整”的活动,两者的区别是,迭代演示会是检查调整产品,而迭代回顾会使检查调整过程。到这里大家应该明白了,Scrum是一个持续改进的过程。
五、Scrum的三个工件
Scrum 的工件以不同的方式展现工作和价值,可以用来提供透明性以及检验和适应的机会。Scrum 中所定义的工件能最大化关键信息的透明性,来保证 Scrum 团队成功地交付完成的增量。
5.1-产品待办事项列表(Product Backlog)
- 产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源;
- 产品负责人负责产品待办事项列表的内容、可用性和优先级;
- 产品待办事项列表是一个持续完善的清单, 最初的版本只列出最初始的和众所周知的需求;
5.2-迭代待办事项列表(Sprint Backlog)
Sprint 代办事项列表是一组为当前 Sprint 选出的产品代办事项列表条目,外加交付 产品增量和实现 Sprint 目标的计划。Sprint 代办事项列表定义了开发团队把产品代办事项列表条目转换成“完成”的增量 所需要执行的工作。
Product Backlog 功能点被放到Sprint的固定周期中,Sprint Backlog 会因为如下原因发生变化:
-
随着时间的变化,开发团队对于需求有了更好的理解,有可能发现需要增加一些新的任务到Sprint Backlog中。
-
程序缺陷做为新的任务加进来,这个都做为承诺提交任务中未完成的工作。
5.3-产品增量(Product Increment)
增量是一个 Sprint 完成的所有产品待办列表项的总和,以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后,新的增量必须是“完成”的,这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。增量是在 Sprint 结束时支持经验主义的可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它,增量必须可用。
六、SCRUM的五个价值观
- 承诺 – 愿意对目标做出承诺;
- 专注– 把你的心思和能力都用到你承诺的工作上去;
- 开放– Scrum 把项目中的一切开放给每个人看;
- 尊重– 每个人都有他独特的背景和经验;
- 勇气– 有勇气做出承诺,履行承诺,接受别人的尊重。
七、怎样才能变得敏捷
用开放的心态看待变化
掌握相关的知识,技能,工具
在实践中学习
业务部门和科技更紧密的合作
- 业务人员和开发人员一起工作,从依赖书面沟通转变为面对面的交谈,沟通效率更高,信息更透明
- 减少不必要的工作,尽量简洁。让团队更加专注于业务价值的交付
- 以交付产品来衡量团队和项目进队,让团队更加专注于交付产品本身
- 尽早、持续的交付软件,让业务需求尽早实现,尽快让业务部门看到功能
- 欢迎对未开发的需求进行调整,紧跟快速变化的市场需求
- 对技术的精益求精,不断学习新的技术和工具,对设计的不断完善将不断提升敏捷性
- 建议团队定期回顾总结,如何做的更好,并相应地调整团队的工作方式,鼓励团队自我完善、
- 激励团队成员,给予资源及充分的技术培训,相信他们能够完成任务,激发团队成员的工作热情和斗志,从局部的工作任务提交,向“端到端”交付结果负责。
1320

被折叠的 条评论
为什么被折叠?



