PingCode

打造Worktile敏捷开发管理工具的思与惑

从2019年初，我们团队准备开发一款适合研发团队使用的敏捷开发管理工具，那时候我们也在思考，到底什么样的工具才算是优秀的研发管理工具，研发管理的场景、方法和流派有很多，市面上关于研发管理工具的产品也是层出不穷，我们从哪里入手才能真正帮助研发团队提高研发效能？基于以下两点考虑，我们选择了从敏捷开发管理进入： 敏捷开发自1999年以来，经过20多年的发展，已经被大多数开发团队所接受，近几年DevOps的流行，更是把敏捷推向了更高的位置，国内太多的团队需要做敏捷转型。 敏捷开发在中国落地的专业度还不够，以至于出现了“中华田园敏捷”的说法，中国的开发者需要一款简单易上手的、专业的敏捷开发管理工具，来帮助他们在团队中更好的落地敏捷。虽然只靠一款敏捷开发工具并不能帮助企业在敏捷转型中成功，但好的工具却能让企业敏捷转型事半功倍。 专业的Scrum流程管理 在Scrum Guide中已经对于Scrum过程中的活动、事件、产出等定义的非常清晰，这里不再重复，只想重点解释一下在落地Scrum过程中经常被忽视的两个问题。 1、绝大部分团队在实施Scrum过程中只重视迭代管理，不重视版本管理，当然这已经超出了Scrum本身的范畴，但是好的研发管理中应该是迭代管理和版本管理并存，他们之间是一个互相依赖的关系。 迭代管理是针对Scrum团队的，它定义的是一个时间盒的概念，用于团队容量管理和进度管理，对于不同的团队来说，明确在一个迭代的时间盒内的产出，这个产出最终以迭代Review为标准，通过了Review并不意味着一定发布出去。 版本管理是针对产品的，它定义的是一个批量的概念，用于版本进度管理和交付风险管理，明确在一个版本中最终的交付物。目前市面上大部分敏捷开发管理工具，都能够很好的支持迭代管理，却忽视了版本管理。 2、在Scrum Guid中定义一个迭代中的四个活动，即迭代计划会议、每日立会、迭代评审会和迭代回顾会，我们发现在大部分敏捷团队中其实只有前三个活动，而自动忽略迭代回顾会议，恰恰相反，迭代回顾会是Scrum迭代实践中的最后一环，也是最重要的一环，迭代回顾会将整个迭代形成了闭环。Scrum小组都是自组织的，只有通过迭代回顾会不断的总结问题，提出改进项，才能帮助团队不断精进。 什么才是真正的Kanban Kanban理论已经存在了很长的时间，其适用范围也从最初的车间管理，到现在的硬件制造、软件开发。在软件开发领域内，很多团队都在使用Kanban管理自己的团队，有的使用电子看板，有的使用物理看板。Worktile团队在做电子看板上已经有了7年的经验，一直以来我们也在探索，到底什么样的看板才是真正的Kanban。在我看来，一个真正意义上的电子看板系统，要能够帮助团队达到以下三点： 帮助团队可视化整个链条的价值流动 帮助团队识别价值流动中的风险点 帮助团队度量价值流动中的各种浪费，并加以消除 基于以上考虑，在一个可视化的电子看板系统中，至少要具备以下一些能力： 能够清晰定义在制品WIP 能够清晰定义在制品限制WIP Limit 明确定义DoD 支持多泳道分割 在制品流转中某些操作自动化 达到某些风险点时，在制品能够高亮显示 需求管理如何做 不管是采用哪种敏捷方法实践，需求管理都是敏捷开发中非常重要的一环。Scrum中定义了两个重要的概念： 产品待办事项Product Backlog 和 迭代待办事项Sprint Backlog ；Kanban中一般采用在制品WIP的概念。 在Worktile Agile中，我们决定采用业界大家共识的三级需求管理体系，这种表示方式并没有一个真正意义上的标准： Epic：史诗，表示比较大的特性，开发周期一般是1-3月，用于产品路线图的规划 Feature：特性，表示相对小一些的特性，开发周期一般是1-3周，用于产品版本的规划 User Story：用户故事，最小的开发粒度，开发周期一般是1-3天，在Scrum中用User Story来作为Backlog，在Kanban中可以用User Story作为WIP。 联动起来才有价值 在研发场景下，对于团队成员来说经常整理需求/缺陷是个常态，另外在基于单个工作项沟通时，往往会提及另一个工作项，作为高效的研发管理工具，要能够清晰的定义工作项之间各种可能的关系。Worktile Agile中我们定义了超过10种工作项之间的关系： parent：定义工作项之间的父子关系 duplicates：表示两个工作项之间的重复关系 blocks：表示两个工作项之间的阻塞关系 其他的如mention、clone、causes关系等 只能够定义关系还不够，Worktile Agile还做到了在发生某些操作的情况下，自动生成他们之间的关系，如果团队成员在某个工作项评论中提到了另外一个工作项，则会在他们之间自动建立一条mention关系。 工程化不可或缺 在研发管理过程中，项目管理是很重要的一块，但项目管理本身并不会关注工程化的过程，在我看来，项目管理和工程化实践是确保研发顺利的两个支柱，缺少哪一个都会造成不可预知的影响，把工程化数据与管理过程结合起来，将会极大的减小管理成本，提升研发效率。 工程化的过程环节众多，涉及到的工具数量庞大，如代码托管、单元测试、代码扫描、流水线、打包、制品、部署等等，在Worktile Agile中可以通过REST API的方式，把工程化数据发送到工作项上面并与之关联，这样对于开发人员可以清晰的看到每一次提交涉及到的工作项是哪个，触发了哪些构建，构建的结果如何，以及当前工作项部署在了哪些个环境。（注：REST API正在内测中，目前还未对外正式发布。） 让一切皆可测试 在User Story的INVEST原则中，明确表示一个好的用户故事要必须是可测试的Testable。敏捷开发过程本身是频繁迭代、周期性强并且能够及时、持续地响应客户的反馈，如何正确建立测试策略，确认客户的需求能得以实现并且确保及时的交付最终产品是值得思考的一件事。 在Worktile Testhub中，测试人员可以轻松编写测试用例并且制定相应的测试计划，同时每个测试用例也可以用Worktile Agile中的User Story关联，让开发人员和产品经理知道这个User Story会如何测试，同时测试的结果也会及时的与Worktile Agile同步。 关于未来的一点想法 最后，简单的谈谈对于未来的一些想法。对于当下来说最重要的事情把现有的产品进一步打磨好，关于未来我们也在探索以下几个可能的思路： 简化手工操作，未来一定是智能的世界，在研发管理工具中，要尽可能的简化手工操作，让工作自动化起来，对于开发人员来说更是如此，他们宁可编写一段自动化脚本，也不愿一遍一遍的执行重复性的操作。 扩大人员覆盖，目前Worktile研发产品矩阵已经覆盖了需求人员、产品、设计、研发和测试等人员，未来我们还会进一步加大人员的覆盖面，让更多的团队角色可以在Worktile中完成他们的工作，比如对于中高层管理人员、PMO等。 扩大场景覆盖，当下我们的关注点在于如何做好敏捷项目管理和测试管理这两个场景上，未来不排除还会延伸到别的场景，比如多项目组合管理等。作者：Terry

