码迷,mamicode.com
首页 > 其他好文 > 详细

IPD模式下开展敏捷开发的一些问题汇总

时间:2015-12-24 00:37:27      阅读:148      评论:0      收藏:0      [点我收藏+]

标签:

1、      我们现在普遍用的是老系统情况下,什么时候把软件和硬件在敏捷项目里面集成?

答:有两种场景:第一种场景是把软件分几个迭代,最后把软件和硬件一起集成;第二种场景是更好的一种场景,每几个迭代后,就把开发出来的部分软件和硬件在一起集成测试,不管这个硬件是开发了一部分或者是整体,软件完成后,在迭代末尾做一个更广泛的整体测试。总的来说,集成和测试越早开始越频繁越好。有个医疗仪器公司,他们有一个非常庞大复杂的系统,这家公司为了提高仪器质量,甚至改变硬件开发流程,把软件分成多个模块来开发。每开发一个模块就先测试这个模块,而不是像以前一样,把整体产品开发出来后进行一个大规模的非常昂贵的测试,导致发现缺陷比较晚。开发出来每个模块后就进行测试,开发出来几个模块后进行集成,这样效率和质量都提高。在产品开发中,不管是硬件还是软件,最大的问题是集成的问题。解决方案是迭代结束后就展开测试,集成测试越早开始越频繁越好。虽然集成是大问题,但是要做到每两个迭代就做一次大集成是很困难的。我们可以退而求其次,第一个阶段,提前一个月来做集成。如果渐渐觉得做的不错,可以提前两个月来做集成和测试,分步骤的循序渐进的做。还有一种情况是比较难做的,一个团队是瀑布式是开发,一个团队是敏捷迭代式开发,这两个团队就需要协商,瀑布式开发的团队需要把写代码和单元测试时间提前一个月进行。

2、      Story依赖硬件怎么处理

如果Story依赖硬件,而硬件需要在版本后期才能完成,对于这种情况,前面的迭代Story没法交付,怎么办?如果把所有的Story累积到最后交付,不能做到持续交付,风险非常大。

一种办法是把Story拆分成两个,一个是可以在仿真系统或者老硬件上进行某某操作,另一个是在新硬件进行某某操作。前一个Story,可以在前面的迭代交付,后一个Story,只能等新硬件完成后才能交付。软件方面大部分的工作,都已经在前一个Story完成,后一个Story,主要是跟硬件的联调工作。

另一种办法是硬件提前开发;或者硬件分阶段开发,先提供DEMO板;或者先提供部分单板。这样Story实施时,相应的硬件已经具备,可以直接测试。

3、      在产品架构烂、自动化测试程度低、人员技能低的情况下,我们什么时候可以开始实施敏捷实践?

星期一就可以(注:我们的交流是在周四和周五进行的)。敏捷/精益思想的本质是持续改进。敏捷不是一天就可以做到,而是一个不断调整、不断适应的过程。当发现并标识出重点问题后,去解决问题才是关键。

4、      华为的设备是电信级的高可靠性设备,只有Internet产品才适合迭代开发。

这是一个误解,美国军方都已经修改了标准,在1994年12月,发布IID模型的498标准。但他们的失误浪费了全世界纳税人的钱,其他政府的修改要慢的多。美国NASA航天飞机软件的核心部分就是一个70年代迭代开发的成功案例,31个月,17次迭代,平均每8周一次迭代。

5、      迭代开发如何做架构?不分析完所有需求,架构能稳定吗?

答:在迭代的早期,我们需要尽早的理解架构上的关键需求,这只是全部需求的一个子集,而且架构性的需求很多是非功能性的质量需求,如可靠性、安全性等,和功能性需求关系不大,容易把握。在迭代的中期,架构的需求和功能性的需求可以并行开发。

 

6、      按特性组建开发团队,谁来做架构?谁来考虑共享?

答:在敏捷方法中,架构团队是存在的,当然可以是虚拟的,也可以是实体的,各特性团队中的首席程序员/架构师会组成产品的架构团队,在迭代的早期参与架构的设计和开发工作,当架构工作完成后,他们又会回到特性团队中工作。在需要的时候,仍可以召集相关人员对架构进行讨论和优化。

 

IPD模式下开展敏捷开发的一些问题汇总

标签:

原文地址:http://www.cnblogs.com/mikeyond/p/5071708.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!