2、项目相关专业领域工具：可能是 IT 项目的编程工具，或者房地产项目的建筑材料成本核算的工具，这些并不是项目的通用性的工具，而是某一个行业专家使用的特殊工具。

需求变更，相信大家一定都遭遇过，即使项目在启动时已经具备完整的需求，在项目启动后还是可能会变动。而且由于管理模型的不同，在项目启动后对需求变更会是件特别耗时费力的事。

出于员工的水平和沟通问题，也许国内有些人并不是那么相信敏捷，但是不得不承认，通过使用敏捷方法，国外的信息技术行业已经发生了翻天覆地的变化。在国外有数据统计，近71％的组织经常使用敏捷方法进行运营。 另一项调查显示，敏捷项目比传统项目成功率高28％。 这也表明了为什么敏捷在产品开发中更加流行。

自2020年11月5日起，25人以下研发团队，可不限时间、不限用量，免费使用PingCode所提供的Agile（敏捷开发）、Wiki（知识库）、Testhub（测试管理）、Plan（项目集）四款子产品，零成本实现研发全流程管理，降本增效。

在日常生活中，有种有趣的现象：我们更津津乐道于美好的故事，比如提到好莱坞，我们关注的只是大牌明星，却忽略了他们成名其背后的艰辛。对于那些成功的敏捷项目，也是如此。在我们见证成功的同时，却忘记了项目团队孜孜不倦的努力。而所有故事只有成功的那一面吗？No！也许消极的背面没有那么让人喜闻乐见，但是如果我...

虽然敏捷诞生只有20年的时间，但却帮助了很多企业取得了成功，在这期间也出现了各种敏捷方法论和思想体系，这篇文章，我们试图去讨论一个问题：对于准备实施敏捷的团队，在Scrum和Kanban两种方法之间如何选择？（特别说明：有人会说Kanban其实是一套思想体系，不是方法论，这里我们不想陷入概念之争，只想解释他们适用的...

从2019年初，我们团队准备开发一款适合研发团队使用的敏捷开发管理工具，那时候我们也在思考，到底什么样的工具才算是优秀的研发管理工具，研发管理的场景、方法和流派有很多，市面上关于研发管理工具的产品也是层出不穷，我们从哪里入手才能真正帮助研发团队提高研发效能？基于以下两点考虑，我们选择了从敏捷开发管理...

Worktile携手飞书，为企业用户提供敏捷开发服务，帮助企业实现软件项目的需求管理、缺陷追踪、迭代规划与推进以及效能度量等一系列工作，将敏捷贯彻到底，从而更好更快地发布产品。

故事点 是敏捷项目管理和开发中的一种抽象的度量单位，用于估计实现一个或多个用户故事的复杂度，它是对工作量的一种描述方式。一个故事点就是一个数字，透过这个数字告诉整个团队用户故事的复杂度。复杂度包括功能的难易程度、风险和花多大的功夫。

作为国内领先的企业协作工具，过去6年Worktile经历了中国SaaS跌宕起伏的蛮荒时代。当国内2C领域逐步布局成熟，巨头和资本也逐步将目光聚焦在2B这个万亿级大赛道，疫情期间和之后，都将加速企业服务的进程。Worktile作为新创公司，过往数年深耕团队协同赛道，品味了企业服务在不同周期下的酸甜苦辣。​过去6年，Worktile以...

无论作为产品用户还是管理咨询顾问，都非常非常喜欢微信。自认感情比较克制属于“高冷”挂，但从很多方面都太佩服太崇拜张小龙了（新书里微信也会是最喜欢的案例之一，真的不只是一个产品而已，很多方面都太牛了）。不知道大家是否有注意到，在疫情爆发后，微信的响应大概最快速也相对最到位的了，看一看立马有了“疫情专区...