PingCode Goals——国内首款研发OKR管理工具

PingCode Goals，真正实现了战略目标规划到敏捷项目实施的完整闭环，填补了产研团队OKR工具在国内的市场空白。——内测用户  万国数据研发总监 近些年，敏捷开发凭借其在产品交付速度、质量、风控等方面的显著优势，逐渐在软件开发模式中占据主流，但大量问题仍然阻碍着企业的敏捷实践： 1、业务、产研团队对需求优先级的判断不一致，互相抱怨； 2、各个研发职能对需求实现目的的理解不到位，影响开发进度； 3、迭代内如期通过演示评审，上线后难以达到市场预期； 4、迭代回顾会上问题提出来不少，却总得不到解决； 5、多条产品线之间各自为战，资源协调顾此失彼； 6、…… 这些问题本质上是由于研发团队及其所在公司过于看重技术和流程，未能建立“上下同欲”的目标感，即使效率再高，也只会事与愿违。 为了解决以上痛点，PingCode在今天正式推出旗下第五款产品，同时也是国内首款专注研发场景的目标管理工具—— Goals。 战略目标规划到敏捷项目实施的完整闭环 2020版“Scrum  Guideline”强化了产品目标和价值在Scrum框架中的重要性，但多数企业或团队在使用SaaS工具管理研发过程的同时，却只能依靠Excel、第三方工具，甚至白板等物理手段进行目标管理。原本想用目标驱动敏捷，实际目标管理却成了敏捷研发的拖累。 Goals的发布，是PingCode布局研发全流程管理的一块重要拼图。 以目标为原点，Goals实现了研发团队目标与企业目标的对齐。 正如用户对我们的评价，PingCode已然能够助力企业实现“从战略目标规划到敏捷项目实施的完整闭环”。 OKR配合产品路线图，确保从计划到交付的整个过程可预测、可控制； 需求规划、开发过程管理、测试执行和持续集成的无缝连接，为高频率、高质量的产品交付提供助力； 研发各个环节的知识、信息被收纳于结构化的知识库中，供企业成员共享和复用。 首款研发目标管理工具，Goals有备而来 1、基于OKR的目标管理 软件研发是典型的知识型工作，相比效率，知识型工作的结果有效性更为重要，决定何为“有效”则需要明确的目标和衡量方式。 如今最有效的目标管理实践体系——OKR工作法，采用这样一种互补结构：目标（O）以定性的方式表达“我们希望实现什么”；关键结果（KR）则是定量描述，从不同维度定义“做到何种程度才算达成目标”。 既有方向又有标准，因此OKR能够帮助团队聚焦于关键领域，更有效地沟通和推动工作。 PingCode Goals 提供非常简单易用的产品体验，让用户无需适应，即可快速创建OKR，指引工作方向。 即使是OKR初学者也不必担心，Goals自带OKR填写指南和适用于产研人员的示例，帮助用户稍加学习，就能写出有效的OKR。 OKR设定 / 填写帮助‌‌ 2、以OKR作为需求的“第一性” 业务和产研人员对需求优先级判断相互矛盾，研发各项职能对交付价值存在分歧，导致客户不买账，内部不信任，是研发管理中的常见问题。 产生该问题的根本原因是大家习惯于从各自的立场和固有经验出发，纠结“做什么”和“怎么做”，而忽视对于“为何做”的收敛、澄清。 OKR能帮企业建立起一致的“第一性原理”——从目标出发创建和描述需求，当评估需求优先级时，首先想的是如果实现这个需求，能为目标达成带来多大影响？ 在Goals中，OKR可同PingCode Agile的需求、Wiki的页面相关联，这样既可由OKR驱动跨部门、跨职能对需求文档、需求池排序、迭代范围和发布排期等形成共识，又便于在需求交付后，跟踪和评估其对目标产生的实际效果。 OKR与Agile需求关联 Goals还可配合PingCode Plan 的“增量范围”，实现大规模敏捷的轻松落地（详见本次推送第二篇文章）。 3、对齐他人目标，着眼于贡献 企业中各项工作的成果只有获得工作以外的认可时才有价值，软件研发也不例外。KPI等管理思路往往将工作时长、代码行数、Bug数等当作考核依据，但在实际中却极易造成产研团队闭门造车，交付的产出技术牛、质量佳，却对业务贡献不大。 OKR提倡“对齐”原则，鼓励员工对准公司整体目标，思考“我需要做什么、做到什么程度”才能对公司整体的目标有所贡献，能同其他产品线形成合力，自行提出目标和标准。以目标对齐带动敏捷开发，能让产研团队激发内驱力，创造真正的价值，并从中获得成就感。 Goals能够帮助用户在组织目标体系中定位自己应当做出的贡献，支持用户添加关注人和建立目标间的对齐关系；通过目标详情和对齐视图，可清晰查看目标的上下文和当前进度，帮助目标负责人与相关同事随时同步进展，识别并移除阻碍。 OKR对齐 4、“小步快跑”兼顾“抬头看路” 敏捷框架下，每轮迭代交付的产出通常需要一段时间过后，才能获得来自市场和终端用户的反馈；在迭代回顾会上提出的改进项，应被细化预期，并被持续跟进改善情况。 然而由于迭代周期往往仅为一、两周，因此单纯实施Scrum很容易忽略两个问题：研发是否真正创造了价值，团队是否在持续精进。 OKR则提供了一个相对更长的周期（一季度至一年），让敏捷团队在迭代之外定期记录和分析价值、效能的阶段性变化，在“小步快跑”的同时，注意 “抬头看路”。 用户在Goals上更新KR进度和进展，系统会自动通知关注成员，同时也会将“我们向目标行进了多远”以可视化的方式呈现出来，以便团队分析和调整对策。 OKR更新 Goals独有的复盘视图，让用户能对各个周期的目标达成情况一目了然，便于从更加宏观和延续性的视角总结经验，并对下一阶段工作进行规划部署。 OKR复盘 OKR布道者的使命延伸 Worktile 是国内首家推出OKR应用的企业级协作平台，曾出版《企业OKR实战手册》一书，累积帮助500+企事业单位在理念和工具层面成功落地OKR。 此次，我们希望借助PingCode Goals的上线，正式启动对研发团队OKR管理的赋能，同更多科技企业分享Agile+OKR的实战经验，让“Think big，start small，move fast”成为可落地的组织能力。 为了让更多研发团队早日实现理念和工具升级，PingCode 决定： Goals开放90天免费使用！ 即日起至2021年6月14日，任何版本的PingCode用户均可免费使用Goals，6月15日起恢复99元/人/年。 为了帮助大家更好的落地OKR，PingCode已经上线免费的OKR知识库，里面总结了我们WMC团队近8年500多家国内企业落地OKR实践经验，点击以下链接可立即免费获取：OKR从认知到落地

PingCode Insight 正式发布，让研发效能可量化、可分析、可提升

