-
![项目管理九大体系内容详解]()
项目管理九大体系内容详解
“项目管理是运用管理的知识、工具和技术于项目活动上，来达成解决项目的问题或达成项目的需求。所谓管理包含领导（leading）、组织（organizing）、用人（staffing）、计划（planning）、控制（controlling）等五项主要工作。”而项目管理则又分为三大类：信息项目管理、工程项目管理、投资项目管理。
2019-07-12 15:36:53 项目管理
-
![任务紧、工作效率低？用日事清这款常用项目管理软件]()
任务紧、工作效率低？用日事清这款常用项目管理软件
如果只是你团队中某个成员效率低，你可以把锅甩给“90后”、““散漫、拖延、没效率“的标签，但如果整个团队效率低都效率低，那一定是团队管理leader的锅。 以我们团队内部做10万级企业用户项目的管理的软件，以及服务过的N多项目管理团队积累的经验，我是可以告诉你那些跑的快的公司是怎么解决的。 常用项目管理软件推荐：首先题主的问题：「团队都是90后，公司项目特别紧，团队效率很低」，其实属于项目管理的典型问题：各位PM应该不会陌生，以上项目管理的五大要素：成本、时间、范围、质量、风险。很多企业在项目开发过程中都会遇到时间、预算、人员配比等各种问题。
2019-07-11 18:08:10 项目管理
-
![如何在敏捷项目中，进行项目治理和监督？]()
如何在敏捷项目中，进行项目治理和监督？
敏捷性和项目治理的概念并未从根本上相对立。每一种都是为了改善产品。 敏捷致力于通过密切合作以及时间限制冲刺的短期检查和调整周期来实现这一目标。 项目治理力求通过我们称之为检查和批准（或拒绝）检查点的方式来实现，其中将产品或项目与一组期望的属性进行比较。 然而，在追求类似目标的同时，敏捷和项目治理采用完全不同的途径来实现这些目标。正是在这些不同的路线中，两者混合时会出现问题。 幸运的是，双方的一些妥协，再加上这里的建议，可以带来敏捷性和监督的成功结合。
2019-06-28 14:59:11 敏捷项目如何进行项目监督
-
![多任务是一个神话，并不能提高组织的生产效率]()
多任务是一个神话，并不能提高组织的生产效率
到目前为止，大多数人似乎都明白多任务是一个神话，并不能提高生产力。如果我同时尝试完成消费报告，打扫我的厨房并阅读昨天的体育新闻，无可否认，我会花更长时间给你写这篇文章。但我们尚未将这种想法扩展到我们的组织。
2019-06-28 11:19:19 多任务处理
-
![在敏捷开发scrum中，用户故事和任务有什么区别？]()
在敏捷开发scrum中，用户故事和任务有什么区别？
用户故事和任务之间有什么区别？嗯，这是一个简单的问题，我想。“差别是......，”我开始回答，团意识到它毕竟不是那么容易的差异。这两个术语“用户故事”和“任务”，他们看起来非常独特。用户故事在产品待办事项上，任务在sprint计划期间被确定，并成为sprintbacklog的一部分。这很好，但不是很有帮助-它就像是说“盐是盐罐中的盐，胡椒粉是胡椒研磨机中的东西。”当然，故事继续在产品代办事项上，而任务继续在冲刺代办事项上。
2019-06-27 19:13:12 待办事项
-
![对于Scrum团队来说，如何确定项目「完成DoD」的定义？可能你需要多级定义]()
对于Scrum团队来说，如何确定项目「完成DoD」的定义？可能你需要多级定义
对于Scrum团队来说，“完成的定义”已经成为一件近乎标准的事情。“完成”的定义（通常称为“DoD”）为要完成的项目确定了每个产品待办项必须是正确的。 典型的DoD类似于：
2019-06-27 18:51:48 scrum
-
![敏捷开发中，对于当下/非当下的任务的优先排序以及中期目标的制定]()
敏捷开发中，对于当下/非当下的任务的优先排序以及中期目标的制定
我希望对产品的发展方向有一个中期愿景。我发现三个月的维度很好。 在每个季度开始时，产品所有者应该定一个目标：“这是我们想要在三个月内需要完成的目标。”这个目标需要与团队和其他利益相关者共同完成的，但产品的最终愿景是由产品所有者决定。
2019-06-27 18:17:11 中期目标
-
![故事点：衡量scrum中工作总量的度量单位]()
故事点：衡量scrum中工作总量的度量单位
故事点是用于表示完全实施产品待办项（productbacklog）项目或任何其他工作所需的总体工作量的估计的度量单位。
2019-06-27 17:34:23 故事点
-
![Sprint评审/冲刺回顾中，除了新功能演示你还要做这三件事]()
Sprint评审/冲刺回顾中，除了新功能演示你还要做这三件事
如果参与者彼此不熟悉，产品所有者可能会让与会者简要介绍自己。在新产品开发计划开始时，自我介绍通常是一个好主意。产品所有者知道来自Marketing的Joe，但团队成员可能不知道。如果偶尔的新参与者参加sprint评论很常见，那么介绍也会很有帮助。也许来自市场营销部的乔只会参加两个评审会议，这是在团队致力于营销相关功能的冲刺之后。
2019-06-26 15:17:47 Sprint评审
-
![如何衡量scrum团队的sprint冲刺速度？你需要明确定义「速度」]()
如何衡量scrum团队的sprint冲刺速度？你需要明确定义「速度」
在非正式谈论它时，我将「速度」定义为衡量团队进展速度的一个指标。在大多数情况下，这个定义非常有效。然而，它会对计算scrum团队速度时应该考虑的一些细节产生混淆。这种混乱的出现是因为确实有两种更精确的速度定义方法。让我们看看它们是什么。1）速度衡量团队在sprint中提供的功能。2）速度衡量团队在sprint中将想法转化为新功能的能力。
2019-06-26 11:42:26 敏捷开发
-
![实现成功的Scrum需要一些重要的仪式：Sprint计划、Sprint回顾、每日Scrum仪式]()
实现成功的Scrum需要一些重要的仪式：Sprint计划、Sprint回顾、每日Scrum仪式
实现成功的Scrum需要一些重要的仪式。这包括Sprint计划、Sprint回顾、每日Scrum等等。通常会有很多关于谁参加、什么时候举行这些仪式、每个仪式需要多长时间、仪式的目的等等的困惑。
2019-06-26 10:53:46 scrum
-
![你有没有在sprint评审会议中睡着过？让会议不再无聊的4条法则]()
你有没有在sprint评审会议中睡着过？让会议不再无聊的4条法则
你有没有在sprint评审会议中睡着过？我有过。但我可以想象它会发生。那么你会不会因为评审会议很无聊就跳过sprint评审会议呢？当然不不，但我被诱惑了。我怀疑你也曾经。我想分享四个问题，你可以问自己，以确保你的sprint评审会议永远不会是那种——让人们睡觉或让他们想跳过会议的类型。
2019-06-25 17:58:58 sprint评审会议
