worktile

3 月，跳不动了？>>> 故事点 是敏捷项目管理和开发中的一种抽象的度量单位，用于估计实现一个或多个用户故事的复杂度，它是对工作量的一种描述方式。一个故事点就是一个数字，透过这个数字告诉整个团队用户故事的复杂度。复杂度包括功能的难易程度、风险和花多大的功夫。 故事点（story point）和预估时间（estimated）不一样，故事点是一种相对的估计，它并不能和类似“人/天”这样的单位画等号，因为每个人完成同样复杂度的工作所需的时间是不同的。我们举个例子说明一下： 假设T团队有A、B、C三位员工，A君的能力是B君的2倍，B君的能力是C君的2倍（能力是不能这样对比的，这里只是方便说明问题），T团队约定10天为一个迭代，现在他们想计划一下未来的工作。如果按照预估时间的方式，一个用户故事B君觉得需要1天，A君觉得0.5天就可以，C君觉得需要2天，那么他们最终定多少呢？ 这里可能出现两种结果： 第一种结果，A君说这个我来做，写0.5天吧！如果按照这个方式，那么整个计划会议就演变成分工会议，A君挑若干的用户故事，自己进行估时，B君和C君也是如此，当每个人的总估时都逼近10天的时候，那么这个迭代的目标就确定了。这是很多团队实际采用的方式，看起来好像没问题，但是久而久之，这种方式的弊端就会显现出来。 自己干自己的，不关心全局的进展。既然每个人自己的工作内容都已经确定

2018年5月10日，敏捷宣言的发起人之一Ron Jeffries公开宣称“开发人员应放弃使用敏捷框架”。Ron Jeffries提到，诸如Scrum和看板之类的敏捷框架，与敏捷原则相差甚远，并不能为开发人员提供好的服务。他希望开发人员重新关注敏捷原则，并放弃使用这些敏捷框架。 我们询问了一些团队在实际工作中如何进行敏捷实践，希望大家在公开场合（互联网或社交媒体上）讲述他们的敏捷实践，以此进行一个大规模的敏捷回顾。我们将这次活动称为“Retro On Agile”。 我们想知道敏捷软件开发这种方式在哪些方面表现得比较好，又在哪些方面可以得到提升，希望大家可以分享他们在实践过程中遇到的困难，付出的努力以及收获的成功。 作为敏捷工具的开发者，我们需要收集这些反馈，以便更好地升级产品，为客户提供更好的服务。 实施敏捷后的反馈 在这次活动之中，大多数参与者都反应“敏捷”并未让他们的团队变得更好。 “虽然敏捷被定义为具体的方法论，但并未真正提高工作的效率。” “希望人们能更多的注重敏捷的原则和价值观，而不是专注于流程和方法论。” “能不能不将敏捷当做一个具体的执行方法？” “如果人们都能意识到敏捷中比站立会议更重要的是 敏捷原则 就好了…” 以上都是他们真是的反馈。与此同时，我们也收到了很多积极的反馈。例如： “我们团队的敏捷过程涉及了假设，实验，测试和执行，而不仅仅只是交付了。”

正如 迭代、衡量和改进 是创造优秀软件的核心一样，团队及其工作方式也很重要。一个不尝试新事物的团队便会停滞不前，其团队工作方式也会成为“传统”。相反，一个乐于尝试新事物，摒弃传统并养成新习惯的团队会更有效率，并会在工作中获取更多快乐。 目前，绝大多数研发团队都在使用敏捷方法。敏捷方法的优点在于， 它强调个人的互动高于严格的流程方法。 团队工作的重点在于完成事务的人，而不是团队规定的具体方法，因为流程方法可以随时进行调整并改进。另外，团队应该允许个人使用其习惯的做事方法。这样一来，团队也可以试着进行改变，这也是持续改进的重要所在。 建立更有效率的团队 如果团队曾经进行过回顾会议，那么就会了解到：什么事情是需要保持的，什么事情是需要停止的，什么事情是需要开始做的，了解这些会使整个团队运转得更好。 但是有时候，仅仅使用回顾会议还不够，团队需要更进一步的改进。 只对产生问题的地方进行优化调整不会有太大帮助。 正如修复缺陷后并不能得到一个新的功能一样，所以需要尝试更多改进的方式方法。 团队为了追求更高的效率，就应该尝试新的工作方式。例如：整个迭代都使用结对编程；一段时间内放弃协作工具，只使用纸制卡片；在公园中进行站立会议等等。无论这些事情会不会给团队带来更高的效率，但只要不断进行尝试，我们就会发现对团队有用的方法。至少可以消除一些对团队没有价值的仪式，这也算是一种改进， 消除浪费并提高效率。

今天是2月5日，春节假期结束后的第三天了。为了能够应对来势汹汹的疫情，众多互联网企业纷纷开启了远程办公模式。不知道各团队前两天的远程办公效果如何，我们 Worktile 管理层在大年初四就开始讨论远程办公的事情，并且将可能出现的问题都尽量提前想到并做了准备。从这两天实际执行的情况看，我所在的研发团队执行的还不错，基本没有受到什么明显的影响。因此我们希望将我们远程办公的一些思考、准备和实践分享给大家，共渡难关。 先简单介绍下，我是 Worktile 基础平台部的负责人，部门包括负责核心组件开发的平台组和负责线上及公司内部服务器管理的运维组。我们的运维团队一直都是一个分布式团队，成员包含北京和杭州，我本人之前也有几年跨国公司的工作经历，对远程工作并不陌生。接下来我想就以下几个方面聊一下我们 Worktile 研发团队是如何实施远程办公的。 明确远程办公的原则 首先，作为研发线的一名主管，我首先给自己明确了一条远程办公的原则——信任，并且首先是自上而下的信任。也就是说，远程办公首先要求管理者，无论是公司CEO还是普通的小组长，都要完全信任自己的团队成员是有责任、有担当，能够自觉的按时按质完成任务，能够主动沟通工作中的问题。只有基于这样的信任，远程办公才可能展开。否则，就会陷入到监视、控制、猜疑这种危险的状况中。所以，信任是远程办公的基础。 其次，任何一级的管理者都要以身作则

