敏捷开发

架构杂谈《十》 常用开发模式 一、瀑布式开发 　　瀑布式开发是在1970年提出的软件开发模型，是一种较老的计算机软件开发模式，也是典型的预见性的开发模式，在瀑布式开发中，开发严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤进行，步骤的成果作为衡量进度的方法。瀑布式开发最早强调系统开发应有完整的周期，且必须完成完整地经历每个周期内的每个阶段，并系统化地考量分析所设计的技术、时间与资源等。 　　瀑布式开发的主要问题是它严格分级导致自由度降低，在需求不明确并且在项目进行过程中可能有变化的情况下基本上是不可行的。 （瀑布式开发模式图） 二、迭代式开发 　　迭代式开发也称迭代增量式开发，是一种与瀑布式开发相反的软件开发过程，它弥补了瀑布式开发方式的一些弱点，有更高的成功率。在迭代式开发中，整个开发工作被组织成一系列短小的、固定长度的小项目，每次迭代都包括需求分析、设计、实现与测试。采用迭代式开发时，工作可以在需求被确定之前启动，并在一次迭代中完成系统的一部分功能或业务，再通过客户的反馈来细化需求，并开始新一轮的迭代。 （迭代式开发模式图） 　　迭代式开发有以下的特点： 　　　　1）每次只设计和实现产品的一部分 　　　　2）一步一步地完成 　　　　3）每次设计和实现一个阶段，这叫作迭代 三、螺旋式开发 　　螺旋式开发兼顾了快速原型的迭代特征及瀑布模型的系统化和严格监控

敏捷开发流程详解 1 敏捷开发流程 ü 敏捷软件开发核心是迭代式开发，增量交付。 ü 每一次迭代都建立在稳定的质量基础上，并作为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈。 ü 迭代型的方法就是将整个软件生命周期分成多个小的迭代，每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。 ü 迭代建议采用固定的周期（1-4）周，可以每个迭代周期不一定要相同，但迭代内工作不能完成，应该缩减交付范围而不是延长周期。 1.1 敏捷流程详解图-敏捷流程图 1.2 敏捷流程三种角色及其职责 角色名称 角色定义 角色职责 注意事项 Product Owner （ PO ） - 产品负责人 确保Team做正确的事 l 代表利益相关人（如用户、市场、管理等），对产品投资回报负责 l 确定产品发布计划 l 定义产品需求，根据市场价值确定功能优先级 l 验收迭代结果，并根据验收结果和需求变化更新需求清单和优先级 l 除了客户需求之外，内部任务如重构、持续集成环境搭建等也由PO纳入统一管理 Scrum Master （ SM ） - Scrum 教练 确保Team正确的做事 l 辅导团队正确应用敏捷实践 l 引导团队建立并遵守规则 l 保护团队不受打扰 l

原文地址： https://www.atlassian.com/agile/scrum/roles 翻译君：CODING 敏杰小王子 Scrum 当中有三个角色：PO（product owner），敏捷教练（scrum master）和开发团队。虽然这看起来很清晰，但如何处理现有职位的问题可能会让人感到困惑。许多团队询问在采用 scrum 时是否需要更改岗位名称？最简洁的答案是“不”。在本文中，我们将讨论 scrum 的角色定义以及如何将它们融进你的组织中，而你无需打印新的岗位名片。 Scrum 角色 VS 岗位职称 这三个 scrum 角色描述了 scrum 团队成员的主要责任，他们并不是岗位职称。这意味着任何职称，即使是现有职位，也可以承担其中一个角色。因为 scrum 的本质是经验主义、自我组织和持续改进，所以这三个角色给出了责任的最小定义，以允许团队有效地工作。这使得团队可以对他们的自我组织和持续改进负责。 参考阅读： https://scrumguides.org/scrum-guide.html 建立一个 Scrum 团队 Scrum 是一个团队构建运作流程的框架。它提供了定期会议和谁做什么的基本结构。 它不为团队提供一个适合所有人的模型。例如，如果团队正在开发 Web 保险应用程序，他们需要了解技术、后端系统和业务领域的人员。另一方面，如果团队正在研究下一代大金刚

