即使您使用敏捷，在开始实施项目之前，您还需要一个高级架构。
通过高级架构，我的意思是将项目分成小部分，基础设施，分布式/基于Web /胖客户端等......
是否有关于此主题的书籍/文章？
答案 0 :(得分：4)
我不止一次与Kent Beck讨论这个问题，他会说你错了，你不需要做出这些架构决定，或者说你应该选择最简单的东西那可能会起作用并从那里开始。
我看到的问题是，在您发现STTCPW实际上不会工作之前，您可以走很长的路，并留下一个很多的返工。现在，如果你正在以增量方式正确地做事，或者更好地使用风险驱动的模型，那么你首先要检查最危险的决策，然后希望你会相对较早地发现这些事情，但肯定无法保证。
另一方面是，许多敏捷项目都处于预先确定大多数架构的环境中，例如Ruby on Rails或J2EE。这些系统可以大大降低风险，因为您有一个明确的环境。
我不知道有关这个主题的任何特定书籍，虽然我正在考虑写一个;这仍然是敏捷社区争论的焦点。
可能我最喜欢的论坛是Martin Fowler's blik我和InfoQ，但我要告诫他要开始发布到infoQ，因此可能会有偏见。
答案 1 :(得分：3)
关于这个主题的好文章是Martin Fowler的"Who needs an architect?"。
我个人认为，您可能需要预先做出比您想象的更少的架构决策。如果你做得足够合理，可以做得很好。
你 需要密切关注设计力量，并且要善于重构。您将希望尽早开始练习。没有预先建立一个架构应该给你很多机会。 ;）
你会做出错误的决定吗？是。是否需要时间来改变架构。肯定。
但是你也节省了很多时间，而不是试图预先建立一个架构。并且，因为在项目开始时您获得的信息量最少，所以前期架构不会真正“正确”。运气好的话，它“只是”过度杀戮，更有可能的是，也会做出更好的决定，以便你以后做出更好的改变。
关于风险，请记住您应该首先开始开发最重要的功能。这样，您的体系结构实际上将构建为最佳地支持最重要的功能，这正是它应该的方式。
你可能喜欢的关于这个主题的好书是罗伯特·马丁的“敏捷软件开发 - 原则，模式，实践”。
答案 2 :(得分：1)
在一般架构上，您有例如：
你有特定于平台的书籍，例如java：
维基百科有一个相当全面的software architecture指针列表。
答案 3 :(得分：1)
这是敏捷的关键问题，我认为还没有人解决它。最初的架构决策对于成功至关重要，正如Kent Beck所说，理想情况下，你会推迟他们，直到你有足够的信息。
他当然可以这么说，主要是因为他可以选择他的客户，并要求这种自由度。改进实施语言三个月后，对他来说可能没问题，但对于我们大多数人来说，这不是一个选择。我们必须尽早做出一些决定，而且必须做对。我们必须使用不充分的信息，并尽可能有效地利用我们的经验。
大多数建筑文本都有一个以表达所需功能的英语句子开头的过程，然后将名词和最终动词分解为分类器的语义表示，最终最终变成实际的代码行。
我们不能轻易地在敏捷中做到这一点 - 用户故事不适合分解，因为它们不够详细，我们没有任何其他功能要求来源。
在你至少编写了发布计划之前，我建议避免使用UML之类的东西（除了至少保留自己的笔记之外的任何东西），并且你已经知道哪些故事可能在迭代中实现。此时，您可以开始详细的架构工作。
在此之前你必须做出一些决定，我认为你能做的最好的事情就是试着确定你能做出的细节：
那种事。通常，这些约束可以在您预期的交付中充分包装，您可以对高级组件及其所在位置充满信心。
我强烈建议的是在用户界面上进行信息架构工作。 UI变得脆弱且价格昂贵，并且线框表示与完成的文章足够接近，可以与利益相关者讨论并获得有价值的答案。
您需要一位优秀的信息架构师，并且您需要定期挖掘用户故事中的IA变更，以确保其中的所有内容得到适当的估算。
对于非UI工作，请仔细考虑解决方案中的一些核心概念 - 即使您不知道具体是什么，通常也可以非常清楚地识别和说明交易边界和交易安全要求等事项。包含在每种类型的交易中。对交易和数据安全专门针对约束和成功标准做出一些陈述，并让利益相关方同意。
最后，在每次迭代开始时，您可以进行一些细节建模和体系结构工作，因为这里是真正的功能分解发生的地方。我强烈建议在预先迭代时加入这项工作。在迭代的实际编码开始时，您应该清楚地知道要创建的每个类，它将存在的位置以及它将与之交谈的内容。如果你没有这个，就不可能协调开发团队。
答案 4 :(得分：0)
听起来你正在讨论功能分解。
有自下而上和自上而下的方法。我喜欢从双方考虑一个项目。这一点尤为重要，因为当您从底部开始时，您可以考虑类及其方法。当您从顶部开始时，您可以考虑程序将如何流动。
尝试：
John Lakos的大规模C ++软件设计（Addison-Wesley专业计算系列）（平装 - 1996年7月20日）