Kick-off Meeting有的翻译为项目启动会议，也有的翻译成开工或者开踢会议，这不重要，明确这个英文名字即可，不用管如何翻译。该会议是PM激励其团队的最佳机会。 在这次会议上，项目管理人员可以建立共同目标，并开始了解每个人。
例2 场景：你选择了使用三个小团队的方式。不过观察一下sprint中的交流方式，你就会发现团队1和团队2一直在交流，而团队3比较孤立 解决办法：如果团队1和团队2在整个sprint中一直聊来聊去（把团队3扔在一边），在下个sprint中你大概就得把团队1和2合并到一块。如果在sprint的前半阶段，团队1和团队2一直交流，然后在后半阶段，团队1和团队3又相谈甚欢，那合并或者保持原样就都是可行的。你可以在sprint回顾会议上提出这个问题，让团队自己决定
上篇文章《研发效能组织架构：职能独立vs业务闭环》介绍了职能独立型组织架构和业务闭环型组织架构的特点，优劣势。也许有的小伙伴可能对这两种组织架构没有深刻的体会，而本文就是想通过数据说话，想仅仅通过计算这两种组织架构下开会时间这一项，让大家知晓职能型组织架构带来的巨大沟通成本，也让大家清晰看到两个组织架构之间巨大的效率差距。
1. Scrum是经验型方法，是”可能性的艺术“ 2. Scrum使得所有事项充分可见，使“秘密交易”最小化 3. Scrum的运作基础是个人和团队的承诺，而非严密的规划及控制。相对于强行控制计划，其忠诚度、自组织和员工责任感是更为有效的机制 4. 团队成员只有事先集体负责，承诺在固定时间内交付实际产品后，才算真正掌握Scrum
在过去的 18 个月里，Argo 项目一直致力于提高整个平台的安全性。除了在 2021 年初完成安全审计，创建更好的安全响应策略，增加 Snyk 来扫描漏洞，现在实施模糊测试，该项目一直在改进整体的安全方法和姿态。安全不是你可以简单地附加到一个项目上的东西，它需要被嵌入到 DNA 中。在此，我们将分享这些更好的安全策略如何帮助我们以快速和负责任的方式响应CVE-2022-24348[1]。
大数据文摘作品，转载要求见文末 编译 | 大力、张家豪，ether、 田奥leo、宁云州 初创公司工程师团队的工作往往是从人数上开始出岔子的。 希拉里·克林顿总统竞选团队中的前任副CTO（首席技术官）Derek Parham如此描述工程师团队的合作问题。因为不了解团队之前的情况，新入职的工程师很可能会改写代码并搞砸一些工作。 工程师们的工作会有重合的地方，他们会在毫无意识的情况下处理相似的问题，因此宝贵的时间（尤其是对那些处理混乱情况的高级工程师而言）都被浪费了。 “随着工程师团队人数的增加和产品数量的
在蓝鲸项目经常能够听到这样的声音。这也难怪，团队大了，总有各种会议和讨论，沟通成本上升不少。但是我们不能只是抱怨，如何提高开会的效率才是关键。
每日站会，英文Stand-up，跟Scrum框架中说的Daily Scrum是一个事儿。
“我们的会议太多了！”作为分布式团队的领导者或成员，你可能经常会听到这样的抱怨。如果你上次听到这个词是在开会的时候，那没什么可奇怪的。大流行增加了我们参加会议的次数，而许多团队一直是采用以会议为中心的协作方法。
本文主要从Scrum的定义和目的、敏捷宣言、Scrum中的人员角色、Scrum开发流程、敏捷的12原则等几方面帮助大家理解Scrum敏捷开发的全过程。
成功的项目管理取决于整个团队对角色和职责的理解，使用责任分配矩阵定义角色是使项目保持在正轨并为成功做好准备的好方法。如果设计得当，责任分配矩阵能够促进项目的成功交付。
OA协同办公系统是高效工作流平台基础上，开发带有控制功能的OA办公系统、标准版功能模块：1、个人事务；2、工作流；3、行政；4、信息管理；5、人力资源；6、公文档案管理；7、系统管理。采用MYSQL数据库
回想起2006年的时候我手上最多的时候有11个项目在同时进行，同时我还要负责几个系统的用户支持工作，还要管理一个小团队的日常工作。那段时间真是有些超负荷运作，忙得是天昏地暗，不亦乐乎。
1. 请简述一下什么是敏捷开发（Agile Development），以及什么是持续集成。 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。、 持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的
敏捷开发（Agile）的核心是去中心化，扁平化结构，拥抱变化，习惯不确定性，当然，还有最重要的迭代。
敏捷是个方法论体系，在这个大的体系下有很多的分支，每个分支侧重或负责的内容有所不同，有的侧重研发管理，有的侧重工程实践。
来red hat两年了，想写点文章记录一下在red hat的所见所闻，应该会写成一个系列文章，每次分享3点，这是第六篇，主要分享以下3点：
公司越大，会议越多。这就导致员工白天工作的时间被占用。很多程序员都是白天开会，晚上干活，导致看起来每天加班都很忙，产出却并不多。在有些公司，这也是导致项目延期的重要原因之一。
时间已经过去几周了，最近实在是太忙；感想写得比较慢；说感想吧，想了很多，但写出来可能就一点了；
测试流程是整个测试过程中的命脉，也同时是指导整个测试团队的核心工作，所以在面试过程中也面试官们必问之题，但是每个公司的测试流程都不尽相同，比如有公司有完整的需求文档，有些公司需求却是零零散散，在测试过程中需求不断向产品，向开发求证。 很多公司虽然有需求分析，但是并没有需求评审，今天我先给大家讲一讲测试流程中的重点之一—需求评审，需求评审的好坏直接影响接下来项目的质量，这也是为什么大多公司都会做需求评审的原因。 评审发起人： 产品经理 评审参与人： 相关的开发人员，相关的测试人员，SQA 以上人员都是必须参加
微软的一群员工就忍不了，包括首席科学家Jaime Teevan在内的团队，拿715个同事做“标本”研究，写了一篇论文。
我们都会有好习惯和坏习惯，编程习惯也不例外。但是一旦你开始意识到自己的不良习惯，你就可以改变，并让自己更好。如果你要打破此列表中的这些不良习惯之一，它不仅仅能影响你，甚至可能还会影响你身边的人。
第4章 我们怎样制定sprint计划 sprint计划会议非常关键，应该算是Scrum中最重要的活动。只是它执行得不好，整个sprint甚至都会被毁掉 举办sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心 sprint计划会议会产生一些实实在在的成果 sprint目标 团队成员名单（以及他们的投入程度，如果不是100%的话） sprint backlog（即sprint中包括的故事列表） 确定好sprint演示日期 确定每日scrum会
本文转载自：腾讯小 Q 聊质量 对于如何主导一次事故复盘很有讲究和方法。对于主导事故复盘的人我们这里称其为“复盘owner”：有的公司是QA，有的公司是测试、开发或者其他角色来承担。 复盘的几个误区 复盘owner仅仅是个会议记录仪：参会的各个角色讨论，owner无法发表任何意见。 复盘到的原因不是根本原因：表面原因，解决不了问题。 主体责任方搞错了：后面又要拉起第二次复盘。或者一味的去追责任方的责任，而忽略了事故本身的原因分析。 改进措施非常难以落地：比如改进措施严重依赖人的自觉，或者实施高复杂度的流程
从差不多 2005 年一直到现在，我都在或多或少做着一些敏捷工作。而到了 2021 年的今天，我对敏捷的现状感到有些失望了。就像大多数踏入敏捷世界的人们一样，我过去和现在都是敏捷宣言的支持者。我个人尝试过 XP、Scrum、看板、SAFe、Scrumban，也看过很多人的经验总结，还参加过很多会议、看过很多 Youtube 的主题视频。有些人，比如说 Jez Humble 就曾试图解决我最熟悉的企业世界的问题，企业界也恰恰可能是我幻灭的起源。
做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律。 —— 侯世达，哥德尔、埃舍尔、巴赫 周三的下午，我像平常一样，写着代码听着歌，突然从天而降一份莫名其妙的故事列表，说让我给个人天，用来投标用。作为一个技术异常牛逼的高端程序员，这对我来说岂不是 A Piece Of Shit…哦不，Cake。拿着列表，打眼一看就知道是做什么 — 又是个审批流系统。注册、登录、忘记密码…这些也需要时间？！哦，还要做个SSO，可能要做点数据集成，给个15人天吧！又是一堆CRUD... CRUD
本文最初发表于 medium.com（《The Agile Developer’s Survival Guide for 2020》），由 InfoQ 翻译并分享。
内容来源：华为云 DevCloud 首席布道师 & 资深产品经理刘恒的技术干货分享。IT 大咖说（微信id：itdakashuo）经华为云和讲者授权发布，转载请标明出处。
我们的开源团队分布在世界各地，有着不同的文化，而异步决策过程是我们团队的关键推动因素。在这篇文章中，我将解释它在 ASF 中起作用的原因所在。
Scrum是敏捷过程中比较著名的一个过程框架，被很多团队采用。 Scrum使用迭代的开发方式，每一次迭代中，都会经历一个“计划->实施->验证->反思”的过程。这是一个开发过程，同时也是一个对项目的认识过程，这样的设计其实也是遵循了哲学的认知论. 名词解释： Sprint：每一次迭代称为一个Sprint。 Backlog：其实就是需求列表。 SM：Scrum Master，Scrum过程的管理者。 PO：Product Owner，需求他说了算。 TEAM：架构师、开发人员、测试人员等。 Chicken：其
现在公司在使用敏捷开发模式进行日常的开发和管理工作，所以我看了下Ken Schwaber的《Scrum Guide》这本小册子，原本是英文的，这里提供中文的，以供日后复习和参考。
作为神经计算和机器学习领域的顶级会议，每年的NeurIPS（神经信息处理系统会议）都会吸引不少中国学者投稿。今年的NeurIPS将于当地时间2019年12月8日-14日在加拿大温哥华举办。
一般来说，参加测试用例评审的人员包括对应项目的产品人员、设计人员、开发人员和测试人员。
开发团队是每一个产品经理和产品负责人的重要合作伙伴：是团队来设计和建造实际产品。但是，要高效地引导并与团队一起工作并不是一件容易的事情。这篇文章将分享8个使开发团队更高效合作的小技巧，从而提高创造成功产品的机会。
上一篇文章《 研发效能组织能力建设之特性团队FeatureTeam（上）》，我介绍了一个非常有意思且高效的组织模式-特性团队。首先介绍了为什么需要特性团队，特性团队的定义、核心价值、优势、可能存在的问题以及带来的成本。接着讲述了特性团队的适用范围，开发新产品、拓展新业务和产品快速增长的产品比较好。然后，我介绍了特性团队的两个角色 FTO 和 FT 队员；最后介绍了在一个大公司里如何多FT进行分工协作。看完这些你是否发现特性团队没有告诉我们在研发过程中如何管理需求，对外协调沟通，怎么开会，规范流程，跟进执行，项目状态如何可视化等。我通常是利用 Scrum 这个管理框架来完成这些事情的，这也就是本文我要介绍的内容。
来red hat两年了，想写点文章记录一下在red hat的所见所闻，应该会写成一个系列文章，每次分享3点，这是第七篇，主要分享以下3点：
今天邀请了腾讯社交网络质量部的高级工程师给大家做个分享，一起来看看我鹅内部对事故复盘的切身体会。 事故复盘(前、中、后)应该怎么做？ 作者：lu 姐 -----------------/ BEGIN /--------------- 拉起现网事故复盘对于互联网公司来说是家常便饭，但是如何做一次漂亮的复盘？通过复盘发掘产品或者项目真正的问题，并通过制定改进措施，促进各个角色配合起来解决问题，避免类似的事故重复出现。 尤其是一些影响面广、涉及部门和角色众多的事故复盘，怎样才能搞清楚，搞明白，搞的漂亮？ 对于
Time 1：2007年 比利时，一个沮丧的独立IT咨询师 DevOps 的历史要从一个比利时的独立IT咨询师说起。这位咨询师的名字叫做 Patrick Debois，他喜欢从各个角度研究IT组织。 2007 年，Patrick 参与了比利时一个政府下属部门的大型数据中心迁移的项目。在这个项目中，他负责测试和验证工作。 所以他不光要和开发团队（Dev）一起工作，也要和运维团队（Ops）一起工作。 他第一天在开发团队跟随敏捷的节奏，第二天又要以传统的方式像消防队员那样维护这些系统，这种在两种工作氛围的切换令他
在过去的几年里，机器学习得到了巨大的发展。但是，机器学习作为一门年轻的学科，其团队的管理方式却更加年轻。今天，许多机器学习经理被推到管理岗位是出于需求，或者是因为他们是最好的个人贡献者，而且其中许多人来自纯学术背景。在一些公司，工程或产品负责人被指派在没有任何机器学习实战经验的情况下构建新的机器学习功能。
越来越多的科技公司正在从传统的企业销售思路转变为以开发者至上的思路来推广产品。因为开发者不喜欢这类销售方式，所以电话销售和演示将不起作用。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
下午四点，Dawn 正忙于她自己的项目。这时她查看邮件发现有一条 Chatter 消息 @ 了她的团队，是关于一个最近移交给其他团队的项目的消息。从消息中可以看出其他团队发现 Dawn 的直接下属 Alex 提交的文件中有一个问题。但是Alex 今天提前下班去参加他儿子的钢琴独奏会了。Dawn 了解到这个问题必须要尽快得到解决，但是她又不想打扰正在观看儿子表演的 Alex。
老实说，这个问题还是蛮有意思的，因为日常工作中，我们参加的大部分会议相对来说没那么正式，也不会有太多人参加。一般能组织项目启动会的项目，都是比较大且公司较为重视的项目，初次参加除了新鲜感，确实也会有点紧张。
写了5年代码，年龄已近30，头发尚存几缕，除了写代码其他并无所长，职业未来在何方？
AI 科技评论按：计算机语言学和自然语言处理领域全球最顶极的会议 ACL，于 7 月 15 日-7 月 20 日在澳大利亚墨尔本召开。在大会的第二天（7 月 16 日），南半球的寒冬并没有削减学者们的热情，在早上的 ACL 主席致辞、Tutorial 和 Poster 论文讲解环节中，都爆满了不同年龄层的参与者。雷锋网发现，除了学校之外，学术机构和企业人士也是参加这场大会的活跃人群。
据 ICLR 官方推特最新消息，原定于 4 月 26 日于埃塞俄比亚首都亚的斯亚贝巴召开人工智能顶级会议 ICLR 2020 要通过各种可能的方法在今年举办一次远程会议。
我在多伦多的一家中型软件公司担任数据科学家。在过去的几个月里，我担任了三场数据科学职位面试的面试官，这三场面试分别面向数据工程师、数据科学家和数据科学QA。
本文要点 Big room planning是每季度举行一次的为期两天的计划会议，参与人员包括所有项目和团队成员 如果正确地推进，让100个或更多的人在一起做计划是可能的，有利的 人们一边在所在的团队中做计划，一边和其他团队协作计划 Big room planning让每个人有个总体了解，知道其他人在做什么，了解谁和谁之间有依赖关系 达成共识和总体方向（总体规划，the master plan）是一个成功的big room planning的先决条件 大规模计划 大规模计划，包括切片和总体规划，是帮助你应对
作为项目经理，我们经历了不同的项目，却总是受限于相似的困局。比如以下三个典型难题： 团队目标不一致 团队成员不熟悉 信息发布不流畅 倘若我们任由问题存在，而不在每次项目中进行总结和提炼，就会反复的徘
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
