-
故事点:衡量scrum中工作总量的度量单位
故事点是用于表示完全实施产品待办项(productbacklog)项目或任何其他工作所需的总体工作量的估计的度量单位。
2019-06-27 17:34:23 故事点
-
Sprint评审/冲刺回顾中,除了新功能演示你还要做这三件事
如果参与者彼此不熟悉,产品所有者可能会让与会者简要介绍自己。在新产品开发计划开始时,自我介绍通常是一个好主意。产品所有者知道来自Marketing的Joe,但团队成员可能不知道。如果偶尔的新参与者参加sprint评论很常见,那么介绍也会很有帮助。也许来自市场营销部的乔只会参加两个评审会议,这是在团队致力于营销相关功能的冲刺之后。
2019-06-26 15:17:47 Sprint评审
-
如何衡量scrum团队的sprint冲刺速度?你需要明确定义「速度」
在非正式谈论它时,我将「速度」定义为衡量团队进展速度的一个指标。在大多数情况下,这个定义非常有效。然而,它会对计算scrum团队速度时应该考虑的一些细节产生混淆。这种混乱的出现是因为确实有两种更精确的速度定义方法。让我们看看它们是什么。1)速度衡量团队在sprint中提供的功能。2)速度衡量团队在sprint中将想法转化为新功能的能力。
2019-06-26 11:42:26 敏捷开发
-
实现成功的Scrum需要一些重要的仪式:Sprint计划、Sprint回顾、每日Scrum仪式
实现成功的Scrum需要一些重要的仪式。这包括Sprint计划、Sprint回顾、每日Scrum等等。通常会有很多关于谁参加、什么时候举行这些仪式、每个仪式需要多长时间、仪式的目的等等的困惑。
2019-06-26 10:53:46 scrum
-
你有没有在sprint评审会议中睡着过?让会议不再无聊的4条法则
你有没有在sprint评审会议中睡着过?我有过。但我可以想象它会发生。那么你会不会因为评审会议很无聊就跳过sprint评审会议呢?当然不不,但我被诱惑了。我怀疑你也曾经。我想分享四个问题,你可以问自己,以确保你的sprint评审会议永远不会是那种——让人们睡觉或让他们想跳过会议的类型。
2019-06-25 17:58:58 sprint评审会议
-
如何通过流程管理降低财务风险?这家公司这么做
本文所阐述的流程管理为中心并非所有的业务均需要流程建立、实施及再造等过程,要针对识别出来的关键业务和风险,确定对关键节点的控制,保持流程管控的适度性,合理控制风险。
2019-06-25 12:04:57 流程管理
-
日事清如何帮助个人做知识管理,从而推动组织知识创新?
之前我们总是说学习型组织,其实个人的知识管理和组织的知识管理是相辅相成的,甚至可以说,如果每个人都做好个人的知识管理的话,这个组织就已经是一个学习型组织了。
2019-06-21 11:56:00 个人知识管理
-
如何用日事清帮助企业进行知识管理?
在这里我觉的可以缓一下,先回顾一下,我们说了主要解决3个问题,竞争压力、工作复杂度提升、知识工作者,还讲了什么知识,知识是对信息的加工,是经过实践证明,可以用来引导决策和行动的,以及知识的两种分类,显性知识和隐性知识。
2019-06-21 11:53:32 知识管理
-
如何将知识管理应用到工作中,解决企业的问题?
对于初次接触或者没有深入过接触知识管理的人来说,有人会以为知识管理就是管理好文档,然后形成知识库。但其实并不只是这样,或者说知识管理很大程度上都不是在做这些收集、整理和归纳的工作。我们只讲知识管理最核心的东西,也就是围绕我们这个主题「用知识管理去解决企业中的问题」来讲。
2019-06-14 15:15:49 企业知识管理
-
在以下五种情况下,看板管理可能是比scrum更好的选择
一个真正敏捷的团队需要尝试很多方法,然后找出最有效的方法,而不仅仅是采用他们尝试的第一个方法。Scrum和看板不是竞争对手,他们是每个团队应该尝试的实验。 虽然这是真的,但我认识到许多团队的实验自由度有限。如果你为一个不能容忍小故障的组织工作,以发现生产力的巨大提高,我理解!如果是你,我愿意改变我关于处方的规则,并就我发现看板比Scrum更适合的五个条件提供一些建议。
2019-06-13 17:38:39 看板管理, 敏捷开发
-
如何使得「产品待办列表」(product backlog)小而且易于管理?
产品待办列表,英文是ProductBacklog,是指产品待办事项的集合,其中事务有优先级判断,先处理优先级高的事项。你应始终努力使产品待办事项(productbacklog)变得小而且易于管理。产品代办事项(productbacklog)中的项目太多,会出现三个问题:
2019-06-10 18:38:11 敏捷开发, scrum
-
ScrumMaster可以同时担任产品所有者吗?
如果你是团队的ScrumMaster,那么你就不应该成为团队的产品所有者(ProductOwner)。首先,产品所有者(ProductOwner)和ScrumMaster专注于Scrum项目的不同方面。产品所有者花费时间考虑要构建什么产品。而ScrumMaster的关注点主要是团队的能力,这也是产品是否能构建出来的关键。也就是说,虽然产品所有者决定团队要构建什么产品,但ScrumMaster需要帮助团队协同工作,确保构建的产品能建设出来。
2019-06-10 15:32:37 scrum