子产品 Insight 的发布，标志着 PingCode 正式进入数据化时代。自此，PingCode 在自动化、数据化、智能化的道路上又迈出坚实一步。 在数字化的时代，研发效能已经成为一家科技公司的核心竞争力。 在软件研发领域，效能提升的方法论和实践一直在快速发展。比如，我们熟知的敏捷开发方法已经诞生了二十年，DevOps 也已经发展了十多年，在很多行业、很多企业都对其进行了引入和落地。但是，我们经常遇到的一种现象是： 当一个组织/团队在消耗了大量的"变革"时间、花费了大量的人力和资金后，却无法有效回答一些看似非常基本的问题。比如： “我们的研发效能到底怎么样？可否量化？” “我们比所在行业平均水平如何？我们的研发能力跟同行相比更好还是更差？” “研发效能的瓶颈点和问题是什么？” “在采纳了敏捷或 DevOps 实践之后，有没有效果？有没有实质上的提升？” “我们接下来提升的方向在哪？如何实现持续改进？” 这就是为什么我们希望进行研发效能度量。 研发效能度量的目标是让效能可量化、可分析、可提升，通过数据驱动的方式更加理性地评估和持续改进，而不要总是凭直觉感性地说出“我觉得..."。 研发效能度量的出发点虽然很好，但是如何正确度量却是一个有难度的技术活儿。 研发效能度量要成功落地需要一个相对完善的体系，其中包含数据采集、度量指标设计、度量模型构建等多个方面。而实际情况是，大家都面临着数据的采集过程复杂成本高、缺乏系统性的思考与设计、偏离了效能度量的正确方向等难题。 而今天，PingCode 效能度量子产品 Insight 正式发布。 自此，PingCode 将帮助企业构建自动采集研发全生命周期效能数据的能力、建立起效能度量和改进的 MARI 闭环，降低度量成本，以开箱即用的方式促进研发效能度量的成功落地。 1. 构建自动采集研发全生命周期效能数据的能力 团队在软件研发中会使用各种各样的工具，而这些工具之间往往相互割裂，造成原始效能数据分散。 所以团队如果要度量效能，就需要从系统中导出数据到 Excel 表格，然后进行各种筛选、关联、透视和加工，最终形成度量报表。 但这一过程不仅提高了度量成本，同时还可能由于大量的人工干预行为导致数据的失真。 PingCode 产品矩阵覆盖了研发管理全生命周期，子产品中产生的过程数据将会自动收集到 Insight 中，并加以提炼形成企业度量所需的各种实时数据报表。 同时 PingCode 还将提供 Marketplace 和 REST API，帮助研发团队把其他工具中的数据收集到 PingCode，这些数据将和 PingCode 自身产品中产生的数据加以汇总融合，从而提供更多维度的效能度量数据。 2. 建立效能度量和改进的 MARI 闭环 2.1设计效能度量指标体系 整个研发管理链条中，本质上是两条工作流。 一条是管理侧以需求特性的全生命周期为核心的需求价值流，涵盖需求收集、规划、开发、测试到上线环节； 一条是工程侧以代码提交为线索的研发工作流，涵盖启动开发、开发中、开发完成、持续集成、持续部署到线上发布环节。 这就要求我们在效能度量的指标体系设计中，充分考虑这两条流之间信息的流转与状态的同步，从而设计出一套覆盖端到端交付的效能度量体系。 根据效能度量的目标，为了帮助企业/组织获得高效率、高质量的持续交付有效业务价值的能力，PingCode Insight 设计了如下三个效能度量指标体系： 交付效率：目标是促进端到端及早的交付，用最短的时间顺畅地交付用户价值； 交付质量：目标是促进端到端高质量交付，避免不必要的错误故障和返工； 交付能力：目标是建设卓越的工程能力，实现持续交付； 实现了端到端交付的效能度量体系的覆盖。 Insight 中非常丰富的度量报表： 2.2建立效能度量分析模型 效能度量分析模型是我们效能分析过程中，由于不同的项目类型或者是改进需求而产生的指标数据组合形式。 也就是说，我们可能有非常多的指标数据，但出于不同的分析目的，会选取的数据指标也不一样。比如燃尽图、速率图、标准差吞吐量、累积流程图、控制图、在制品限制图，几个指标组合在一起就是一个常用进度评估模型。 通过这个模型我们可以获取背景信息和上下文，知道任务何时完成，预测问题，对问题复盘与回顾。 用户借助 PingCode Insight 可以非常便捷搭建和使用各种效能度量分析模型 Insight 中的效能度量报表都以效能仪表盘的形式展示，每个团队都可以根据不同的分析需求来搭建分析模型，并将该仪表盘保存以达到开箱即用的效果。 同时在每个效能仪表盘上支持添加不同的指标分析，也可以针对每个效能仪表盘设定不同的可见性权限，以满足团队不同角色所关注的效能度量指标。 2.3回顾与改进 当通过上面建立的不同指标模型，分析诊断出问题后，将进入到MARI 闭环中最核心的一环——改进。 因为度量不能仅仅停留在数字层面，而是需要在层层深入挖掘出根本原因后，使度量带动思考和行动，建立持续改进的闭环。 大部分团队在这一阶段经常遇到的问题是：大家都知道了问题在哪，也制定了改进目标/措施，但并没有人员去负责监督改进的结果，最后只流于形式。 PingCode 的产品矩阵能够有效帮助企业实现效能改进的闭环管理： Insight 实现效能的度量和分析； 得出的改进措施借助 PingCode Project 中的安排专人负责、跟踪进度，从而让每一个改进措施都有结果。 随着度量体系逐渐成熟，企业/效能委员会可能会把重心放到效能分析和效能提升的实践分享上来，从而在公司内发挥更大价值。在这一阶段 PingCode Wiki 能够帮助他们形成效能度量指导手册、效能提升案例库和专项解决方案知识库，沉淀过程资产，让效能的度量、改进和提升成为日常工作的一部分。 3.通过自动化流程规范化降低度量带来的额外成本 研发效能的度量不是免费的，为了做到准确、有效的度量，各种成本加在一起很高。 比如我们经常会去度量团队的需求交付周期及其在设计、开发、测试、部署等每个阶段的时间消耗和占比。这样一个看似简单的度量需求，其实背后要做很多事情。 度量的准确性依赖流程的规范性，需要明确研发流程、制定相应规范，并确保相关的活动都在系统中进行及时、完整的记录。 为了能在减少研发中各角色时间和精力投入的基础上，提升效能度量的准确性，我们可以借助PingCode 产品矩阵的能力加以实现。比如： PingCode Flow 自动化的能力减少工程师繁琐的重复性和事务性手动操作，如在多个子产品之间进行状态更新同步等，从而自动完成状态的流转和信息的同步。 PingCode Project 、PingCode Testhub、PingCode Ship 搭建出一套标准化、规范化的研发工作流，并加以固化； PingCode Wiki 制定和沉淀企业内的技术规范和流程制度； 通过自动化的状态流转以及标准化的工作流搭建，系统中研发过程数据得以更为准确的记录，也在较低成本的情况下给度量提供了有效的研发基础数据。 小结 在本篇文章，我们探讨了通过子产品 Insight 的发布 PingCode 产品矩阵给用户带来的效能度量方面的四点重要价值：自动采集效能数据、建立效能改进闭环、沉淀效能改进规程资产、降低效能度量成本。 而本质上， Insight 以及 PingCode 整个产品矩阵在研发效能度量方面的价值远不止于此，还有更多的价值等待用户去挖掘。 我们希望通过PingCode Insight 的发布，能够正真帮助企业构建起效能度量和改进的闭环，提升企业的核心竞争力。

