-
![日事清刘磊：不忘初心，日事清为了什么而存在？]()
日事清刘磊：不忘初心，日事清为了什么而存在？
不忘初心，日事清起步阶段一无所有的时候，靠着要做一款好的效率工具的热情支撑着我们扛过了无数个艰难的时刻。厚积薄发，现在赶上了中国经济转型升级的数字化时代，更需要我们担当起重新定义中国效率的使命。
2019-07-15 15:00:15 日事清
-
![敏捷开发案例：Cisco通过规模化敏捷，提高生产力和提高质量]()
敏捷开发案例：Cisco通过规模化敏捷，提高生产力和提高质量
Cisco（思科）的IT不断寻找更快，更简单的新方法。作为其数字IT战略的一部分，思科云和软件IT（CSIT）希望采用更多敏捷开发作为通过持续交付新功能来取代定期主要版本的方法。改善团队协作和关注使所有团队成员能够查看当前项目状态，促进问责制，帮助三支团队超越自己的轨道，使团队能够自我管理
2019-07-12 16:58:03 敏捷案例
-
![敏捷开发管理的原则是什么？敏捷的原则在于项目、团队、企业的透明度]()
敏捷开发管理的原则是什么？敏捷的原则在于项目、团队、企业的透明度
-“如果你必须将敏捷提炼成一个原则，那么这个原则是什么？” 这是一个很好的问题，如此简单和又具有挑战性！说它具有挑战性是因为敏捷的原则取决于业务的背景和规模。 定义单一原则很困难，因为敏捷涉及到许多相互关联的原则和实践。 例如从团队背景出发：没有开放性和高效沟通的跨职能团队就无法协作并为客户提供价值，团队没有反思和适应就无法持续改进，没有卓越的技术团队就无法提供经常构建的优质工作软件。
2019-07-12 16:41:57 敏捷管理
-
![在 日事清 中使用甘特图来管理项目]()
在 日事清 中使用甘特图来管理项目
为了让项目办公室顺利运行，您需要正确的工具。这些关键的任务工具将用于追踪各部门的目标与指标。 您已知道日事清非常适用于团队管理工具，但您是否知道还可使用日事清来创建强大的项目管理工具？只需构建甘特图即可。
2019-07-12 16:28:34 甘特图 , 管理项目
-
![项目管理九大体系内容详解]()
项目管理九大体系内容详解
“项目管理是运用管理的知识、工具和技术于项目活动上，来达成解决项目的问题或达成项目的需求。所谓管理包含领导（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 故事点