为什么出现极限编程 ？ 敏捷方法论有一个共同的特点， 那就是都将矛头指向了“文档” ，它们认为传统的软件工程方法文档量太“重”了，称为“重量级”方法，而相应的敏捷方法则是“轻量级”方法。正是因为“轻量级”感觉没有什么力量，不但不能够有效体现灵活性，反而显得是不解决问题的方法论似的。因此，就有了一次划时代的会议，创建了敏捷联盟。 在敏捷方法论领域中，比较知名的、有影响力的，是拥有与 Microsoft 的操作系统相同缩写语——XP的极限编程（eXtreme Programming）。极限编程方法论可以说是敏捷联盟中最鲜艳的一面旗帜，也是被研究、尝试、应用、赞扬、批判最多的一种方法论，也是相对来说最成熟的一种。 这一被誉为“黑客文化”的方法论的雏形最初形成于1996—1999年间，Kent Beck、Ward Cunninggham、Ron Jeffrey 在开发 C3 项目（Chrysler Comprehensive Compensation）的实践中总结出了 XP 的基本元素。在此之后，Kent Beck 和他的一些好朋友们一起在实践中完善提高，终于形成了极限编程方法论。 什么是解析极限编程 ? 那么什么是 极限编程呢？ 这里我们把极限编程简称为 XP XP 是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式 。与其他方法论相比，其最大的不同在于：

2019年08月09日，上海受台风利奇马的影响，晚间狂风大雨。 临下班，合作渠道WB在微信群里报告线上生产事故问题：赶快扒日志看记录，日志显示一切正常，看不出bug在哪里，WB声称并未接收到我方CI的回调请求。晚七点多，肚子已经饿了，给WB说，看日志CI没啥问题，先撤了。 在出公司大楼经过一个拐角的时候，隐隐感觉这情形代码里的配置项会不会有问题，心里很是忐忑，冒雨又折回。重新打开电脑，再捋一遍代码的时候，bug像一道匕首直刺心头：卧槽，这个路径竟然还是测试环境 的路径！项目组是公司敏捷开发团队，每周五都会有生产版本发布，赶快给负责版本控制的同事打招呼，等一下，搭个顺风车。 在确定了配置路径有问题之后：亟待明确的是服务间调用是走内网还是走外网，要不要NG转发，走不走esb，是不是要申请通信权限。简单描述一下WB的该次请求：WB请求CI的NG--------》NG转发到CI的Mule服务----------》Mule服务调用Gateway----------》Gateway转发至应用微服务Application ---------》Application服务响应之后执行异步回调Mule服务---------》Mule服务请求WB接口地址 。中间涉及的防火墙和权限就暂且忽略，目前的问题点是：Application服务响应之后执行异步回调Mule服务，这个Mule服务内部接口地址规范是什么

敏捷开发 禅道 git devops 来源： https://www.cnblogs.com/cuiqq/p/11328844.html

概述 本场景描述的是针对10以下小型产品研发团队或小型项目的敏捷应用场景。Leangoo单团队敏捷开发项目模板是基于Scrum模型定义的，所以这里所说的单团队是指只有一个Scrum团队的场景。 Scrum是用于开发和维护复杂产品的一个框架。上世纪90年代，Scrum在全球已得到广泛应用,Scrum最初用于产品研发，目前已广泛用于软硬件开发、互联网、人工智能、学校、政府、市场、管理组织运营等诸多领域。随着技术、市场和环境的复杂度和不确定性持续增长，Scrum在处理复杂性方面的效用日益得到证实。下图是Scrum的框架和流程： ​ 在Leangoo中建立敏捷项目 对小型团队来说，在 Leangoo 中建立一个敏捷项目就可以很好的支持团队的产品或项目研发。如果下图所示： ​ 项目示例： ​ Leangoo的敏捷项目模板会默认创建“产品Backlog”看板，缺陷看板和第一个迭代的迭代看板（在Scrum中，迭代叫做Sprint），您可以根据需要创建后续迭代的看板。您也可以根据产品和项目的特征，判断是否需要通过使用Leangoo脑图工具创建产品路线图规划。 产品路线图规划和需求管理 产品路线图是重要的产品管理工具。产品路线图是一个高层次的战略计划，它描述了产品在未来一段时间可能会如何发展和壮大。产品路线图确保整个产品团队持续关注产品的目标，帮助产品负责人把握产品的战略方向

