问题标签 [extreme-programming]

神话人月现在很经典，但“手术团队”方法仍然很有趣。哪种方法最接近它或具有相同的本质？

总结外科团队的类比：外科医生了解问题/业务领域并且是专家。当团队中有问题或冲突时，他们是权威。当出现问题时，外科医生之间会相互合作，比如设计，作为一个较小的紧密专家团队。所以本质上他们拥有领域的知识，被委托去做他们认为正确的事情，并做实际的编码？团队的其他成员专注于支持、测试、文档和项目计划，这些都是委派的任务。因此，外科医生也是最熟练/训练有素的资源。

答案可能是项目、编程、设计方法，因为它似乎对主要方法领域都有影响。采购开发中的敏捷、MDA、Extreme？这个问题对于复杂业务领域中的大型软件也更有意义，比如空中交通管制，而不是 COTS 开发人员或通用实用程序。

在设计后端系统时，你通常给你的故事和任务赋予什么粒度？

创建故事和任务的大多数示例通常以 GUI 应用程序为中心，故事是用户可以做的事情（例如，通过 ISBN 搜索一本书），每个任务都围绕启用此 GUI 功能。

在设计后端系统时，即没有用户界面而只是一堆与数据库、中间件等对话的服务时，您如何提出任务和故事？

几年来我一直在练习 TDD 和（一些）XP，并发现它解决了我在采用它之前在我的职业生涯中遇到的许多问题。通过消除如此多的头痛，我对编码的热爱重新焕发了活力。问题是我也发现很难找到利用这些实践的 .NET（我当前的堆栈）项目。

我对 SO 社区的问题是：您认为哪些社区（语言和/或框架）最接受敏捷实践，例如 tdd、（所有 xDD 真的）xp、ci 等？

要问这个问题，必须定义一种测量方法。我将为给定的社区/堆栈将其定义为：

（当前采用敏捷方法的项目数量）/（当前项目数量）

显然，如果没有可能不存在的数据，这是不可能确定的……我只是在寻找人们的看法

我最近一直在研究极限编程，想知道在我工作的地方实现它是否现实。

我的问题是，如果你向一个潜在的新客户推销，你告诉他们你正在使用 XP，并且你解释了他们作为客户的责任，如果他们有可能会推迟选择你的公司以前从未在 XP 环境中工作过？

鉴于在我看来这是一种客户密集型软件开发方法，人们向客户销售 XP 的经验是什么？这里的背景是向各种各样的客户销售大中型网站。

在他的应用极限编程一书中，Ken Auer 随便提到了一个 Enabler 模式。Kent Beck 也提到了它（至少在 2004 年 11 月 8 日的一封电子邮件中），但我无法在通常的地方找到任何细节（谷歌、c2.com 上的 wiki 等）

我在哪里可以找到更多信息？

我们有一个系统，除了 Java 代码之外还运行一些 Bash 脚本。由于我们正在尝试测试所有可能会破坏的东西，而那些 Bash 脚本可能会破坏，我们想要测试它们。

问题是很难测试 Bash 脚本。

有没有办法或最佳实践来测试 Bash 脚本？还是我们应该放弃使用 Bash 脚本并寻找可测试的替代解决方案？

诸如“将服务器从 v1 升级到 v2”或“提高启动性能”或“重构登录模块以降低代码复杂性”之类的技术项目是否应该进入产品 backlog，如果是这样，非技术产品所有者应该如何确定它们的优先级与其他功能更强大的积压项目相比？

是否应该有单独的技术资料积压？我们是否应该与两个可以在产品待办列表中优先考虑功能和技术内容的人共同担任 PO 角色？

敏捷/XP 可以与分层方法一起使用吗？

敏捷/XP 应该与分层方法一起使用吗？

将源代码分层需要额外的努力，从而显着增加开发时间。

注意：“层”是指带有 POCO、DA 等的单独组件。

我正在寻找专用于极限编程的 SaaS 协作工具。诸如带有积压日志、任务和项目管理、仪表板等的 SocialText 之类的东西……您正在使用哪些工具？

谢谢！

我来自 XP 背景。我非常了解这个过程，并且有扎实的工作经验。我发现它是开发软件的最佳方式。

我发现自己处于某种流程医生的位置，这产生了很多自我检查和对自己理解的重新评估。

我听到的一个很常见的事情是，有些作品不能变成故事。我个人不相信这一点。借口包括

1. 它太大了（开发人员在 5 周结束之前将没有任何东西可以显示）。
2. 这是一个复杂的算法或抽象概念（将需要 5 周的时间来编写并且什么都没有显示）。

这个问题是为了获得提示、提示或建议。

我正在寻找关于如何解决这些和类似的感知问题的提示、技巧和建议（如果你能想到的话，还有更多）。

我将标记关于如何绕过不会写故事的用户/开发人员的信息最多的答案，并解决他们为什么不写故事的许多借口（我只列出了几个，还有更多）。