敏捷开发知识体系整体框架

上传人:大米 文档编号:563353992 上传时间:2023-12-20 格式:DOCX 页数:18 大小:171.57KB
返回 下载 相关 举报
敏捷开发知识体系整体框架_第1页
第1页 / 共18页
敏捷开发知识体系整体框架_第2页
第2页 / 共18页
敏捷开发知识体系整体框架_第3页
第3页 / 共18页
敏捷开发知识体系整体框架_第4页
第4页 / 共18页
敏捷开发知识体系整体框架_第5页
第5页 / 共18页
点击查看更多>>
资源描述

《敏捷开发知识体系整体框架》由会员分享,可在线阅读,更多相关《敏捷开发知识体系整体框架(18页珍藏版)》请在金锄头文库上搜索。

1、1 敏捷开发知识体系整体框架1.1敏捷开发工程实践111项目管理迭代开发风险价值生命周期多级项目规划完整团队 每日站立会议*任务板燃尽图1.1.2 需求管理需求订单业务流程草图用例驱动开发用户故事1.1.3架构演进的架构*演进的设计*基于组件的架构设计1.1.4开发结对编程测试驱动开发 重构代码规范1.1.5 测试单元测试*并行测试*测试管理1.1.6变更管理持续集成自动构建团队变更管理12敏捷开发管理实践描述*定义和特征说明主要角色主要活动和最佳实践*主要输入输出工作流程13敏捷开发工程实践描述*定义和特征说明应用说明案例说明2敏捷开发核心价值观和原则2.1敏捷软件开发宣言*个体和互动高于流

2、程和文档*工作的软件高于详尽的文档*客户合作高于合同谈判响应变化高于遵循计划*也就是说,尽管右项有其价值,我们更重视左项的价值.2.2敏捷软件开发的核心价值观敏捷开发的核心理念就是以最简单有效的方式快速打成目标 响 ,并在这个过程中及时地 应外界的变化,做出迅速的调整.2.2.1 核心价值观以人为本目标导向客户为先拥抱变化222敏捷开发的原则我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。业务人员和开发人员必须相互合作,项目中的

3、每一天都不例外。 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。可工作的软件是进度的首要度量标准。 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。以简洁为本,它是极力减少不必要工作量的艺术。 最好的架构、需求和设计出自自组织团队。团队定期地反思如何能提高成效,并依此调整自身的举止表现。3敏捷开发管理实践3.1 ScrumScrum 是一种迭代式增量软件开发过程,通常用于敏捷软件开发。 Scrum 包括了一系 列