传说中在2001年2月的某一天，17位搞软件开发的老大哥们在一个叫Snowbird的有雪有鸟的胜地开会，自然，他们只能讨论软件，大概是觉得整天写文档太烦了，他们憧憬未来的轻量级开发方法，工程师都是实干型的，他们立即起草了《 敏捷宣言 》来表达他们的想法，宣布他们对以前开发方法的不满，并组建了 敏捷联盟 ，从此一发不可收拾。他们提出的 Twelve Principles of Agile Software 引发了后来对于软件开发的很多争论与思考。 以下是对他们提出的12条敏捷开发准则的最后3条的理解： Principle 10: Simplicity--the art of maximizing the amount of work not done--is essential. 翻译 ：精简——将不需完成的工作量最大化的技能——是不可或缺的 初看这句话觉得很诡异，具体翻译来说是“精简性——最大化未完成的工作量的艺术——是根本的。”除去中间的插入语，剩下的部分就是很直接的“Simplicity is essential.”。细想之下，发现这个原则在软件开发中却是很有道理。于是乎，我想到了一个关于效率efficiency的基础原则：KISS Principle—Keep it Simple, Stupid.这是一个很关键的概念，但是很多人都总是忽略遗忘它。不要给自己添加额外的工作

在软件开发时，经常面对的第一个项目实现决策是“我们应该使用哪种开发方法?”这是一个引起很多讨论(和激烈辩论)的话题。如果您以前没有使用过这种方法，那么适当了解开发方法和理论是必要的;简单地说，这是一种组织软件开发工作的方法。这与项目管理的风格或特定的技术方法无关，尽管您经常会听到这些术语混在一起或互换使用。最流行的两种基本方法是:瀑布开发和敏捷开发。这两种方法都是可用的、成熟的方法。 现在，说起敏捷开发（Agile Model）和瀑布开发（Waterfall Model）模式，很多人认为敏捷开发是未来的项目实施的趋势，瀑布实施太老土已经过时了。另外确实一些跨国企业如索尼，联想也在使用敏捷的方式实施一些项目。但实际上我们看到绝大多数公司还是依然在采用瀑布的方式实施项目。本文主要简单介绍敏捷和瀑布的区别和优劣。 敏捷开发和瀑布开发 1、瀑布模型 瀑布模型是一种项目分解为有限的阶段来开发软件的方法。只有在审查并验证其前一阶段时，开发才会应进入下一阶段。在瀑布模型中，阶段不重叠。在这种方法中，事件的顺序是这样的: 收集和记录需求 设计 代码和单元测试 执行系统测试 执行用户验收测试(UAT) 解决任何问题 交付成品 对于瀑布的开发模型来看，似乎依然具备很可靠的工作逻辑，一个工程或项目分为多个阶段，每一个阶段都投入相应的资源，来完成本阶段的工作。每一个阶段到下一个阶段，都有明确的输入输出产物

一、各个成员在 Alpha 阶段认领的任务 姓名 Alpha 阶段认领的任务 林剑峰 用户信息页面：完成用户信息的上传 石竞贤 发布信息页面：完成用户图片上传云存储的功能，并且把发布信息上传到云数据库 饶元兴 设计app首页页面、设计app个人信息页面、 陆君健 模块测试以及进度报告的编写 周惠龙 设计发布信息的页面、首页发布信息按钮实现跳转到发布信息页面 梁景涛 首页失物招领信息列表的实现 二、明日各个成员的任务安排 姓名 明日任务安排 林剑峰 学习小程序的编写、编写博客园 石竞贤 进行实名认证，环境搭建，完成微信小程序的开发前的工作，学习小程序的编写 饶元兴 学习小程序的编写 陆君健 学习小程序的编写 周惠龙 学习小程序的编写 梁景涛 学习小程序的编写 三、整个项目预期的任务量 （使用整数表示，与项目预估的总工作小时数一致。比如项目 A预估需120小时才能完成，则任务量为120。) 姓名 Alpha 阶段认领的任务 任务量 林剑峰 用户信息页面：完成用户信息的上传 15 石竞贤 发布信息页面：完成用户图片上传云存储的功能，并且把发布信息上传到云数据库 24 饶元兴 设计app首页页面、设计app个人信息页面、 20 陆君健 首页发布信息按钮实现跳转到发布信息页面 14 周惠龙 设计发布信息的页面 12 梁景涛 首页失物招领信息列表的实现 14 总任务量 99 四