正如 迭代、衡量和改进 是创造优秀软件的核心一样，团队及其工作方式也很重要。一个不尝试新事物的团队便会停滞不前，其团队工作方式也会成为“传统”。相反，一个乐于尝试新事物，摒弃传统并养成新习惯的团队会更有效率，并会在工作中获取更多快乐。 目前，绝大多数研发团队都在使用敏捷方法。敏捷方法的优点在于， 它强调个人的互动高于严格的流程方法。 团队工作的重点在于完成事务的人，而不是团队规定的具体方法，因为流程方法可以随时进行调整并改进。另外，团队应该允许个人使用其习惯的做事方法。这样一来，团队也可以试着进行改变，这也是持续改进的重要所在。 建立更有效率的团队 如果团队曾经进行过回顾会议，那么就会了解到：什么事情是需要保持的，什么事情是需要停止的，什么事情是需要开始做的，了解这些会使整个团队运转得更好。 但是有时候，仅仅使用回顾会议还不够，团队需要更进一步的改进。 只对产生问题的地方进行优化调整不会有太大帮助。 正如修复缺陷后并不能得到一个新的功能一样，所以需要尝试更多改进的方式方法。 团队为了追求更高的效率，就应该尝试新的工作方式。例如：整个迭代都使用结对编程；一段时间内放弃协作工具，只使用纸制卡片；在公园中进行站立会议等等。无论这些事情会不会给团队带来更高的效率，但只要不断进行尝试，我们就会发现对团队有用的方法。至少可以消除一些对团队没有价值的仪式，这也算是一种改进， 消除浪费并提高效率。

前言：文章来自Worktile产品经理的产品需求管理经验分享。 作为B端产品经理，我接触过很多研发及产品团队，每个团队对产品需求的管理方法不尽相同，各有千秋。下面我来分享一下我司的产品团队是如何管理产品需求的，其实也就是一个产品需求在Worktile中的流转过程，希望我们的经验可以对各位有所帮助，也欢迎各路大神交流指点。 下面我通过需求流转的不同阶段来介绍我们如何做需求管理： 需求收集 管理需求的第一步首先是要进行需求的收集。我们的需求来源除了产品经理自己通过市场调研等各种渠道分析出的需求，来自用户的需求、建议、缺陷，都是由销售、客户成功的同事在一个公开的项目 （公共Backlog） 中提交，然后产品经理和设计师会定期对需求池的需求进行评审处理； 以下是在需求收集阶段我们会设置的一些关键属性： 1.需求描述 对于2B的产品需求，信息无非是角色、场景、原因、目的、预期这几点。但由于不同企业的角色、场景等信息复杂多样，所以无法形成统一的标准化数据来源，因此，我们规定以任务标题来描述需求最终的预期，其他必要信息通过任务描述来进一步补充； 2.功能分类 因为Worktile有“项目”、“消息”、“简报”、“网盘”等不同的应用，不同的应用是由不同的产品经理负责的，所以让需求提交人选择【功能模块】的原因是为了方便产品经理根据自己负责的应用筛选需求； 3.需求类型 新功能、交互优化、视觉优化

当前，似乎每个人都在践行敏捷。这主要归功于敏捷能够适应变化并整合客户反馈的特质。现代社会这两者是非常重要的，因为技术在不断地革新，且人们获取信息的方式越来越容易——包括公开的客户反馈。 快速响应并将客户反馈纳入产品和流程，要求自组织团队不断调整工作的内容以提高效率。团队可以进行定期调整以满足每天出现的新需求。在项目规划方面，这种波动环境可能会使事情变得棘手：因为几乎不存在明确的截止期限和可预期的交付成果。 因此，如果践行敏捷的基础正在快速变化，那么在不断迭代项目的同时，敏捷中如何定义完成？我们如何知道已经真正完成了任务？这是一个有趣的问题。在回答这个问题之前，让我们先了解关于敏捷及其方法论。 一、在敏捷中如何完成工作 简单来说，在项目管理中，敏捷用迭代方法来规划和指导项目过程，这将鼓励变革。这种方法与传统的项目管理方法（如瀑布式）截然相反，因为瀑布式设定了严格的流程和结构。 敏捷是为短时间内进行冲刺（sprint）的小团队设置的过程，可以帮助团队在项目中快速响应变化。小组在冲刺前后定期碰面，根据项目变化调整工作方式。 通过敏捷框架，团队才可能打造客户需要的产品，而不是闭门造车，交付不符合市场需求和趋势的产品。有了敏捷模式，在项目过程中，团队可随时根据需要进行调整工作，从而找到更好的路径去开发合适的产品。这将使得组织更具竞争力，但当存在无穷尽的功能更新和其他修复任务时