PingCode Agile 正式升级为Project，打造研发团队卓越交付能力

PingCode Agile （敏捷开发管理）子产品正式升级为 Project （项目管理）。 此次升级，我们在敏捷开发的基础上增加了对瀑布开发的支持。 除此以外，伴随着 PingCode 从刚发布时的4个子产品成长到如今的7个子产品，产品能力更加完善。Project 提供的价值也并不局限于项目管理，而是成长为一个能帮助团队提升交付效能的工具。比如： 借助全新的 Project ，团队可以选择敏捷Scrum、Kanban、瀑布开发中任意符合需求的项目管理方式； 团队也可以选择/创建符合自己管理方式的工作流，并且在 Project 实现项目的闭环管理； 除此以外，团队也可以借助自动化工具提升团队的工作效率等等。 本文就来为大家详细介绍全新的项目管理子产品 PingCode Project 。 01全新升级更全面的项目管理模式支持 常有人问，研发管理模式到底哪个好，哪个更能实现软件的快速交付？ 其实没有标准答案，一切取决于项目的特点。 而借助于 PingCode Project ，你可以从敏捷 Scrum、Kanban、瀑布开发多种研发项目管理方式中，根据自身项目的特点匹配适合的管理方式，以实现科学管理高效产出的目的 1.1全新的瀑布开发管理 以瀑布为主的传统型项目管理的特点是强计划驱动，需求范围固定下来后才可分配人员和时间，并在项目推进过程中积极跟踪和控制风险。 在瀑布开发模式下团队会经常面临着项目风险失控、研发协同复杂等问题。 为了帮助团队解决以上问题，更好的管理瀑布开发，Project 提供了强大的管理能力，比如： 项目规划：在 Project 创建WBS，规划项目阶段、计划、任务、周期、资源、依赖关系，以实现科学的项目规划； 甘特图：借助甘特图，可视化项目计划，呈现和管理项目进度、关键里程碑、资源、依赖阻塞点； 里程碑：设置关键里程碑、规划交付物、执行进度跟踪，确保有节奏达成项目目标； 除此以外，还有： 交付物管理：规划交付物目标，提交并检查交付物，跟进目标达成情况，以降低交付风险； 需求规划：对收集到的需求进行完善、分析、评审，规划需求阶段； 开发管理：工作项关联集成代码托管、CI/CD 工具，跟踪开发、构建及部署进度； 而这些也仅是 PingCode 在瀑布开发项目管理的部分能力，更多内容大家可以注册体验。 1.2最标准的Scrum和Kanban管理 1.2.1 Scrum Scrum 是一个解决复杂多变问题的框架。 使用Scrum 管理的过程中团队可能会面临需求管理混乱、交付进度迟缓、不同工具频繁切换等问题。 而这些都能通过 Project 提供的Scrum项目管理中得到解决。 比如 Project  在需求收集阶段能够以自定义字段的方式，满足个性化收集以及尽可能全的记录需求信息的需求，并以史诗/特性/用户故事三级需求、标签等方式管理需求优先级。 在解决交付进度迟缓问题上，Project 提供了直观、多视角的报表视图以跟踪迭代进展，并且还提供了团队速度、累计流量图等多种可视化报表，全方面度量研发效能。 最后，因为PingCode 本身就是一个研发全生命周期的管理工具，并且能够以插件的形式与你现有的工具相互打通。 1.2.2 Kanban Kanban 是一种为质量和过程中出现的问题提供了可见性，使得缺陷、瓶颈、变异性以及经济成本等因素对流动与交付速率的影响变得更明显的管理方式。 在Kanban项目管理上， Project 为用户提供的国内最标准的 Kanban 功能，能够有效帮助团队提升可视化、标准化等管理能力。 整体上，Project 的 Kanban 管理由规划、看板、工作项、版本、测试、页面、报表五大组件构成，能够比较全面地实现看板管理以及可视化管理的需求。 除此以外，还提供了高度自定的能力，以满足团队个性化工作流创建需求。 在标准化管理上，比如：国内很多 Kanban 工具都不具备并在制品限制功能，而在 Kanban 方法中，它是限制混乱的有效方式。 Project 中的 Kanban 支持通过限制每一个阶段允许积压的在制品数量来避免大量工作并行，达到控制混乱的目的（这一行为被称为在制品限制（WIP limit）。 除此以外，还有很多标准化的能力，比如支持将步骤拆分为Doing/Done & DoD，以保证整体开发过程的质量等等。 更多功能，大家可以通过注册进行体验，这里就不过多介绍。 理论上，无论是哪一种研发管理模式都会有一套最佳实践，但在不同的团队都有其熟悉的运转流程、管理方式、角色构成。 所以无论是Scrum、Kanban还是瀑布开发， PingCode Project 都预置了一套标准的管理流程模板，同时也支持根据团队管理方式创建适合自身的工作流。 02全新升级更全面提升团队交付效能 2.1打通全流程与全场景 确定了适合的研发管理模式，将进入到对研发项目的过程管理。 而整个软件项目研发管理链条，本质上是管理侧以需求特性的全生命周期为核心的需求价值流，以及工程侧以代码提交为线索的研发工作流。 研发管理工具的核心价值在于管理两条流，实现两条流之间的联动，完成信息的流转和同步。 所以无论在哪种研发管理模式，都需要工具来打通项目全流程、全场景的管理。 而 Project 具有打通研发全流程与全场景的能力，实现了从需求收集、规划、开发、测试、发布到上线，需求价值全流程的管理。 同时，借助REST API 等还可以将工程侧管理工具，如gitlab、Jenkins、Docker等产生的数据和信息集成到 Project，完成两条工作流之间信息的自动流转和同步。 所以跨团队以及产研团队内的不同角色，如项目经理、技术经理、产品都能在 同一个平台进行管理与协作； 以及从目标规划、需求、开发、编码、构建、测试到发布上线的全流程、全场景都能通过 Project 实现打通与管理 2.2根据直观的实时数据提升团队效能 至此，我们已经实现了项目全流程与全场景的管理，但就软件研发整个生命周期而言并未结束。 要搭建软件交付的闭环，研发团队还需要深入挖掘出组织或团队所处的位置和存在的问题，做到持续改进。 在具体项目上 Project 提供了团队速度、累计流量图等多种可视化报表，满足团队对该项目的度量和改进需求。 在团队或企业层面，PingCode 效能度量子产品 Insight 能够提供如交付效率、交付质量、交付能力等多维丰富的效能数据，以帮助团队洞察和改进。 2.3利用自动化提升工作效率 在闭环建立起来之后，研发团队的产品交付效能是否还有提升的空间？ ITChronicles 发布的一项调查显示：当前技术工作者一年有将近69天都在进行着事务性工作。也就是说，每年全球有将近5万亿美金被浪费在了这些重复性的工作中。 因此，让团队成员从那些重复性的、事务性的工作中解脱出来，成为了另一个让软件产品快速交付的突破点。 PingCode Flow 是我们在去年就已经发布的自动化产品，它能够与PingCode全线子产品如 Project 等进行关联，服务于整个研发团队。 能够帮助团队将开发中大量低价值、重复性的和事务性的工作从手动操作变为自动触发执行，比如自动变更工作项状态、自动变更负责人等等，让团队专注于真正有价值的任务。 小结 在本篇文章，我们重点传达了现阶段 Project 的几点核心价值： 敏捷开发以及瀑布为主的传统型开发项目，都能通过Project 进行管理； Project 能够打通研发全流程、全场景，促进需求价值流、研发工作流之间的信息的流转和同步； 在使用Project 管理项目的过程中可以借助 Insight 实现研发效能的度量和改进，以及利用 Flow 的自动化的提升工作效率，实现项目的闭环管理。 研发项目管理最终是为了高质量、快速、有价值的交付，而这正是 PingCode Project 乃至整个产品矩阵致力于帮助用户实现的。 如今，PingCode 已经能为所有类型的项目都提供一套最佳实践，做到全流程闭环管理，并以自动化、数据化、智能化的方式帮助团队不断提升软件项目交付的效能。  

