标签：
答：有两种场景：第一种场景是把软件分几个迭代，最后把软件和硬件一起集成；第二种场景是更好的一种场景，每几个迭代后，就把开发出来的部分软件和硬件在一起集成测试，不管这个硬件是开发了一部分或者是整体，软件完成后，在迭代末尾做一个更广泛的整体测试。总的来说，集成和测试越早开始越频繁越好。有个医疗仪器公司，他们有一个非常庞大复杂的系统，这家公司为了提高仪器质量，甚至改变硬件开发流程，把软件分成多个模块来开发。每开发一个模块就先测试这个模块，而不是像以前一样，把整体产品开发出来后进行一个大规模的非常昂贵的测试，导致发现缺陷比较晚。开发出来每个模块后就进行测试，开发出来几个模块后进行集成，这样效率和质量都提高。在产品开发中，不管是硬件还是软件，最大的问题是集成的问题。解决方案是迭代结束后就展开测试，集成测试越早开始越频繁越好。虽然集成是大问题，但是要做到每两个迭代就做一次大集成是很困难的。我们可以退而求其次，第一个阶段，提前一个月来做集成。如果渐渐觉得做的不错，可以提前两个月来做集成和测试，分步骤的循序渐进的做。还有一种情况是比较难做的，一个团队是瀑布式是开发，一个团队是敏捷迭代式开发，这两个团队就需要协商，瀑布式开发的团队需要把写代码和单元测试时间提前一个月进行。
如果Story依赖硬件，而硬件需要在版本后期才能完成，对于这种情况，前面的迭代Story没法交付，怎么办？如果把所有的Story累积到最后交付，不能做到持续交付，风险非常大。
一种办法是把Story拆分成两个，一个是可以在仿真系统或者老硬件上进行某某操作，另一个是在新硬件进行某某操作。前一个Story，可以在前面的迭代交付，后一个Story，只能等新硬件完成后才能交付。软件方面大部分的工作，都已经在前一个Story完成，后一个Story，主要是跟硬件的联调工作。
另一种办法是硬件提前开发；或者硬件分阶段开发，先提供DEMO板；或者先提供部分单板。这样Story实施时，相应的硬件已经具备，可以直接测试。
星期一就可以（注：我们的交流是在周四和周五进行的）。敏捷/精益思想的本质是持续改进。敏捷不是一天就可以做到，而是一个不断调整、不断适应的过程。当发现并标识出重点问题后，去解决问题才是关键。
这是一个误解，美国军方都已经修改了标准，在1994年12月，发布IID模型的498标准。但他们的失误浪费了全世界纳税人的钱，其他政府的修改要慢的多。美国NASA航天飞机软件的核心部分就是一个70年代迭代开发的成功案例，31个月，17次迭代，平均每8周一次迭代。
答：在迭代的早期，我们需要尽早的理解架构上的关键需求，这只是全部需求的一个子集，而且架构性的需求很多是非功能性的质量需求，如可靠性、安全性等，和功能性需求关系不大，容易把握。在迭代的中期，架构的需求和功能性的需求可以并行开发。
答：在敏捷方法中，架构团队是存在的，当然可以是虚拟的，也可以是实体的，各特性团队中的首席程序员/架构师会组成产品的架构团队，在迭代的早期参与架构的设计和开发工作，当架构工作完成后，他们又会回到特性团队中工作。在需要的时候，仍可以召集相关人员对架构进行讨论和优化。
标签：
原文地址：http://www.cnblogs.com/mikeyond/p/5071708.html
