敏捷

点击链接理解详情 作者介绍 前言随着越来越多行业的企业开始关注麻利，业务麻利（Business Agility）成为一个新的热点。毕竟大部分的行业和组织与软件无关，然而仍然要实现业务上的麻利，所以这个系列会次要谈两点： 第一个是：“什么（What）是业务麻利？”第二个是：“如何（How）从业务架构角度切入业务麻利？”第二局部介绍从业务架构中最根底的局部 —— 价值流（value）与能力（capability），切入业务麻利。这部分会联合一个案例 Air France KLM Cargo Procurement 来阐明。 什么是业务麻利 依据业界的支流观点，再联合本身的教训，我认为业务麻利比拟全面的定义如下： “业务麻利是一种组织级的办法，它能帮忙业务疾速响应市场内外部的变动。这样的组织宽泛地利用了麻利的准则，使得整个公司可能更快地响应变动，放慢上市工夫，同时在不就义品质的状况下升高不必要老本。” 所以，要掂量一个组织是否达到业务麻利，有几个关键点 —— 1. 响应力（Responsiveness To Change）和上市工夫（Time To Market） 这个词是掂量一个组织是否是业务麻利的要害。首先，响应力意味着外部外的任何变动，组织都能感知到，都能做出必要的调整，这里的调整可能产生在组织内的各方面，不仅仅是业务或数字部门，也可能是HR，财务，供应链，甚至是供应商。其次，业务麻利的成绩肯定会体现在产品或服务上市工夫的缩短。也就是说，如果组织外部的变动如果仅仅是降低成本，那么也不能称这个组织达成了业务麻利。 2. 降低成本同时不就义品质 咱们都晓得要加强响应能力或缩短上市工夫，传统地做法是加大资源投入。比方VIP客户能够设置专人服务，能够增设专门的服务通道，这样能够能够疾速响应VIP客户的需要；又比方对于研发减少人手，对生产减少资源都能够肯定水平的晋升响应力和缩短上市工夫。但这些并不是咱们这里探讨的业务麻利范畴。 另一个放慢Time To Market的办法是升高肯定的品质，这种状况在软件与互联网行业尤其显著，第一个上市的产品为了抢工夫，通常bug一直。背地的起因可能是需要剖析工夫有余，开发工夫有余，测试工夫有余等等。但通过升高品质与进步老本（绝对行业均匀）都不是咱们所说的业务麻利组织。 3. 广泛应用麻利的准则 那么如何做呢？这里是所谓业务麻利的根本准则，也就是组织内宽泛地利用麻利的12条准则（见下）。我把麻利的12条准则做了稍许表述上的调整，以适应业务麻利的场景，用“我的项目”和“产品”代替了“软件”。同时裁减了这里“设计”和“架构”的含意，不单指软件架构设计，能够是“产品设计”，“我的项目设计”，“产品架构”，“我的项目架构”等等。 在过往我的项目的落地过程中，咱们发现这些准则齐全能够实用各类组织，并且毫无违和。 当然要做到业务麻利的成果，这绝不是一件容易的事件。麦肯锡曾做过一个钻研，发现速度（speed）和稳定性（stability）在大部分的互相矛盾的。很多的组织如果一旦晋升速度当前，它的stability就会降落，它的稳定性就不行了。既能做到又快又好又稳固的只有12%的组织，即所谓的麻利组织。 如何实现业务麻利所以业务麻利其实没有那么容易做，甚至是一个组织各因素互相掣肘的过程，是个矛盾体，那咱们要怎么做？ 在答复这个问题前，给大家一个思考题，业务（Business）到底是个机器（machine）还是一个有机体（organism）？ 已经我看到过相似的问题是“组织是一部机器还是一个生命体？” 这两个相似的问题引发的思考是相似的。该问题背地实际上还有一个延长问题，即“业务到底是怎么产生的？是严格地依照设计制作进去的，还是成长进去的？” 不同的答案会决定你所在组织的麻利转型策略（strategy）、设计（desgin）和路线图（roadmap），这就是所谓的“顶层设计”。 咱们回顾很多大组织的倒退，例如苹果公司，从两个人的守业公司，到遍布寰球的各种业务。在几十年的工夫里，苹果公司至多公布了大大小小数十个系列的产品（见下图）。 同时你会发现，苹果公司随同新产品新业务，都在调整组织，以合乎它的业务需要，促成它的业务倒退。而这些调整通常都产生在新产品新业务推向市场前（下表是苹果公司若干次重大变动）。 1984年Macintosh公布，1985年史蒂夫·乔布斯来到，产品与业务调整； 1997年收买NeXT，史蒂夫·乔布斯回归，大量产品被暂停，研发与公布iMac； 2000年产品策略调整，勾销局部产品，聚焦倒退ipod和Mac电脑。2001年推出iPod取得重大胜利； 2007年公布iphone，公司名称从苹果电脑公司改为苹果公司，策略调整； 2011年史蒂夫·乔布斯离世，蒂姆·库克继任，组织进行从新调整； 2018年收买芯片公司，2021年开始包含Mac全面采纳自研芯片。 ....... 所以说，组织要倒退某种业务，须要从上到下产生或大或小的重组，这些调整包含组织架构、资源、流程等等）。就好比任何一栋修建，它都根本的架构，组织为了撑持某种业务，也须要某个架构撑持，也就是业务架构撑持。 从业务架构视角看业务1.什么是业务架构 业务架构被定义为“企业的蓝图，提供对组织的独特了解，并用于协调战略目标和战术需要” —— 摘自《BIZBOK® Guide v11》 业务架构蕴含了从客户/用户，产品，策略，度量，政策等等，而要反对所有这些的根底局部离不开4个方面（见下图）包含“能力 Capability、信息 Information、价值流 Value Stream、组织 Orginization”。换句话说如果要进行麻利转型，也离不开它们，咱们明天重点谈2点，能力capability和价值流value stream。 ...

1 什么是麻利？麻利开发是一种思维或方法论，就是通过一直迭代开发和增量公布，最终交付合乎用户价值的产品 麻利思维源于最后的《麻利宣言》： 【麻利软件开发宣言】 个体和互动高于流程和工具；工作的软件高于详尽的文档；客户单干高于合同会谈；响应变动高于遵循打算；《麻利宣言》代表麻利的价值观，麻利开发准则则帮忙咱们通过更灵便的形式思考开发方法和组织；具体十二条麻利开发准则： 咱们最重要的指标是通过继续一直地疾速交付有价值的软件使客户称心；怅然面对需要变动，即便在 开发前期也一样。为了客户的竞争劣势，麻利过程掌控变动。常常地交付可工作的软件，相隔几星期或一两个月，偏向于采取较短的周期。业务人员和开发人员必须相互合作，我的项目中的每一天都不例外。激发个体的斗志，以他们为外围搭建我的项目。提供所需的环境和声援，辅以信赖，从而达成指标。不管团队内外，传递信息成果最好、效率最高的形式是面对面交谈。可工作的软件是进度的首要度量规范。麻利过程提倡可继续开发。责任人、开发人员和用户要可能独特维持其不掉稳固、连续。坚定不移地谋求技术卓越和良好设计，麻利能力由此加强。以简洁为本，它是激励缩小不表要工作量的艺术。最好的架构、需要和设计出自自组织团队。团队定期地反思如何进步功效，并依此调整本身的举止体现。麻利开发模式 []() 2 什么是麻利测试？‘麻利测试’既不是一种测试方法，又不是一种测试形式，而是为了适应麻利开发而特地设计的一套残缺的软件测试解决方案。这个解决方案应该可能反对继续交付，涵盖所需的、正确的价值观、思维形式、测试流程，一系列优良的测试实际和更适宜的测试环境，以及自动化测试框架和工具。 麻利测试能够采纳目前已有的各种测试形式，与传统测试相比，侧重点有所不同，次要的差异是价值观、思维形式、流程和实际等。 麻利测试包含（但不限于）的测试流动：在工作中用具体的实例领导开发人员做测试，评审测试想法和假如，开发测试自动化，执行探索性测试，执行验证品质属性的测试，如性能、可靠性、安全性等。 2.1 传统测试和麻利测试的差异[]() 3 麻利思维形式包含 成长性思维、团队对品质负责的思维 高低为驱动的思维与用户思维 3.1 成长性思维成长性思维其主旨是“请置信，你能够提高”，领有成长性思维的人置信人的能力是能够被造就的，总是致力并一直成长；能够承受失败，但不会成为失败者，充斥自信，心田有力量，认为明天的失败不代表今天会失败，置信本人的后劲是未知的，肯定能克服困难，于是越战越勇，最终走向胜利； 领有成长性思维的测试工程师和领有固定性思维的测试工程师的比照 []() 3.2 对团队品质负责的思维麻利中，咱们强调的是共担 测试人员守护品质，提供品质信息，甚至帮忙团队改良品质，天然很有价值，然而如果依赖测试来保证质量，那么其实是很难保证质量的，而且老本很高。应该让整个团队关注品质，从需要开始尽可能一次把事件做对，从而构建出高质量的产品，这对企业来讲更有价值效率更高老本更低。 3.3 上下文驱动的思维在麻利测试中要意识到上下文是始终在变的，测试策略和办法也要依据上下文几时调整，一直优化，尽可能达到更无效、更高效的测试状态；上下文能够简略地了解为我的项目所处的环境，包含人员、危险变动、研发状态和质量标准等。 3.4 用户思维从用户视角登程，从用户故事角度思考的思维形式； 4 scrum 模式下的 测试流程[]() Scrum模式下的麻利测试六层有7项流动：测试的剖析与定义、测试计划、测试设计、BVT、继续测试、版本验收测试以及测试交付与反思，然而不能了解位7个阶段，许多互动都是并行的，包含打算、设计都是贯通整个迭代的。 测试剖析与定义，对用户故事进行需要评审，为每一个用户故事建设验收规范，确保它具备可测试性，并从业务需要触发，理解要做哪些测试，初步界定测试范畴测试计划，这里指以后迭代的测试计划，包含进一步明确具体的业务要求和质量标准，制订测试指标，明确测试范畴和测试项，合成测试字母表辨认出测试危险并制订测试策略等。打算是一个笼罩整个迭代的过程，也就是后面所说的，要基于上下文一直调整或优化测试计划，只是在迭代打算时先写出初步的测试计划，依照打算开始执行后续的测试过程。测试设计，这里强调的是粗粒度的测试设计，包含事件流图、状态图等BVT（build verification testing）版本构建测试，每日构建或代码提交触发的软件版本构建，须要对软件版本进行主动验证，只有高成功率的继续集成才有意义。岂但包含传统的冒烟测试，也包含代码扫描，查看代码规范性，安全性等 动态代码剖析。继续测试是在迭代中的次要流动，包含设计评审、单元测试、用户故事实现的验证和集成测试等，也蕴含继续的新功能测试和继续的回归测试，以及性能测试、平安测试、兼容性测试等专项测试版本验收测试。麻利的验收测试通常是指对用户故事的验收规范验证。测试交付与反思。测试交付还包含品质剖析，并要回顾、扫视整个测试过程，找到测试不加的中央，从而在下一个迭代版本中改良。5 麻利模式下如何发展测试？5.1 构建弱小的麻利测试根底设计继续集成和继续测试 继续集成（continuous integration，CI），在1998年就被列入极限编程的外围工夫。2006年 马丁 福勒提出了比较完善的办法和实际： 继续集成是一种软件开发实际，即团队开发成员常常集成他们的工作，通常每个成员每天至多集成一次，这也就意味着每天可能会产生屡次集成，每次集成都通过自动化的构建（测试）来验证，从而尽快发现集成谬误。 继续交付（continuous delivery CD ），继续交付是一种能力，可能以可继续形式，平安、疾速底把代码编程（包含个性、配置、缺点和试验）部署到生产环境上，让用户应用。 在继续集成中的测试流动 通过与自动化测试工具/框架的集成，在继续集成环境中执行自动化测试，然而这里须要思考继续集成中测试范畴和提供疾速反馈之间的均衡，个别继续集成自动化测试流动应该只蕴含 单元测试、代码动态测试和BVT（基本功能验证） []() 测试左移：代码评审，有助于提前发现缺点，进步代码规范性进而促成研发团队常识共享。 5.2 麻利测试的设计和执行1）创立DOD 用户故事DOD维度 迭代DOD 维度 公布版本DOD维度 DoD(definition of done) 工作实现的定义。在迭代初为一个迭代建设DOD，并且在迭代实现时查看实现状况。 所有代码通过动态检测，重大问题都已批改；所有新增代码失去人工评审；所有实现的用户故事都有对应的测试用例；测试用例都已执行；所有实现的用户故事失去Product Owner的验证。……2）将用户故事转化成测试场景 3）摸索式测试和角色扮演的场景开掘 4）自动化测试、UI自动化测试 5.3 测试右移把软件测试从研发阶段延长到运维阶段，从研发阶段的继续测试延长到部署上线后的在线监控和在线测试。 ...

前言极限编程（XP）的创始人之一Ron Jeffries说道：“在麻利中，让设计简单化，必须让设计从简略开始，而后变得成熟。要做到这一点，重构是惟一的前途。”什么是重构重构是指扭转代码的构造，而不是代码的行为。举个例子：假如一个程序中有两个办法，每个办法都蕴含几行雷同的代码，那么这几行雷同的代码能够从原来的两个办法中抽取进去，放到一个新的办法中，在原来搁置这几行代码的中央替换为调用这个新的办法。这个重构略微改善了程序的可读性和可维护性，因为当初一些代码显著被复用，并且反复的代码被移到了一个中央。代码构造产生了扭转，然而行为并没有变。重构不仅对TDD（测试驱动开发）的胜利至关重要，同时也有助于避免代码腐烂。代码腐烂是由反复的代码、有数的补丁、蹩脚的分类和其余编程差别造成的。团队的开发人员以他们本人的格调编写代码也会导致代码腐烂。产品公布后，代码腐烂是典型的综合症，如果容许代码腐烂，过不了几年，零碎就要全副重写。通过一直的重构，并且在一些小问题变成大问题之前一直地修复它们，咱们可能放弃咱们的应用程序不会腐烂。Robert C.Martin称之为童子军规定。童子军里有一个规定：“来到的时候，总要让露营地比你来的时候更洁净。”利用于软件开发中就是：提交一个模块代码的时候，要让它比下载的时候更简洁一些，不管谁是这段代码的原作者。如果咱们都遵循这个简略的规定咱们的零碎最终会变得越来越好，是整个团队照料整个零碎，而非集体各自只关怀他们那一小部分，这样就合乎代码集体所有制准则，同时还能够造就团队成员的主人翁精力和责任感。 何时重构Kent Beck提出了“代码坏滋味”的说法，这种坏滋味，就是收回了重构的强烈信息，在《重构》一书中提到了24类，在这里咱们重点探讨以下几类： 1.神秘命名猜谜这件事如果产生在浏览代码的时候，就不是一个好的体验。代码整洁最重要的一项就是好的命名，尽量做到见名知意。每个团队都有本人对立的命名标准，常见命名办法有驼峰命名法如userName，蛇形命名法如user_name，脊柱命名法如user-name等，不管哪一种，就是不要呈现theList，var1这种写法。在代码编写过程中，咱们应该三思而行如何给函数、模块、变量和类命名，使他们可能清晰地表明本人的性能和用法。改名是最罕用的重构伎俩，包含批改函数申明、变量改名、字段改名等，好的名字可能节俭将来在猜谜上的大把工夫。如果想不出一个好的名字，阐明背地很可能潜在更深的设计问题，为一个名字所付出的纠结，经常能推动咱们对代码进行精简。 2.反复代码反复代码，顾名思义就是两段代码看上去简直雷同或者两段代码都是实现雷同的性能。当程序中存在大量反复的代码，会造成代码长度过长，不易浏览，遇到雷同或类似的代码段须要认真分辨，如果须要批改某一处的时候，为了防止脱漏须要查找出所有的雷同代码段进行批改，不易保护。如果是同一个类的两个函数含有雷同的代码，如文章结尾的例子，这时候能够用提炼函数来提炼出反复的代码，而后让这两个地点都调用被提炼出的那段代码。如果反复代码只是类似而不是雷同，能够先尝试用挪动语句重组代码程序，把类似的局部放在一起以便于提炼。 3.过长参数列表函数通常都须要接管参数，而后去实现某些解决，在《代码整洁之道》中提出，一个函数的参数应该尽可能短，最好只有一个，其次是两个，如果呈现三个以上的参数，就须要留神了。函数的参数过多不易于保护和批改，可读性也差，容易出错。如果一些参数来自同一个对象，那么就不要独自取出这些数作为函数参数传递，而是间接将这个对象传递过来。如果某些参数值能够通过调用已知的一个办法失去，那么就要把这个参数退换为在办法体内调用取值的那个已知办法。还有参数不来自同一个对象，如果有必要，咱们也要毫不犹豫的为这些参数新建一个不可变的类，强制将它们放在一起 4.过长函数在编程晚期，因为调用子函数须要产生额定的开销，所以大家都不喜爱小函数，一个函数动辄几百多行，鼠标的滚动条要滚好一会能力到办法开端，更不用说一行一行的去浏览，去了解，能够设想他人来批改这段代码的时候他有如许苦楚。古代的开发环境曾经齐全罢黜了过程内的函数调用开销。所以要保障本人的函数短小精悍。通常一个函数长度的底线是要在一个屏幕内齐全显示。当然有时候一个函数开始的时候并不是那么长，只是随着每次需要的变更，每次一点点的加代码而没有留神重构，幸运的认为一点点基本不算什么，千里之行;始于足下最初终于不可收拾了。过长函数应该踊跃的进行函数合成，提炼函数，找到函数中适宜集中在一起的局部，把他们提炼进去造成一个新的函数。哪怕有时候是对一行代码进行这样的提取也是值得的口头，因为要害不在于函数的长度，而是在于函数做了什么。 5.全局数据在开始学习编程的时候，老师应该讲过防止应用全局变量，因为它太不可控了，在代码的任何一个角落都能够批改它，而且没有任何机制可能探测进去到底哪段代码做出了批改。全局变量一次次造成的那种诡异bug，足够让你刻骨铭心。对于全局数据要防止应用，函数内的就放在函数体内，代码段内的就放在代码段中。无处可放，须要独自存在的全局数据就将其封装在函数中，这样就能够找到在哪个中央进行了批改，还要将这个函数放在某个类中，限定那些办法能够应用它，让数据的批改过程可控可追溯。 6.正文代码中如果呈现了大段的正文用来解释代码的含意，而起因是代码写的太蹩脚了，不得不依赖于正文，这就是一种坏滋味。当你感觉须要写正文的时候，能够先试试重构，试着让所有正文都变得多余。如果须要正文来解释一段代码做了什么，能够试试提炼函数；如果函数曾经提炼进去，然而还是须要正文来解释做了什么，能够试试为函数申明改名；如果正文是阐明某些零碎的需要规格，试试引入断言。不是提倡不要写正文，而是要写适合的正文，对于正文，咱们应该遵循这样一条准则：“正文的应用不是为了阐明这段代码能做什么而是应该阐明为什么要这么做”。 7.死代码死代码泛指在程序运行过程中执行不到的代码，或者执行的到但没有任何作用的代码，也就是无用代码。当程序中的变量变成不依赖于内部传过来的数据,被定义成常量时，便无奈适应外界其余的变动，就会产生死代码。这些代码通常是因为需要变更或者代码批改，变得用不到了，如果发现，就及时革除它们。 写在最初重构越晚，须要批改的代码越多，就会造成技术债权。除了下面提到的几类重构的场景，还有很多其余的场景，重构尽管不是包治百病的灵丹妙药，然而重构是十分有价值的，能够帮忙你始终良好地管制本人的代码。尤其是作为麻利开发团队，重构是团队成员应该熟练掌握的，任何团队都应建设重构技能。同时，Scrum培训师Stefan Wolpers示意，Scrum团队应该思考将15%～20%的资源分配给每个Sprint周期的重构代码和修复谬误。由此可见，重构这件事件是循序渐进的作为一项改良流动继续进行。

随同着数字化与信息化的倒退，研发效力和降本增效日渐成为企业治理焦点。尤其对于研发型团队而言，疾速地、保质保量地交付价值是优先级最高的工作，但在理论的开发过程中，咱们总会遇到技术债权、并行抵触等影响研发效力的状况。 在辞别横蛮成长，主张精耕细作的明天，企业/组织应该如何解读种种效力阻碍，制订可复制的解决方案？本篇文章将从7 个常见的研发场景登程，分享无关研发效力晋升的心得与教训。 场景一：并行开发导致代码抵触组内/组间并行，或由代码回退/合并等造成的各种并行开发导致代码抵触是常见的效力问题之一。并行化的分支治理和版本治理是比拟重要的议题，而合并策略、Feature分支治理、变更治理都可能影响研发效力。 解决这个问题，能够思考以下三种优化形式： 时序串行治理 以工夫为轴，串起整个版本主线，代码对版本负责，版本对性能负责。对同一零碎而言，代码是并行开发的，但最终的交付物/公布物是程序公布的；对不同零碎而言，次要思考相互间的依赖关系，影响面以及公布程序。 性能化整为零 依照麻利迭代形式将大性能化整为零，更好地应答变动。如遇到迭代周期内需要必须变更的状况，须要确定好变更的影响范畴和需要优先级。需要分而治之技术/优化需要和跟版迭代需要可能须要采纳不同的公布策略和分支治理。这样既能够保障业务指标按期、无效地达成，还能保障各种优化和撑持工作灵便地进行和并行。 场景二：技术债与架构腐化技术债是一个陈词滥调的话题。企业在平时的研发治理中，应器重「好习惯」的造就，若等到技术债堆积成山，零碎不可救药才着手解决，恐怕就为时已晚了。 倡议在日常的研发治理中，增强代码审核机制，履行代码的P3C规范化查看；后期对业务的技术计划也应作出正当取舍。 另外，架构设计应结合实际业务和资源进行充分考虑，谨防适度设计。好的架构是演变而来的，没有一劳永逸的完满架构。 场景三：频繁的故障排除工作并行协同时，配置和资源文件的不同步也是造成抵触和问题的重要因素。为防止额定的排除工作影响研发效力，企业能够思考晋升配置和资源的独立性以及简化性。 第一，尽量按工夫程序治理需要配置的惟一值；如果不能保障惟一配置，则举荐按分组逻辑治理各组的批改值（不冗余其余组的原有配置）。 比方，按工夫序列治理或分组并列治理，待确定提测节点后再进行合并。这样能够较清晰地发现抵触项，避免相互笼罩。 此外，除公共配置外，思考按性能进行分组配置，不要将全部内容写在一个配置文件里。 第二，配置合并时，签入签出流程要尽可能短。配置的合并过程须要审核，但配置调整的流程工夫窗口不易过长，免得造成额定的期待老本，诱发潜在的抵触。 场景四：生产问题排查与数据安全性许多时候，生产环境的数据必须脱敏，但同时，研发团队又须要验证生产问题或放大问题的影响面。这种状况应该如何解读和解决？ 用脱敏后的非敏感数据实现验证 生产环境的客户数据脱敏后，记录局部非敏感的ID参数、异样等日志仍能够作为无效数据，实现特定场景下的剖析诉求。 在Pre准生产环境同步非客户数据 筹备一个与生产环境绝对统一的「克隆体」——Pre准生产环境，同步并通过非客户数据实现生产环境的验证。 非客户数据包含局部生产测试的数据、经客户容许的可收集的局部数据，以及通过合规齐全脱敏后的数据等等。采纳A/B测试，后行浸透运行 通过大量客户浸透，或对局部特定租户进行生产环境的短时浸透运行，稳固后再投入大规模部署。 场景五：环境复杂度研发过程中，开发环境和部署环境的复杂度也会影响研发效力。因而，倡议尽可能地升高自测、联调、环境部署的复杂度，以及同一个服务的代码量和复杂度。 举个例子，有些零碎仅是启动就要耗时 30 分钟，那么每位开发者每天花在应答环境、应答启动的工夫老本也显著减少了。 场景六：生产问题和潜在问题 不可否认地，没有一款产品、一项服务能永远不出问题。因而，搭建无效、可快速反应的业务监控和运维监控体系十分重要。 不论选用哪种监控平台零碎，外围目标都是监控外围指标，并实现要害指标的及时预警和告诉。无效、间接、疾速地反馈和解决发现的问题，比丰盛的监控计划更为重要。 其次，器重测试环节。思考补充多种测试伎俩，尽可能地发现问题，比方针对接口的自动化测试、针对场景的集成测试、对大型零碎的压测环境等等。 场景七：非技术影响因素在研发流程治理过程中，非技术因素也会对研发效力产生重要的影响。 研发流程的简洁性与合理性产品继续输入与正当的需要粒度会议效率和沟通协调的老本及损耗性情不同导致的无效沟通形式的差别长期的紧绷状态Liga总结研发流程治理是研发效力晋升畛域中重要的议题。管理者能够以鸟瞰视图，剖析和判断研发全生命周期的运行状况，并借助智能化的监控和预警工具，发现问题、解决问题、防止问题，做出更牢靠的治理干涉和疏导。 理解更多麻利开发、项目管理、行业动态等音讯，关注咱们的sf账号-LigaAI~ 或者点击LigaAI-新一代智能研发合作平台，在线申请体验咱们的产品。

写在后面「麻利之道」是 LigaAI 的全新栏目。在这里，Liga 心愿能与更多敌人一起深入探讨「麻利」常识，开掘和发现更多工作和生存中的“麻利可能”。新篇第一章，咱们聊聊“什么是麻利”。 麻利开发尽管被视为“开发者的福音”，但却频繁被国内团队诟病成“世纪大谎话”。难道麻利开发在国内真的行不通吗？ 事实上，许多团队声称的“麻利”不是最后解放开发者的麻利，而是全面了解需要、极其谋求疾速交付、疏忽软件品质的“田园麻利”。麻利开发在国内实际的“跑偏”，源于对“麻利”深度了解的不足，浮于外表的利用将“麻利”错当成“疾速”。因而，本篇心愿与诸位就以下问题独特探讨“麻利”的实质： 麻利开发是什么？麻利开发的「麻利」指什么？麻利开发比瀑布开发更好么？打造麻利开发团队的第一步是什么？麻利开发是什么？麻利开发自1990年代起逐步被宽泛关注，作为一种新型软件开发办法，它形容的是一种疾速应答变动的能力。 麻利联盟（agilealliance.org）对麻利开发的定义如下：麻利软件开发是一组基于麻利软件开发宣言及其背地的12个准则中表白的价值观和准则的框架和实际的总称。上面，咱们来重温一下「麻利宣言」，以及其背地的价值观和准则。 麻利宣言 Agile Manifesto「麻利宣言」诞生在美国犹他州的雪鸟城，一个跟软件反动或者科技翻新没啥关系的滑雪基地。2001年，苦于软件开发中不合理的繁冗流程和文件，来自多个不同软件开发畛域的17位代表汇集在一起（度假），探讨软件开发的将来。最终，他们达成了价值观和原则上的共识，独特签订并公布了「麻利软件开发宣言 Manifesto for Agile Software Development 」，即「麻利宣言」。 「麻利宣言」在极限编程 (XP)、Scrum、动静零碎开发 (DSDM)、水晶开发(Crystal Clear)、特色驱动开发(FDD) 等框架中找到了共同点，并定义了麻利开发的四项外围价值观和十二条根本准则。 麻利价值观 Agile Values「麻利宣言」传递了不同于传统软件开发的四项价值观，即麻利开发更器重 个体和互动 Individuals and interactions工作的软件 Working software客户单干 Customer collaboration响应变动 Responding to change「麻利宣言」在价值观的最初说到：“只管右项有其价值，咱们更器重左项的价值”，而左项的四项价值，即流程和工具、详尽的文档、合同会谈和遵循打算正是传统软件开发模式——瀑布式软件开发的外围。 麻利开发准则 Agile Principles「麻利宣言」进一步拓展四项价值观，补充提出了麻利开发应该恪守的十二条准则。 麻利开发 Agile Development麻利价值观和麻利开发准则独特阐明，麻利开发以客户称心为指标，器重成员个体的能力与价值，强调团队内外须要严密合作和高效沟通，认为个体内驱、团队信赖、谋求卓越和优化提高能推动我的项目进行。 麻利开发的初衷是为了让软件开发回归到客户想要的软件自身，用价值产出取代标准文档推动我的项目实现。与非麻利的传统软件开发模式相比，麻利开发摒弃非必要的流程和文件，通过作业简化和团队内外的高效单干等，继续实现软件价值的短周期交付，让客户称心。 麻利开发的「麻利」指什么？要答复“什么是麻利”，首先要分明麻利开发的外围是什么：为什么麻利开发要求短周期开发、继续交付、拥抱变动和少写文档？ 短周期开发和继续交付是为了获取客户反馈确认研发方向，防止最终产品与客户冀望不符；拥抱变动是因为需要多变，要让最终的软件成绩符合实际的应用场景，成为有价值的软件；少写文档是为了高效传递信息，专一研发，同时能够防止需要变更导致有效文档浪费时间。能够看出，麻利开发实质上是一个需要逐步明确和丰盛的过程，而麻利开发的外围就是响应需要的变动。换句话说，麻利开发通过升高试错老本（比方缩短研发周期、摒弃非必要文档等），减小需要变更对我的项目推动的影响。 如果说麻利开发是一个具备试验性质的，一直施行“打算-实际-反馈-优化”循环的软件开发模式，那么麻利则是一种主张化繁为简和良性反馈，强调定期优化和继续提高的价值观。 为什么「麻利开发」在国内实际会脱离原有的轨迹，最初演变成「中华田园麻利开发」？因为大家把「麻利」搞错了。 麻利强调要及时依据变动进行调整和优化，以减小负面影响，它反映的是一种疾速响应变动的能力，而不是疾速研发的能力。哪怕跳出软件开发畛域，麻利也依然是一种可能贯彻“生存-工作-学习”的问题解决思维形式。就像百度词条所定义的：麻利是一种通过发明变动和响应变动在不确定和凌乱的环境中取得成功的能力。 麻利开发比瀑布开发更好吗？如果仔细注意「麻利宣言」的表述会发现，初代麻利联盟者未曾否定瀑布开发的价值，也未曾示意“麻利价值观比传统软件开发价值观更有价值”。实际上，麻利开发和瀑布开发，作为两种不同的软件开发模式，原本就没有相对的优劣之分，毕竟任何办法或者工具都要放在具体场景应用中探讨才有意义，团队形成、我的项目性质、工夫/老本等反对等都会影响办法有效性的最终断定。 可能有敌人要反驳：“端水巨匠吧你，瀑布曾经过期了，当初大家都喜爱搞麻利。” 对啊，为什么越来越多的团队和组织放弃了瀑布开发，转而抉择采纳各式各样的麻利开发方式？ 因为市场是疾速变动的，用户的需要也是多变的。相比瀑布开发的规范流程，麻利开发更能适应需要变动，做到随时响应。毕竟只有疾速响应需要变动，能力保障在当下的商业环境中相对竞争力。 「麻利开发 V.S. 瀑布开发」是一个陈词滥调的命题，两种办法各有特点，也别离实用于不同的场景： 瀑布开发更实用于我的项目需要明确且鲜有变动的，或对我的项目打算要求高的开发我的项目；麻利开发实用于需要多变的、性能耦合度低或可用性可继续叠加的，以及迫切需要市场反馈的我的项目。戳图片理解更多【麻利开发 V.S. 瀑布开发】比照 关注 LigaAI公众号 并回复关键词「比照图」获取纯享版比照 打造麻利开发团队的第一步是什么《新的新产品开发游戏》的作者发现，世界优良公司最卓越团队具备以下三个特色：超过寻常、自主性和多功能。如果想要打造卓越的麻利开发团队，应该从哪里开始？ 首先明确卓越的麻利开发团队是什么样的。「麻利宣言」形容的“现实团队”有以下特色： 业务人员和开发人员相互合作高效沟通（最好是面对面沟通）个体斗志，成员是我的项目外围坚定不移地谋求技术卓越和良好设计团队要定期反思，优化调整责任人、开发人员和用户独特维持稳固步调如果现实的麻利开发团队是高效单干、良好沟通、斗志昂扬、节奏统一的，那么打造麻利开发团队的第一步，就是领有一个「小而精且构造扁平」的软件研发团队。 布鲁克斯法令指出，因为组内沟通成本增加等，投入更多的人来开发一个紧急的我的项目只会让进度更慢。因而，麻利开发中，团队越小越有劣势，而最佳的麻利团队规模应该维持在 4-9 人之间，宜少不宜多。开发团队必须熟练掌握实现一个我的项目所需的全副技能，能力顺利推动我的项目实现。麻利开发团队须要业余精湛且多功能的成员，换句话说，兼具深度业余和跨职能的「T型人才 T-shaped Person」是麻利开发的最优选。扁平化组织构造所隐含的兽性假如是，人除了社会需要外，还有一种想充沛体现本人能力、施展本人后劲的欲望。因而，在扁平组织中，成员都可能通过自主摸索和继续精进来实现指标，推动我的项目进度。除了小而精之外，麻利开发准则中也有一条内容刻画了具体的团队画像： ...

最近，咱们团队为了进一步提高合作效率，组织了一次趣味分享流动，心愿通过游戏的形式，帮忙技术部门的共事们更好地了解和实际麻利开发的办法。 在这次流动中，“哪种口头形式更麻利”、“为什么采纳这种办法”等关乎麻利概念实践和实际办法的思考被搭档们提出来并公开探讨。作为开发小组的成员，我获益颇多，特将此次流动中的思考总结下来分享给大家，独特成长~ 游戏规则10集体翻30张牌，每个人要把这30张牌的每1张牌都翻一遍，计算第1集体翻完30张牌所消耗的工夫和所有人翻完30张牌所消耗的工夫~ 假如每一个红色方块耗时x，每一个橙色方块耗时y，每一个黄色方块耗时z （x, y, z > 0） 计划1: 第n集体必须等第n-1集体翻完所有的30张牌能力开始翻牌，第1集体不必等 那么咱们参考上图的构造，先计算第1~5集体的翻完30张牌的工夫，而后再乘以2就是总计用时（不存在影响工夫的意外状况）： T1 = ((5 + 1) 5 / 2 x + (4 + 1) 4 / 2 y + 25 5 z) * 2 =30x + 20y + 250z 计划2：第n集体必须等第n-1集体翻完第5张牌能力开始翻牌，第1集体不必等；且第n集体必须等第n-1集体翻完第m张牌，能力翻第m张牌，第1集体不必等。 参考上图构造，先计算1 ~ 10集体翻完前5张牌的工夫，而后再计算第10集体翻完6 ~ 25张牌的工夫就是总计用时（不存在影响工夫的意外状况）： T2= ((5 + 1) 5 / 2 x + (4 + 1) 4 / 2 y) 2 + 25 z = 30x + 20y + 25z ...

在Scurm框架下，Product Owner 是一个十分重要的角色，那么PO应该把握的那些基本知识呢？上面通过7个方面进行简略的介绍。 1、“Project to Product”咱们先来比照一下我的项目思维和产品思维。我的项目思维模式“由外向外”定义了什么是胜利，应用的外部衡量标准更多的是对于工作治理和初始打算的执行精度。产品思维形式是一种由外而内的办法，它通过内部衡量标准来领导产品的开发，以实现价值最大化。 客户看中的是什么？我的项目还是产品？组织的指标并非是交付我的项目，而是通过产品交付价值，这些产品最终会为组织带来更高的收益和更低的老本。产品杰出客户群就会增长，现有的客户就能保留下来。所以忘掉我的项目吧。把创意当做一个产品来对待，而后将产品创意交给一个富裕能力的团队，向他们介绍业务指标及其意义，如客户的满意度，让每个成员都粗浅意识到，实现这些指标的惟一办法是尽快公布有价值的产品，并验证事后设计的商业假如。 总结来看，麻利产品治理的特点： 激励频繁公布，尽早获取市场反馈传播指标而不是工作；团队为他们的解决方案赋予更多的创造性，针对他们的打算领有更多所有权缩小对任务分配、报告和管理决策的依赖，从而打消节约一个组织不管开发何种产品，都会制订不同档次的打算。因为形似洋葱，因而形象的称之为“洋葱圈打算”。 在大的组织指标和开发团队日常工作之间存在“鸿沟”，咱们称之为“产品治理真空”。 产品的真空区越大就会导致产品的技术团队与业务就越拆散、就越依赖我的项目和工作治理、层级和交接就越多、节约和返工就越多等一系列的问题，最终会导致交付给客户的价值就越少。 真正的产品治理就是在整个组织中自上而下地实现麻利能力，并因而打消产品治理真空。如果施行到位，则必将发明出真正的竞争劣势 愿景：发明透明性。胜利的PO应该为团队建设清晰的产品愿景价值：用于确定要检视的内容验证：为了进行最终验证并升高总体产品危险，必须与市场建设一个反馈环。因而，须要做的是尽可能的频繁公布产品治理真空区是须要PO参加进来的中央，一个被受权并且具备创业精神的PO可能填补产品治理的真空。 2、Product Owner Product Owner的特色如下： 负责该角色的是一个人驱动产品胜利对于客户来说代表我的项目对于我的项目来说代表客户要与所有人独特合作个别由客户或客户代表负责在Sprint过程中作为不可或缺的团队成员在理解了PO的特色当前，咱们再来看一下Product Owner的使命： 创立产品愿景定义产品个性依据市场价值进行优先级排列对投资回报率（ROI）负责依据市场反馈调整产品个性和优先级承受/回绝工作成绩确保为迭代输出做好筹备PO必须衡量产品的多重属性： 如果只是把精力集中在本人可能制作的产品上，那么你的产品可能没人想要，即使你对这个产品充满热情也杯水车薪。如果你只是把精力集中在本人能卖掉的产品上，可能会给客户许下不切实际的诺言，承诺一个生产不进去的产品。如果你只是集中精力生产能卖掉、本人却没有激情的产品，那么你最初生产进去的产品可能流于平庸。 上图的地方区域，三方交回的地位，是最现实的，是建设在事实根底之上的美好前景，很可能发明卓越。 3、Product VersionProduct Version（产品愿景）是指产品负责人对产品将来前景和方向的一个高度概括形容，它应合乎公司或组织的战略目标。好的产品愿景能让我的项目团队理解产品的价值，建设独特的指标并激发团队士气。 Product Version 的工具个别包含：Product Box（产品包装盒）、Press Release（媒体发布会）、Elevator Pitch（电梯演讲）。其中比拟罕用的就是电梯演讲工具，在乘电梯的20秒内清晰精确的向客户解释分明解决方案，这是麦肯锡公司测验其陈说报告的办法之一。电梯演讲梳理产品愿景的格式化构造如下： For (customer)【指标客户】,who (statement of need)【需要和机会】,the (product name) 【产品名称】is a (product category)【产品定位、类型】that (key benefit, compelling reason to buy).【要害长处和购买理由】Unlike（primary competitor)【次要竞争对手】,our product (statement of primary differentiation)【差异化申明，即杀手性能】.为了无效地流传愿景并确保更好地了解和遵循愿景，还能够在团队的工作场合中想方法让愿景宣言随处可见。 4、Product BacklogProduct Backlog（前面简称PB）是指产品可能包含的性能的动静列表以及其余为用户提供价值的工作。一个衰弱的PB应该具备DEEP 特色： Detailed appropriately【详略切当】Estimated【做过估算的】Emergent【涌现的】Prioritised/ordered【排列优先级的】PB向团队所有人凋谢，但归根结底由PO进行梳理，聚焦在What能给用户带来最大价值。 在PB中能够蕴含的内容： 性能需要非性能需要Spike（探针/打探）技术债权Spike能够作为一种研究性条目放在PB中，其指标是帮忙获取某项性能在实现时所须要的更多信息。通常，Spike是对某项性能实现的一个非常简单的概念验证。Spike的最终目标是通过试验来升高危险，让咱们可能更快的做出更好的产品决策。 揭示：Spike的危险在于可能像任何货色一样被滥用。例如：每一个Sprint都是以一个Spike故事完结，要明确，Spike对企业不尝试任何的间接价值。所以能够应用，但不要滥用。 PB常见的优先级排序法有：MoSCow、KANO、100 Dollars，感兴趣的能够查阅相干材料进一步理解。 ...

影响地图是一个简略却极高效的协作性的策略布局办法。有的产品，它还活着，它曾经死了；有的产品，还没公布，就曾经死了。太多的产品失败的案例，源于方向性谬误，基于谬误的假如，性能与业务指标/价值之间不足必然的关联与一致性，在做的事与冀望的指标背道而驰。影响地图试图通过结构化、可视化、合作化的形式来从源头解决上述问题。 影响地图是一门战略规划技术，通过清晰的沟通假如，帮忙团队依据总体业务指标调整其流动，以及做出更好的里程碑决策，影响地图能够帮忙组织防止在构建产品和交付我的项目的过程中迷失方向。确保所有参加交付的人对指标、冀望影响和要害假如了解统一。 同时，影响地图能够无效的评估交付，作为品质反馈的规范之一：如果一个需要没有无效的反对冀望的行为影响，那么即便在技术上正确，性能交付给用户了，也依然是失败的。 影响地图试图去解决组织面临的范畴蔓延、适度工程、不足整体视图、开发团队和业务指标不能保持一致等困扰 影响地图的构造简略的讲，影响地图是这样的一个思维逻辑和组织构造：为什么（Why）-->谁（Who）-->怎么（How）-->什么（What） 也就是：咱们的指标是什么（Why），为了达成指标须要哪些人（Who）去怎么（How）影响，为此咱们须要做什么（What）。影响地图通过构建产品和交付我的项目来产生本质影响，从而达到业务指标。 为什么（Why）？咱们为什么做这些？也就是咱们要试图达成的指标。找到正确的问题，要比找到好的答复艰难得多。把本来刻画在文档中，更多的是暗藏在高层利益干系人头脑中的业务指标，定性定量的疏导进去。指标形容要遵循SMART准则：Specific明确，Measurable可度量，Action-Oriented面向口头，Realisitc事实的，Timely有时限的。确保每个人晓得做事的目标是什么，帮忙团队合作，针对真正/适合的需要设计更好的计划。 谁（Who）？谁能产生须要的成果？谁会妨碍它？谁是产品的消费者或用户？谁会被它影响？也就是那些会影响后果的角色。思考波及到的这些决策者、用户群和生态系统，留神角色同样有优先级，优先思考最重要的角色。角色定义应该明确，防止泛化，能够参考用户画像Persona的形式进行定义。 怎么（How）？思考角色行为如何帮忙或障碍咱们达成指标？咱们冀望见到的影响。只列出对靠近指标有帮忙的影响，而不是试图列出所有角色想达成的事。影响是角色的流动，是业务流动而不是产品性能。现实状况下应展示角色行为的变动，而不仅仅是行为自身。不同的角色可能有不同的办法，帮忙或妨碍业务指标的实现，这些影响彼此之间可能是互相参考，互相补充，相互竞争，或者互相抵触的。既要思考到侧面的影响，也要思考负面或妨碍的影响。 留神：业务发起方应该针对角色Who以及影响How，而不是交付内容What进行优先级排序。什么（What）？作为组织或交付团队，咱们能够做什么来反对影响的实现？蕴含：交付内容，软件性能以及组织的流动。实践上这里是最不重要的一个档次，防止试图一开始就将它残缺列数，而应该在迭代过程中逐步完善。同时留神，不是所有列出来的货色都是须要交付的，它们只是有优先级的交付抉择。 "永远不要试图实现整个地图，而是要在地图上找到达到指标的最短门路。"影响地图足够简略，操作性强，又有足够的收益：可能帮忙创立更好的打算和里程碑布局，确保交付和业务指标统一，并更好的适应变动。影响地图的首要任务是展现互相的关联，主要工作是帮忙发现代替线路。 正如作者所言：影响地图合乎软件产品治理和公布打算的发展趋势------包含面向指标的需要工程、频繁的迭代交付、麻利和精益软件办法、精益守业产品开发循环，以及设计思维。如果你认同上述趋势，那么影响地图会是你的菜。 影响地图的特点结构性：从业务指标到交付的结构化梳理和开掘的办法，指标--角色--影响--交付物；整体性：连贯指标和具体交付物之间的树状逻辑图谱；协作性：利益相干人一起沟通探讨合作，把暗藏在集体头脑中的默认的思维逻辑开掘共享进去；动态性：动静调整、迭代演进、教训证的学习；可视化：对立共享的视图，构造清晰易读。它将各个部门/角色不同的视角，不同的思维逻辑，不同的前提假如，通过可视化和合作的形式进行梳理、廓清和导出。通过连贯交付内容、影响和指标，影响地图显示了之所以去做某个性能的因果链，同时也可视化了各利益相干人做出的假如。这些假如包含：业务交付的指标，波及指标干系人，试图达到的影响。 同时，影响地图沟通了两个层面的因果关系假如： 交付会带来角色行为的变动，产生影响；一旦影响达成，相干的角色会对整体指标产生奉献。 影响地图分层是否能够将影响地图分层？ 我认为齐全能够而且正当。《影响地图》也提到倡议打算两次会议：第一次定义预期的业务指标和度量；第二次来制作一张地图。第一步就是确定使命，而一个战略目标往往太大，无奈疾速奏效，须要拆分成可短期达成的战术指标，依据优先级排序的战术指标，逐次进行影响地图分析，期间动静调整更新，定期决定是否须要持续。 因而能够有两层的影响地图："一份针对整体产品愿景，一份针对中期交付。" 同时，通过分层，也能够无效的管制参加两个会议的人员组成。高阶的领导者未必须要加入所有的影响地图流动，尤其是战术影响地图会议。 参加人员Decision Maker，留神肯定要有决策者参加，包含：商业决策、技术决策、营销决策（原书中为高级技术和业务人员）。如果发现一个问题探讨很久没有决定，兴许是因为不足适合的参加人员，应该找更高阶的人员决策。参加人数：原书的倡议是将第一次会议人数限度在不超过5-6人，确保要害的业务决策者和技术人员参加进来。随后的会议能够适当扩充规模分组讨论，随后汇总，但人数越多，会议的节奏和范畴就越须要管制。 影响地图与用户故事的关联影响地图能够作为用户故事列表的无效输出影响地图的输入物，能够作为用户故事的输出，作为Epic、UserStory的起源。这些输出曾经通过了价值判断，角色开掘，优先级排序，甚至曾经有了一 局部的验收规范（是否影响了受众同时为达成指标作出贡献），同时也因为有资深技术人员的参加，初步做过技术可行性判断。因而这些backlog的输出，往 往更加靠谱，对交付团队更具价值。 输出模式《影响地图》书中有明确的形容，把三段式的用户故事与影响地图几个层级进行mapping：作为一个Who，我心愿What，以便于How。 影响地图能够很好的管制用户故事列表有限蔓延看似动静调整的故事列表，依据精益打消节约的思维，保护残缺的故事列表，事实上也是节约。存在的问题有两点： 第一，看不到用户故事与业务价值间接的分割，往往为了实现性能去做，而不是思考其背地交付的价值，以及这个价值是否被用户认可；第二，故事列表往往是各方头脑风暴的后果，同时还在不断更新，却很少剔除，这个长长的列表不仅须要定期维护，其背景、内容、优先级、价值等都在随着商业环境的变动而一直变动；事实上保护一个三个月或者半年当前才可能实现的需要就是节约。指标/里程碑与公布打算业务指标能够与迭代的公布打算关联，每次迭代只解决大量的指标；《影响地图》倡议一次只解决一个指标，目标在于疾速反馈和调整；集体认为基于团队规模、迭代步速，一次迭代能够蕴含几个指标决定于指标的颗粒度以及工夫估算，不可一概而论。当然在具体执行时，这里会是一个争执以及变数较多的点。 如何避免思维蔓延，地图扩张先发散再收敛实战练习中，咱们40多人分成6组，别离绘制本人的影响地图；理论场景中，如果每组都基于同一个指标，绘制进去的地图会各具特色而发散，最终须要疏导将发散的地图进行收敛，在此过程中，会发现更好的实现或是新的假如导出，最终失去成型的影响地图。 分层和分拆时，把握80/20准则，不求八面玲珑，只须要波及最要害重要的因素。思考到大部分团队会应用物理板+即时贴的形式进行影响地图的设计，集体认为，本来因为物理空间受限以及可读性起因存在的物理白板的弊病，反而能够作为细化水平的一个无效限度准则（正如驰名的两个披萨准则）：以物理墙/白板为影响地图的最大边界。 绝对于咱们通常关怀的业务性能/营销流动，即影响地图的第四层What，咱们更应该把把注意力放在前三层指标、角色和影响上，尤其是角色和影响上，关注点如此，优先级排序也是如此；先不要关注在What即本人要做什么事件上，这往往会让咱们陷入执行的细节，埋头做事，而疏忽了事件的初衷。 少数的门路最终不会被执行，是否须要保留？ 首先要防止过早陷入过多的细节，将来一切都是未知的，所有的都是基于以后的假如，所以保护一份残缺的地图，试图将所有想法都演绎在地图上，是没必要的。其次，指标导向，防止在那些对整体指标没有作用的影响上破费过多的工夫。整理出来的门路，当然能够保留下来，作为下一次影响地图的局部输出。 此外，须要留神的是，What蕴含交付内容、软件性能和组织的流动，如果交付的所有条目都是技术性，兴许要从新扫视影响地图，尤其是角色Who与影响How两局部，并非所有的指标都是须要通过产品性能达成，更多状况下，兴许一个简略的营销流动就能够疾速实现目标。 什么工夫完结影响地图会议何时完结"当要害想法曾经呈现在地图上"，当曾经达成指标，并且确定最快/小门路，临时也想不出更好的代替计划时，就能够完结。倡议设定严格的timebox，一旦呈现工夫点超时，或者是团队陷入太过细节的探讨，或是没有找对适合的人，不足适合的决策者，兴许是业务决策者，兴许是技术决策者。 影响地图何时生效如同打算，在制订进去的那一刻兴许影响地图就曾经生效，因而须要适时调整（留神是适时，未必是实时）。影响地图更像是迭代打算，每个影响达成，进行反馈评估，对影响地图的内容以及优先级进行调整；一旦指标达成，兴许这张影响地图就实现了使命。 影响地图能够在哪些方面利用影响地图的思维办法和逻辑构造是广泛实用的，因而能够利用到很多畛域，诸如旅行，健身，减肥，教育，学习打算，战略目标，营销策略，销售打算等；但理论执行的过程未必要残缺的按四个阶段进行。 对影响地图实际的集体领会，演绎为"三心二义"不忘初心 始终牢记做事的初衷是达成业务指标，而不是实现性能，甚至不是达成影响（如果影响最终不能帮忙实现目标）；不要贪婪 不要试图一次实现好几件事，而应该分拆成多个里程碑，多张地图；不要试图一件事做完满，冀望把所有列出来的事件都实现是不事实且没必要的；把握80/20准则，达成指标即可，业务环境始终在变，业务关注点也会随之变动；赤子之心 不偏不倚，不卑不亢，边走边学边调整，对指标和将来抱着一颗坦诚、恭敬与摸索的心，不否定、不自卑、不盲从。批判主义 狐疑所有，多问几个为什么；把假如疏导进去，通过剖析和实际来验证假如；实用主义 所有以实用登程，价值导向，指标导向，后果导向，放弃简洁；参考 : 《影响地图》中文电子书：http://www.ituring.com.cn/boo...起源：Agile1001 玩乐高，学麻利，规模化麻利联合作战沙盘之「乌托邦打算」，2022年3月5-6日登陆深圳，将“多团队麻利协同”基因内化在研发流程中，为规模化晋升研发效力保驾护航！!⛴公众号回复“乌托邦”可加入

管理层都喜爱指标，是基于这样的出发点，“咱们须要一个数字来掂量咱们的体现。数字会关注人并帮忙咱们掂量胜利。” 尽管本意是好的，但数字治理会不盲目地导致有问题的行为，并最终有损于更宽泛的我的项目和组织指标。指标实质上并不是一件好事，只是常常不恰当地被应用。这篇文章展现了管理层对指标的传统应用所引起的许多问题，并提供了解决这些功能障碍的代替办法。 通知我你如何掂量我，我会通知你我的行为形式。 ——埃利亚胡·戈德拉特 一、咱们应用指标的形式有什么问题？从数字治理角度查看指标的组织遵循如下流程： 管理层提出指标并制订措施；管理层为从事工作的人制订了一个长期（3-6 个月到1年）的指标；管理层只传播指标（依据约定的指标）；从事工作的人尽其所能达到目标人数。这一过程激励出于以下目标对指标进行装载： 指标作为指标——数字的指标使人们特地容易将其用作传播指标的惟一伎俩。通知人们一个尺度和一个数字通常比解释一个简单得多的指标要容易得多。指标通常是一个拍脑门的数字，一些组织甚至破费大量工夫来确定该数字应该是多少。掂量绩效的指标——有了一个既定的数字而不是一个明确的指标，管理人员当初很容易应用雷同的衡量标准来跟踪人们朝着指标后退的速度。许多组织将这些数字与集体绩效指标分割起来。指标作为最佳实际——将指标同时用作指标和绩效衡量标准会导致意想不到的副作用——这意味着该指标是实现目标的最佳办法。当一个独立的个人应用数字指标来掂量其他人时，它会对从事工作的人施加更大的压力，以达到既定的数字。因为他们仅依据该指标的绩效进行掂量，因而他们会尽其所能来实现该特定指标。这意味着没有其余办法最适宜实现最终目标。装载具备多种用处的繁多指标会导致许多问题，尤其是在处理软件等常识工作时。度量是对一个简单得多的属性的一种简化，简化复杂性的代价是以漠视真正的最终目标为代价的，并以次优后果告终。 让咱们看一个例子： 一位测试经理，咱们称她为 Mary，每周都会与开发主管 Dan 举办会议。“咱们的谬误数量如何了？” 她问他们最近的一次迭代。丹答复说：“咱们革除了三个优先级为一级的谬误，修复了四个优先级为二级的谬误并革除了创纪录的十二个优先级为三级的谬误。这周还不错吧？” 玛丽看着开发负责人，微微点头，“很遗憾，咱们的客户报告了五个一级谬误，六个二级谬误和十五个三级谬误。下周你须要更加致力。” 因错过指标而感到愤恨和手足无措的丹来到了会议，想着让他的团队再工作一个周末。 在这个非常简单的故事中，所抉择的指标达到了使会议疾速进行的益处：在丹报告他的后果和玛丽回应后，两个人都很快理解了停顿。可怜的是，交付有用软件的隐含指标被脱漏了，丹来到会议时提出了一个更可能导致进一步软件问题并连累软件品质的解决方案。 玛丽陈说她的指标的形式给丹施加了压力，要求他缩小谬误的数量，这仿佛是一个值得钦佩的指标。尽管缩小谬误的数量是一个很好的指标，但它也导致了一个十分被动的解决方案，丹来到会议时想着该要多致力工作。Mary 提出的问题漠视了更宽泛的指标，也没有提出关键问题来帮忙领导 Dan 和他的团队解决谬误存在的根本原因。如果不解决这个根本原因，Dan 和他的团队注定要一生修复谬误。 Dan 正在经验单循环学习[1]。单循环学习是对同一问题的反复尝试，办法没有变动，也从不质疑指标。如果Dan心愿解脱这种恶性循环，他须要做一些不一样的事件。软件的不当应用使 Dan 偏离了交付有用软件和进步整体软件品质的最终目标。爱因斯坦对精力错乱的定义仿佛很适宜这里：“一遍又一遍地做同样的事件，却期待不同的后果。” 二、小心你度量的货色组织喜爱指标，因为它使设定指标更容易，并阻止人们质疑指标背地的指标。这导致管理者对组织效率产生谬误的意识。与弱小指标相干的弱小激励迫使人们只专一于工作的一部分，而疏忽了可能使指标更加胜利的其余促成因素。组织必须警觉这种踊跃的破坏性焦点，它会导致人们漠视其余重要因素。 即便是麻利技术也不能爱护团队免受因测量和跟踪谬误数字而导致的不良行为的影响。例如，麻利团队常常应用故事卡[2] 进行开发工作。团队常常在其组织的软件生命周期中将这些小的工作增量可视化。一个典型的流程可能看起来像这样，现实的故事流从左到右挪动： 图 1：故事墙示例 管理人员和产品管理人员常常会问这样一个问题：“该性能多久能够实现？” 团队通常抉择将其解释为编码实现时，屈服于测试和生产门路是软件过程中微不足道和无关紧要的局部的想法。项目管理则通过提出下述问题进一步强化了这种认识：“咱们这周实现了多少个故事？” 而不是更好的问题，“咱们有信念向最终用户公布多少故事？” 或者更好的是，“咱们向最终用户公布了多少故事？” 再好一些的问题是，“咱们的用户从咱们最近的版本中发现了多少价值？” 团队心愿做正确的事件，因而这些问题和指标促使开发人员专一于让故事开发实现。让咱们看看适度专一于这个次优指标的结果： Malcolm 是营销代表，他总是对开发人员为他构建的产品十分感兴趣，因而他会尽可能频繁地到访团队。他常常与开发人员 Dan 交谈，询问他的性能何时实现。Dan，不想让马尔科姆悲观，他致力专一于实现马尔科姆提出的任何要求，他晓得离Malcolm回来询问停顿不远了。Dan常常对本人说，“这个性能肯定十分重要。” Tim 是团队的最新的测试人员，常常须要与 Dan 等开发人员分割，以理解如何触发新开发的性能。 有一天，蒂姆走近丹，“嗨丹！我真的须要你的帮忙来理解如何测试你上周实现的这个性能。” 丹，在提供快照的压力下，“你不能自己做任何事件吗？我须要实现这个性能，这样马尔科姆能力解脱我的反对。” 对丹的回应感到震惊，蒂姆回到他的办公桌前，期待着。他心想：“除非丹帮我，否则我什么也做不了。” 每周都会产生这种状况，随着工夫的推移，期待测试的故事会越来越多。最终，马尔科姆招集团队散会，关怀他两个月前要求的性能在生产中依然未能看到。令人诧异的是，丹说他一个多月前就实现了。蒂姆害羞地答复说：“我无奈测试那个故事，因为我须要丹的帮忙，而他始终忙于其余工作。我不想打断他。” 咱们能够从这个故事中学到什么？首先，对 Malcolm 来说重要的是工作流程曾经实现。只管马尔科姆问什么时候能够实现，但他真正想要的是可能在生产中应用它。咱们晓得蒂姆没有实现工作所需的常识，他的工作以及丹实现更多工作的压力阻止蒂姆取得更多常识。最终的后果是在测试过程中造成了一个恶性循环，始终没有公布，而且 Malcolm 不明确为什么他没有收到他要求的性能。这就是为什么像看板软件开发这样的办法激励 明确的正在进行的工作 限度。当瓶颈呈现时，这些限度迫使人们帮忙别人。这些 WIP 限度有助于克服当人们用谬误的集体生产力指标而不是交付的整体价值来掂量时呈现的不良行为。《精益软件开发》一书，强调掂量端到端后果的重要性，而不仅仅是过程的一小部分，并提出称之为“优化整体”的准则。优化整体意味着确保应用的指标不会推动次优行为实现交付有用软件的真正指标。 三、更失当地应用指标的指南鉴于因指标使用不当而呈现的不良行为，这是否就意味着它们没有立足之地？度量指标当然有其施展空间，只是须要一种不同的办法。应用以下指南可疏导你更失当地应用指标： 明确地将指标与指标分割起来；偏向于跟踪趋势而不是相对数字；应用更短的跟踪周期；当指标进行推动改革时扭转指标。3.1 明确地将指标与指标分割起来在传统格调中，管理层决定实现特定指标的最佳措施是什么；而后，管理层依据该措施设定指标；而后，管理层只向从事工作的人说明这个指标，通常是用数字示意。为监控指标停顿而抉择的措施与理论指标自身之间的界线很含糊。随着工夫的推移，掂量背地的起因隐没了。即使是该指标与最终目标不再相干，人们却仍然专一于实现指标。度量的一个更适合的用处是确保所选的进度度量（指标），始终与其目标（指标）相干。 例如，在软件开发的场景中，您可能会看到如下定义的指标： 办法必须少于 15 行，一个办法的参数不能超过 4 个，办法圈复杂度不得超过 20。适当的应用度量规范，每一项措施都应与其最后的目标明确分割起来。以后的跟踪和监控机制必须与其指标解耦，并明确指标以便帮忙人们更好地了解指标的用意。存在于更丰盛的上下文中的度量将领导人们为实现目标做出更适合、更求实并且更有用的决策。不足目标，付出的致力意味着人们千方百计创造性地和零碎做游戏，最终将偏离真正的指标。 ...

十四五布局大纲中指出，要放慢数字化倒退、建设数字中国，以数字化转型整体驱动生产方式、生存形式和治理形式改革。新形势下，数字化建设被提到了前所未有的高度，是实现翻新驱动倒退的重要抓手。然而，数字化建设过程中，企业常面临业务变动快、合作流程繁、能力积淀难等诸多问题，只有提前整体布局布局，以迷信方法论和业余管理工具对数字化策略进行落地，能力更好地帮忙企业实现数字化转型。 猪齿鱼效力治理平台，由上海汉得信息技术股份有限公司（以下简称上海汉得）自主研发推出，通过提供体系化方法论和合作、测试、DevOps及容器工具，帮忙企业拉通需要、设计、开发、部署、测试和经营流程，一站式进步管理效率和品质，助力团队效力更快更强更稳固，帮忙企业推动数智化转型降级。 本周四，由上海汉得和上海熙上网络科技有限公司独特推出的“企业数字化建设门路与效力晋升实际分享”线上直播，将邀请猪齿鱼资深业务架构师程沛女士分享企业数字化建设整体框架设计、方法论、效力晋升利器与利用实际，为企业数字化建设提供思考方向。欢送扫码报名。 直播介绍 直播工夫：2021年12月16日（周四） 19:30-21:00 直播地址： 腾讯会议 ID：583-107-754 或间接点击：https://meeting.tencent.com/d... 主讲人： 程沛 猪齿鱼资深业务架构师 倡议参会人员： 各公司技术总监、研发主管、我的项目总监、施行参谋、信息中心负责人等 您将播种： l 企业数字化建设的方法论和五大武器 l 数字化效力晋升的要诀 数字化大潮正席卷寰球，咱们诚邀您和您的团队加入本次线上直播，独特探讨企业数字化建设与效力晋升话题！ 本文由猪齿鱼技术团队原创，转载请注明出处：猪齿鱼官网 对于猪齿鱼 猪齿鱼Choerodon数智化效力平台，提供体系化方法论和合作、测试、DevOps及容器工具，帮忙企业拉通需要、设计、开发、部署、测试和经营流程，一站式进步管理效率和品质。从团队协同到DevOps工具链、从平台工具到体系化方法论，猪齿鱼全面满足协同治理与工程效率需要，贯通端到端全流程，助力团队效力更快更强更稳固，帮忙企业推动数智化转型降级。戳此处试用猪齿鱼

最近又一个我的项目用瀑布形式做砸了（因为本文会屡次提到本我的项目，咱们就叫她我的项目X吧）。我的项目X刚开始的时候，咱们部门的麻利转型还没有起步，所有我的项目仍然用瀑布形式。这个我的项目我一开始就想采纳麻利，毕竟这才是我拿手的，和客户那边也沟通过，他们也不拥护尝试。而且我的项目的自主开发局部是用Java写的，有肯定的JUnit测试笼罩和继续集成（CI）根底。然而因为我始终没有想好这个我的项目能够如何拆分进而迭代，所以我的项目的麻利转型始终被搁置，其理论开发过程仍然是瀑布形式，也遭逢了所有瀑布形式会遇到的问题。 （传统需要难以描述用户的实在想法，传统瀑布开发没有疾速反馈机制） 瀑布不行，向麻利转型曾经是共识，然而具体怎么做呢？通过对我的项目X的复盘以及对其余我的项目的思考，以下是我的一些心得。 把我的项目拆分成用户故事才是硬本事我也算是个“老麻利”，但像后面说的，在面对一个具体我的项目，不会把我的项目拆分成用户故事，就无奈麻利起来！真正的麻利开发必须是基于用户故事的开发过程。 所谓用户故事就是含有肯定业务价值的端到端交付。瀑布开发是把我的项目依照不同生命周期阶段横向拆分的过程。而麻利开发是把我的项目或产品或业务指标竖向拆分成若干可体验、可交付的用户故事的过程。一个用户故事，应该是用一两个月甚至几个星期或更短时间就能做进去的货色，咱们能够通过它更早地获取用户反馈，从而确定产品的正确性。这也合乎麻利提倡的“小步推动，频繁验证”的准则，是升高项目风险最无效的办法。 （瀑布和麻利的不同拆分过程） 只有基于用户故事开发能力疾速交付和继续交付正如后面所说，咱们用一两个月甚至几个星期把第一个用户故事做进去并给用户体验和反馈，而不是大半年甚至一两年后在我的项目前期才把产品给用户体验，咱们更早、更快地交付并获取反馈，而一直反复这样的过程，就是继续交付的过程。在整个过程中，咱们都在交付业务价值，而不是战战兢兢地拿着一堆半成品面对那个死亡日期的迫近。 我的项目X最终出现给用户的是不同类型的基金报表，其实每一类报表就是一个用户故事。如果咱们一开始就以最重要的一类报表，作为首个用户故事进行开发，只须要两、三个月的工夫，咱们就能够把这个用户故事实现并交付给客户进行测试和反馈，有任何的反馈咱们都能够及时进行修改。失去客户认可后，咱们就能够如法实现其余报表。更重要的是，从第一个用户故事，也就是最早可测试产品取得的用户反馈将确保其余用户故事的开发也在正确的方向上。而在瀑布形式下，两个月后咱们才刚刚收到需要文档，什么开发都没有开始。 （尽早定义和交付最早可测试产品可及时获取用户反馈，确保产品正确） 因而，定义好用户故事是施行麻利的根底，没有这个根底，其余麻利实际的施行其实只是部分改善，仍然是战术上的改进，而不是策略上的扭转，久远来看，收效无限并容易倒退。麻利开发是一个有机体系，各种具体的方法论和实际须要打组合拳能力施展出其应有的效劳，基于用户故事开发是所有的根底： 如果不是基于用户故事开发，简略地把我的项目的长周期拆分成短周期并不是真正的迭代，因为每个周期都没有可体验、可交付的货色，仍然像瀑布一样在一直沉积半成品，这也不是真的Scrum；如果不是基于用户故事开发，测试驱动开发（TDD）和行为驱动开发（BDD）很难发展，因为不足具体用户场景的形容，很难写出具体、扼要的测试用例，因此很难累积足够的自动化测试进步零碎的可改性，外部品质、重构、继续优化便无从谈起；如果不是基于用户故事开发，继续集成（CI）也意义不大，因为提交的代码并没有形成可交付的产品，其实并没有真的在集成。既然用户故事是麻利开发的重中之重，那么如何定义好用户故事呢？诚然，这是麻利转型的难点。业界无关具体定义用户故事的说法并不多，这也是为什么用户故事始终被忽视，因为还没有标准答案，大家无从下手。《用户故事地图》是为数不多的较具体地论述用户故事定义方法的书籍。所谓用户故事地图就是从左至右按工夫程序列举用户行为（也就是流程的每一步），在每个用户行为下从上至下列举相应的细节，包含所须要的开发点，形成一个二维的“地图”。基于这个地图，还能够对每个开发点的业务价值进行扫视，找出最小可用产品（MVP）并制订公布打算。然而间接从整个我的项目或产品动手编制用户故事地图其实十分艰难。 （《用户故事地图》是为数不多的较具体地论述用户故事定义方法的书籍） 具体用户场景+用户故事地图则是我认为比拟可行的办法所谓具体用户场景，就是构想一个用户在应用某个性能的具体过程。比方咱们应用共享单车，具体的场景是用户找到一辆单车、用手机扫码和开锁、骑行、达到指标地、锁车、领取费用。这个场景的每一步，依照工夫程序从左到右列举进去，而后再合成每一步所须要的零碎或模块，在每个零碎或模块下从上到下列举所须要的细节，包含所须要开发点，便造成一个用户故事地图。如果这个场景依赖于其余场景，比方注册，那么就构想注册的场景及其用户故事地图。如果注册就是所有其余场景的前置条件，就优先开发它。 （场景+地图是一对好基友） 再举一个传统金融我的项目的例子。比方银行开户，其中一个典型场景就是具体某类客户通过某个渠道开某类账户的过程。在这个例子里，能够设想它会有很多个不同的场景，而每个场景都是一个交付。有了一个具体场景，咱们就能够剖析要实现这个场景，背地须要哪些零碎来撑持，每个零碎须要开发什么，造成一个用户故事地图。 当然，以开户为例，开发首选场景的过程会绝对较长，因为软件从无到有有打地基的过程，业务实现也须要各个系统的兼顾配合，但它并没有看起来那么艰难和漫长，因为： 因为一个具体场景绝对于整个我的项目要简略得多，相比传统形式下各个系统各顾各围绕所有性能进行开发，开发内容绝对简略很多，集成的难度也绝对低；首选场景的开发其实为其余开户场景打下了大量根底，其余场景的开发会绝对快和容易很多，交付会减速；能够采纳微服务架构、云服务、容器和像Spring Boot这样的疾速开发框架在技术上大大缩短了从搭地基到业务逻辑开发的前置工夫。我的项目X中，开发第一个用户故事的确会是开发周期最长的一个用户故事，然而因为它为其余用户故事打下了大量根底，它们的开发会大量重用第一个用户故事的代码，开发与交付会大大放慢。 基于场景更易了解和测试因为场景具体和绝对简单明了，不像传统需要的性能形容那么形象和割裂，它更容易解释、了解和测试，也是测试驱动开发（TDD）和行为驱动开发（BDD）的根底。 基于场景思考用户体验构想场景也是思考用户体验的过程，后面提到的更早和频繁获取的用户反馈也蕴含用户体验。 用户体验并不是互联网产品的专有名词，在传统的业务开发中，用户体验等同重要，只是它始终在瀑布开发中被忽视。 在我的项目X前期，离原定交付日期只有一个月了，客户提出在测试过程中发现，因为一个申请须要在不同零碎中解决，很难追踪，倡议减少一个对立的申请ID作为辨认。这时咱们有两个选项： 咱们的指标是依照打算把原定的所有报表按时交付，因而这是新的需要或需要变更，不应该在这个时候思考；咱们的指标是实现业务价值，客户在测试中发现的这个问题在上线后必然会被有限放大，不解决这个问题，用户体验和可用性极差，咱们应该优先解决这个问题。因为工夫无限，咱们要和客户沟通是否先集中精力测试某类报表，确保操作的用户体验和可用性，把一个月后的公布指标改为先上线这类报表，实现局部业务价值，其余报表在这次公布后再测试和上线。前者是瀑布的思维，后者是麻利的思维。而依照瀑布思维交付，就像咱们新装修完一间会议室，电视机、视频会议主机、电话都有，每个设施独自都能通电开启，然而电视机不能连贯视频会议主机进行视频会议，也不能连贯电脑进行演示，电话也没有设置好不能进行通话，也就是所有设施对用户来说其实都是不可用的。这样的交付有何意义？这几个需要哪怕只有一个能被满足，都比当初这种状况要好。 其实每个我的项目的需要或产品的设计，都是由一个个具体的场景形成的如果咱们和客户能从一开始就以场景作为切入点，咱们的眼里就不再是一个个孤立的性能，而是一个个有具体业务价值、可交付的用户故事，开发的过程便是这一个个业务价值的继续交付过程，这也是一个产品长期演进的过程，我的项目只是产品演进的一个个小插曲，软件开发中最不可控的因素——工夫对于客户来说也变得不那么敏感。在此基础上，再联合其余麻利方法论和实际，精益求精。 总 结传统瀑布开发是半成品沉积而且不足疾速反馈的过程，传统需要只思考性能而不思考场景和用户体验。麻利开发是基于用户故事的业务价值的继续交付过程。把我的项目拆分成用户故事是施行麻利的根底。具体用户场景+用户故事地图是定义好用户故事的一个具体方法。 作者：肯尼兹▪刘晚期麻利践行者起步于极限编程相熟极限编程、Scrum、看板办法、测试驱动开发、继续集成、行为驱动开发 【IDCF共创读书会】第2期汇报在【冬哥有话说】收费直播，关注公众号回复“共读”获取地址 12月9日（周四）晚8点，共读《继续交付2.0》

团队动静成长Tuckman模型 Forming团队理解并建设根本规定。只有模式上的单干，团队成员彼此被视为陌生人。 Storming团队开始沟通彼此的感触，但仍将本人视为独立的个体，而非团队的一部分。容易发生争执。对来自于管理者的管制示意出恶感 Norming团队把集体视为团队的一部分，并意识到承受、容纳别人的观点能够帮忙获得工作进展。在磨合中建设合作的范式/标准。 Performing团队在凋谢和信赖的气氛中工作。灵便度是要害。组织构造对团队的影响很小 团队不同阶段须要不同的领导格调 从自治理到自组织 何谓自组织？大量个体基于简略规定的相互作用，无需地方调控，可能涌现出整体上的新秩序。 如何实现团队的自组织？简略的团队约定规定，包含DoD等没有集体的失败，只有团队的失败团队独特对指标作出承诺，从实现目标取得成就感结对工作... ... 玩乐高，学麻利，规模化麻利联合作战沙盘之「乌托邦打算」，12月25-26日登陆深圳，将“多团队麻利协同”基因内化在研发流程中，为规模化晋升研发效力保驾护航！!⛴公众号回复“乌托邦”可加入

2021年11月11日，数智化效力平台猪齿鱼 Choerodon公布 V1.1版本，多项性能新增或优化，多管齐下，全面晋升团队工作效力！ 通过提供体系化方法论和合作、测试、DevOps及容器工具，猪齿鱼帮忙企业拉通需要、设计、开发、部署、测试和经营流程，贯通端到端全流程，助力团队效力更快更强更稳固，帮忙企业一站式进步管理效率和品质，推动数智化转型降级。 本次猪齿鱼 V1.1 版本在团队合作和DevOps方面新增和优化了多项性能： 全新上线的工作日历，使工作日程尽在把握，让工作安顿井井有条新增我的项目及组织的工时日历，便于团队和我的项目管理者更好地评估和治理工作量，为晋升团队效率添砖加瓦新增组织层甘特图，帮忙团队建设零碎思维，从而更好地治理和优化我的项目过程DevOps模块新增外接代码仓库，晋升仓库安全性，并在部署模块新增利用核心，反对集中查看和治理容器部署与主机部署后生成的所有利用与资源，使DevOps模块性能更弱小更易用猪齿鱼我的项目群、开发、测试等其它功能模块，也都进行了不同水平的批改和优化，欢送大家返回猪齿鱼官网申请收费试用。 加入猪齿鱼线上直播，马上get所有新性能！为帮忙您疾速理解本次新版本的新个性，并在我的项目中开始利用猪齿鱼产品晋升团队效力，咱们特邀请您加入《猪齿鱼V1.1新个性详解》线上直播。 直播工夫：2021年11月18日（周四） 19:30-21:00 直播地址：腾讯会议 ID460 991 254 主讲人： 程沛 资深业务架构师，猪齿鱼研发部专家组负责人 常壮 猪齿鱼研发总监，猪齿鱼产品研发创始人、研发部技术负责人 图：猪齿鱼V1.1新个性详解 猪齿鱼效力平台 V1.1 次要新个性1. 新增在线工作日历，反对Outlook、Google等本地日历订阅，疾速把握工作项安顿 猪齿鱼工作日历将集体工作项及不同我的项目工作项以工夫维度集中在一处，在在线日历中查看工作，使团队间可能疾速同步工作。工作日历更是我的项目工作项可视化的利器，使业务工作和我的项目合作变得更加通明可视化，高深莫测本人的日程安排。 图：猪齿鱼-工作日历 之前的版本中，猪齿鱼已提供相干性能，能够从待办列表、看板、故事地图或路线图等角度布局我的项目团队的整体打算，以及追踪我的项目的整体进度。本次猪齿鱼V1.1版本更进一步，可能从集体角度登程，聚焦用户集体每天各个时段须要实现的事件，其中包含参加的不同我的项目的工作项，以及在各个我的项目中“我经办的工作项”和“我参加的工作项”，帮忙您及时发现有工夫抵触的工作，进步工作效率。 图：猪齿鱼-查看工作日历工作 除了能够在猪齿鱼上查看工作项，您还能够将工作日历订阅到本地Outlook等日历利用中，更好地掌控工作工夫。 图：猪齿鱼-可将工作日历订阅到本地Outlook 2. 工时反对日历模式展现及日志查看，工作进度高深莫测 企业管理者对我的项目老本投入和理论利润产出日益关注，猪齿鱼工时日历帮忙企业管理者清晰精确地跟踪我的项目成员的工作工夫，追踪员工的闲置工夫及资源工作状况，管理者轻松把握团队的工作进度，核算精确的人力老本，实现精细化治理。本次版本在原有的工时注销性能还减少了工时日志性能，帮忙企业管理者查看对应工时的工作项。 图：猪齿鱼-工时日历 对于我的项目团队成员，为了防止遗记注销工时的状况，本次版本减少了每日工作揭示，帮忙团队成员跟进集体工作项。 3. 合作模块优化甘特图性能，帮忙管理者多角度评估我的项目 为了使甘特图更便于我的项目打算治理，本次版本的甘特图在原有的根底上新增了以下性能： 反对查看多个迭代的工作项，反对按冲刺视图查看，反对按史诗视图查看，从全局角度及多维度查看工作项进度反对自定义工作项程序，自定义列字段，针对工作项详情减少零碎字段“理论开始工夫”、“理论完结工夫”，便于管理者依据团队需要，自定义甘特图查看维度，疾速评估工作进度在猪齿鱼的组织层也减少了甘特图性能，并且显示资源抵触，帮忙管理者正当布局组织资源，进步组织团队的资源利用率 图：猪齿鱼-甘特图 4. DevOps局部新增及优化了开发、部署、测试性能，具体如下： 开发 应用服务模块新增反对创立应用服务时配置内部GitLab仓库，并且反对从GitLab-Group中批量迁徙代码仓库至Choerodon平台，保障更平安更稳固的仓库拜访流水线模块CD阶段新增反对容器部署与主机部署工作部署 为晋升产品继续交付能力，新增利用核心性能，集中查看和治理容器部署与主机部署后生成的所有利用与资源利用核心模块-主机利用详情，新增反对查看各种通用过程的详情新增反对疾速批量部署HZERO利用新增反对在主机中部署其余类型制品测试 笼罩功能测试及API测试性能，保障产品质量，用例库反对批量删除测试用例；测试计划导入用例反对依照用例优先级筛选API测试工作编排新增反对增加自定义脚本API测试工作新增反对多层目录分类管理API测试工作工作配置全局变量中新增反对增加变量形容以上就是猪齿鱼数智化效力平台V1.1版本次要性能，欢送拜访猪齿鱼官网申请收费试用。 本文由猪齿鱼技术团队原创，转载请注明出处：猪齿鱼官网 对于猪齿鱼 猪齿鱼Choerodon数智化效力平台，提供体系化方法论和合作、测试、DevOps及容器工具，帮忙企业拉通需要、设计、开发、部署、测试和经营流程，一站式进步管理效率和品质。从团队协同到DevOps工具链、从平台工具到体系化方法论，猪齿鱼全面满足协同治理与工程效率需要，贯通端到端全流程，助力团队效力更快更强更稳固，帮忙企业推动数智化转型降级。戳此处试用猪齿鱼

疫情之下的高速公路管控重任江苏高速公路信息工程有限公司（以下简称：江苏高速信息）成立于 2002 年，是江苏交通控股旗下，业余从事高速公路畛域机电系统集成、智能交通软硬件研发、大数据分析经营的高新技术企业，也是全省惟一一家同时具备高速公路智能化和楼宇智能化建设、革新与保护力量的科技型企业。自研软件蕴含高速公路治理的方方面面：免费零碎、监控零碎、车牌辨认治理、实时营运管理系统等。 自 2020 年疫情暴发以来，各地政府和人民大众对高速公路这一民生命根子的治理响应效率要求一直进步，以满足疫情突袭时能迅速启动防护和管控措施，同时对人民大众及时颁布高速公路防控治理规定，为出行服务提供精确的信息，江苏高速信息的「营运综合治理平台」肩负着这一智慧交通的重任。这对江苏高速信息的零碎建设迭代效率上提出了更高的要求：响应随时可能会产生的各种长期交通管控规定需要，及时上线相应的治理能力。 研发效率面临挑战在江苏省的智慧交通建设程度一直进步的同时，疫情重复一直也让江苏高速信息的研发团队组织治理形式和研发效率面临着重大挑战： 各小组职能间跨平台合作，多个工具间来回切换，合作效率有待晋升；零碎版本公布流程繁琐、耗时长，发版频率需进步；所应用的工具无奈满足缺点统计、需要完成率等相干报表输入，无奈评估研发投入及研发产出品质。一站式研发管理工具提效，实现组织麻利江苏高速信息在理解到 CODING 提倡的一站式理念后，决定将研发团队所有的工作都搬到 CODING 中闭环解决，让团队通过一个账号搞定所有工作。从组织上调整，解决合作效率问题，打造能适应麻利迭代的高效能研发团队，实现组织麻利，疾速响应业务需要。 CODING 指标治理，放弃团队指标一致性在布局各个系统的长期能力建设方向时，江苏高速信息外部每个产品职能团队须要高低放弃指标的通明，让业务、产品、技术团队朝着同一方向后退。应用 CODING 指标治理，江苏高速信息的 HRBP 和各产品部门总监一起开始组织并实际了 OKR 治理形式：月初设定指标 -->月末检视指标 --> 复盘和总结。在 OKR 的制订上，江苏高速信息团队认为，CODING OKR 是指标协调和沟通工具，而非绩效考核工具，并在填写过程中疏导团队成员正确填写指标： 能量化的肯定要量化；切实不能量化的，就要形容指标做到的水平以及可能带来的益处。 自定义团队工作流，需要进度实时共享遇到 CODING 前，江苏高速信息苦恼于没有一个好的需要管理工具来记录并治理产品需要，不利于产品需要的积淀和流转。应用 CODING 后，解决了日常工作中需要被脱漏的景象，同时也极大进步团队对需要流转、交互的流畅性，进步合作效率。尤其疫情期间遇到突发需要，产品需要的传播更须要精确且高效。 在 CODING 的帮忙下，江苏高速信息给团队内所有的岗位职能人员设计了正当的工作流，将开发、产品、测试等所有岗位人员的工作台都放到 CODING，每个人的指标是什么、做了什么、做到什么水平都能直观展现。 开发人员实现需要开发工作，关联对应的合并申请和代码版本同步给产品经理，任何意见和想法都在评论中积淀，避免信息断层和脱漏。管理者随时能看到我的项目最新进展，清晰理解每个打算的阻塞点和资源瓶颈，掌控项目风险点。即便面临疫情多变的突发状况，都能井井有条推动需要落地。 测试过程紧跟产品节奏，实现「质」的飞跃江苏高速信息的研发负责人示意，咱们心愿能看到每个迭代版本里的测试后果和最终反馈的缺点相干数据，用以评估我的项目的研发品质，但目前没有适合的统计工具，只能依赖手工统计，比拟耗时耗力。 对于江苏高速信息测试团队的苦恼，CODING 让测试管理工作「在线化」，不再依赖本地 Excel。不再须要每月苦等人工报告，关上 CODING 即可提供主动生成的测试报告，测试用例执行数、覆盖率、缺点状态散布数等等在一张报表中高深莫测。 另外，与大多数企业的测试流程不同，CODING 的测试治理理念提倡测试工程师作为麻利组织中重要的角色之一，应在产品需要阶段即染指理解原始的产品需要，开始测试用例的编写并纳入相应的迭代工作内容之中。这样防止在开发实现后测试再进入从头理解原始的产品需要，帮忙江苏高速信息大大缩短了测试周期。 自动化公布流程，实现研发麻利过来，江苏高速信息的开发、测试及部署环节均在本地自建工具实现： 本地自建 GitLab、装置 Jenkins 并应用 Ant 或 Maven 等工具构建、应用 Selenium 等工具进行测试...整个过程须要团队消耗大量的精力来对工具进行装置与日常保护，重大依赖本地环境，团队新共事须要付出高额的学习老本能力上手应用，团队常常为了解决不同工具间的连贯响应问题应接不暇，发版效率较低。 江苏高速信息将代码仓库迁徙至 CODING，而后配置了继续集成、制品库、继续部署自动化流水线的触发规定，依据不同我的项目的需要制订不同的触发流程，开发人员只须要专一于本人的业务代码，无需关注底层的工具连贯，开发实现即可主动触发构建、部署。发版效率也从以往的每月一次进步到每周发版，对于紧急的变更需要，更是能够做到半天内响应上线。 CODING 助力江苏高速信息实现团队「双敏能力」我国高速公路行业近 10 年来的规范化、信息化经营整体倒退迅速，江苏作为高速信息高速基建的软件提供商，在软件基建能力上也力争与时俱进，一直冲破现有阻力，通过应用 CODING 让研发流程和业务、治理全面在线化，让团队能具备‘研发麻利’和‘组织麻利’的双敏能力。 ...

作为麻利项目管理的开篇文章，还是先来简略地说一说为什么先从麻利开始，为什么是以 PMI-ACP 为参考。当然，这一系列的文章可能不可避免地会为 PMI-ACP 做一些广告，然而我想通知大家的是，麻利以及项目管理相干的内容要把握好，实际比实践重要，也比考试证书要重要的多。 从麻利开始的项目管理咱们先不说项目管理这回事，单说麻利这个单词，置信只有是互联网圈的从业者都不会生疏。不仅仅是麻利开发，也有麻利产品，麻利经营，甚至麻利的人事和行政。也能够说，万物皆可麻利。当然，麻利的外围其实还是在于针对传统项目管理的延长。 学过 PMP 的同学肯定分明，在 PMP 中，万物也是都能够当成是我的项目来治理的。只有你有一个打算、过程，最初要取得一个后果，那么这个事件就是一次我的项目过程。而麻利则是在传统的项目管理的根底上倒退起来的，并且更具备潮流性的一种项目管理形式。传统项目管理很重视打算，它有三大外围过程，别离是范畴、进度、老本，有一个外围支柱是品质。在前面的文章中，咱们会介绍传统项目管理的铁三角就是范畴、进度、老本。而麻利的铁三角，则和传统的项目管理有了很大的不同。在这里先卖一个关子，这个内容咱们前面再说。 对于古代的互联网企业来说，真正遵循纯麻利我的项目开发的公司其实并不多。这里的纯麻利指的是真正的完完全全的按麻利的形式来进行软件开发的企业。大部分企业尽管在一直地推广良好的麻利实际，但也不会齐全舍弃掉传统的项目管理中的内容。毕竟，纯麻利还是有很多要求和限度的，这个在未来的学习过程咱们也会看到。 当然，大部分的麻利实际都是不错的，置信不少读者的公司可能都曾经在用了，比方每日站会、评审会这些麻利会议，测试驱动开发、个性驱动开发这些开发流程，结对编程可能会比拟少见，但咱们的代码审计（Code Review）预计不少公司还是会执行的。另外小团队作战、迭代冲刺、用户故事这些名词想必也是大家耳熟能详的。 我的自媒体帐号下的粉丝大部分都是开发人员，对于下面的这些名词都不会生疏，反而是传统的 PMP 中的一些名词可能会更生疏一些。所以，从麻利开始，大家会更有趣味学习上来。 真正的起因好吧，下面说了一堆客套话，来说说从麻利开始写项目管理系列文章的真正起因。 PMP 马上要改版了，第7版据说变动很大。所以不筹备以第六版来写和录视频了。未来等第7版公布了一起再学习。 另外，【信息系统项目管理师】的考试内容还是第5版的内容。而我过后学习的也是第5版的内容。所以相干的传统项目管理的系列文章还是会写。不过会以信管师相干的学习系列文章来写。当然，做为 PMP 的参考资料也是齐全没有问题的。这个系列的文章就放到麻利之后去写了。 PMI-ACP不做广告，但多少也要介绍一下我考过的这个证。 和 PMP 一样，都是 PMI 的认证。国内上比拟通用，个别外企会比拟认。国内的话，大型的企业次要还是会以信管师和 PMP 的认证为主。录视频的时候会给大家看看我的证长什么样子，和 PMP 的区别就是字不一样，色彩也不一样而已。考试题目比 PMP 少，考试工夫也比 PMP 少一个小时。 另外，更重要的是它比 PMP 便宜，续证时要的 PDU 也少一些。PMP 我没有续证了，这个 PMI-ACP 证我也不太会思考持续续上来，次要就是太贵，而且对于咱们来说其实用途不是特地大。如果你是外企或者大型企业的专职项目经理，或者是立志要齐全投身项目管理行业的，那么还是十分值得考据和续证的。另外，最好的还是考一个咱们国家本人的 信息系统项目管理师 ，更便宜，而且不必续证，一生的。具体的内容在信管师相干的系列文章中再具体阐明。 总结明天就是一个简略的结尾，讲了一下咱们先写麻利系列的起因。没有什么其余重要的内容，但后续精彩内容可千万不要错过咯！ 参考文档： 《某培训机构教材》 《用户故事与麻利办法》 《高效通过PMI-ACP考试（第2版）》 《麻利项目管理与PMI-ACP应试指南》 各自媒体平台搜寻【硬核项目经理】

先从一个故事开始： 三周前接手了一个我的项目，一把手动摇反对并亲自推动，需要清晰明确且已文档化，单干各方已拉通指标且达成统一，三周后的明天，一把手换人了且指标须要修改，需要的内容和优先级须要颠覆重来，新退出了三个合作方各有各的诉求，治理复杂度迅速晋升…… 可能很多人，尤其是麻利我的项目管理者对上述场景并不生疏。 这个变动给我的项目带来的挑战是： 投入的工夫和资源节约了，如何挽回？变动带来不确定性，如何在治理中缩小危险？变动同时带来了治理的复杂度，作为管理者，如何迅速率领团队理清思路？对于管理者来讲，面临的考验是：打算突破了，不确定性产生了，然而还是要按时交付等同的工作内容。 宝洁公司（Procter & Gamble）首席运营官罗伯特·麦克唐纳（Robert McDonald）用一个军事术语形容了这个时代： “这是一个 VUCA 的世界。” VUCA 指的是不稳固(volatile)、不确定(uncertain)、简单(complex)、含糊(ambiguous)。”用一句话概括就是，咱们所处的这个时代，任何事件都在变动，随时都有扭转产生，即便是以拥抱变动著称的麻利团队，身处多变的环境，也须要一直优化治理，应答变动。而应答变动最强有力的伎俩之一便是进步团队效力。 丹·平克在《驱动力》一书里认为， 要打造一个高度参加和有积极性的团队需思考三个关键因素：首先，在整个团队内要有一种独特的使命感；其次，人们必须从他们的领导者那里取得受权，能够自主地工作来实现团队指标；最初，人们须要空间和机会去精通他们的畛域，而不是仅仅学习如何做到“刚好”。这里的高度参加和有积极性的团队便是高效能团队的特色，这几个关键因素反映到团队治理上，使命感是指标，自主工作是能源，精通所在的畛域是能力，所以，要施展高效能的状态，团队必须有指标，有能源，具备实现目标的能力。 指标指的是团队因何存在，团队打造的我的项目因何存在，不同的我的项目可能谋求不一样的指标，比方满足性能、效率晋升、减少用户数量、品质过硬、打造业界影响力、驳回实际新技术，等等，都可能是团队的指标或者团队阶段性的指标。能源指的是团队自主抉择何种形式工作，不是自上而下的命令，而是团队独特决定的后果，比方沟通形式、单干形式、流程工具等的抉择，是自组织团队抉择的治理形式。能力指的是做这件事件，团队能不能做得好，做得快，做得业余。 总结一下 指标是团队“想不想”，能源是团队“愿不愿”，能力是团队“能不能”，团队只有想做这件事件，被迫做这件事件，有能力做这件事件，团队能力施展高效能的状态。再来看看短少某个关键因素会呈现什么状况，假如团队有指标和能力，然而能源不强，此时团队被动做事，积极性不高，所以做起事件来便会效率低。假如团队有能源和能力，然而短少指标或者指标不清晰，则团队做起事件来因为不晓得哪个方向是对的，所以会走很多弯路，一直的颠覆重来，所以会节约多。假如团队有指标和能源，然而不具备能力，则团队没有产出或者产出的后果不能满足要求，所以会品质差。进一步证实了高效能团队必须同时具备指标、能源和能力三个关键因素。 那么麻利团队是如何治理团队指标、开掘团队能源、建设团队能力的呢？从四个方面进行剖析。 一、麻利团队的特点 - 为应答变动而生麻利的治理形式近年来之所以越来越受到欢送，是因为麻利一些实际和治理流动能很好的适应变动，有这样几个特点是麻利我的项目所特有的： 麻利我的项目的优先级随着阶段性打算的清晰一直调整，保障了资源的无效利用；麻利我的项目通过短周期的迭代打算代替长周期的我的项目打算，最大限度的保障疾速产出后果，验证后果；一旦有变动产生，可能在短周期的打算里疾速失去剖析和应答，升高了变动被滞延带来的危险；每个迭代自成闭环又一直优化，保障了产出后果的最优。简略总结一下，麻利团队不是缩小变动，而是将变动当成日常治理的一部分，和变动和平共处，适应性共生。 二、治理指标 - 清晰统一通明麻利我的项目一个很大的特点，就是治理通明，对于指标的治理尤其谋求透明化，在治理指标的时候，有如下四个准则： 指标清晰：清晰的我的项目指标是团队致力的方向，清晰的指标有利于资源的集中和领导优先级的调整；及时调整：因为不确定的存在，指标在治理的过程中须要及时调整，使其反映变动的影响和新的需要；了解统一：团队成员对指标了解统一，能有利于促成单干、防止抵触、缩小沟通老本和升高模糊性；可视化：可视化是指标的展现模式，能反映指标的实现水平，可视化的停顿状态对团队也是一种激励。总结一下，麻利团队为了对立团队致力的方向，在指标治理上必须做到清晰统一通明。 三、晋升能力 - 疾速应答不确定性带来的挑战传统的软件项目管理中，团队成员的能力和角色绑定，角色和特定的技能绑定，当我的项目中有新工作产生或者成员到职，团队依赖内部提供资源供应，期待的老本高，当项目管理过程中呈现瓶颈，则又会呈现资源期待工作，呈现节约，由角色定义的能力大大降低了团队单干的效率。 和传统的能力治理不同的是，麻利团队提倡由能力标签定义角色，基于团队指标定义所需的能力，团队成员依据本人所承当的工作抉择不同的能力标签，成员和能力标签多对多的关系，也就是说，同一个角色，可能抉择多个能力标签并相应的去建设几种能力，同一种能力能够在多个团队成员身上体现，这样设置的益处是，在关键时刻团队成员能够相互补位，倒退多样化的能力也有利于团队成员的职业倒退，互相合作和补位的形式能极大进步单干的效率，进而可能疾速应对外来的变动。 四、开掘团队能源 - 自组织团队治理形式抉择麻利我的项目的团队推崇自组织，自组织团队通常会自主抉择单干的流程、工具、纪律和文化。 流程是为了保障信息通明和团队合作的流程，比方自主决定开发流程、沟通流程、决策流程、会议流程等；工具指的是团队抉择的用来给我的项目带来效率晋升的工具和实际，比方工作跟踪管理工具，自动化测试工具，沟通管理工具，麻利实际流动等；纪律是团队作为整体为了更好的单干而达成对于奖惩的共识，有对于行为的、对于抵触的、对于合作的、对于违规操作的等等；文化是将团队凝聚在一起的价值观和行为准则，比方以客户为核心，拥抱新想法，奉献分享，价值共享等等。 总结一下：晋升效力是麻利团队为了应答变动带来的挑战而采取的无效伎俩，为了保障团队施展高效能，团队必须具备清晰统一通明的指标，必须开掘能源通过自组织的形式进行治理，必须建设多样化的能力实现工作。团队指标答复的是“要不要”，团队能源答复的是“想不想”，团队能力答复的是“能不能”，只有三个因素具备，团队才具备了高效能，而高效能答复的是团队做的“快不快”的问题。 钻研发现，踊跃的团队环境有助于缩小事变，升高团队成员的治理老本，与那些不在踊跃团队中的成员相比，该项老本降幅可达50%，因为高效能的团队具备一种实现更多工作，并能更快发现问题的个体智慧。 起源：Thoughtworks洞见 作者：陈庆敏 申明：文章取得作者受权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。 IDCF社区共创读书会 首期汇报，每周四晚8点，冬哥有话说收费直播，关注公众号回复“共读”获取直播地址 8月19日，共读《思考，快与慢》8月26日，共读《DevOps实际指南》9月2日，共读《麻利无敌之DevOps时代》

7月30-31日，IDCF主办的北京站（暨总第16期）DevOps黑客马拉松圆满结束。本次较量邀请到精益麻利翻新专家王立杰、DevOps畛域顶级大咖徐磊等老师负责领导教练。来自北京视高盛景、光大银行、开课吧、京东、中信银行、中国人寿、讯飞极智等7家企业的30余名参赛者组成4支战队，通过2天1夜的奋战，全副挑战胜利！ 36小时挑战，麻利驱动商业创意/产品翻新DevOps黑客马拉松是由IDCF独创的、学练赛一体的金牌训练营，模仿实在业务场景，帮忙成长型企业寻找第二增长曲线，率领参赛者体验端到端DevOps，在36个小时内经验7个模块，使用迷信的DevOps办法，从商业模式布局开始到我的项目路演完结，残缺经验一次商业翻新过程，现场公布一款翻新产品。较量过程中，将精益守业+麻利开发+DevOps流水线完满联合，至今已有数千人参加并统一五星举荐。 DevOps黑客马拉松7大模块包含： 模块一：学习端到端DevOps 5P框架，根本认知DevOps理念及办法； 模块二：商业模式翻新，通过商业模式画布，为我的项目设计一个性感的商业模式，寻找增长第二曲线； 模块三：产品性能布局，通过用户画像摸索标签及痛点，利用用户故事地图梳理产品外围性能，梳理产品愿景、定义产品外围价值，构建产品MVP原型； 模块四：制订产品迭代打算，学习把握迭代指标设计、工作拆解与认领等技巧，设立物理看板并筹备执行； 模块五：现场打造继续交付流水线，搭建开发环境与分支策略，搭建继续交付流水线，梳理微服务架构并实现第一个迭代MVP版本的线上交付；模块六：应用影响地图梳理产品冷启动布局； 模块七：讲演我的项目计划并演示产品Demo，各组PK决胜。 践行团队公约，在竞争中减速团队交融本期黑客马拉松的参赛选手来自不同的企业，现场组队同创商业翻新打算。在正式较量前，各小组制订团队公约，疾速交融团结一致，攻克艰难，用契约精力推动团队合作。 （回绝“天堂团队”，共书团队公约） 关注后果更看重过程，路演PK决出各项荣誉DevOps黑客马拉松挑战赛设置了最佳黑马团队、最佳流水线、最佳创意、最佳黑马精力、最佳演讲集体等多个奖项，奖项评比综合路演后果，在较量过程中，领导教练会依据各战队在每个环节的体现给予加分。 通过强烈角逐，各项大奖最终揭晓，值得一提的是，本次挑战赛总分第二名与第一名仅1票之差。 第二组 【太空梭SPACE SHIP】战队获得最佳黑马团队奖； 第四组【Zero】战队获得最佳流水线奖； 第三组【Sun Tech】战队获得最佳创意奖和最佳黑马精力奖； 第一组【北京黑八科技】战队，来自北京视高盛景公司的周岳，取得本次黑马的最佳演讲个人奖。 黑马史上“最认真回顾”较量完结后，组委会收集了每位参赛选手的学习感触，记录学习与较量过程中的心得和总结。本届参赛者除了精彩的比拼以外，还奉献了黑马史上“最认真回顾”。 （黑马史上“最认真回顾”） 在职业技能上失去的晋升： 通过DevOps黑客马拉松，把握了fork code、配置Jenkins、配置流水线、公布K8S等技术；了解了规模化麻利、故事地图、DevOps搭建、用户画像、站会、看板、团队分工等麻利办法；在团队治理上会通过团队公约的形式造成团队价值观；在执行事项的安顿上，强调以团队成员认领的形式推动，而不是简略的调配。较量过程中的开心与挑战： 会为了团队对DevOps有共识根底、团队拿到加分项拿到奖项而开心；会在剖析商业打算、平板撑持超过4分钟、博得较量的时候感到很冲动；在决定要做一款什么样的产品和要求1天写完PPT时感触到挑战；通过整场较量感触到了黑马精力是最大的播种。参加DevOps黑客马拉松带来的启发： 无效的单干分工可能带来显著的效率晋升，好的互助气氛可能保障最终后果的达成，在业余技术上须要一直学习新的办法，用新技术带动业务改革；只有将用户痛点梳理分明，将用户指标画像梳理清晰，在业务动作执行上能力聚焦，能力造成合力，课程中的用户故事地图和用户画像的办法带来很大晋升；好的产品不仅仅是好的技术，更须要有继续倒退的布局，能力做好版本划分，有序推动，不走弯路。将黑客马拉松的常识与技巧带回到工作中： 在工作拆解上，将对业务的共识细化成可操作的实际，围绕实际执行所需，来补充团队技能，晋升能力；将团队公约、最小MVP、需要场景化等团队治理和工作办法带入到理论团队中，让我的项目运行更加麻利高效；从新布局团队分工，利用DevOps与Docker对现有架构进行降级，专项推动用户画像我的项目，对用户有全面清晰的认知；把握到很多DevOps的工具，会将工具带回到理论业务中，用来晋升研发效力。 （参赛者“意犹未尽”的盆友圈） 更多精彩霎时 （路演PK太火爆，吃根冰棍降降温，还有来自场外小伙伴的爱心投喂） （围成圆桌聊聊天&“动静相宜”的小游戏） （黑马群里的“红包雨”） 有过DevOps黑客马拉松的人生，才算残缺守业是一件痛并高兴的事，在日常工作中，咱们经常从以后业务视角想问题，陷入业务壁垒与各种矛盾中，不能沉着地站在商业视角思考长期倒退。 一名合格的职场人，无论是产品、研发、测试、运维还是项目经理，想要成为独当一面的管理者，都要可能让本人冷静下来思考以后业务的现状、时机和挑战。 IDCF DevOps黑客马拉松，将一个我的项目守业过程拆解为7个要害模块，将简单的我的项目问题针对性解耦，每个环节系统性思考，找到业务的破局点，让每一个成熟的职场人，可能短暂地跳出以后的业务视角，在守业气氛中从新思考，找到团队疾速倒退的第二增长曲线。 9月11-12日，上海站，11月20-21日，深圳站，企业组队参赛&集体参赛均可，一年等一回，错过等一年，连忙上车~公众号回复“黑马”退出

一、什么是麻利测试？麻利测试是遵循麻利软件开发准则的软件测试实际。麻利测试波及跨职能麻利团队的所有成员，测试人员提供专门的专业知识，以确保以可继续的速度频繁地交付客户所冀望的业务价值。“需要实例化”用于捕捉冀望和不冀望行为的实例，并用来领导代码开发。（起源：麻利测试-维基百科） 我喜爱来自“Global App Testing”的对于麻利测试的定义：“麻利测试的理念是，和编码一样，测试是开发的一个要害局部。在麻利中，测试被间接集成到软件开发过程中，以便尽早、频繁地发现bug。因而，测试人员能够在开发过程的每一个节点上发现问题，从而使产品疾速走向公布。” 为了更深刻地理解麻利测试的概念，让咱们先回顾一下传统测试和麻利测试之间的区别。 二、传统测试 vs. 麻利测试首先，咱们须要理解传统软件开发办法和麻利软件开发办法的次要区别。传统的软件开发通常被称为瀑布式开发，被称为线性程序生命周期模型，而麻利是一种迭代的、增量的软件开发办法。 以下是传统测试和麻利测试的不同点： 传统测试麻利测试在软件开发完结时开始测试继续测试/和开发同时进行品质是测试人员的责任团队对品质负责有专门的测试人员或测试部门所有团队成员参加测试基于脚本进行测试摸索式测试有需要文档作为参考用户故事和用户需要作为参考攻破软件的思维开发出最好的软件的思维测试染指晚，对产品质量反馈晚测试更早的染指并提供继续反馈发现缺点预防缺点（起源：The differences Between Testing in Traditional and Agile Approaches - Medium.com） 三、麻利测试人员须要恪守的10项准则如上所述，在麻利开发中，测试是整个麻利团队的事件。咱们可能都晓得麻利团队中没有一个角色叫做Tester，所有团队成员都是开发人员。因而，当咱们应用术语“麻利测试人员”时，指的是次要流动与测试和质量保证相干的团队成员。 我对麻利测试人员的10条准则很感兴趣，这在《测试人员和麻利团队实用指南》一书中常常提到。它们源于麻利软件开发的宣言和准则，不仅对测试人员有用，而且对所有团队成员都有用。当初让咱们来摸索它们是什么。 3.1 提供继续的品质反馈麻利测试人员不仅继续进行测试，而且还定期向团队和客户提供有价值的品质反馈。这样能够帮忙Product owner和客户通过样品和测试来廓清需要。 测试人员还须要与团队严密单干，并在开发过程中提供品质反馈，以确保团队在业务逻辑和软件行为方面处于正确的轨道。 3.2 为客户交付价值这是最重要的一条准则，因为软件开发的最终目标，特地是麻利团队的最终目标是为客户交付最好的软件。 3.3 面对面交换正如麻利的第六条准则所说，“向开发团队传递信息和在开发团队外部传递信息的最无效办法是面对面交谈”。不仅让开发人员之间间接沟通，而且让客户间接与开发人员进行沟通，这会无效缩小凌乱和各环节的谬误。 3.4 具备勇气勇气是每个麻利团队成员必须具备的品质之一。麻利的测试人员须要勇气去承当任何工作来实现工作；敢于学习新技能，帮忙我的项目向前推动，确保软件品质；咱们还应该具备寻求帮忙的勇气，特地是当提供帮忙的人看起来很忙，压力很大时；咱们也须要勇气容许他人犯错误，因为这是惟一能吸取教训的办法。 3.5 放弃简略我的客户常常说“先简略一点”。我喜爱这样。作为测试人员，咱们须要与客户单干，使业务规定、测试用例和记录的bug尽可能简单明了。测试人员和团队面临的挑战不仅是提供尽可能简略的软件实现，而且还要采取简略的办法来确保软件满足客户的冀望。 不管怎样，咱们须要让事件尽可能简略。上面的名言激励咱们这样做： “简略就是终极的简单”（莱昂纳多·达·芬奇） 和“如果你不能简略地解释它，你就不可能很好地了解它”（阿尔伯特·爱因斯坦） 3.6 实际继续改良通过寻找工具，学习更多的技能让工作做得更好，并从客户投资中取得更好的回报，这是麻利团队的要害价值。作为麻利测试人员，咱们须要找到一种办法让反复的工作通过自动化来实现，这样咱们就有更多的工夫做更有价值的工作。 3.7 应答变动在很多状况下，团队从零开始开发一个新个性，信息很少，在开发过程中会有很多变动。作为麻利测试人员，咱们须要与团队单干来适应变动。 3.8 自组织麻利团队须要意识到，所有团队成员都负责测试和对软件品质负责。当团队呈现问题的时候，是每个人的问题。 3.9 关注人麻利团队的一个要害价值是建设一个每个人都有机会奉献和倒退技能的环境。测试人员须要学习更多的技能为团队奉献更多的价值。通过这样做，咱们将打消测试是低技能工作或测试人员是二等公民的错误想法。麻利团队的所有成员都是等同重要的。 3.10 享受工作你有没有问过本人这样的问题：是什么让你喜爱软件研发工作？对我来说，与团队一起交付软件，帮忙用户更好地实现工作，为客户带来价值，这让我很快乐。在麻利开发中，咱们能够通过本人的想法和技能为团队发明价值。 四、论断在我看来，麻利哲学使所有团队成员都可能奉献本人的价值，为客户提供最好的软件。我置信，作为测试人员，如果咱们可能实际以上10项麻利测试准则，并且渴望通过每天学习更多的技能让本人一直成长，咱们就能为团队发明更多的价值。 起源：软件品质报道 作者：Test Ninja 本文翻译自 Agile Testing Principles For Testers and Agile Software Development Team (enlabsoftware.com)，介绍了什么是麻利测试，麻利测试与传统测试的区别，以及测试人员应该实际和恪守的10项麻利测试准则。 申明：文章取得作者受权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。 7月每周四晚8点，【冬哥有话说】研发效力工具专场，公众号留言“效力”可获取地址，留言“回放”获取回放地址 ...

自汉得发表开源以来，Choerodon猪齿鱼已被上千个组织所应用，帮忙企业实现软件的生命周期治理，从而更快、更频繁地交付更稳固的软件。通过一千一百多天的奋战，2021年06月30日，Choerodon猪齿鱼迎来了1.0后行版正式公布，标记着Choerodon猪齿鱼走向的成熟和稳固，欢送各位降级体验。 公布版本：1.0公布工夫：2021年06月30日更新范畴：全局版本范畴：开源版、商业版本文次要内容包含： 1.0版本的重大调整Choerodon1.0开源版更新阐明Choerodon1.0商业版更新阐明1.0版本的重大调整应用开源组件库Choerodon UI 1.4.0 新主题-风铃紫Choerodon UI开源组件库（缩写 C7N UI），领有开箱即用的高质量 React 组件，全链路开发和设计工具体系，帮忙企业级中后盾产品晋升开发效率。自V 0.1.0就开始撑持Choerodon猪齿鱼的前端组件，并在2021年2月4日公布稳固开发正式版 V 1.0，反对平滑降级，目前除了Choerodon猪齿鱼还撑持着HZERO、飞搭等产品的前端组件。 C7N UI信息如下： 官网：https://open-hand.github.io/choerodon-ui/zhGitHub：https://github.com/open-hand/choerodon-uiGitee：https://gitee.com/open-hand/choerodon-uiChoerodon猪齿鱼1.0版本全面应用C7N UI 最新版本1.4.0的新主题风铃紫。 Choerodon官网迁徙至汉得焱牛开放平台汉得焱牛开放平台致力于升高技术中台交付老本和准入门槛，为内外部用户提供更高效、更便捷的一站式服务平台。 Choerodon主页介绍了产品劣势、产品性能、解决方案、客户案例等信息，并比照了Choerodon猪齿鱼不同版本的性能差别，包含开源版、商业版、SaaS。 Choerodon主页：https://open.hand-china.com/open-source/choerodon 汉得焱牛开放平台-文档核心集成了汉得自主研发产品的相干文档，致力于打造成汉得的“百科全书”，更集中、更便捷、更对立的满足用户的浏览和查问。 Choerodon文档将开源版、商业版、SaaS版各版本的文档迁徙至文档核心，提供多样化的服务反对。 Choerodon文档：https://open.hand-china.com/document-center/doc/product/10003/10274?doc_id=39943&doc_code=1723 Choerodon猪齿鱼1.0开源版更新阐明麻利合作新增性能减少输出提醒；子工作反对问题类型转换； 减少每人每日工作量图表；减少集体工作量统计；所有问题反对自定义列表字段显示、程序以及列宽度；新增复制问题时反对字段可选复制；新增疾速创立问题时反对抉择经办人； 我的项目报告减少一键折叠；问题详情新增反对疾速创立缺点；新增公布版本性能，治理版本理论公布内容； 模块列表减少程序；问题详情新增显示测试进度；新增问题详情反对复制问题链接；兼容Safari浏览器；新增切换问题类型输出必填字段； 性能优化配置看板时反对切换看板；优化问题详情关联问题；优化挪动问题卡慢的问题；优化评论问题默认倒序显示；疾速创立必填项提醒优化；优化疾速创立子工作后主动关上详情；优化问题详情更多按钮程序；优化问题评论发送音讯；优化状态机页面；优化工夫显示格局；优化自定义问题类型值集过多时加载迟缓；优化问题详情附件展现模式； 缺点修复修复UI/UX文件上传后无奈预览的问题；修复甘特图左右挪动工夫周期边长的问题；修复状态自定义排序偶发乱序的问题； 常识治理性能优化优化创立文档能够抉择创立到根目录； 缺点修复修复知识库文档多层级创立时，目录无奈左右滚动；修复知识库全屏切换/退出失落编辑内容； 代码开发新增性能代码治理-分支治理中，新增分支合并触发关联问题状态变更；代码治理-分支治理中，反对开发人员在此关联同组织下其余我的项目的麻利问题；代码治理-分支治理页面新增1个分支反对增加多个麻利问题的性能；代码库治理-权限审批模块，新增批量审批的性能；CI流程中Docker构建步骤中新增镜像平安扫描卡点的性能，反对为镜像扫描增加门禁限度； 环境部署缺点修复修复了部署记录页面中，偶现失落批量部署的记录的问题；修复了CD阶段的工作准确匹配/排除抉择的触发分支显示谬误的问题；修复了主机部署的错误信息和工作失败信息未展现的问题； 测试治理新增性能新增测试执行状态变更触发问题状态变更；测试执行反对定位所属文件夹；测试执行执行按文件夹批量调配打算执行人；打算新增关联版本、冲刺；性能优化优化测试计划进度展现；创立用例时反对输出自定义编号；优化用例自定义编号规定；根底性能菜单界面调整将我的项目汇总在顶部，不便查看； 将合作拆分为合作、文档两局部，并对页面菜单层级做了调整； 将设置中的菜单做了层级调整； 新增性能站内信模块新增反对以左侧弹框的模式展现； 性能优化自定义角色中，将部署-资源菜单下的性能权限细化； 缺点修复修复了我的项目成员分页查问部署配置报错的问题；修复了oauth重置明码长度校验异样的问题；修复了同步ldap定时工作时，偶现停用的问题； 装置或降级装置文档：https://open.hand-china.com/publish-center/product/product-detail/10003/version/10426/document?docVersion=1.0&doc_id=125697&doc_code=1734 降级文档：https://open.hand-china.com/publish-center/product/product-detail/10003/version/10426/document?docVersion=1.0&doc_id=126701&doc_code=121227 Choerodon猪齿鱼1.0商业版更新阐明商业版除了对开源版功能模块做了降级，还对以下模块做了不同水平的新增、批改和优化。 需要治理贯通着产品的整个生命周期，包含我的项目外部及内部用户的需要收集、需要审核、剖析、拆解及开发进度的跟进。 新增性能需要审核减少创立需要；需要审核反对导出需要；导出需要减少形容字段；需要池反对自定义列表字段显示、程序以及列宽度；需要池反对导入需要； 缺点修复修复我的项目成员不能星标需要的问题； 规模化麻利以企业级的大规模麻利框架SAFe为根底，对多我的项目并行开发、多团队业务需要整顿及产品开发路线图等进行治理，帮忙团队进步协作性，升高团队治理的复杂性。 新增性能版本关联新增与devops联动；路线图反对自定义列表字段显示、程序以及列宽度； 性能优化优化PI指标关联个性可抉择是否暗藏已关联个性； 缺点修复修复迭代日历工夫范畴不能抉择1年的问题；修复ART设置跳转到子项目报错的问题； 自动化测试包含接口测试、性能测试、流量回归测试、UI测试，贯通项目管理、麻利开发DevOps全流程，提供麻利化的继续测试工具，进步团队测试效率，保证质量。 新增性能性能测试-执行性能测试，新增反对为每次执行增加执行备注；性能测试-执行性能测试，新增反对为每次性能测试执行设置继续时长；性能测试-执行性能测试，新增反对永远循环执行选中的测试工作；性能测试模块新增反对手动进行正在执行中的性能测试； 性能优化API测试工作开启定时设置后，加上【定时】的标签；树结构中也加上筛选； 缺点修复修复了用例库-创立/批改API测试用例时，点击【保留并执行】，跳转至记录界面后，弹框未收起的问题； 品质治理通过报表以图形化的形式直观的展现我的项目下利用代码品质数据，便于直观展现以后我的项目的总体代码品质及每个利用的代码品质，以供团队治理参考。 新增性能单表预览脚本；表设计字段新增unsigned、time、blob、longblob类型反对；表设计增加数据库类型、字段类型大小写、团队邮箱配置；表模块可变更、模块编码可批改、可迁徙模块表到其它模块；期初数据导入增加操作选项，反对新建、更新、删除、重置选项；新增主动提交、降级表设计性能；增加PostgreSQL数据库反对；克隆表构造；表设计，表构造字段程序可批改、可插入字段；批量提交表； 性能优化表构造页面，备注字段宽度调整优化；生成DDD模型代码，过期注解替换；公布操作改为提交；字段默认值增加EMPTY_STRING（空字符串）反对；不同模块可反对同名表；索引列可在索引列表展现；关联关系辨别版本；弹性域字段创立可定制化； 利用市场Choerodon利用市场是平台内应用服务组件与罕用中间件的管理中心，反对平台下所有我的项目间接部署便可应用。 新增性能利用市场中，默认预置MySQL的配置与信息；根底组件部署中，反对部署人员对MySQL进行主机部署与容器部署； 社区参加感激以下敌人在社区论坛中提出反馈和意见，在1.0版本更新中作出贡献，感激大家始终以来的反对。 更加具体的内容，请参阅Release Notes和官网用户手册。 欢送各位朋友通过Choerodon的GitHub和猪齿鱼社区进行反馈与奉献，帮忙Choerodon猪齿鱼一直成长。Choerodon会继续优化，敬请期待。 -▼- 大家也能够通过以下社区路径理解猪齿鱼的最新动静、产品个性，以及参加社区奉献： 官网：https://open.hand-china.com/o...论坛：https://openforum.hand-china....Github：https://github.com/open-hand/...Choerodon猪齿鱼官网社区用户交换群，此群可交换猪齿鱼应用心得、Docker、微服务、K8S、麻利治理等相干实践实际心得，群同步更新版本更新等信息，大家能够加群探讨交换。 ...

一、什么是“文档”在剖析麻利开发中的文档之前，咱们要先搞清楚什么是“文档”。 维基百科给出的解释是： 具备三个根本属性，即：知识性、记录性、物质性，它具备存贮常识、传递和交流信息的性能。从这个定义咱们能够晓得：“文档”能够了解为所有能够存贮常识、促成沟通、传递信息的无形或有形的材料。 弄清楚“文档”的概念后，咱们就能够持续剖析麻利开发中的文档了。 二、麻利文档≠不写文档很多团队在看到麻利宣言的这句话当前： 工作的软件高于具体的文档都会产生一个问题：既然软件比文档重要，那麻利开发是不是能够不写文档了？ 在这里咱们就假如在软件开发过程中是能够不写任何文档的，那咱们日常的工作场景可能会是这样的： 迭代打算会的时候，没有任何书面的Backlog，PO把需要跟大家口述一遍，而后就间接开始开发；迭代的过程中，没有设计图，没有接口文档，没有测试用例，没有bug记录……；每日站会的时候没有看板，每个人都在口述本人昨天做了啥、明天要做啥，然而没人能分明地晓得总共要做多少性能，做了多少性能，还剩多少性能；需要的改变全靠口头告诉，销假或未出席会议的人全凭猜；PO对故事进行验收的时候，因为没有可视化的文档，导致开发团队做的货色基本不是他想要的，不停地返工；评审会上，因为bug太多，新性能演示频频翻车，客户不欢而散；回顾会上，SM发现没有任何主观数据可供回顾的，于是大家轻易聊点不疼不痒的话题，散会；我的项目勉强上线，没有用户手册，没有运维文档，无人会应用，没人能保护；我的项目卒。看完下面的形容，有些场景是不是似成相识？大家是不是感觉有些文档还是很有必要的？ 写很多具体的文档不适合，然而齐全不写文档更不适合！ 文档不仅能够让咱们开发过程中的沟通更顺畅、进度更通明、变更可追踪、bug有记录，还能够让咱们交付的产品更便于保护、应用和批改，能够无效缩短产品的寿命。能够毫不夸大的说，文档就是产品的一部分！ 那既然文档如此重要，咱们在麻利开发中要写多少文档呢？ 三、麻利文档＝发明价值的文档之前我始终纠结于麻利开发到底要写多少文档的问题，起初我在第N次浏览《Scrum指南》的时候，看到了Scrum的定义： Scrum 是一个轻量的框架，它通过提供针对简单问题的自适应解决方案来帮忙人们、团队和组织发明价值。——《Scrum Guide 2020》最新版的Scrum指南将Scrum的目标从“最高价值的产品”改成了“发明价值”，从上一节的形容咱们晓得，文档是麻利开发的一部分，那咱们在麻利开发中写的文档有没有在“发明价值”呢？ 咱们通过文档所播种的价值，可能跟图1相似：现实状况下，在没有任何文档的时候，写得越多（收入），播种就越多（支出），咱们所取得的价值（利润）也越高（利润=支出-收入）。 然而超过某个价值最高点，咱们再写更多的文档（追加投资），可能就不再产生显著的收益了（追加投资产生的支出<追加的投资），也就是咱们撰写的新文档曾经不能“发明价值”了，这时咱们取得的价值总额开始降落。此时再持续写下去的话，最终会达到收支平衡点，这时咱们所交付的全副文档，曾经不产生任何价值了，即咱们通过写文档所取得的支出，曾经跟咱们的收入一样多了。 如果一份文档曾经处于价值最高点了（或者曾经越过价值最高点了），再写更多的文档就不能再“发明价值”了，这显然是一种节约，一份文档一旦曾经实现了它的预期指标，再对它做再多的投资只会是画龙点睛。 咱们用产品文档来举个例子：咱们在布局一个新产品时，一份产品愿景文档是十分有必要的，因为它能够清晰的指明产品的定位及将来的倒退方向；如果咱们再依据这份产品愿景文档，整顿出一份用户故事地图，这也是非常有用的，因为它对于用户的画像、功能模块的划分、性能迭代的布局等都是很有帮忙的。然而如果咱们再进一步，依据用户故事地图写了一份具体的产品设计文档，文档包含了所有已知需要的详细描述、页面的原型设计、跳转逻辑、版本的公布日期及对应的性能列表等，这些工作就有点画龙点睛了，因为咱们当初只有一个待验证的产品愿景，咱们还不能确定产品的方向是否正确、用户画像是否精确、需要是否能满足最终客户的须要等，咱们这时候做的这么一份具体的设计文档，很可能是用不上的。即便咱们强行应用这份文档，前期的保护老本也会十分高，这份文档就属于不能“发明价值”的文档，它会导致咱们交付文档的总价值升高。如果咱们在做完这份具体的产品设计文档当前，再分割一家出版社，将它编辑后印刷进去，这时候咱们通过这一系列的产品文档所播种的总价值（理论收益-投入老本），可能简直就是0了！ 当然下面这张图我画的有点理想化了，写文档就像摸索客户的需要一样，在达到最高价值之前，咱们可能会走很多弯路，写很多不必要的文档，不过为了便于阐明，我假如从一开始咱们就在写那些能“发明价值”的文档。 那咱们怎样才能保障本人少走弯路，确保始终在写发明价值的文档呢？ 四、怎么写出一份发明价值的麻利文档一份文档是否能够为产品发明价值，能够通过以下5W1H的形式来判断： 4.1 WHO-谁须要文档？咱们在做产品布局时，都会先做个用户画像，以确定咱们的产品服务于哪些客户，用户画像能够帮忙团队从“以性能为核心”转向“以用户为核心”做产品设计。 咱们写文档的时候也是一样，在决定要写一份文档之前，咱们要首先思考到文档的使用者是谁？是客户、是用户、是产品人员、是开发人员还是公司领导？角色不同，对文档的需要可能也会不同，所以咱们只有首先确定了文档的使用者，才有可能写出满足客户须要的、发明价值的文档。 这里有个概念大家须要留神一下：咱们要确认的是文档的“使用者”，而不是“提出者”。这两者有什么区别呢？置信大家都听过一句话：“你妈感觉你冷”，文档的提出者就能够类比为妈妈，而文档的使用者能够类比为孩子——孩子冷不冷，只有孩子本人才晓得。 4.2 WHAT-须要什么文档？当有人跟你提出须要文档时，肯定是因为他的某些需要没有失去满足，那咱们须要提供什么样的文档能力满足客户的需要呢？这里记住4个准则。 首先，你提供的文档要抓住客户的痛点，否则客户必定会一直的要求你提供更多的文档。其次，要客户十分具体地形容他对文档的需要，肯定不能承受泛泛而谈的需要。比方客户说“我要一份产品文档”，这个“产品文档”就太泛了，然而如果说“我要一份产品的原型图”就具体多了。第三，要确定文档的载体，也就是具体模式，比方是word，是Axure源文件，还是HTML？最初，通知客户你制作文档所需的工作量，你在文档上投入的任何工夫，你本都能够用在新性能的开发上的，你必须让客户意识到这点，这样客户才不至于无止境的提文档的要求。一个举荐的做法是，把文档也当做是需要，排入到Backlog中，通过将文档视为需要，你能够将其工作量提供给利益相干方（可能不止文档的使用者）做参考，以此决定文档要不要写、写到什么水平。从根本上说，对文档的投资是一个商业决策，而不是技术决策：文档不应该为流程或规章制度而创立，文档应该为你的利益相关者而创立。 PS. 如果你所在的组织的确在为流程而写文档，这时能够关上《Scrum指南》，翻到“Scrum Master 以多种形式服务于组织”一节，通知Scrum Master，这正是他发挥作用的时刻！然而要留神一点，《Scrum指南》中只说了Scrum Master要服务于本人的组织，如果另一个组织对你所在的组织有不合理的要求，比方你作为乙方在为甲方做一个我的项目，甲方强制要求你在每个里程碑节点的时候都要提供一堆文档，这一点就超出Scrum Master的管制范畴了。 4.3 WHY-为什么须要？为什么要写这个文档？撰写文档必定是为了有所回报（发明价值）：可能是为了推销产品（用户手册、售后指南等），也有可能是为了升高沟通老本（产品原型文档、接口文档等），也有可能纯正是为了通过某个流程（比方你作为乙方为了通过甲方的验收）。但不论怎么样，在写任何类型的文档前都要先搞清楚其背地的起因：客户当初是如何做的、为什么须要新的文档、他们心愿如何应用新的文档、有了新的文档当前会有哪些收益等等。这里须要留神一点，不论客户的实在须要是什么，大多数状况下，咱们写文档的目标都是为了沟通，而沟通的次要目标是了解！晓得了这个逻辑当前，咱们可能就不会再醉心于欠缺的、精美的文档了，因为文档只是一个工具，沟通和了解才是目标！ 看完了后面3条：“Who-What-Why”，你有没有感觉这个构造有点相熟？没错，就是用户故事的3因素：As a 【role（Who）】, I want 【function（What）】, so that 【business value（Why）】. 用户故事通过这3个因素，就能保障做进去的性能是有价值的，那咱们要写的文档是不是也能够只通过这3个因素来判断有没有价值呢？ 用户故事只有3个因素就能把一个事件说的明确，是因为用户故事有几个隐含的条件：软件的解决方案是Scrum团队和利益相干方在Sprint打算会上个体探讨进去的（How），使用者是通过APP或web应用软件的（Where），软件中产生的事件都是在应用期间或预期工夫（比方闹钟）产生的（When）。然而麻利开发中的文档，是没有这些隐含条件的，所以咱们还是须要持续摸索5W1H中剩下的3个因素的。 4.4 HOW-怎么提供？上一节咱们聊到，咱们提供文档的目标是为了沟通和了解，为了更好的达到这个指标，咱们要怎么做呢？丛斌老师在他的《知行合一：实现价值驱动的麻利和精益开发》一书中给了一个沟通热度及其有效性的模型，如下图所示： 从上图能够看出，“有问题廓清环节”的沟通形式（邮件、电话、白板探讨等）在沟通热度和有效性方面都显著高于“无问题廓清环节”（录音、录像、纯文字等）的沟通形式，所以咱们应该优先选择“有问题廓清环节”的沟通形式，同时在沟通实现当前，依照客户的须要，及时整顿出适量的文档（比方电话的录音、白板的照片等）。然而是不是“无问题廓清环节”的沟通形式就一无是处了呢？也不肯定，在某些状况下，比方交换个体之间的间隔（无论是物理上的还是工夫上的）很大时，“无问题廓清环节”的沟通形式会是一个更好的抉择，这种沟通形式，就须要筹备大量的文字、语音或视频文档了。 4.5 WHEN-何时提供？麻利开发中需要治理常常采纳的策略是推延决策，创立麻利文档的工夫也遵循这个策略，咱们要尽可能的推延所有文档的创立工夫，如下图所示，只有在咱们理论须要的时候再去创立它们。例如，零碎概要文档最好是在一个版本的开发末期编写，因为只有在这时你才晓得你理论构建了什么。同样，大部分的经营反对文档也最好在我的项目生命周期的最初来写。然而，这并不意味着所有的文档都应该留到最初。团队应该在整个开发过程中为最初要交付的文档记录素材，这样你就不会失落要害信息。开发过程中记录的素材最好只是一些零散的信息，因为在最终交付之前，没必要对文档进行认真打磨。 在我的项目信息稳固后再撰写文档，你能够无效升高与文档相干的老本和危险：老本升高是因为你不会浪费时间去批改文档中曾经变动的信息；危险升高是因为你现有文档过期的可能性大大降低。如果你提前写完了文档，然而文档中蕴含的信息都还只是个布局，那么一旦信息发生变化，你就会面临批改文档甚至是从新编写文档的危险。换句话说，你不应该在我的项目晚期投入大量工夫来记录打算的想法，比方需要、设计等。相同，咱们最好等到我的项目的前期，等零碎曾经初具雏形，并确定好哪些信息对你真正有用的时候再去撰写文档。 这个实际的一种极其形式是等到你零碎上线后再写文档，这种形式的次要的长处是你写的都是已知的、稳固的内容（你曾经公布的软件）。不过这种做法有几个显著的毛病： 这时你很可能曾经遗记了某些决定背地的起因，如果这些起因对你很重要的话，这个问题会很重大。你可能没有适合的人再去写文档了，因为他们可能曾经转向其余我的项目了。你可能没有估算来做这项工作。编写文档的志愿可能不复存在。所以咱们应该尽可能的推延麻利文档的提供工夫，然而不要始终推延到我的项目完结了才写，同时咱们要在我的项目过程中时刻记录有用的素材。 4.6 WHERE-从哪里开始？后面说了这么多，很多人可能还是有一个纳闷，麻利文档到底应该要从哪开始写？尽管我在后面画了这么一张图： 然而这只是一个示例，我并不是倡议大家都依照“麻利开发方式”的示意来写。因为每个公司的我的项目类型、治理形式、规章制度可能都不一样，所以这一点是没法给出一个规范的实际办法的，我的倡议是从现状开始！可能有人看到这个答案就笑了：咱们当初就是在写一堆无用的文档，你让我从现状开始？ 这里我要解释下我所说的“现状”的含意：现状不是指你们当初在写哪些文档，而是你们当初在应用哪些文档。比方你们在日常的开发过程中始终在用设计图、接口文档等，并在整个我的项目过程中放弃更新，那么这是一个很好的迹象，阐明这些材料都是很有价值的我的项目信息，你应该围绕着这些信息来编写文档。对于那些没有放弃更新或更新当前也根本无人问津的文档，这些文档很可能就是在为了流程而写，再继续编写这类文档就没有任何价值了。 所以从现状开始的含意是：你能够从团队始终在应用的我的项目信息开始写文档，而后在麻利迭代的过程中，也继续一直的迭代你的文档。 五、小结如果麻利文档要用一句话来总结的话，那就是：在正确的工夫，找到正确的人，挖掘正确的需要，应用正确的办法，实现正确的文档！ ...

在过来的十年中，软件开发经验了许多阶段。从使流程麻利高效到应用DevOps简化IT服务，曾经有了许多冲破，MVP是对软件开发过程产生了根本性影响的提高之一。本文将深入探讨MVP在软件开发中怎么起作用、以及如何发挥作用。 什么是MVPMVP，Minimum Viable Product即最小化可行产品，是由Eric Ries 在《精益守业》里提出的一种软件开发办法。简略地说，就是指开发团队通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上继续疾速迭代，直到产品达到一个绝对稳固的阶段。它波及到后期开发我的项目的根本框架，并应用起码的性能和用例，以提前降低成本，辨认设计中的缺点，同时缩小上市工夫。 为什么要应用MVP开发？原始模式的软件开发是一个有缺点的过程，开发人员一度破费大量工夫和金钱，最初却发现了谬误和问题。因而，MVP开发有助于提前确定次要指标用户需要，最终确定技术堆栈和性能，以及确定价值主张。特地是对于那些有严格估算指导方针的组织来说，重点应该是利用最简略的技术堆栈开发一个有意义的性能列表。 以下步骤对于确定性能并确定其优先级至关重要。 掂量市场需求查看本人的软件在市场上提供的性能是否存在供给缺口。产品的需要能够基于满足消费者确切冀望的消费者反馈。为了确定需要，咱们须要剖析竞争对手及其在市场上的现有产品。 辨认产品的局限性通过开发，产品的局限有助于利益相关者为将来问题做好筹备，并施行适当的布局和代替计划。所有这些限度都带来了市场机会，这将带来无效的麻利开发和用以辨别市场现有产品的差异化。 跳出思维定势上面这些步骤会让你更靠近你的最终目标：为高级性能设置和应用构思确定我的项目范畴列出应用程序的性能和非性能个性执行线框图，而后再做想法原型 实现技术堆栈技术栈由一堆工具和技术组成，能够部署这些工具和技术来创立和公布产品。这些堆栈蕴含第三方、库、模块、包和工程工具，与所抉择的编程语言兼容。堆栈还必须满足交付相干方所冀望的业务价值的须要。 设计原型图一个前端技术栈以及框架，为开发人员提供了应用实现组件的能力，比应用程序的自定义解决方案部署更快。这些元素能够与思维的次要后端算法分割起来，从而失去一个可测量的MVP。这能够进一步与需要、正确的客户和客户反馈相匹配。 因而，必须制订初始路线图，并与适当的企业应用程序开发服务提供商创立危险登记册。 其实MVP的实质就是在做试验，每个MVP都能够帮忙答复一个针对某个假如的问题。之所以要尽可能的低成本去设计MVP，是因为MVP的实质是做试验，是试错，并不是在制作最终的产品，所以要尽可能用现有产品或者人工服务的形式来代替产品开发，尽可能地升高试错的老本。这也合乎麻利开发的“小步快跑、疾速迭代”，而二者关系能够用一句话说清：麻利开发是晓得“方向”验证“办法”，最小可行产品是晓得“办法”验证“方向”。

明天有一个风行的英文缩写词用来刻画这个风云变幻的时代：VUCA（乌卡时代）。四个英文字母别离示意动荡性（Volatility）、不确定性（Uncertainty）、复杂性（Complexity）和模糊性（Ambiguity）。企业的寿命、产品的生命周期、抢夺用户和行业更替的工夫窗口都在以前所未有的速度缩短。在这种场景下，企业迫切需要DevOps人才晋升研发效力。学习并晋升DevOps技能，能够为集体职业倒退关上一扇新的大门。 随着DevOps在越来越多研发团队落地，DevOps人才的缺口也越来越大，据调查，DevOps工程师的薪资程度也远高于其余角色。那么对于传统开发工程师来说，该如何把握DevOps继续交付的外围能力呢？ 资深麻利翻新专家王立杰老师提出端到端DevOps继续交付的5P法令，即： Philosophy：了解DevOps价值观Principle：了解DevOps十大准则Practice：把握端到端DevOps四大外围实际Platform：理解风行的DevOps工具与平台People：理解如何驱动DevOps组织变革为了帮忙更多心愿晋升产品研发效率的团队和集体，王立杰老师将5P法令的精华开发成一门训练营课程《IDCF 端到端DevOps继续交付（5P）工作坊》，除了帮忙学员理解和把握DevOps继续交付5P法令外，还率领学员理解把握DevOps核心理念及企业施行DevOps的必要性，并入手制订DevOps改革路线图。 工作坊以IDCF DevOps人才成长地图为索引，内容蕴含10个模块，全面笼罩要害角色技能，同时采取学练一体的训练形式，全程案例教学，角色扮演，辅以入手练习，将实践和实际无效联合，引入国内外多个实在产品案例，具备很强的实践性。 开课时间5月15-16日，2天， 线上课程，每天9:00—16:30（本训练营为ADCC认证前置要求课程，下拉到文末可间接报名，前30名报名享受五折优惠哦~） 面向对象各类 IT/软件企业和研发机构研发经理与总监、技术经理、测试经理、 项目经理、过程改良人员、运维人员、开发人员、测试人员，以及心愿疾速高效软件产品研发的团队和集体。 课程纲要模块1：DevOps历史简介DevOps诞生的偶然性及倒退过程从广义的D2O到端到端（E2E）的DevOps研发效力的要害定义与度量指标精益、麻利、DevOps的关系企业转型DevOps后的收益 模块2：DevOps价值观（Philosophy）BAT、PPT、PMP模型 模块3：DevOps十大准则 模块4：映射流水线 (Mapping Pipeline)翻硬币游戏：流动效率与利特尔法令为何要映射价值流？如何映射价值流DevOps转型画布 模块5：DevOps外围实际之继续摸索（CE）假如验证（精益守业、MVP、翻新核算等）协同钻研（设计思维、Lean UX、Gemba等）架构设计（云原生、微服务、康威定律、容器化、无服务器、可运维、平安、公布策略等）愿景整合（电梯演讲、实例化需要、WSJF等）模块6：DevOps外围实际之继续集成（CI）协同开发（版本控制、涌现式设计、遥测开发、结对、TDD等)继续构建（代码继续集成、骨干开发、门控提交、动态扫描等）继续测试（测试4象限、测试金字塔、契约测试、探索性测试、自动化测试、准生产验证等）继续平安（破绽扫描、利用平安、浸透测试、平安加固等）模块7：DevOps外围实际之继续部署（CD）环境部署（基础设施即代码、自动化部署、选择性部署、自服务部署、蓝绿部署、黑启动、个性开关等）环境验证（测试数据治理、功能性测试、非功能性测试、安全性测试、渗透性测试等）环境监控（全栈遥测、可视化展现、联结监控、AIOps、ChatOps等）环境复原（回滚/前向修复、会话回放、不可变基础设施、Game Day、混沌工程等）模块8：DevOps外围实际之按需公布（RoD）按需公布（黑启动、个性开关、灰度公布、金丝雀公布、A/B测试等）计划巩固（SRE、安全监控、劫难复原、LRR/HRR等）价值度量（翻新核算、遥测数据分析、先导指标、假如验证等）反馈学习（基于事实的改良、Go See、解决问题的文化、优化整体等）模块9：发动DevOps转型填充转型画布，确定转型要害事项基于加权最短作业优先（WSJF）算法排定转型事项优先级模块10：成为IDCF DevOps认证人士课程讲师 王立杰 资深麻利翻新专家，华为云MVP，曾任京东首席麻利翻新教练、IBM客户技术专家。PMI-ACP受权讲师、规模化麻利SAFe认证咨询师(SPC5)，北大光华治理学院/新华都商学院《守业机会剖析与辨认》课程特邀讲师，京东大学《京东翻新之路》、《从0到1的商业模式摸索》金牌讲师。 超过15年的研发治理、麻利转型、产品翻新领导教训，已经提供培训与征询的企业包含百度、京东、VMWare等互联网企业，中国移动、Agilent、IBM、阿朗、爱立信、诺基亚、东软等传统电信/IT/软件企业，招商银行、工商银行、中信银行等金融企业，E人E本、长虹、海尔等白电企业，海天修建、同方威视、中大医疗等传统行业；已经在“Scrum Gathering、 AgileChina麻利中国、麻利之旅/Agiletour、51CTO、MPD、品质竞争力大会/TiD”等大会做过屡次演讲，被评为品质竞争力大会/TiD 2014最受欢迎10大讲师；目前专一于企业麻利组织转型、研发效力晋升、企业产品翻新。 （王立杰老师的著/译作） 往期课程现场 《IDCF 端到端DevOps继续交付（5P）工作坊》将于5月15-16日开课，关注公众号回复“5P”理解详情及报名。

尽管你常常据说精益（Lean）和麻利（Agile），但对麻利和精益之间的关系是不是也常常感到困惑? 尽管这两种办法常常一起应用，但它们是两种十分不同的项目管理办法。 那么它们是什么呢? 精益与麻利办法又有何不同? 又有什么分割呢？ 一、 精益与麻利: 简史咱们将首先看到这两种办法是如何产生的，毕竟精益、麻利的差别就从起源开始就存在了。 1.1 麻利20世纪80年代，计算机程序员应用传统的开发方法，如瀑布办法来治理他们的软件开发我的项目。这一过程不仅耗时，而且老本昂扬。 然而，软件开发的世界正在迅速倒退，而成长通常意味着适应变动。在瀑布模式中，一个产品的开发可能须要几个月，有时甚至几年的工夫。因而，当软件或产品公布时，就以后的需要而言，它很可能曾经过期了。 为了克服这个问题，麻利宣言应运而生。麻利方法论是建设在麻利宣言中列出的4个价值观和12个准则之上的。麻利通过让涉众参加整个过程来帮忙团队更好地适应变动。通过这种形式，能够更好地布局、开发和部署工作软件。 麻利是一种疾速迭代的软件开发办法，与传统的项目管理办法不同，在麻利办法中，一个大型项目被合成为更短的开发周期，即sprint。每次冲刺通常继续2-4周。上面通过一个例子来阐明麻利准则。 假如你正在建造一个机器人。像Waterfall这样的传统项目管理办法中，你可能须要破费几个月或一年的工夫来打算和开发机器人，而后能力最终部署它。这可能会导致你认为很酷的AI性能变成无用的状况。顾客真正想要的是一个具备完满均衡能力的机器人。 而应用麻利办法，这是能够防止的。在麻利办法中，客户踊跃地参加开发过程。在每个sprint完结时，他们会提供反馈，而麻利团队会在下一个周期中实现必要的扭转。这种继续的改良为谬误留下了更少的空间，更有利于构建一个完满地满足客户需要的机器人。 1.2 精益20世纪70年代，大野耐一(Taiichi Ohno)开发了一种被称为丰田式生产零碎(TPS)。它的指标是通过打消任何类型的节约来降低库存老本和进步汽车供应链的效率。 TPS的灵感来自于杂货店的库存管理系统，当须要物品时，应用视觉信号精确地批示库存需要。这缩小了总体节约，优化了整个生产过程。而后，该零碎就缓缓造成精益制作准则。 然而精益软件开发是如何发挥作用的呢? Mary和Tom Poppendiek受精益制作准则的启发，写了一份全面的软件开发指南。精益软件开发是基于精益方法论的准则，这七项准则是: 打消节约内建品质创立常识推延决策疾速交付尊重人整体优化每一个精益准则都旨在通过打消节约来优化生产过程。它还试图在最大化客户价值的同时最小化危险。打消节约指的是去除所有不能减少过程价值的货色。这可能是任何事件，从不必要的会议和文档到效率低下的办法。 二、麻利与精益之间的6个要害区别既然你曾经晓得麻利办法和精益办法包含什么，你曾经感觉到它们是不同的，对吗? 为了让事件更分明，这里列出麻利和精益的六大要害区别。 2.1 方法论上的差别这是麻利办法和精益思维之间最显著的区别。 麻利开发器重继续改良和取悦客户，着力于我的项目开发过程的优化。它的指标是使过程灵便、通明和适应性强。为此，麻利我的项目会经验迭代开发周期(sprint)，麻利团队会从头到尾踊跃地让客户参加进来。 精益办法的外围是优化生产过程。这都是对于最小化危险和打消节约(精益生产)。事实上，“打消节约”是精益办法的首要准则之一。当你排除了所有与我的项目最终后果无关的货色时，制作过程就会主动缩短并变得高效。从久远来看，这会为你节俭大量贵重的金钱和工夫。 2.2 办法上的差别只管精益和麻利办法都是优良的软件开发办法，但它们的开发方法略有不同： 在麻利实际中，我的项目是在小增量、短周期或sprint中开发的。迭代和增量办法指的是将我的项目合成为不同的阶段，每个阶段由打算、实现、测试和评估组成。这个过程一直反复，直到达到你想要的后果。 精益办法旨在在生产过程中引入渺小的增量变动以提高效率。尽管这会导致更短的开发周期，但这并不是精益的外围关注点。 2.3 我的项目时间轴的差别只管精益和麻利办法的指标都是尽早交付产品，但它们的我的项目时间表是不同的。 麻利或Scrum团队的工作周期很短，以疾速交付。每个周期或冲刺通常继续2-4周，有固定的迭代周期。 精益团队通过优化流程来缩短我的项目工夫，通常限度在过程中的工作，这缩小了整个我的项目的时间表。然而，与麻利不同的是，没有特定的工夫框架。 2.4 团队中的差别精益和麻利办法遵循不同的团队构造。 麻利团队是由自组织的、跨职能的集体组成的小团队。 自组织: 团队决定如何本人实现工作。跨职能: 团队成员有不同的业余畛域，但都朝着一个独特的指标致力。团队成员包含产品经理(产品负责人)、麻利教练或ScrumMaster、开发人员、业务分析师等。在精益项目管理中，你要组建多个精益团队，由相干部门的成员组成。每个团队由治理各自团队和集体我的项目的团队负责人领导。尽管你的精益团队成员应该是有能力的，但他们不肯定必须是自组织的和跨职能的。 2.5 总体目标的差别麻利精益开发方法努力实现不同的指标。 在麻利开发中，指标是创立合乎最终用户或涉众需要的货色。 对于精益开发，指标是打消任何不能为产品开发减少价值的过程。 2.6 关注畛域的差别麻利开发关注我的项目范畴和客户价值。在麻利软件开发中，软件产品的范畴是指它的个性和性能。客户价值的优先秩序是，在每个sprint完结时，你承受反馈并在下一个周期中实现扭转。精益软件开发是对于改良过程流和品质，重点是过程改良和品质(指标是零缺点)，这通常应用一种称为价值流映射的办法来实现。 什么是价值流映射? 价值流映射是一种用于将产品创立和交付给客户之间的一系列事件可视化的办法。 三、麻利与精益有什么相似之处？晓得为什么人们常常把麻利框架分组并精益生产吗? 这是因为两种办法都有独特的价值，比方疾速适应变动的能力。以下是精益、麻利的相似之处。 继续改良: 两种办法都关注于定期检查工作办法以寻求可能的改良。客户价值优先: 无论是麻利积极参与客户反馈，还是精益关注交付品质，都旨在为客户提供更多的价值。高效的时间表: 麻利办法在频繁的版本公布中部署产品，而在精益项目管理中，开发过程蕴含尽可能少的步骤。这两种办法都关注于放弃效率。继续的后果流: 通过将开发过程合成为多个局部，麻利一直地以增量的形式交付价值，而精益则一直地打消节约，从而产生价值。起源：软件品质报道 作者：Test Ninja 4月每周四晚8点，【冬哥有话说】DevOps之庖丁解牛，拆解DevOps的工具及具体实战。公众号留言“解牛”可获取地址 0401《数据库继续交付流水线分享与演示（Azure DevOps+Flyway）》0408《继续交付中的版本治理与基于Azure DevOps扩大框架的插件开发》工夫待定，本周四暂停一期《微服务，多团队合作中的API测试怎么做 - Pact契约测试》0422《BoatHouse端到端流水线展现》

Choerodon 猪齿鱼作为开源全价值链多云麻利合作平台，是基于开源技术Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益麻利、继续交付、容器环境、微服务、DevOps等能力来帮忙组织团队来实现软件的生命周期治理，从而更快、更频繁地交付更稳固的软件。 2021年04月15日，Choerodon猪齿鱼公布0.25版本，本次更新麻利中的问题项新增跨我的项目挪动、上传并预览UI/UX文件等性能，组织层新增状态机模板及看板模板性能；流水线中CI阶段新增镜像平安扫描工作等性能及图表；测试中反对导出测试报表等性能；其它功能模块也都进行了不同水平的新增、批改和优化，欢送各位更新体验。 公布版本：0.25公布工夫：2021年04月15日更新范畴：麻利合作、代码开发、环境部署、测试治理、制品库、根底性能上面就为大家带来具体的模块介绍。 麻利合作新增性能所有问题减少列表视图；问题项详情反对上传并预览UI/UX文件； 问题项反对评论及回复；问题项反对跨我的项目挪动； 我的项目报告反对我的项目品质图表；反对自定义问题类型； 反对启停用问题类型；零碎预约义字段反对保护默认值；页面配置的自定义字段控件减少人员多选控件；反对导入页面字段配置；模块反对自定义程序；状态机反对状态自定义程序；组织层减少状态机模板和看板模板； 工作台减少我经手的、我报告的；我的项目概览减少我的项目动静；导入导出问题反对保留罕用模板；反对问题延期告诉；反对冲刺延期告诉；麻利问题反对移除关联分支的性能； 性能优化优化富文本编辑器：反对插入表格； 上传附件反对分片上传；所有问题按状态筛选优化可按问题类型级联；优化导入导出按钮地位；迭代打算工作台模式融入我的项目概览；优化查找用户反对按用户名拼音搜寻；优化创立问题项时切换问题类型，概要、形容清空的问题； 缺点修复修复导出、发送我的项目报告因内容过长造成显示不全的问题；修复看板兼容Safari浏览器问题；修复待办事项快捷拖动issue数据不统一的问题；修复状态机初始状态设置自定义流转不失效的问题；修复导入问题自定义问题类型导入失败的问题；修复问题详情开发标签页存在两个more-vert按钮； 代码开发新增性能利用流水线-CI阶段-构建工作中，新增反对镜像平安扫描的性能； 流水线构建后果反对本地下载；流水线构建日志反对本地下载；DevOps报表中新增流水线触发次数图与流水线执行时长图； 环境部署新增性能PV治理中创立PV时新增反对增加Label的性能； 性能优化部署人员变更实例时，默认不再调整其中Pod数量，仅可通过资源-运行详情界面中的Pod控制器调整其数量； 测试治理新增性能测试用例减少自定义编号； 测试计划反对批量删除用例；测试报表反对导出PDF；工作台减少待我执行的用例； 性能优化优化测试计划批量指派；优化测试计划抉择用例模式； 缺点修复修复测试计划中创立缺点时关联问题抉择框错位的问题；修复测试计划中创立缺点时经办人显示乱码的问题； 制品库新增性能制品库-Docker仓库中新增镜像平安扫描的性能，反对显示出扫描后的后果详情； 缺点修复修复了制品界面上传jar包较大时，接口超时的问题； 根底性能新增性能组织层与我的项目层-导入用户，反对通过Excel批量导入自定义的角色；创立我的项目反对抉择多个我的项目类型，且反对批改已有我的项目的我的项目类型；工作台中加上集体代码提交的记录展现；自定义工作台与我的项目概览反对一键重置为默认的；我的项目设置-通用中反对批改我的项目类型； 缺点修复修复了我的项目列表-最近应用栏，未将应用服务依照应用的工夫进行倒序排序的问题；修复了组织层角色查问，自定义角色和预约义角色查问混同的问题； 社区参加感激以下敌人在社区论坛中提出反馈和意见，在0.25版本更新中作出贡献，感激大家始终以来的反对。 @kychen @MyHarper01 @Rmond 更加具体的内容，请参阅Release Notes和官网用户手册。 装置文档：http://choerodon.io/zh/docs/installation-configuration/steps/ 降级文档：https://choerodon.io/zh/docs/installation-configuration/update/0.24-to-0.25/ 欢送各位朋友通过Choerodon的GitHub和猪齿鱼社区进行反馈与奉献，帮忙Choerodon猪齿鱼一直成长。Choerodon会继续优化，敬请期待。 -▼- Choerodon猪齿鱼商业版0.25也做了同步更新，可通过汉得开放平台理解性能详情； 汉得开放平台：https://open.hand-china.com/market-home/detail/=R9X1123B5UbNWDY_CL_8tg===?from=myProduct 大家也能够通过以下社区路径理解猪齿鱼的最新动静、产品个性，以及参加社区奉献： 论坛：https://openforum.hand-china....Github：https://github.com/open-hand/...欢送退出Choerodon猪齿鱼社区，独特为企业数字化服务打造一个凋谢的生态平台。

可能搞垮团队的货色切实太多了，OKR就是其中一个。俗话说得好，只有致力搞，没有OKR搞不垮的团队。 老K在两年前就尝试过OKR，也踩过不少坑、交了学费，没有人比我更懂如何用OKR搞垮一个团队，总结了11个招式，招招致命，请审慎应用。 第1招 不充沛宣导OKROKR绝对于传统的MBO指标治理办法，就好比姚明和郭敬明，尽管都叫小明，但其实他们是两个不同的物种。 所以，想用OKR搞垮一个团队，就要一上来间接搞，别去宣导OKR有什么不同。最好就是搞得大家一头雾水，只有你是整栋办公楼最靓的仔。 改革嘛，总要有人当炮灰嘛，你不入天堂，难道让老板入天堂么？ 第2招 没有失去高层的反对不能说高层不懂OKR，只是高层更关注方向性的货色，较少关注执行层面，然而人家手里有权呀。 想要搞砸OKR，你就疏忽高层，千万别装孙子，因为你就是孙子。最好瞒着高层偷偷搞，给他们个惊喜，如果做不到，给个惊吓也是能够的。 其实，高层可能坐到那个地位，OKR的理念肯定是晓得的，只是不足一个富裕激情、又违心去背锅送死的傻子。 你的呈现令高层眼前一亮，因为傻子来了。 人总要有点万死不辞的精力：每天被气死一万次，也不辞职。就算失败了1000次，也要再致力24次，好凑个整数嘛。 第3招 没有OKR培训和导入OKR还须要培训吗？这么简略的工具，别羞辱大家的智商了。咱们都是受过九年制义务教育的，尽管你比他人牛逼，读了十年。 他人都不懂，就只有你懂，才显得你才高八斗呀。 他人都玩不转的时候，你架着七彩祥云进去力挽狂澜，连董事长都拍手说你不懂事：这么拉风的事件，当然要让领导来做了。 别怕，反正大部分自认为聪慧的人，就是这样作死的。 第4招 组织没有清晰的策略组织越没有策略越好，大家背对背猜拳，所有全靠瞎蒙。 不论你的OKR是自上而下，还是自下而上，没有清晰的策略，指标都没法对齐，酸爽吧？ 部门之间的工作也没法聚焦。工作不易，全靠演技，感不打动本人不要紧，打动老板就行了。 你想通过OKR把团队搞垮？就在没有清晰策略的时候推广OKR，让大家各自为政，没法聚焦指标，忙是忙了，到了最初没有产生价值。贻误战机，等着被对手干掉吧。 第5招 不辨别承诺型OKR和愿景型OKROKR类型不加以辨别，采纳一刀切的形式，让团队无从执行，离搞垮团队又进了一步。 OKR打分也要一刀切，实现了是应该的，完不成扣绩效，就这么简略粗犷无效。 团队的能量，超乎你的设想，有时候不对本人人狠一点，你都不晓得他还有把事件搞砸的本事。 第6招 Obj不定性谁说Obj肯定要定性，老子就定量，咱走的是写实路线。少整些扑朔迷离的货色，Obj全都量化。 谁说KR肯定要定量，我就整虚的，咱走工笔路线。你看那些抽象画，越看不懂，越值钱。 生存就是这样，你认为看透了它，可你就是玩不过它。 还不如不按常理出牌：搏一搏，村姑变嫩模。 兴许你只是前半生运气不好，别着急，还有后半生呢，因为后半生你就习惯了。 第7招 OKR都是自上而下OKR当然要自上而下，这样能力保障高层的相对权威。 老K每次给上司定OKR的时候，都会看似不经意地露出胸前的纹身，大家没有不遵从的。最近天冷了，纹身都露不进去，感觉大家没那么尊敬我了。 你认为OKR自下而上，就能调动员工的积极性？员工就是个执行机器，所以记得对员工好一点，别骂员工不动脑子，因为不动脑子的前提是，他首先得有个脑子。 第8招 不对齐OKR高低对齐、左右对齐，嫌不嫌烦啊？对齐干啥，把本人的事件做好不就行了，管那么多正事干嘛？ 反复造轮子又怎么了？做同样的事件有什么问题？反正是大公司，有的是资源能够节约，你操啥心？来吧，造作吧，反正有大把时光。 是不是很有情理的样子？ 那小公司怎么办？别问，问就是杠精。 第9招 不解决KR执行中的问题KR执行中的问题，要让上司本人解决，领导又不是保姆。 神枪手都是子弹喂进去的，只有在和平当中能力学会和平，让员工本人搞定吧。 领导就该红尘作伴，活得潇潇洒洒，策马奔流，共享人间热闹...... 如果员工遇到了问题，搞不定怎么办？ 明天解决不了的事件，别着急、别慌，因为今天你也解决不了。 第10招 没有规范统一的评分零碎OKR评分全靠拍脑袋，领导说行，不行也得行；领导说不行，再行也不行；明天行，不等于今天行；这次行，不等于始终都行。真TM太有哲理了。 评分就是一门玄虚，规定看情绪。 执行得好与坏，不仅团队不分明，连老板本人也不分明。 正好给竞争对手制作烟雾弹，没把对手弄死，先把本人弄死。 这招打完，搞垮团队的指标就实现90%了。 第11招 制订完就束之高阁最初一招：OKR制订实现，管理层就马放南山，去享受岁月静好、现世安稳，因为世间值得，剩下的交给工夫吧，工夫会给咱们答案。 千万别开什么周会、月会、复盘会。如果上了OKR还一堆麻烦事，那我上它干嘛？ 再说了，上OKR等死，不上OKR找死，横竖都是死，我还搞个毛啊。 来来来，喝完这杯还有三杯......那就这样吧...... 结 语许多老板自觉跟风，用先进的工具和理念把企业武装到牙齿，比方：ERP、中台、KPI、OKR......一拍脑袋，全副都要上。 一阵骚操作之后，还没等团队适应过去，又一杆子打死：不灵嘛，可恶的XXX，又被割韭菜了...... 所以说，收智商税是一门古老的生意。要害是，韭菜们不仅可恶，还不长忘性，这基因也太强大了。 你们这样子，有思考过镰刀的感触吗？一点技术含量都没有，割下去基本没有快感。 韭菜们，就不能尊重一下镰刀吗？人家只想做一把宁静的镰刀，怎么就这么难呢。 最初，如果你的团队正在应用OKR，请对照以上11条。如果中了5条以上，连忙跑路吧，团队大概率是要垮掉了。 起源：技术领导力 作者：Mr.K ...

瞎话说我算不上是一个特地爱看书的人，我的看书效率也不算高，然而这么多年下来也看了一些麻利相干的书籍，整顿一下或者你也须要。以下排名不分先后想到哪本就写哪本。 1《凤凰我的项目：一个IT运维的传奇故事》 对读者来说最艰难的可能就是如何能静下心来保持每天看书，如何让本人能看得进去很要害，否则嘴上读着文字，思路早已飞走，所以举荐的第一本书就是凤凰我的项目，我读这本书的时候是几年前了，过后读的出发点是想理解下DevOps，因为晓得本人看书效率不高所以找了这本以小说模式写的书，尽管在过后读过之后也没有很了解到底DevOps的概念是什么，然而的确外面很多内容还是感触颇深。 2《麻利无敌之DevOps时代》 说到小说模式的书，那这本《麻利无敌之DevOps时代》就不得不提了，这本书是姚冬、王立杰、许舟平几位老师合著的，在20年这本书能够说是十分火爆的，过后本人买了一套，后续还通过各种流动拿了两套，当初家里还有一套没有拆封，有喜爱的敌人能够分割我收费送给你。 看这本书时因为对麻利和DevOps曾经有了本人的了解，所以不像看《凤凰我的项目》时那么迷茫，很多内容都十分有感悟，书分为上下册，以一个爱情故事做串联，外面波及了各个方面的麻利DevOps常识，如果你想全面理解麻利那连忙动手读一读，因为篇幅较长建议您能够多读几遍。 3《走出硝烟的精益麻利-咱们如何施行Scrum和Kanban》 举荐这本书是因为这本书算是我的麻利启蒙书，过后我还没有考过任何的麻利认证，想找一本书理解下麻利是什么，在购书网站看了评估感觉这本书还不错就下手了，拿到之后还记得是在火车上第一次关上，记得在后面几页作者说这本书不是写给菜鸟的（心中妈卖批），外面是实际过程中摸索进去的一些做法，可能并不适应所以的组织或团队，本人还是硬着头皮看了一半，第二次再拿起来也是几年之后了，再读的时候感触颇深，所以起初这本书成为了我做外部培训时的奖品，当你加入了一两天的麻利培训后，读一读这本书或者会很有播种。 4《麻利整洁之道》 这本书也是20年看的书，过后看到这本书立即想到了《代码整洁之道》，买回来读了，第一感觉是读起来不累，作者是麻利宣言发起人之一Robert C.Martin，作者用很天然的语言在介绍麻利的初衷，没有过多的术语，也没有难以了解的概念，同时作者也强调了麻利工程实际的重要性，读过之后仿佛没有播种太多的知识点，然而感觉心灵有受到启迪（小伙子，你有点夸大哈），仿佛能了解麻利巨匠特地保持的所谓纯正的麻利。 5《继续交付》和《继续交付2.0》 第一次读《继续交付》没有读完（怎么好多书第一次都没有读完？），起初读是因为考DevOps Master的认证，过后把这本书读了两遍，算是对书中的内容有了一些了解，能够说书中的内容很全面了，是DevOps必读书籍，《继续交付2.0》是乔梁老师的大作，内容也是十分全面，而且对麻利、继续交付、继续交付2.0等概念波及的范畴作了廓清，两本书连起来读或者会事倍功半。 6《京东麻利实际指南》 写到这里就忽然想到了这本书，这本书给人的感觉是“短小精干”，书很薄然而波及的内容很广，麻利概念、Scrum、XP、Kanban、规模化麻利和各种案例都很丰盛，我只是花了几个早晨抽时间就读完了，如果你读书的工夫很少那看看这本书，不错！ 7《大规模Scrum》和《SAFe4.0参考指南》 刚刚说到了规模化麻利就立即想到这两本书，鉴于行业内Less和SAFe的框架之争把这两本书放在一起总感觉怪怪的，话说回来这两本书其实我都没有看完，起因是我看到一半就把书扔在一边转而去钻研Less和SAFe的官网了，所以起初很多内容都是通过官网学习的，然而如果你喜爱看书，这两本规模化麻利的书还是值得动手的。 能够说SAFe和Less框架的设计区别还是很大的，Less还是依赖于Scrum做得好，在这个根底下来做扩大会更加得心应手，用吕毅老师的话说有了岗位和角色就肯定会忙起来，没人会说本人没事儿干，所以Less保持more with less，能不加人就不加，能不加工件就不加，反观SAFe则更像一个工具箱，波及的内容十分之多，有点pmbok的感觉，内容全了，具体利用是就依赖于如何裁剪了，框架各有特点也各有劣势，还是实际出真知。 8《麻利预计与布局》 这本书是考ACP时逼着本人读的，这本书还是很全面的介绍了麻利打算的内容，如果你想全面的理解一下还是倡议读一读，我集体的认识是这本书局部内容写得有点啰嗦有种看国产电视剧的感觉，跳过几页仿佛还能接得上（仅代表个人观点）。 9《看板办法-科技企业逐步改革胜利之道》 学麻利必须要学看板，学看板就必须读一下这本《看板办法-科技企业逐步改革胜利之道》，作者是大卫·安德森，也是把看板办法从传统行业引入到软件研发畛域的人，所以，读它就对了。 10《Scrum精华》 这本书能够说是学习Scrum的经典书籍了，不过羞愧的是我晓得这本书很晚，然而读过之后也有种相见恨晚的感觉，静下心来读一读您会对Scrum有更深刻的了解。 11《The Scrum Guide》 很多敌人通过各种各样的路径理解了Scrum这个办法，鉴于Scrum框架是简略的，所以很多人认为曾经把握了Scrum，然而实际过程中发现很多做法与Scrum提倡的方向有所偏离，所以既然你决定使用Scrum框架，那这本薄薄的官网读物难道不应该多读几遍吗？ 12《精益和麻利开发大型利用实战》 如果你看到这本书的作者你会发现和《大规模Scrum》这本书是一样的，没错，用Less的一张图来解释他们的关系，两位作者首先写的就是这本《精益和麻利开发大型利用实战》，也就是图中的experimes局部，后续在这个根底之上又写了《大规模Scrum》一书，所以从这一点上来看咱们晓得Less框架的造成不是先有了框架和指南，而是先有的实际继而依据无效的实际总结造成了整个框架体系。 13《用户故事与麻利办法》 如果你想认真的理解麻利打算的内容就看《麻利预计与布局》，如果你想认真理解用户故事的内容这本《用户故事与麻利办法》就是你的不二之选，这本书还是挺厚的，都是围绕用户故事编写的，按需浏览吧。 14《用户故事地图》 如果说用户故事这本书只能让你看到树木，那用户故事地图这本书就在传授你办法看到整个森林，这本书讲述了用户故事地图的起源和设计，用户故事地图是十分好的工具用起来也比较简单，如果你想追根溯源就读一下这本书吧。 15《麻利软件测试》 如果你是测试人员或者对麻利测试畛域很感兴趣倡议读一下这本书，很多麻利测试相干的概念都能在这本书中找到，比方测试四象限、测试金字塔等。 16《麻利项目管理（第2版）》 很多Scrum Master、麻利教练可能都是由项目管理人员转岗的，所以这本书里形容的麻利项目管理模式能够让读者了解麻利项目管理与传统项目管理的差别。构想、揣测、摸索、适应和完结五个阶段很好的形容麻利项目管理的思路和办法。 17《麻利回顾：团队从优良到卓越之道》 麻利是为了灵便响应客户的诉求，为客户带来价值，而要害的实际是定时和及时地回顾以及继续改良，所以麻利回顾是十分重要的麻利实际，这本书围绕预设会议基调、收集数据、激发灵感、决定做什么和总结收尾几个步骤具体的介绍了麻利回顾的经典办法。 18《麻利中国史话》 最初举荐的一本同样是20年的新书，作者是熊节老师，对我来说浏览这本书是因为我深知本人在麻利圈是个新人，心愿通过这本书理解那些错过的重要事件，过往的教训能帮忙咱们少走弯路，也能进步咱们对历史的认知，“知史以明鉴”！ 以上就是我集体举荐的20本麻利书籍，兴许不是所有的都适宜您，仅以集体的视角做简评和举荐，心愿对您有帮忙！ 起源：麻利DevOps那些事儿 作者：杨久成 4月每周四晚8点，【冬哥有话说】DevOps之庖丁解牛，拆解DevOps的工具及具体实战。公众号留言“解牛”可获取地址 0401《数据库继续交付流水线分享与演示（Azure DevOps+Flyway）》0408《继续交付中的版本治理与基于Azure DevOps扩大框架的插件开发》0415《微服务，多团队合作中的API测试怎么做 - Pact契约测试》0422《BoatHouse端到端流水线展现》

摘要：为了升高各种剖析工具的后果汇总到通用工作流程中的老本和复杂性, 业界开始采纳动态剖析后果替换格局(Static Analysis Results Interchange Format (SARIF))来解决这些问题。本文分享自华为云社区《DevSecOps工具与平台交互的桥梁 -- SARIF进阶》，原文作者：Uncle_Tom。 1. 引言目前DevSecOps曾经成为构建企业级研发平安的重要模式。动态扫描工具融入在DevSecOps的开发过程中，对进步产品的整体的平安程度施展着重要的作用。为了获取安全检查能力笼罩的最大化，开发团队通常会引入多个平安扫描工具。但这也给开发人员和平台带来了更多的问题，为了升高各种剖析工具的后果汇总到通用工作流程中的老本和复杂性, 业界开始采纳动态剖析后果替换格局(Static Analysis Results Interchange Format (SARIF))来解决这些问题。本篇是SARIF利用的入门篇和进阶篇中的进阶篇，将介绍SARIF在利用过程中对深层次需要的实现。对于SARIF的根底介绍，请参看《DevSecOps工具与平台间交互的桥梁–SARIF入门》。 2. SARIF 进阶上次咱们说了SARIF的一些根本利用，这里咱们再来说下SARIF在更简单的场景中的一些利用，这样能力为动态扫描工具提供一个残缺的报告解决方案。 在业界驰名的动态剖析工具Coverity最新的2021.03版本中，新增的性能就包含: 反对在GitHub代码仓中以SARIF格局显示Coverity的扫描后果。可见Covreity也实现了SARIF格局的适配。 2.1. 元数据（metadata）的应用为了防止扫描报告过大，对一些重复使用的信息，须要提取进去，做为元数据。例如：规定、规定的音讯，扫描的内容等。 上面的例子中，将规定、规定信息在tool.driver.rules 中进行定义，在扫描后果(results)中间接应用规定编号ruleId来失去规定的信息，同时音讯也采纳了message.id的形式失去告警信息。 这样能够防止规定产生同样告警的大量的反复信息，无效的放大报告的大小。 vscode 中显示如下： { "version": "2.1.0", "runs": [ { "tool": { "driver": { "name": "CodeScanner", "rules": [ { "id": "CS0001", "messageStrings": { "default": { "text": "This is the message text. It might be very long." } } } ] } }, "results": [ { "ruleId": "CS0001", "ruleIndex": 0, "message": { "id": "default" } } ] } ]}2.2. 音讯参数的应用扫描后果的告警往往须要，依据具体的代码问题，在提醒音讯中给出具体的变量或函数的相干信息，便于用户对问题的了解。这个时候能够采纳音讯参数的形式，提供可变动缺点音讯。 ...

好多年以前，我是个程序员。尽管那时候很穷，然而我素来没有因为没钱而失望过，因为我晓得，当前没钱的日子还很多。 通过多年奋斗，终于做到了技术经理，买了一辆属于本人的车。 我也明确了一件事件：我这个年纪的人，骑电动车的时候肯定要戴平安头盔，否则，会被开宝马飞驰的同学认出来。 记得刚做技术经理的时候，我还是改不了爱装逼的故障，常常整些高大上的治理方法论。 我已经不遗余力地推广麻利，不停地给团队讲、给领导讲、给老板讲。不为别的，因为如果他们不懂这货色有如许好，我装逼给谁看呢？ 起初我懂了，装逼就算了，如果你装逼还不抵赖的话，雷就会劈你。就算雷懒得劈你，老板也会揍你，别问我是怎么晓得的。 谈到麻利，我有着本人独到见解。我置信：只有致力搞，没有麻利搞不垮的团队。 经验了这些，我更能谈谈本人的感悟。 一、不置信麻利一提到麻利，员工就在想：“傻逼领导，又瞎折腾了！”、“麻利就是快！以前10集体干的活，当初5集体就干完了！大家要就业了。” 当员工有这种想法的时候，你就能够放心大胆搞麻利了。让员工们在不了解的状况下推麻利，埋下一颗定时炸弹。 俗话说得好，万事开头难，因为前面的难，你缓缓就习惯了。开个好头，你就胜利了一半。 二、不指定麻利教练程序员是一群绝顶聪明的人，我稍差一点，我只是绝顶。既然这么聪慧，还须要啥麻利教练？又想搞培训，割咱们的韭菜？没那么容易。 大家都是受过九年制义务教育的，尽管我比你们牛逼一点：我读了十年。 其实很多情理都是“做得说不得”的，麻利就是。学费还是要交的，早交比晚交要好。 三、不尊重队员记住，团队成员都不是人，没得感情。要把麻利、OKR等先进管理工具，批量引入团队，肯定可能药到病除，极大晋升战斗力，不必管员工的感触。 你晓得为什么高层领导对上面的员工都很友善，而基层领导对上司都很凶吗？ 这么说吧，你见过有人对本人的办公用品怄气的吗？ 四、不容忍犯错大家都是职场成年人，拿后果谈话，做不好就要重罚，怎么能容忍犯错呢？ 如果犯错不必受罚，LV每年出这么多包包干嘛？ 五、回避艰难一旦施行麻利，问题就来了。长期需要能不能插入？文档还要不要写？我的项目还要不要评审...... 遇到问题首先要沉着。明天解决不了的问题，不要焦急，因为今天你也解决不了。 六、把改革当试验麻利不就是开开站会、画画白板吗？有什么稀奇的，先找几个团队试试看，谁晓得行不行啊？ 麻利不是提倡“先开枪后瞄准”吗？先跑起来吧。 可问题是，你打进去的可能是原子弹呢？打乱了团队的节奏，影响了业务失常发展，你恐怕只能革本人的命了。 七、太激进麻利很好啊，这么多牛逼闪闪的公司都上了麻利，咱们抄作业都不会吗？ 所有我的项目都换成麻利模式，明天成熟度L0，今天成熟度L4。只有想不到，没有做不到。 记住两条定律： 麻利是完满的；如果发现有问题，请参考第一条。麻利怎么可能有问题呢？肯定是咱们的问题，是咱们不配上麻利。 八、批评和打击团队人类创造语言是干嘛的？为了传八卦的呀。所有批评和倡议，都要私下里说，千万不要放在台面上，越神秘越好。 什么老板小姨子的姐夫又跟小姨子的姐姐打得火热了、哪位开发哥哥偷偷在人群中看了测试妹子一眼......那点陈谷子烂芝麻的事，也要分个九九八十一回解说。 要让团队气氛乌烟瘴气，搞垮团队的大业，不可企及。 九、激化矛盾产品和开发的关系，就像斗地主，方才还是一伙的，一转眼就成了敌人。 有时候又像情侣，热恋时，情侣们常感叹上辈子积了什么德；结婚后，夫妻们常狐疑上辈子造了什么孽。 记住，开发永远不要跟产品争吵需要，因为吵了一上午，人家的需要曾经整明确了，你的代码在哪呢？ 十、不足产品布局自从上了麻利当前，产品就彻底放飞自我了。开发都麻利了，能力都开释了，还要啥产品布局啊？ 天下产品，唯抄不破。厉害的产品经理都是搞C2B的----Copy to BAT。 先抄阿里，再抄腾讯，度娘不行了，那就抄拼多多吧。 十一、技术架构失控麻利这么快节奏，哪有功夫搞技术架构？全副上长期计划，出问题就打补丁，补丁下面再打补丁。 出线上事变就开始甩锅，肯定是产品设计的问题、要不就是测试没测到、可能是运维的问题...... 总之，程序员别给本人太大压力，费头发。切实不行，筹备删库跑路吧。 十二、不足工具反对主动构建工具没啥稀奇的，手动也一样啊，缓缓打磨，要有工匠精力。 麻利管理工具也别买了，Excel就挺好，每年花那几十万费用，省下来给兄弟们发发奖金，难道不香吗？ 自动化测试，也是个败家玩意。测试都自动化了，那么多可恶的测试妹子难道要下岗吗？做集体吧。 要晓得，丑陋的测试妹子是我每天下班的理由。否则，下班跟上坟有什么区别。 十三、文化鸿沟团队文化要顺其自然，别整那没用的团建。独狼程序员有什么不好，一个优良的程序员，能顶10个平庸的程序员，不肯定非要合群啊。 还整啥对立文化衫、团队slogan、文化墙？杀了我吧。 这就是我，色彩不一样的烟火；我就是我，看了本人都恼火。 结语想要用麻利搞垮一个团队并不难，以上13条只有做到一半，预计这个团队就垮了。 俗话说，不当家不知柴米贵，不拍照不知本人肥。有些事件要一直尝试，哪怕翻车了，至多总结了教训。 麻利施行没有捷径，都是一步步走进去的。经验了风雨，不肯定看见彩虹，还可能会得重感冒。 然而幻想还是要有的，万一见鬼了呢。 起源：技术领导力 作者：Mr.K

本篇是《研发治理的101条军规》专栏的第一篇，先在这里给各位介绍下我想构建这个专栏的想法和想跟各位分享的内容方向: 《研发治理的101条军规》将是一个对于如何更好治理研发团队，晋升研发效力的系列文章，打算输入101篇。 Worktile团队自身将高效研发作为过来数年继续打造的公司能力，在一直的对麻利研发和DevOps工程化的摸索与迭代中，咱们逐渐打造了极其强悍且高效的百人研发团队。 同时，因为Worktile是一个以效率为外围价值的合作工具，咱们也一直向用户输入了很多干货，因而将这些干货集结成集，是一件有意义的大事件。 大道至简，每条军规其实并不简单，因而篇幅可大可小，重要的是哪怕一个很小的规定，都能产生化学般的反馈，对团队治理和研发效力带来很不一样的价值。 例如，咱们在往年1024节庆贺Worktile研发团队技术分享的第100期。许多技术敌人都十分感叹为何咱们可能将每周技术分享保持5年？咱们每期的技术分享主题都积淀为团队贵重的常识资产，新退出的共事也能很快受惠于过来不同研发工程师的积攒。我也会在后续的军规中和大家聊聊研发技术分享可能做到5年一直的机密。 研发治理的101条军规，初步打算分享101个研发治理的“文治秘籍”，蕴含治理篇、办法篇、工具篇、工程篇和闲聊篇几个类别，从研发团队的治理细节，到工具化的应用技巧；从每日站立会议，到DevOps工程化实际。101军规将为每个研发团队，尤其是研发管理者、CTO提供一线百人规模团队的治理实际，本文将作为开篇，咱们从讲述一个小的两周迭代开始。 研发治理的101条军规之两周迭代，正篇开始在Worktile团队，咱们继续保持一项十分外围的研发治理办法：两周迭代，这条军规的外围不是两周或者一个月的工夫节点，而是周期性的迭代可能造成团队继续的习惯，而这个习惯具备极其神奇的力量。 （上图是咱们基于 PingCode 的迭代治理） 两周迭代的神奇力量体现在： 激活的组织都是有节奏感的，两周是最合适的工夫长度，让整个团队造成了继续的节奏感。长期履行两周为一周期循环，能够让每个开发者都逐步适应更高效的节奏，而好的节奏就是团队能量的催化剂。两周迭代，让迭代打算环节异样重要，因为庄重且认真的迭代打算将决定了将来两周的开发工作，Worktile开发团队通常将产品经理、设计师、开发者组织在一个工夫较长的迭代打算会议上。产品在需要池确定优先级，并针对每个用户故事解说产品细节，开发成员依照优先级评估故事点，并通过PingCode麻利布局来针对接下来的Sprint做开发计划，蕴含重要的需要和Bug。两周迭代的布局会议，保障了开发小组之间的充沛的沟通和共识，进入开发阶段会缩小很多无谓沟通，反而整体研发效率极其高效。 两周迭代可能主动造成研发团队的文化，两周既是周期，也是指标。这意味着两周完结，团队须要如期交付。尽管996成为互联网公司的标配，但其实无意义的加班对团队自身是有挫伤的。两周迭代可能主动造成团队共识，2周后无论状况如何，都必须实现迭代工作，否则团队都对指标无奈交代。在这种文化影响下，每个团队成员都能自驱性的对后果负责，2周就是军令，到期未实现将是一件没有体面的事件。两周迭代的复盘会议，咱们让开发者本人演示本人的性能实现，这个小创意很有价值。分享人须要本人负责演示，在团队的社交压力下，演示环节呈现问题是不太有体面的事件，因而在复盘会议之前，开发者都能很负责的对进度和品质负起责任。两周迭代能让产品、设计、开发造成失当的单干节奏，咱们基本上做到了产品早设计一个迭代，设计早开发一个迭代，不同迭代环环配合，彼此不连累。这个本事也是受害于节奏感这件事。两周迭代，可能逐步理解一个开发小组的生产力，团队速率逐渐稳固，而这个生产力也将作为每个迭代工作量的评估规范，帮忙团队更好的打算迭代。另一方面，也能够通过逐渐晋升团队速率作为研发团队的治理指标去优化。例如，咱们某开发小组将两周故事点从20个逐渐晋升到30个，从这个指标都能直观的看到团队效率的继续改良。 （上图为 PingCode 的团队速率报表） 两周迭代刚好适配了OKR的周期治理。从实质来说，研发治理做好两件事就可能事倍功半，第一是指标，第二是过程，指标通过OKR机制保障，过程通过麻利迭代实现。而两周迭代的设计，更好可能匹配OKR中的周期性，如果团队OKR是基于每月的，那么就能恰好在一个指标周期中蕴含2个迭代周期，造成指标和过程周期的完满匹配。 每两周一个迭代，可能让开发团队聚焦方向，造成节奏感，最重要的是一个有着自驱力的文化被打造进去。每个开发者都成为继续迭代过程的标兵，推动产品向着继续迭代的方向大踏步向前走。聊完第一条军规，最初来聊一个工具——PingCode，这是咱们团队基于多年积淀，正在打造的研发管理工具。您能够在PingCode中体验一个研发治理自动化工具给团队所带来的扭转。 内容起源：Worktile作者：Anytao研发治理101军规——PingCode（Worktile）CEO王涛

Scrum指南11月18日，Scrum指南公布了最新版本，整个发布会继续了3小时，全程英文，对于中国的麻利酷爱者，不晓得有多少人熬夜看了直播。如果错过了也没关系，珍藏本文，咱们一起来逐字逐句地比照一下，2020版的Scrum Guides，到底有哪些变动。 PS：不喜爱看原文的同学，间接拖到最初看总结。 一、Scrum 指南目标 【集体了解】 1.从“他们”到“咱们独特”，这个主语上的奥妙变动，其实能够看出两位创始人Ken Schwaber & Jeff Sutherland对于这个版本的用心水平，及Scrum框架凋谢的心态。 2.强调Scrum框架中每个元素都十分重要，不要轻易去裁剪。所以，很多同学在埋怨Scrum不好用的时候，认真想一想，你是不是很好的恪守了Scrum的主流程呢，还是只实际了其中一部分？ 3.强调Scrum尽管在软件研发畛域利用最为宽泛，且指南的描述性语言也都采纳了IT类语言，但Scrum也同样实用于非IT部门。当然这不是凭空说的，而是交融了Scrum成立25年以来，寰球各界人士在各个行业的多元实际。源于实际，领导实际。 4.Scrum指南更多的是通用性语言，其余的交给大家自行扩大。 二、Scrum定义 【集体了解】 1.从“发明产品”，变成“发明价值”。这个变动我认为是十分重要的一点，咱们交付的是价值，肯定不是产品。“价值”才是更应该掉强调和关注的，而“产品”只是“实现价值”的一个载体。 2.减少了一条“Scrum须要SM营造环境”。可能从以往的反馈来看，没有适合的“环境气氛”，Scrum很难落地。营造环境这个重任，落到了SM身上，真是任重而道远啊。 3.从“轻量级的、容易了解的、难以精通的”，到“易于了解的、不残缺的、个体智慧的、规定是用于领导的”。这外面强调了： “不残缺是成心的”，因为须要大家在Scrum落地中自行扩大，能更好的就地取材。“个体智慧的”，不要“我感觉（包含SM）”，要“大家感觉”。在共识的根底上能力更好的落地和执行。“规定是用于领导的”，不是死板的遵循，而限度了其灵活性。三、Scrum实践 【集体了解】 1.Scrum实践形容局部，新增了“精益思维”重要性的形容，目标是缩小节约，专一于基本。 2.强调分享的重要性，独特学习，独特成长，全技能造就。 四、Scrum价值观 【集体了解】 口头外围靠“疏导”，而不是强制的要求。 五、Scrum Team 【集体了解】 1.从“自组织”变成“自治理”。可能之前很多人在执行过程中，把“自组织”玩成了“无组织”吧，所以，为了缩小这种误区，采纳了新的词汇自治理（self-management)来形容。 2.强调了Scrum团队的责任，并不是简略的把产品上线就完结了。而是要围绕“产品指标“Product Goal”去全流程的参加，保障“价值”能在“产品”上被真正的被体现。 六、开发团队 【集体了解】 1.强调DoD在内建品质的重要位置； 2.新增Sprint Goal概念，并每天测验打算。 七、产品负责人 【集体了解】 PO是PBL惟一负责人被删掉了，从2020版的形容中推测，可能是在以往的执行过程中，PO过于强势，或者开发同学参加PBL梳理过少，而妨碍了大家敌对的交换和互动。 八、Scrum Master 【集体了解】 将服务型领导者（Servant Leader)改成了真正的领导者（True Leader）。这个变动打消了原先对服务型领导的误会。SM不是团队保姆，而是要营造适合的环境，打消各种隔膜，并且作为教练，辅导组织驳回正确的Scrum。 九、Sprint 【集体了解】 1.再一次强调，迭代交付的是价值； 2.Sprint Goal不能扭转，然而大家能够围绕指标，进行细节廓清和范畴调整。 十、勾销 Sprint 【集体了解】 正如2017版形容的那样，因为sprint周期较短，所以勾销sprint的意义不大。另外2020版指南，引入了“Sprint Goal”的概念，这样能很好的避免因为没想好、或者指标不聚焦带来的失败。所以勾销sprint将成为极小概率的事件，且不激励这种行为，所以被删掉了。 十一、Sprint 打算 【集体了解】 1.在Sprint打算中，所要做的事件，都必须要与Product Goal进行关联，换句话说，关联不上的需要，都是伪需要。 2.Sprint打算要解决的问题是：（WHY）为什么做？（WHAT）做什么？（HOW）怎么做？这个很像黄金圈法令（Golden Circle）和影响地图（Impact Mapping）的构造。 十二、Daily Scrum 【集体了解】 删掉了站会内容常见的三个问题：“昨天做了什么？”，“明天做什么？”，“有没有妨碍？”。可能是避免误导大家认为这三个问题是站会中每个人都必须要僵硬答复的问题，目标是让团队本人去思考如何开站会是高效的，且适宜本人的。 ...

理解麻利的人应该对回顾会不生疏，回顾会是在SCRUM框架五个流动中的最初一个流动，然而在麻利的理论利用中，回顾会并不只是会在利用SCRUM的团队中应用，在其余麻利实际中也会引入回顾会作为反馈环节。 那么什么是回顾会呢？在SCRUM中，回顾会是来回顾以后迭代中的流程、工具、实际、沟通、环境、资源等方方面面，检视各个过程并提出改良项的流动。这个会议重点在于聚焦问题并继续改良。 这个是一个最容易被疏忽的会议，尤其是在开发压力比拟大时，回顾会往往会是第一个被裁剪的过程。 一、为什么须要进行回顾？孔子曰：吾日三省吾身。只有一直反思/回顾能力找到本人须要改良的中央并继续改良，在软件开发中也同样如此。麻利体系是开源体系，没有起点；即没有最麻利只有更麻利。那么如何让咱们的麻利团队更加麻利呢，回顾会是一个必不可少十分重要的会议。每个迭代中运行着雷同的过程，这同时也意味着可能反复着同样的谬误。能够说没有回顾就没有继续改良。如果你的团队在利用麻利，在利用SCRUM框架，那么回顾会是继续改良的必要过程和流动。 二、回顾会利用怎么开？这个问题对麻利教练提出了比拟高的要求，在回顾会上，尤其是在刚开始实际麻利的团队回顾会上，团队往往不晓得回顾会要做些什么。常见的误区就是会把回顾会了解为总结会或者反思会。此时，麻利教练要给予正确的疏导。 回顾会的流程比较简单，通常有以下几个议程： 2.1 会前筹备回顾会之前肯定要收集足够的数据，包含迭代中故事完成度，燃尽图，速率图，每个故事耗时状况等，收集数据后须要向团队进行展现。其次，确定好要邀请的人员以及回顾模式和议程。回顾会的筹备是十分重要的，筹备是否会很大水平上决定是否开一个无效的回顾会。 2.2 会议次要议程1）向团队展现度量数据，通过数据进行初步剖析，激励团队参加探讨，是否有不言而喻的重大问题，是否有非凡状况导致本迭代的数据问题。如果有重大问题，在回顾时作为重点进行回顾。 2）让团队成员各自总结须要持续放弃的和须要改良的项，这里有很多办法，包含三栏式（Well, Less Well, Puzzle）、海星图（Start, Stop, Do Less, Do More, Keep）以及SSCC（Start, Stop, Continue, Change）等。 3）将大家的反馈进行分组，并针对须要改良的问题进行剖析，这时也能够采纳一些根因剖析的工具，包含鱼骨图等，最初收敛出须要做的改良点。 4）针对改良点制订行动计划（Action）及负责人（Owner），并就行动计划在团队内达成统一。 2.3 完结会议回顾会的完结，能够增加一些典礼感，比方由几个人说一下这个迭代中须要感激的人，为他提供帮忙的人，简略的表示感谢；而后由SM做一个简略的总结，对会上探讨达成统一的改良项、负责人和行动计划进行重申，最初须要对大家表示感谢后完结会议。 三、如何开好回顾会？怎么使回顾会开得最有成果？能够将迭代中的问题全面裸露进去就是有成果的；能够将上个迭代反复产生的问题缩小甚至防止就是有成果的；团队成员都认为每个迭代咱们都在继续改良中，并且乐于每个迭代进行回顾改良就是有成果的。最初，只有回顾后贯彻执行继续改良才是最无效的。那么如何使回顾会有成果呢？ 3.1 营造轻松的气氛会议场地：大部分的回顾会都会抉择在会议室进行。在工作单位中会议室的确是大家个体探讨事宜比拟适合的场合，然而容易给大家一种缓和庄重的感觉，不利于团队成员畅所欲言。个别比拟倡议的咖啡间等等。会议工夫：个别回顾会会定在迭代最初一周的周五，迭代评审会之后。这个工夫点个别迭代都曾经实现，大家只剩下一些收尾的工作，会比拟容易营造大家放松的氛围，团队不必去思考仍未开发完的性能、未修复的bug等，团队更容易参加到回顾中。参会人员：回顾会须要大家畅所欲言，针对相干问题进行解决方案和行动计划制订的流动，是团队外部自我改良的流动。因为领导层通常把握着团队成员的绩效奖金等切身利益，如果有领导层的参加会容易大家感觉到缓和，以至于会报喜不报忧，没有方法继续改良。这时个别倡议如果不是有十分重大且必须要领导解决的问题之外，不会倡议领导层参会。对于产品经理是否应该加入回顾会的问题，产品经理是团队的一员，准则应该要加入回顾会，然而如果产品经理的在场会导致团队缓和或者不敢提出问题，那产品经理还是不倡议加入会议的。暖场：为了让大家放松下来，个别须要SM收场比方一个笑话，一个简略小游戏收场，让大家放松下来适应轻松的气氛；收场：麻利教练能够通过一些小技巧让大家疾速思考起来，比方让团队成员用一句话、一个词或者一个水果来形容对以后迭代的感触，用简略的话来形容容易激发大脑的思考。一句话，一个词语而不是一段话，这时就会激发大家去动脑，从泛滥词语中抉择一个最适宜形容以后迭代的，这样做的次要目标就是让大家的思路先转起来。3.2 晋升团队成员的参与度SCRUM非常重视集体，是以人为本的。在回顾会上，使得大家都参加探讨是十分重要的。上面有几个办法能够帮忙团队减少参与度。 大家匿名写出须要改良的和须要持续放弃的，这样能够爱护大家防止因为写出不好的中央让大家感到难堪。每次会议的议程和开展形式可进行调整。如果每次回顾会的内容和形式都是雷同的，大家会变得越来越形式化，感觉回顾会没有意义。每次调整暖场形式或者大家的参加形式，这样能够在放弃新鲜感的同时晋升大家的关注度。激励发言，在感激和感悟环节，激励大家表白本人的感悟以及对团队成员（某位成员）的感激。这时须要激励大家发言，无论发言如何都要给以尊重和认可。如果没有人发言，后期倡议能够通过抽签或者乏味的形式找到人来发言，缓缓减少大家参与度。3.3 贯彻执行改良项为了保障改良项可能顺利落实，须要抉择对大家目前影响最大的，即优先级最高的，同时须要综合思考改良项的老本和开销后抉择。须要做的改良项倡议肯定要写入下个迭代的backlog中，不便跟进的同时也能使得改良项负责人认真对待。 四、回顾会重要留神点增强器重度，不要让回顾会变成很少人员加入的可有可无的会议。有些团队的误区就在于每次回顾的重点都是雷同的，这就使得团队认为每次回顾会的内容是雷同的，可裁剪的。这时须要SM去疏导团队聚焦以后迭代是否已贯彻执行上一迭代改良项，是否有新的须要改良的问题，以便继续改良。防止天马行空的议论不切实际、不可能实现或者不相干的话题。因为回顾会是比拟轻松让大家畅所欲言的流动，这时很容易天马行空漫无目的的议论，要及时将大家的探讨拉回到正确的思路上来。防止对重大问题熟视无睹，回顾会上要敢于提出大家都认为是有问题，然而没有人敢于提出的问题。防止团队成员陷入郁闷自责，这一点跟营造轻松的气氛和会议参加人员十分相干。此外要置信所有成员在现有条件下曾经做出了最大的致力。防止陷入相互指责，互相吐槽的地步。要通过回顾以后迭代的问题来改善后续迭代的状况。如果团队有追责文化，很容易呈现这种状况，这时须要循序渐进的扭转大家的思维定式，同时缩小追责，减少激励和处分机制。回顾会上的改良项肯定要贯彻执行，没有执行就等于没有改良，没有改良回顾会就失去了意义。防止为了过程而过程，要每期制订回顾重点，防止形式主义。如果仅仅为了会议而进行会议，那比不开会议还要蹩脚。写在最初回顾会不倡议裁剪，只有继续回顾能力继续改良。在工作过程中，须要咱们时不时的停下来回顾下，咱们是否做了最好的计划，是否有更好的计划？如果对现状十分不满且急需扭转，停下来回顾思考下，兴许是个不错的开始。 作者：IDCF社区FDCC认证学员 魏祖迎 想要晋升麻利DevOps技能，来场DevOps黑客马拉松！想要寻找第二增长曲线实现翻新增速，来场DevOps黑客马拉松！2021年4月24-25日，IDCF DevOps黑客马拉松走进天府之国-成都关注公众号回复“黑马”退出吧~~可本人报名，也可公司组团加入哦！

作为企业里 PMO 团队的一员，我的次要工作内容就是为组织、为团队找到更好的工作办法，其中麻利的工作办法咱们尤为推崇。那在工作之外的生存中，麻利的办法是否适宜呢？毫无疑问必定适宜，不信你能够看看我是如何组织我的婚礼的。 本文纲要预览： 咱们想要什么样的婚礼有哪些好的 Idea 能够帮忙咱们达成指标婚礼的流程很简单，如何无效治理、防止脱漏重要事项婚礼成果 Review、婚礼过程复盘、过程材料积淀 咱们想要什么样婚礼人的注意力、工夫都很无限。如果不在当时定义好什么叫做一场胜利的婚礼，那么你很难正当的安顿事件的优先级，在关键时刻决策做什么、不做什么。另外，从外在驱动力的角度来说，一个受认可、鼓舞人心的婚礼愿景是激励大家专一投入的关键因素。 具体实施步骤也很简略，和老婆一起头脑风暴：“如果此刻婚礼曾经完结时，咱们达成了什么样的指标会感觉这场婚礼是称心的。” 就这样，咱们定义了婚礼的指标是： 【美美哒】【印象粗浅、特地、用心、有感情】【周到的安顿】【关照好亲朋好友】【兼顾身材、不太累】 有哪些好的 Idea 能够帮忙咱们达成指标确定好婚礼指标之后接下来就是拆解指标的环节了，咱们利用便当贴来进行头脑风暴拆解，同样通过一个问题疏导：“咱们须要做哪些事件可能帮忙咱们达成指标” 。 具体的施行办法是通过一轮轮发散收敛的疏导来收集 Idea 的： 发散：将脑子里所有的 Idea 都写下来贴在墙上收敛：哪些 Idea 能够进一步分类汇总发散：分类之后的主题时候还有能够补充 Idea收敛：这些 Idea 中重要水平是怎么样的延长：人的大脑是用来思考的不是用来存储的，举荐应用可视化的头脑风暴办法。将所有的 Idea 通过便当贴出现，可能很大水平的辅助咱们思考。 要害知识点： 【头脑风暴】【钻石模型】【程度思考】【可视化】 婚礼的流程很简单，如何无效治理、防止脱漏重要事项在确定了婚礼的指标，对达成指标的要害门路进行拆解之后，咱们决定依照工夫线构建整场婚礼的用户故事地图。做这件事件的次要目标有三个： 梳理残缺的婚礼全景图，确保不会脱漏任何筹备工作邀请家人一起梳理，过程中能够对齐很多流程分配任务时会十分不便，大家能看到全景也能看到细节具体的施行办法是：首先依照工夫线拉出整场婚礼的骨干流程，而后在骨干流程下补充须要施行的具体细节工作。 有了残缺的用户故事地图之后，安顿工作、治理停顿的环节也变得非常简单。招集所有参加婚礼筹备工作的搭档一起开个启动会，依据用户故事地图分配任务，过程中及时在墙上更新工作的停顿。 要害知识点： 【用户故事地图】【工作看板】 婚礼成果 Review、婚礼过程复盘一场婚礼要善始善终，开始确定了指标，最初也必定要验证指标是否达成。邀请你的老婆和家人对失常婚礼进行整体的评估也是必要的，具体的施行办法能够疏导大家答复几个问题：“婚礼最后定义的几个指标，咱们的实现状况怎么样？如果 0-10 分你会打多少分？为什么？” 尽管婚礼只有一次，然而组织婚礼过程中的很多经验值得去反思学习，给本人留出一些工夫反思复盘是也是非常重要的，复盘也是成长的最佳利器。 当然婚礼的最初，最开心的事件必定是数红包啦！当然开心的同时也别忘了及时将婚礼中相干材料进行归档哦。 最初心愿这篇文章能给大家一下启发，让大家开始思考如何迁徙本人的常识，进步本人工作和生存的品质和效率。 文末彩蛋！ 想理解国外网友如何打算在Jira上举办了一场令人惊喜婚礼的吗？点击????《苦涩暴击！用Scrum策动的浪漫婚礼！》 作者：IDCF社区 陈文博  作者介绍：哈啰出行PMO部门高级项目经理。CSM，历任程序员/技术/产品经理。2019年麻利之旅组织者，Atlassian用户社区Leader，破马张飞总导演，印象笔记认证咨询参谋。 想要晋升麻利DevOps技能，来场DevOps黑客马拉松！想要寻找第二增长曲线实现翻新增速，来场DevOps黑客马拉松！2021年4月24-25日，IDCF DevOps黑客马拉松走进天府之国-成都关注公众号回复“黑马”退出吧~~可本人报名，也可公司组团加入哦！

咱们常常探讨什么是麻利、什么是精益、什么是DevOps，与其去探讨什么是，不如探讨为什么。精益、麻利与DevOps为什么会产生？目标是为解决软件研发交付中遇到的各种问题。 软件研发的过程，是价值交付的过程。而价值交付，天生就是从客户来，到客户去，是端到端的。价值交付过程是一个系统工程，须要进行全局优化而非单点改进。割裂的去看价值交付价值流上的单点，亦或是阶段点之间的问题，例如业务到开发，开发到测试，开发到运维，都只能是部分改善。 华为HE2E（端到端）的DevOps施行框架，就是将整个软件价值交付过程残缺展示进去，会集业界先进实际的同时，也联合了华为本身30年研发教训，造成的一套可操作可落地的麻利开发方法论，并基于华为云DevCloud工具链进行固化和承载。 上面让咱们逐个解读HE2E DevOps施行框架的几个次要局部。 影响地图，回归商业的初心 简略的讲，影响地图是这样的一个思维逻辑和组织构造：为什么（Why）-->谁（Who）-->怎么（How）-->什么（What） 也就是：咱们的指标是什么（Why），为了达成指标须要哪些人（Who）去怎么（How）影响，为此咱们须要做什么（What）。影响地图通过构建产品和交付我的项目来产生本质影响，从而达到业务指标。 Why： 答复：咱们为什么做这些？也就是咱们要试图达成的指标。找到正确的问题，要比找到好的答复艰难得多。 Who： 答复：谁能产生须要的成果？谁会妨碍它？谁是产品的消费者或用户？谁会被它影响？也就是那些会影响后果的角色。找对受众群体，是接下来最要害的问题，受众若是匹配谬误，做进去的产品就是对牛弹琴。 How： 答复：思考角色行为如何帮忙或障碍咱们达成指标？咱们冀望见到的影响。 What： 答复：作为组织或交付团队，咱们能够做什么来反对影响的实现？蕴含：交付内容，软件性能以及组织的流动。最初，才是咱们要做的事件，也就是通常咱们讲的产品性能。 往往咱们做产品最容易犯的谬误就是一上来就列举一堆的性能，却没有想分明咱们为什么要做这些，有没有/有哪些人须要，须要这些性能干什么。 影响地图的价值正在于它将事实的商业逻辑用最清晰简洁的构造展示进去，以终为始，回归初心，从目标登程，推演出最终的产品性能。 影响地图能够帮忙组织防止在构建产品和交付我的项目的过程中迷失方向。确保所有参加交付的人对指标、冀望影响和要害假如了解统一。 影响地图能够无效地评估交付，作为品质反馈的规范之一：如果一个需要不能无效地反对冀望的行为影响，那么即便在技术上正确，性能交付给用户了，也依然是失败的。 用户故事地图，既见树木又见森林由影响地图失去了What局部，也就是咱们要做什么，是不是就能够当成用户故事User Story排进产品待办事项Product Backlog开始开发了呢？答案是还不能够。 用户故事是麻利开发中广泛应用的实际，但常见的困惑是：产品负责人整顿了一大堆的产品Backlog，还编排了优先级，过早地陷入到细节的探讨中，只见树木不见森林。 传统麻利开发中，扁平的产品待办列表，存在很多问题：它很难解释产品是做什么的；对于一个新的零碎，扁平化待办列表无奈帮忙咱们确认是否曾经辨认出全副故事；同样的，扁平化待办列表也无奈帮忙制订公布打算，用户故事少则几十，多则上百，详细分析每一个用户故事并且做出是否驳回的决定是十分乏味并且低效的。 用户故事地图是一门在需要拆分过程中放弃全景图的技术，目标是既见树木，又见森林，聚焦于故事的整体，而不是过早的纠缠于细节，在看到全景图的同时，逐层进行细节拆分。 采纳用户故事地图，跳出了扁平化的产品待办列表，看到了产品的全景图，能够真正聚焦于指标用户以及产品最终的状态。产品待办列表只是一维的，而用户故事地图是三维的，这是高维与低维的比拟，高维恒胜。 JeffPatton说，故事地图非常简单，事实也是如此。在Workshop游戏时，咱们最短只须要15分钟解说，30分钟演练，就能够残缺地把用户故事地图弄懂。 用户故事地图基于简略的网格构造，规定是从左到右讲述故事，即叙事主线；自上向下的拆分，即由大到小的细节展示；其中最要害的局部是产品的构思框架，贯通整个产品的公布地图，能够帮忙团队以可视化形式展现依赖关系。此外，更多的背景信息能够摆放在地图的周边，例如产品指标，客户信息等；这简直就是用户故事的全副了。短短几分钟的解释，所有的听众就能领悟到它的价值所在。这也恰好是用户故事地图的魅力所在，好的货色通常都很简略而无效。 Scrum与Kanban，井水不犯河水有了需要的梳理和组织，接下来就是开发落地的过程，而这一过程中，最多应用的就是Scrum与看板的办法。 Scrum与看板，在江湖上是两个门派，驳回时是否须要若明若暗，辨别严格呢？笔者是一个实用主义者，并非唯方法论者，Scrum与看板事实上是能够很好联合的。Henrik Kniberg有一本书叫做《Scrum与Kanban井水不犯河水》，讲的就是如何兼容并蓄，将Scrum与Kanban的实际进行交融，互相借鉴，从而施展两者的最大价值。 Scrum的益处是，它是一个框架，设定了角色、流动、过程产物，以及相干准则。 打算会议与每日站会，造成了工夫维度上从大到小的拆分；Product Backlog与Sprint Backlog，造成打算层面从大到小的合成；而Epic-Feature-Story-Task的层级关系，造成了需要粒度上的划分。 迭代评审会议，是对迭代产物的沟通与反馈；回顾会议，是对迭代过程的扫视与优化。 Scrum设定了严格的工夫盒Timebox，对节奏的放弃大有益处，Develop on Cadence，产品大的版本/批次，到小的迭代，再到每日的站会，就是一个很好的节奏把控过程。 Kanban最大的价值在于可视化，软件研发最大的问题就在于过程不可见。可视化意味着把价值流动，以及问题都显示化进去。裸露问题，而不是遮掩；解决问题，而不是追责。 WIP限度在制品，是看板办法中最难恪守的实际，却也是精益软件开发准则的精髓体现。Stop Start，StartFinishing，进行开始，聚焦实现。笔者今天下午还在和共事聊，咱们开发中最大的问题往往在于开始的事件太多，却没有及时的将一件事件打穿做完。为什么会这样？如何发现？答案是可视化，人们往往没有意识到本人同时在进行的工作到底有多少，一旦将并行工作可视化进去，加上WIP限度，才有可能解决并行在制品问题。 生产过程中的物料沉积被视为节约，研发过程中的工作沉积如何解决？有了后面讲到的可视化，让过程以及产物看得见；有了WIP，让并行工作失去管制；但仍然无奈解决上下游产能不匹配可能造成的工作沉积问题；拉动式零碎比照于传统的推动式零碎，目标就在于解决这一问题。传统开发过程中工作是被上游推动，一旦上游产能低于上游，或者呈现阻塞，就会呈现上游的工作沉积；拉动式零碎中，只有上游产能呈现空余，能力从上游拉动工作，因为有WIP的限度，所以上游一旦超过WIP，而上游又没有产能能够拉动时，上游是不能持续发展工作的（Stop Starting），所以最好的方法是帮忙上游尽快实现（Start Finishing），这也体现了Whole Team的精力。 可视化，WIP，拉动式零碎，造成了看板的三要素。 咱们刚刚介绍了HE2E大图的上半局部，通常被称为治理实际，也是传统麻利开发所关注的局部。接下来咱们看下半局部的工程实际，继续交付域。 继续交付继续集成、继续测试、继续交付、继续部署、继续公布，会不会傻傻分不清楚？（如果真的分不清楚，能够查阅笔者新近的文章） 正如Jez Humble对继续交付的定义：“Theability to get changes—features, configuration changes, bug fixes,experiments—into production or into the hands of users safely and quicklyin a sustainable way.” ...

背景企业的一些我的项目团队每天都开站会，像Scrum外面倡议的一样说那三个问题，然而成果不现实，如同是形式化的内容，并没有起到什么本质的作用。 比方，开完站会后，成员持续做着手头的工作，成员仍然只关怀本人的工作，其它人员的工作齐全不理解，如同站会并没有带来什么成果。再比方，开站会自身也有很多问题：会议超时、成员早退、成员注意力不集中等。具体常见问题如下图所示。 到底如何正确的开站会？站会的意义在哪里？能够不开站会吗？这些问题始终困惑着不少的团队。 问题剖析对于站会的问题大抵分为两类状况： 第一种，团队十分分明应该开站会，意识到站会的确有一些价值，然而对于目前的站会情况不是很称心，如何玩转站会是团队关怀的。对于这类团队，问题的本源为不是十分分明站会的外围价值，以及不晓得怎么实际，团队更须要一些具体的措施来帮忙他们更好地开站立会议。第二种，团队在试着开站立会议，不晓得站立会议有什么价值，如同开和没开没有什么区别。这种状况，是因为团队没有尝到站会的价值带来的苦头，团队没有概念，同样不足最佳实际。综上，不论是第一种还是第二种状况，都须要对站会的价值进一步了解，也就是为什么要开站会，它的意义是什么？而后，都须要明确正确的站会应该怎么样开？最初，都须要一些最佳实际和关键点来帮忙团队开好站会。 解决措施为了减少一些趣味性，咱们先来看两个视频，思考和感受一下“正确”与正确的站会能够开成什么样。 如何玩转站会？咱们依照如下思路学习一下。 1、了解站会价值团队每天站着召开的短时间会议称之为每日站会。每日站会是团队对每天工作检视和调整，提前进行自组织。 通过站会团队每个人能够理解全局，晓得产生了什么事件，实现冲刺指标的停顿如何，对当天的工作是否须要批改打算，有什么问题或者阻碍须要解决。每日站会是一个检视、同步、适应性制订每日打算的流动，以帮忙自组织团队更好地实现工作。 有些团队认为每日站会是解决问题的，是传统意义上向项目经理汇报状态的会议，其实都是不精确的，或者说误会了它的外围意义和价值。 每日站会对于让团队成员每天集中精力在正确的工作上是非常无效的。因为团队成员在伙伴背后当众作出承诺，所以个别不会推卸责任。给团队成员一种精力激励，要对每日的工作指标信守承诺。每日站会还能够保障Scrum Master和团队成员能够疾速解决阻碍，造就团队文化，让每个人意识到咱们是“整个团队在一起战斗”，一些没有应用麻利的组织有时候也同样做采纳每日站会。 演绎一下站会的价值和意义，以及误会： 2、明确正确站会正确的站会应该怎么开呢？咱们一起学习下。 对于每天的工作，为了提前进行自组织，团队成员准时围绕着白板前站立（减少典礼感）。 团队成员在站会上须要轮流发言，答复如下三个问题： 我昨天做了什么？（从上次站会到当初，我做了什么？）明天打算做什么？（在下次站会之前，我会做什么？）我遇到了哪些问题和阻碍？（哪些问题和阻碍阻止了我的工作或使我的工作放缓？）这简略的三个问题能够促使团队成员每天都要检视本人的工作、制订本人的工作打算、取得革除阻碍的帮忙以及对团队做出承诺。 如果团队按正确的形式开站会，进行得好的话，能够达到如下成果： 共济压力。衰弱的麻利团队都会共济压力。所有的团队成员都要承诺一起实现冲刺的工作。这就使得团队成员之前相互依赖并且对彼此负责。如果一个团队成员间断几天都做雷同的事件，并且没有停顿，显然不足后退的能源，而其它团队成员不能熟视无睹。因为他未实现的工作会变成其余成员的阻碍。细粒度的合作。在站立会中，团队成员的交换应该疾速而且有重点。举例，当一个成员说完明天打算做什么后，另外一个成员可能会说：“哦，原来你明天打算做这个啊，这就意味着我要调整我的工作优先级，没关系，你依照你的打算做吧，我能够调整。很快乐你说了这些。”这种细粒度的合作使得团队成员晓得他们之间如何及何时凭仗对方。一个麻利团队应该谋求高效、零期待，防止期待节约。汇集多数工作。在站会期间，团队中的每位成员都能够晓得哪些工作正在进行，哪些工作曾经实现。衰弱的团队应该关注事件的实现，也就是说工作不能始终处在进行中。在站会中，团队须要确认哪几个工作是以后的焦点，这样团队就能够尽快把焦点工作做完。换句话说，做完10件事，远比正在做100件事儿更有意义。每日承诺。在站会上，团队成员须要对团队做出承诺。这样团队成员就晓得麻利交付什么成绩并如何放弃彼此负责。提出阻碍。其实在麻利中任何工夫都能够提出阻碍，然而站会是一个黄金时刻，团队成员能够停下来认真思考“有什么事件妨碍了我或让我的工作放缓了”。3、最佳实际和关键点后面了解和明确了站会的价值和站会怎么开，以及开得好会取得什么样的成果，然而没有讲怎么能够把站会开好，实际的关键点是什么。别急，接下来一起总结下站会开好的关键点。 通过大量实际总结出一些可能帮忙开好站会的关键点，兴许这些关键点并不是全实用，所以还是要依据现实情况做出适合本人团队的抉择和裁剪。这些关键点，我称之为“站会18 key”。 站会18key依照人（People）、过程与办法(Procedures and methods)、工具与设施(Tools and equipment)划分，帮忙大家记忆和学习。 Key 1: 主持人会议主持人（比方Scrum Master，也能够团队成员轮班，轮流感触下站会的节奏）确保会议的举办，并管制会议工夫，团队成员进行简短无效的沟通。 Key 2: 两个比萨大小的团队在《Scrum麻利软件开发》一书中，作者麦克.科思提出了一个简略的办法用来分别什么是适合的团队规模，那就是，如果两个比萨够整个团队成员吃的话，那这个团队的规模比拟适宜。 因为两个比萨大小的团队跟家庭的规模类似，站立会的指标能够轻松达成。当团队是家庭规模大小时，人们头脑中就很容易追踪到团队中产生的事件。人们能够很容易地记住每个人每天的承诺，以及每个人对于其余成员或团队成绩的责任。Scrum中也倡议团队规模不要太大，个别为7-9人左右。 Key 3: 限度发言团队外成员也能够参加，但没有发言权。Scrum中已经应用过术语“猪”和“鸡”来区别在每日站会中哪些人应该参加发言，哪些人就站在旁边看就行了，不过这两个术语当初曾经不必了。 这两个农场动物术语来自一个老笑话：“在早餐吃的火腿鸡蛋中，鸡是参与者，猪是全副投入了。”显然，Scrum应用这些术语是为了辨别参与者（鸡）和为了实现冲刺指标面全力投入的人（猪）。在每日站会中，只有猪应该发言，如果有鸡加入例会的话，应该作为旁观者。 Key 4: 预留缓冲工夫倡议开发团队在上班时间后的半小时或者1小时后开每日站会。这样能够给堵车、喝咖啡、查看邮件、去卫生间或其余每天下班后的例行工作提供一些缓冲工夫。晚点散会还能够给开发团队一点工夫来查看前一天的工作（比方，前一天早晨开始运行的自动化测试工具所生成的缺点报告）。 Key 5: 同时同地每日站立会议应尽可能在同一时间、同一地点召开，最好的形式是在团队的可视化的工作板后面召开。同一时间和地点也能够无效帮忙团队成员造成固有的节奏，不必在找地点和确认当天的开会时间浪费时间。 Key 6: 准时开始所有的团队成员需盲目按时到场，会议主持人要依照预约的工夫按时开始会议，而不论是否有人还没到。对于早退的人员要有一些惩办措施，比方缴纳罚金或做俯卧撑等。惩办措施和数量由团队成员当时共同商定，如果是罚金，如何摆布也由团队独特决定。如果团队成员就是不盲目按时到场怎么办？对于更多这方面的解决方案请参见上面的理解更多中的“成员早退的解决方案”。 Key 7: 站立散会团队成员肯定要站着散会，这也是会议的名字叫站立会议的起因。站着散会的确比坐着散会简明扼要，让人更想快一点完结会议，开始一天的工作。坐下容易使人放松，精力不集中，不易控制工夫（置信很多人有领会）。 Key 8: 强调站会目标常常强调站会目标，特地适宜刚刚启用站会的团队。能够由Scrum Master来强调，如果没有Scrum Master也能够由其它Leader（轮职的主持人也能够）来强调。而后询问团队成员“站会对你们来说怎么样？你们失去了什么成绩？”几次当前，团队成员可能抉择指标申明作为每天的度量，在每次站会之后，团队成员对本人的体现做出相应的评估，是一种强有力的自我管理工具。 Key 9: 聚焦三个问题站会期间，团队成员就说那典型的三个问题（昨天…明天…阻碍是…），其它事件不说。只探讨已竣工和行将开始的工作，或者在这些工作中碰到的问题和阻碍。目标不是向领导汇报工作，而是团队成员之间互相交换，以独特理解我的项目状况和独特解决问题。 Key 10: 眼神反对这是一个好玩的游戏：当一个人站在后面发言时，要求其余团队成员都直视发言人，并进行眼神交换。别让发言人抓到你在看别处。这个游戏帮忙发言人的发言简洁，同时能够增强成员对发言人所讲内容的了解。这样能够帮忙团队减速欠缺每日打算。 Key 11：严格工夫盒站会是开发团队的一个工夫盒限定为 15 分钟的事件。工夫倡议不要太久，对于5-9人的团队来讲15分钟的会议工夫足够。 ...

本文分为以下6个局部为大家解说！ 零代码开发平台因何而来？零代码开发平台是什么？零代码开发平台的劣势？零代码开发平台适宜谁用？零代码开发平台有什么局限性？企业如何抉择零代码开发平台？一、零代码开发平台的由来？ 不难看出，在当下这个信息时代，很多工具型软件都愈来愈呈“傻瓜化”趋势倒退。而早在上个世纪就有了相似的概念雏形，比方在零代码的状况下，用Excel搭建仓库管理系统。但这种形式显然不太适宜现今的互联网时代。所以随着技术的倒退，再加上很多传统企业面临代码开发的资金与工夫老本等问题。从而催生了低代码开发和零代码开发工具。帮忙企业非技术人员实现零代码利用搭建，也能够成为一款开发工具让IT技术开发人员实现疾速效率的开发。 二、零代码开发平台是什么？ 零代码开发平台指的是无需代码开发、就能实现利用搭建的平台。举个很形象的例子，置信很多人都玩过乐高积木（没玩过，最起码也听过吧...）。零代码和乐高这种产品有差不多的共性，就是能给人提供具备肯定法则的模型，让人们能疾速构建出本人想要的模型。 所以咱们给零代码的定义能够是：提供功能模块，让用户像搭建积木一样搭建治理利用。而零代码开发平台的性能次要是：信息收集、剖析、合作等。通过功能模块，衍生零碎利用，像咱们常见的利用有：生产、销售、人事、我的项目、绩效等都能够轻松搭建！ 三、零代码开发平台的劣势？ 相较于传统开发利用模式来说，零代码开发平台的劣势可分为以下几个局部： 1、业务需要覆盖面广 可笼罩市面上常见业务管理需要，只有有信息收集、剖析、合作等需要均可用零代码开发平台疾速构建。 2、零代码根底也能操作 轻易来一个不懂代码的业务人员，也能够依据他对于业务的了解，疾速构建本人所须要的业务。而对于业余的IT技术开发人员来说，零代码开发是帮忙其晋升开发效率的好帮手！ 3、利用落地效率快 业务人员搭建好利用之后，能够通过邀请、组织、调配权限等性能，让企业其余人员疾速参加到其中。 4、前期迭代更容易 当企业业务产生扭转时，管理员能够间接通过批改利用的形式，实现业务管理利用的迭代，个别几天就能够实现，更加的高效迭代形式，能给企业降低成本。 5、服务更加有保障 在传统开发模式中，很多系统软件都是一次性付费。而这种付费模式，往往会存在企业在前面的应用过程中，需要响应的积极性大大降低，让用户应用体验没法失去无效保障。 而零代码开发平台大部分都是采纳按天/按月/按年付费的模式，而且零代码厂商为了能让企业用户可能放弃续费，必定会投入大量的人力、物力、精力在已付费企业用户的体验上。相比之下，零代码开发平台的这种续费模式，能从本源上保障企业用户的短暂利益。 四、零代码开发平台适宜谁用？ 像短少外围业务零碎的中小型企业、短少对立承接非核心业务零碎的中大型企业、传统企业的信息部门人员、业务部门人员、或者不具备逻辑根底的IT开发人员，个别通过短期试用，都能疾速构建利用。（织信零代码开发平台已开启所有根底性能，当初申请可取得终生收费体验权利） 五、零代码开发平台有哪些局限性？ 作为一款工具，他和人是一样的，不可能是完满的，所以零代码开发平台也会有一些劣势所在，而它的劣势也是相对来说，正确来讲是绝对于传统开发来说，零代码搭建的自在水平无限，所以对于某些说零代码开发平台能代替程序员的人来说，这相对是一种误会。低代码只是一款工具，提高效率的工具，它的作用不是代替程序员，而是帮忙程序员晋升开发效率。所以零代码开发平台的定位从上市以来就很显著，次要就是为了高效的解决传统信息化速度的滞后问题。 六、企业如何抉择零代码开发平台 最初局部，对于零代码开发平台的选型问题，这里举荐几个选型参考维度供大家参考： 1、产品性能 市面上低代码、零代码开发平台很多，尽管都叫低代码/零代码，然而其实他们也有一些不同之处，或者说他们的侧重点不一样，倡议大家在抉择之前，先去理解一下零代码厂商的解决方案、客户案例。这样能有利于晓得该产品到底适不实用。 2、零碎性能 作为一款零碎来说，其性能是最重要的一部分，一款好的零碎，通常在安全性和稳定性方面会有显著劣势。目前很多零代码厂商都会有SLA协定（次要是为了测试其零碎稳定性的一种证实），抉择之前能够理解一下该零代码厂商是否具备这方面的文件。 3、产品价格 价格个别是企业购买零碎必须要理解的内容，而零代码开发平台的价格个别是依据企业应用的人数，和定制需要所决定的。所以企业在购买前，肯定要搞清楚本人的需要以及多少人要应用等问题。而且倡议企业切勿抉择价格太低的零代码产品，因为价格低的产品，个别所能保障的内容就少。 4、应用体验 当初市场上的零代码开发平台基本上都提供收费试用的产品，所以企业在购买之前肯定要自行体验一番，看看该产品是否合乎本人的需要，再做定夺！ 5、服务水准： 企业购买零碎相对不是一锤子买卖，企业一旦购买对其日后的倒退也会有肯定的影响，所以，在购买前能够在试用期间，顺便理解一下零代码开发平台的服务水准，如果遇到零碎问题对方能及时解决，或者正当的给出解决方案。那么在这根底之上，企业还需综合以上内容的其余几个方面，再决定是否对其产品进行购买。 正当并且无效地使用零代码开发平台，不仅能够让咱们工作高效地运行，还能最大水平保障团队指标的达成。我举荐应用织信Informat，它内置100多个利用模板并笼罩：OA、ERP、CRM、绩效、人事、企业服务、集体及组织等多个利用场景。点击一键装置，即可收费试用。当初注册可享受一生收费应用权利。同时还能体验在线搭建性能，是帮忙企业开启数字化转型的重要引擎。

摘要：麻利与平安仿佛矛盾，但如何共存？本文将为你解读从“利用麻利”到“利用麻利+平安”的实现门路。起初，企业以传统的瀑布式研发模式把软件开发过程划分为需要、剖析、设计、开发、测试等不同的流程。这些流程有着严格的先后秩序之分，只有当后面的流程完结之后，下一个流程能力开始运转。这种开发方式好似瀑布的着落，由此命名为瀑布模型。 但随着业务的倒退，研发模式也在产生了一直的演进，传统基于阶段的瀑布研发过程，导致当开发对于迅速变动的业务响应重大滞后，为此业界提倡通过麻利的形式，疾速迭代，小步快跑，继续集成，被动拥抱变动。 麻利开发以用户的需要进化为外围，采纳迭代、循序渐进的办法进行软件开发。把一个大我的项目分为多个互相分割，但也可独立运行的小我的项目，并别离实现，在此过程中软件始终处于可应用状态。 现在，随着挪动互联网的迅速倒退，利用从需要到上线的TTM（Time to market）越来越短，普遍存在的开发和运维的“凌乱之墙”成为了断裂点，为此业界开始提倡DevOps的合作模式，麻利精益的理念进一步延长到运维侧。同时，随着云原生基础设施的建设和CICD技术的倒退，DevOps已宽泛得利用到各个企业。 从“利用麻利”到“利用麻利+平安”然而随着数字化席卷各行各业，利用进入了咱们生存的方方面面：人与人的互联、物与物的互联、人与物的互联正在成为事实，利用对于人和社会的平安威逼也逐日晋升。因为利用的平安防护和安全意识还广泛滞后，为此以Built-In Security和自动化为根本理念的DevSecOps开始失去器重。DevSecOps的理念在将平安融入麻利过程中，即通过设计一系列可集成的控制措施，增大监测、跟踪和剖析的力度，优化平安实际，集成到开发和经营的各项工作中，并将平安能力赋给各个团队，同时放弃“麻利”和 “合作”的初衷。在这一理念中，企业的整个IT团队指标对立，即在保障麻利开发的根底上，独特背负起平安的责任。 DevSecOps引入自动化平安DevSecOps实际上是DevOps的连续和演进。云原生技术加持下的DevOps使得利用开发和上线周期越来越短，传统的平安团队上线前染指的模式曾经重大滞后，不仅不能无效的进行零碎的平安防护，而且也会影响利用的交付速度。DevSecOps的最要害理念就是强调在利用的全生命周期都内嵌平安，同时提出平安的检测和防护做到尽可能的自动化，将自动化融入平安，实现了品质、平安和速度的最佳均衡。平安应尽可能做到全场景，从基础设施、代码、镜像、到架构，同时须要做到笼罩利用的全生命周期，从开发态、运行态直至运维态。 DevSecOps须要平安工具自动化以及平台化在传统的研发过程中，研发与平安割裂，次要是因为平安影响研发效率，但自动化的平安工具能够实用以后的麻利开发需要。基于平安与DevSecOps的强烈诉求，华为云正在逐渐的将华为20年来深耕平安的能力通过云服务的模式外溢，让更多的企业能共享华为对于平安的先进理念和技术实际，华为云通过让在DevOps的每个环节都通过标准、方法论和自动化的平安服务，来实现DevSecOps的理念，如在创立利用阶段平安框架和编码标准，嵌入IDE插件的代码查看等。上面咱们具体逐个来看华为云所实现的平安工具自动化以及平台化。 平台化：全流程云原生DevSecOps平台华为云提供云原生DevOps平台：华为云DevCloud软件开发平台。华为云DevCloud在业界具备较高的影响力，失去了业余咨询机构和客户的官网认可，在全流程、反对的技术栈与平安可信角度有较强的竞争力，华为云DevCloud为客户提供了从需要/布局到运维的多个服务。 自动化工具与平安无缝连贯代码托管服务是DevCloud为客户提供的稳固、平安的代码治理服务，该服务同时也反对了华为外部1100亿行的代码治理，多个平安可信的措施，多仓协同和高并发。代码剖析和代码查看服务，也是华为自主研发的代码动态查看服务，积淀了华为多年的高质量代码查看规定集，反对的语言多，规范多，同时提供了自动化辅助缺点修复的个性。 代码构建服务，为客户提供了配置及代码的构建服务，反对丰盛的构建语言和框架，同时通过多种技术实现10倍+的构建减速，并提供关闭的构建环境，保障构建阶段的可信平安。云测服务，为客户大规模，高并发，全流程的智能测试服务，提供测试治理，性能测试，API测试，挪动测试等多种业余测试服务，并通过测试设计的智能化，测试执行的智能化和测试剖析的智能化，晋升测试的效率和拦挡问题的比例 同时，华为云在DevOps的根底上，陆续减少平安设计，平安合规，安全检查，和平安防护的业余服务，通过服务化的接口和华为云DevCloud进行深度集成。同时，在已有的运行、运维平安的根底上，进一步全方面的增强网络安全、数据安全、利用平安与数据库安全，让云原生的利用生得平安，活得平安。 而对于企业如何更好的施行DevSecOps，咱们有以下几个实际： 平安可信应该是每个人的责任，而不仅仅只是平安团队关怀的事件。器重架构解耦，架构解耦，低依赖，平安危险和影响范畴更可控。器重自动化和常识协同，一直晋升效率，通过常识分享，组织和集体继续改良。致力打造全功能团队，团队自治，破除部门墙，对商业和用户负责。平安可信+高效麻利从概念提出到当初，云原生所带来的麻利、凋谢、标准化、轻量、松耦合与灵便的劣势是企业数字化转型降级的根底必选项。面对日益严厉的平安威逼和平安影响，云原生加持下的DevSecOps 理念和实际，将平安自动化内嵌到利用的全生命周期，在保障平安可信的同时，也仍然可能施展云原生所带来的高效与麻利。 点击关注，第一工夫理解华为云陈腐技术~

Choerodon 猪齿鱼作为开源多云利用麻利全链路技术平台，是基于开源技术Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益麻利、继续交付、容器环境、微服务、DevOps等能力来帮忙组织团队来实现软件的生命周期治理，从而更快、更频繁地交付更稳固的软件。2020年12月31日，Choerodon猪齿鱼公布0.24版本，本次更新上线了麻利合作中的绩效及甘特图性能，其它功能模块也都进行了不同水平的新增、批改和优化，如代码开发、环境部署等，欢送各位更新体验。 公布版本：0.24公布工夫：2020年12月31日更新范畴：麻利合作、代码开发、环境部署、测试治理、制品库以及根底性能上面就为大家带来具体的模块介绍。 麻利合作新增性能反对关注问题项；新增甘特图性能，以便我的项目管理员进行工作排期； 工作列表问题项反对批量删除；问题项反对关联或新建测试用例；故事地图新增冲刺泳道； 故事地图反对所有字段进行筛选；看板反对一键折叠、一键开展；新增绩效，通过图表展现冲刺的实现状况，以便更好的治理我的项目；绩效性能剖析以后冲刺故事、工作、缺点状况及历史冲刺故事、工作、缺点趋势变动，以便用户更好的理解冲刺的实现状况。 故事点分布图从打算、理论两个维度展现故事点、工作工时次要负责人的数量以及占比；故事实现状况图从故事点、工作两个维度展现次要负责人打算、理论实现比照及百分比；缺点排行榜从非生产环境、生产环境两个维度展现责任人、创建人缺点数量并按降序排列；缺点分布图从非生产环境、生产环境两个维度展现责任人、创建人缺点数量柱状分布图；问题实现趋势图从故事点、工作工时两个维度展现每个冲刺打算、实现数量及顺冲刺的变动；缺点趋势剖析图从非生产环境、生产环境两个维度展现责任人、创建人每个冲刺缺点数量及随冲刺的变动，可通过责任人筛选；性能优化优化故事地图卡片款式；优化看板卡片款式；优化状态机自定义流转；优化问题详情残余问题显示；优化问题复制时同时复制自定义字段的值；优化搜寻栏反对全选、反选、无；缺点修复禁用点击空白敞开弹窗；代码开发新增性能流水线-代码查看工作中新增Maven单测的性能；流水线CD阶段中新增内部卡点的工作，用于触发内部的工作流或其余零碎；应用服务版本新增反对批量删除的性能；性能优化优化了利用流水线树结构中的搜寻，间接筛出含有字段的对象，并进行字体色彩加深；创立与批改流水线的界面新增通过拖拽来扭转阶段与工作的程序 ；优化了流水线页面的刷新加载速度；缺点修复修复了创立流水线，增加工作时，应用服务为空问题；修复了流水线中人工卡点工作，能够抉择没有应用服务权限的成员作为审核人员的问题；修复了利用流水线-CD阶段-部署工作中，不反对批改配置信息的问题；修复了实例视图中，共享应用服务详情中信息的展现问题；环境部署新增性能部署模块新增主机配置性能，反对我的项目人员在此保护治理部署类型的主机；手动部署模块新增主机部署的形式，反对将jar包与Docker镜像间接部署到已有的主机中；集群模块新增“新建集群”的操作，反对通过录入节点来新建集群；集群模块新增反对增减“平台集群”的节点，并反对移除节点中的master或etcd角色；性能优化针对同一集群下的service内部ip及端口，增加了不能反复的限度；缺点修复修复了部署配置页面列表中各个字段排序报错的问题；测试治理新增性能测试计划新增测试报告；制品库新增性能新增maven、npm制品仓库删除性能；新增组织时创立harbor仓库；制品库中容许有的我的项目所有者都能在Nexus仓库中给本人或我的项目成员调配角色；制品库中容许所有Nexus仓库人员都能看到Nexus制品库下载记录；缺点修复harbor初始化脚本空指针修复；saga工作扫描不到修复；根底性能新增性能平台治理与组织治理的安全策略中新增强制用户批改默认明码的设置；组织层与我的项目层的自定义角色新增反对删除的性能；工作台-疾速链接中新增置顶性能，反对将任意链接置顶；工作台-疾速链接中新增集体分组，反对独自查看我的项目或集体的疾速链接；我的项目层新增客户端的创立与治理性能，并反对我的项目所有者在此为客户端调配我的项目角色；性能优化优化了用户创立失败后的操作，此时反对停用此用户；缺点修复修复了平台层工作治理页面，点击浏览器刷新时白屏的问题；修复了LDAP同步记录中同步类型显示的问题；修复了登录Token生效后多标签页弹框的问题；修复了工作台中，偶现最近应用环境反复呈现的问题；修复了音讯铃铛告诉中，流水线的跳转链接有误且点击后报错的问题；修复了我的项目层-告诉-资源删除验证，勾选某个框之后，点击保留，勾选的内容有效的问题；社区参加感激以下敌人在社区论坛中提出反馈和意见，在0.24版本更新中作出贡献，感激大家始终以来的反对。 @zhuozuozhi @hyland 更加具体的内容，请参阅Release Notes和官网用户手册。 装置文档：http://choerodon.io/zh/docs/installation-configuration/steps/ 降级文档：http://choerodon.io/zh/docs/installation-configuration/update/0.23-to-0.24/ 欢送各位朋友通过Choerodon的GitHub和猪齿鱼社区进行反馈与奉献，帮忙Choerodon猪齿鱼一直成长。Choerodon会继续优化，敬请期待。 -▼- 大家也能够通过以下社区路径理解猪齿鱼的最新动静、产品个性，以及参加社区奉献： 官网：http://choerodon.io论坛：https://openforum.hand-china.com/Github：https://github.com/open-hand/choerodonChoerodon猪齿鱼官网社区用户交换群，此群可交换猪齿鱼应用心得、Docker、微服务、K8S、麻利治理等相干实践实际心得，群同步更新版本更新等信息，大家能够加群探讨交换。 ①-Choerodon猪齿鱼官网交换（已满）； ②-Choerodon猪齿鱼官网交换（可加）；【微信号发至客服邮箱choerodon@vip.hand-china.com，经营共事拉您入官网交换群】 欢送退出Choerodon猪齿鱼社区，独特为企业数字化服务打造一个凋谢的生态平台。

摘要：麻利软件开发理念已慢慢被业界广泛承受，越来越多的公司和团队不得不面对一个新的问题，就是规模化麻利的引入和实现。目前市场上规模化框架次要有SAFe，Less，Scrum of Scrums, Spoity等等。其中SAFe是应用最宽泛的规模化麻利框架，那么SAFe到底是个什么东东呢？这篇文章中将为大家解说。SAFeSAFe是什么SAFe（Scaled Agile Framework，大规模麻利框架），是一个在线的知识库，该知识库具备通过验证的集成准则、实际和能力，可大规模施行精益、麻利和DevOps。 SAFe倒退历史2011年，SAFe第一版由Scaled Agile公司创始人Dean Leffingwell在scaledagileframework.com网站公布，截止到2019年10月，SAFe曾经更新至5.0版本。 SAFe外围价值观协调一致领导者通过建设和表白投资组合策略和解决方案愿景来传播工作，在打算期间确定业务价值，并领导范畴的调整以确保需要与能力相匹配。 内建品质领导者通过创立内建品质成为规范的环境来扭转零碎并展现承诺。 通明领导者促成所有相干工作的可视化，并发明一个环境：“...事实总是敌对的，在任何畛域中人们能够取得的每一个证据都使人们更加靠近事实。” 我的项目群执行领导者作为企业所有者参加打算增量（PI）的布局行业执行，在踊跃打消阻碍和消极因素的同时，庆贺高质量的产品增量。 SAFe的准则 SAFe外围能力l 精益麻利领导力l 团队和技术麻利l DevOps和Release on Demandl 商业解决方案和精益系统工程l 精益解决方案治理SAFe的配置SAFe反对各种开发环境，具备四种开箱即用的配置。别离是： 必不可少的SAFe配置Essential SAFe配置是所有SAFe配置的根本构建块，是最简略的实现终点。它提供精益麻利领导能力，团队和技术敏捷性能力，以及DevOps和按需公布能力。 SAFe以一个名为麻利公布培训（ART）的组织构造为根底，麻利团队，要害利益相关者和其余资源致力于一项重要的，继续的解决方案工作。 大型解决方案的SAFe配置大型解决方案SAFe配置引入了业务解决方案和精益系统工程能力，反对那些构建最大，最简单的解决方案，这些解决方案须要多个麻利公布列车和供应商，但不须要组合级别的思考因素。 这种解决方案的开发对航空航天和国防，汽车和政府等行业来说很常见，因为大型解决方案 - 而非投资组合治理 - 是次要关注点。 解决方案培训组织构造可帮忙企业应答最大的挑战 - 构建大规模，多学科的软件，硬件，网络物理和简单的IT零碎。开发这些解决方案须要额定的角色，工件，事件和协调。 投资组合SAFe配置Portfolio SAFe配置提供精益我的项目组合治理能力，使组合执行与企业策略保持一致。它通过一个或多个价值流围绕价值流组织倒退。 投资组合SAFe通过投资组合策略和投资资金，麻利投资组合经营和精益治理的准则和实际提供业务敏捷性。 残缺的SAFe配置残缺的SAFe配置包含精益企业的所有五项外围能力。它是框架的最全面版本，反对构建和保护大型简单解决方案组合的企业。 对于SAFe的更多理解请移步到咱们的华为云DevCloud业余服务，服务中蕴含SAFe的系统化培训课程，并提供了相干认证，更有资深专家的亲自领导。 此外，DevCloud业余服务还提供了开发者的相干能力评估，参加评估大可得奖，并能点亮象征着荣誉的开发者勋章，赶快来吧~~~~ 流动详情：【开发者福利季】开发者身份评测认证，点亮勋章享大礼 本文分享自华为云社区《想尝试规模化麻利的同学请留步~》，原文作者：麻利的小智 。点击关注，第一工夫理解华为云陈腐技术~

摘要：新的一年行将开始，你在2020打算实现的事已实现了多少？咱们晓得，很多人会在新年伊始满怀期待的做打算，并致力做好工夫治理，然而当打算赶不上变动的时候，往往会措手不及，一再耽误。因而咱们须要明确“响应变动高于遵循打算”的准则。那么如何维持这两者之间的均衡，高效的实现一件事，这个问题也正是这篇文章所要和大家分享的，如何在麻利开发中做打算，即麻利布局。一个人不能没有生存，而生存的内容，也不能使它没有意义。做一件事。说一句话，无论事件的大小，谈话的多少，你都得本人先有了打算，先问问本人做这件事，说这句话，有没有意义?你能这样做，就是奋斗根底的开始奠定。——戴尔·卡耐基 2020年马上就要过来了，很多公司和团队以及集体都陆续着手这整年工作的演绎和总结，与此同时也开始对新的一年的瞻望。从小编上大学开始（那如同是一个很长远的时候……），大家会在QQ空间或者QQ签名上写一些很正能量的话以必定本人一年的致力和激励本人在新的一年能百尺竿头更进一步。当然很多有心人不仅是心怀美妙期盼，而且还做了新一年的打算，比方，应用近些年来比拟风行的bullet journal——子 弹笔记。子 弹笔记能它能让你在短时间内找到最重要的事件，高效的做好工夫治理，辞别自觉的做事件。在记录的时候，记得都是关键词或短句子，并且配合着肯定意义的符号有条理的排列内容，给人一种简洁和清新的感觉。 -------图片来源于网络 子 弹笔记之所以被寰球范畴所推广和认可正是认为这样简洁、高效的做打算的形式，其实这也正是遵循了事实的生存状态，即咱们须要高效的同时，正每时每刻不再面临着变动，而详尽简单的打算往往只是费劲不讨好。这在软件行业中也是一样的。 原来的瀑布式开发的形式曾经无奈适应当今疾速的变动，详尽周密的打算必然无奈指引软件走出VUCA时代所带来的“光明”，而麻利开发的形式应时代所需势在必行，因为在麻利宣言中就提出了“响应变动 高于 遵循打算”的口号。可能有些读者会有疑难说“难道麻利就不做打算了吗？”，其实不是这样的。麻利一样须要做打算。那么有些读者可能又会问“不是说响应变动高于遵循打算吗？怎么还做打算呢？”其实麻利宣言不是说不做打算，而是说相比做打算更有价值的是响应变动，所有以变动为根据。那么有读者可能又会问“既然当今世界无时不刻不再变动，你如果响应了变动还怎么做打算呢？”很快乐有读者会有这样的疑难和思考，而这个问题也正是这篇文章所要和大家分享的，如何在麻利开发中做打算，即麻利布局。 什么是麻利布局麻利布局是一种逐步欠缺过程的布局办法，是对价值的探究过程。布局为一个概括性的我的项目开发问题“咱们要构建什么？”找到最佳的答案，这一答案综合了性能、资源和进度三个方面。布局应该足够牢靠，能够用来作对该产品和我的项目进行决策的根底。麻利布局更关注布局过程而不只是建设一个打算。它激励批改、产生易于批改的打算，并且连续到整个我的项目过程。 麻利布局无效的起因常常进行从新布局在不同档次上制订打算基于性能而不是基于工作制订打算小故事放弃工作晦涩每次迭代都要打消解决中的工作在小组档次跟踪抵赖不确定性并为之做打算麻利布局和传统布局的区别麻利布局谋求实在需要，反复初始打算麻利团队开始时对我的项目的愿景有一个初步的探讨，之后用原型进行迭代。干系人能够在原型的根底上对我的项目进行反馈和调整。而在瀑布打算中，范畴和解决方案还没有确定就须要干系人对我的项目进行具体的阐明和反馈。麻利通过原型来更好的了解相干畛域，并以原型为根底进行进一步的打算和细化，这也体现了渐进明细的概念。 麻利布局贯通于整个我的项目中，不仅仅是后期的工作传统布局中强调后期打算的重要性，次要集中在我的项目范畴布局、工夫布局、老本布局、品质布局、人力资源布局、沟通布局、危险布局、洽购布局、干系人布局以及变更治理、配置管理和过程改良等相干打算上。这些过程都在我的项目开始之前就须要执行。麻利恰恰相反，麻利认为知识型我的项目的危险等级和不确定性使得后期打算呈现了许多问题，所以麻利办法提倡在整个我的项目生命周期中都进行布局，会有不同档次和具体水平的打算。然而， 麻利认为后期打算是很有必要的，只是不宜适度，须要找到一个平衡点，既要做好足够的后期打算以缩小大量反复和返工的危险，也能防止适度打算导致ROI降落以及多变的我的项目打算。 麻利布局是挪动打靶，须要及时调整中期打算当指标是静止的时候，能够做很多打算，从而向着那个静止指标致力后退，当指标是挪动的时候，就更加须要作出大量中期调整以保障指标达成，相似挪动打靶。为了达成指标，麻利办法应用了简单的探测和适应零碎去获取反馈并作出调整。 麻利布局的准则假如当时无奈制订完满的打算当时布局有帮忙，但不宜适度最初责任时刻再敲定打算关注调整与从新布局胜于与遵循打算正确治理WIP提倡更小、更频繁的公布疾速学习布局并在必要时候调整方向麻利布局的办法布局各层级打算，明确产品开发的方向在麻利办法中，晚期的打算是必要的，但有可能是不太完满的。不确定性导致了反复打算的必要性。为了体现适应性打算的特点，别离为：麻利愿景、产品打算、版本打算、迭代打算、每日站会打算。打算的档次体现了渐进明细的特点，渐进明细的最终目标是为了交付与原始设计对象统一的产品。五层打算体现了在麻利我的项目中一些细节不断涌现，须要依据反馈从新排序优先级，从而调整整个我的项目。这一点体现了麻利宣言中的最初一条“响应变动胜过遵循打算”。五层打算如下图所示。 定义愿景布局洋葱图的顶端是愿景层。产品愿景要分明形容从哪些方面为用户或者客户之类的利益干系人提供价值。这一层是定义产品要解决的首要问题和产品的指标人群。思考这些问题有助于理解产品为用户带来的真正价值，和如何让产品与其余试图解决雷同问题的产品区别开来。 确定产品概要列表和路线图开始时必须产生一些最根本的需要来填充产品列表，在确立列表之后，建设一个产品路线图。路线图要有时间轴、版本号和对应的个性性能信息。路线图能够示意产品随着工夫的推移如何以增量形式构建和交付，以及驱动每一个版本的重要因素。 制订版本打算依据产品路线图的工夫路标从产品列表中选取适当的个性进入对应的版本打算中。版本布局是次要针对增量交付获得范畴、日期和资源之间的均衡。每个企业和公司都须要有一个适合的节奏，有法则的向客户交付产品个性。迭代完结的可交付增量是潜在可公布的，是否公布要根据组织的公布节奏。通常的公布节奏有三种。 在实现每个冲刺后公布：让公布和迭代的节奏保持一致。 在实现多个冲刺后公布：将多个迭代的后果合并为一个版本进行公布。 在实现每个个性后公布：不思考迭代是否完结，做完一个个性就公布一个，这就是通常所说的继续公布。很多企业和公司实现一个个性后就马上向局部或者所有客户公布个性，十分频繁，有时可能甚至一天公布很屡次。 制订迭代打算迭代打算聚焦于实现本迭代所应开发的用户故事的具体工作以及工作的下发。一个迭代是一个较短的研发周期，通常继续2-4周。团队从产品列表中抉择排序较高的用户故事纳入以后迭代中进行开发。制订迭代打算是为团队抉择本迭代要实现的需要或工作。 每日打算在每日站会中，团队成员聚在一起，每个人顺次讲述本人在上次每日例会后做了什么，明天筹备做什么，是否遇到了任何妨碍。团队通过每日站会的模式评估本人的状态，以一种十分直观的模式通知大家当天打算做什么，这也能够让团队尽早辨认危险。尽管晚上的这项典礼开始于对前一天的成绩的探讨，但胜利的团队会意识到每日站会是探讨打算的会议，而不是探讨状态的。因而，每日站会应该专一于制订一个每日进度的打算。 最初以图的模式总结在这些级别产生的工件及其相互之间的分割。 继续调整布局，保障产品的价值在麻利的整个层级布局中，是一个继续布局的过程，团队会一直依据过程中的所学所获来逐步完善打算；这种办法使团队在短期内就能明确责任，同时帮忙他们理解本人的责任是如何推动长期指标的实现的。布局洋葱图的每一个档次都不止执行一次，而是在产品的整个生命周期中屡次执行。不过，每层执行的频率取决于该层的地位。一般而言，最常布局的是较低的级别，随着向更高级别的迈进，你将逐渐减慢你打算的步调。比如说，你要常常、乃至每天做日常布局，但你可能只须要每隔几个月甚至一年才从新扫视你的产品愿景。 在麻利产品整个开发过程每个阶段都是继续进行的，联合开发过程图咱们了解一下麻利中的继续打算，过程图如下所示。 通过流程图能够看出，先制订一个后期打算，通常是以后迭代以及将来2-3个迭代的工作是明确的；而后尽早实现并公布给客户获取反馈；依据反馈及时进行打算，对后期制订的版本打算和产品路线图进行调整，不停的在后期打算和及时打算中寻找均衡，保障团队的指标始终是给用户带来价值，从而保障产品的价值。 麻利布局的工具工夫盒工夫盒是固定的一段时间，绝对比拟短，打算的工作要在这段时间内实现。麻利比拟关注工夫盒的概念，比方：一个迭代的工夫盒是2-4周，一个迭代的打算会议是2个小时，一个回顾会的工夫盒是1个小时，一个站会的工夫盒是15分钟。工夫盒的完结点能够视为一个检查点，采纳工夫盒的形式给整个麻利我的项目的施行提供了频繁的检查点，通过后果评估、获取反馈、管制老本、治理危险来监控外界变换的不稳固的环境，从而测量进度并且从新打算进行中的工作。 渐进明细渐进明细是一种滚动式布局的技术。 在PMI编制的PMBOK中，是一种对进度计划编制的技术，是指在我的项目过程中，随着信息越来越具体，估算越来越精确，继续改良和细化打算。细化是量化的根底，逐渐细化咱们的工作，能够晋升我的项目打算的指导意义。 最小可售性能（MMF）最小可售性能（MMF）是一个最小和可市场化的软件特色或者产品特佂，能够疾速开发并为用户提供重要的价值。互联网时代的竞争中，第一个占领市场就能够抢占先机，即使这个性能可能还不齐备，仅具备局部可用的性能。最小可售性能代表性能包足够残缺到能够为用户或者市场提供价值，同时也足够小。在软件我的项目中，增量交付的形式让客户能够更早地获取可用性能，从而晚期受害。增量交付在帮忙团队取得晚期投资回报的同时，也取得了晚期的反馈，给后续性能开发提供了参考。 怎么样，各位读者敌人，鱼和熊掌是不是能够兼得啦。在麻利的开发中兴许你还有会这样或那样鱼和熊掌的问题，那无妨来华为云的DevCloud业余服务转转，这里不仅提供了解决方案还有各种能力评估呢！ 在业余服务中针对不同的岗位提供了评估的能力，让开发者能够对号入座，并基于你所在的岗位、技术失去主观、全面、零碎的测评以及名师般的学习疏导。 快来拜访业余服务平台，通过集体能力评估，看看本人是什么程度吧！ 点击关注，第一工夫理解华为云陈腐技术~

舒适揭示：本文约3000字，须要浏览5分钟，共分为8个局部，倡议分段浏览！软件开发过程中，从产品概念造成到产品布局、往往要做具体的需要剖析和我的项目布局等，因而，选对一款项目管理工具对开发者就显得尤为重要。 明天咱们一起来理解下华为云DevCloud项目管理（Scrum我的项目）是如何做到需要布局以及工作项合成的！ 华为云DevCloud项目管理（ProjectMan）是为软件开发团队提供麻利项目管理与合作的云服务，积淀了华为30多年软件研发的先进理念与丰盛实际。项目管理反对麻利Scrum治理，Scrum我的项目交融麻利设计理念，可疾速实现麻利迭代打算、创立工作工作，直观出现每日站会看板、缩短迭代周期、晋升项目管理效率。项目管理提供迭代性能，能够用来做版本打算治理，在我的项目里设置迭代，匹配版本公布打算工夫点，便可对版本打算进行跟踪治理。 阐明：DevCloud项目管理分为“Scrum我的项目”和“看板我的项目”，以下仅讲述“Scrum我的项目”的需要布局与合成过程。 Scrum我的项目需要布局与合成过程上面咱们将其分成八个局部来说说。 什么是Scrum？实用场景有啥劣势？通过需要的分层和合成，多角色合作，确保需要范畴可调整按迭代继续交付，实现闭环反馈Scrum我的项目需要合成过程DevCloud如何应用Scrum我的项目？写在最初什么是Scrum？Scrum是迭代式增量软件开发过程，通常用于麻利软件开发。Scrum包含了一系列实际和预约义角色的过程骨架。Scrum中的次要角色包含同项目经理相似的Scrum主管角色负责保护过程和工作，产品负责人代表利益所有者，开发团队包含了所有开发人员。 以下是一些Scrum的通用实际： 客户成为开发团队中的一部分，例如客户必定对开发的后果真正感兴趣，和所有其余模式的麻利软件过程一样，Scrum有频繁的蕴含能够工作的性能的两头可交付成绩。这使得客户能够更早的失去能够工作的软件，同时使得我的项目能够变更我的项目需要以适应一直变动的需要。频繁的危险和缓解打算是由开发团队本人制订。在每一个阶段依据承诺进行危险缓解，监测和治理（危险剖析）。打算和模块开发的通明。让每一个人晓得谁负责什么，以及什么时候实现。频繁的进行所有相干人员会议，以跟踪我的项目停顿。均衡的（公布，客户，员工，过程）仪表板更新。所有相干人员的变更，你必须领有预警机制，例如提前理解可能的提早或偏差。没有问题会被藏在地毯下。意识到或说出任何没有预见到的问题并不会受到惩办。在工作场合和工作工夫内必须全身心投入。实现更多的工作并不意味着须要工作更长时间。实用场景强烈的市场竞争或客户需要变动快，产品或我的项目存在较大不确定性。 举荐倡议：采纳反对麻利开发模式的研发治理平台，短周期继续交付，疾速响应需要和市场变动。 有啥劣势？业余方法论与实际的承载： 承载麻利治理、精益的软件项目管理理念。反对Scrum我的项目和看板我的项目模板，面向不同的软件治理场景，兼顾规范和轻量灵便的软件开发场景。反对Scrum举荐的需要布局和需要合成档次。反对麻利迭代开发、迭代打算和工夫线清晰展示我的项目停顿。通过需要的分层和合成，多角色合作，确保需要范畴可调整客户的需要或原始需要，往往是形象甚至宏观的，须要了解客户需要背地的问题实质，将客户需要或原始需要进行布局和合成，最终合成为每个迭代可交付的最小工作项。 项目管理服务Scrum我的项目类型中，预置了麻利实际中举荐的Epic-Feature-Story/Bug-Task的四层模型。 从原始形象宏观的需要Epic（中文通常翻译为史诗个性），通过合成为多个Feature，继而再逐渐合成为Story。Story是UserStory的简称，Story是站在用户视角合乎INVEST准则的最小可交付的工作项单元。一个Epic合成为一个或多个Story，并依据开发团队的人力管道和Epic的打算工夫，将Story布局到一个或多个迭代中继续交付。 一个宏观形象的Epic通过这种形式保障了每个迭代都有能够运行的软件让用户试用，获取用户反馈，一直依据反馈进行修改，最终满足用户的需要并取得商业胜利。 阐明：理解Epic（策略动作）、Feature（个性）、Story（用户故事）、Bug（缺点）、Task（工作）具体阐明请看这里。 按迭代继续交付，实现闭环反馈在麻利软件开发的语境下，迭代是重复式的继续交付并继续获取反馈的软件开发流动，其对应的是瀑布式软件开发中的固定程序全副实现才交付的软件流动。 每一个迭代都谋求尽可能的公布产品并获取用户的反馈，每次迭代获取的反馈都同时作为下一个迭代的改良输出。迭代能够升高危险和变更老本，晋升研发效率。 在麻利的方法论中，通常应用“迭代”，而Scrum实际中应用“冲刺（Sprint）”，两者有渺小的区别。项目管理服务思考国内用户的应用习惯，应用“迭代”。 Scrum是麻利开发的支流办法，通过迭代冲刺的形式，继续交付，从用户需要到用户反馈实现每一个闭环的软件开发过程。通过最重要的迭代打算会议、每日站会、迭代回顾、验收会议来进行简略高效的治理。 Scrum我的项目需要合成过程项目管理服务对Scrum我的项目的需要进行统一规划，以思维导图的模式进行需要布局和合成，行将工作项的层级构造展现进去，更直观的展现父子关系，在布局中新建工作项后，会主动生成到工作项列表中。 我的项目中已创立的工作项，依据所隶属的Epic根节点，会主动同步到工作项页面。依照工作项类型层级关系（从大到小顺次为“Epic > Feature > Story > Task/Bug”类型）进行需要布局，具体为增加Epic类型工作项、给Epic工作项增加Feature类型子工作项、给Feature工作项增加Story类型子工作项。为了疾速实现产品外围性能，并尽快上线，尽早收集用户反馈，将产品的各个Feature中最能体现用户价值的Story设置为“高”优先级。 确保将产品的基本功能买通上线，而不是对某一个Feature做适度设计。 项目管理服务为用户提供思维导图式需要布局与合成性能： 同时也提供迭代治理与布局的性能： DevCloud如何应用Scrum我的项目？看完上述介绍，置信大家对项目管理的需要布局与合成性能曾经有很多理解了！接下来给大家讲讲布局需要与合成工作项的具体操作过程吧~~ 样例：开发人员A是公司的项目经理，须要进行商城治理，业务方向为订单治理、会员治理和促销治理。操作步骤如下： 步骤1：在DevCloud项目管理中新建Scrum我的项目 登录DevCloud控制台，在左侧导航中抉择“项目管理”，单击“立刻应用”。 在进入的DevCloud项目管理首页，单击“新建我的项目”。 在“新建我的项目”页面，我的项目类型选中“Scrum”。设置我的项目参数，单击“确定”，实现Scrum我的项目的创立。 步骤2：在Scrum我的项目中进行思维导图布局 在Scrum中，能够依据理论须要以思维导图模式设置不同层级的工作项。 单击项目名称，进入我的项目详情页面，抉择“工作 > 布局”，单击“思维导图布局”，进入思维导图布局页面。依据需要布局筹备，给每个层级的工作项增加子工作项，顺次为“Epic > Feature > Story > Task/Bug”。在不同或同层级之间拖动工作项，能够调整布局需要，整个需要布局后果如下： 阐明：有子工作项的工作项，不能调整到Task层级，否则会超出层级。无子工作项的工作项能够往上或往下一级别类型调整。 步骤3：在Scrum我的项目中给工作项安顿迭代开发计划 在我的项目详情页面，抉择“工作 > 工作项”，能够查看需要布局中所有工作项状况，能够通过工作项类型筛选出对应类型的工作项，如Story、Task、Bug。 抉择“工作 > 迭代”，依据须要在我的项目里新建迭代，或应用默认的迭代1、迭代2和迭代3亦可。 分迭代能够治理需要布局中所有Story工作项，默认显示以后迭代工作项。依据匹配版本公布打算工夫点，选中左侧“未布局工作项”，将工作项别离拖拽至对应的已布局迭代中。 至此，所有需要布局与工作项合成已实现，管理者再依据理论人力安顿，给各个工作项调配解决人，按计划点闭环工作项即可。相干操作如下： 增加我的项目成员批量设置工作项解决人迭代回顾相干操作的具体操作步骤，请查看《项目管理用户指南》。 写在最初产品需要布局与工作合成很重要，且要随时能响应客户需要，而不是一味的迭代开发！心愿能帮忙大家实现一个个开心，高效，信念满满的我的项目开发：） 本次就分享这么多，大家还想理解些啥，欢送在评论中留言。 点击关注，第一工夫理解华为云陈腐技术~ ...

摘要：任何工具或者流程如果让人们在本人的工作环境中感到举步维艰，那它就不能被称为麻利，只能称之为“伪麻利”。《2020年麻利状态报告》中显示，现今许多组织还在学习如何施行麻利。受访者中也有大概50%的人示意，他们的团队中只有不到一半的人在应用麻利，而其中仍有高达84%的人抵赖他们的组织没有达到高水平的能力。 一部分公司或团队在践行麻利后获得了微小的胜利，让更多的人趋之若鹜，纷纷转型麻利。但转型麻利绝非易事，在这一过程中，最常见的问题就是团队并未真正了解麻利准则及外围价值观，而是一味地照猫画虎。天然，照猫画虎最终还是失败了，这时候通过这一系列变动的团队或成员就开始大肆宣扬“麻利无用论”：搞那么多虚头巴脑的招式，只会节约更多的人力物力财力，减少工夫老本，到头来没有什么实质性的用途。然而，真的是麻利无用吗？还是你用错了麻利？ 麻利宣言的次要内容是： 个体和互动高于流程和工具；工作的软件高于详尽的文档；客户单干高于合同会谈；响应变动高于遵循打算。但在很多公司中，团队打着“麻利”的旗号，实际行动却重大偏离麻利宣言及价值观，最初往往“欲速则不达”。麻利宣言合著者Robert C. Martin承受采访说，任何工具或者流程如果让人们在本人的工作环境中感到举步维艰，那它就不能被称为麻利。因而，这些仅披着一层“麻利”外壳的团队，只能称之为“伪麻利”。 当团队或者公司踏入“伪麻利”的怪圈时，如何发现这一问题，就是咱们要去解决的问题了。 什么是伪麻利？ 1.极其的麻利1）“麻利”并不是一味的“快” 谈到麻利，作为一种轻量级办法，很多人误认为麻利就是“快”：快速反应、疾速交付。因而整个团队只顾谋求速度，认为“工夫紧工作重”，以致于为了谋求速度而不得不放弃品质。这种以疾速交付为重心的产品无奈满足客户的需要，甚至无奈通过测试的品质鉴定。 2）“麻利”并不是一味的“简洁” 麻利十二准则中第10条为“以简洁为本，竭力缩小不必要工作量的艺术”。有的人就会说了，既然要提倡简洁，那么就把不必要的流程简化吧：每日站会太浪费时间了，减掉；回顾会议毫无意义，减掉；筹备文档太简单了，减掉；麻利提倡响应变动，所以不须要打算会议了，减掉……相对主义者往往会感觉既然要简化就简化的彻底一些，就要进行大刀阔斧的改革。然而在一通乱裁之后，真正有价值的货色被“淘汰”了，留下一群摸不着头脑的程序员在反复繁琐的工作中持续敲代码。 2.僵化的麻利1）站立会议 每日站会是麻利团队进行工作互通的桥梁。每日站会不须要团队成员对本人的工作内容作出详尽而清晰的报告，只须要用两分钟的工夫进行一个简略的陈说，总时长个别在15分钟左右。这里的15分钟只是一个大略的工夫，具体工夫会依据每个团队的成员数量以及工作性质而变。在麻利的实际过程中，一些团队将站立会议的概念混同，只是死板地遵循15分钟会议工夫的规定，不管团队成员数量多少，要求必须在15分钟内完结。 一旦会议工夫被刻板化，这会给团队成员减少很大压力，促使他们不得已找些零零碎碎的工作来搪塞会议，因而也就无奈达到每日站会促成团队外部交换的目标。 2）看板 麻利团队中通常利用看板帮忙团队实现工作可视化、工作状态透明化，激励团队成员工作、进步工作专一力及效率。然而在设置看板后，也会一个很大的缺点：看板处于半闲置状态，无奈失去及时更新，团队成员无奈从看板中获取响应的信息。这样的后果就是：看板成为了一个代表麻利的陈设。负责人在汇报工作的时候，一指墙上的看板：看，咱们团队在转型麻利。但实际上，麻利的观点有没有深刻贯彻，除了团队外部成员，其余谁也不晓得。 3.传统型领导的麻利之前写过一篇对于规模化麻利改革的文章，文中强调了在团队转型规模化麻利之前，首先须要领导者转型麻利。同样，在传统团队转型麻利的过程中，也须要领导者率先转型麻利，具备精益麻利思维。只有精益麻利的领导者能力通过开掘、利用团队和集体的短处推动团队的麻利化。 我曾理解过这样一家公司，领导者思维连续着传统的瀑布式开发模式。当整个团队开始转型麻利的时候，领导仍在提倡开发流程的前后连续关系，导致团队在施行麻利开发的小周期迭代时遇到很大的阻力，整个团队呈现出一种“高不成低不就”的状态。如果公司外部都没有达成对立的麻利转型态度，这时的麻利团队就会举步维艰。 因而，要想突破麻利转型成果不佳的“咒骂”，就要敢于冲破团队现行模式的枷锁，识破团队中的“伪麻利”景象，依据团队的理论状况适当扭转策略，真正做到让麻利“活”起来。 点击关注，第一工夫理解华为云陈腐技术~

摘要：产品经理、开发、测试、运维、终端用户……DevoOps给这些角色带来什么劣势？企业每天都面临着疾速变动和高要求。当初的主力消费者比他们的上一辈对企业有着变幻无穷的要求和更高的冀望。日益强烈的竞争意味着企业必须迅速而明智地采取行动，以保住本人的市场份额。企业一直与竞争对手竞争，致力为客户提供最好的产品。许多艰难的根本原因是不足沟通，对于许多公司来说，DevOps是解除窘境的办法。 依据RightScale 2016年对1060名IT专业人士进行的云端状态考察，81%的大企业和70%的中小企业报告采纳了DevOps。这种麻利思维办法波及到客户、产品治理、开发人员、QA和其余角色之间的合作，以便向更好的产品、服务和零碎后退。 DevOps带给不同角色的劣势是什么？开发人员没有采纳DevOps的开发人员可能会对构建和部署流程的日常工作感到丧气。因为不得不一遍又一遍地实现雷同的工作，他们会没有工夫进行翻新。 而当有了DevOps和自动化，那些枯燥反复的工作就能够被打消！没有了这些耗时性我的项目，开发人员能够领有更多的工夫做本人喜爱的事件：研发。花更多的工夫翻新、更少的工夫修理和保护是一种胜利。 不想参加软件的运维？随着DevOps买通筒仓，减少单干，这种状况也在不远的未来向你招手了。 运维人员对于运维来说，在未采纳DevOps前，典型问题之一是从开发人员那里获取随机的、通常是错误百出的代码。因为沟通很少，达成决定须要更长的工夫，也会让工作更加艰难。运维所关怀的是保护环境的稳定性，但这很难做到。 有了DevOps，运维人员在计划外工作和返工上破费的工夫缩小了22%。这次要是因为减少了与开发人员的交换。更好的代码、共享的代码库和更稳固的操作环境使工作更加轻松。 自动化和继续集成容许在不威逼稳定性的状况下交付新性能。 产品经理当你的产品和服务须要更长的工夫能力制作进去并付诸行动时，你就很难战胜你的竞争对手。当你的软件有谬误时，这尤其艰难。 DevOps激励合作环境。当在生产过程中有更多的交换，产出是更好的产品。当每个人都保持一致时，最终交付的产品肯定会更好。DevOps带来的46倍的软件部署频率和440倍的变更前置工夫会让运维的工作更加轻松。 系统管理员要高效地治理一个从不沟通的团队简直是不可能的。不足沟通使工作变得艰难，因为软件有谬误，反馈不及时，可见性低。 合作是DevOps的要害因素之一。沟通会带来更好的产品和更好的零碎。此外，它们的治理也不那么简单。自动化缩小了人为谬误，且可使故障更改率升高3倍。 DevOps还减少了整个软件开发过程的可见性。当可能检测谬误、定位其本源并发现起因时，就能够迅速修复问题。DevOps使得故障修复速度快96倍。 测试工程师如果你不晓得问题是哪里产生的，是谁造成的，就很难解决问题。当找不出问题，无奈解决问题，并且晓得每一分钟都意味着越来越多的人感到不不便（可能还会为此懊恼）时，压力就来了。 DevOps容许更快地解决问题。进步可见性和沟通对于解决问题至关重要。工程师能够应用实时数据来解决问题并理解应用程序更改的影响。当呈现问题时，解决方案施行得越早越好。如果一个Bug变得太深，就更难修复了。 QAQA的工作是确保产品和零碎都运行良好，但这并不意味着他们喜爱谬误缠身的软件和过程。如果没有沟通、合作和自动化（DevOps的所有支柱），谬误就会泛滥成行。 有了DevOps，团队成员能够一起工作来生产更好的产品，自动化能够缩小容易防止的人为谬误。后果就是呈现更少的谬误。并且，因为继续的集成、继续的交付以及频繁的小更改，谬误也更小更容易修复。DevOps用户报告说，修复平安问题的工夫缩小了50%，故障复原速度放慢了96倍。 客户服务任何在服务行业工作过的人，无论是在餐馆、批发还是客户服务，都晓得与不满的顾客打交道的苦楚。当零碎呈现故障和谬误时，用户会很不快乐。当然故障不是你发明的，但你必须解决它们。 DevOps会导致更少的谬误，这意味着用户的应用体验更加舒服。尽管依然会接到用户的投诉电话，但这只会越来越少。此外，用户也不会因为重复经验雷同的故障而火暴。 一个更具协作性的环境意味着你的工作更容易。 终端用户扭转的意义是为了更好的用户体验。采纳DevOps不仅为本人简化了流程，这也意味着将有更多的工夫为客户做出更多的改良。 DevOps通过改良流程和应用程序使最终用户的体验更加统一。总的来说，让互动更欢快。 所有角色都受害！综上所述，每个人都受害于DevOps的一些基石，如继续集成、继续交付、公布自动化、测试自动化和合作。继续集成简直打消了产生大故障或谬误的可能性。自动化流程打消了繁琐的手工工作。合作创立了一个协调的团队，并改良了最终产品。 DevOps发明了更高兴、更高效的团队。人们不用一次又一次地实现同样无聊的工作，解决同样的问题。挫折感和不欢快的缩小会让团队成员更有效率和效率。这样能够打消工作中一些不称心的中央，为组织减少价值。 团队效率达到高峰，有更多创造性和变革性的工作、个体责任和增强沟通。当筒仓被突破后，团队会对独特的指标和实现目标的打算有一个更清晰的意识。此外，减少透明度会带来更理智的决策。受权、自信和合作的团队口头得更快更无效，从而导致更快的公布和更智能的工作。 如果出了问题或者有计划外的工作，沟通能够帮忙团队治理意外的阻碍。DevOps建设流程并明确优先级，以领导您和您的团队成员在继续执行原始打算的同时实现计划外的工作。 当员工做他们喜爱做的事件时，他们会更投入，更高兴。DevOps不解决工具问题，它解决人的问题。高兴的员工带来高兴的顾客。 公司也受益匪浅通过更好的流程和沟通环境，公司将受益匪浅。不仅在感情上每个人都是敌人的形式，在经济上也是如此。更称心的员工能够做他们喜爱做的事件，而客户失去了更好的体验，公司就会从中受害。 因为DevOps节俭了工夫和资源，并进步了公司的速度和竞争力，因而ROI（投资回报率）有了切实的进步。因为继续集成、继续交付、公布自动化、测试自动化和合作，组织可能更快地交付个性并更快地进入市场。团队是被动的，而不是被动的，因为它能满足新的市场需求并应答平安威逼。 继续的反馈使公司可能更频繁地听取客户的意见。因而，组织能够交付更及时、更具相关性的软件。这样就能够更快地响应客户一直变动的需要并改善用户体验。 在现今社会下，每家公司实质上都是科技公司。如果没有疾速的软件，将永远无奈将本身产品推向市场。而没有DevOps，就无奈领有疾速的软件。 DevOps使IT与业务指标保持一致。它发明了一个专一于发明价值和继续改良组织的团队。发明最好的客户体验是头等大事，每个人都在一起发明和保护最好的产品和服务。 DevOps将速度与方向联合起来，为企业带来利益。 点击关注，第一工夫理解华为云陈腐技术~

摘要： 麻利转型胜利的企业到底是从老总开始？还是从项目经理开始？还是团队自身具备这种意识？置信还有很多想要转型麻利的公司都存在这样的疑难。从06年首届麻利中国开发者大会召开到当初，麻利办法在国内的利用一直减少，对于麻利转型的热度只增不减。麻利转型胜利的企业到底是从老总开始？还是从项目经理开始？还是团队自身具备这种意识？置信还有很多想要转型麻利的公司都存在这样的疑难。 在企业中，除了老总、项目经理和团队，还有产品经理、测试、运维、PMO、品质治理、人力资源、行政财务等等角色。企业想要进行麻利转型之前，须要搞清楚上面的两个问题： 不同角色在麻利转型中的作用。企业中每个角色都和生产非亲非故，都须要参加转型，他们在麻利转型中都起到什么作用；如何判断由谁开始，如何去做。企业想晓得胜利转型的案例除了去参考哪个角色先动之外，更关怀的是如何去做，从哪动手，是一个什么样的过程，须要留神什么。理解不同角色的作用，让麻利转型对症下药咱们将企业成员分成四类角色来看一下他们在麻利转型中的作用。 从下面的表格中能够看出，麻利转型是一个须要全民参加的改革，所有的角色都须要做出扭转。如果只是独自一个角色动起来，其余角色不动就会变成转型过程中的妨碍。依据传统企业的组织构造模式，指引方向和保驾护航的高层以及中流砥柱的中层在转型中起到决定性作用，所以胜利的企业转型是从高层和中层开始，各个角色群策群力来实现。 高层和中层治理同时口头，上下一心实现转型高层管理者要建立麻利思维，做好战略规划依据VersionOne公布的13期寰球麻利状态报告，组织转型胜利因素的TOP3是：对外部麻利教练的投资、高管资助和公司提供的培训我的项目。由此可见高层在转型胜利过程中起到了决定性的作用。高层须要采取的口头能够参考如下过程： 注意事项 评估诊断的目标是为了确认麻利引入是为了解决问题，是过程改良，而不是盲从和跟风。试点我的项目的抉择可参考：规模5-9人、周期半年之内、我的项目重要度高、业务人员参与度高。麻利团队组建时人员抉择可参考：业务纯熟、长于表白、勇于开拓、有工作责任心和主人翁意识、认同麻利工作形式、基于被迫的踊跃乐观者。高层可能从策略层面进行部署，调控各种资源为转型创造条件，向下推广遇到的阻碍会比拟少。然而因为高管要对转型后果负责，会承当肯定的责任和压力，就有可能进入到命令和管制模式，导致团队胆怯采取被动，这样就和麻利中的团队自组织相矛盾，呈现“形敏神不敏”，让转型碰壁。所以高层管理者或领导者们，要改变传统领导办法，建立麻利的思维，做好战略规划，采纳麻利的技术，使员工真正实现自组织、自治理，最终推动麻利胜利转型，进步竞争劣势。 中层管理者要深刻了解麻利，率领团队践行麻利在麻利模式下，中层管理者作用至关重要。建设跨部门团队，实现端到端的交付，项目经理起到关键作用；PMO、品质治理部门负责企业的体系建设，流程和品质管控等，在向麻利转型的过程中，这些必然要产生扭转；产品经理是我的项目需要的输出端，麻利模式下对需要的输出也有本人的要求。同时在麻利模式下，中层治理的角色和治理形式都要产生一些变动，如果他们不能产生扭转，就会变成妨碍，所以中层对麻利的认可和承受在很大水平上决定了转型胜利的可能性。 中层的作用次要在下面流程的 环节，当高层选定试点我的项目之后，整个试点我的项目的施行要依赖于中层治理，须要采取的口头可参考如下过程： 前面的步骤取决于以后小团队试点的胜利与否，如果胜利就转入到 环节，在企业的其余我的项目中施行麻利；如果不胜利须要依据失败的起因去具体分析，是抉择其余我的项目持续试点还是进行麻利应用，这时候高层意见会占主导地位。试点我的项目也是企业的一个尝试过程，麻利不是万能的，最终是否要向麻利转型还要依据企业的具体情况具体分析。 下面给出的同时口头是倡议的理想化状况，事实中企业状况可能有以下两种： ·高层管理者先动起来高层须要辨认企业中的积极因素，特地是中层治理中的踊跃成员，让中层治理紧随其后，率领团队口头起来，从而造成上下一心。在小说体的《猎豹口头：硝烟中的麻利转型之旅》中就讲述了相似的情景，盛远金融公司的转型从CIO开始导入麻利，中层治理踊跃配合转型，最初胜利实现了麻利转型。 ·中层管理者先动起来中层管理者在施行麻利之前依据领导的格调，决定是轻轻口头还是先沟通汇报取得高层反对。要害是要率领团队尽早发明第一个功效，以获取高层的认可。从而造成上下一心。在小说体的《麻利无敌之DevOps时代》中，就是通过讲述一个从一线经理阿捷开始的麻利转型故事，阿捷率领团队从Scrum开始到XP、精益实际，同时取得了高层的反对，最初胜利实现了麻利转型。大家感兴趣能够浏览参考。 由此可见，不论是从谁开始，胜利的转型肯定是高低配合，所有角色全副都要产生扭转，每一个人都麻利了，企业就麻利了。 写在最初在德国教育家雅斯贝尔斯的《什么是教育》中提到，教育的实质是一棵树摇动另一棵树，一朵云推动另一朵云，一个灵魂唤醒另一个灵魂。麻利转型也是这样的过程。通过个体行为思维变动以及个体之间的互动，耳濡目染造成企业麻利土壤，实现麻利在企业生根发芽。所以让咱们先从本身做起，去影响身边的人，一点点的扩充，从而影响更多的人。麻利路上，你我同行！ 参考附录Mike Cohn. Scrum麻利软件开发[M].北京：清华大学出版社.王明兰.麻利转型：打造VUCA时代的高效能组织[M].北京：人民邮电出版社.刘华.猎豹口头：硝烟中的麻利转型之旅[M].北京：人民邮电出版社.王立杰.许舟平.姚冬.麻利无敌之DevOps时代[M].北京：清华大学出版社.13th Annual State Of Agile Report[R].VersionOne.MAY 7,2019.点击关注，第一工夫理解华为云陈腐技术~

在首个 Sprint 开始之前，须要召开一个递增的 Sprint 打算。用来打算和确定一列麻利公布火车的工夫维度，通过定量的工夫递增（Sprint）来保障编码实现和咱们打算工作（Mission）的继续统一。PI 将在固定的工夫箱内打算出一个可量化、可实现和最终可测量验收的打算路线图。Choerodon猪齿鱼通过以下步骤进行PI过程： ART同步会议通过我的项目群看板促成可视化通过迭代日历进步麻利团队可见性ART同步会议在 PI 打算会议之后，各种我的项目群事件创立了一个闭环零碎，从而 “放弃火车在轨道上前进”。如图所示：  为了放弃工作继续停顿和透明度，就须要频繁的合作。为了评估和治理进度和依赖关系，ART通常通过各种同步会议进行协调。这其中包含: Scrum of Scrum（SoS）：公布火车工程师（RTE）每周（或更频繁）疏导 Scrum of Scrum会议，来协调依赖，并将停顿和阻碍以可视化的形式出现进去。Scrum Master或者其他人向大家同步麻利团队实现里程碑和PI指标的进度,并治理团队间的依赖关系；产品负责人(PO)同步：产品经理（PM）和产品负责人（PO）通过 “PO 同 步”会议，对 ART 的停顿在多大程度上与我的项目群 PI 指标相一致取得可视化出现。探讨个性开发中遇到的问题或者发明的新机会，并评估任何可能呈现的范畴调整。这个会议也是每周进行一次，也能够依据理论状况更加频繁的举办。一些 ART 将 Scrum of Scrums 会议和 PO 同步会议组合成一个“ART 同步”会议。ART同步会议有助于跟踪打算的停顿并解决重要问题（阻碍）。 ART同步会议须要展现： 指标和特色的全副停顿；须要上报给其余团队或打算级别的危险和问题；与其余团队的依存关系状；通过ART同步会议，高级管理层和团队能够轻松理解进度，预测，依存关系和问题。这将有助于整个ART的确咱们的指标是否对齐，是否存在阻碍延缓按期交付。Choerodon通过我的项目群看板、迭代日历提供了较为全面的可视化根据。 通过我的项目群看板促成可视化PI开启后，看板立刻开启。我的项目群看板提供了流转可视化，通过个性在继续开发、继续集成、继续部署、继续交付中一直流动，最终实现价值流的交付。同时，看板有助于预测瓶颈，通过每个状态的队列长度，疾速确定ART要面临的危险，并且及时打消危险。如下图所示： 通过迭代日历进步麻利团队可见性迭代日历残缺、通明的展现了ART中各个麻利团队的开发状况，我的项目群管理人员能够通过PI、团队、冲刺多个视角，再联合故事点、问题计数两种维度，多方位的展现各个团队、各个冲刺、各个工作项的停顿状况。 总结PI执行过程中，麻利团队在源源不断的为ART提供能源，每个独立的麻利团队在一直的进行迭代反复工作，这包含：迭代打算、每日站立会议、团队演示以及团队回顾。而ART管理人员只须要通过看板和迭代日历理解各个团队的停顿，及时移除阻碍。 如何在Choerodon中进行SAFe大规模麻利实际，请参考大规模麻利实际指南（一）：如何开启大规模麻利之旅。理解SAFe的术语以及对应到Choerodon上的性能，请参考大规模麻利实际指南（二）：SAFe术语与Choerodon性能对照表。理解什么是大规模麻利框架SAFe以及Choerodon猪齿鱼如何聚焦SAFe框架理念进行大规模麻利实际，请参考Choerodon大规模麻利|大规模麻利框架SAFe。 对于猪齿鱼Choerodon 猪齿鱼作为开源多云利用麻利全链路技术平台，是基于开源技术Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益麻利、继续交付、容器环境、微服务、DevOps等能力来帮忙组织团队来实现软件的生命周期治理，从而更快、更频繁地交付更稳固的软件。 更加具体的内容，请参阅Release Notes和官网。 大家也能够通过以下社区路径理解猪齿鱼的最新动静、产品个性，以及参加社区奉献： 官网：http://choerodon.io论坛：http://forum.choerodon.ioGithub：https://github.com/choerodon欢送退出Choerodon猪齿鱼社区，独特为企业数字化服务打造一个凋谢的生态平台。

原文作者：Sjoerd Nijland 原文地址：https://medium.com/serious-sc... 翻译：柴晓燕&付新圆对于麻利中的流动有很多，本文先从Sprint打算开始，分享一些办法、倡议和注意事项，这些对了解和实际Scrum都很有帮忙。 Who？Sprint打算的参与者：整个Scrum团队。 请留神， Sprint打算是 一个踊跃的、单干的流动。如果需要的话，大家能够随便走动查找材料或解决问题。开发团队能够招集其他人来帮忙，在会议期间能收集到更多信息。 “开发团队还能够邀请其他人加入，以提供技术或畛域倡议。” — Scrum指南参与性并不是每位成员都会在参加流动时体现出积极主动和创造性，有些成员只有在感到自信或难受时才会退出。 出勤率和参与度低都会升高透明度，并带来危险。Scrum Master认为每个人都加入和参加是他们的责任。 “ Scrum Master能够确保流动进行，并确保参与者理解其目标。” — Scrum指南我认为，解释缺勤和参加的价值，同时发明一个舒服、欢快、平静和尊重的环境，是Scrum Master 激励团队成员参加的最佳办法。 “给他们提供所需的环境和反对，并信赖他们来实现工作。” —麻利宣言。有时，参与者可能会占据主导地位，并试图利用一事件来领导和影响团队的方向。这些输出可能十分有价值，但可能会障碍其他人增加贵重的输出，参与者应该意识到这一点。当团队成员之间产生不尊重甚至友好时，Scrum Master应该及时染指。团队要把Scrum Master视为教练，以爱护团队环境的平安。 When?Sprint打算产生在什么时候： Sprint的开始。 这其实是一个很难答复的问题，《Scrum指南》并没有明确指出Sprint打算必须在一开始就进行。 事实上，如果精确地解释的话，在Sprint打算期间打算的工作指的是行将到来的Sprint，而不是以后的或这个Sprint。 Sprint打算不会在两者之间进行，因为Sprint在上一个Sprint完结后立刻开始。请记住，Sprint充当的是事件的容器。 《Scrum指南》暗示了这一点。 “每个人都在另一个Sprint中重新组合，打算开始另一个Sprint” —《 Scrum指南》。侥幸的是，Scrum.org的Scrum词汇表更加具体： “Sprint打算：定时流动，以开始Sprint。” — Scrum词汇表团队在优化期间筹备Sprint打算并不少见。总的来说，Sprint打算在统一的工夫和中央开始。 How long ?如果进行长度为一个月的冲刺，最多须要8个小时来进行冲刺打算 。对于周期短的冲刺， 则破费的工夫更少。 团队通常会依据sprint的周期来制订迭代打算 ，一个星期的Sprint可能 须要2个小时的打算工夫。请记住，这只是最大工夫，没有最小工夫。经验丰富的团队很可能在时限到期之前实现打算 。 好的合作与改良能促使sprint打算会议更加迅速，更加无效。就是说，工夫并不能决定解决问题的效率 。 筹备Sprint打算时咱们要筹备以下内容 ： 来自Sprint回顾会的反馈和有价值的输出内容 （可能曾经退出到产品待办事项列表中）欠缺的产品待办列表在上次迭代回顾会议上确定的至多一项 优先级较高的流程改良探讨Sprint的潜在指标“实现”的规范，即验收规范。最近一次的产品增量最近一次迭代开发团队的体现冲刺期间开发团队的预计容量在我的我的项目中，团队经验了很屡次迭代 ，成员们都在呐喊推延Sprint打算，他们要么不认为上一个Sprint曾经实现，要么感觉本人筹备不充沛 。 那么， 上一个Sprint中 未被认 为“实现”的工作能够从新 布局 到下一个Sprint中。 请记住一个冲刺规定的工夫范畴完结标记着这个冲刺的完结，当然勾销冲刺除外。 无论哪种状况，Sprint打算都不会推延。如果在Sprint打算之前，上述所有内容都不是通明的，那么Sprint打算的工夫范畴可能容许在打算期间发明这种透明性。 Ready的解释一些团队应用“ Ready ”的定义。Scrum仅规定了一个定义（只管这并不排除团队引入诸如 INVEST)规范之类的其余定义）： “能够由开发团队在一个Sprint内“实现”的产品Backlog项被认为是“筹备好”的，能够在Sprint打算中进行抉择。”—Scrum指南。目标“在Sprint打算完结时，开发团队应该可能向产品负责人和Scrum Master解释其打算如何作为自组织团队来实现Sprint指标并创立预期的增量。” — Scrum指南并且 ： “ 开发团队在Sprint 的第一天 打算的工作将在本次会议完结前被合成。” — Scrum指南（强调）如果实现了此目标，就达到了Sprint打算的目标 。 ...

超过 70% 的组织曾经在业务中施行了某种类型的麻利办法。然而，将麻利转化为胜利的路线并不总是一帆风顺的。换言之，即便在麻利世界，挑战仍然存在，上面是几位行业专家分享了他们对于组织如何能胜利创立麻利文化的想法。 从失败中学习，在过程中变换 Andres Angelani, Cognizant Softvision的 CEO，分享到放弃麻利文化能够归结为以下四个要害准则： 从疾速、低成本试错中，边做边学：没有从失误中学到经营教训，那才是失败。一开始就设定指标，过程中的每一步让组织和利益相关者都有成长和有播种。麻利的“实践”杯水车薪：任何麻利的施行都须要合乎需要，而不是规定一些对业务没有价值的过程或做法。如果速度、团队自主性、品质和业务成绩没有出现进去，阐明领导麻利转型的人或团队没有发挥作用。掂量什么是对业务重要的指标。以人为本: 招募、培训和留住你所须要的人才，帮忙组织实现业务倒退，这须要你致力地建设以人为本的社区。后退的同时要转换：业务不会进行。明天的环境要求咱们在持续倒退的同时进行数字化革新。在麻利中激励设计思维 Jason Cranford Teague, Rivet Logic 的 UX 负责人，激励组织意识到设计思维是麻利中的一个重要因素。他说：“设计和开发不应该离开。”“开发须要参加设计决策，确保解决方案可行，设计须要与开发联合，这样解决方案是依照设计来构建的。” Cranford Teague 分享到，如果设计思维在麻利中做得正确的话，和“设计委员会”无关，而是容许训练有素的设计师来领导计划而不是复述内容。“因为一些最重要的设计决策，要等到解决方案被开发进去，能力做决定。” 赋能员工 麻利开发有机会胜利的惟一路径是发明赋能员工的文化，Belatrix Software 的总裁兼联结创始人 Alex Robbio 说到： “这须要在整个组织中发展，包含管理层和业务层的员工。” 须要组织流程更改 Robbio 说，当一个组织 all-in 开始麻利的时候，它波及到整个组织构造的变动，包含对我的项目和打算的优先秩序。通常你会创立所谓的“scrum-of-scrum”，你有多个 scrum 团队。当你持续扩大时，你可能须要在PMO下退出不同的麻利团队。 “领有数字化工场的流程、信息流和工具对企业级麻利，是至关重要的，” Robbio 说。“只有信息流是数字化的，能力实现无效的治理构造和治理。例如，在麻利中，团队成员能够很容易地看到燃尽图的状态吗？” 跳出日常，激发翻新 让员工一起参加娱乐和学习流动，能够发明更好的纽带，促成团队建设。Rachel Bush，Viget 营销经理与咱们分享她们企业通过相似的 “无意义的周末” 将麻利翻新融入到他们的文化中。“无意义的周末” 是公司资助每年举办一次48小时的黑客松大会。他们还建设了很多我的项目，目标是让员工理解组织中其余团队和角色。“它让团队成员尝试不同的角色，更好地理解共事如何工作，” Bush 说。 自上而下的麻利培训 对每个部门负责人全面培训麻利，这样他们能够自上而下，能确保流程顺利施行，Fueled首席营销策略师 Ciara Hautau说。“对新人的麻利培训也很重要，让他们一开始就不会回到原有的旧流程。” “咱们公司要求新上任的人，须要借着文档和办法里来了解咱们如何使用麻利办法治理我的项目。每个季度都会做一个回顾，能够看到哪些工作有功效，哪些须要改良，组织能无效地使用麻利。 布局麻利，在团队层面采纳麻利实际 依据 Robbio 的倡议，各个团队须要对他们的合作形式做出具体的扭转，例如采纳 scrum 或看板。企业有多种不同的麻利办法能够抉择，大家都会依据各自具体需要抉择使用。他说：“在这个层面上，数字化的工作场合会带来很大的不同。” “例如，员工是否容易用一个按键就能分享电脑屏幕？”如果员工想和另一位共事在不同的地位交谈，他们会有高质量的麦克风吗？团队是否有帮忙他们合作更有效率的工具？” ...

背景在某开发团队辅导的回顾会议上，团队成员对于优化预计具体方法上达成了一致意见。询问是否有什么具体的预计办法来做估算。 问题剖析回顾意见上大家对本次Sprint的成果做回顾，其中80%的成员对于本次Sprint的估算成果不称心，最终团队心愿在下一个Sprint中，估算流动能有所改善。 经理解，团队目前的估算办法很简略，基本上是架构师和团队中有丰盛开发教训的成员一言堂。估算的速度也很快。对于有些有疑难的需要，开发成员也是保持沉默，草草认领了工作。 团队迫切希望学习新的估算办法来优化目前的估算流动，因而分享几个具体的估算办法给团队实际，让他们本人抉择适宜、喜爱的估算办法是解决问题的要害。 解决措施咱们来学习下具体的故事点估算的实际，感受一下估算。这里介绍最罕用的两种估算办法：一个是打算扑克估算，另一个是麻利估算2.0。下表内容展现了这两种估算办法在什么情景下抉择。 打算扑克估算在麻利开发中，最典型的应用故事点做估算的办法是打算扑克（Planning Poker）。 打算扑克由James Grenning在2002年首次提出。打算扑克汇合了专家意见（Expert Opinion），类比（Analogy）以及合成（Disaggregation）这三种罕用的估算办法，使团队通过一个欢快的过程疾速而精确的得出估算后果。 打算扑克的参与者是团队的所有成员。典型的麻利团队规模举荐为7±2人，如规模比拟大能够思考拆分成为多个小团队各自独立进行估算。Product Owner也须要加入，但不参加估算。 打算扑克开始时，每个参加估算的组员都会失去一副打算扑克，每一张牌上写有一个Fibonacci数字 （典型的打算扑克由12张牌组成：?，0, ½，1, 2, 3, 5, 8, 13, 20, 40, 100,∞，其中?代表信息不够无奈估算，∞代表该用户故事太大）。 开始对一个用户故事进行估算时，首先由Product Owner介绍这个用户故事的形容。过程中Product Owner答复组员任何对于该用户故事的问题。展开讨论时主持人(通常由Scrum Master负责)应留神管制工夫与细节水平，只有团队感觉对用户故事信息曾经理解到能够估算了，就该当停止探讨开始估算。 所有问题都被廓清后，每一个组员从 扑克中筛选他／她感觉能够表白这个用户故事大小的一张牌，然而不亮牌，也不让别的组员晓得本人的分数。所有人都筹备好后，主持人发口令让所有人同时亮牌，并保障每个人的估算值都能够被其他人分明的看到。 常常会呈现不同组员亮出的分值差距很大的景象。当呈现有很多不同分值的时候，出分最高的人和出分最低的人须要向整个团队解释出分的根据。（主持人须要留神管制会议气氛，避免出现意见不一导致的攻击性舆论。）所有的探讨应集中于出分者的想法是否值得团队其余成员进行更深刻的思考。 随后全组能够针对这些想法进行几分钟的自在探讨。探讨之后，团队进行下一轮的全组估算。一般来说，很多用户故事在进行第二轮估算的时候就能失去一个全组对立的分值，然而如果不能达到全组意见统一，那么就反复的进行下一轮直到失去对立论断。 麻利估算2.0（Agile Estimating 2.0）打算扑克是Scrum团队利用最宽泛的麻利估算办法，然而有时候打算扑克玩起来消耗比拟多的工夫，尤其是在十人左右的团队中。Ken Schwaber在他的书《Agile Project Management with Scrum》中指出，在进行迭代布局时，迭代打算环节应该管制为一个4小时的固定工夫，然而从战术的角度看，如果一个会议继续4小时，大部分的参会者会有筋疲力尽的感觉，并且很难放弃长久的注意力。 为了解决这个问题，Brad Swanson 和 Björn Jensen在上海Scrum Gathering （2010/4/19）上介绍了Agile Estimating 2.0技术。这个新的估算技术同样基于的专家意见，类比和合成，同样实用Fibonacci数列，然而它能够显著地缩短会议工夫。它的估算过程大抵分为次要四步，如下图所示： 第一步：由Product Owner向团队介绍每一个用户故事，确保所有需要相干的问题都在做估算前失去解决。 第二步：整个团队一起参加这个游戏。 只有一个简略的游戏规则：一次仅由一个人将一个用户故事卡放在白板的适合地位上：规模小的故事在左，大的在右，一样大的竖向排成一列。整个团队轮流挪动故事卡，直到整个团队都认同白板上的故事卡的排序为止。 第三步：团队将故事点（Story Point）调配给每个用户故事（列）。 最简略的做法是应用投票来决定每个用户故事调配到哪一个Fibonacci数字。 最初一步：应用不同色彩来辨别影响估算大小的不同方面，并且重新考虑是否须要批改估算值。 例如，咱们应用红色来示意那些无奈被自动化测试脚本笼罩的用户故事，因而那些用户故事须要一个更大的数字来包容手工回归测试的代价。 在国内一些企业屡次实际Agile Estimating 2.0之后，反馈的后果还是令人兴奋。据称，团队对于估算的准确性更有信念了，并且只消耗原先的1/2工夫。 ...

摘要： 本文介绍了成熟度模型在软件开发行业的利用，重点论述了成熟度模型对于麻利和DevOps在企业中进行规模化推广的价值，探讨了成熟度模型的设计准则，并对于如何理智应用成熟度模型给出了倡议。导言在麻利和DevOps社区，只管对成熟度模型始终有些争议，但应用各种成熟度模型来领导转型的尝试却从未进行过；从笔者的从业经验来看，审慎地应用成熟度模型，对麻利和DevOps在企业中的规模化推广具备很重要的现实意义。 成熟度模型简介“团队定期地反思如何能进步功效，并依此调整本身的举止体现”，这是麻利宣言的一个准则，它激励咱们继续地对软件开发办法进行改良。这种改良间接体现在晋升团队的效力（更多的价值，更快的交付速度，更高的交付品质，以及更低的老本等），最终服务于企业的业务指标。改良通常由团队交付业务价值所面临的问题或挑战触发，团队共同识别改良点，采取改良措施，查看改良功效，再发动新的改良；周而复始，永不停歇。 针对软件开发办法的改良没有起点，这个漫漫长路须要指引，成熟度模型正是为了满足这一需要。所谓成熟，意思是长大和成长，指生物体发育到齐备的阶段，或事物倒退到欠缺的水平。尽管成长的过程是间断的，但还是能够通过观察主体特色的显著变动来确定一些阶段，譬如人类成熟的过程能够分为婴幼儿、儿童、青少年、成年、老年等阶段。基于这个隐喻，成熟度模型应用一个结构化的框架，形容所关注的主体如何随着工夫的推移而倒退(成熟)；演进的每个阶段，被称为成熟度的一个级别，表明了在成长门路上的停顿。 在软件开发畛域，历史最悠久，也是最驰名的成熟度模型是CMMI。CMMI及其前身CMM，是受美国国防部委托，由Wattss Humphrey在软件工程研究所(SEI)领导的团队所创立，以评估供应商无效交付软件我的项目的能力。该模型定义了五个渐进的成熟度阶段，从级别1(最不成熟)开始，到级别5(最成熟)完结；依据其成熟度特色对每个阶段进行形容，蕴含指标、实际和实例等。自上世纪九十年代初被提出之后，CMM迅速为软件开发行业所承受，它所利用的成熟度模型构造，也被很多其它成熟度模型所借鉴，譬如PMI的组织项目管理成熟度模型等。 当麻利静止衰亡，并逐步成为软件开发的支流之后，尽管CMMI并没有被市场摈弃，但其粗浅的瀑布模式烙印，成为相当一部分麻利实践者们眼中的反面教材，也导致麻利和DevOps社区对成熟度模型的争议一直；但不可否认的是，随同着麻利和DevOps在企业的推广，成熟度的利用从一开始就呈现，且始终没有进行过；麻利教练的工具箱里少不了各种成熟度模型。 成熟度模型的类型针对任何具备继续演进特色的主体，咱们都能够设计一个成熟度模型。主体范畴可大可小，取决于利用的须要；譬如，能够别离为麻利或DevOps设计一个模型，也能够设计一个范畴更广的研发效力成熟度模型来涵盖它们；或者，对于某些特定畛域，例如继续集成或者看板办法，也能够建设一个轻量级的成熟度模型。 成熟度模型次要有阶段式和连续式两种类型。其中，阶段式模型在整体上把成熟度分成多个阶段，每个阶段都有一组考察点；每个考察点用指标或满足指标的实际进行形容，展现了成熟度所关注的某个方面。 图一是阶段式成熟度模型的示例，扼要地形容了继续集成的五个成熟度级别；继续集成能力的晋升，是通过自低而高，逐个满足各级成熟度中所有考察点的指标来实现的，每个级别都建设在上一级的根底之上。 图一：阶段式成熟度模型示例 连续式模型同样蕴含多个考察点，每个考察点为一个独立的评估项；与阶段式模型不同，每个考察点都蕴含成熟度的几个阶段，各阶段能够用阶段性的指标，满足该指标的实际，或可能体现该阶段成熟度的行为进行形容。 图二是一个连续性模型的示例；这是一个DevOps成熟度模型，考察点包含6大畛域36个子畛域，每个具体考察点（子畛域）蕴含五个成熟等级的形容，图二展现了其中的一部分（需要畛域）： 图二，连续式成熟度模型示例 对于连续式模型，原则上成熟度的晋升能够从每个考察点独立发展（理论施行要思考实际的相互依赖和撑持），评估时针对每个考察点都给与一个等级。一种常见的后果展现形式是雷达图，如图三展现了某我的项目团队两次评估的后果，直观反映了：1）每次评估各考察点的等级；2）两次评估之间各考察点成熟度的变动；3）团队的薄弱点和劣势等。这些信息对于团队布局和跟进改良，具备很强的指导意义。 图三：连续式成熟度模型的评估后果示例 成熟度模型的价值成熟度至多答复了三个问题：“我在哪？”（以后成熟度），“我要去哪里？”（指标成熟度），“我怎么样能力达到那里？”（两头经验哪些步骤）。而这，是团队实现继续的效力改良所须要解决的外围问题。 现实状况下，给研发团队设定有挑战性的指标，辅以信赖和反对，提供必要的资源，团队本人在指标的驱动下实现改良；但现实情况是，这种自发的改良往往不会如期而来。在组织中进行麻利和DevOps的规模化推广，最常见的问题是，少数的团队不晓得怎么继续改良，不晓得本人要改良什么，甚至不晓得本人到底做得怎么样。 麻利和DevOps教练能够补救这种缺失，在转型晚期帮忙团队顺利上路，但受限于教练资源（譬如几位常驻麻利核心的教练服务数千人的研发组织），教练来到团队之后，更漫长的继续改良之路须要团队本人走上来。咱们都晓得，教练最重要的产出是成熟的团队，特地是造就出合格的具备麻利意识的领导者，可能率领团队继续改良。正如丰田所提倡的“造物先造人”，当有优良的人才呈现，什么事件都会变得简略；然而，“十年树木，百年树人”，造就出合格的团队和卓越的麻利领导者是何其之难。 毫无疑问，企业一方面要有久远视角继续一直地在人才培养进行投入；但另一方面，也要应答眼前向业务交付价值的压力，疾速晋升团队效力。如何在教练资源无限的状况下，踊跃寻找出在整个组织层面投入产出比高，可能提供普及型服务，疾速奏效的方法？这是麻利和DevOps规模化推广必须答复的问题。通常做法是提供基础性赋能（培训、短期辅导）后，激励团队基于行为后果一直尝试，即创立一种继续改良的机制，容许团队犯错，在业务指标的引领下，尝试各种新的做法，疾速迭代，一直反思，有用则强化，有效则摈弃。 然而，正如心理学家，社会学习实践的创始人班杜拉所言：“如果人们不得不单纯依赖本人的行为后果来告知本人应该如何行为的话，学习将十分艰辛，更不用说其危险性了”。所幸的是，人类具备模拟的天才，学习不肯定要亲身经历。班杜拉的一系列观察学习钻研通知咱们，通过模拟别人的胜利，咱们能够学会各种各样的社会行为。对于麻利和DevOps的施行而言，成熟度模型实际上提供了一个现实的模拟对象。企业的麻利推广团队（譬如麻利卓越核心，DevOps教练组，转型领导团队等），能够通过开发、保护、公布成熟度模型；答疑，评估和给出倡议，来撬动组织转型。 具体来说，利用成熟度模型能够在以下几个方面对转型具备重大促进作用： 第一，明确效力主张。通过成熟度模型，向研发团队收回什么是冀望的高效能研发行为的明确主张；模型所提供的框架，系统性给出了在研发次要过程域（考察点）的效力改良的指标，是组织效力改良的思维纲领；围绕如何实现各考察点的指标，模型同时也提供了大量优良的麻利和DevOps实际倡议，是组织效力改良的行动指南。成熟度模型的公布，能疾速地为整个组织的继续改良建设参照体系。 第二，认清现状。通过与成熟度模型的对照，团队能够很容易地评估出本人在麻利和DevOps施行上所达到的程度（处在怎么的阶段），这成为团队进一步改良的终点。在组织层面收集各研发团队的成熟度数据，可能勾画出组织整体的麻利和DevOps施行程度，一方面能够发现在效力晋升上的共性问题，集中力量攻坚薄弱点；另一方面也可能将以后的程度作为组织改良的基线，以此为根底布局下一步的改良。 第三，设定改良指标。指标驱动曾经写进古代组织的基因之中，小到Scrum小组，大到整个研发组织，如果领有麻利或DevOps成熟度的指标，将使得改良失去关注并更有保障（无论是工夫还是资源的投入）。成熟度模型的高阶段要求，是各团队的具体改良指标；在组织层面，也能够基于组织现状，设置一个总体改良指标，譬如达到不同等级的团队比例等，作为OKR自上而下合成到各团队（在设置OKR指标这件事件上必须谨慎，防止造成改良口头的形式化）。 第四：布局改良路线。成熟度模型给出了团队从现状（低阶成熟度）到指标（成熟度高阶段）的门路（即须要通过哪些阶段）；攀登高峰不止一条路，但有的起伏平缓，而有的更为平坦，有教训的登山者晓得要走前人走过的路。成熟度模型所布局的门路，是前人实际的经验总结。诚然，团队采纳麻利或DevOps的成熟过程与生物体的成熟过程有很大不同，后者必须间断通过所有阶段，而麻利的采纳则不受这个限度；因而，在布局上不能教条，团队齐全能够依据本人的状况，造成特定的改良门路。 第五，营造竞争气氛。以适当的形式，在整个组织层面展现汇总的成熟度数据；辨认在晋升成熟度过程中涌现出的优良团队并给与适度的表彰；激励亲历者讲述通过成熟度的晋升而带来效力晋升的胜利故事并鼎力宣传等。这些动作，都承载在企业的麻利或DevOps成熟度模型之上，不同团队之间容易产生共鸣，并存在肯定的可比性，可能在团队之间发明侧面的竞争气氛，带来改良的紧迫感。 第六，度量改良停顿。通过麻利和DevOps来进行全面的效力改良，是一个继续、漫长和没有起点的旅程；团队要常常检视本人做得怎么样，是不是走在正确的路线上，而成熟度模型在这个过程之中能够成为掂量改良进度的规范；通过在改良过程中的继续评估，团队能够清晰地理解本人在改良路线上所处的地位，为后续改良流动的设计提供根据。 成熟度模型设计准则设计什么样的成熟度模型决定了组织要定义什么样的研发效力规范，将怎么的行为作为团队模拟的对象。成熟度模型的设计必须回归应用成熟度模型的目标，即可能疏导团队和组织继续晋升效力，进而改善业务产出。为了实现这一指标，须要遵循以下准则： 第一，基于企业现状。成熟度模型的通用性越高，则越是形象，落地领导的价值越低。鉴于麻利和DevOps办法和实际的多样性，以及其推广施行的灵活性，很难呈现一个适应各种场景的麻利或DevOps成熟度模型；为了可能领导改良，模型的设计肯定要基于企业现状来，思考企业的业务诉求、技术路线、人员程度和研发治理模式等束缚，而不是简略地瞄准现实的麻利或DevOps状态。 第二，具备导向性。模型所蕴含的考察点，对各考察点指标的定义，以及对不同阶段的评估规范，都要具备明确的导向性，反映了组织的效力指标（交付速度优先，还是效率优先？更好的用户体验还是更低的老本？），效力关注点（弹性的组织，优化的流程，先进的工具，业余的人员等），以及组织对于达成指标的实际经验总结和洞察；通过这种导向性，疏导团队体现出组织所冀望的行为。 第三，关注指标。对各考察点的设计，重要的是明确指明指标，而不是严格限定是否采纳了某种具体实际。每个考察点从低到高的各阶段，反映的是达到目标的水平；不同阶段的评估规范能够举出一些最佳实际的例子，但最佳实际不是重点，重点是通过这些实际帮忙团队达成阶段指标。通过对指标的关注，使得团队更可能理解差距，本人决定采纳何种措施达成指标，并在通往指标的征程中一直调整措施，而不是教条地采纳实际。 第四，绝对主观。不同的评估者，在同一期间，对同一个团队，基于雷同的事实，应该可能给出近似的评估后果。量化数字要求天然可能达成这指标，但不用太强求量化，只有考察点的指标形容明确的，其反对实际或体现得行为是可观测的即可。成熟度模型设计之初，能够思考通过对试点我的项目的利用，对其信度和效度进行测验。再次揭示，不用谋求齐全主观，这不是考核；存在一些含糊，有肯定争议，引发一些探讨是无益的。 第五，放弃动静演变。组织业务指标和所处的环境在变动，组织的外部环境在变动，软件开发办法和实际自身也在疾速变动，往年还备受追捧的办法和实际可能明年就过期；因而，成熟度模型必须适应这种变动，放弃演变，以排汇业内最新的成绩，来更好地适应你的环境，帮忙企业达成指标。 如何使用成熟度模型团队从本人的现状登程，沿着成熟度模型的阶梯，一直追赶高的等级，实现继续改良；成熟度的等级自身在这个过程中天然而地成为焦点。但如果以成熟度等级为基本，特地是以拿证为目标进行评估，则很容易带来静止式，一刀切的“改良”。这个时候对等级指标的片面追求很容易让改良口头脱离团队的现状，非但违反利用成熟度模型的基本目标（即晋升效力），而且评估流动自身会成为团队的累赘（筹备各种证据），对团队的失常工作造成烦扰；一阵风之后，留下一堆作为证据的文档和弃之不必的流程工具，团队的所有行为依旧。等级自身并不重要，继续地改良以使得团队可能更好地服务业务才是基本，不能够本木倒置。 成熟度模型是工具，工具自身通常是没有对错的；刀既能够伤人，也可能救人，就看握在谁的手中，为了什么目标。所以，对成熟度模型的利用要谨慎：咱们能够用它来作为参照和模拟对象，但却不能把它设计成规范强制大家恪守；咱们能够用它来设定改良指标，但用来考核绩效可能大失所望；咱们能够把优良团队秀进去可能激励其余团队效仿，但如果把临时垫底的团队也公布出来却不是个好主见。 成熟度评估是模型利用和实现改良的伎俩之一，它基于模型提供的继续改良的蓝图，帮忙咱们在改良的征途上进行查看（辨认以后所在的地位）和调整（确定进一步改良的方向）。成熟度评估不是为了取得一个冀望的等级，而后完结；而是要通过评估建设一个基线，成为进一步改良的新起点，并给出下一步口头的倡议。 评估流动自身能够有多种形式，抛开内部认证评估不谈，在企业外部有团队自我评估，穿插评估（利用麻利和DevOps社区力量，不同团队穿插评估），以及集中评估（由企业麻利核心的教练对立评估）等多种形式。特地举荐穿插评估的实际，它一方面解决了集中评估的资源缓和问题（设想一下几个教练对上百个团队进行评估的场景）；另一方面，也是更重要的是，它能够使不同团队有机会互相学习。 评估的后果包含团队在成熟度模型中所处的等级，做得优良的中央，以及不足之处。团队基于这个后果，对标模型更高等级，剖析可能的改良点，马上采取行动，投入下一轮的改良之中。作为麻利和DevOps推广团队，既要基于评估后果发现共性问题，针对性提供集中培训和专项辅导；也要辨认涌现进去的优良实际，在组织层面进行分享。评估的后果倡议汇聚起来，造成整个组织的成熟度画像；各团队成熟度的具体等级能够不颁布，但整体程度的通明有利于各团队判断本人在整个组织中所处的地位，加强各团队的改良紧迫感。 须要警觉的是，成熟度模型通常是基于教训、观点，甚至假如所做的构建，而不是应用科学办法的后果。评估后果所给出的改良倡议，仅仅是一种你的团队能够如何成长的假如，它的作用在于让你领有一个绝对靠谱的参照物，帮忙你疾速决断和采取行动；你要验证这个假如在你的环境中是无效的，或者是有效的（判断规范是是否可能进步效力指标）；而后疾速调整，进行新一轮的尝试，从而实现继续改良研发效力的目标。 结束语只管成熟度模型的利用在麻利和DevOps社区的争议不会平息，但还是有组织可能从中获益；咱们能够通过明智地应用它，使其成为撬动麻利和DevOps在企业规模化推广的利器。存在即正当，对包含成熟度模型在内的任何办法和工具的应用，咱们应秉承实用主义而不是教条主义，同时持有批判性思维和凋谢态度；“不论黑猫白猫，能捉老鼠的就是好猫”。 点击关注，第一工夫理解华为云陈腐技术~

在敏捷软件开发中，史诗＆故事都是常用的术语。对于管理敏捷软件开发来说，Choerodon猪齿鱼是一个很好的工具，为敏捷术语和功能提供了非常广泛的实践方法，例如：史诗，故事、任务、子任务和缺陷，这些都是Choerodon中的问题类型。 史诗：是一个功能集或是一个大的用户故事，但因为颗粒度太大而无法适应冲刺，它可以分解为许多较小的故事；故事：是简短的用户需求，足够小以适合冲刺；任务：是完成用户需求的过程性的工作，表示用户故事开发任务的完成；子任务：子任务通常是故事或任务的具体拆分，由单人承接，而且通常能在短时间内完成；缺陷：主要针对测试中的缺陷或者已发布版本的缺陷； 本文将详细为大家介绍敏捷中史诗和故事以及它们在敏捷中的具体使用规范。 什么是史诗？史诗是一个大的故事，当一个功能具有多个场景时，该功能则需要在史诗层面进行多种实现。史诗代表的通常是与特定结果密切相关的原始想法，与该史诗相关联的用户故事则代表需要交付的解决方案的各个方面。总的来说，通过史诗可以跟踪待办事项中比较大的用户需求，史诗中包含多个小的产品功能的用户故事，这让用户需求更加具有层次结构。 如何编写史诗？对于史诗的编写，目前还没有标准格式，一些团队会使用熟悉的用户故事格式，也有一些团队则用简短的短语表示史诗。 在命名史诗时，请牢记以下两点： 1.它是开发或需求的核心内容；2.编写时使用组织中的每个人都可以理解的语音文字，以免产生歧义；因为史诗是编写用户故事时要参考的内容，并且在编写用户故事时还要参考所有团队成员的意见，所以正确的编写史诗并将详细信息在史诗中体现非常重要，这有助于避免团队中的许多冲突和对产品功能的误解。 用史诗介绍开发的新功能时，需要包括开发此功能的原因、需要解决的用户需求以及新功能的度验收量标准。此外，该功能的任何文档或早期的思路，可以向团队简单介绍，或者提供清晰的图片和信息。注意：团队对功能达成共识和目标是成功交付的关键。 Choerodon中的史诗示例： 史诗01：向用户提供排序和优先级选项，以轻松管理需求 用户故事01：作为发布经理，我希望将发布映射到不同的sprint，并看到每个故事的优先级。用户故事02：作为系统管理员，我拥有优先处理产品需求的权限。用户故事03：作为用户，我可以标注需求的优先级，并实现简单的拖放操作重新排序需求。编写史诗时需要注意的是： 谨慎思考在编写史诗时，可以先撰写项目构想的草稿，并需要思考最有必要的内容以及在以后的开发中包含的内容。这些都需要仔细考虑。 逻辑清晰在编写后续的史诗时，应该根据先前的主题来创建史诗，前后的史诗需要合乎逻辑且一致。 结合测试史诗不只是从大的故事进行思考，它分解的每个功能还需要在测试中可用。 参考专家人士的意见在编写过程中不应仅依靠个人或团队成员的眼光和思路，还需要参考专家人士的意见，阅读专业人士的的博客或他们推荐的书籍。他们的工作经验和意见能使史诗更加客观，也能让团队成员获得专业的经验和技能。 史诗是项目计划过程中重要的组成部分，有了史诗，团队成员和利益相关者可以看到产品真正的目的和用户需求。正确的史诗是进一步项目开发甚至产品研发的好帮手。 什么是用户故事？用户故事是基于史诗进行分解的，反映的是用户需求和用户可以得到的价值。它们从用户的角度描述功能的各个部分。在敏捷开发过程中，当我们开始站在用户的角度上思考时，即使这个功能不是当前解决方案的范畴，我们仍需要建立用户可以操作的行为场景。例如，我们正在针对共享照片和视频的特定问题制定解决方案，根据经验我们按照预期的方式执行所有操作，但是用户第一次使用并且不了解产品，可能查找不到特定角色对应的照片。为了避免这种情况，在用户故事中从用户角度清楚地说明所需的功能非常关键。 如何编写用户故事在敏捷方法论中，团队构建的所有内容都应围绕用户，这里的团队指的是产品经理、客户、利益相关者还有产品的最终用户。为了深度了解用户的需求和痛点，在开始编写用户故事之前，需要确定好产品的角色。以下是编写用户故事时广泛使用的模板： “ 作为一名 <角色或角色>，我可以 <目标/需要> 这样说 <为什么>”或者，在另一种情况下：“作为 <特定的用户类别>，我希望 <能够执行/执行某项操作>， 以便 <获得某种形式的价值或收益>”上面的描述为产品用户制定了业务价值。除此之外，用户故事的魅力在于，它不仅制定了业务价值，而且还制定了开发和测试的要求。通过简单的描述，添加产品功能的验收标准等描述，以总结需要完成的所有任务。 以下Choerodon中某个项目的用户故事的简短形式： 作为夜晚驾驶的驾驶员，我想迅速找到最近的优质加油站，以补充高品质的汽油。验收标准： 作为开灯的司机，我可以看到所有即将到来的加油站。点击“Ctrl+T”，我可以选择适合我的加油站品牌的加油站。到达加油站，我可以看到即将到来的选定品牌的加油清单。点击“M”键，我可以看到最近在地图上选择的加油站。 用户故事的重点是从用户的角度清楚地说明所需的功能，需要正确的理解用户需求并详细的表达出来。编写用户故事时需要注意： 用户故事≠任务用户故事不是任务。在实际开发中，一个故事可能需要数百个任务才能成功交付，任务与执行有关，而用户故事是根据用户需求定义的。在编写故事时，应着重于提供有关产品功能的信息。 故事简明扼要故事必须简单而准确。只需使用简单准确的语言即可，有助于团队成员和利益相关者深入了解用户需求，避免花时间澄清用户故事中不清楚的地方，比如术语和首字母缩写词等。 了解用户在开始编写用户故事之前，都需要收集一组关键用户（理想情况下是产品的角色用户），了解他们的个人资料、观点、对产品的期望以及相关的“痛点”，以帮助更好地了解用户及其需求。 大胆思考当将产品描述为用户故事放到待办事项中时，“没有预算，时间周期不允许，可行性低或成本高等”会限制产品的思维。正确的做法是大胆思考 ，将用户故事维护到待办事项列表，从产品的清晰度、用户愿景方面获得的价值。 用户故事提供了一种快速而准确地描述软件产品或系统功能的好方法，在产品规划会、产品迭代会中具有主导和输出作用。在这些会议过程中，用户故事需要以紧凑、结构化的方式阐明思想的提要。 故事地图根据敏捷的定义，在Choerodon中我们使用故事地图的形式来体现史诗和用户故事的价值。 故事地图的优势： 将史诗用作业务价值的容器；根据产品版本得到横向流程；快速制定出产品的蓝图，得到mvp版本的制作周期；（关于MVP的介绍可以参考《MVP：平衡“可行性”和“最小化”》）；以故事为中心，使开发人员的精力全部集中到重点功能上；使用增量来定期检查并调整项目进度；总结敏捷开发关注于快速且持续地交付给用户高价值、高质量、可用的产品功能。通过史诗和用户故事梳理用户需求、识别用户角色、梳理用户故事逐步完善更多细节，使执行的故事足够短小、简单，能在单个迭代期内完成，达到快速交付的目的。 本篇文章出自Choerodon猪齿鱼社区付新圆&柴晓燕。

在敏捷研发的过程中，或者项目结束后的复盘阶段，度量并分析团队成员在周期内的工作负荷、完成的工作量与工作动态，能够让管理者清晰的认识到团队成员的工作负载与工作效率；团队成员间也可以相互查看对方所参与的项目，近期工作动态或近期事项。 效能度量的主要功能为统计团队成员在一段时间内的计划事项数、完成事项数和所编辑的 Wiki 数以供分析。这些数据将会在趋势面板上进行显示。并且还可以自行设置分组并添加其它成员，方便快速查看团队成员近期工作概览。 使用准备团队拥有者或管理员在【团队管理】->【权限配置】中为相应的用户组的勾选「效能度量」的「查看页面」权限。勾选完成后处于该用户组的成员的工作台会出现效能度量的功能入口。 趋势面板面板将会反映所添加成员的工作量趋势图，以三个数据维度进行展示：计划事项数、完成事项数和 Wiki 编辑数。可以选择日、周、月三种统计周期视图进行查看，通过下方的滚轮横轴进行左右拖拉日期。 计划事项数将会统计处理人在一个时间周期内开始和截止时间所安排的事项总数，纳入统计的事项包含史诗、需求、任务、缺陷和子任务。 如果事项填写了开始和结束时间，那么处在这个时间周期的每一天的事项数 +1；如果事项只填写了开始时间，那么开始时间所在当天事项数 +1；如果事项只填写了截止时间，那么截止时间所在当天事项数 +1。具体的计数原理请参考计划事项数计数方式。 完成事项数将会统计处理人在固定周期内完成的事项总数。这里的完成事项定义涵盖史诗、需求、任务、缺陷和子任务。若对这些事项做出了完成操作，即状态类型从“非已完成”到“已完成”，则视该事项被定义为完成。 如果在时间周期内且周期结束后状态类型仍然是“已完成”，那么完成事项数 +1。具体的计数原理请参考完成事项数计数方式。 编辑 Wiki 数将会统计团队成员更新过的 Wiki 篇数。若在同一个周期内对同一篇文档进行修改并执行了“提交文档”，那么编辑 Wiki 数算为 1 篇。 添加成员与分组管理在「添加成员」中可以通过成员姓名或搜索项目一键添加项目内成员，添加进图表的成员可移除。在「分组」下拉组件中可进行添加分组、删除和重命名等操作，添加的成员默认进入当前选择的分组中。分组为用户自行设置，并不会在团队内公开显示该分组，属于个性化查看功能。 成员工作概览页在效能度量页面中点击任意成员，可进入成员的工作概览页。页面包含： 成员名称和头像；最近活跃时间；参与的项目；近期事项；该成员近期的工作动态。 近期事项近期事项的统计内容包含： 已完成，查询近 1 个月完成的事项，按照完成时间逆序排；进行中，查询状态类型为“进行中”的事项，按截止时间逆序排；未开始，查询状态类型为“未开始”的事项，按截止时间逆序排。工作动态工作动态为成员的日常协作动态，可按分类查询，包含： 项目协同代码仓库持续集成持续部署Wiki文件网盘... 权限控制该功能涉及到的权限模块名称为效能度量，具有“查看”权限。每个团队的拥有者和项目管理员将默认勾选「查看功能」权限点。 计数方式详情计划事项数计数方式如果事项填写了开始和结束时间，那么处在这个时间段里的每一天的事项数 +1；如果事项只填写了开始时间，那么开始时间所在当天事项数 +1；如果事项只填写了截止时间，那么截止时间所在当天事项数 +1。例如表 1： 事项开始时间结束时间事项 A2020 年 1 月 1 日2020 年 1 月 5 日事项 B2020 年 1 月 3 日2020 年 1 月 6 日事项 C2020 年 1 月 4 日未设置事项 D未设置2020 年 1 月 3 日依据表 1 的数据，该成员的计划事项统计结果如下： ...

前言当今企业发展不再以大为目标，而更多追求强和快，因为只有后者才能适应时代变化让企业处以不败之地，我们称这个时代为快鱼吃大鱼的时代，追求快和强也是企业的新形态。 传统行业小到菜场经济，大到航空航天，在逐步被互联网和创新颠覆。由于数字化、智能化给企业发展和管理带来的竞争压力，更多以敏捷为起点的跨职能协作正在逐步发展，特别是电子商务领域。 作为创新驱动和创新引领的行业，电商领域的技术和模式不断的创新，电商企业在这个时代如何寻找生命力和增长动力，如何去定义产品的“强”和研发的“快”是其必须面临的课题。 在电商行业为代表的大多数企业里，业务效能管理用于实现产品的强，交付效能管理用于实现研发的快，通过引入敏捷思维+DevOps的模式，企业在对业务效能和交付效能的管理上，将不同于传统模式下的管理，从而助力企业更快的生产更强的产品，在每年的购物大促期间取得更好的销售成绩，提高品牌的影响力和市场能力。 业务效能传统业务效能以KPI指标为导向，将企业经营目标分解到各个业务领域，并挂钩绩效以促进员工积极性，实现企业经营目标的达成。指标通常包含业务增长、净值、用户数等，往往以年为周期进行计划，执行和考核验收。 这种模式在大多数情况下是行之有效的，但是当企业面临环境变化，竞争对手变化，供需变化时变成难以应对，这在电商企业中，影响尤其巨大。例如今年年初的新冠病毒影响打乱了多数企业年初的目标部署，导致业务发展受挫，对于传统绩效管理这是场灾难。 新形态的业务效能包含两个层面的含义：业务效能机制和业务效能指标。 业务效能机制：企业最高目标和最终执行者之间必须是相互对应的，否则就存在损耗。这意味着企业目标必须穿越董事会、总经理、部门领导精确传达到执行者，同样执行者的执行结果需要及时反馈，为上层领导们调整目标提供切实有效的量化依据。为了保障双线链路的畅通，需要引入更为频繁的敏捷迭代效能制度机制，将年度规划转换为季度QBR（Quarterly Business Review）模式。 业务效能指标： 企业需要重塑产品价值定义，而这不仅仅是业务指标，应该关注实现业务指标增长所需要的一切相关元素，我们称之为价值元素。例如北极星指标、用户分层转换率、用户净荐值NPS（Net Promoter Score）、用户行为数据等，以大数据为依据设计的产品核心效能指标_。_ 产品在不同的阶段应该对不同的价值元素进行OKR方式的进行管理，实现产品综合竞争力提升，这样的产品才能称之为“强”竞争力和生命力。 交付效能科技型企业研发交付管理主要围绕三大核心领域展开管理：产能（或效率）、质量、成本。传统度量通常围绕三大领域设置指标，如人均代码行、故事数（点）作为产能，测试和生产缺陷数作为质量依据、人月费率来考核成本等。对研发的效能评价因为技术和产品的差异性变得不可执行。在新形态下，研发效能的定义需要在原有管理领域基础上同时关注：价值流动效率、工程效率、度量基准。 价值流动效率：业务人员在研发领域最关心的是，从需求提出到触发最终用户操作所需经历周期时长，我们称之为前置时间，这代表着我们响应市场的速度有多快。在平均40天的创新叠加周期内，企业的研发效能必须保持小于40天的前置时间才能确保产品的竞争力始终领先。而这也是敏捷迭代交付模式中追求MVP，高频交付的小步快跑模式的意义所在。分析前置时间中各个环节的过程数据是提升产品“快”速交付的关键。 工程效率：迭代高频的交付模式需借助自动化来实现交付效率最大化，并减少人为发生的错误风险和时间成本。在DevOps指标中分层自动化测试覆盖率、持续集成频率、一次投产成功率、环境可用率等都是需要关注的指标项。 度量基准：研发指标都和研发的输入即需求相关。需求规模的度量方式将影响研发指标结果的客观性，如代码行、故事点、人天经验值都是效能度量产生偏差的根本原因。选择统一规范的需求度量基准方法（如FPA），将为研发效能度量和改进提供最重要的依据。 结束语敏捷研发已成为业界主流，更是企业提升效能的制胜法宝。DevOps作为敏捷理念向运维领域的延伸，为企业在数字化进程中追求创新和市场响应提供坚实的支撑，更是提升企业转型的动力。作为企业需要做的就是拥抱敏捷和DevOps，让交付团队与运维团队互相协作，提升业务的能力。重塑企业效能。 华为云软件开发平台（DevCloud）是集华为近30年研发实践、前沿研发理念、先进研发工具为一体的一站式云端DevOps平台，618年中钜惠，DevCloud产品历史低价，助力企业更快的拥抱敏捷和DevOps，提升效能，做强产品，提高交付效率。 点击关注，第一时间了解华为云新鲜技术~

本文通过一个真实的案例介绍了敏捷项目的实践过程和产品经理在其中的角色和作用。 产品经理在敏捷项目中的角色在敏捷交付项目中，PO扮演着重要角色。PO确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品ROI（profitability of product）负责，是维护产品需求清单（ product backlog ）的人，代表利益相关者的利益。 PO在敏捷项目中的主要职责如下： 1、确定产品的功能； 2、决定发布的日期和发布内容； 3、为产品的ROI负责； 4、根据市场价值确定功能优先级； 5、每个sprint中，根据需要调整功能和优先级（每个sprint开始前调整）； 6、接受或拒绝开发团队的工作成果； 7、参与Scrum Planning Meetings（Sprint计划会议），Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会） 一句话总结PO的职责：告诉产品团队要做什么，做功能的先后顺序是怎样的，需求有变动时该如何处理。 如何在一个月的时间完成20个史诗级故事？毫无疑问，这是一个impossible mission。先看着个需求是怎么来的。 笔者服务过一家做园林绿化的公司，这是一个传统行业，主要承接市政工程项目。老板在寻找新的市场机会，他看到了客户在信息化产品方面的需求，决定投入智慧园林产业。老板希望为客户提供信息化、智慧化的公园物联网平台和整体解决方案，以此增加公司的业务范围，为此公司成了新的智慧公园事业部。 在前期在经历了9个月的的探索并交付了一个内部用户项目后，并没有取得预期的成果，销售部门不知道该卖什么也不了解客户的需求，研发部门面临巨大的交付压力，老板对部门的整个部门的业绩不是很满意。 我作为新项目的高级产品经理，临危受命，目的是就是帮助老板探索新的市场机会，尽早推出产品，让销售的兄弟可以带着弹药上战场。 愿景愿景是描述了项目的发起原因以及预期的最终状态。--施瓦伯《scrum敏捷项目管理》 第一步是了解项目的需求。这里有两个主要的利益相关者，一个是客户，一个是老板。在经过两周的市场调研、竞品分析后，我决定对老板进行一次访谈以确定需求。经过访谈，确认了老板的关注点： 1、尽快(最后确定下来是1个月)让客户看到智慧公园产品的样子，包括软件demo和硬件设备； 2、尽可能充分展示公园的业务场景和设备(最后确认20个业务场景，40个设备)； 3、在项目启动前，提供项目的预算。 4、可以先开发一个演示产品(MVP)，数据可以是静态的。 如果按照以下公式来”一键生成”产品愿景： 今天，当【用户群】 想要【期望的活动/结果】时， 他们必须【当前的解决方案】 。 这是不可接受的，因为【当前解决方案的缺点】。 我们相信有【一种体验/一个场景/一项服务/…，是令人向往的】， 我们通过【技术/方法】达成它。 那么，本项目的愿景就是："今天，当客户想要了解我们的产品时，他们只能通过画册的方式，这种体验不是很直观，他们看不到设备的状态和运营数据，我们要给客户一种更接近实际效果的产品体验，我们希望通过开发一个演示产品达成它。" Got it，原来老板就是想做一个演示APP! 通过这个APP客户会可以进行浏览、拖拽、点击等交互操作，可以看到运营数据和设备的状态(演示数据)，甚至可到公园的视频监控画面(提前录好视频)。 本项目和BOSS沟通后决定采用敏捷项目交付产品，主要目的是: 简化文档提高效率尽早交付敏捷项目有很多好处。其中一个就是交付可供客户使用和验证的最小可行性产品（MVP），获取反馈后再不断迭代改进，连接真实的设备和数据，最终打磨出真正符合客户需求的爆款产品。 在愿景阶段我们还需要确定任务角色和场景，以及发布产品路线图。 人物角色和场景角色可以帮助我们确定目标客户，也就是“谁”的问题；场景可以是我们理解产品如何改变客户的生活角，确定“在什么情况下”“干什么&遇到什么问题”。可采用头脑风暴和业务场景技术确定任务角色和场景，本项目确定任务和主要场景如下： 产品路线图接下来是创建产品路线图，产品路线图是产品需求的高层次概述，产品路线图 将用户关注点/主题按优先级排序，分成若干阶段，每个阶段都需要一个Sprint计划。创建产品路线图需遵循4 个步骤： 1）确认需求 2）将需求分类或分定主题， 3）评估相对工作量和优先化级， 4）评估粗略时间框架（评估sprint持续时间，以及粗略发布时间） 本项目是整个产品路线图的第一个阶段。 发布计划发布计划是宣布产品对外发布的时间和功能范围，大部分软件项目以每 2 到 6 个月作为一个发布周期，一般以产品开发线路图开始规划发布。 ...

作为全球跟踪时间最长，规模最大的敏捷调查，VersionOne的敏捷报告已经成了很多人每年学习计划中的重要事项。现在我们就来了解一下连续第14次发布的年度敏捷报告，看看在调查结果的背后，都传递了怎样的一些趋势信号。 企业敏捷转型越来越关注业务价值一切回归初心，所有的方法与实践还是需要回到服务业务目标。各组织都在实践中不断成长，只有真正有价值，能够对业务有所贡献的方法与实践才能得到关注和发展。自然地，敏捷转型的动力将转移到业务敏捷，它关注产品维度的短周期、小批量、高价值、高质量，以及稳步建设达到这些目标的基础能力，再加上团队级的基础敏捷实践，这样的敏捷转型才是解决问题的根本措施，业务敏捷才是组织真正需要的。 报告指出，采用敏捷的两个最大原因是加速交付71%和管理变更优先级的能力63%。前5位的原因还有提高生产力、业务融合、增强质量。降低成本从去年的41%降到了26%。 以上数据说明大家提升了业务目标的关注度，对成本的关注开始降低，这从侧面反映了大家对敏捷转型成本的认可。所有这些基于价值而非成本的目标，能持久驱动组织更加敏捷、更有生命力。 另外，报告中提到的规模化敏捷方法占比最高35%的SAFe框架，从5.0版本开始，也全面围绕业务敏捷进行方法论的重新梳理，把对业务的支持放在了前所未有的高度，引领了规模化敏捷转型的方向。 DevOps发展趋势越来越明显作为与敏捷方法相辅相成的DevOps实践越来越受到组织的青睐，尤其是大型组织，更加希望通过基于相关工具链的标准化价值流管理，加强各团队协作，加速交付速度，提高质量。前面提到的关注业务价值，需要技术的投入和工具支撑，这些正是DevOps的强项。也正是因为实际收益的支撑，使得DevOps的接受速度如此惊人。 报告中DevOps转型成效占前5的是：加速交付速度70%，改进质量62%，减少风险48%，增加客户满意度43%，与业务目标一致的交付39%，这些都和组织的需求保持一致。持续提升了组织对DevOps的青睐。 报告还指出，在上一报告73%的高应用水平基础上，这次更有高达76%的组织有启动DevOps的计划，而且90%的组织认为DevOps对他们非常重要，这充分说明了DevOps的热度。另外，敏捷工程实践的关注度从22%上升到了34%，强制审计的刚性需求提升了自动审计工具的关注从10%上升到了28%，这些也都能结合DevOps得到更系统化的落地。 DevOps转型牵涉面广，需要规模化敏捷的辅助，而规模化面对的挑战主要来自文化相关的阻力。前三位分别是一般组织的变革阻力、缺乏足够的领导层参与、跨团队的流程与实践不一致。这些分析给我们一个清晰的指示在于：改变系统需要管理，对于规模化敏捷，只有团队层的实践是不够的，还需要领导层的充分参与和工具链支撑。这也与大型组织更关注DevOps的原因一致。 越来越多的组织开始重视对敏捷效果的度量关注业务价值的明显趋势还体现在敏捷转型和DevOps转型的度量，基于对价值流管理的分析，未来在价值流度量上会有更多投入。另外，在对外包商相关的度量实践中，新FPA方法会带来更多透明度，利于双方关系的长期发展。 报告中相关的内容有对敏捷转型成功的度量，前5位的指标分别是客户满意度、业务价值、按时交付、质量、业务目标达成。实践敏捷5年以上的组织，有更大比例开始启动DevOps相关项目，也对价值流管理及其工具链更感兴趣。95%的公司正在实施敏捷，且有18%是所有团队全部实施。千人规模的组织开始在更多部门实践敏捷，非IT部门实施敏捷也占到了30%。这些数字从参与度上给予了后来者更多信心。从成熟度角度，有84%的组织表示仍未进入较高成熟度，说明敏捷之路仍然任重道远。 这些数据表明，在落地敏捷转型过程中，需要具体交付敏捷辅导的人员和项目执行人员引起足够的重视，以确保敏捷的可持续性。 对外包商的敏捷交付能力要求越来越高在一半应用敏捷方式的外包项目中，有42%的受访者认为可能会在未来24个月内增加敏捷实践的使用。这表明利用敏捷获得相对竞争优势的组织会加大投入，因为这是为数不多的使外包组织能够持续增长的引擎之一。同时对甲方而言，只有包含外包商的敏捷才是整体的敏捷，才能真正发挥助力业务目标的最终价值。 敏捷之路任重而道远，转型之路仍需不断的成长和磨砺。 对敏捷或DevOps的结构和相关知识，小朋友你是否有很多问号？那么这里的准备的“技术秘籍”是你需要的。本期【敏捷智库】为大家带来每日站会、用户故事拆分及DevOps转型闭坑指南等三个领域的的精彩内容。 根据“秘籍”的指导，在享受专业的技术解读和实战讲解，学习当下最新技术实践回复帖子即可得到这三本“秘籍”，还等什么呢，快来参加吧~~ 如果您想在知识卡看到哪些内容，有什么建议，请对我们说：点这里~ 知识卡原文链接： 第1期：每日站会18Key 第2期：用户故事拆分 第3期：DevOps转型避坑指南 知识卡每周持续更新，请收藏关注~高清无水印知识卡请点击附件下载： 【干货分享】敏捷&DevOps知识卡第2期_用户故事拆分.pdf 【干货分享】敏捷&DevOps知识卡第1期_每日站会.pdf 【干货分享】敏捷&DevOps知识卡第3期_DevOps转型避坑指南.pdf 点击关注，第一时间了解华为云新鲜技术~

前言：宜信技术人物专访是宜信技术学院推出的系列性专题，我们邀请软件研发行业的优秀技术人，分享自己在软件研发领域的实践经验和前瞻性观点。第四期专访我们邀请到宜信科技中心财富管理产品部负责人Bob，与大家一起聊聊个性化推荐产品功能的设计和B端产品的功能策划方式。 拓展阅读：回归架构本质，重新理解微服务|专访宜信开发平台（SIA）负责人梁鑫) 智慧金融时代，大数据和AI如何为业务赋能？|专访宜信AI中台团队负责人王东) 一切技术创新都要以赋能业务为目标|专访宜信数据智能研发部负责人张军) 记者：Bob老师您好，首先请简单介绍一下您目前主要负责的产品，这些产品各自面向的用户及核心价值是什么。 Bob：我在宜信科技中心财富管理产品部，主要负责为我们财富业务的客户和理财师提供线上科技能力和产品，主打的产品是宜信财富APP和宜信理财师APP。宜信财富APP，面向财富客户提供一站式线上财富管理服务，包括“投前”的个性化推荐、线上多方式的投教等；“投中”的纯线上化签约、交易和支付；“投后”的资产分析、净值同步和报告等。 宜信理财师APP，面向理财师提供包括客户管理、线上营销、交流互动等在内的一系列线上工具，对他们进行科技赋能，从而帮助他们更好地获取客户、洞察客户、服务客户，最终实现销售业绩的达成。 记者：您刚才提到，我们的产品在投前环节提供个性化推荐功能，最近几年随着大数据和AI的兴起，智能化的个性推荐成为产品功能的一种主流趋势。那么就个性化策略设计而言，在产品的前端功能设计和用户体验、后端用户画像数据与产品匹配方面有什么方法和原则？用到了哪些技术？ Bob：首先，在起初的金融产品选品上，我们会基于大数据模型，从宏观市场预判、大类资产配置、产品的历史业绩表现等多维度进行自动化甄别筛选，从而将市场上最优秀的、最符合客户需求的产品快速纳入到选品池中，并定期更新选品池。其次，通过对用户静态和动态的KYC进行智能识别，对每一位客户进行画像，从可投资资产规模、客观风险承受能力等多维度洞察他们的理财需求，并根据客户不同的需求进行聚类和分层。 最后，通过机器不停学习过往用户的理财行为，建立智能策略，将最适合的金融产品与适合的客户建立连接，并通过前端界面推送给客户。 记者：从用户需求出发设计产品功能和用户体验，涉及到算法、大数据等技术，这就需要比较长的时间来实现产品理想态，产品经理如何协调版本规划和技术实现的节奏？ Bob：罗马帝国不是一天建成的，市场也是瞬息万变的，这就要求产品的更新迭代能更好地应对变化。我们在团队内部引入了敏捷项目管理的思想，将大的产品规划进行需求拆解，先以最快的速度发布一个MVP(Minimum Viable Product,意思是最轻量级的可行性产品)，以快速得到市场检验和用户反馈。接下来根据这些反馈的数据，不断调整产品策略，小步快跑，快速迭代，使产品逐步贴近市场和用户。 目前宜信财富APP和宜信理财师APP的版本迭代以一个月为周期，每个月的版本发布称为一趟“发布列车”，每趟“列车”会“装载”哪些产品特性、满足哪些用户需求，在发布的一个多月前就会收集上来，然后进入产品设计和开发阶段，就相当于列车的“预售票”。而宜信财富的微信小程序、H5以及市场活动，迭代周期更短暂，会缩短到一周或半个月。 记者：产品验收过程中，对于智能推荐产品的推荐准确度是怎么评估和校验的？ Bob：拿智能推荐产品来举例，产品经理关注的核心指标是从为用户推荐产品到交易完成的转化率。从将产品推荐推送到用户面前，到用户浏览、完成风险评估问卷，再到完成申购、打款等全流程，我们都会去观测并评估每一步转化率是否达到预期，从而有针对性地制定产品改进计划。记者：据悉，您所负责的产品既有面向C端用户（财富业务用户）的，又有面向B端用户（企业理财师）的，请问这两者之间的核心区别是什么？怎么界定一款产品属于B端产品还是属于C端产品？ Bob：在《场景革命》这本书里有这样的一句话：“to B和to C本质上没有什么不同，因为它们都是给人用的”。这句话我非常认可，无论是“B”还是“C”，他们都是用户，都希望使用令人满意的产品。如果一定要说区别，可能是B端产品客群相对固定，而且他们更善于主动找上门来提出需求，产品经理需要根据特定客户去挖掘需求，定制化产品。而对于C端产品，更需要产品经理对用户群体进行宏观把握，并善于运用数据工具来洞察客户的画像，找出主流客群的共性场景和需求。 记者：宜信B端产品的设计思路是什么？具体解决了哪些用户需求，从哪些角度考虑功能的设置? Bob：宜信财富服务的B端客户就是我们自己的理财师，他们都是我们公司的员工，相对固定。我们的总体思路是通过提供线上工具，尽可能地帮助每一个人提升工作效率、降低企业成本，最终完成销售绩效，从而提升宜信财富整体业绩。具体包括以下几个方面：获客方面，我们提供微信端获客小程序，让理财师不用和客户见面，通过微信快速分享客户感兴趣的活动、文章、产品等内容，就能引导他们快速实现注册、实名和洞察。 洞察客户方面，我们提供AI-KYC的工具，帮助理财师在几秒内快速洞察客户的理财诉求和偏好。 管理客户方面，我们提供线上化的客户关系管理工具，帮助理财师更好地管理相关资料，包括：客户画像、生命周期、行为数据等，让理财师在服务客户时更实时，真正做到懂客户所需。 与客户互动方面，我们提供一系列在线营销工具，帮助理财师更便捷、专业地为用户提供在线服务，包括：市场活动的邀请管理、资产的分析等。 理财师管理方面，我们提供一系列的数字化管理工具，帮助理财师和他的管理者更方便地进行销售管理，包括活动量管理、KPI业绩管理等，大大提升了他们的工作效率。 记者：前段时间，产品经理圈有个很有意思的话题：5年后，产品经理会消失。当然有些危言耸听，但是产品圈的焦虑确实存在，您如何看待这个问题？人工智能等新技术的兴起也在推动产品功能的改变，作为产品经理，您认为要如何才能让自己保持对新技术的敏感度，将新技术应用到我们的产品中呢？您认为未来产品经理的发展走向有哪些可能？ Bob：我认为一个行业可能会随着时代的发展而变得兴旺或衰败，可产品经理这个岗位在未来只会越来越重要。首先，无论哪个行业或公司之所以兴旺，毫无疑问，其成功的要素都离不开以用户为中心、以满足好用户的需求为目标，以让用户满意为使命，而产品经理这个岗位就是以用户为中心而生的。 其次，产品经理并不是一个劳动密集型岗位，这个岗位的核心价值是通过产品经理自身对行业和用户的洞察，设计出令人惊叹的产品。这里面有对用户情感的洞察，有对产品设计感性的领悟，有对未来的敏锐预判，而这些都是无法用机器来替代的。 如何保持一名产品经理的竞争力？ 1）建议产品经理在日常工作和生活中有意识地培养自己对市场的敏感性，无论是近期发生的新闻，还是和朋友的一次聊天，或者生活中遇到的琐事，都有意识去发现其中的市场机会，这是一个持续的过程。 2）多体验市面上出现的新鲜产品，这是获得新的灵感、掌握行业最新动态很有效的方法。这里的新鲜产品不是指老生常谈的微信、百度、今日头条这样的大众产品，而是去挖掘更新鲜有趣的产品与服务，始终保持好奇心。 3）硅谷目前仍然是世界互联网的创新中心，建议多阅读来自硅谷互联网媒体的原汁原味的英文资讯，毕竟很多新的技术和产品模式仍来自于硅谷，可以借鉴和启发思路。

为了让大家对敏捷有更多的了解，小编特意采访了阿里巴巴高级技术专家、敏捷教练张燎原。他是如何看待敏捷、如何帮助团队落地敏捷的，作为研发团队的一员，我们可以从哪些地方着手敏捷，以下是对他的采访。 嘉宾简介：张燎原，阿里巴巴高级技术专家，他是敏捷和精益方法的积极实践者和推动者，具有十多年软件研发一线实践经验，经历过消费电子、通信及互联网多个行业，长期从事研发管理、研发教练及组织转型工作，曾负责Nokia全球大规模敏捷导入实施和转型辅导，成功帮助淘宝、闲鱼、阿里云等事业部引入精益产品交付和创新方法，帮助实现DevOps转型。译有《程序员度量》、《软件驱魔》等。同时，他热衷编写代码和开源，涉及软件设计、测试驱动开发、代码重构、遗留代码的维护和持续集成及交付。工作之余，他还擅长画画和摄影，被同事戏称“最会画画的敏捷教练”。 1、燎原你好，我知道你是敏捷和精益方法的积极推动者，在阿里也辅导过淘宝、闲鱼等多个团队。从事敏捷这么多年，特别好奇，你是如何看待敏捷和精益的呢？ 张燎原：以前，敏捷作为一个很时髦的概念，大家总是反复在提，就像现在的DevOps一样。在我看来，不论是敏捷、精益还是DevOps，能不能解决问题， 这个才是最重要的，一切不以解决实际问题的概念炒作都是耍流氓。去年我和何勉老师（阿里巴巴敏捷教练团队负责人）在一起讨论， 我们是在做敏捷、精益的转型还是其他的什么，后来我们决定提升研发效能。作为一个研发团队，能够持续快速高质量地交付有用的价值，才是我们觉得作为一个研发团队要追求的。 提升研发效能，主要分两点来看，第一个是回答如何持续快速高质量的交付的问题。在交付团队里，大家协作特别好，写的代码要没有太大的问题——高质量，发布特别快。所以，我们知道的比如看板、Scrum是解决我们协作的问题；测试自动化、CI/CD以及DevOps是为了帮助高质量的发布；我们提倡的DDD、Clean Code，是为了让我们的代码能够更健壮、质量更好、更Clean，大家在协作的时候，能够通过代码来交流，这些都是提升交付能力的手段和实践。 另外一点是，就要回答什么是有用的价值这个问题。对很多工程师来说，大家可能更关心代码写的好不好，从产品那拿到的需求，大家基本都认为是对的。很多时候产品提了一个需求，一个工程师可能要做一天甚至是一个礼拜才能完成这个需求。但是，如果这个需求没有价值，那就相当于白干了。所以这个时候，我们要走到源头去看一看，这个需求是否是有用的，对我们的业务有没有帮助，是否值得我们投入。 所以你问我如何看待敏捷，我不会说是要快速响应变化，因为我觉得这样还是有点抽象。回到研发的本质，我们是要持续快速高质量地交付有用价值，从解决阻碍我们达成这一目标的问题出发，选择相应的方法和实践，最终解决掉这些问题，这才是实实在在、对我们有帮助的。 2、你是如何帮助团队落地敏捷的，这中间有没有遇到一些困难？ 张燎原： 我觉得首先是让大家看得见，对问题形成一致的理解。当我们开始在团队落敏捷时，大家会说我没有问题，所以首先我们要让大家看得见问题，在问题上达成共识。这样，目标才会一致，做事才能齐心。 其次，大家在解决方案上要达成共识。有的时候，针对一个问题，可能有A解法，也可能有B解法，但我们要一起探讨是用A还是用B。例如，B可能见效快，但不持久；A见效慢，但是持久。这个时候，我们得去找一个折中的解决方案。 再次，要有一条明确清晰的改进路径。解决方案要能解决问题，但同时也要给大家改进的信心。每个阶段都能解决一些问题，通过持续地发现和改进问题牵引着大家往前走。这种改进不应该都是烟斗式的，即开始会导致效率先降下来，然后才会慢慢持续往上爬。 最后，有节奏地给出有效反馈。通过在合作过程中，通过数据也好，或者观察到的问题也好，持续地给团队反馈，让大家明白自己是在正确的路上行走的。 这几点对我们来说都是比较大的挑战，但比较好的是，我们现在能驾轻就熟来应对。还有一点，大部分时间，我们是站在全局的视角来看问题，这和具体的职能团队是有差别的，他们更多是站在自己的职能的角度。大家看问题的视角不一样，在沟通的时候，也就需要更有同理心。 3、在敏捷实施过程中，给团队建立信心真的很重要，能具体说说你是如何在短时间内给团队建立信心的吗？ 张燎原：在实施转型或提效的时候，需要持续地给大家信心。我们不太建议一股脑地给一个完整的解决方案，把之前的全部推翻掉，就按照新的来。因为我们接触的团队，基本上都是工作在现有的业务上的，哪怕是创新型的一些团队，大家之前也一起磨合了很长的时间，大家都有自己熟悉的工作方式和习惯。 我们团队之前有一个案例：《4个迭代，从批量交付到持续交付转型》，就非常典型，每做一个迭代都是让大家看到收益，然后才有信心做第二个迭代。例如，当时的第一个迭代是把所有的职能端到端的拉齐，让大家看到整体。这个时候就减少了各个职能之间的交流误会，整个沟通就顺畅了。然后在整个可视化的协作流程中，大家就会发现：喔，原来需求有这么多反复、原来需求太大了，甚至需求都没搞清楚就开始了。其实很多时候，这些都是大家自己发现的。当解决了协作的问题，大家有了信心，就开始着手解决需求的问题。当需求澄清的问题解决后，又会发现发布速度是不是可以更快一点，原来一个月发一次，现在是不是可以每个礼拜都能发。这样每一个迭代都会有一些点得到了改进，并且也能够持续暴露其他的一些问题，能够让大家朝比较理想的状态前进。 如果你告诉大家落一个解决方案需要半年的时间说半年之后才能看到结果，你做了一个月没结果，大家能接受，第二个月没结果，大家可以坚持，如果第三个月还是如此，可能就没有然后了......这是我们在制定解决方案的时候需要特别考虑的。 4、你们的敏捷实施或提效一般多久能见到效果？ 张燎原：从目前在阿里接触的一些团队来说，一个月内，基本上就能够看到一些明显的效果了。当然这跟我们合作的团队也有很大的关系，大家彼此都挺配合的，甚至有的时候他们比我们还专业，他们会说，燎原老师，你看这种方式是不是会更好。然后我发现他给出来的点可能是我都没想到的，所以在这个过程中，我们也是在相互学习。 当然，改进是一个持续的过程，目标越大，要投入的时间可能就会越长。 5、一般什么时候可以判断说这个团队辅导OK了？ 张燎原：一般情况下，在辅导开始的时候，我们都会有特别明确的目标，我们会清晰地把需要改进的问题定义出来，让大家看得见，找出根因，而不仅仅是现象。随着问题逐渐被解决，后面我们会有意识的慢慢抽身出来，看没有我们的时候，是不是也能够work起来，如果我们发现没有我们也行，这个时间也就到了。 在这个过程中，很重要一点，我们要善于发现和培养有潜力的同学，在被辅导团队留下种子，这些同学会是团队持续改进的生力军。 6、有什么方法可以帮助一些团队发现自己的问题？ 张燎原：我觉得能做IT的人都是聪明人，如果他没有发现这个问题，更多的是因为他没有这个意识，没有意识到自己要去看有没有问题。所以我们会通过其他的一些渠道，让大家去意识到这件事。老实说，大家不缺方法，缺的是意识，我们希望能够让大家意识到这件事情的重要性，如果我们没有一个很好的研发能力去支撑业务效能的话，我们也很难把业务效能做好。虽然很多时候我们只觉得业务效能很好很重要，我承认确实很重要，但研发效能是基础。如果你有一个很好的点子，但是没有很好的这种研发团队，没有研发方式来支撑。你的点子，也实现不了。 7、如何让更多的有需求的团队也能得到你们的支持？ 燎原：确实，让我们去辅导一个团队，肯定没有问题，但是如果让我们同时去辅导很多的团队，精力肯定就忙不过来，一个人一天就24个小时。这个时候我们会有一些策略，例如，就像前面所述，我们会培养业务团队的一些同事，让他们成为这方面的专家，就像一颗种子，他也会发展壮大，然后他自己做的一些事情，对他所在组织都会有很大的帮助，这是一种杠杆撬动的力量。另外，我们还会通过其他的一些手段，例如线上、线下的培训课程、最佳实践文章、案例分享，以及鼓励更多同事把他们一些好的点子share出来。我相信这样一个一个的点，都能够帮助规模化。 还有另外一个很重要一点，我们所在的研发效能团队，通过各个业务部门的实践，对实践方法及不同场景的总结沉淀，会形成一些体系化的东西，然后与工具做更多的结合，让大家通过工具就可以轻松上手，把好的实践最大化。例如，现在Aone的看板，看板上为什么分那些阶段、为什么有那样的一条条泳道、需求是怎样移动的，最早我们是用物理看板，但是现在我们把它都融入到产品里，团队建好自己的项目空间，就自动会有一块项目看板，从而让好的实践在更多的团队得到使用。 8、作为研发团队的一员，我们每个人可以如何着手去实施敏捷？ 我觉得单独从了解方法或知识的角度来说，看完了一本书或者一篇博客，10天半个月可能也就忘了。但是我们可以从自己现实当中的问题出发，比如做为程序员可以去思考，如何能够让代码变更高效地发布。例如你可以搭一个持续集成的流水线，让大家的代码一提交就触发自动化的检查、自动化的测试和部署，把这个做好就是往敏捷，往研发效能的提升上就走了一大步。 对产品经理来说，需求应该如何组织，是否都有对应的目标，任务朝需求对齐，需求朝目标对齐。对于一线管理同学，可以思考整个团队的能力模型，团队的协作当中有哪些问题，比如测试和开发同事、前端和服务端之间的协作有没有更好手段，让大家的协作更高效。这样每个人都站在自己的角度上，改进一点点的话，形成合力。大家再在站在系统的角度，串起来一起看，就会改进很多。 即使是一个刚入职场开发同学，也可以思考代码能不能写的更clean，减少code smell，把这代码写的别人一看就懂，每一段代码都能有很好的单元测试，减少维护成本。这些都是在提升研发效能，在实践敏捷。敏捷不是挂在嘴上，而是落在每天的工作里。 9、最后，本周六你的分享《从持续交付到业务创新》，希望能给大家带来哪些收获？ 张燎原：很多时候我们做工程师，都是站在自己的位置去看待问题，很少有机会能够站在全局，端到端的角度去看待问题。这次分享我希望能够带着大家一起，从研发的端到端、从需求到交付，去了解我们可以通过哪些手段去提升研发效能，以支持我们提升业务效能。 对于每一个不同的角色，能够富有同理心地去看待软件研发过程中的其他职能的工作，真正做到“眼高手低”：即看到整体，落到实处，整体形成合力，往组织效能最大化的方向去努力。 阿里有一句话叫做：一张图、一场仗，一颗心，首先画好一张整体的图，把团队之间协作的图画好，我们才能得对齐，上下同心，然后把这场仗打好。期待与大家的交流。 本文作者：云效鼓励师阅读原文 本文为云栖社区原创内容，未经允许不得转载。

敏捷大数据，即在敏捷理念原则指导下，构建出一系列通用平台工具，和一整套大数据应用全生命周期方法学，以支撑更轻量、更灵活、更低门槛的大数据实践。本文从理论层面整体解释我们所理解的“敏捷大数据”。 一、敏捷大数据的理念原则1.1 组件化／平台化／产品化／本地化组件化／平台化：通过对大数据处理链路进行模块化抽象，形成多个功能高度內聚的组件化平台；组件化平台既可独立与已有平台组件整合使用， 也可组合起来以解决更多不同链路上的问题。 产品化／本地化：通过组合不同的组件化平台，加上抽象萃取过的业务逻辑模型和规则算法模型，可以很容易构建特定业务领域的产品化解决方案；解决方案产品实际落地时可进行本地化处理，主要包括数据模型适配／规则集引入／算法模型参数调整等。 1.2 统一化／开放化／管控化统一化旨在简化系统复杂度，提高管控能力；开放化旨在增强适应度，提高灵活性；两者相辅相成，需要找到一个合理的平衡点，且不失整体的管控性。 1.3 标准化／接口化／配置化／可视化标准化／接口化：在大数据处理链路中，形成一系列标准化协议，包括数据命名空间协议／元数据和数据类型规范协议／数据访问接口协议／查询语言协议／数据传输协议／数据安全协议等；以服务接口和队列接口方式提供系统间交互。 配置化／可视化：以配置化和可视化方式提供人机交互。 1.4 自助化／自动化／智能化现代数据应用要求能力输出，让领域用户在受管控的环境中，可以更加自助化的使用平台和数据实现业务需求；自助化的常规操作可以以自动化方式更好支持；自助化的洞察分析可以以智能化方式更好支持。 1.5 引擎驱动化（事件引擎／动作引擎／规则引擎）通过引入高级引擎驱动能力，使得敏捷大数据应用可以更加迅捷、灵动、主动的触达外部受众，这时大数据应用本身已经成为强大的业务驱动引擎。 二、可以抽象出的通用平台工具以企业级实时数据平台为例，我们在敏捷大数据理念原则的指导下，对实时数据平台整体端到端进行了模块化切分，并形成一系列标准化协议，最后以统一开放的原则确定了要开发哪些通用平台工具及其边界和接口规范。 上图是实时数据平台的概念模块架构图，在后续文章中我们会以实时数据平台为切入点，详细阐述衍生出的通用平台工具的抽象概念和架构设计。 三、贯穿大数据应用全生命周期3.1 需求分析验证阶段在需求分析阶段，我们需要有能力可以快速开发数据应用原型POC，并且在验证有效后能够快速迭代以尽早覆盖所有需求点。 敏捷大数据的平台化／配置化／可视化等能力能够支持业务开发人员通过配置和可视化方式快速地进行需求迭代验证。业务开发人员只需要关注业务问题本身，无须过多关注大数据技术问题。 3.2 架构设计选型阶段在实际存储和计算引擎选型过程中，要考虑很多很多因素，除了满足SLA和数据规模等要求，还不得不受到开源技术选型的种种限制和问题。 敏捷大数据的标准化／接口化／统一化／开放化等能力提供了一套架构选型的最佳实践，既极大的减少了系统设计的复杂性，屏蔽了开源技术不兼容的问题，也能够支持选择不同存储和计算引擎的灵活性。 3.3 实施测试调优阶段大数据定制化开发的实施测试和调优往往是件很耗时耗力的工作，并且随着处理链路的变长和技术选型的多样性，更加增加了测试调优的复杂度。 敏捷大数据的平台化／接口化／配置化／可视化／统一化／管控化等能力可以让实施测试调优的过程变成只需进行可视化配置／实验／验证的迭代过程，数据处理链路过长问题被配置化／可视化屏蔽，技术选型过多问题被统一化／管控化屏蔽。 3.4 上线部署迁移阶段大数据定制化开发的上线部署迁移往往步骤繁杂，容易出错，即使可以以脚本方式支持，也可能由于不统一和不直观带来潜在问题。 敏捷大数据的平台化／配置化／可视化／统一化／管控化／自助化等能力可以让上线部署迁移更加简单，这些都得益于平台的统一化能力，并且这些能力以自助的方式开放给用户。 3.5 管理运维监控阶段管理运维监控在企业中往往是统一归集管控的，敏捷大数据的平台化／管控化／自助化等也提供了相应的能力，此外，还可以提供自动化／智能化等能力进一步降低运维工作量；同时也可以通过接口化能力与环境已有监控运维系统集成。 四、践行敏捷大数据实践 上图即为我们所总结的敏捷大数据各个组件的关系： 敏捷大数据理念＋敏捷大数据平台栈＋敏捷大数据方法学 → 敏捷大数据实践 本文给出了“敏捷大数据”的定义，以及敏捷大数据理念，并且简要描述了基于这套理念之上如何构建平台栈和如何实践方法学。在后续的文章中，我们会围绕具体的敏捷大数据实践经验详细展开我们的敏捷大数据之旅。 作者：卢山巍 来源：宜信技术学院

摘要：敏捷大数据智能化的主要目标就是，结合敏捷大数据实施理念，研发灵活的、轻量化的智能模型，并在敏捷大数据平台上对数据流进行实时智能化处理，最终实现一站式的大数据智能分析实践。 一、前言人工智能的诞生可以追溯到上世纪50年代，在达特茅斯会议上，麦卡锡提出了AI的概念，但在初期的热度过后，人工智能的发展经历了多次低谷，直到从90年代中末期开始至今的这近二十年的时间里，人工智能才真正迎来了黄金时期。尤其是在近10年来，各方面因素都推动其不断发展：理论上，机器学习，尤其是统计学习和神经网络理论不断突破，效果显著；外部环境上，软硬件技术的进步为人工智能模型的实现提供了足够的计算能力；此外，极为重要的一个因素就是在数据方面，大数据技术的发展使人工智能终于摆脱了数据的桎梏，可以在充足的样本基础上提升模型的能力。可以说，现在各领域智能模型的研发绝大多数都离不开大数据技术的支持。 反过来看，人工智能对大数据技术同样有着极为重要的作用。 一方面，对于利用大数据技术收集到的数据需要通过一些智能分析过程才能发现其中的价值；另一方面，通过对已有数据的智能分析，我们可以推导出更多的数据特征，甚至进一步指导数据生产的方向。所以在今天我们谈起大数据的利用，都不可避免地涉及到人工智能、机器学习等概念。 敏捷大数据平台栈作为一个实时数据基础设施平台，是对大数据理论与技术进一步发展的成果，自然也会有对智能化方面的研究与布局。敏捷大数据智能化的主要目标就是，结合敏捷大数据实施理念，研发灵活的、轻量化的智能模型，并在敏捷大数据平台上对数据流进行实时智能化处理，最终实现一站式的大数据智能分析实践。 为实现上述目标，我们对人工智能、机器学习、实时运算等技术，以及相关业务领域知识，乃至产品用户体验都进行了深入的研究与分析，本系列文章将把我们的理念和在上述过程中所获得的一些经验、成果与大家分享。 二、实时数据智能处理随着技术的发展，我们能够获得前所未有的海量数据，如果能够快速、高效地对这些数据进行处理，发现其中的高价值信息，无疑可以极大提升企业的应变能力，从而在复杂且易变的业务场景中迅速地做出战术乃至战略上的调整。因此，实时数据处理已成为未来大数据技术发展的主要方向。数据处理的实时化必然会对与数据紧密相关的智能分析模型造成影响，可以说，为了快速识别、适应外部环境的变化情况，各组织已经开始将数据实时处理能力与AI能力相结合，实现智能数据分析业务的快速交付。 实际上，针对实时数据流的智能化处理技术已经在很多行业中得到了先验。例如在互联网直播领域，基于视频流的实时滤镜、实时特效算法已经在快手、抖音等众多APP中普遍使用，而国外的Twitch等直播网站，也推出了实时游戏数据分析等AI插件来增强直播效果；在体育数据领域，基于实时赛况的球队、球员数据统计分析和赛况走势预测也在各体育数据提供商处，如Opta Sports等，得到了应用；在交通领域，基于实时交通信息的路况拥堵预测系统也已经开始实施。此类例子不一而足，但都反映了实时AI数据处理已经在不同领域、不同业务场景下得到了广泛应用，并且发挥了不可取代的作用。 在金融领域的许多场景中，对于实时AI数据处理同样存在有众多需求，如实时风控、实时数据预测、实时异常检测、实时用户分析等等。下图为实时产品推荐的一个数据流图，可以用于金融产品推荐场景中，例如网贷、保险、基金、股票等产品。 该图描述了如下过程：在交互端我们可以通过埋点获得大量的、不同用户的行为数据，这些数据将被企业实时数据平台采集，与用户、产品及其他数据一起提供给计算层的各类模型，如用户兴趣模型、产品画像模型等。这些模型对用户和产品进行特征刻画，最终提供给推荐模型计算、排序、过滤得到最终的推荐列表。这一过程中我们可以根据采集到的实时用户行为数据流对用户兴趣模型进行更新和校正，从而实现对用户所感兴趣内容的实时追踪。 上图没有体现的一个过程是对产品画像模型的实时更新，尽管相对用户的行为数据而言，产品的特征数据相对稳定，但在实际当中还是有不少产品对时效性要求很高，其画像特征也需要我们进行实时的维护，例如证券市场的数据信息等。这些产品数据流可以通过其他渠道汇总进入企业实时数据平台之中，并提供给产品画像模型进行产品特征的重构，最终提供给推荐模型进行产品推荐。一个好的实时产品推荐系统可以灵敏捕捉用户的需求、响应产品的变化，可以高效地针对用户开展个性化精准营销，提升用户体验度的同时还能够提高获客和关单数量，产生巨大的业务价值。 在上图中企业实时数据平台扮演了为推荐模型提供实时数据的重要任务。在一个敏捷的数据环境中，敏捷大数据就平台可以很好地支持上述工作，一种实现架构如下图所示： 在该图中，dbus和wormhole可以方便对接多种不同数据源，实时获取数据，将数据pipeline源头实时化。另外wormhole支持流上处理，很适合接入产品画像模型和用户兴趣模型对产品与用户的特征进行实时刻画，这些特征经过存储后由moonbox根据需要进行抽取，输入推荐模型得到需要的推荐列表，最终返回给交互端。此外，如果加上davinci数据BI的支持，我们还可以轻松地实现实时业务指标监控，便于我们对推荐效果进行评估。整个过程灵活、便捷地整合了多种不同开源平台以快速搭建实时数据应用，还可以根据需要随时切换开源选型，支持快速迭代试错，结合已有的算法模型就能够迅速支持实现智能用户产品实时推荐这一场景。 三、敏捷AI如前文所述，在实时AI数据处理过程中，基于敏捷大数据的各项业务组件，结合第三方的开源构件，通过简单配置即可快速编排、敏捷地实现算法运行的底层支持架构。这使得整个系统中看起来唯一的麻烦之处在于我们还要事先开发好各种智能模型，这对于一些业务组织来说还是有一定的技术门槛；此外对于某些业务来说，快速推进和成本控制才是首要考虑的因素，那么针对性地定制化开发智能算法模型，并调整调用接口使之可以接入实时数据架构之中，就显得比较笨拙。例如很多数据分析的业务人员，也许不需要太过精准的模型性能，但最好能够保证分析系统实施的便捷性、业务逻辑实现的迅捷性。 我们已经让数据处理变得敏捷，那么如何将数据智能也变得更加敏捷呢？为了解决这一问题，我们提出了敏捷AI的实施思路，即在现有敏捷大数据产品的基础之上，基于业务场景设计开发一系列可插拔的实时智能模型算子，这些模型涵盖了业务场景内常见的智能化数据分析需求，具有较强的通用性和复用性，能够无缝接入敏捷大数据平台上的实时数据流并向平台输出分析结果，根据需要实时流入各业务端，最终实现基于实时数据流的智能分析过程。在敏捷大数据产品和敏捷AI的支持下，业务人员可以根据业务场景快速构建从实时数据处理平台到实时数据智能分析，再到实时数据展示的整个智能化数据治理流程，并可根据效果灵活调整试错，极大降低实时智能化业务分析的实施成本。 在上述敏捷AI的实施思路下，我们着手构建敏捷AI算法库，这是一套基于业务领域划分的轻量级通用数据模型集合。其中的每个模型的设计应该遵循以下原则： 轻量级，对模型复杂度进行适当的控制保证数据处理的实时性；独立性，尽量减少环境依赖或保证环境的部署独立性，避免由模型引入给系统整体带来的环境依赖变动；单一性，各模型功能尽量单一，保证各模型功能的平行性；数据普适性，除部分模型存在一些必需的特征外，各模型应保证对接入数据的普遍适应能力，通过一定的配置或映射即可以适应绝大多数的业务场景。为了实现上述要求，我们在研发模型时将不可避免地在某些方面做出一些取舍，例如模型若想通用必将会导致性能的一定程度下降，如何在这些矛盾中寻求一个合理的折中，也是在设计时需要考虑的问题。目前，我们已经针对一些领域开始研发敏捷AI模型，经过实际测试与应用后，不久的将来就将整合进现在的敏捷大数据产品栈中。此外，在未来我们还可以公布相关接口和规约，让用户也有能力将自己的模型加入到库中。 四、结语实时数据的智能化分析是未来大数据技术和人工智能技术发展的重要方向之一，如何降低这一实施过程的经济成本、时间成本、技术成本以及变更成本，是敏捷大数据和敏捷AI着重解决的关键问题。本文结合敏捷大数据产品提出了一种解决思路，希望我们的产品能够帮助各组织方便、快速、灵活地构建自己的实时大数据智能分析系统。来源：宜信技术学院 作者：井玉欣 宜信技术学院

7月7日，Scrum社区聚集在阿姆斯特丹（荷兰）参加第5届Scrum Day Europe。目标是从Scrum社区生成见解并定义Scrum框架的改进。白天我们要求大家回答5个问题：在过去的20年里，Scrum的实力已被证明是什么？未来20年Scrum应该关注什么？到目前为止，Scrum最让你感到沮丧的是什么？什么连接你到Scrum？什么是可以添加到Scrum的小改进？每位参与者都贡献并提供了意见 因此它被证明是一个真正的社区活动！今年的主题是“下一次迭代”。因此我们回顾了Scrum在过去20年中给我们带来了什么，同时也期待着Scrum的未来。当然，评估是通过回顾展进行的。根据参与者，Scrum的优势是什么？这是一个简单轻巧的框架（6x）这是一个透明度促成因素（5倍）它提供了一个可持续和持续改进的框架（4x）它吸引了普遍基本的人类需求和价值观（3x）它提供短反馈循环，连续计划（3x）它消除了客户 - 供应商的界限（2x）这很有趣也很成功（2x）它是个人成长的推动者的使用时间盒它改善 了所有层的通信这不是一颗银弹 (尤指人们寄予厚望的某种新科技)它强调多学科团队合作根据参与者的说法，Scrum在未来几年应该关注什么？支持创造价值驱动型组织，关注客户满意度（9）加强整个组织的框架（9）保持简洁（3）在下一个sprint开始之前设置进程/网关（2）提供更多支持扩展Scrum的实践（2）证明Scrum工作的指标！（2）不断创新和适应提供工作 增量解决与非Scrum组织的接口问题建立实践以发展文化拥抱精益 思想整合DevOps 原则专注于Sprint 目标提供工具来检查产品的神智逐渐与多个独立组织合作为企业高管提供Scrum将Scrum应用于其他“慢速发展”行业，例如制药行业与评论家进行更多讨论，以了解他们在Scrum中缺少的感受研究敏捷是多么“敏捷”。因为有些组织滥用敏捷。根据参与者的说法，Scrum最让你感到沮丧的是什么？Scrum看起来很简单，但实在太难了（6）Scrum 僵尸 变体（5）对Scrum Master角色的误解（4）没有 授权的产品所有者（4）管理层不愿意改变（2）角色需要高于普通人Scrum和当前组织的值不匹配纯粹专注于软件开发不知道如何处理投资组合/产品管理缺乏做到这一点工作水 - 摔倒团队沟通根据参与者，您将什么与Scrum联系起来？Scrum工作，开始整理！（5）合作成瘾（5）令人敬畏的工作氛围（3）邀请人们不断改进，一次一小步（3）我个人得到了乐趣回到我的工作生活！（2）权力下放的决策（2）我在瀑布工作了21年Scrum的常识活下去！在工作和个人使用它活下去！处理unknows使用自动化软件帮助掌握Scrum流程Scrum Process Canvas是一个用于帮助您管理Scrum项目的Scrum工具 - 从识别项目愿景到最终产品交付，使敏捷项目更加简单有效。Scrum Process canvas可帮助您：在一个设计精美的Scrum流程画布中无缝导航整个Scrum流程。快速，轻松，无缝地执行Scrum活动。让整个团队充分参与。（开放Scrum Process Canvas快速导览 - 视觉范例）为每个Scrum团队打造。借助scrum流程画布，scrum工作项，敏捷管理工具和直观界面，Scrum Process Canvas可帮助您的Scrum团队在每个Scrum项目中取得最大成功。优先产品积压。通过识别业务目标（作为用例），Epics和用户故事，逐步构建产品backlog。整个项目中的新郎产品积压很容易。用例用户故事地图积压优先排序在用户故事地图中整理用户故事将用户活动，史诗和用户故事保存在结构良好的用户故事地图中。通过拖放轻松重新排列用户故事。点击编辑用户故事。通过Web访问故事地图，随时随地工作，节省时间并完成更多工作。通过更好的计划开始冲刺。sprint backlog管理器为敏捷团队提供了一个直观的界面，用于讨论和选择要包含在sprint中的故事，创建和估计任务。更快地创建Sprint Backlog借助表格界面和选择工具，快速将用户故事包含在sprint积压中。结果是一个明确的积压故事列表，整个团队可以在整个sprint中关注这些故事。努力估计任务列表从包含的故事中轻松维护开发任务列表。通过列表视图，准确地估算比较任务所涉及的工作量。让你的团队回到整个冲刺阶段。所有scrum工具都支持您的团队在整个sprint中将承诺的用户故事转化为功能性可交付成果。每日ScrumBurndown图表障碍日志Scrumboard进度跟踪回顾与回顾记录每日Scrum会议保留每个团队成员在每日Scrum会议中报告的工作，计划工作和遇到的障碍的记录。创建任务以管理每日Scrum会议中标识的操作项。轻松检索早期日常Scrum会议的内容。无缝迭代。一次执行一个sprint的sprint活动。轻松切换到任何早期的冲刺，随时查看其历史记录。敏捷发布管理。通过用户故事地图，您可以随时轻松地将故事添加和排列到发布分区中。项目可交付成果的状态也可以以临时方式更新。发布交付项目回顾轻松发布管理用户故事地图提供了一种可视化的发布管理方法。作为发布计划的一部分，您可以通过拖放将用户故事添加到发行版中。将每个人都放在同一页面上。有效管理团队成员的角色和职责。从一开始就将scrum master，产品所有者，业务分析师，UXers和开发人员放在同一页面上。即时文档，自动存档。生成产品待办事项，sprint积压，任务列表，各种会议等的报告。从可视化的Scrum cabinet中检索文档。内置任务管理平台。一站式敏捷解决方案提供了积压和任务管理之间的无缝集成。您可以在一个地方创建任务，报告和监控进度。单一软件，多种用途。使用UML，BPMN，ERD，DFD，UX（线框，原型设计），代码工程，ORM，思维导图等来加强您的Scrum项目。敏捷敏捷方法论敏捷开发ScrumScrum敏捷

雖然這篇文章討論了Scrum中的一些常見指导原则，但重要的是要記住這些指南是靈活的，應根據您團隊的需求進行塑造。當我提到規則時，我指的是那些無法修補以適應特定背景的方面。例如，沒有產品負責人，開發團隊和Scrum Master，您就無法做Scrum。當我提到指南時，我指的是那些可能被改變以適應特定背景的方面; 但是，影響只能在實施後進行驗證。然後我們相應地檢查和調整。例如，Product Backlog細化消耗不超過團隊容量的10％。容量是小時數，故事點數還是天數？嗯，沒有規則。Scrum團隊自我組織並選擇最適合他們背景的東西; 遵循我們消耗的指導方針，不超過團隊容量的10％。在這篇文章中，我將探討一些將11個要素綁定在一起的指南，並讓Scrum團隊靈活地將這些方面融入其背景中。＃1。開發團隊規模建議開發團隊的規模為3-9名成員。根據具體情況，可能會有更多人或更少。它的影響因團隊環境而異。不到三個開發團隊成員減少了交互，導致生產率降低。較小的開發團隊可能會在Sprint期間遇到技能限制，導致開發團隊無法提供可能可釋放的增量。擁有超過九名成員需要太多的協調。大型開發團隊為實證過程提供了太多的複雜性。＃2。開發團隊的標題/角色Scrum無法識別開發團隊中的任何標題/角色。在開發團隊中，每個人都是開發團隊成員。雖然在組織內，團隊成員可能擁有頭銜/角色。根據我的經驗，我沒有遇到任何只有一個頭銜/角色的團隊。＃3。每日Scrum的三種問題格式我使用過的大多數團隊都使用了每日Scrum的三個問題的格式：昨天我做了什麼幫助開發團隊實現Sprint目標？今天我將做些什麼來幫助開發團隊實現Sprint目標？我是否看到任何妨礙我或開發團隊滿足Sprint目標的障礙？這三個問題只是以Scrum開頭的團隊的模板。只要他們專注於Sprint目標的進展，開發團隊就可以按照他們認為合適的方式構建他們的Daily Scrum。＃4。活動時間表事件的時間框表示一個月Sprint事件允許的最長時間。指南是：對於較短的Sprint，時間限制通常較短。這是否意味著，對於為期兩週的Sprint，Sprint Planning的時間限制為四小時，Sprint Review為兩小時，Sprint回顧為一個半小時？沒有。只要滿足其目的，事件可以根據需要调整短/長，但它們不能超過最大分配時間。例如，Sprint計劃為期兩週的Sprint計劃活動如果達到目的可能會在兩小時內結束，如果不滿足，則可能會持續八個小時。＃5。進展趨勢Scrum指南建議使用燒毀圖表和累積流量等實踐來監控進度。但是，團隊可以完全自由選擇他們認為合適的任何練習。根據我的經驗，我見過團隊創建視覺路線圖，基於里程碑的進度，旅程線，釋放燃燒圖表等。我們還需要記住，在復雜的環境中，只有經驗數據才能幫助我們做出正確的決策。＃6。估計在 Scrum的指南介紹了需要積壓的產品項目來進行估計。如何估算它們完全取決於Scrum團隊。故事點，理想日，T卹尺碼，狗尺碼是一些方法。Scrum團隊可以做“沒有估計”嗎？當然，只要Scrum團隊能夠起草支持經驗主義的計劃，創建透明度，並幫助團隊在Sprint結束時創建可能可釋放的“完成”增量。Scrum團隊自行組織選擇適合其背景的內容。＃7。工作分解在“選擇的工作將如何完成？”部分下。對於Sprint計劃，Scrum指南提到：開發團隊在Sprint的頭幾天計劃的工作在本次會議結束時進行分解，通常分為一天或更短時間。然而，這通常有助於發展團隊這樣做。根據我的經驗，我看到幾個團隊沒有將他們的工作項目細分到如此細緻的水平。他們了解如何將功能轉換為“完成”增量。＃8。Sprint評論這是一項重要的檢查和調整活動，Scrum團隊與主要利益相關方就Sprint期間取得的成果進行合作，以及在下一個Sprint中可以做些什麼來優化產品的價值。Scrum指南還描述了Sprint Review中的元素：與會者包括Scrum團隊和產品負責人邀請的主要利益相關者。產品負責人解釋了產品待辦事項項目已“完成”且未完成的內容。開發團隊討論Sprint期間的情況，遇到的問題以及這些問題是如何解決的。開發團隊演示了它“完成”的工作，並回答了有關增量的問題。產品負責人會討論產品Backlog。他或她根據迄今為止的進展（如果需要）預測可能的目標和交付日期。整個小組就下一步做什麼進行合作，以便Sprint Review為後續的Sprint Planning提供有價值的信息。回顧市場或產品的潛在用途如何改變下一步最有價值的事情。審查下一個預期的產品功能或功能發布的時間表，預算，潛在功能和市場。對於已經獲得資助一年的Scrum團隊來說，在每兩週一次的Sprint評審中審查其預算是否有意義？也許不吧。並非所有上面提到的元素都適用於所有Scrum團隊。它們作為指導提供，以便Scrum團隊可以選擇在Sprint審核期間討論和触及產品交付的各個方面，因為他們認為適合他們的上下文。＃9。發佈到生產每個Sprint的目的是創建一個可能可釋放的“完成”增量。這意味著增量需要處於可用狀態並滿足Scrum團隊的完成定義（DoD）。然而，將增量釋放到生產中的選擇由產品負責人決定。根據團隊的上下文及其創建的增量，Scrum團隊可能決定每個Sprint執行多個版本，每個Sprint發布一個版本，或者累積發布多個Sprint; 無論如何優化產品的價值。＃10。完成的定義“完成”的定義有助於提高透明度，並對完成工作的含義達成共識。根據Scrum指南，Scrum團隊有望擴大他們的國防部並使其更高質量的更嚴格。同樣，這不是一個規則。取決於團隊的背景; Scrum團隊可能會在每次回顧中重新審視它的國防部，或者可能繼續使用相同的國防部，除非它學會了新的東西以提高產品的質量。結論這些只是Scrum指南中的一些指導原則。我想提出這種區別，因為我經常發現Scrum團隊與Scrum規則和指南混淆。幾乎沒有什麼是常見的 - 將Sprint計劃的時間安排為兩個星期的Sprint或開發團隊花費太多時間和精力將PBI分解為“任務” - 其他人並不常見。我相信這篇文章將幫助團隊確定Scrum的一些方面，他們可以修改這些方面以適應他們的背景。Scrum参考What are the Scrum Events?What are Scrum Ceremonies?What is Product Backlog Grooming?What are the 3 Important Questions in Daily Scrum?Scrum Sprint Cycle in 8 StepsWhat is a Sprint in Scrum?Heartbeat of Scrum - The Daily StandupDaily Scrum Meeting - A Quick GuideWhy Fixed Length Sprints in Scrum?What is Scrum Release Planning?What is Sprint Planning?What is Sprint Review? ...

什麼是僕人式領導？雖然僕人式領導的觀念是一個至少可以追溯到兩千年的永恆概念，但現代僕人式領導運動是由Robert K. Greenleaf於1970年發表的，當時他發表了他的權威文章“僕人作為領袖 ”，他創造了這些文字。 “僕人式領袖”和“僕人式領導”。僕人式領導是一種非常社會化的領導風格。雖然傳統的領導力是關於“金字塔頂端”的人積累，囤積和鍛煉（通常會墮落為濫用）權力，但僕人式領導是與團隊分享權力，識別，優先考慮和滿足他人和幫助人們盡可能地發展和表現。必須強調的是，在說“仆人领导 - 是仆人第一”時，Greenleaf並不意味著僕人領袖應該順從，而是要真正想要服務，幫助他人。Greenleaf在AT＆T擔任管理髮展總監近四十年，當他於1964年退休時，他被認為是世界領先的企業領導專家之一。傳統領導與僕人式領導為什麼僕人式領導是一種強大的管理風格僕人式領導是一個在過去十年中吸引了一些研究人員注意力的概念，他們的研究結果一致表明了這種領導風格的力量。綠葉的“僕人式領導的最佳測試”：多層次分析是2011年的研究由內布拉斯加-林肯大學的羅伯特·W·海登，美國即說：“這項研究實證檢驗羅伯特·格林里夫（1970）的僕人領導的開創性的銜接。他理論化的四個個人成果（健康，智慧，自由自主和服務導向）都是根據僕人式領導的既定維度進行測試的。所有相關性都是顯著且積極的。“領導者對領導者的信任和對組織的承諾的影響2013年由地中海社會科學期刊發表的南非瓦爾理工大學的理查德·奇諾莫納的研究得出結論：“結果表明，僕人領導積極地影響員工對領導者的信任以及員工對組織的重大承諾。“僕人領導和員工對主管的承諾，由美國德克薩斯州康考迪亞大學的Shane Sokoll於2014年在國際領導力研究期刊上發表的一項研究表明，“發現僕人領導對員工對主管的承諾產生了重大影響。" 以下是簡單的指導方針。它能幫助你作為Scrum Master成為一名僕人領袖。1.承諾將自己放在最後僕人式領導者和其他類型的領導者之間的區別，僕人式領導者首先是僕人而不是領導者。成為僕人領袖意味著您致力於將您的個人利益放在最後。換句話說，僕人式領導是對謙卑的承諾。成為僕人領袖不是關於你的成功，而是關於你所服務的人的成功。你不是關注的中心，你所服務的人應該成為關注的焦點。我們目前生活在一個人們喜歡吹噓他們在社交媒體上取得成功的世界，僕人式領導不是吹噓你的個人成功。如果您吹噓自己的成功或作為Scrum Master的能力，或者您使用Scrum成功交付的項目，我很遺憾地說這不是僕人式領導。這些成功都不屬於你，它屬於你所服務的那些人，你沒有權利宣稱它是你的並吹噓它。我經常對其他人的公司Scrum Master的職業道路有疑問，看來他們擔心Scrum Master會在他們的餘生中保持同樣的位置。Scrum Master的成長不應該通過她在組織結構圖中的排名來看待，而應該通過她的服務的影響來看待。雖然公司中有許多領導者在組織階梯上奮戰，但我很遺憾地說，但僕人式領導並不是要在組織結構圖中奮鬥。記住這一點，你將以激光為重點服務他人，遠離公司政治，保持中立和不偏不倚。把自己放在最後，讓別人成功的方式需要很大的謙虛。2.關注他人的偉大我見過很多人問過我，“ 如果我的團隊沒有按預期交付我不應該懲罰他們嗎？“很多人還問我，” 如果有一個團隊成員沒有像其他團隊成員一樣快或多快地交付，我不應該懲罰那個人嗎？“許多公司和領導人多年來一直堅持”獎懲“模式。這種領導風格不再適用於21世紀，因為它不具有人性化。用棍棒和胡蘿蔔來懲罰表現不佳的工人的時代已經結束。我們已經通過它，我們應該在上個世紀留下它。懲罰表現不佳的傳統模式對我個人來說從未有任何意義。這只是感覺不對。僕人領袖應該幫助一個表現不佳的人，並將他們提升到更大的水平。僕人領袖總是在服務於讓別人變得偉大，而不是懲罰，指責或判斷他們。一個Scrum Master會問一個表現不佳的團隊成員，“ 我能為你做些什麼，這樣你才能成為偉大的並讓你擺脫這種局面？“你作為僕人領袖的目標不是你的偉大，而是其他人的偉大。您可能需要加倍努力或犧牲您的個人資源才能使它們變得更好。“ 但是，但是，如果我們試圖指導那個人並且他仍然沒有改變怎麼辦？“我個人認為人類是成長的動力。沒有人在早上醒來只是為了最壞。我們應該通過他們的鏡頭而不是我們的鏡頭來看待故事，而不是根據我們所看到的結論得出結論。我們應該先看看自己。僕人式領導者是一種領導者，他積極主動地解決問題的核心，這樣她就可以讓其他人變得很棒，而不是根據她所看到的結果做出結論。通過關注他人的偉大，我們對別人的評價就會減少，我們會讓別人感到安全。僕人式領導者專注於創造一個人們可以茁壯成長並成為自身最佳版本的環境，而不是人們變得具有防禦性和自尊心低的環境。3.尊重他人需要完全人性化我們一直生活在工作場所只是工作場所的信念之下，在那個系統之外我們可以完全是人。許多公司都提倡工作與生活平衡的概念，因為他們認為工作場所是關於工作的，而在該系統之外的是生活。你沒有在工作場所生活。在這種信念中，人們需要關閉他們的人性，並在每次進入工作場所時將其留在家中。我個人認為，完全是人類是一項基本需求，不應該被關閉。無論是在工作場所還是在工作場所之外，人們都需要成為人。僕人領導者不區分工作場所內外的人。僕人領導關心員工在工作場所的福祉。僕人領袖個人對她的人民作為人類感興趣。她是一個人。憐憫可能不是我們在公司環境中聽到的常見詞彙，但作為僕人式領導者，我們需要富有同情心和好奇才能對我們所服務的人產生個人興趣。要有同情心和好奇，你需要是真誠的，你不能偽造它。我還記得我的老闆告訴我的一句話，“ 不要帶著問題來找我，帶著解決方案來找我。“每當我聽到有人這麼說時，我總覺得不舒服。這聽起來不對，儘管我認識的很多人都認為這是管理層的標准信念。這種信念讓我感到氣餒，因為我覺得我需要獲得老闆的批准。如果我不能帶著問題來找我的老闆，我還能信任誰來幫助解決我的問題？在這種信念中，似乎我需要完美，我不能錯，我不能犯錯誤。僕人式領導者創造了一個環境，人們可以在工作中感到安全，完全是人，就像人們在他們的朋友和家人中感到安全，完全是人。她的人民應該說“ 我不知道 ”或“ 我失敗了，我需要幫助 ”，而不必擔心工作中的判斷或懲罰。當一個僕人領導有問題而不是告訴他們稍後帶著解決方案回來時，會邀請他們。我們隨時為他們服務。她的人民可以創造空間和時間來反思他們的錯誤。人們可以做一個能為公司帶來價值的實驗，而不必擔心失敗。勇敢說出真相僕人領袖有勇氣說實話，即使這會讓別人感到不舒服甚至抵抗。她沒有給她發送的任何信息加糖，因為她希望她的員工能夠改進並獲得新的體驗。她走的是講話，她的每一條信息都有完整性。真相可能不是過去人們習慣聽到的，因為真理沒有為政治創造空間。僕人領袖不是安全的，也不擔心說實話，因為她知道她的目標是他人的偉大。無論她做這件事有多困難，僕人領袖都會說實話。僕人式領導者不偏不倚，沒有任何收藏，否則會降低她為整個組織帶來的服務質量。告訴真相對於許多人來說永遠不會感到舒服，因為我們擔心真相會傷害他人，否則會使我們在工作場所的未來付出代價。有時候我們只告訴老闆他想听到什麼，因為我們害怕受到懲罰，或者我們不會得到他的認可。僕人領袖是不同的。僕人領袖是真誠的，她沒有隱藏的動機，也沒有個人對她的信息感興趣。說出的真相將把她所服務的人民和組織帶到一個新的高度，而不是傷害他們。事實將促使人們以不同的方式思考而不是保持現狀或住在舒適區。僕人領袖創造了一個人們可以安全地說出真相並說出真相的環境。5.開放性關於你自己的漏洞我們從上面的觀點中看到，僕人式領導者如何專注於為更大的利益服務他人。僕人式領導者也是一位對自己的弱點持開放態度的領導者。一個僕人領袖謙虛地說她沒有所有問題的所有答案，她給出的任何建議都不能作為絕對真理。僕人式領導者謙虛地不吹噓她自己，同時對她的不完美持開放態度。許多人認為，當領導者對她的脆弱性持開放態度時，這表明她很脆弱。有些人甚至可能會說她沒用。畢竟，在企業環境中，我們以我們的能力來衡量，因此在公開場合公開我們自己的漏洞會被其他人視為我們作為領導者的無能力。對我們自己的漏洞保持開放是對他人的一種服務形式，以便其他人也可以安全地對他們開放。這是我們從服務對像那裡獲得信任的唯一途徑。當我們獲得他們的信任並且他們對自己的脆弱性持開放態度時，我們可以為他人服務。當領導者有勇氣對自己的脆弱性持開放態度時，人們會感到舒適並且不會害怕判斷。人們會信任領導者，並且當領導者首先對她的人民表現出對她的脆弱性的開放態度時，他們會對自己的漏洞保持開放態度。成為僕人領袖需要謙虛。當僕人式領導不是我們社會中許多公司或領導者所採用的標準時，成為僕人領袖並不容易。對我個人而言，這對我個人來說從未如此簡 我個人仍然在努力成為一名僕人領袖。作為僕人領袖並不容易。但我相信，作為一名僕人領導者，與其他領導者相比，使我們與眾不同，是什麼能夠為這個世界帶來變化。我使用上面的指導作為我自己的動力，繼續提高我的僕人領導能力。期待在未來多年看到你作為僕人領袖的美麗工作的結果。綜上所述Scrum Master 采用僕人式領導需要將团队的需求放在首位。僕人式領導者主要關注团队的成長和福祉：首先為他人服務，對於希望在團隊成員中發揮最大作用的現代管理者來說，僕人式領導是一個強大的工具。

在转向敏捷之后，很多团队开始使用“用户故事”一词。用户故事是一种简单而优雅的技术，可以收集客户需求。然而，它需要一定的理解和实践才能用User Stories构建出色的软件。让我们仔细看看用户故事是什么以及如何使用这种技术取得成功。什么是用户故事？用户素材是对功能的简短描述，它为用户或客户带来价值，团队可以在迭代中提供这些功能。用户故事应该回答3个问题：我们为谁建造它？ - 作为<用户类型>我们在建什么？ - 我想<feature>我们为什么要建造它？ - 这样<值或利益>在此之后，用户故事的典型格式是：作为<用户类型>，我想要<feature>，以便<value或benefit>。用户故事示例：作为注册用户，我希望能够将我的图片下载到我的个人资料中，以便其他用户可以看到我的样子。有没有创建用户故事的程序？没有正式的过程来创建用户素材。尽管如此，还是应该遵循一条准则来创建一个好的用户故事。它被称为3 C，由极限编程的创始人之一Ron Jeffries提出。该卡是用户故事的书面说明。它没有捕获有关应该构建的内容的所有详细信息。相反，它是一个提醒，是对必须进行的后续通信的承诺。对话用于讨论用户故事的细节。它可能会被一些文档补充。确认由用户验收测试表示，确保用户故事满足用户/客户的验收标准。如何撰写高质量的用户故事确保用户故事具有适当质量的良好做法是遵守Bill Wake的INVEST首字母缩略词的标准。INVEST还有助于确定用户故事是否已被充分理解并为开发团队开始工作做好准备。独立 - 用户故事不应该依赖于另一个用户故事，因此用户故事可以按任何顺序开发。可协商 - 用户故事的详细信息通过产品负责人和开发团队之间的口头对话进行协商。有价值 - 用户故事应该为用户/客户带来所需的价值。估计 - 开发团队应该很好地理解用户故事来估计它。小 - 用户故事应足够小，以适应迭代。可测试 - 应为用户故事编写正确的验收标准，以便进行验证。什么不是用户故事？让我们对自己说实话：用户故事不能通过其定义成为“技术用户故事”，因为在这种情况下它不会给用户/客户带来直接价值。不过，许多团队喜欢在需要执行代码重构等技术任务时创建用户故事。我建议将其他工作项用于此类任务，并与您的产品负责人就此类工作达成一致，以便了解为何需要这样做。这同样涉及非功能性需求任务，界面设计任务，复杂的用户交互任务或错误。您可以自由地为这些任务创建其他工作项。例如，Constraint Story可用于表示非功能性需求。用户故事是捕获产品功能的绝佳技术，但我们没有义务将其用于所有目的。谁是用户？在编写用户故事之前，应该清楚地了解创建用户素材的用户是谁。有时它被新用户故事技术的团队所忽视，他们最终创建了具有不必要功能的软件。因此，做一个适当的用户研究，让你的所有用户类型或用户角色或角色写下来并描述。可以帮助您解决此问题的两种技术是用户角色建模和角色。谁负责撰写用户故事？通常，客户代表（例如产品负责人）负责用户故事。尽管如此，用户故事并不是从顶级到团队的规范，而是产品负责人和团队之间的协作技术。这就是为什么如果用户故事是协作编写的话会更好。一个很好的方法是做一个故事写作研讨会。细节在哪里？由于用户故事不是规范，因此详细信息以不同方式传达：3 C指南中的第二个“C”是Conversation。对话是敏捷最重要的方面之一。因此，大多数细节都是通过客户代表和开发团队之间的口头沟通来传达的。第三个“C”是确认。用户验收测试确认用户故事满足用户/客户的验收标准，并且它们用作正式的文档详细信息。BDD（行为驱动开发）是一种编写验收测试的好方法。如果需要，某些用户故事可能包含其他书面详细信息。你怎么知道用户故事何时完成？使用“完成定义”技术。简而言之，Done的定义是团队成员之间对工作完成意义的共同理解。完成的定义通常以活动清单的形式创建，其表明商定的价值（用户验收测试以满足用户验收标准）和质量（以满足质量标准）。团队有时会忽略最后一个，在迭代结束时，什么可以使用户故事不可能发送给客户。完成技术的定义有助于避免这种情况。完成定义的示例：完成时间：单元测试通过代码经过同行评审用户验收测试通过集成测试通过回归测试通过用户指南已更新如何开始定义产品范围？在项目开始时，我们需要定义产品的粗略范围，以便对其有全局视野。这可以通过Epics完成。史诗是一大块工作，有一个共同的目标。Epic可以被视为占位符，用于稍后创建的更详细的用户故事。Epic通常需要多次迭代才能完成。什么是组织用户故事的最佳方式？使用由Jeff Patton发明的故事映射技术 (User story Mapping)。故事映射代表了一种自上而下的需求组织方法，也是确定优先级和规划的好方法。对BABOK®Guidev2的敏捷扩展指出：“故事映射提供了解决方案支持的活动序列的视觉和物理视图。它使用二维网格结构来显示产品在水平维度上的关键方面的顺序和分组，详细信息和优先级关于垂直维度的故事。故事映射是一种分解技术，它允许从端到端视图开始逐步理解解决方案，并深入到详细的用户故事。故事映射示例 (Visual Paradigm User Story Mapping)：https://www.youtube.com/watch…

3C’s = 卡 (Card)，会话 Conversation)，确认 (Confirmation)”;这个模板（来自Ron Jeffries）捕获了用户故事的组成部分：第一个C (Card) 是原始形式的用户故事，即卡片。用户故事手动写在索引“卡”上，以保持简洁。标准格式有3个基本组件：作为[用户类型]，我想/需要[目标]，以便我可以完成[理由/商业价值]。该卡只是一个占位符。第二个C (Conversion) 是对话。对话有必要获得有关卡的更多详细信息。该对话促进了敏捷团队之间的增量和持续协作，以便围绕问题和潜在解决方案建立共同理解。第三个C (Confirmation) 是确认。确认是接受标准，它捕获基本要求并将其转换为测试标准，以便我们知道何时成功交付了用户故事。1.卡 (Card)用户故事应该能够放在3“x5”便条卡上，有效地捕获最重要的信息。虽然这个“C”有时指的是实际的记录卡，但我们的意思是它指的是用户故事的最佳尺寸。正如杰弗里斯所写，卡片不应包含有关要求的所有信息，而是足以用于规划识别要求并提醒项目团队的故事。每个用户故事都应遵循以下标准化格式：“作为[特定用户]，我想[执行此操作]，以便[我可以实现此目标。]” 专注于收集每种用户类型的用户故事，以创建一组最具代表性的用户故事。用户故事应尽可能直接由用户编写。但是，根据项目类型和组织细节，用户故事也可以由项目团队成员和/或产品所有者编写。可以使用常见的启发技术（如访谈，问卷调查，观察和用户故事撰写研讨会）收集完整的用户故事集，以确保用户故事准确反映用户需求。2.对话 (Conversation)在用户故事即将被放入sprint之前，产品所有者应该与客户讨论他们的用户故事（或与其业务领域相关的用户故事）以进行详细说明和验证。与用户的协商对话是必要的，因为用户故事可能难以解释，可能需要一些背景知识来实现，或者自编写故事以来需求可能已经改变。对话代表项目团队与产品所有者或其他利益相关者和商业中小企业之间的讨论。在这些对话中，产品所有者告知利益相关者正在发生的事情，利益相关者或团队成员交换想法，意见和感受。对话应在整个项目生命周期中进行。虽然我们主要讨论口头讨论，但对话还可以包括通过电子邮件，内部聊天程序或通过需求管理和业务分析工具（如Enfocus Requirements Suite™）进行的电子通信。3.确认 (Confirmation)用户故事的最后一个组成部分是用于确认用户故事是否已正确实施并成功交付的验收标准。必须在开发开始之前定义验收标准，以确定每个用户故事何时完成并按用户的意图工作。验收标准可用于演示用户故事的界限，并且通常在产品所有者，项目团队和用户之间进行对话时进行考虑。建议用户是编写验收标准的用户，因为每个用户故事都是从用户的角度编写的 - 因此确保用户故事完成和满意的测试也应由用户编写。最好是这样定义验收标准的细节正是时候用户故事被放置在一个冲刺前。提供太多细节是浪费和耗时的，因为如果用户故事发生变化，则还需要更改细节。但是，提供太少的细节通常会导致重大的返工，并迫使开发人员做出错误的假设。它们应该被写成勉强够用; 也就是说，用户故事应该只包含启用开发所需的绝对最小信息量，并允许测试以合理的效率进行。这样做的理由是最大限度地减少在不增加最终产品价值的任何事情上花费的时间。敏捷软件开发文章什么是敏捷软件开发？什么是用户故事？什么是用户故事映射？用户故事与敏捷软件开发的使用案例

短跑运行在短在一段有限的时间距离。它被用于许多包含跑步的运动中，通常用作快速到达目标或目标的方式，或避免或抓住对手。为什么短冲刺？你应该有一个足够短的迭代，以保持团队的注意力，但足够长，以提供有意义的工作增量。在Scrum的指南限制了冲刺长度为一个月。失败快 - 太小导致不会失败短Sprint的优势来自于尝试某些事情（快速失败），获得快速反馈，然后快速检查和调整的策略。在存在高度不确定性的情况下，开始研究产品通常会更便宜，了解我们是否做出了一个好的决定，如果没有，在花更多的钱之前快速杀死它。快速失败：为什么短跑长度必须短？类似于Kaizen（改善）的想法，它是日语中的“改进”。在商业领域，改善是指不断改进所有职能并让所有员工从首席执行官到装配线工人的活动。分析这些变化的结果并重新开始微调。以这种方式，可以提高正在执行的任务的生产率或质量。一点一点地做出微小改变远比一次性解决所有问题更有效。我们的想法是让变更变得如此简单，以至于在实施过程中很难失败。首先，我们养成了改变的习惯。然后我们添加新的更改或稍微改变更改的里程碑，以便我们可以逐步改进。一个接一个地应用调整很重要。这个想法是为了避免选择应用和何时应用的复杂性。这样我们就能够分析每个小改进的结果。如果我们同时申请几个，我们将不知道哪个有效，哪个没有。或者一个人的效果是否已经抵消了另一个人。Scrum - 持续改进Scrum框架基于经验主义，它依赖于透明度，检查和适应性。在Scrum事件和工件协助定期检查和调整，导致持续改进。在sprint计划期间，scrum团队会检查产品积压并调整sprint目标，预测和sprint积压。在每日Scrum期间，开发团队会检查sprint目标的进度并调整sprint backlog。在冲刺审查期间，Scrum团队和利益相关者检查增量，冲刺和产品积压并调整产品积压。Scrum - 持续改进最后，sprint回顾展是scrum团队改进的正式活动，scrum团队通过实施可行的，可持续的改进来检查围绕人员，关系，流程和工具的冲刺。

(Source: Scrum.org)Scrum Developer是一个T形人一个T-型的人有两种特性的，因此使用字母“T”来形容他们。字母“T”的垂直笔划描述了他们所具有的特定领域的深层技能，而水平笔划描述了跨多个学科的协作处置。它由两件事组成，即对其他人的学科的同理心和热情，以至于他们可能真正开始练习它们。只熟悉某个特定领域的人称为I形人。下图解释了I形人和T形人之间的差异。T-形Scrum开发人员从上图中可以看出，Scrum开发团队的测试工程师需要具备的技能不仅仅是“点击测试”，他们应该有_一些_编程，分析，设计，开发，技能等。分析师应该有技能超越“分析”，他们有望进行_一些_编程，测试工程，设计，营销，技能等。设计师有望拥有“设计”技能，预计会有一些编程，测试和分析技能。嗯，你明白了。因此，我们认为分析师不会比程序员和程序员更高的位置，而不是测试工程师。在像软件开发这样的创意产业中，在开发团队中拥有T形人员非常重要。James Shanteau做了一项研究，发现专家（I-Shaped people）的判断既不符合该领域专家的判断，也不符合内部一致性。在开发团队中拥有许多T形人员可提供创意行业急需的广泛见解。IDEO - 着名设计公司的首席执行官蒂姆·布朗表示，拥有一个T形人很重要，因为他们能够建立在其他人的想法基础之上，并不会立即抛弃你自己的竞争理念。T形人从另一个角度想象这个问题 - 站在别人的鞋子里。T-形人也非常热衷于其他人的学科，以至于他们可能真正开始练习它们。T-形人不是一个真正的新概念，在文艺复兴时代，有很多T形人，仅举几例着名人物：莱昂纳多达芬奇 - 画家，雕塑家，建筑师，音乐家，数学家，工程师，发明家，解剖学家，地质学家，制图师，植物学家和作家。Galileo Galilei - 物理学家，数学家，工程师，天文学家和哲学家。Nicolaus Copernicus - 数学家，天文学家，医师，经典学者，翻译，州长，外交官和经济学家。T-形人不是通才，他们在一个领域拥有深厚的技能，但也有其他技能可以帮助他们与其他开发团队成员合作。例如，伽利略和哥白尼是众所周知的天文学家。哇，你可能认为开发人员拥有的技能太多，这些开发人员是否存在？是的，他们存在，但不幸的是，他们中的大多数人已经很高兴与一家好公司合作。而且由于软件正在吞噬世界，软件的作用越来越重要，我们需要提高游戏的门槛。

第一个极限编程项目于1996年3月6日启动。极限编程是几种流行的敏捷过程之一。事实证明，它已在全球各种规模和行业的许多公司中取得了巨大成功。极限编程是成功的，因为它强调客户满意度。而不是在将来某个日期提供您可能想要的所有内容，而不是在您需要时提供您需要的软件。极限编程使您的开发人员能够自信地响应不断变化的客户需求，甚至在生命周期的后期。极限编程强调团队合作。经理，客户和开发人员都是协作团队中的平等合作伙伴。极限编程实现了一个简单而有效的环境，使团队能够高效地工作。团队围绕问题进行自我组织，以尽可能高效地解决问题。 极限编程以五种基本方式改进软件项目; 沟通，简单，反馈，尊重和勇气。极端程序员经常与他们的客户和程序员沟通。他们保持设计简洁。他们通过从第一天开始测试他们的软件获得反馈。他们尽早将系统交付给客户，并按照建议实施变更。每一个小小的成功都会加深对每个团队成员独特贡献的尊重。有了这个基础，Extreme程序员就能够勇敢地响应不断变化的需求和技术。极限编程最令人惊讶的方面是它的简单规则。极限编程很像一个曲线锯拼图。有很多小件。单独的碎片敏捷流程图毫无意义，但当结合在一起时，可以看到完整的画面。规则可能看起来很尴尬，一开始可能甚至天真，但都是基于合理的价值观 和原则。我们的规则设定了团队成员之间的期望，但不是最终目标。您将意识到这些规则定义了一个促进团队协作和授权的环境，这是您的目标。一旦取得成效，即使规则发生变化以满足公司的特定需求，团队合作仍将继续。这个 流程图 展示了极限编程规则如何协同工作。客户喜欢成为软件过程中的合作伙伴，开发人员无论经验水平如何都积极贡献，管理人员专注于沟通和关系。非生产性活动已被削减，以减少所涉及的每个人的成本和挫败感。从这里开始，按照小按钮的轨迹，参加极限编程

(Source: XP - Iteration Planning)在每次迭代开始时调用迭代计划会议，以生成该迭代的编程任务计划。每次迭代为1到3周。 客户从发布计划中按照对客户最有价值的顺序选择用户故事进行此次迭代。还选择了要修复的失败验收测试。客户选择的用户故事的估计总计达到上次迭代的项目速度。用户故事和失败的测试被分解为支持它们的编程任务。任务记录在索引卡上，如用户故事。虽然用户故事是客户的语言，但任务是使用开发人员的语言。可以删除重复的任务。这些任务卡将是迭代的详细计划。开发人员注册执行任务，然后估计他们自己的任务需要多长时间才能完成。对于接受任务的开发人员而言，重要的是估计完成任务所需的时间。人们不可互换，而且要完成任务的人必须估计需要多长时间。每项任务应估计为1,2或3（如果需要，添加1/2）持续时间的理想编程天数。如果没有干扰，理想的编程日期是完成任务需要多长时间。短于1天的任务可以组合在一起。超过3天的任务应该进一步细分。现在再次使用项目速度来确定迭代是否超过预定。在任务的理想编程天中总计时间估计值，这不得超过上一次迭代的项目速度。如果迭代次数太多，那么客户必须选择要推迟的用户故事，直到稍后的迭代（也叫雪耕 - Snow Plowing）。如果迭代太少，则可以接受另一个故事。任务天的速度（迭代计划）会覆盖故事周的速度（发布计划）因为它更准确。看到用户故事被雪覆盖通常令人震惊。不要惊慌。记住单元测试和重构的重要性。任何一个领域的债务都会让你失望。在安排之前避免添加任何功能。只需添加您今天所需的内容。添加额外的东西会减慢你的速度。不要试图改变你的任务和故事估计。规划过程依赖于一致估计的冷现实，将它们勉强降低会产生更多问题。密切关注您的项目速度和积雪。您可能需要重新估算所有故事并每三到五次迭代重新协商发布计划，这是正常的。只要您始终首先实施最有价值的故事，您将始终尽可能为您的客户和管理层做好准备。迭代开发风格可以为您的开发过程增加灵活性。通过不比当前迭代更远地规划特定的编程任务来尝试及时规划。

编写用户故事后，您可以使用发布计划会议来创建发布计划。发布计划指定 将为每个系统版本实现哪些用户故事以及这些版本的日期。这给出了一组用户故事供客户在迭代计划会议期间进行选择，以便在下一次迭代期间实施。然后将这些选定的故事翻译成单独的编程任务，以在迭代期间实现以完成故事。在迭代期间故事也被转化为验收测试。这些验收测试在此迭代期间运行，并且随后的迭代将验证故事何时正确完成并继续正常工作。当项目速度 在几次迭代中发生显着变化时，或者在任何情况下，在几次迭代之后继续进行，并安排与客户的发布计划会议并创建新的发布计划。发布计划以前称为承诺计划。更改名称以更准确地描述其目的，并与迭代计划更加一致。

(Source: User Stories)用户故事与用例具有相同的用途，但不尽相同。它们用于为发布计划会议创建时间估计。它们也用于代替大型需求文档。用户故事由客户编写，作为系统需要为他们执行的操作。它们与使用场景类似，不同之处在于它们不限于描述用户界面。它们的格式为客户在客户术语中编写的大约三个句子，没有技术语法。用户故事也推动了验收测试的创建。 必须创建一个或多个自动验收测试以验证用户故事是否已正确实施。用户故事最大的误解之一是它们与传统的需求规范有何不同。最大的区别在于细节层次。用户故事应该只提供足够的细节，以便对故事实施的时间进行合理的低风险估计。在实施故事的时候，开发人员将转到客户并获得面对面的要求的详细描述。 极限编程流程图开发人员估计故事可能需要多长时间才能实现。每个故事将在“理想的开发时间”中得到1,2或3周的估计。这个理想的开发时间是在代码中实现故事所需的时间，如果没有干扰，没有其他任务，并且您确切知道该做什么。超过3周意味着您需要进一步打破故事。不到一周的时间，你的水平太过细致，结合了一些故事。大约80个用户故事加上或减去20是在发布计划期间创建发布计划的完美数字。故事和需求文档之间的另一个区别是关注用户需求。您应该尝试避免特定技术，数据库布局和算法的详细信息。您应该尝试将故事集中在用户需求和优势上，而不是指定GUI布局。

“水桶估计系统”是一种用中小型人群估计大量物品的方法，并且可以快速完成。水桶估计系统具有以下特性，使其特别适用于敏捷环境：它 很快！可以在一小时内估算几百件物品。这是 合作的。一组中的每个人大致平等地参与。它提供 相对结果而不是绝对估计（点数与小时数）。结果无法追溯到个人，因此它鼓励 小组负责。与 团队合作估算工作量或与 利益相关者合作估算价值。水桶估计系统流程水桶估计系统的估算工作如下：按照下图设置物理环境。确保所有要估算的项目都写在卡片上。从集合中随机选择一个项目。把它读给小组。将它放在“8”桶中。这个项目是我们的第一个参考项目。从集合中随机选择另一个项目。把它读给小组。该小组讨论了其在规模上的相对位置。一旦 共识已经达成，把该项目在适当的桶中。随机选择第三个项目，经过讨论并达成共识后，将其放入适当的桶中。如果随机物品已经明显地将刻度朝向一端或另一端倾斜，则重新缩放物品（例如，如果第一物品实际上非常小并且应该在“1”桶中）。分而治之。将所有剩余项目均等地分配给所有参与者。每个参与者将项目放在规模上而不与其他参与者讨论。如果一个人有一个他们真正不理解的项目，那么该项目可以提供给其他人。完整性检查！每个人都悄悄地审查规模上的项目。如果参与者发现他们认为不合适的项目，欢迎他们提请小组注意。然后该小组讨论它，直到达成共识并将其置于其中一个桶中。在卡片上写下桶号，以便记录估算值。需要考虑的一些要点：多个项目可以在同一个存储桶中。项目不能放在“桶”之间以表示更精确的估计。如果项目的分布倾斜到比例的任何一端，那么在完整性检查步骤期间，该组还应该讨论项目是否可以并且应该在比例尺上更均匀地展开。如果是这样，那么该小组就会集体进行。辅导员应注意确保在“健全检查”步骤之前没有人移动已经放置的物品。参与者之间的项目划分不需要完全相同 - 不要担心“处理”项目。相反，只是粗略地划分它们。如果“分而治之”阶段有一两个人通过他们的项目工作非常缓慢，建议他们与已经完成的人分享剩余的项目是可以接受的。个人完全弃权是不可接受的。如果有人想要投弃权票，他们应该被告知这意味着他们将不会在估计中有任何未来的发言权。在“分而治之”阶段，保持绝对沉默至关重要。特别是，不应对项目进行双边讨论。这是为了保护尽可能多地放置物品的个人的匿名性。水桶估计系统是一种很好的替代估算方法，可以尝试代替规划扑克。它比规划扑克快得多，但仍能获得合理的结果。

根据INVEST原则，对用户故事的要求是它必须“足够小”或具有合适的大小。用户故事应该足够小，可以在冲刺中完成6-10个。当然这也取决于开发团队的速度。为了原则上实现这一目标，必须相应地分割大型故事。在下文中，我想向您介绍Mike Cohn的简单快速的SPIDR方法。他总结了五种技术，几乎每个大型用户故事都可以分为几种。钉鞋Spike是敏捷软件开发中使用的术语。尖峰是功能的小型原型实现，通常用于新技术的评估和可行性。该方法涉及调查和建立知识。如果其他SPIDR方法效果不佳，则应该使用它。借助这些新获得的知识，可以更好地理解一些故事，并可能更容易地分裂。然而，该方法相对抽象，因此比其余方法更难应用。路径如果用户故事中有多个可能的备用路径，则一个选项是从这些路径中的某些路径创建单独的用户故事。为每条路径写一个故事并不是绝对必要的，只要它有意义。例如，让我们看一个用户想要在线商店购买的用户故事。现在有两种可能的途径：使用信用卡付款或使用Paypal付款。理论上，信用卡付款可以进一步细分，但你需要权衡每种类型的信用卡是否有自己的故事。然而，支付购买的首要任务分为上述两种备选方案。因此，新创建的故事更小，更容易估计。接口在该上下文中的接口可以是例如不同的设备或设备类型，例如由iOS或Android供电的智能电话。用户故事也可以根据这种多样性进行划分。让我们坚持使用不同操作系统的示例：例如，在项目中，可能存在仅与Android设备的使用相关的用户故事，或者专注于Web浏览器的其他用户故事。为了避免使故事过于庞大和全面，您应该问自己要开发哪些设备或接口。也许第一个开发结果应该只引用iOS设备，因为可能更大的目标组。数据当初始故事仅涉及相关数据的子范围时，可以使用另一种用于分割用户故事的技术。以一个旨在吸引游客到特定城市的网站为例。例如，如果它是以博物馆而闻名的城市，那么第一个故事可能包括该地区不同博物馆的信息。随后的故事可能包括穿越城市的各种旅游，以及另一项户外活动。规则业务规则或技术标准可能是另一个分裂因素。以在线购买电影票为例。通常存在约束，例如基于相应电影的业务要求，例如每个电子邮件地址最多五个票的在线购买限制。有了这个故事，可以想象开发团队省略了这个限制，允许每个访客购买尽可能多的门票。然后可以在第二次迭代步骤中添加限制。像这样的增量交付意味着初始故事不会立即完全实现，而是以几个较小的步骤提供。有时忽略技术规范或业务规则是有意义的，如果通过这样做，您可以更快地实现满足用户或客户的可呈现结果。可以在以后检索省略的故事。小用户故事 - 更容易实现用户故事分裂并不总是那么容易：许多初学者倾向于将他们的故事过于全面而且过于庞大。但是，当涉及到开发团队的改进，并最终实现故事时，很快就会发现必须制作更小的故事。在我之前关于写（好）用户故事的博文中，我坚持认为故事应该是“可估计的”和“小的”。如果您知道如何分割大型故事，则更有可能发生这种情况。正如编写用户故事一样，练习也是完美的。敏捷软件开发什么是敏捷软件开发？什么是用户故事？什么是用户故事映射？用户故事与敏捷软件开发的使用案例

在这篇文章中，我们将介绍如何编写好的用户故事以及应该包含哪些内容。用户故事代表一小部分功能，具有团队可以在冲刺中提供的业务价值。用户故事和传统需求文档之间的区别在于详细程度。需求文档往往包含大量文本并且非常详细，而用户故事主要基于会话。我们可以将用户故事的结构分解为：需要的简要说明在积压修饰和sprint计划期间发生的对话以巩固细节确认故事圆满完成的验收测试在编写用户故事时要记住的一个重点是，它们是从最终使用该产品的用户的角度编写的，因此在编写用户故事时我们必须清楚地识别用户是谁。如何写好用户故事根据经验，一个好的用户故事应该遵循INVEST的缩写：I ndependent - 用户故事不应该相互依赖，因此它们可以按任何顺序开发。N egotiable - 避免太多细节; 保持灵活性，以便团队可以调整实施的故事数量。V aluable - 故事应该为其用户提供一些价值。E stimable - 团队必须能够估计故事。S商城 - 用户故事应足够小，以适应冲刺; 大型故事很难估计和计划。T estable - 确保正在开发的内容可以得到充分验证和测试。用于编写用户故事的格式是什么？用户故事通常具有以下格式：作为<用户类型>，我想<feature>以便<benefit>。示例：作为 abc.com 的客户，我想要一个登录功能，以便我可以在线访问我的帐户详细信息。As a customer of abc.com, I want a login functionality so that I can access my account details online.如前所述，要特别注意产品的用户是谁，并避免“用户”的一般角色。如果你不知道谁是用户和客户，以及为什么他们会想要使用的产品，那么你应该没有写任何用户故事。叙述用户故事的第一部分是叙事。用2-3个句子来描述故事的意图。这只是意图的总结。对话用户故事最关键的方面是开发团队，客户，产品负责人和其他利益相关者之间应该不断进行的对话，以巩固用户故事的细节。验收标准验收标准代表满意的条件，这些条件被写为场景，通常采用Gherkin（Given，When，Then）格式。验收标准还提供故事的完成定义。谁应该写用户故事？在大多数情况下，用户故事由产品负责人或业务分析师编写，并在产品待办事项中进行优先级排序。但是，这并不是说只有产品负责人才能编写用户故事。实际上，任何团队成员都可以编写用户故事，但产品负责人有责任确保存在积压的用户故事并确定其优先级。重要的是，用户故事不应该被视为需求文档，在撰写时将被交给开发团队实施。用户故事应被视为鼓励产品负责人和开发团队之间进行对话的一种手段，因此应在产品待办事项修饰会话期间进行协作编写。让开发团队参与编写用户故事的一个优点是，如果存在任何技术限制，可以提前突出显示它们。测试人员可以特别增加构建有效验收标准的价值，并提前计划需要测试的内容和方法。用户故事的详细程度如何？用户故事关注客户价值。用户故事与其他形式的需求规范之间的基本区别在于详细程度。用户故事是正在进行的工作的隐喻，而不是对工作的完整描述。随着系统开发的进展，通过协作围绕用户故事进行充实的实际工作。如果描述变得过于冗长（超过索引卡上的描述），您应该重新访问用户故事。您可能想要包含太多细节。请记住，用户故事的目的是鼓励协作。它并不意味着记录工作的每个方面，因为传统的需求声明通常就是这种情况。此外，描述中的过多信息可能导致接受标准中缺少信息。在同意处理故事之前，团队必须了解验收标准。这些对于了解需要做什么以满足用户故事至关重要。接受标准应该足够详细，以定义用户故事何时满足，但不是那么详细，以至于无法进行协作。编写用户故事时常见的错误太正式或太多细节。 有良好意图的产品所有者经常尝试编写非常详细的用户故事。如果团队在迭代计划中看到一个看起来像IEEE需求文档的故事，他们通常会认为所有细节都在那里并且将跳过详细的对话。编写技术任务的用户故事。 敏捷的大部分功能来自于每次迭代结束时软件的工作增量。如果您的故事实际上只是技术任务，那么在每次迭代结束时，您通常不会使用工作软件，并且在优先级排序方面会失去灵活性。跳过对话。 在迭代计划之前，故事是故意模糊的。如果您跳过验收标准对话，则可能会向错误的方向移动，缺少边缘情况或忽略客户需求。敏捷软件开发什么是敏捷软件开发？什么是用户故事？什么是用户故事映射？用户故事与敏捷软件开发的使用案例

構建服務時可以使用許多敏捷方法，每種方法都有自己的一套工具和技術。本指南介紹了3種最流行的敏捷方法：Scrum看板Lean流行的敏捷方法解釋了ScrumScrum是最常用的敏捷方法。它允許高度結構化的模型具有明確定義的角色和職責。這對於正在轉向敏捷的傳統結構化組織尤其有用。在Scrum指南中了解有關Scrum功能的更多信息，由Scrum，Ken Schwaber和Jeff Sutherland的開發人員撰寫。看板 (Kanban)看板作為一種開發方法的靈感來自於生產系統，這些系統專注於減少浪費和提高質量，就像豐田創造的那樣。看板是一種可視化和改進當前工作實踐的方式，以便工作快速流經系統。快速，順暢的工作流程意味著您可以：快速，可預測地提供價值及早獲得反饋，了解您的產品或服務是否滿足用戶需求精益 (Lean)精益軟件開發，如看板，改編自豐田生產系統等精益生產原則。精益原則旨在幫助您的團隊專注於：減少浪費迅速交付學習和提高使用證據和數據做出決定使用多種敏捷方法您不必只使用一種方法，您可以從多種方法中選擇工具和技術來滿足您的團隊需求。每種方法都有自己的語言來描述基本的工具和技術，重要的是要理解：為什麼你選擇了一種工具或技術敏捷的目標找到您可以使用的其他敏捷方法。確定使用哪些方法Scrum如果您的團隊不熟悉敏捷工作，那麼Scrum是一個很好的起點。您的團隊通常會在以下情況下找到最有用的Scrum：建立新產品或服務增強現有功能在每個’sprint’中添加新功能（固定的時間段）當您運行實時服務並有緊急請求時，您可能會發現sprint約束並希望轉向基於流程的方法，如看板。但您仍然可以繼續使用與Scrum相關的許多活動，例如每日站立會議，回顧會議和定期審查進度。看板 (Kanban)看板幫助您的團隊：找到流程中的瓶頸控制你正在做的工作量根據實際交付預測您的輸出當您的團隊需要快速響應不斷變化的優先級時，它尤其有用。精益 (Lean)精益使您的團隊能夠盡快專注於學習。當您的團隊首次發現用戶的需求並決定如何滿足這些需求時，精益工具和技術尤其有用。更多推荐的Scrum文章如何使用Scrum Board进行敏捷开发？Scrum boards (also known as scrum task boards) are tools that help teams visualize backlogs of sprint work items. The board can use many manual (whiteboard and sticker) and virtual forms (software tools), but it can perform the same function regardless of appearance. (Scrum 板 (也称为 scrum 任务板) 是一种工具, 可帮助团队使冲刺积压工作项可见。该板可以采用许多手动 (即白板和贴纸) 和虚拟表单 (即软件工具), 但无论外观如何, 它都能执行相同的功能。)如何为Scrum项目撰写产品愿景？模板和示例The product vision is not part of the Scrum process. Why is it so important? Schwaber believes that vision is two necessary illusions, starting the Scrum project by stating: “The smallest plan starts the vision of the necessary Scrum project composition and product backlog” (产品愿景不是Scrum流程的一部分，为什么它如此重要？Schwaber的认为，愿景是两个必需的一个假象，开始Scrum项目，通过陈述道：“ 最小的计划开始了必要的Scrum项目组成的愿景和产品Backlog ”)Scrum: 什么是产品Backlog中的DEEP？Product Backlog projects have described attributes (D appropriate details), Story points (E stimated), order (P rioritized), and they are constantly added, deleted and updated (E merged) in the backlog to reflect the backlog of teams in a timely and appropriate manner. (产品Backlog项目具有描述的属性（D适当的详细说明），Story points（E stimated），order（P rioritized），并且它们在积压中不断被添加，删除和更新（E合并）以反映到对以及时和恰当的方式积压团队的积压。)如何为用户故事撰写SMART和INVEST目标?SMART is a set of standards for creating goals such as Sprint goals. While INVEST reminds you of the characteristics of high-quality product backlog (PBI) (or user stories) typically written in user story format. (SMART是一套创建目标（如Sprint目标）的标准。虽然invest会提醒您高质量产品积压工作（PBI）（或用户案例）的特征，通常以用户案例格式编写。)Sprint Increment (冲刺增量) vs Potential Shippable Product (潜在可发货产品) vs MVP vs MMPScrum requires the team to build an incremental function in each sprint, and the increment must be deliverable, because the product owner may decide to release it at the end of the sprint. This article explains and clarify the related key concepts of: sprint increment, potential shippable product MVP and MMP. (Scrum要求团队在每个sprint中构建一个增量的功能，并且增量必须是可以发送的，因为产品负责人可能决定在sprint结束时发布它。 This article explains and clarify the related key concepts of: sprint increment, potential shippable product mvp and mmp。)什么As / I want / so that 用户故事模板？The most common technology is the role-feature-reason template, which is used by teams and product owners to start writing user stories in three parts: (1) As a (role); (2) I want (feature); So that (reason). (最常见的技术是角色 - 特征 - 理由模板，用于团队和产品所有者开始编写用户故事，分为三个部分：（1）作为 As a（角色）; （2）I What 我想要（特征）; So that（理由）。)Scrum中的Burndown图表是什么？Burndown chart is a graphical representation of the remaining work and time. It is usually used in agile software development methods, such as Scrum. However, burning charts can be applied to any project that contains measurable progress over a period of time. (Burndown chart 是剩余工作与时间的图形表示。它通常用于敏捷软件开发方法，如Scrum。但是，刻录图表可以应用于任何包含一段时间内可衡量进展的项目。)Scrum中的Sprint目标是什么？Sprint goals show the expected results of iterations that provide shared goals for the team, which must be defined before the team starts Sprint in order to focus on achieving this goal. This ensures that everyone is on the same page. After choosing goals, the team must strive to implement them. (Sprint目标显示了为团队提供共享目标的迭代的期望结果，必须在团队启动Sprint之前定义该目标，以便专注于实现此目标。这可确保每个人都在同一页面中。选择目标后，团队必须努力实施目标。)如何使用MoSCoW方法确定产品积压的优先次序?MoSCoW (also known as MoSCoW prioritization or MoSCoW analysis) is a prioritization technology designed to reach a consensus with stakeholders on its importance for the delivery of each requirement. (MoSCoW方法（也称为MoSCoW优先级划分或MoSCoW分析）是一种优先级技术，旨在与利益相关方就其对每项要求的交付的重要性达成共识。)Sprint Backlog在Scrum中是什么意义？Sprint Backlog is a set of product backlog projects selected for the current Sprint and a plan to provide product increments for achieving Sprint goals. (Sprint Backlog是为当前Sprint选择的一组产品Backlog项目，以及为实现Sprint目标而提供产品增量的计划。) ...

“持续关注卓越的技术和良好的设计提高了灵活性。” “Continuous attention to technical excellence and good design enhances agility.”下一句话很有趣。许多人可能把敏捷软件项目团队想象成一群“牛仔”，他们只是聚在一起，敲出代码，而没有太多的设计计划，也没有任何编码标准。通常情况并非如此。敏捷认识到需要以正确的方式做事情，以避免以后不必要的返工。然而，敏捷的方法不应该导致产品过度设计或“镀金”。在敏捷环境中，你经常听到的一条评论是“仅仅是够好 (“just barely good enough.)”的概念。换句话说，这项工作应该在完整性和质量方面达到一个成功的水平，以充分实现它预期的目的，而不是更多。超过“勉强够好”的水平被认为是浪费。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“简单——最大化未完成工作量的艺术至关重要。” “Simplicity—the art of maximizing the amountof work not done—is essential.”“简单——最大化未完成工作量的艺术至关重要。”这个原则强调简单。有多少次我们看到项目失去了控制，因为需求变得太复杂，很难实施，并且需求变得过度设计，试图满足你能想象到的每一个可能的需求？这也与“仅仅是够好 (just barely good enough)”的概念有关 —— 不要过度设计；尽可能简单。在某些情况下，从一些非常简单的东西开始，看看它是否满足需要，然后在以后仅在必要时扩展功能可能是有意义的。敏捷的另一个概念是“最小可行产品 (minimum viable product)”，它定义了产品在市场上必须可行的功能特性的最小集合。一般来说，采用增量方法从简单的东西开始，然后在必要时扩展它，而不是从可能对需求造成过度破坏的过于复杂的东西开始，会更有效。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“最佳架构、需求和设计来自自组织团队。” “The best architectures, requirements, anddesigns emerge from self-organizing teams.”敏捷很大程度上基于自组织团队的思想，但这需要一些解释。有时，开发人员使用“自组织”的概念作为无政府状态的借口，但这并不是他们想要的。其目的是，如果你在一个跨职能的团队中有合适的人，并且团队被授权以协作的方式集体使用团队中的所有技能，那么它通常会比一个单独的人能够提供更好的结果。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“团队定期反思如何提高效率，然后相应地调整和调整其行为。” “At regular intervals, the team reflectson how to become more effective, then tunes and adjusts its behavior accordingly.”敏捷在两个方面具有适应性：设计适应不确定和不断变化的用户需求，它可以从需求的高级视图开始，并在项目启动后逐步细化需求。过程本身是适应性的，而不是高度规定性的。敏捷很大程度上建立在持续改进的基础上，利用短时间间隔来重新判断什么是有效的，什么是无效的，并在必要时采取快速的纠正措施。在Scrum中，这称为回顾，它发生在每个冲刺的末尾。随着项目的进展，团队将根据需要不断改进和调整敏捷过程。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“工作软件是进度的主要衡量标准。” “Working software is the primary measure of progress.”衡量软件开发项目的进展可能是困难和有问题的。传统的方法是将一个项目分解为任务，并跟踪这些任务的完成百分比，以此来衡量进度；但是，这可能会产生很大的误导，因为通常任务列表不完整，并且完成水平通常需要一些主观判断，这很难做出，而且往往不准确。测试是这方面的另一个因素，在过去，整个开发过程和测试过程可能是连续的。结果是，即使软件的开发看起来是完整的，但在测试和验证它是完整的之前，您不知道它到底有多完整。敏捷方法强调在开发软件时更同时地进行测试。敏捷中有一个概念叫做“完成的定义”，你会经常听到。团队应该清楚地定义“完成”的含义，这通常意味着软件已经过测试并被用户接受。在其他环境中，done的定义可能会更加模糊，并受到解释的影响。如果您没有明确定义“完成”，则任何对完成百分比的估计都可能是可疑的。更准确的进度度量方法是将一个软件项目分解为多个功能块，其中每个软件块都有一个明确的“完成”定义，并且可以向用户演示以获得反馈和接受。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“经常交付工作软件，从几周到几个月，优先选择较短的时间范围。”下一个原则强调使用迭代方法将项目分解为非常小的增量，称为冲刺或迭代，通常在两到四周的范围内。这很有道理的原因有两个：所有敏捷开发过程（如scrum）都基于持续改进。我们希望团队采用一种经验的方法 (empirical approach) 来了解随着项目的进展，哪些是可行的，哪些是不可行的，并在必要时进行调整，而不是采用一个永不改变的严格定义的过程 (defined process)。如果将项目分解为很短的增量 (increments)，并且在每个增量结束时进行学习，那么学习和持续改进可以更快地发生。一个流行的敏捷口头禅是:“及早失败，经常失败”。 “Fail early, fail often.”换句话说，在许多情况下，最好快速尝试一些东西，从中学习并做出调整，而不是花费所有可能需要的时间来尝试设计一种第一次毫无效果的方法。人们工作效率更高，只需在短时间内完成任务。如果做得正确，团队会发展出一种节奏和节奏，这种节奏和节奏对于快速而有效地产生确定的工作量增量非常有效，就像制造装配线一样。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“在整個專案過程中, 業務人員和開發人員必須每天一起工作。” Business People and Developers MustWork Together下一個原則強調專案團隊和業務贊助者之間的夥伴關係。這與敏捷宣言中 “合作而不是合同 (collaboration over contracts)” 的價值非常一致。為了落實這一原則, 業務贊助者 (business sponsors) 和專案團隊都需要對專案的順利完成承擔共同責任。這就需要業務贊助者的參與程度遠遠高於許多傳統專案中的常見水準, 在這些專案中, 專案的實施幾乎可能完全委託給專案團隊。當然, 參與的程度應適合專案的性質, 企業主辦人的參與方式可能因情況而異。例如, scrum 有一個名為 “產品擁有者 (Product Owner)” 的角色 (Role), 它為專案提供日常業務方向, 但方向可能並不局限于此。在一個大型的企業級專案中, 可能還有其他一些利益攸關方者 (other stakeholders) 需要提供投入, 需要以某種方式參與。設計一種讓合適的人在合適的時間參與進來的方法, 對於專案的成功非常重要。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“围绕有动机的个人构建项目。为他们提供所需的环境和支持，并相信他们能够完成工作。” “Build projects around motivated individuals. Give them the environment and support they> need, and trust them to get the job done.”下一个原则强调了在项目中适当激励个人的重要性。在过去，有些项目经理经常使用高压、指挥和控制策略来迫使项目团队更快地交付结果。在我们的职业生涯中，很多人都参与过“死亡行军 (Deatch March)”项目，在这个项目中，人们被赋予完成某件事情的绝对期限，如果有必要的话，他们必须在晚上和周末工作。当你处在一个需要高度创造力和创新的环境中时，这种方法就不能很好地工作。敏捷的哲学是建立在项目人员的高度授权和个人主动性的基础上的。敏捷团队没有被明确地告知该做什么，也没有被强制去做以满足最后期限的要求，而是被赋予了一般的指导，并期望自己能够确定如何最有效和高效地完成它。使这种方法发挥作用需要一种以人为本的领导风格。然而，这并不意味着不需要任何领导。一个敏捷的项目经理需要调整他或她的领导风格来适应这种情况，这通常取决于几个因素，包括项目的性质、团队的成熟度和经验水平。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“向项目团队传递信息的最有效方法是面对面交谈。” “The most efficient and effective method of conveying information to and within a project team is face-to-face conversation.”这原则强调面对面的交谈。这是另一种说法，你不能把它当作绝对的，而是把它当作相对的。分布式团队 (distributed team) 并不总是能够进行面对面的交流，但如果可能的话，这当然是可取的。这一声明也不意味着唯一的交流形式是直接的面对面的交流。它是对瀑布式项目历史的一种反应，瀑布式项目严重依赖文档化的需求作为一种沟通方式。有许多方法可以以各种形式交流信息，您需要选择最佳组合来确定给定的情况。正确的组合将取决于许多因素，包括项目的范围和复杂性以及项目团队的分布。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“敏捷过程促进可持续发展。赞助商、开发人员和用户应该能够独立地保持恒定的速度。” Promote Sustainable Development敏捷的许多基础来自精益制造和全面质量管理（TQM）。许多年前，在一个制造环境中，公司了解到，像血汗工厂这样的制造工厂，强迫工人在恶劣条件下加班，通常不会产生高质量的产品。在敏捷环境中，同样的事情尤其如此，因为工作的成功如此关键地依赖于团队的创造力和动力。在这种情况下，更重要的是要创造一个长期可持续工作的环境。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“欢迎不断变化的需求，即使是在开发后期。敏捷流程利用变化来获得客户的竞争优势。” “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”下一个原则强调创造一个期望和欢迎变化的环境，而不是严格控制和限制；当然，这并不意味着项目是完全不受控制的。基于与客户的合作关系，有很多方法可以有效地和协作地管理变更。重要的是，项目团队和客户应该事先就如何管理变更达成共识。更多推荐的 scrum 文章Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

这四个价值陈述构成了敏捷宣言的基础。敏捷宣言中的原则扩展了价值, 并提供了更多细节。同样, 与值语句一样, 这些语句也应被视为相对偏好, 而不是绝对偏好。这些原则概述如下, 并在以下各节中进行更详细的讨论:我们的首要任务是通过早期和持续交付有价值的软件来满足客户。欢迎不断变化的要求, 即使是在开发后期。敏捷流程利用变化来获得客户的竞争优势。经常交付工作软件, 从几周到几个月不等, 优先考虑较短的时间刻度。在整个项目过程中, 业务人员和开发人员必须每天一起工作。围绕有积极性的个人建立项目。给他们所需的环境和支持, 相信他们能完成任务。向项目小组和在项目小组内传达信息的最有效率和效力的方法是面对面的对话。工作软件是衡量进展的主要标准。敏捷进程促进可持续发展。赞助商、开发者和用户应该能够无限期地保持不变的步伐。持续关注卓越的技术和良好的设计可提高敏捷性。简单性–最大限度地增加未完成的工作量的艺术–是必不可少的。最好的架构、要求和设计来自自组织团队。团队定期反思如何变得更加有效, 然后相应地调整和调整其行为。更多推荐的 scrum 文章Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

早期和持续交付有价值的软件“我们的首要任务是通过及早持续交付有价值的软件来满足客户的需求。”“Our highest priority is to satisfy the customer through early and> continuous delivery of valuable software.”第一个原则强调“及早和持续地交付有价值的软件”。在敏捷之前的许多传统计划驱动的项目中，最终用户客户直到项目的最终用户验收测试阶段才看到任何东西，到那时，进行任何可能需要的更改都是非常困难和昂贵的。强调软件的早期交付可以实现两个主要目标：1。它为客户提供了一个在开发周期早期看到软件的机会，并提供反馈和输入，以便能够快速、轻松地进行更正。2。工作软件是一个很好的进度度量。从实际完成、测试和交付到用户满意程度的增量软件功能方面衡量进展要准确和有效得多，而不是试图衡量未完成的大型开发项目的完成百分比。在不将大型软件开发项目分解为多个部分的情况下，准确地测量整个软件开发项目的进度是非常困难的。这可能是一个非常主观的判断和一些猜测。将工作分解为明确定义的“完成”标准的明确定义的部分，提供了一种更真实和客观的方法来衡量进展。更多推荐的 scrum 文章Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

用户故事的目标不仅是记录需求，还要提供客户在生产中使用的工作软件。用户故事提供了一种机制，用于记录客户和开发人员之间关于软件功能的讨论。定义“用户故事代表卡中的客户要求，导致对话和确认。” 〜罗恩杰弗里斯模板以下是用于定义用户故事和验收标准的众所周知的模板。价值陈述：作为（用户角色），我想（活动），以便（业务价值）接受标准：给定（上下文），何时（执行行动），然后（可观察的后果）一般准则以下是编写用户故事时要考虑的一些通用准则：用户故事有三个方面：卡片，对话和确认（Ron Jeffries 2001）用户故事应表示对用户或系统所有者有价值的功能。用户故事应描述单个功能。用户故事应该有一个注释部分，其中记录了有关用户故事详细信息的对话。用户故事应该在故事点中具有估计（成本），其表示大小和复杂性。用户故事应根据其对客户的价值进行优先排序。良好用户故事的属性（INVEST）Mike Cohn在他的“用户故事应用”一书中指出了一个好的用户故事的六个基本属性。这些是：独立的（I）用户故事应该不依赖于其他用户故事。用户故事应该是自包含的。用户故事应按任何顺序完成和发布。当发生依赖关系时，应该以不同的方式组合或拆分用户故事。可面议（N）用户故事不应该是合同义务，因为它们是可以协商的。用户故事应该是客户，开发人员和测试人员之间的协作谈判。有价值的（V）用户故事应该对软件的用户或所有者有价值。用户故事不仅仅对开发人员有价值。用户故事应明确定义客户/用户的利益，以帮助确定优先级。用户故事应由客户编写，以确保其对客户/用户有价值。可估计（E）用户故事应根据故事点进行估算。在开发团队估计用户故事之前，应该清楚地理解用户故事。在开发团队估算之前，用户故事应包含足够的详细信息。当开发团队缺乏领域知识时，用户故事可能无法估计。当开发团队缺乏技术知识时，用户故事可能无法估计。当用户故事太大时，用户故事可能无法估计。小的（S）用户故事应该尽可能小，同时仍然提供用户价值。用户故事应该能够适合一次迭代。对于大的用户故事将难以理解和估计。可测试的（T）应通过测试验证用户故事，以证明它们已正确实施。用户故事应包含指导测试的故事接受标准。用户故事应该很容易进行单元测试。（技术实施）用户故事应该很容易接受测试。（行为的）用户故事应尽可能以自动方式进行测试。故事点规划改进的Fibonacci（0,1 / 2,1,2,3,5,8,13,20,40,100）T恤（xxs，xs，s，m，l，xl，xxl，）完成（DoD）的定义团队可以使用许多标准来定义他们的“完成定义”。这可确保团队提供在功能和质量方面完成的功能。Done的定义是可审核的核对表。以下是国防部的一系列可能标准和活动：单位测试通过接受标准达成代码已审核通过功能测试非功能性要求产品负责人接受用户故事用户故事示例以下是用户故事的示例。参考科恩，迈克。用户故事应用：敏捷软件开发。第1版，Addison-Wesley Professional，2004年。Wake，William C. Extreme Programming Explored。Addison Wesley，2002。

每个Sprint的输出的正式名字为“潜在可交付产品增量”。在开始第一个Sprint之前，产品负责人、团队和Scrum Master必须审视对于把一个产品待事项列表中的事项做到潜在可交付所需要的所有事情。所有为了交付产品所需的活动都应被包含在“潜在可交付”的定义中，并且要在这个Sprint中完成。遗憾的是，当团队开始使用Scrum时他们通常做不到在每个Sprint都能交付出“潜在可交付增量”这个目标。这通常是因为团队缺少自动化或者不够跨职能（例如，技术文档撰写者还没有被包含在跨职能团队中）。随着时间的过去，团队必须要提高从而能够在每个Sprint交付“潜在可交付产品增量”。但是为了开始，他们需要建立一个他们当前能力的基线。这会被记录在“完成的定义”中。在第一个Sprint开始前，产品负责人和团队要对于“完成的定义”达成共识，“完成的定义”是创建“潜在可交付产品增量”所需要的活动的子集（对于一个好的团队来讲两者是一样的）。团队会根据“完成的定义”来计划他们在Sprint中的工作。一个好的产品负责人总是会希望“完成的定义”与“潜在可交付”越接近越好，因为这样会增加开发中的透明度并降低延迟和风险。如果“完成的定义”不等同于“潜在可交付”，那么就会有工作被延迟到发布之前，这会导致风险和延迟。因此被延迟的工作有时被称为未完成的工作。Scrum团队应当持续地改进，这一点会表现在对“完成的定义”的扩展上。

概述：在团队成员间更新信息和进行协调。参与者：团队必须参加；产品负责人不是必须的；ScrumMaster通常会在场，但要保证团队自己主持会议。时长：最长15分钟。一旦Sprint开始，团队就要投身于另一个Scrum实践，那就是每日Scrum会议。在每个工作日指定时间都会举行这个很短的（15分钟，或者更短）会议。团队中的每个人都要参加。为了让它保持简洁，建议每个人都保持站立姿势。这是团队同步他们的工作并互相报告遇到的阻碍的机会。在每日Scrum会议中，每个团队成员一个接一个地向团队的其他成员报告三件事：（1）你昨天做了什么？（2）你今天要做什么？？（3）遇到了什么阻碍？注意每日Scrum会议并不是向管理者报告状态的会议。这是一个自组织团队互相分享目前工作情况的时刻，从而帮助他们进行工作协调。有人要把这些阻碍记录下来，Scrum Master负责帮助团队成员解决它们。在每日Scrum会议中只有很少或不会有深入的讨论，其形式只是做回答那三个问题的报告。如果的确需要讨论，那么在每日Scrum会议后马上就会有一个或多个并行的跟进会议，但在Scrum中没要求任何人必须参加这些会议。部分或者全部的团队成员需要针对于他们在每日例会中所收到的信息进行调整时开跟进会议很常见，换言之，这是又一个审视并调整的周期。对于新接触Scrum的团队，通常情况下建议管理者或者其他会被认为有权威的人不要参加每日例会。这样做的风险是会让团队感到“被监视”。它使得团队在压力之下每天都报告出重大进展（这是不切实际的期望），并使团队不愿报告问题。并且它会破坏团队的自管理，引入微观管理。对于一个利益相关人，更有益的做法是在会议后再找到团队，并帮助解决那些让团队进展慢下来的阻碍。

概述：为了将来的Sprint拆分大事项、分析事项、重新估计并重排优先级。参与者：团队；如果产品负责人是能够帮助梳理细节的专家，那么他会全程参与整个活动，否则他可以只参与其中一部分来设定方向或者重排优先级；其他理解需求并能给予团队帮助的人；ScrumMaster将在会议的开始部分来指导团队如何有效地开这个会，否则的话他不必参加。时长：通常来讲不多于团队一个Sprint工作容量的10％，但有时对于“有大量分析工作”的事项来讲要更长一些。例如，对于两周的Sprint，可能要有一天的时间花在梳理上。Scrum中一个很少有人知道，但很有价值的指导原则是，每个Sprint中整个团队要把一定百分比的时间专门用于梳理产品待办事项列表上，做为对将来Sprint的支持。这包含了详细的需求分析、把大的事项拆小、估计新的事项以及重新估计已有事项。Scrum中没有说这个工作该如何来完成，但是一个经常用到的方法是在接近Sprint中部或者结尾时开一个专注的研讨会，这样团队和产品负责人以及其他利益相关人就可以不受打断地专门做这些事情。这种梳理活动并不是为了当前Sprint已经选择的那些事项。它是为了将来的事项，最可能是为了下一两个Sprint。有了这个实践方法，Sprint计划会议变得相对简单些，因为产品负责人和Scrum团队将从一组清晰的，被很好分析过并认真估计过的事项入手。没有开过这种梳理工作研讨会（或者没做好）的特征是Sprint计划会议中出现重大的疑问或者发现，或者令人困惑并感觉不完整。这样一来计划工作通常要延续到Sprint中去，这显然不是大家想要的。

概述：对于功能性的产品增量进行审视并调整。参与者：团队、产品负责人、ScrumMaster。产品负责人可以邀请其他恰当的利益相关人参加。时长：时间箱为Sprint中的每一周对应一个小时。在Sprint结束后，就到了Sprint评审会议 (Sprint Review Meeting)，人们会评审这个Sprint。出席会议的人有产品负责人、团队成员以及ScrumMaster，再加上客户、利益相关人、专家、领导层和任何有兴趣的人。对于两周的Sprint来讲最长为两个小时。任何参与者都可以问问题和提意见。评审会议常常会被错误地打上“演示”的标签，但这并没有抓住这个会议真正的用意。Scrum中的一个关键思想是审视并调整。观察并了解发生的情况，然后根据反馈进行演进，不断进行。Sprint评审会议是对于产品的审视并调整活动。它让产品负责人了解产品和团队的当前状况（也就是对于这个Sprint的评审），也让团队了解产品负责人和市场的当前状况。因此，评审会议中的一个关键元素是团队与产品负责人之间进行深入的对话来了解情况和得到建议等等。评审会议当然要包含使用团队所创造的真的，运行起来的软件，但如果评审的关注点只是在看产品而没有进行交谈，这么做就失衡了。Sprint评审会议中“运行起来的软件”这部分并不是由团队来做“报告”，不会用到幻灯片。它是指亲手来检验正在运行的真正的软件，例如在一个用于开发的沙盒环境中。在评审会议议室里会有一台或多台电脑，人们可以在上面检验和使用运行起来的软件。最好有一个积极交互的过程，由真实用户和产品负责人动手与软件交互，而不是由团队做出一个被动的展示过程。尽量做到在不超过30分钟的时间之内做完Sprint评审会议的准备，否则就意味着有什么地方做得不对。

概述：针对流程和环境进行审视并调整。参与者：团队、ScrumMaster、产品负责人（非必须）。团队可能会邀请其他利益相关人，否则这些人不准参加。时长：时间箱为对应Sprint中的每一周为45分钟。Sprint评审会议包含了对于产品的审视并调整。而在评审会议之后的“Sprint回顾会议”则包含了针对流程和环境的审视并调整。这是团队讨论什么方式能工作，什么方式不工作的机会，并对要尝试的改变达成一致意见。有时Scrum Master可以扮演回顾会议的效率协调者，但可能还是找一个中立的外人来协调这个会议更好。一个好的做法是，Scrum Master们互相帮助协调彼此的回顾会议，这会起到在团队间“交叉受粉”的效果。组织Sprint回顾会议有很多技巧，《敏捷回顾》（《Agile Retrospectives》）一书中提供了很有帮助的一系列技巧。很多团队的回顾会议只关注于问题，这很不好。这使得人们以为回顾会议是某种让人情绪低落的或者负面的事件。正相反，要保证每次回顾会议也关注于正面的事物或者优势。有几本关于“欣赏式探询”的书在这方面给出了更多的点子。回顾会议如果总是用同样的分析技巧可能就会变得无聊起来，这样的话就要随着时间的推移引入不同的技巧。

Scrum不仅仅是一套具体的实践，确切地说更为重要的是这个框架提供了透明度并给出了“审视并调整”的机制。Scrum通过让影响产品负责人 (Product Owner) 和团队 (Development Team) 效率的机能失调和障碍变得显而易见，使它们得到及时处理。比如，产品负责人可能不清楚市场情况、特性或如何估算它们的相对商业价值。亦或者团队可能对于工作量估算或开发工作还不够熟练等。Scrum框架会迅速揭露这些弱点。Scrum并不能解决开发的问题，只是让问题都赤裸裸地显现出来，并为人们尝试用短周期和小改进试验来解决问题提供了框架。假设团队因为任务分析和估算技能不佳，而不能交付他们预期在首个Sprint完成的工作。对于团队而言，这是次失败。但是实际上，这是个必需经历的第一步，以使得团队对于以后的预期更加实际和周到。Scrum的这种模式使得机能失调显现出来，让团队能够及时处。正是这种基本的机制带给了使用Scrum的团队所能经历到的最大好处。一个常见的错误做法是当使用某个Scrum实践遇到挑战时改变Scrum。比如，团队交付有困难，他们可能决定延长Sprint，那么时间永远都是充裕的，并且在这过程中确保自己永远都不用学习如何更好地估算和管理时间。这样，没有经验丰富的Scrum Master的教练和支持，这个组织的Scrum就会蜕变成只是其自身弱点和功能不调的镜像，并且破坏了Scrum所能带来的真正利益：也就是使得好坏都显露无遗，给组织提供自我提升的机会。另一个常见的错误做法就是假定某个实践是不准许或禁止的，只是因为Scrum没有明确地提到。比如，Scrum没要求产品负责人为产品制定长期策略，也没要求工程师对于复杂的技术问题向经验丰富的前辈讨教。Scrum将这些都留给相关的个人来做正确的决定，在多数情况下，以上两个实践（和其他一些）都是特别推荐的。还有一个需要注意的是管理者强制团队使用Scrum。Scrum提供给团队空间和工具来自我管理，这种从管理层强压下来的命令并不是取得成功的方法。一个比较好的做法就是让团队先从同事或管理者处了解到Scrum，进行全面的专业培训，然后由团队决定在一定的时期内忠实遵循Scrum实践，在该时期结束时团队将评价其工作经历，再决定是否继续使用Scrum。虽然首个Sprint通常对于团队来说是极富挑战性的，但值得庆幸的是在Sprint结尾时Scrum带来的好处就会显现出来。所以很多新的Scrum团队都惊叫：“Scrum太难了，但是比起我们以前的做法它简直是太好了！”

Scrum Projects的主要利益相关者是产品负责人产品负责人的一个不可或缺的责任是向Scrum团队传达Scrum项目的重要性和重要性。这是通过使用Product Backlog成功实现任何敏捷项目的关键。现在让我们看一下产品负责人的一些主要职责 ：产品Backlog的创建和维护：Scrum Process主要用于软件环境和新产品开发领域。这是产品负责人正在进行的工作和全职工作。在任何sprint计划会议之前，他必须不断地进行梳理。根据业务ROI确定Backlog的优先级：产品负责人还需要根据业务和情况的需要对待办事项进行优先级排序。他还将用户故事中的史诗，主题和特征详细阐述，这些故事足以在单个冲刺中实现。产品负责人负责不断提醒Sprint＆Release团队，并确保团队在实现目标的过程中保持正轨。产品负责人负责与客户和利益相关方不断保持沟通，以确保团队正在构建正确的产品并提供预期的业务价值。同样在每个Sprint结束时，产品负责人都有机会引导团队朝着为利益相关者创造价值的方向发展。产品负责人还会在每个Sprint结束时不断检查Scrum团队所做的工作，并拥有接受或拒绝其工作或建议修改的绝对权限。产品负责人还充当团队对外界的代言人，并应确保所有沟通渠道保持开放，项目获得成功所需的正确的支持。如果产品负责人认为所需的方向发生了巨大变化并且不再需要花费，则有权终止Sprint。如果竞争对手发布新产品并且客户想要反击，则可能发生这种情况产品负责人的职责是繁重的，有很多必须由他穿着因此一个产品负责人的选择必须明智地做，因为它可能会导致成功或失败对整个项目可能最终意味着项目成功或失败。Scrum角色什么是Scrum团队？什么是Scrum的自组织团队？Scrum团队如何运作？ - 简要指南如何成为Scrum项目的优秀产品负责人？什么是产品负责人在Scrum中的角色？敏捷开发：如何成为合格的Scrum Master？什么是Scrum中的猪和鸡？项目经理与Scrum Master对项目所有者什么是三个Scrum角色？什么是Scrum Master？角色和责任什么是敏捷中的跨职能团队？作为Scrum Master，您如何帮助您的项目所有者？

Scrum方法需要改变传统方法的思维方式。中心焦点已经从瀑布方法的范围转变为在Scrum中实现最大的商业价值。在瀑布中，改变成本和进度以确保达到预期的范围，在Scrum中，可以改变质量和约束以实现获得最大商业价值的主要目标。瀑布模型适用于有序和可预测的项目，其中所有要求都明确定义并且可以准确估计，并且在大多数行业中，此类项目正在减少。客户需求的变化导致企业适应和改变其交付方式的压力增大。Scrum方法在当前市场中更为成功，其特点是不可预测性和波动性。Scrum方法基于inspect-adapt循环，而不是Waterfall方法的命令和控制结构。Scrum项目以迭代方式完成，其中首先完成具有最高业务价值的功能。各个跨职能团队在Sprint中并行工作，以便在每个Sprint结束时提供潜在的可交付解决方案。因为每次迭代都会产生可交付的解决方案（这是整个产品的一部分），所以团队必须实现可衡量的目标。这可确保团队正在进行，项目将按时完成。传统方法没有提供这种及时的检查，因此导致团队可能会下班并最终完成大量工作。当客户定期与团队互动时，定期审查完成的工作; 因此，可以确保进度符合客户的要求。然而，在瀑布中没有这样的交互，因为工作是在筒仓中进行的，并且在项目结束之前没有可用的功能。在复杂的项目中，客户不清楚他们在最终产品中需要什么，并且功能需求不断变化，迭代模型可以更灵活地确保在项目完成之前可以包含这些更改。但是，当完成具有明确定义的功能的简单项目，并且当团队具有完成此类项目的先前经验（因此，估计将是准确的）时，瀑布方法可以是成功的。敏捷 Vs. 瀑布下面是一个表格，可以更好地了解Scrum和瀑布的差异。下面是一个表格，可以更好地了解Scrum和瀑布的差异。敏捷还是瀑布？见图Standish Group的最新报告涵盖了他们在2013年至2017年期间研究的项目。在这段时间内，敏捷和瀑布的成功，挑战和失败的整体突破如下所示，敏捷项目成功的可能性大约是后者的2倍，失败的可能性降低1/3。（来源：vitalitychicago.com - 比较瀑布和敏捷项目成功率）敏捷与瀑布 - 项目成功率更多推荐的 scrum 文章Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

任务计划和评估对于按照优先产品Backlog中指定的要求迭代开发产品至关重要。Scrum团队在任务评估会议中估算完成任务列表中每项任务所需的工作量。此过程的结果是Effort Estimated Task List。Scrum团队使用Task列表，这是一个包含团队为当前Sprint提交的所有任务的综合列表，用于开发Effort Estimated Task List。任务列表必须包括任何测试和集成工作，以便Sprint的产品增量可以成功地集成到之前Sprint的可交付成果中。尽管任务通常基于活动，但任务被分解的粒度级别由Scrum团队决定。在任务评估会议期间，Scrum团队使用任务列表来估计完成任务或任务集所需的工作量，并估计在给定Sprint中执行任务所需的人员工作和其他资源。该技术的一个主要优点是，它使团队能够对用户故事和需求拥有共同的视角，以便他们可以可靠地估计所需的工作量。任务估算会议中开发的信息包含在“工作量估计任务列表”中，用于确定Sprint的速度。在本次研讨会中，Scrum团队可以使用各种技术，如分解，专家判断，类比估计和参数估计。任务评估会议也可以与任务计划会议相结合。为了保持相对估计大小并最小化重新估计的需要，团队使用估计标准。估计标准可以用多种方式表达，两个常见的例子是故事点和理想时间。例如，理想时间通常描述Scrum团队成员专门开发项目可交付成果的小时数，而不包括花在项目之外的其他活动或工作上的任何时间。通过评估标准，Scrum团队可以更轻松地估算工作量，并使他们能够在必要时评估和解决效率低下问题。任务估计的输出是Effort Estimated Task List。它是与Sprint中承诺的用户故事相关联的任务列表。通常，估算的准确性因团队技能而异。估计的努力以团队商定的估算标准表示。Scrum团队在Sprint计划会议期间使用此Effort Estimated Task List创建Sprint Backlog和Sprint Burndown Chart。团队集体估算在Scrum开发期间，团队分担责任并共同致力于每个Sprint的工作，因此敏捷团队的估计工作量使用了集体估算方法。集体估算通常使用规划扑克作为工具，团队通过玩估计游戏进行集体估算。规划扑克被认为是在敏捷中进行工作负荷估算的最有效和最有趣的技术。它由一组类似于斐波纳契数的数字组成，包括：0,0.5,1,2,3,5,8,20,40，？，∞，扑克牌每组有4组这样的斐波那契数字用于服务供4人使用。群体与个体估计的准确性根据一些关于软件项目实验中个人和小组之间努力估计准确性的研究。来自同一公司的20名软件专业人员分别估算了实施相同软件开发项目所需的工作量。参与者有不同的背景和角色，软件项目以前已经实施过。之后，他们组成了五个小组。每个小组通过讨论和结合他们之间的知识来商定一项估计。结果 - 基于小组讨论的估算比个人估算更准确。进行计划扑克的步骤每个团队成员获得一组卡片，包括0,0.5,1,2,3,5,8,13,20,40，？，∞，共12张牌。该产品所有者要么读描述要素的团队。团队成员讨论该功能，并在需要时询问产品所有者问题。当成员完成讨论后，他们每个成员选择一张扑克牌来代表估计。然后同时显示卡片。如果团队评估不同的估计。我们同意吗？我们有差异吗？有什么我没考虑过的吗？那些选择最高或最低价值的人应该在每个成员选择另一张扑克牌之前与小组分享他们的推理。讨论结束后，您可以估算另一轮，团队需要达成协议。返回第二步并开始估计下一个条目。估计大小，而不是估计时间段，使用相对估计而不是绝对估计估计只不过是一个受过良好教育的猜测。我们利用手头的所有知识和经验来猜测它将花费的时间。因此，不是单独查看每个新工作项，为什么不将它与以前完成的工作项进行比较？人类更容易与类似物品相关而不是猜测事物的实际大小。例如，它是否更接近这个非常小的东西？或者它更像这个正常大小的项目？还是像我们上个月完成的那项工作一样真的很大？做相对估计不仅会减少估算工作所花费的时间，还会大大提高估算的准确性。我们的大脑无法进行绝对估计; 我们总是把我们需要估计的新事物与我们已经知道的事物相关联。故事点估计估计速度 - 记录和平均每个Sprint的团队速度该团队的速度是多少故事点数的Scrum团队在一个Sprint实际完成。团队速度告诉你团队的速度有多快。一个新估计的项目或团队（过去没有参考速度记录），我们可以做1-2个Sprint来测量速度作为初始速度。在Sprint实施过程中，我们需要记录每个Sprint的速度，以便将来的计划。估计用户故事速度我们估计产品Backlog的故事点总数，然后我们知道每个Sprint的平均速度，然后我们可以计算出我们需要完成多少Sprint，因此预计Sprint将是项目所需的。如下图所示。Scrum项目持续时间估算其他Scrum实用技术什么是Scrum中的Sprint目标？什么是Scrum中的Burndown图表？什么是角色 - 功能 - 原因模板？Sprint增量与潜在可运输产品对比MVP对MMP为用户故事撰写SMART目标和投资谁在Scrum中创建产品Backlog项目或用户故事？什么是敏捷估算？什么是敏捷中的故事点？如何估算用户故事？

在Scrum项目中，Scrum团队成员负责提供所需的产品或服务，而不是Scrum。因此，我们应该小心组建Scrum团队。Scrum团队有时被称为开发团队，因为他们负责开发产品，服务或其他结果。它由Sprint Backlog中的用户故事组成的一组人员为项目创建可交付成果。Scrum团队提供所需项目结果的基本特征如下所述：自组织 (self-organized)： Scrum团队成员是有动力的人，他们不等待上级分配任务。他们承担责任，分担风险，做出决定，共同努力实现共同目标。授权：(Empowered) Scrum团队或开发团队获得所需的资源，以提供所需的产品或服务以及作出决策的权限。如果团队只有责任但没有权力做出决策，那么连续/迭代开发就很困难。协作 (Collaboration)：项目管理是一个共享的价值创造过程，团队一起工作和互动，以提供最大的价值。Scrum团队应该分享知识，想法，风险和责任，并与团队成员协调工作，以提供理想的结果。共同目标 (Shared Goal)： 团队中的个人应共同努力实现共同目标。团队目标应该叠加他们的个人目标，如成长，评估和金钱。最佳规模 (Optimum Size)： 一个小型Scrum团队可能没有开发产品或服务所需的技能，而大型Scrum团队可能会破坏工作，因为团队内部的协作将很困难。根据SBOK的定义，Scrum团队的最佳规模应为6到10。这将确保Scrum团队足够大，能够拥有交付项目所需的技能，并且足够小，可以进行协作。多样化的技能 (Cross-functional)： Scrum团队应该集体拥有提供项目可交付成果所需的技能。在Scrum团队组建期间，应该选择团队成员，牢记交付项目可交付成果所需的技能。并置 (Collocated)： 建议组建一个Scrum团队，成员并置。这确保了团队成员之间的协作和协调可視化 (Visualized)：工作任務的可視化。讓團隊成員瞭解工作任務項以及當前進度。

对于大多数转向敏捷方法的公司而言，产品所有者 (Product Owner) 是新的东西。但是，每个月您都会看到产品所有者需求的显着增长。为什么？我们将在本文中讨论它，更多地关注产品所有者在软件开发项目中的角色。谁是产品所有者？一个伟大的产品负责人基本上是他的产品的企业家。PO是敏捷团队的成员，负责提供高质量的数字产品。简而言之，PO定义用户故事并优先处理积压 (Backlog)，同时保持团队功能的概念和技术完整性。敏捷产品负责人在质量控制方面的作用是巨大的。PO是一个关键成员，他接受完成后的故事。根据我们的经验，与不同行业的公司合作，如果公司没有采购订单，那么在大多数情况下，如果没有达到最后期限并且产品交付的功能不是真正需要的，那么开发过程会变得混乱。但是，我不得不说要完成敏捷软件开发项目中需要完成的所有工作，在我看来，产品负责人应该有一些技术知识才能更有效。为什么？因为产品所有者应该能够与技术团队交谈并理解对推进项目至关重要的概念。此外，PO应该能够向其他利益相关者解释技术概念。PO就像开发团队和利益相关者之间的中间人。但是，除了掌握技术知识外，PO应该从最终用户的角度对产品有所了解。这意味着PO也应该有业务背景。不幸的是，现在世界上很少有人真正符合这个“理想的候选人”标准，因此许多大学和学院开始开设课程来培养产品所有者。如果您想听取我们的意见，那么我们认为将技术人员，开发人员或CTO转换为PO比商务人员容易得多。让我们来看看PO的主要责任范围。软件开发项目中的产品负责人角色创建和维护产品Backlog 在软件领域，没有什么是不变的，产品负责人必须根据客户和市场需求调整产品Backlog。此外，好的PO知道何时以及如何说NO。这可能是最明显但也是最难掌握的人。对新想法或功能说“是”很容易，这只是产品积压的另一个项目。但是，良好的积压管理包括创建可管理的产品积压，其中的项目可能会实现。在积压的情况下添加项目，知道什么都不会发生，只会造成“浪费”和错误的期望。为了避免整个开发过程花费太长时间的情况，项目失去了重点，而开发的解决方案可能无法真正解决业务问题，PO应该对某些功能和变更说“不”。但在这些情况下，根据业务价值或ROI确定积压的优先级 每个用户故事必须按相对重要性排序。不应该有5个高优先级。重要的是要知道哪个用户故事是＃1，哪个是＃2等。这不仅仅是从业务角度来看，PO应该考虑到开发部分以及在做X之前根本无法开发的一些功能任务。因此，PO应该从双方分析需求，并提出最佳解决方案，最佳优先级，从一开始就为产品增加更多价值。用户故事 PO应该知道如何编写用户故事。简单的例子是：作为用户，我想<某个目标或目标>，以便<benefit，value>。这里有一篇文章解释用户故事。在每个Sprint开始时传达愿景和目标 这有助于保持团队的正常运转。产品负责人代表客户发表意见，并与利益相关方共同创造产品愿景。每个决定都考虑到产品愿景。这确保了可持续的产品开发，为开发团队提供了清晰度，并增加了产品成功的机会。吸引客户和利益相关者以确保团队正在构建正确的产品 开发团队不应该花时间向客户解释技术问题，这是PO的工作。换句话说，产品负责人是团队对外界的代言人，应该确保所有沟通渠道都是开放的，并且项目需要适当的支持才能取得成功。PO负责定义实现目标的边界和约束。它们可以包括截止日期完成日期，成本限制，内存限制和最低速度。参加每日Scrum会议，Sprint计划会议以及Sprint评审和回顾。 对于产品负责人而言，拥有能够适应不同团队和个性类型的良好沟通技巧尤为重要。产品负责人应根据当前状态，进展，可能的斗争和问题更新利益相关者。质量保证 通常情况下，PO是唯一可以接受故事的团队成员。这包括验证故事是否符合验收标准并具有适当的，持久的验收测试，并且它符合其“完成定义”投资回报率 产品所有者负责提供最佳投资回报。他们对sprint的发布和产品级别的所有经济决策负责。预算，时间和质量可根据需要进行调整，每个产品的成本和收益积压也可用于确定用户故事的优先级。解决冲突 任何无法处理冲突的人都不应该是产品所有者。在数字产品开发中，拥有强大的冲突解决技能对于阻止争议升级并专注于真正重要的事情非常重要。有时，PO必须经历一些冲突才能达成解决方案。准时交货 产品负责人负责确保团队满足截止日期和目标。PO负责根据里程碑提供最佳工作软件。如果您喜欢本文关于软件开发中的产品负责人角色，您可能会喜欢：Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (基础篇)Scrum的基本功 - 集合中英文版本 (角色和责任篇)

本教程适用于敏捷软件开发新手的Scrum团队成员，以了解他们的角色和职责。本教程还将帮助那些已经在敏捷模型中工作的人提高他们的技能，并帮助那些只想了解这些角色的人。它还将提供对责任及其所隐藏的每个角色的洞察力。Scrum团队的角色和责任Scrum团队主要由三个角色组成：Scrum Master，产品负责人和开发团队。核心团队以外的任何人都不会对团队产生任何直接影响。Scrum中的每个角色都有一套非常明确的职责，我们将在本教程后面详细讨论。在本节中，让我们关注Scrum团队的整体属性和理想的团队规模。Scrum团队属性以下是Scrum团队的2个属性：Scrum团队是自组织的Scrum团队是跨职能的自组织Scrum团队在完成工作方面是自力更生和自给自足的，无需外部帮助或指导。这些团队有足够的能力采用最佳实践来实现他们的Sprint目标。跨职能Scrum团队是团队中具备完成工作所需的所有技能和熟练程度的团队。这些团队不依赖团队外的任何人来完成工作项目。因此，Scrum团队是完成整个工作项所需的不同技能的非常有创意的融合。每个团队成员可能不一定具备构建产品所需的所有技能，但能够胜任他/她的专业领域。话虽如此，团队成员不需要交叉功能，但整个团队必须是。具有高自组织和跨职能的团队将带来高生产力和创造力。Scrum团队规模Scrum中推荐的开发团队规模为6 +/- 3，即3到9个成员，不包括Scrum Master和产品负责人。现在，让我们继续前进，详细讨论这些角色。Scrum MasterScrum Master负责促进/指导开发团队和产品负责人从事日常开发活动。他是确保团队理解Scrum价值观和原则并能够实践它们的人。与此同时，Scrum Master还确保团队对Agile充满热情，以便在框架内实现最佳效果。Scrum Master还帮助并支持团队自我组织。除了对团队成员进行有关敏捷重要性的培训和培训外，他还有责任确保团队始终保持积极性和强化。他还致力于加强团队成员之间的沟通和协作。Scrum Master是一名流程负责人，他帮助Scrum团队和Scrum团队以外的其他团队了解Scrum值，原则和实践角色和责任＃1）教练 - Scrum Master为开发团队和产品负责人充当敏捷教练。Scrum Master在某种程度上可以作为开发团队和产品负责人之间正确沟通的推动者。Scrum Master负责消除其他角色之间的障碍。如果注意到产品负责人没有参与或没有给开发团队提供适当的时间，那么Scrum Master的工作就是指导产品负责人了解他参与整个团队成功的重要性。＃2）辅导员 - Scrum Master也是Scrum团队的推动者。他促进和组织Scrum团队成员要求的所有Scrum活动。Scrum Master还帮助团队做出重要决策，从而提高Scrum团队的整体生产力。Scrum Master从不命令团队成员做某事，而是通过指导和指导帮助他们实现目标。＃3）消除障碍 - Scrum Master还负责消除影响团队交付业务生产力的障碍。团队成员无法自行解决的任何障碍都会导致Scrum Master解决。Scrum Master根据对团队生产力和业务的影响对这些障碍进行优先排序，并开始研究这些障碍。＃4）干扰关守 - Scrum Master还保护Scrum团队免受外界干扰和分心，以便团队可以在每次冲刺后继续专注于为业务提供最佳价值。如果团队在Scaled Scrum环境中工作，其中多个Scrum团队正在协同工作并且在他们之间具有依赖关系，那么干扰可能会引起更大的关注。Scrum Master确保团队不参与任何不相关的讨论，并专注于Sprint项目，而他自己则负责解决来自外部的查询和疑虑。Scrum Master负责保护团队免受外部干扰并消除障碍，以便让团队专注于提供业务价值。＃5）仆人领袖 - Scrum Master通常被称为Scrum团队的仆人领袖。他最重要的职责之一就是向Scrum团队询问他们的顾虑并确保他们得到解决。Scrum Master的职责是确认团队的基本要求是优先考虑并得到满足，以使他们有效地工作并产生高绩效的结果。＃6）流程改进者 - Scrum Master和团队还负责定期即兴创建所采用的流程和实践，以最大限度地提高交付价值。Scrum Master不负责完成工作，但是他有责任让团队设计一个让他们完成冲刺目标的流程。产品负责人我们将在本教程中讨论的另一个非常重要的角色是产品负责人。产品负责人是客户/利益相关者的代言人，因此负责缩小开发团队与利益相关者之间的差距。产品所有者以最大化正在构建的产品价值的方式管理差距。产品负责人将参与Sprint活动和开发工作，并在产品的成功中发挥至关重要的作用。角色和责任＃1）弥合差距 - 产品负责人与内部和外部利益相关方密切合作，收集输入并综合愿景，将产品功能放入产品Backlog中。产品负责人有责任了解利益相关方/客户群体的要求和偏好，因为他是代理人并肩负着构建正确解决方案的责任。同时，产品负责人确保开发团队了解需要构建的内容以及何时构建。他每天都与团队合作。产品负责人与团队的互动增加了反馈频率和响应时间，从而提高了正在构建的产品的价值。产品所有者的缺席/减少协作可能导致灾难性的结果并最终导致Scrum失败。产品负责人确保产品待办事项项目透明且清晰表达，团队中的每个人对项目都有相同的理解。管理产品待办事项 - 作为上述结果，产品负责人负责创建和管理产品Backlog，订购产品Backlog中的项目以最好地实现利益相关方的要求，即产品Backlog项目的优先级，最后他应该随时可以回答或澄清所有开发团队的问题。总的来说，他负责培训产品Backlog以提高交付价值。任何想要在产品Backlog中添加/删除项目或需要更改项目优先级的人都应该定向到产品所有者＃3）认证产品 - 他的另一个责任是认证正在构建的功能。在此过程中，他为每个产品待办事项项定义了接受标准。产品负责人还可以创建代表他定义的验收标准的验收测试，或者可以在创建它们时从中小企业或开发团队获得帮助。现在，他是通过执行验收测试来确保满足验收标准的人。他可以选择自己执行这些验收测试，也可以请专家这样做，以确保功能和质量方面得到满足并满足期望。此项活动通常在项目完成时在整个sprint中完成，以便可以发现错误并在实际Sprint审核会议之前修复。＃4）参与 -产品负责人是Sprint相关活动的主要参与者。他与开发团队密切合作，解释项目，范围和价值。他还充当开发团队的推动者，能够在Sprint结束时获取他们应该提供的Product Backlog项目。除Sprint活动外，产品负责人还负责产品发布活动。在产品发布活动期间，产品负责人与利益相关方进行讨论，以讨论下一版本的项目。团队蓬勃发展的关键成功因素之一是整个团队应尊重产品负责人及其决策。产品负责人以外的任何人都不应该告诉团队要处理哪些项目。建议单个产品拥有一名全职产品所有者。但是，可以存在产品所有者是兼职角色的安排。代理产品所有者代理产品所有者是产品所有者自己注册的人，他可以接管他的所有职责，缺席并支持他。代理产品负责人对他所委派的所有责任负有责任，但最终完成的工作的责任仍然在于实际的产品负责人。代理产品负责人还有权代表实际产品负责人做出必要的决策。开发团队Scrum团队的另一个非常重要的部分是开发团队。开发团队由熟练掌握自己专业领域的开发人员组成。与其他Scrum团队成员不同，开发团队负责实际实施潜在可交付软件/增量，并在每个Sprint结束时交付。开发团队可能包括具有专业技能的人员，如前端开发人员，后端开发人员，开发人员，QA专家，业务分析师，DBA等，但他们都被称为开发人员; 没有其他标题是允许的。开发团队甚至不能像测试团队，需求规范团队等那样拥有子团队。团队的成立考虑了在没有外界帮助的情况下成功开发，测试和交付每个Sprint产品增量所需的所有基本技能。因此，该团队应该是自给自足和跨职能的。开发团队不会从Scrum团队外部获得任何帮助并管理他们自己的工作。开发增量的责任始终在于整个开发团队，但Scrum团队中的每个人都负责整体交付。完全由开发团队决定添加/删除团队成员。如果需要新的技能组合，开发团队可以选择在团队中构建专业知识或向团队添加新成员。角色和责任＃1）开发和交付 - 开发团队负责根据每个sprint结束时的“完成定义”创建完成增量。完成增量可能不一定是下一个生产版本的一部分，但它绝对是最终用户可以使用的潜在可释放功能。产品负责人致电决定需要成为发布的一部分。开发团队负责开发和交付符合“完成定义”标准的每个Sprint的完成增量。任务和提供估算 -开发团队还负责从下一个Sprint中提取优先产品Backlog中的用户故事/项目。因此，这些项目构成了Sprint Backlog。Sprint Backlog是在Sprint计划会议期间创建的。开发团队的另一项非常重要的职责是通过分解Sprint项目并为这些Sprint项目提供估算来创建任务。没有人告诉开发团队做什么以及如何做。开发团队有责任从下一个Sprint中提供的Product Backlog中获取项目。Sprint启动后，无法更改/添加/删除项目。开发团队规模应明智地选择开发团队规模，因为它可能直接妨碍团队的生产力，从而影响产品交付。开发团队不应该非常庞大，因为它可能需要团队成员之间的大量协调。但是，对于一个非常小的团队来说，获得递增所需的所有技能将非常困难。因此，应为开发团队规模选择最佳数量。建议的开发团队规模为3到9个成员，不包括Scrum Master和产品负责人，除非他们还与其他开发人员一起开发软件增量。摘要Scrum团队角色产品拥有者开发团队Scrum Master尺寸Scrum团队规模 - 3到9自组织团队知道完成工作的最佳方式。没有人告诉自组织团队该做什么。跨职能团队拥有完成工作所需的所有技能，无需任何外部帮助。产品拥有者代表委员会或受其影响。与利益相关者和Scrum团队合作。管理产品积压解释产品待办事项。确定工作项的优先顺序。确保产品积压易于理解和透明。清楚地定义要处理的项目。确保开发团队了解产品待办事项中的项目在产品负责人中添加/删除/更改的任何内容都应通过产品所有者进行。接听电话以释放工作项。Scrum Master确保团队清楚地理解和采用Scrum。是Scrum团队的仆人领导者。删除障碍物保护团队免受无用的交互，最大限度地提高Scrum团队创造的业务价值。根据要求促进Scrum事件。确保会议时间安排。开发团队在每个Sprint结束时提供可能可释放的“完成”产品增量。它们是自组织和跨职能的。没有人告诉开发团队什么和如何做。没有标题是允许的。所有人都是团队中的开发人员。不能创建子团队。他们对Sprint项目负责。开发团队负责任务并提供估算。这就是我们在Scrum团队角色和责任方面的全部内容。我们讨论了每个团队成员所承担的责任以及他们作为一个整体团队的工作方式。Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

BPMN（业务流程建模符号） 是业务流程建模现代化的标准，由BPMI符号工作组五月制定2004年版的2.0 BPMN发布于2010年在英国最初的规范写由对象管理组。 BPMN的目标是：负责流程实施的技术专家;创建和改进流程的业务分析师;监控和控制流程的经理。通过这种方式，BPMN可以作为业务流程及其实现之间的链接。BPMN使用简单的图形表示法将业务流程可视化为图表。这些图形元素对用户来说很直观，并允许他们构建复杂的语义结构。业务用户发现使用表示为图表的流程非常方便，许多分析师使用BPMN来解决这个问题。使用BPMN设计的所有流程模型都是_可执行的_，不仅仅是在纸上描述，这意味着它们可以在任何BPM系统中运行。计算机程序将图表转换为实时运行的实际可执行进程。这 实际在BPMN建模和阅读业务流程的课程是一套用实际的例子，它会教你如何与流行的工作经验BPMN标准。为了提供课程的示例，我们使用了ELMA业务流程管理软件。这个独特的课程介绍了使用BPMN中描述的业务流程的核心概念。这是本课程的第一课，我们试图使其简单易懂，最重要的是，有用！第1课在BPMN中，通过具有一系列图形元素的图来描述过程。这种可视化使用户易于理解过程的逻辑。BPMN主要用于设计和读取业务流程的简单和复杂图表。为此，BPMN标准按类别对图形元素进行分类：因此，使用业务流程图的用户可以轻松识别元素。使用BPMN描述的任何过程都表示为根据某些业务规则因此或同时执行的多个步骤（活动）。看看“订单处理”流程，该流程可用于销售和租赁自行车的在线商店。图1“订单处理”流程您应该始终从“ 开始事件”中读取进程。图1.1开始事件从名称中可以看出，“ 开始事件”标识了流程的起点; 它只能有输出序列流。在BPMN中，起始事件由具有开放中心和圆形边界的圆圈表示。在我们的示例中，“ 开始事件”可以是电话呼叫，也可以是来自商店网站上留下的客户的消息。 从 Start Event开始，该过程遵循顺序流程，直到它到达 End Event ; 一个进程可以有几个结束事件。图1.2结束事件一个结束事件 指定了一个进程内的路径完成; 它只能有传入的序列流。一个结束事件 是通过用粗实线边界的圆表示。在我们的示例中，结束事件是将商品交付给客户。 请注意，在ELMA中，开始事件 和结束事件也按颜色区分，这就是为什么它们分别显示为绿色和红色圆圈的原因。工作流程由开始 事件和结束 事件之间的各种元素可视化。表示在该过程中执行的工作的核心元素称为活动。活动是BPMN的可执行元素，可以是原子的也可以是非原子的（复合）。Activity的原子类型称为任务。它以图形方式显示为圆角矩形。最常见的任务代表用户完成的工作，这就是为什么它通常被称为用户 任务。在我们的示例中，任务活动是：“处理客户请求”，“填写购买表单”和“填写租赁表单”。 图1.3用户任务BPMN的另一个广泛使用的元素是网关。在图形上，它显示为菱形，用于确定决策和评估条件。基本上，Gateway是一个分支点，通过拆分和合并来控制流程。图1.4。网关在我们的示例中，客户可能想要购买或租用自行车，并且根据该决定，订单被处理为购买或租赁。在流程图中，网关是决定点，指定每种情况下顺序流必须采用的方式。 在接下来的课程中，我们将了解其他BPMN 2.0图形元素及其在实践中的使用。熟悉BPMN的基本过程元素后，即使是最复杂的过程图，也可以阅读和理解。Business Process ModelingWhat is BPMN?BPMN Orchestration vs Choreography vs CollaborationBPMN Activity Types ExplainedBPMN Artifact Types ExplainedBusiness Process Modeling Software ToolBPMN Diagram and Tools - Visual ParadigmHow to Draw BPMN Diagram?Easy-to-Use BPMN Tools尝试BPMN在线例子（单击->即时编辑)