4、 实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色 负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。3.1.1 Scrum 中的角色3.1.1.1猪”角色* 产品负责人( Product Owner)通常由市场部门的人担任敏捷教练(Scrum Master)*通常由开发组组长担任开发团队( Scrum Team)包括开发 ,需求,测试3.1.1.2鸡”角色用户软件是为了某些人而创建! 就像 假如森林里有一棵树倒下了, 但没有人听到,那么它算发出 了声音吗”,假如软件没有被使用,那么它算是被开发出来了么? ”利益所有者(客户,提供

5、商)*影响项目成功的人,但只直接参与冲刺评审过程。管理者*为产品开发团体架起环境的那个人3.1.2 主要活动和最佳实践冲刺回顾会议(Retrospective Meet ing)凳.+ .作*(盘十3?Sprint Backlog”覇冲剧龔审会段 何*M*F*用仇均 SCMiK测尙乱Oaiiy Scrum -AliMCRUMf豪三 f IHkTft 1AXK MM /冲敢塊別仝彊,贬人 w 的产乩* 担息Wprwl釣左M迭代0、Vj迭代式软件开发 两层项目规划(Two-Level Project Planning)整体团队协作(Whole Team)持续集成冲刺规划会议(Spri nt Pla

6、n Meeti ng)每日站立会议冲刺复审会议(Spri nt Daily Meet ing)(Sprint Review Meeting)3.1.3主要输入输出产品订单 (Product Backlog) 冲刺订单 ( Spring Backlog) 燃尽图 ( Burndown Chart)新的功能增量3.1.4工作流程3.1.4.1项目管理过程在 Scrum项目管理过程中产品负责人获取项目投资,并对整个产品的成功负责*产品负责人协调个中利益干系人, 确定产品订单中初始的需求清单及其优先级,完成项目商业价值分析和项目整体规划, 并任命合适的敏捷教练开展项目工作3.1.4.2项目开发过程在S

7、crum软件开发过程中,每个冲刺就是较短的迭代,通常为24周.*在每个冲刺开始时, 产品负责人和敏捷教练通过召开冲刺规划会议和”两层项目规划”的最佳实践制定冲刺订单(类似迭代计划)在每个冲刺迭代中 ,团队强调应用”整体团队协作”的最佳实践,通过保持可持续发展的工作节奏 和每日站立会议,实现团队的自组织,自适应和自管理,高效完成冲刺工作在每个冲刺结束时 ,团队都会召开冲刺复审会议 ,团队成员会在会上分别展示他们开发出的软件 (或其他有 价值的产品),并从产品负责人和其他利益关系人那里,得到反馈信息.在冲刺复审会议之后 ,团队会自觉招开冲刺回顾会议 ,回顾整个项目过程,讨论哪些方法做的好 哪些方面

8、 可以改进,实现软件交付过程的持续,自发的改进3.2 XP3.3 OpenUp3.4 Lean4敏捷开发工程实践4.1 迭代式开发敏捷迭代开发是指每次按照相同的开发方式短期的开发软件的部分,或前期开发并不详尽的软件,每次开发结束获得可以运行的软件,以供各方干系人观测,获得反馈,根据 反 馈适应性的进行后续开发,经过发福多次开发,逐步增加软件部分,逐步补充完善软件, 最终 开发得到最后的软件每次反复开开发叫一次迭代,在Scrum中成为Sprint,中文常译为”冲 刺”.4.2 持续集成持续集成(Continuous integration)是指当代码提交后,马上启动自动编译,自动部署金额 自动化

9、测试来快速验证软件,从而尽快的发现集成错误.4.3 多级项目规划多级项目/产品规划, 在软件开发领域, 是指以迭代开发为基础, 形成多层次的, 逐步 细 化的项目或产品计划这些层层相关的项目/产品规划包括:*项目/产品愿景*项目/产品路线图版本发布计划迭代计划每日实现4.3.1 项目/产品愿景在计划阶段,首先,项目stakeholder,项目/产品负责人将参与并组成工作组,他们负责阐述项 目的重要性,给出项目成功失败的关键标准以及项目整体层面”完成”的定义;在过程中,可以利用形成项目愿景的一些个工具,包括愿景盒子(Vison Box),业务收益矩阵(Busi ness Ben efits Ma

10、trix),项目范围矩阵(Scope Matrix),滑动器(Slider),成本收益矩阵 (Cost/Benefit Matrix)等;最后,项目愿景需要使用尽量简要的文档固定下来,并保证项目团 队成员都能了解.该文档需要包括:当前的问题机会描述和理由 (描述项目的重要性 )项目的价值项目如何和组织的战略目标达成一致*解决方案综述项目包含的关键功能项目必须服从的技术和约束条件项目范围项目的关键时间线*项目收益分析项目和其他项目的依赖性项目的相关风险以及如何消除4.3.2 项目/产品路线图主要描述为了达到产品愿景而需要交付的关键功能和特性,这些特性基本处于Epic和特性 层面,不包裹用户故事(

11、User Story).它从时间的维度来表述对愿景的支持和实现它从时间维度 来表达对愿景的支持和实现当项目/产品需要发布多个版本时,项目线路图就非常重要,否则, 它和发布计划相同,项目/产品线路图由项目负责人和项目经理维护,并保持更新通常,会形 成路线图问题或幻灯片, 使用大图标显示重要的里程碑, 包含的功 能和发布日期等, 让所有项 目/产品相关人员都清楚产品各个组件的可能发布日程 4.3.3 版本发布计划版本发布计划由团队成员和项目/产品负责人共同制定, 并通过版本发布计划会议讨论 通 过它包括了当前版本需要交付的,达成一致的关键功能,并经过优先级排序,可以包含EPIC 和User Sto

12、ry版本发布计划中常使用的概念包括:故事点,迭代团队速率和优先级排序通常,项目/产品负责人提出本次发布的目标,团队成员根据目标和功能特性的重要 性对故事进行排序,并依据团队速率觉得本次发布需要包含的故事点前几次版本发布使 用估算值,其准确性随着项目/产品的时间持续而逐步精确版本发布计划是剧本适应性可调整的 计划, 会随着项目演进而改变.434迭代计划迭代计划是对版本发布计划的再次细化, 同样由团队成员和项目/产品负责人共同制定 并听 过迭代计划会议讨论通过.迭代会议负责两件事情:根据当前状态确定是否需要对版本计划做出更新 为当前的迭代计划制定迭代计划迭代计划中常使用的概念包括:拆分Epic和U

13、ser Story,任务,任务估算在迭代会议 上,成 员首先根据当前的项目变化对发布计划进行更新, 然后根据更新后的, 重新排序过的故事制定当前迭代需要完成的故事,并对这些故事进行详细的任务拆分成员在认领完任务 后, 会对任务的实现时间做出估算, 估算值需要具体到这些估算信息可以方便任何成 员追踪任 务的进度.4.3.5 每日实现没事实现是团队成员完成任务的具体过程, 它依据任务估算值并根据任务最终实现情 况更 新该值在敏捷方法中,使用每日站会议来报告进度通过15分钟的站立形式,团队成员报告故 事或者任务的完成,未完成状态,而解决层面的问题则在会议之后处理.4.4 完整团队Scrum 团队必须

14、具备的三个完整性:4.4.1 团队职责完整性4.411产品负责人(Product Owner) 确定产品的功能。*决定发布的日期和发布内容。为产品的收益(profitability of the product)负责。根据市场价值确定功能优先级。*在 30天内调整功能和调整功能优先级。接受或拒绝接受开发团队的工作成果4.4.1.2 敏捷教练(Scrum Master)负责监督整个 Scrum项目进程,调整开发计划保证团队资源完全可被利用并且全部是高产出的。 保证各个角色及职责的良好协作。解决团队开发中的障碍。做为团队和外部的接口,屏蔽外界对团队成员的干扰。保证开发过程按计划进行,组织Daily Scrum, Sprint Review and Spri nt Pla nning meet ings。4需要知道什么任务已经完成,哪些任务已经开始,哪些新的任务已发现,和哪些估计可能已经发 生变化.根据 以上的情况更新反映每天完成的工作量以及还有多少没有完成的 燃尽图*需要找出阻碍Scrum的障碍和依赖,根据优先级指定计划解决这些障碍个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清,或通过内部的沟通解决,或向管理层和HR寻求帮助解决 Scrum Master需要知道什么任务已经完

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 学术论文 > 其它学术论文

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号