问题标签 [agile]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
architecture - 高级架构
即使您正在使用敏捷，在开始实施项目之前，您也需要一个高级架构。
通过高级架构，我的意思是将项目分成小部分，基础设施，分布式/基于网络/厚客户端等......
有没有关于这个主题的书籍/文章？
agile - Scrum 敏捷和 RUP 之间有什么关系？
敏捷与 RUP 之间存在关系。实际上，我认为敏捷开发是一种 RUP。在上面来自 IBM 的文章中，您可以看到他们正在将模型拟合到 RUP。
有人对这三个有趣概念之间的关系有任何实际的解释吗？
agile - 敏捷（Scrum）采用——进展如何？
对于在您的组织中实施 Scrum 的人来说，您最大的障碍是什么？如果您确实克服了这些障碍，又是如何克服的？
agile - 是否可以在 SCRUM 流程中担任多个角色
您认为一个人在想要使用 SCRUM 的软件开发公司中担任多个角色是否可行？
例如，如果一个人是
- SCRUM 大师和团队成员
- 产品负责人和团队成员
- SCRUM 主管和产品负责人
你认为哪些组合是可能的？你在这样的团队工作吗？如果一个人有多个角色，应该考虑什么？
感谢您的任何提示。
project-management - 当您有多个项目时，Scrum 如何工作？
我对 Scrum 的好处和流程非常了解。我得到了关于积压、燃尽图、迭代、使用用户故事和其他各种 Scrum“框架”概念的想法。
话虽如此...我在一家网络开发公司工作，该公司一次管理多个项目，有六名团队成员组成“生产团队”。
Scrum 如何处理多个项目？您是否仍然只是在一定时间内为单个项目安排一次迭代，整个团队都在为此工作，然后在迭代完成后继续进行下一个具有新迭代的项目？或者是否有一种“敏捷”的方式来管理多个项目，同时只需要一个团队进行自己的迭代？
project-management - Scrum：太多还是不够？
我的公司最近开始使用 Scrum；我们已经完成了 2 次冲刺。我们仍在学习，但我们肯定已经暴露并修复了我们开发过程中的一些问题。所以总的来说，我认为这对我们有好处。
在阅读了许多来自布道者、愤世嫉俗者和介于两者之间的人的关于 Scrum 的互联网思考时，三个常见但有些矛盾的主题对我来说很突出：
- Scrum 实施失败的原因是 Scrum 的流程没有得到足够密切的关注。
- Scrum 实施失败是因为组织没有使 Scrum 适应自己的环境/文化/实践。
- Scrum 的过程并不重要；只有敏捷宣言中的价值观很重要。
这些示例可以在对这些 SO 问题的回答中看到：
我不得不承认，我们还没有遵循 Scrum 的所有指导方针：我们还没有在 sprint 结束时发布，我们的 Scrum Master 不希望我们在接近结束时将任务从 sprint backlog 中移出冲刺，以便他可以看到我们的计划偏离了多少（这意味着燃尽图永远不会变为 0），并且紧急的客户支持问题仍然具有破坏每个人计划的不可思议的力量，举几个例子。
我的问题是：在尝试解决这些和其他问题时，是尝试更接近官方 Scrum 流程，更好地接近我们的一些前 Scrum 流程，还是更好地思考 Scrum 的原则尝试想出一个完全不同的过程？
project-management - 对敏捷环境中的大型项目进行估算
我的公司刚刚收到了第一个大型开发项目的询盘，我想使用敏捷过程。客户对应用程序有远见，但公开承认要求很少，并承认我们将不得不按小时收费。正因为如此，我几乎把敏捷方法卖给了他。
问题是他想要一个数字来预算。我读过很多文章，它们几乎都主张不要放弃估算，因为客户会为这个数字做预算，即使需求发生变化，他们头脑中和书中的数字也不会改变。
我读过有很多方法可以在合同中考虑定价，但几乎所有方法（除了一个）都包含一个预先编号。这似乎违反了敏捷开发的整套原则。
所以我的问题是，如果您是敏捷开发者，您如何设法规避敏捷开发的 Catch-22？
agile - 已完成的用户故事 - 丢弃？档案？
我们开始使用 Scrum 流程进行开发。我们现在有很多用户故事。不过我想知道，一旦用户故事完成、测试和部署，你还会用它做其他事情吗？我们现在正在使用小索引卡，我认为将它们扔进垃圾桶就可以了。
如果你保留它们，你以后如何处理它们？
agile - 使用 Scrum 的敏捷方法相对于瀑布方法的一个优势
如果你必须选择 Scrum 相对于瀑布式流程的一项优势，你会选择什么？
project-management - 敏捷 - 任务分解 - 估计与否？
在我们的迭代计划中，我们经常发现自己和这个人处于同一个位置——如果你没有经验，如何估计一个编程任务
在您给出合理的估计之前，我绝对同意原型设计。但这同样适用于任何需要一点架构和设计的东西——但我不太愿意在 sprint 的范围内做这一切。
基本思想是，您尽可能多地确定您有信心的任务，并按照正常情况估计这些任务。对于那些你不确定的领域，应该确定两种“类型”的任务：调查和实施。
调查任务是对您不确定的工作的简要描述，例如“调查如何将 Control X 绑定到数据”。为这些提供了估计。
实施任务是传统的粗略猜测，可能基于分配的故事点，您认为实施该功能需要多长时间。
在 sprint 期间，当调查任务完成时，开发人员应该处于对正在发生的事情有更好了解的阶段。然后可以识别“适当的”任务，它取代了实施占位符。此外，在此阶段可能会确定进一步的调查任务，并继续循环。
在上面的示例中，我们从 7 小时开始的调查任务和估计在 14 小时的实施任务开始。一旦完成第一次调查，任务 1、2 和 3 将在一定程度上被识别和估计，其中任务 3是另一项调查任务，稍后将确定任务 4 和 5。如您所见，第一次实施估计在 14 小时内交付了该功能 - 但实际情况是至少需要 4 + 7 + 3 + 4 + 2 = 20。比最初的估计多三分之一。
替代文字 http://www.duncangunn.me.uk/myweb/images/estimate.png
欢迎所有想法 - 我的直觉是这会飞 - 我是对的还是我是错误的兄弟？
干杯!