Scrum对于开发人员本身的优势？[关闭]

Scrum是一种项目管理方法，您如何将其“出售”给对当前状况相当满意的团队中的开发人员？

对我来说，向我们的产品经理解释Scrum如何使他能够定期发布，修改需求并让团队首先专注于高优先级的故事似乎很容易。我发现很容易解释TDD或持续集成在开发人员的日常生活中带来了什么。

但是，如何说服开发人员接受Scrum？Scrum如何使他们的生活更轻松？

Scrum将为正在发生的事情提供更多的可见性。管理不善，最后一刻发生变化，承受压力以及开发人员通常会遇到的各种问题。

但是，它也将使拖延者，恶意开发人员，疯狂的个人主义者，……换句话说，不良开发人员具有很大的知名度。

Scrum是一把双刃剑

Scrum将为您带来解决这些问题的机会。这就是为什么它如此强大。

将大目标（“使软件完成”）分解为较小的部分（故事），并确定在当前sprint中应执行哪些任务，这将提高生产率并减少压力。当你明确知道你应该做什么，现在，几乎没有约的压力，你可以集中精力做的小片，而不是由大感觉整个淹没。

堆栈排名/积压使里程碑结束不再是行军

作为开发人员，我在软件开发中最常看到的“破坏性模式”是某些“外部控制器”（例如项目管理，执行管理）对“最喜欢的功能”不会使其成为事实这一事实感到非常兴奋。日历日期”，并下令进行死亡。

Scrum因为在待办事项列表中将“重要功能”排名很高，因此可以帮助开发人员以两种方式主动管理这种紧张状态。首先，您可以在待办事项列表中将“收藏夹功能”排名较高，以便他/她最有可能感到高兴。其次，它给出了一个非常直观和具体的答案：“由于我们将“闪烁小部件”移动到了第1位，因此很可能我们不会在此sprint中进入“弹跳小兔子”，因为它现在已排在第7位。您对此权衡感到满意吗？”

我还发现，对于短距离的冲刺，“外部控制器”对推迟工作的不那么沮丧。如果“闪烁小部件”直到9个月后才成为里程碑1和里程碑2才结束，那么“闪烁小部件”的赞助商就会非常沮丧。但是，如果“闪烁的小部件”在堆栈中的排名是7，而不是1，因为确实有6项重要的事情需要首先完成，那么这意味着我们可能会在sprint + 1或最差的sprint + 2中完成它。它将从现在开始显示12或18周（使用6周的冲刺）。以我的经验，耐心等待3个月是“可以接受的”-此外，回到3个月以上里程碑的“瀑布”模型中，

最后，如果我们要达到冲刺的终点并且事情花了比预期更长的时间，那么能够将积压的项目5-6-7推到下一个冲刺并确保我们已经完成了1-2-3，这是很好的选择-4质量高，每周工作70小时。毕竟，我们一定会在下一个冲刺中达到5-6-7。同样，鉴于推迟时间较短，“外部控制者”对此通常会比较自在，不要坚持要求我们将里程碑推迟两周并每晚订购晚饭“只是为了克服困难”。

Scrum团队中的人们可以自己决定很多事情：在下一个冲刺期间将做什么，我们如何在任务中打破这个故事，谁在做什么事情上等等。这赋予了他们权力，这几乎与微型机器人完全相反。 -管理。

从一开始就考虑到需求将改变的事实。开发人员无需使用精确的估算来创建详细的规格，然后花数周的时间开发功能，只需意识到客户一看到结果便改变主意...

对我来说，从开发人员的角度来看，您可以自行分配任务，这是开发人员最大的卖点。而且，与客户/产品所有者的亲密关系有助于理解更大的方案。

有两件事：

• 在Xavier关于需求从一开始就改变的观点的基础上，当每个人都从一开始就接受某些事情不会达到客户的期望时，就会形成一种政治气氛减少。快速的交付和审查将意味着错误沟通的成本很低，并且开发人员可以像客户期望的那样改变事物，使其发挥应有的作用，而不必玩责备游戏。

• 故事点！什么开发人员不喜欢在做事上获得积分！？！认真地说，这比在SC2或Stack Overflow中获得徽章要好。

作为一名开发人员，我对scrum有几件事。

开发人员往往会事先获得更多信息。产品负责人需要详细解释下一次冲刺期间将要完成的所有工作，以便进行合理的估算。

及时估计意味着该估计是相当准确的。每个人通常对冲刺将完成的事情都有一个相当好的想法。这为程序员和项目经理提供了可以克服不合理需求的工具。

每三到四个星期后退一步，屏住呼吸，至少要改变一下脚步，这是很好的选择。

自组织团队似乎给工作带来了更多变化。

至少从理论上讲，在冲刺期间，中断和“紧急情况”较少。

每天的站起来会议迫使程序员每天说几句话。

在每次冲刺结束时都明确地讲完故事并进行回顾时，很容易看到进展。

燃尽图表是跟踪进度的一种非常有效的轻量级手段。

开发人员的优势是早期反馈（来自客户，测试人员，产品负责人等）。

作为一名开发人员，我总是对分步做事感兴趣，不会分心。Scrum提供了这一点。

PS：混乱不是方法论，而是框架。