国内首款产品管理工具 PingCode Ship 正式发布

在过去，国内研发团队所使用的研发管理工具基本都以产研团队管理为中心，核心解决需求价值流中从开发、编码、构建、测试再到发布上线环节的管理问题。 这也就意味着，非常多的团队无法通过现有工具建立一个“用户驱动的反馈循环”，通过这个循环观察到发生了什么，人们在产品中做了什么，然后把这些反馈吸收进产品，再反复迭代。 甚至无法帮助团队回答一些关系产品发展的根本性问题，比如： 销售/需求提交方说这个需求很有价值，那么到底有多少用户提过这一需求？ 我们自己规划了一系列功能，但哪些才是用户真正需要的？ 我们有如此多的客户反馈来源，要如何将这些反馈集中，以实现全局“产品洞察”？ 需求优先级到底怎么排更合理？是否可以通过多维度数据洞察进行优先级排序？这些数据如何采集？ 客户是否有机会通过“产品路线图”来帮助补足我们产品管理的核心要义？ ...... 这就使得产研团队“离代码太近，离客户太远”，无法将有限的精力聚焦于提升产品竞争力，服务好目标客户。 正是在这样的背景下，PingCode 打造了全新“产品管理”子产品 Ship。 国内首款产品管理工具 PingCode Ship 正式发布 与国内那些工单收集的管理工具不同，PingCode Ship 旨在提供一个“以客户为中心的产品管理工作流”，帮助产品研发团队： 做对产品决策，更快切入市场 洞察产品机会，真正理解客户需求 科学规划产品优先级 构建连接所有人的产品路线图 构建以客户为中心的产品管理工作流 1、覆盖全渠道的客户反馈门户 为了帮助产研团队更好地洞察用户需求，Ship 为用户提供了统一的需求、缺陷和建议反馈通道，其中就包括Web Portal、小程序、邮件、Webhook等渠道。目前已经上线 Web Portal，其他方式也将陆续上线。   而 Ship 的能力也并不局限于工单提交，它还是一个适度开放的需求/产品讨论社区。 客户可以通过点赞、评论等方式支持自己同样需要的功能，从而帮助产研团队了解客户更期待什么样的功能，优化现有的产品规划排期。 2、建立统一的需求池管理 通过以上工单收集渠道，客户的各种需求、缺陷等都将进入到 Ship 统一管理。但除了用户需求外，我们产品的需求可能还来自公司的目标、战略规划。 虽然这些在 PingCode 都是由 Goals 这个子产品管理，但无论是战略目标分解后的需求、或是产品/技术经理提出的产品/技术规划需求，也都将进入 Ship 统一管理。 3、以客户为中心的需求优先级决策 当进入到需求评审、排期阶段，以往很多团队评估优先级通常是根据需求工作量、技术难度、需求提出方、过往经验等有限的几个方面进行。 在 Ship，团队可以通过设置评审因素，比如需求价值、工作量、客户权重、竞品、团队目标支持度等，并针对不同维度设置分数计算方式，建立标准化产品优先级模型，数据化评估客户最需要的功能，确保产品目标与公司经营目标保持一致。 评审完的工单/需求将直接与工作项的关联，推送到PingCode Project，从而建立清晰完整的前后逻辑关系。 4、以客户为中心的产品路线图 产品路线图是产品负责人推动项目发展的重要工具，它将告诉团队每个阶段目标是什么，当前所处的位置。所以在需求评审和排期完成，团队将根据评审结果成产品路线图。 Ship 不仅支持将产品特性按版本、迭代、里程碑、时间展示，团队任务一致规划，同时团队可以便捷查看路线图中每个需求背后的客户反馈，如果有需要团队也可以有选择地通过 Ship 将产品路线图公开同步给客户或业务团队。 5、多产品管理 企业开发的过程中通常还会涉及多产品线/多项目。针对这一需求，Ship 提出了模块化能力，比如：用户可以通过创建子需求池来实现对不同产品/项目的管理，并设置对应的权限： 除此以外，有些企业为了精细化客户运营，实现商业价值的最大化，也会要求对客户建立分级管理制度。 而 Ship 为企业提供了自定义客户分组及管理能力。比如，企业可以通过该功能了解到今年客单价100万以上的付费客户提交的需求总量、在几个产品线的分布排名、采纳率、行业分布、响应时间等数据信息，以辅助个性化的客户需求管理。 基于 PingCode 实现研发自动化、数据化、智能化 至此，Ship 结合原有的子产品矩阵，PingCode 以客户为中心的研发工作流就正式建立。 同时，结合现有能力 PingCode 也将帮助企业构建从需求到开发的无缝流转过程，实现从需求收集到开发全链路可追踪、可复盘、可度量，实现真正的全链路管理。 PingCode Ship：打通客户、业务团队和产研团队之间的协作，帮助团队规划更科学的产品路线； PingCode Project：提供标准的敏捷开发流程以及瀑布模型开发，规范团队的协作流程； PingCode Testhub：组织测试团队的测试用例和测试计划，为最终的产品质量保驾护航； PingCode Wiki：生产和结构化沉淀团队规范、制度、实践经验，保证了团队信息的准确性和正确性； PingCode Goals：让所有项目都聚焦于共同的目标，并在更高视野上及时了解企业目标进展； PingCode Flow：提供自动化技术，将重复性和烦闷的手动操作变成自动化执行，让团队专注高价值生产； PingCode Insight：通过数据驱动的方式更加准确地评估和改善研发效能； PingCode Access：集成企业级帐号目录和支持单点登录，实现全局统—安全管控； 应用市场：帮助团队集成现有工具，实现数据信息的同步。 结语 Ship 的发布也意味着 PingCode 与 Atlassian 的差异化会更大。 因为在过去，PingCode 与 Atlassian 的差异可能更多地体现在产品体验、易用程度、更适配中国产研团队等。 而在 Ship 发布以后， PingCode 把软件研发过程、需求的生命周期又往前推进了一步，PingCode 真正具备了以客户为中心的需求管理能力。 在 PingCode，我们不仅仅是创建了一个管理产品团队的工具，来获取客户反馈并将客户数据嵌入到产品管理过程中，我们自己也在亲身使用这些方法。 用 PingCode 生产 PingCode，这确保我们自己的产品团队始终以客户为中心，理解更多客户和业务场景中的真实问题，并持续构建创新的功能和产品，以解决这些挑战。 我们相信，优秀的产品管理工具可以让企业在这个快速数字化转型的时代茁壮成长，更好地服务客户不断变化的需求。 如果您想了解您的业务如何从一个完整的产品管理流程中受益，或了解更多关于PingCode的能力，欢迎访问  PingCode 官网注册体验 ，或通过我们的 Ship 线上发布会了解。  

