检测到您已登录华为云国际站账号，为了您更好的体验，建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
检测到您已登录华为云国际站账号，为了您更好的体验，建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
好的用户故事讨论的是为谁做和为什么做，而不仅仅是做什么。作为Who，我想要What，以便于Why。有了Who、Why、What的信息，How就变得呼之欲出了。以往我们上来就写需求的，往往注意到的是What（干什么），却忽略了Who（为谁做）以及Why（为什么做）。而Who>Why>
讨论工程方法和企业能力。但是现在，在交付方式逐步从单体软件向云上迁移的过程中，大家开始意识到继续在自己的研发环境做基于本地化的私有化工具链已经落伍。于是提出新的要求，做新的全云化的DevOps工具链，本文将讲述对此理念进行的实施。 本文主要分为以下五个部分： 首先要检查自己的DevOps状况。
设，投入了DevOps建设。这个决定是当时做的很正确的一个决定，尽管那段时间非常痛苦，因为团队既要交付特性，压力很大，加班很多，同时还要做工程能力的建设。CodeArts先从一个团队做试点开始，有效果之后再铺开，不久之后所有团队都开始做DevOps。 华为DevOps一体化平台框架
持续规划与设计 什么是敏捷 影响地图 用户故事地图 用户故事驱动的敏捷开发 我在CodeArts做需求 Scrum的22个基础知识点 Scrum实践之团队 Scrum实践之冲刺 敏捷项目管理 敏捷实践之物理看板与电子看板
是把问题敲碎，放在每一个迭代当中。 回到开始，我们想一下之前要做的性能优化的事情，简单来说可以分为两个部分。第一个部分是固化的部分，包括CDN的建设、所有Web上的容器设置。CodeArts使用的是前端的Angular框架，关于Angular框架本身的演进与优化，再到基于业务实践
《科技想要什么》一书中，将科技比作生物。生物是在不断进化，伴随着科技生物的进化，科技生物的研发方法也在不断的进化。华为公司在过去三十年，从小型做硬件、做CT通信产品的公司，成为跨ICT公司，研发理念和思想上也在不断变化。经历了初步的CMM持续交付、持续集成到敏捷、DevOps，直到最新的
最终，持续交付归结为一句话，痛苦的事情反复做。 下图所示的持续交付的原则中，红体字描述的，是最与技术无关的一个实践，却也是最重要的核心理念：提前并频繁的做让人感到痛苦的事。 小结 在开始行动之前，首先应思考需要解决的是什么问题，而不是去问应该采纳何种方式。 不应去问持续集成应该怎么做，TDD应该怎么做。那些都是
不说是一个令人感到意外的结果。 当我们认真研究当前中国企业的DevOps现状时，就会明白这个结果也在情理之中。虽然国内应用DevOps的众多，DevOps已经在国内逐步落地实践，但大部分企业仍然位于DevOps能力成熟度初始级和基础级，其比例高达7成。 在DevOps的细分领域，
活动自动化。 在项目部署过程中，经常遇到由于环境不一致而导致的失败，例如研发调试环境的JDK升级后，未在环境清单中标记清楚，导致生产环境未做相应升级而引发失败。为了避免因为环境不一致导致的各种问题，本样例项目中将各微服务应用与环境统一打包到镜像，保持环境（开发调测环境、测试环境、QA环境、生产环境）一致。
的做到。每一丝的赘肉都会影响身体执行的速度，所以需要锻炼来消除。如何消除持续交付过程中的赘肉？和肌肉锻炼燃烧脂肪一样，痛苦的事情需要反复做，做十次一百次上千次，反复打磨，持续优化。 工程过程是需要高效、准确并且高度保持幂等性的。也就是说，执行一次的结果，与执行一百次的结果应该是一
Development Method，动态系统开发方法） Exploratory Testing（探索性测试） 《2019年中国DevOps现状报告》中，针对国内各种敏捷开发方法的调研结果显示：在所有敏捷方法中，Scrum、看板方法、自定义混合模式是最受企业欢迎的前三种敏捷开发方法，占比分别为45.41%、41
物理看板的优势和劣势 优势 成本低：几乎不需要成本，办公室允许粘贴的玻璃墙、白墙或者白板均可，再准备点便签和笔。 入门快：只要团队想好了怎么做，立刻可以做到工作的可视化，特别适合刚刚使用看板的入门级团队。 更改方便：对于看板的规划，只要有新的想法就可以灵活的变动和快速的实现。比如，
在“消息设置”页面中找到“邮件通知”，勾选“开启”。可以单击“更改设置”，修改邮箱地址。 定制项目工作流程 在迭代Review会议中，团队将向产品负责人做产品演示，并出示测试报告，由产品负责人确认Story是否完成。而当前的Story状态中没有能够显示测试已完成的状态，因此测试人员建议增加一个状态“验收中”。
也有问题，测试环境部署时间比较长，测试人员在α、β生产各个节点上面做部署，然后做验证，使得部署耗费了很多时间。 下面让我们再看看测试，测试最重要的是要做什么。这里有两个关键的焦点： 第一点，测试就是一个质量活动，做测试就是要保证质量。 第二点，业务价值。测试要围绕业务价值去做，而
践的全景图。 在Scrum框架中，工作在建议时间长度的迭代中循环做，这个迭代叫做冲刺。 各个冲刺提交的工作内容必须是对用户和客户来说具有确定价值的交付物。通常来说，在每一个冲刺中，不可以对交付内容的人员和范围等目标做改变。各个冲刺要达到Scrum团队共同认同的完成定义，并且交付一个潜在的可以发布的产品增量。
线以及各种周边配合，涉及的团队非常复杂。基于时代背景来看，核心网络产品要交付出来，在以前经常需要一年多以上，基本是一年一个版本，半年的时间做线上验证，包括到客户的机房验证，那个时候升级都需要选访问量最低的时候进行半夜断网升级。 怎么保证迭代的速度加快，迭代的质量逐步变得更好呢？后
任感。 大量数据表示一个普遍的共识：做多个项目或者跨多个团队会降低生产力，因此建议团队成员尽可能专注于一两个产品。当然专注于一个产品开发工作时，更容易做到专注、有责任感。 持续的工作节奏 开发团队必须以可持续的节奏工作，不再进行死亡行军，这样做可以维持一个健康、有趣的环境。 采用
任务。 本章节以任务“phoenix-codecheck-worker”为例进行讲解。 配置并执行任务 开发人员可以对样例项目中预置的任务做一些简单的配置，增加Python语言检查规则集，使检查更全面。 编辑任务。 进入“凤凰商城”项目，单击导航“代码 > 代码检查”，页面中显示样例项目内置的4个任务。
时间段内需求交付和缺陷修复的进度、资源分配和风险。 而且项目经理经常遇到的问题是项目成员的工作饱和度不能直观的展现，特别是当成员跨项目时，做两个以上项目的任务，更增加了识别难度。 项目经理驾驶舱能够帮助项目经理对项目交付进行全链路跟踪，跟进项目进度以及识别交付风险。同时项目经理驾
好的用户故事讨论的是为谁做和为什么做，而不仅仅是做什么。作为Who，我想要What，以便于Why。有了Who、Why、What的信息，How就变得呼之欲出了。 以往我们上来就写需求的，往往注意到的是What（干什么），却忽略了Who（为谁做）以及Why（为什么做）。 而Who>Why
长按/截图保存，微信识别二维码
或者关注公众号“华为云”
