微信昵称：潇兮筱矣华为云账号：King0622DAY 05建立一个看板，把所有需求都放在里面，每天开15分钟的例会来确定一下优先级、就绪情况和进度每个用户故事都要解释为什么要做并给出具体的验收条件用户故事具体内容需求描述---原始的需求描述，可以是 作为。。。（谁），我想要。。。（做什么），为了…（为什么）的格式确认理解---复述对需求的理解并要求需求提出方确认理解。由于一般需求的表述都是抽象的，同一件事情不同人的理解可以有天壤之别，复述与确认可以确保大家的理解是一致的问为什么---询问需求提出者为什么需要这个需求和为什么现在就需要：在什么场景下需要这个需求，包括谁用、什么时候用和使用条件、要解决什么问题、使用频次、怎么发生等，从而甄别伪需求。有些需求其实是解决方案，需要挖掘其背后的真实用意。验收条件---可作为验收测试用例的具体例子，即实例化需求。要让抽象的需求变得具体和可测试。包括快乐路径和意外场景详细设计与实现----满足需求的具体设计以及实现集成测试验收用户验收测试---用户验收测试过程与测试结果上线备忘---用户故事的上线所需要的一些额外的步骤微服务架构就是把整个应用按照业务拆分成独立的应用1.    每个应用可独立开发、部署和扩容，甚至有独立的数据库2.    每个应用的职责单一、松耦合，和其他应用通过远程接口调用，没有代码依赖3.    基于以上原因，每个应用的开发、查错和变更速度快，它能更快地响应业务需求，提高敏捷性4.    由于采取去中心化结构，每个应用可以采取完全不同的技术栈，包括不同的开发语言在技术选型上自由度大敏捷使用的估算单位是故事点，它是一个和复杂度或规模有关的相对数

微信昵称：潇兮筱矣华为云账号：King0622DAY 04整体架构设计和解决方案要在项目层面决定，她涉及将来的交付需要分配到哪个产品小分队，具体的产品的设计、开发和系统测试则比较清晰，由产品小分队完成。建立产品小分队其中一个目的是团队自治，实现产品级别的端到端交付。所以要考虑以下几个原则：能否减少对外依赖；能否提高沟通与交付效率，减少等待与交接；能否自主决策；能否可视化需求与依赖，并根据业务价值进行需求排序。          客户是需求的提出者，当客户提出一个需求的时候他的描述可能都是当时的一些想法，IT项目是要讲客户的想法做成可落地实施的项目。不断的让客户验收让客户参与进来一方面能是需求不断的明确化另一方面能让项目与客户的真实需求相契合，所以客户的拥抱对敏捷转型很重要          简单设计、提早测试、快速反馈、持续改进是敏捷的原则          “单件流”减少批量大小，可以提高交付速度         将项目的大需求拆分成业务价值明确、能快速交付、彼此独立的需求条目

微信昵称:潇兮筱矣华为云账号：King0622具体的需求的拆分—把项目拆分成用户故事是实施敏捷的基础如何将需求文档拆分成用户故事----需要对业务的熟悉我们应该和业务部门一起去通过用户故事地图等方法重新审视整个业务模式如何能够在期限内运作起来，所需要的最小可用产品是什么？定义了MVP相当于制定了产品的第一个发布版本的范围。我们可以为其余的用户故事制定后续的发布计划。交付给客户的具有可使用价值的“最小可用产品”---MVP（minimal viable product）为何要定义MVP首先 开发一个功能所需要的时间和成本总是超出预期的其次 需求是需要验证的假设，通过MVP可以快速实验，通过最小成本验证需求假设是否成立最后 MVP是从整个业务角度来找出一个既能实现相同业务目标、IT成本又最小的方法来快速启动新业务我们应该和业务部门一起去通过用户故事地图等方法重新审视整个业务模式如何能够在期限内运作起来，所需要的最小可用产品是什么？定义了MVP相当于制定了产品的第一个发布版本的范围。我们可以为其余的用户故事制定后续的发布计划。软件开发唯一不变的就是需求会不断变化，软件开发要拥抱变化极限编程的12个具体实践计划游戏、小型发布、现场客户、测试驱动开发、持续集成、重构、代码集体所有权、简单设计、结对编程、每周只工作40小时、系统隐喻、编码规范。极限编程的5个核心价值：沟通、简单、反馈、勇气、谦逊。与传统的重文档、重过程的方法不同，它更强调面对面沟通、简化设计与实践、面对当下以及避免重复和浪费软件领域中的看板方法包含3个原则：进度可视化、限制在制品、观察和改善流动在方法的选择上，有专属团队的纯开发项目，需要稳定的交付节奏的项目，适合用scrum；需要跨项目、跨团队合作的，一人分饰多角的，维护类型的项目，适合用看板简化与业务部门的关系、拆分需求和缩短反馈环