PingCode 入选“2022年度企服口碑产品TOP36”

11月30日，由36氪企服点评主办的年度口碑产品与标杆解决方案正式发布。在本次评选中 PingCode & Worktile 双双入选，并且 PingCode 凭借产品好评度与用户覆盖度优势成为唯一入选的软件研发项目管理工具，一同入选的还有飞书、可画、Xmind等产品。 36氪企服点评年度口碑产品是基于真实点评数据，在点评数量和分数的基础上，从产品好评度和用户覆盖度两大维度出发，形成口碑综合评分算法，计算出年度 Top 36 的口碑产品。 产品好评度是指用户提交的点评中对软件总体评价以及细分维度（包括功能满足度、易用性、售后服务的打分）所形成的综合分数。软件的点评综合分数并非所有单条点评综合分数的均值得出，每一条点评的权重会受点评发布时间、用户使用时长、团队规模、主观问题丰富度这些因素影响。 用户覆盖度是指软件的使用受众大小。用户覆盖度的主要依据为软件的点评数量，软件的点评用户的行业分布、点评用户的职位分布会对软件的用户覆盖度产生权重影响。 PingCode & Worktile 作为融合新型互联网技术的全新一代企业级研发管理与项目协作平台。 PingCode 旨在让软件研发管理自动化、数据化、智能化，帮助公司更快更好地交付产品，助力传统行业公司推动敏捷落地和数字化转型。在近几年 PingCode 已然成为国内发展最快的智能化研发管理工具，以客户为中心的产品理念、开箱即用的用户体验、逐渐成熟的产品体系收获了良好的用户口碑。在国产化替代浪潮中，PingCode 成为替代 Jira 的首选产品。 截至目前， PingCode 已服务超过6000家企业客户，包括比亚迪、宁德时代、小红书、51社保、易快报、来也科技、星思半导体、大普微电子、上海电银、宽带资本、中国科学院、北京大学等知名机构/企业，在行业口碑上，也整体高于行业平均水平。 Worktile 提供了丰富的自定义功能和日常办公应用，帮助各行各业的公司以目标驱动，更加敏捷地组建跨部门团队，共享信息，协同工作。作为国内最成熟的项目协作工具之一，Worktile 已经为超过60万家企业提供服务，是国内领先的企业级项目协作与目标管理工具。 在未来，PingCode & Worktile 将继续保持快速的更新与迭代，以持续的创新力为企业研发赋能，为用户输送更多价值。

PingCode 年度盘点：20大重要特性集锦

