敏捷开发培训

敏捷开发 ()09/28/20109/7/20221 n 介绍9/7/20222 -敏捷的开发流程敏捷的开发流程n (敏捷的开发流程)是一种软件开发流程的泛称，几项共通的特性：n客户与开发人员形成密切合作的团队，因为客户无法于初期定义完整的规格，而开发人员于开发过程中也常常无法知悉外在环境或业务的变动，所以需要两者密切合作方能开发适用的软件。n项目最终的目标是可执行的程序，因此所有的中间产品必须经过审慎评估，确认有助于最终目标，才需要制作中间产品。n采用 与 方式分阶段进行，密集 是否符合需求。n流程可以简单，但规划与执行必须严谨。n强调团队合作，赋予高度的责任，团队有自主权得以因应变化做调整9/7/20223 n敏捷开发是一种以人为核心、迭代、循序渐进的开发方法 n在敏捷开发中，项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。9/7/20224敏捷开发核心价值()n 个人和交流重于过程和工具n 正在运行的软件本身重于复杂的文档n 与客户的沟通和交流重于使用合同约束客户n a 对变化的快速响应重于跟随计划9/7/20225敏捷开发原则()1.最高目标是通过快速的和经常的发布软件满足客户的需要2.提交软件的周期为几个星期到几个月3.产生正确的软件是衡量进度的首要标准4.主动接受需求的改变而不是拒绝5.商务人员和开发人员工作在一起6.个人必须有动力，要创造环境支持他们的要求，信任他们7.最有效的交流方法是面对面的交流8.最好的结构，需求和设计来自于自组织的团队（），允许任何人提出想法和建议9.持续改进设计和编码10.鼓励正常工作，减少长时间加班11.保持简单，减少不必要的部分，认识到简单的设计比复杂的设计更难（）12.定期调整过程，获得更高效率9/7/20226敏捷开发的设计原则 n单一职责原则：n开放封闭原则：n替换原则：n依赖倒置原则：n接口隔离原则：9/7/20227敏捷开发-迭代计划最新版本验收测试发布计划迭代计划开发项目周期项目周期9/7/20228敏捷开发-迭代计划9/7/20229名词解释故事故事 是客户想要系统做的事情，适合在一至两个迭代内完成，并且是可测试的，他不一定是商业价值的直接体现。迭代迭代 是一个周期在2-4周，能够完成当前团队所能实现的，最具商业价值的功能，并可以提供一个可工作的小版本供发布。Velocity 翻译为项目周转时间。代表团队在给定周期内能够完成多少商业价值，以便用于衡量将来该团队能够提供的商业价值。也即昨天的天气。9/7/202210名词解释优先级优先级 主要考虑商业价值，同时兼顾市场风险、商业风险、技术风险等因素在内的一个衡量数字，优先级越高通常意味着其商业价值越高风险系数风险系数风险系数 综合商业环境、项目资源、技术以及项目环境等等因素在内的一个衡量数字，它是优先级的重要衡量指标之一。它通常出现在故事中。风险系数较大意味着优先级也较大。负载因子负载因子负载因子 是综合项目成员的技术能力、技能集、精神状态等等因素，对于团队成员的一个负载系数。9/7/202211名词解释理想时间理想时间 排除一切可能的外界干扰，同时排除自身的精神状态，职业态度等等因素，完成某项工作所需要的时间。实际时间实际时间 理想时间乘上负载因子任务任务任务 分配到项目成员，从故事切分的出来。通常任务时间不应该超过10个实际工作日。9/7/2022121.2.3.9/7/202213 n 为 提出的软件开发流程n内容含盖 ,等软件开发生命周期的直接工作n与 ,&，等支持性工作。9/7/202214 的主要精神 1.项目进行采用 程序分阶段渐进地完成项目功能；2.广泛使用 于商业需求分析、系统分析与系统设计；3.强调架构设计；4.对每项工作所需要的技术、工具、做法、模板、检查项目均有详细的定义，架构完备且具有可调整的弹性。9/7/2022151.2.3.9/7/202216-n极限编程，最轻量级的开发流程，其最主要的精神是在客户有系统需求时，给予及时满意的可执行程序，所以最适合需求快速变动的项目 n强调客户所要的是 的执行码，所以把与撰写程序无关的工作降至最低，并要求客户与开发人员最好以 的方式一起工作 9/7/202217强调4个因素n交流()，要求程序员之间以及和用户之间有大量而迅速的交流n简单（），要求设计和实现简单和干净n反馈（）通过测试得到反馈，尽快提交软件并根据反馈修改n勇气（）。勇敢的面对需求和技术上的变化9/7/202218 开发流程 开发人员随时可以和客户进行有效沟通，撰写 以确认需求。简易快速的系统设计，撰写独立的验证程序以解决特殊困难的问题，找出算法即可丢弃验证程序。规划多次小型阶段的项目计划，以最快速度完成每一阶段的程序交付客户，客户负责 ；前必须完成 与 程序，所有模块整合前都须经过 ；开发人员必须快速响应 与需求变更；要求二人一组使用一台计算机设计程序，当一人 时，另一人负责思考与设计；程序必须符合程序规范，并常做程序的重构()。9/7/202219原则和实践 n n 类似，描述用户所见的系统功能，但避免使用大量的文档，由用户编写（不仅限于描述用户界面）。使用用户的语言编写，不使用技术性的语言，每个 限于几句话。用于在 会议上对开发时间进行评估，也用于产生验收测试（），必须使用可以自动进行的验收测试保证软件的正确性。与传统的用户需求的区别在于详细的程度，并不会确定需求的每个细节，它只是用来简单的描述系统功能，供开发人员进行估计开发进度，在开发过程中开发人员和用户会不断的交流以讨论细 节问题。应该专注于功能，不应该过分注重用户界面等细节。一般一个 在1-3周的时间完成，如果估计超过3周，说明 太大了，需要细分.9/7/202220原则和实践 n n召开一个 会议，产生。将用于指定每个的计划。开发人员对每个 估计开发时间（在不被打断，无其他工作情况下的开发时间，包括测试），用户对 给出优先级，会议并不制订每个的计划。要用户，开发人员和管理者都同意，在完成功能范围（），使用资源（）,时间（）和质量()上达 成一致（一般质量是不能改变的）9/7/202221原则和实践 n n 是的一个原则，每个完成一些用户有意义的功能集合，尽快的提交给用户以获得反馈，及时调整，提交的越晚，调整越困难。9/7/202222原则和实践 n n团队在开发过程中要收集数据，以便于对自己的开发速度进行评估，用于以后的 9/7/202223原则和实践n n每个 的周期称为，每个约为1-3周，在一个项目中保持每个的时间相等，不要超前制定计 划，每个的计划在的开始时制定。这样能够更灵活的应付变化。不要急于完成本次没有包括的功能。要 注重每个的时间限制，当团队觉得不能按时完成时，召开一次 会议，重新评估，减少一些。9/7/202224原则和实践 n n在每个 开始的时候召开会议，从 中选择还没有实现的用户最迫切需要的。上一个中没有通过验收测试的功能也要在这个中实现。可以根据上一个的实践调整团 队速度。和失败的测试被分解成，使用技术语言编写，作为 的详细描述。程序员主动领取并估计完成时间，每个应该在1-3天内完成，超过3天的应该被细分。如果整个团队需要的时间 多于或少于规定的时间，调整。9/7/202225原则和实践 n n不要使每个开发人员局限于一项工作，不要使某项工作依赖于一个开发人员，增加知识共享，减少信息孤岛，多进行交流和培训。当项目中的所有人对所有模块都了解并可以进行开发时是效率最高的，鼓励开发人员在不同中开发不同的模块。9/7/202226原则和实践 n n每天工作 开始之前，开5-10分钟的会议（站立会议），站立的目的是为了强迫节省时间，会议的目的是交流，提出存在的问题，但不要在会议上解决问 题。开一个所有人员参加的短会比多个个别人员参加的会议要高效。在会议上提出的问题可以由少数人讨论解决，这个少数人参加的会议如果涉及到代码，可以在计算机前讨论。9/7/202227原则和实践 n n并不是一成不变的，当团队觉得需要修改的时候，可以根据自己的情况进行修改，任何修改都要经过整个团队的讨论和达成一致 9/7/202228原则和实践1n n保持简单的设计，在完成同样的功能的情况下，选择简单的设计，不要急于设计没有计划的功能，应该认识到：a n n使用统一的术语描述系统，在用户，管理者和开发人员之间使用统一的术语。这将使交流清晰。n n使用(,)进行系统设计，鼓励更多的人参加设计。每个卡片表示系统中一个对象，写上对象的名字，责任和每个责任需要交互的其他对象。可以模拟对象之间 的交互。卡片是易于理解的，但是是非正式的，如果需要正式的文档，要将卡片转换为相应的文档。n n n 9/7/202229原则和实践2n n使用 减低风险，当遇到技术难题或设计问题时，使用简单的程序进行测试，找出问题，在不同的解决方法之间进行评估。在早期进行实验可以有效的降低风险。n n不要过早的设计没有计划的功能，在一个需求经常变化的环境中，过早的设计经常是没有用的。n n鼓励对设计和代码经常进行重构（），目的是去除冗余，提高质量，保持设计简单。重构必须以完全测试为检验条件9/7/202230原则和实践1n n用户是项目组的成员之一，用户的参加贯穿整个开发过程，用户与开发人员之间的交流是重要的 n n使用统一的编码标准，这是保持代码整洁和共享代码的基础 n n 是的一个特点，在编写代码之前先编写单元测试代码，单元测试代码和代码由同一个程序员完成。先编写测试代码可以使程序员更好的理解需求，避免直接编码造成的理解偏差，对需求的不清晰，可以在编写测试代码时就发现。测试代码也是检验程序是否完成的标准。编码工作应该是以下工作的循环：1 编写测试代码2 运行测试程序，确认失败3 编写实现这个测试程序要求功能的代码，不需要实现其他的功能，只需要实现刚刚满足测试程序的功能4 运行测试程序，确认成功实践证明，方式需要的编码实践少于先编码，后写测试代码9/7/202231原则和实践2n n 是的特色，它要求两个程序员在一台计算机上同时进行编程工作。共用鼠标和键盘，通常一个人进行战略上的思考，程序架构和函数，类之间的关系，一个人进行输入和战术上的思考，完成函数和类。两个人可以经常交换角色。n n要保证源代码库的状态是可标识的，同一时间，只允许一个的程序进行整和和测试，这样可以缩小问题产生的范围。不同的可以在自己的机器上随时进行整和和测试.n n只要有可能 就进行代码整合，周期可以在几个小时，最好不要超过一天。9/7/202232原则和实践3共同拥有代码 鼓励每个人对项目中的任何人提 出新的想法，任何开发人员对项目中的任何代码都可以进行增加功能，改正错误和重构。优化工作放在最后 先使系统能够正常工作，不要猜测系统的瓶颈，要实际测量 不要长时间的加班，大多数加班并不能挽回已有的延迟，连续超过两个星期的加班说明有问题存在。向一个已经延迟的项目填加人员也不是一个好的选择。9/7/202233原则和实践1n所有的代码都有单元测试 n单元测试是的基 石，中的单元测试应该是可以自动进行的，所以可以很快的进行所有的单元测试，单元测试应该在编码之前创建。单元测试的代码和代码一起，没有单元测试的代码不能够。使用自动单元测试可以系统整合时节省大量的发现错误和改正的时间。单元测试越完善，节省的时间越多。n代码在前必须通过所有的单元测试 n发现后，首先增加测试 n在实际运行中发现,首先增加，然后增加，在增加完测试后在查找和修改代码，增加的测试保证同样的错误不会再出现 n n 根据 在 会议上创建，它也应该可以自动运行以便可以经常运行。9/7/2022341.2.3.9/7/202235 9/7/202236特点n自我管理的团队n以“”为周期迭代的产品开发n以一系列“产品”记录了产品需求n没有特定的工程实践惯例n在以生成规则创造的敏捷开发环境交付产品n是其中一种“敏捷方法”9/7/202237 开发流程开发流程 n 开发流程是 的一种，以英式橄榄球争球队形()为名，基本假设是开发软件就像开发新产品，无法一开始就能定义 的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证项目成功。n 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，碓保每天、每个阶段都朝向目标有明确的推进，因此 非常适用于产品开发项目。9/7/202238 开发流程开发流程(.)n 开发流程通常以 30 天为一个迭代周期，每个迭代周期叫做一个，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部份，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检视每个成员的进度与计划，了解所遭遇的困难并设法排除，决定第二天的任务安排.n较为有特色的，是它特别强调开发队伍和管理层的交流协作。每天，开发队伍都会向管理层汇报进度，如果有问题，也会向管理层要求帮助解决。9/7/202239总体骨架总体骨架迭代迭代每30天Daily SCRUM每24小时高优先级可运行的软件可运行的软件工作项分解产品订单产品订单Product Backlog迭代订单迭代订单Sprint Backlog新的功能新的功能增量增量迭代规划会议迭代规划会议Sprint Plan一般不超过8小时。前4个小时：产品负责人向团队展示最高优先级的产品，团队则向他询问产品Backlog的内容、目的、含义及意图。后4小时：团队计划本Sprint的安排迭代复审会议迭代复审会议Sprint Review 一般4个小时，由团队成员向产品负责人额其他利益相关人展示Sprint周期内的产品开发情况迭代回顾会议迭代回顾会议Sprint Retrospective一般3个小时，ScrumMaster将鼓励团队在SCRUM过程框架和实践范围内，对开发过程做出修改，使它在下一个Sprint周期中更加有效和令人愉快每日站立会议每日站立会议Daily Scrum Meeting在简会上，每个成员主要回答三个问题;自上次SCRUM简会后的一天了（昨天），你做了什么?从现在到下次SCRUM简会的一天里（今天），你要做什么?在实现SCRUM及项目目标的工作中，你遇到哪些困难吗?产品负责人产品负责人Scrum主管主管开发团队开发团队9/7/202240顺序.重叠开发过程并非以一段时间集中完成一个过程.而是将所有过程中必须的每一部分集中在这段时间内完成需求设计代码测试9/7/202241 结构框架产品所有者ScrumMaster团队职能迭代计划迭代验收迭代回顾每天召开的 scrum 会议仪式产品backlog迭代 backlog进度曲线图产出9/7/202242 n自组织的团队n 跨功能团队没有角色区分n 最少2个,最多7个n 对工作交付负责n只要交付工作需求,授权做任何事情.9/7/202243角色及职责角色及职责火腿鸡蛋！三思过后我决定不和你开餐馆了。因为我全身心投入，而你只牵涉入内！9/7/202244&n:成员成员:他们承诺对迭代目他们承诺对迭代目标交付负责标交付负责n:项目组有关的成员项目组有关的成员,但并不专但并不专注于项目注于项目n以观察者的形式参加以观察者的形式参加 9/7/202245 n优先级制定开发的版本规划n必须确保驱动开发的需求只有一份n受管理层,客户等影响但仅有权调整n与相关成员协同工作来确定 的n消除关于的疑惑,确保理解一致,消除干扰9/7/202246 n 职责职责n确保的成功确保的成功n 实施实施 实践和规定实践和规定,保护团队以保护团队以免受干扰免受干扰n 项目管理的代表项目管理的代表9/7/202247n交付产品的固定的时间箱.建议2-3周n迭代包括,n一旦迭代开始,仅 能增加或者删除 中的n当迭代的目标变的没有意义的时候,才能终止迭代开发n对于,不允许迭代内的需求变更：需求优先级调整仅存在于迭代之间9/7/202248如何定义n团队自己从产品的中选择一些他们能够完成的任务作为迭代的n迭代被创建n任务被确认并且每一任务估计工作量应该在1-16小时左右n迭代的的确定是团队协作的结果，而不是只有的决定n概要设计已经讨论过为了选择好去处度过这个假期，我需要先看到酒店的照片.编写后台和中间层(8 小时)编写界面(4)编写测试用例(4)写类foo(6)更新性能测试用例(4)9/7/202249 l每天 15 分钟，团队面对面站立成圈l晨会是为项目信息同步可视化,不是为了解决问题l避免无关的讨论9/7/202250团队成员需要回答3个问题昨天你做了什么?1今天你将要做什么?2你有需要帮助的地方吗?3n对于 来说这些问答不是工作进度报告n他们是团队成员彼此的承诺9/7/202251 9/7/202252迭代结果的验收n团队需要演示所完成的迭代工作n典型的做法是使用演示形式展示新功能或者底层架构的实现n非正式的n2小时的提前准备n不需要正式演示文档n整个团队都需要参加n邀请所有关注产品的人参加9/7/202253迭代的回顾n周期性的回顾，总结工作中的经验和教训n一般 1530 分钟n在每个迭代结束时开始做n整个团队都需要参加n产品所有者n团队n可能还包括客户9/7/202254产品 n需求n项目中待完成的工作列表n理想的是每一个待完成的工作都将对客户和用户产生价值n产品所有者将对这个列表进行优先级排序n每个迭代开始前优先级的排序工作还需要再度修正一组产品 9/7/202255产品 的样例 列表估计量顾客可以酒店预定3顾客可以取消预定.5顾客可以提前更改预定的日期.3酒店工作人员可以出具()报告8提高对突发事情的处理能力8.30.509/7/202256管理迭代的 n团队的个人将要签收其将拥有的工作n工作不是单向的分配n对于剩余工作量的估计每天需要更新n团队中任何人都可以添加，删减或者更改迭代中的工作项目n为了迭代目标以及将发布的结果而工作n如果对将要面对的困难不清楚，最好先定义一个相对工作量较大的工作项目然后适时在以后将其分散成较小额工作量的几个部分n更新每个项目的剩余工作量9/7/202257迭代的样例任务编写用户界面848编写中间层1612104测试中间层81616118编写在线帮助12编写类88888增加对错误的日志记录849/7/202258迭代燃尽图9/7/202259Q&A9/7/202260演讲完毕，谢谢观看！