微信昵称：潇兮筱矣华为云账号：King0622DAY 02工欲善其事必先利其器在IT行业创新、学习和引进新技术以及提升交付效率对公司适应市场新变化很重要，特别是面对现在迅猛发展的互联网信息化时代。主要的工具有：JIRA----项目与事物跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域Confluence----用于企业知识管理与协同，以及构建企业wikiJira与confluence是敏捷开发的利器，他们彻底贯彻了敏捷开发所倡导的去中心化、协作、集体讨论、信息共享、灵活、透明、可视化等原则GitHub----基于Git工具的在线代码托管平台，分布式的代码管理工具，突破了传统的集中式代码管理模式，程序员可以通过GIT在本地管理自己的分支，在成熟的时机把分支推到GitHub中，管理员可以通过保护主干分支，强制所有合并到主干的请求必须通过评审才能完成，从而强化代码评审的过程此外还有：nexus、Jenkins、sonarqube、ansible等推动devops的行动方案主题介绍：提出开放式的问题---用A4纸写下---用彩笔框起来---贴在左上处头脑风暴：个人头脑风暴：1纸1想法；字数6-12字；每人4-6张纸----小组头脑风暴：提炼5条；用彩笔写A5纸，纸张横写排列组合：宣读、罗列---第5张配对---不能有孤儿---自行分类---控制在4—7列提炼中心词：从最长列开始---不能超过6个字---记录在最上方的卡片----标明各列序号模型图：思考关系结构----摆放关键词---解读图形---可自行设计

微信昵称：潇兮筱矣华为云账号：King0622DAY 01启示一：敏捷开发更受基层工程师的欢迎，因为它倡导信任、自治以及通过技术手段如自动化测试来取代文档。管理层通常更喜欢管控与流程。所以通常认为敏捷是自下而上的。但是管理层作为一个项目的主要责任人，又有分配资源---包括项目预算、人员安排、任务优先级把控、关键节点监督的重要环节，如果管理层同样认可敏捷，与基层工程师之间达成信任和共识对于整个项目甚至公司的交付效率都是巨大的推动       所以：管理层自上而下的推动力对敏捷转型至关重要二、传统的瀑布模式对业务部门和技术部门都带来了很多消极方面    对于业务部门：1.逾期交付；2、超支；3、看到成品时项目已接近尾声；4、缺乏透明度，不知道具体进度；5、很难变更需求；6、最终发现开发出来的产品不是他们想要的；7、贻误战机，丢失市场机会    对技术部门：1、过度承诺；2、难以一次性消化所有需求；3、惧怕需求变更；4、不断重做；5、后期压力巨大；6、加班加班加班三、敏捷开发的一些核心价值观    对于核心的价值观是需要基层技术人员与管理层在实施敏捷前就达成共识的，最好能上升到公司战略层     个体和交互胜于过程和工具；可工作的软件胜于面面俱到的文档；与客户的协作胜于基于合同的谈判；响应变化胜于遵循计划    敏捷所有的变化，就是为了一件事情—快速反馈    只有及时的反馈才能及时止损 才能不断的修正现有项目与客户需求之间的差距

华为云账号：King0622微信昵称：潇兮筱矣

Day03+King0622+潇兮筱矣

Day02+King0622+潇兮筱矣

day02+King0622+潇兮筱矣

Day01+King0622+潇兮筱矣