PingCode 作为国内领先的简单易用的新一代自动化、数据化、智能化研发管理工具，帮助企业提升研发效能是我们的使命。 过去一年中，PingCode 始终保持着高频率的产品迭代节奏，新上线子产品2个，累计发布238个版本，其中80个包含重大功能更新的次级版本，158个产品细节优化及稳定性升级的修订版本。 本篇文章我们将盘点过去一年中，PingCode 为用户带来的重要特性更新，希望这些新特性能在新的一年为你的团队带来帮助，真正提升团队的研发效能。 一、全新视觉升级 PingCode 自2020年发布以来一直保持着原有的视觉风格及信息架构，随着产品不断的迭代升级，基于用户的声音及产品未来规划，原有的视觉设计和信息架构无法支持产品的发展。在2022年6月，PingCode 进行了一次全新的视觉升级，重新定义了统一的导航区、操作区、数据展示区。 伴随着本次视觉升级，为了用户更好地理解并使用产品，我们也对产品中的概念进行了统一，形成了统一的配置中心，将分组、类别、Emoji 等能力应用到了全产品线中。 二、产品管理发布 目前市面上的研发管理工具，关注点都在于从需求到任务拆解、开发、编码、测试、最终发布上线的流程管理，忽略了产品型团队对于需求的收集、分析、评审过程。 PingCode 发布的“产品管理”子产品很好的弥补了这部分的缺失，它解决了从产品的视角如何进行需求的管理，包括： 需求收集：汇总来自于不同渠道的用户需求，进行条目化的管理 需求优先级：综合多种不同维度的因素，对需求进行优先级排序 需求排期：对需求进行优先级排序之后，如何进行排期，在什么时间节点交付 需求交付：确定好需求优先级和排期之后，交付到不同的研发团队进行具体的实现 三、效能度量发布 研发效能度量的过程实际上是把研发活动中产生的过程数据，进行加工与清洗，并且转化为可视化的信息，帮助团队进行效能分析与洞察。把数据转化为信息是这个过程中最有价值的环节，信息对用户是有意义的，而不是单纯的数据。 PingCode 推出的“效能度量”子产品，能够真正帮助企业更好地实施落地效能度量。如果你的团队在研发管理过程中使用 PingCode 产品矩阵中的其他子产品，如使用了“项目管理”子产品进行敏捷过程管理，使用“测试管理”子产品进行测试活动管理，这些子产品中产生的过程数据将会自动化地收集至效能管理工具中，并进行加工清洗，最终以可视化的效能仪表盘形式展现出来。 PingCode 中的效能度量报表都以效能仪表盘的形式展示，每个团队可以创建不同的效能视图，在效能视图下定义多个仪表盘，在每个效能仪表盘上支持添加不同报表，也可以针对每个效能视图设定不同的可见性，以满足团队不同角色所关注的效能度量指标。 四、瀑布模型发布 为了支持更多团队的研发管理场景，PingCode 升级了“敏捷开发”子产品为项目管理，新增了瀑布模型的支持，至此 PingCode “项目管理”子产品已经支持常见的三种研发管理模型：Scrum 开发、Kanban 开发、瀑布模型开发。 瀑布模型是一种将开发工作拆分阶段，并按序执行的研发模型，支持合理规划项目，对进度、成本与风险高度把控，主要包括： 项目规划：创建WBS，规划项目阶段、计划、任务、周期、资源、依赖关系 甘特图：可视化项目计划，呈现和管理项目进度、关键里程碑、资源、依赖阻塞点 里程碑：设置关键里程碑、规划交付物、执行进度跟踪，确保有节奏达成项目目标 交付物：规划交付物目标，提交并检查交付物，跟进目标达成情况，降低交付风险 工作项类型自定义：自定义工作项类型与信息配置，满足更多场景需要 五、协作空间支持讨论 帕特里克·兰西奥尼（Patrick Lencioni）曾经说过：如果你能让一个组织中的所有成员齐心协力，你就可以在任何时候、任何市场状况下、任何行业中纵横驰骋，战胜挑战。 2022年 PingCode 的子产品目标管理由原来单一的目标功能，升级为协作空间，并且上线了团队讨论功能，为团队成员提供一个开放平等的沟通空间，在这里团队成员可以随时就工作中遇到的问题求助其他成员，或者是分享自己对某个问题的解决方案。 未来一年协作空间将会支持更多新的特性，以保证跨职能的团队协作中下面的问题都能被解决，让整个团队可以步调一致的高效工作： 谁在为目标负责，以及目标的进展如何 我工作中遇到了问题，该向谁求助 我解决某个问题的方案如何提供给团队成员 其他团队/成员在做什么 谁擅长处理这个方面的问题 六、评论功能全新升级 评论是团队成员之间就具体的事项进行沟通交流的最主要渠道，也是贯穿于 PingCode 整个产品中最重要的全局能力，在 PingCode 中每一个基本元素都支持评论能力。 过去一年我们对评论功能进行了大幅升级，采用所见即所得的编辑器，同时增加了大量的新特性，至此 PingCode 中评论功能支持的特性如下所示： 支持文本格式设置 支持发送代码段 支持发送表情 支持@提及成员 支持#提及工作项 支持/快捷回复 支持添加页面/代码片段作为附件 支持评论置顶 支持已发送评论编辑 七、支持工作项本地化配置 项目管理中以前对于工作项的配置都是全局生效的，即修改了某个工作项类型的配置后，所有项目中的工作项都会同时生效，现在 PingCode 支持了项目内的本地化配置。 如果不开启则会默认使用全局配置，开启后将会使用本项目内的配置。而一旦开启项目本地化配置，全局配置的变更不会再影响到当前项目。这样可以极大地方便不同的团队根据自己的业务场景和使用偏好，进行个性化地项目管理配置。 八、支持工作项提醒与通知 现在 PingCode 支持在不同工作项类型上配置个性化的提醒及通知。工作项提醒用于在工作项的某个时间属性上设定好时间规则，在满足该规则后系统会自动发送消息提醒，如在工作项截止日期的前1天，在工作项开始日期过期2天后等。 工作项通知则是在某个属性发生变更时，或者某个动作发生时，由系统自动发送消息通知，如优先级发生了变化，或者工作项被删除、被归档等。工作项提醒及通知同时也支持在项目内开启本地化配置。 九、支持工作项工作流配置 工作项工作流用于定义工作项状态的改变规则，主要包括以下几个方面的定义： 工作项是否允许从「状态A」 变更至「状态B」 从「状态A」变更至「状态B」时只允许特定成员进行变更 从「状态A」变更至「状态B」时工作项属性需要满足一定的条件 目前 PingCode 提供了两条前置规则用于满足以上场景：配置变更的成员、变更状态时的属性验证。如果想实现在状态发生变更后进行一些后置操作，可以使用 PingCode 中的自动化规则实现。 十、支持空间可见性 在知识管理中，现在空间支持不同的所属位置以及可见性设置，当组织下一些规章制度放在公开空间中时，组织成员不用加入该空间也可以访问空间内容。同时空间也支持创建个人空间，不同所属和可见性对应的权限如下： 未来所属/可见性能力将会在整个 PingCode 中提供支持，如产品/项目/测试库等。 十一、支持思维导图 过去一年 PingCode 编辑器团队自研了极具扩展性的底层画图框架，并在此画图框架基础之上，实现了第一个应用：思维导图，以帮助组织成员高效地梳理结构、整理思路，目前思维导图基础能力已经完善，支持节点样式定义、布局等，未来还会提供更多关于思维导图的高级设置能力。 同时我们也会基于现有的画图框架，在此基础上提供更多实用的画图场景，如流程图等。 十二、页面支持图文混排 图文混排是指将文字与图片混合排列，文字可在图片左侧和右侧，围绕图片进行显示，丰富了图文的展示。 在页面中插入图片和输入文本内容，选中图片后根据需要混排的效果选择「图片居左」或者「图片居右」即可设置图文混排格式。通过图文混排，可以极大地提升页面的文档排版能力，编写更加专业的文档。 十三、页面关联能力增强 过去一年中，PingCode 对于页面的关联能力进行了增强，现在对于页面和页面之间建立联系，除了可以添加单个页面链接之外，可以直接插入整个空间的页面目录树，或者是部分页面目录树，以及加入当前页面的目录大纲；在页面和工作项之间的联系，除了加入单个工作项之外，也可以直接添加工作项列表。 未来 PingCode 还会继续加强页面和其他子产品中元素之间的关联，如在页面中关联产品需求、工单、测试用例、执行用例、目标等。 十四、报表支持多指标/多维度 研发效能度量本身是一个非常复杂的过程，在整个过程中要有系统性思维和全局思考能力，设计完善的效能度量指标体系。而往往单一的维度/指标无法进行有效的度量分析，需要综合多指标/多维度才能得出分析结果。 现在 PingCode 效能度量已经支持多指标/多维度，在设计报表时可以根据实际情况加入选择，另外多指标/多维度只对某些特定的图表类型支持。 十五、报表支持数据钻取 钻取分析指沿着特定属性维度的层次下降，获取更详细的数据。通常用于对某数据的不断细分，以分析在各种细分情况下的数据关系，找出影响该数据的根本原因。在实际度量过程中，我们可以采用按阶段下钻、按部门下钻、按聚合维度下钻等。 现在 PingCode 已经支持多维度的钻取分析，在配置报表时可以根据度量需求选择是否开启数据钻取。 十六、支持访客能力 访客能力适用于组织内部成员需要与有「合作」关系的外部人员之间进行协作，通常一个组织会和多个组织建立「合作」关系，如： 合作伙伴：如供应商、经销商、分销商、代理商、服务商、加盟商等，需要经常沟通协作 外包团队：如开发外包、测试外包等 现在使用访客能力可以让这些外部合作伙伴无缝与组织内部成员之间协作，并且外部访客的权限会受到一定的限制，除非授权否则无法看到组织内部公开的信息。 十七、支持安全水印 管理员在管理后台开启安全水印功能后，组织成员访问 PingCode 时所有界面将会显示配置好的水印图案，用于加强组织内部信息管理，防止截屏、拍照泄密等。 还可以根据组织需要，选择在全部产品中开启或者选择部分产品开启水印，以及自定义水印显示的文案，默认将会使用当前登录用户的姓名和手机号/邮箱。 十八、登录页和品牌配置 登录页和品牌是组织文化的一部分，现在使用 PingCode 后可以根据组织需要，使用企业专属的品牌 Logo 和组织文化图片，替换 PingCode 默认的 Logo 和文化图片，将 PingCode 配置为企业专属的研发管理平台，凸显品牌特色，全方位宣传企业文化。 自定义品牌： 十九、支持更多目录服务 为了帮助团队更好的使用 PingCode，解决团队内部多个不同系统之间的帐号管理问题，减少企业管理成员帐号的成本，过去一年 PingCode 先后支持了更多第三方目录服务，包括： SAML 2.0 CAS OAuth 2.0 这些目录服务已经在大量的客户场景中得到了落地和验证。 二十、全局 Emoji 能力 过去一年，PingCode 构建了统一的全局 Emoji 能力，在系统中每一个分组/类别、产品模块、测试模块、页面目录树等地方，你都可以使用 Emoji 表情替换默认的元素图标，让设置的分组/类别/模块等看上去更容易区分，也更有代表意义。 未来 Emoji 能力会作为整个产品的一项全局能力，提供更多适用的场景。 除了以上列举的重大发布和重要更新之外，过去的一年我们还发布了大量的其他更新，在产品的整体细节和易用性方面进行了很大的提升。 同时增加了更多自动化的场景，进一步减少重复的手工性的操作，节省用户的操作时间；在开放性方面新支持了大量的 REST API 接口，帮助团队通过编码的方式进行数据的获取与操作，以及进行原有工具链和 PingCode 之间的数据流转。 未来一年 PingCode 团队会继续秉持高频率的产品发布节奏，致力于让 PingCode 更加贴近研发团队的管理模式和习惯，提升产品的整体易用性，切实帮助研发团队提升效率，助力企业数字化转型。