2018年5月10日，敏捷宣言的发起人之一Ron Jeffries公开宣称“开发人员应放弃使用敏捷框架”。Ron Jeffries提到，诸如Scrum和看板之类的敏捷框架，与敏捷原则相差甚远，并不能为开发人员提供好的服务。他希望开发人员重新关注敏捷原则，并放弃使用这些敏捷框架。

正如 迭代、衡量和改进 是创造优秀软件的核心一样，团队及其工作方式也很重要。一个不尝试新事物的团队便会停滞不前，其团队工作方式也会成为“传统”。相反，一个乐于尝试新事物，摒弃传统并养成新习惯的团队会更有效率，并会在工作中获取更多快乐。

距敏捷开发宣言的发布已经过去了将近二十年，现在很多团队都在思考“敏捷”的工作方式。营销团队想要尝试Sprint的方式来加速盈利，运营团队正在采用Scrum敏捷项目管理，而人力资源团队则正在寻求如何为公司战略注入更多的灵活可变性。

看板方法起源于丰田精益，最核心的理念就是减少浪费。而精益生产分析技能在敏捷中的体现，就是“价值流程图”工具，可以帮助我们识别 7 大浪费，减少浪费就是在增加价值。7 大浪费如下，可用 WIDETOM 来便于记忆：

敏捷估算，就是在敏捷开发中，对即将开始的工作进行工作量、复杂度和持续时间的相对估算。通常情况下，软件开发过程中有很多未知数：技术更新，需求变更，系统之间的依赖关系等，它们都会影响估算结果，所以说估算是一项费时费力的工作，并且得到的结果也是不精确的。既然如此，我们为什么还需要进行敏捷估算呢？

经过近一年时间的打磨，Worktile研发产品正式发布啦！和以往Worktile版本升级不同的是，这是一个全新的产品形态，目前已上线 Agile（敏捷开发）、Pipe（持续交付）、Testhub（测试管理）、Trace（质量追踪） 四大产品，旨在实现产品研发全生命周期的管理。

官方《Scrum指南》中定义：Scrum Master在Scrum团队中属于服务型领导，负责践行和支持《Scrum指南》中定义的Scrum，要帮团队的每个人理解Scrum理论、实践、规则以及价值观。

一个产品有需求的提出、评审、确定，以及实际的开发测试和交付这几个阶段。从2001年敏捷被提出开始到现在已经有越来越多的项目在使用敏捷。现在的敏捷已经变成一种常态，这个时候讨论敏捷实践中被大家的忽略点就变得非常有意义。

会议，或“仪式”是敏捷开发的重要组成部分。作为重要元素之一，会议不应该脱离其他元素独立存在。（很多人倾向于在瀑布流项目中添加类似仪式，然后将其称为“敏捷”，这种做法根本就是无稽之谈。）下面，让我们来看看敏捷的这些仪式，了解它们如何实现团队赋权并推动敏捷的发展。

日本企业：我的第一份工作，我发现它这个文化，或者它这个流程设计的是和他们的特点非常相关，如果大家接触过日本，就会知道他们有一个特点，两个字—“变态”。

在印度有这么一个神奇的团队，他们有5000名左右的员工，每天要运送20多万份餐，一份盒饭要经过3-4个人的手才能抵达目的地，交通工具只有火车，自行车，板车和双腿，没有任何单据，甚至都不需要客户填写地址。

应Worktile团队之约，撰写了此文。我从来不喜欢敷衍了事，于是准备良久，回顾了这些年的点点滴滴，才成此文，以此祭奠那些年，项目管理之摸着石头过河的那些日子。

关于开发，我们已经有了太多的方法论和工具，这之间其实很难说哪个方法论是正确的，哪个工具是最好用的；其实开发是“任性的”，它没有定律，如人饮水冷暖自知，其过程是否高效，除了团队的内功实力这个决定性因素之外，还取决于整个流程是否是清晰的。高效总是伴随着清晰而来，清晰的目标，清晰的计划，清晰的职责……而这...