-
![敏捷开发管理的原则是什么？敏捷的原则在于项目、团队、企业的透明度]()
敏捷开发管理的原则是什么？敏捷的原则在于项目、团队、企业的透明度
-“如果你必须将敏捷提炼成一个原则，那么这个原则是什么？” 这是一个很好的问题，如此简单和又具有挑战性！说它具有挑战性是因为敏捷的原则取决于业务的背景和规模。 定义单一原则很困难，因为敏捷涉及到许多相互关联的原则和实践。 例如从团队背景出发：没有开放性和高效沟通的跨职能团队就无法协作并为客户提供价值，团队没有反思和适应就无法持续改进，没有卓越的技术团队就无法提供经常构建的优质工作软件。
2019-07-12 16:41:57 敏捷管理
-
![如何在敏捷项目中，进行项目治理和监督？]()
如何在敏捷项目中，进行项目治理和监督？
敏捷性和项目治理的概念并未从根本上相对立。每一种都是为了改善产品。 敏捷致力于通过密切合作以及时间限制冲刺的短期检查和调整周期来实现这一目标。 项目治理力求通过我们称之为检查和批准（或拒绝）检查点的方式来实现，其中将产品或项目与一组期望的属性进行比较。 然而，在追求类似目标的同时，敏捷和项目治理采用完全不同的途径来实现这些目标。正是在这些不同的路线中，两者混合时会出现问题。 幸运的是，双方的一些妥协，再加上这里的建议，可以带来敏捷性和监督的成功结合。
2019-06-28 14:59:11 敏捷项目如何进行项目监督
-
![在敏捷开发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评审会议
-
![在以下五种情况下，看板管理可能是比scrum更好的选择]()
在以下五种情况下，看板管理可能是比scrum更好的选择
一个真正敏捷的团队需要尝试很多方法，然后找出最有效的方法，而不仅仅是采用他们尝试的第一个方法。Scrum和看板不是竞争对手，他们是每个团队应该尝试的实验。 虽然这是真的，但我认识到许多团队的实验自由度有限。如果你为一个不能容忍小故障的组织工作，以发现生产力的巨大提高，我理解！如果是你，我愿意改变我关于处方的规则，并就我发现看板比Scrum更适合的五个条件提供一些建议。
2019-06-13 17:38:39 看板管理, 敏捷开发
-
![如何使得「产品待办列表」（product backlog）小而且易于管理？]()
如何使得「产品待办列表」（product backlog）小而且易于管理？
产品待办列表，英文是ProductBacklog，是指产品待办事项的集合，其中事务有优先级判断，先处理优先级高的事项。你应始终努力使产品待办事项（productbacklog）变得小而且易于管理。产品代办事项（productbacklog）中的项目太多，会出现三个问题：
2019-06-10 18:38:11 敏捷开发, scrum