Jira Server 产品终止支持进入倒计时

今天是2023年2月15日，距离 Atlassian 旗下 Jira、Confluence 等系列产品中国区 Server 版本终止支持正式进入365天倒计时。 在政策发布之初，我们曾详细解读并得出结论：中国用户3年之内影响可控，但要提早布局（原文见文末）。如今两年时间过去，寄希望于 Atlassian “回心转意”显然已无可能。 因为就在前不久，Jira官方在活动中宣称：在“2024年2月15日之后，您所使用的 Server 版本的安全漏洞将不再有官方的修复方案，产品的 Bug 也不再被修复。在支持日期结束后，Atlassian 和Marketplace 合作伙伴将不再为任何问题、安全更新或关键漏洞的错误修复提供技术支持。” 2021年2月，Atlassian宣布正式停售旗下Jira、Confluence 等产品Server版许可证，并于2024年2月15日终止Server产品的支持 伴随着中美关系日益紧张，Atlassian“强制上云”政策发布两年来，官方对中国区客户并未提供足够有诚意的解决方案，Cloud / Data Center 版长期存在的问题也并未得到解决： 致命的数据安全问题：Jira 在中国不设本地服务器，数据安全难以保障 非原厂服务：Jira 在中国本土不提供原厂服务，代理商服务陷入窘境 高昂的价格：Jira Cloud 版价格持续上涨，Data Center 版价格对500人以下客户极不友好 实质上，Jira 已经不再适合作为中国数字化企业的首选研发管理工具。 一、# PingCode 陪跑计划 #启动 PingCode 作为领先的国产研发管理工具，在 Jira Server 终止服务倒计时365天起，诚挚发出陪跑邀请，协助 Jira 老用户完成平滑过渡，研发效能提升不断档，迎接更加自动化、数据化、智能化的研发管理新篇章。 #陪跑Jira用户 针对Jira老用户，PingCode提供迁移、价格双重保障，解决后顾之忧： 数据迁移方案：PingCode 源生 Jira Importer 和Conflunce Importer 迁移工具，更有一对一个性解决方案，协助Jira用户完成数据迁移 陪跑特殊折扣：凡Jira老用户，无论Cloud/DataCenter/Server版，PingCode提供陪跑特殊折扣，降本增效

PingCode 第三届开发者大会成功举办

PingCode 开发者大会或许会迟到，但永远不会缺席。 原定于2022年10月24日举办的 “PingCode 开发者大会” 因疫情原因推迟，属于2022年 PingCode 开发者们的新知创想，不得不藏器待时。 2023新春伊始，万象更新，伴随着万物逐渐回归正轨，大会也于2月26日在北京奥北科技园成功举办！ 作为 PingCode 一年一度的知识分享盛宴，自 2020 首秀至今，已经成功举办三届。 本届大会，来自 PingCode 北京总部、西安研发中心等地的百名开发者齐聚一堂，一同交流分享最佳实践、个人成长、以及公司在新技术领域的应用和创新。 本届大会以“保持热爱”为主题，设7大主题分享及圆桌论坛，涵盖前端、运维、服务端等领域，聚焦开发者关心的热点技术和前沿技术，既有经验丰富的架构师开拓思路，也有最硬核的开发实践经验，深入浅出、干货满满。 主题分享精彩纷呈： 2023 再看状态管理 当下的前端应用不可能会脱离状态管理，对于我们这样的企业级应用更是如此，那么 React 从 Redux 到 Mbox 再到目前来看状态管理其实已经发生了翻天覆地的变化。本次分享分别介绍了状态管理常用的三种模式：函数式、依赖追踪响应式和函数响应式，通过 Redux、Mbox 和 RxJS 的示例形象的介绍每种模式的区别，以及对应的编程范式和哲学，当下状态管理的现状和困境是什么？Angular 框架和其它框架下状态管理的区别如何？作为开发者如何更好地解决企业级应用开发中状态管理的痛点？ ——徐海峰 服务端部署架构的演进之路 记录我们从物理机部署、容器化部署、Kubernetes 部署到 EKS 部署，每次选择的初衷和面临的困难，以及我们能看得到的未来。 ——孙敬云 WiredTiger-数据储存技术 浅析 WiredTiger 底层逻辑，以及如何在开发中正确且高效地使用 mongodb ，如：读写操作处理、checkpoint、数据压缩、数据回收等。 ——晏少文 Monorepo and its Friends 探讨 Monorepo，turborepo 和 nx，以及它们如何能够应用在服务端开发中。 ——徐子岩 从零打造现代化绘图框架 Plait 介绍 Web 前端画图领域主要的开源作品，它们的发展历程，可能会涉及流程图、思维脑图、画笔等方向，以及我们自研画图平台 Plait 的一些设计考量。 ——杨振兴 PingCode OLAP 从 0 到 1 分析常见的场景下OLAP方案的选择，以及我们自己方案选择的考虑和遇到的问题。 ——赵力 0-1 搭建 PingCode 性能测试 分享性能测试的相关知识、PingCode 性能测试解决方案，以及性能测试的未来。 ——张月青 除主题分享外，圆桌论坛也一直是 “PingCode 开发者大会”重要环节之一。在今年的圆桌论坛上，开发者纷纷就管理、发展、公司、技术前沿等方面提出自己的疑问。 比如： 为什么我们要构建自己的组件库？ 如何持续保持对技术的热情？ 如何持续打破舒适圈，保持学习的劲头？ 技术管理者应该如何兼顾各方工作？ ... 圆桌嘉宾 CEO 王涛、研发 VP 徐子岩、产品研发部总监徐海峰、效能研发部总监孙敬云围绕着大家的问题分别讲述了自己的经验、见解，为开发者们提供了一个学习和扩展视野，激发创新和灵感，深入了解公司的历史和规划的机会。 在圆桌论坛结束后，PingCode 还对过去一年中优秀讲师、技术传播者、文章作者进行奖励表彰，以感谢他们为团队带来的贡献。 知识的生发、分享、沉淀，不只发生在 1024 开发者大会，过去的9年里， PingCode 研发中心已经组织举行了过百场类似的技术型分享，通过不断地分享、学习、反馈，实现团队的持续成长和提升，对技术“保持热爱”，已经成为PingCode开发者的基因。 未来，PingCode 将继续加大技术创新力度，推动数字化转型，为客户提供更加优质的技术服务和产品。