本文综述了嵌入式系统敏捷开发(Agile Development),敏捷宣言,敏捷的原则,很多的敏捷开发的实践习惯,敏捷开发与瀑布开发流程的区别,敏捷的任务stories划分,并行开发、敏捷的时间安排,敏捷的通信交流方式等等。敏捷开发的其他别名包括极限编程(Extreme Programming),特性驱动的开发(Feature Driven Development (FDD)), 迭代式增量软件开发Scrum,完全清楚(Crystal
Clear)以及DSDM动态系统开发方法(Dynamic Systems Development Method)。
为什么嵌入式系统软件开发要采用敏捷开发呢?并不因为敏捷开发是现在的流行词,更重要的是因为敏捷开发能提高你的效率,基于计划驱动的实现方式会掩盖很多的问题,当你发现时也许就晚了。计划的开发并不能提供足够的自信来掌控产品的发布时间。软件开发项目往往受制于较长的开发周期、推迟的发布、无法预测的时间安排、较差的质量、不合客户预期等。这些所有的问题会构成一个正的恶性循环,如下图1所示。
模糊的需求
上面的恶性循环中有一些正反馈,如计划安排、修改缺陷、以及需求更改的恶性循环。这正是迭代实现的敏捷开发可以有效解决的问题。基于瀑布的软件开发流程定义需求-系统设计-测试-实现-测试-发布的实现听起来很诱人,但通过时间的考验证明往往不能满足需求。迭代开发,很多年以前就作为敏捷开发的重要的实践方式,从1987年Fred Brooks作为国防部军事软件开发上建议从瀑布流程转换成迭代开发开始就意味着瀑布模型在大型的DoD软件项目上的失败。在过去的十余年间,敏捷开发更多的是和软件开发联系在一起而不是和嵌入式,虽然嵌入式有其特殊性,但采用敏捷开发同样有增益,因为嵌入式开发也有同样的问题。
什么是敏捷开发?
敏捷宣言包括:
- 个体和交互胜过工具和过程
- 可以运行的软件胜过面面俱到的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
个体和交互胜过工具和过程
敏捷强调个人交互和团队合作的重要性,很多开发流程总是把人的因素从软件开发中排除,但是敏捷宣言的首要表述就是强调人和交互,工具是需要的,但是在团队中的人创造了成功的软件产品。
可以运行的软件胜过面面俱到的文档
第二点是对开发流程的度量,文档也许有价值,但可以工作的软件更有意义。但敏捷也并不意味着不写文档。只是说文档需要时间来写和维护,很多时候文档只是因为我们的流程需要文档而已,而敏捷开发者则能度量写文档的意义,而创造客户需要的文档。外需要记住的是文档并不能表明项目进度的,敏捷开发则是当50%的项目特性实现时才算项目50%完成了。虽然嵌入式软件只和硬件一起交付一次,但并不表明不能用特性来跟踪进度。
客户合作胜过合同谈判
这点是强调和客户的紧密合作。客户的交互很重要是因为软件很难在初始时就能确定具体的特性和features。需求和市场往往瞬息万变,客户早些介入很更好的表明他们的需求。
响应变化胜过遵循计划
最后一条是对现实中的复杂情况的应对。计划很重要,但是情况变化很快也需要经常的变换,但这并不意味着敏捷开发没有发布的日期,而日期和承诺在敏捷开发中看的很重。敏捷开发者会在短的时间周期内来度量和计划的一致性。
敏捷开发的基本原则:
- 优先级最高的,通过早期和持续交付有价值的软件来满足客户;
- 欢迎变更需求,即使在开发的后期提出。敏捷过程为客户的竞争优势而控制变更;
- 以两周到两月为周期,频繁地交付可运行的软件,首推较短的时间定量;
- 在整个项目过程中,每一天开发人员都要和业务人员合作;
- 由个体推动项目的建设,为个体提供所需的环境,支持和信任;
- 在开发团队中或开发团队间传递信息的最为有效和高效的方法是面对面的交谈;
- 衡量进展的重要尺度是可运行的软件;
- 敏捷过程提倡可持续的开发;
- 发起人,开发者和用户应该步调一致;
- 不断地关注技术上优越的设计会提高敏捷性;
- 简洁是最重要的,简洁就是尽量减少工作量的艺术;
- 最佳的架构,需求和设计来自于自组织的团队;
- 团队要定期反省如何使工作更有效,然后相应地调整行为。
迭代开发
敏捷开发是一种迭代和增量开发(iterative and incremental development (IID)),IID通过把项目分割成一各个的2周到4周的迭代周期来获取反馈信息,每次迭代输出的都是可以工作的软件开发结果。每次迭代相当于一个单独的项目,能发布一个可以应用的产品。当然在初始的迭代中,也许只能看到软件在测试环境中的情况或者原型。敏捷开发中的成员角色分为客户和开发者,客户定义和测试产品,开发者创建产品。入式软件工程师需要理解反馈,设计的控制系统通常都有反馈机制来让系统可控。基于迭代的敏捷项目能提供对项目至关重要的参数,如进度安排、需求和设计。把敏捷当做软件开发的控制系统好了。项目预测、计划和组织工程为若干个迭代。发布的节奏有利于建立一个可以测量的速度,从而校正开发计划,监控进度。如每次迭代完成20个点,而挤压的工作有200个点,那么可以说10次迭代完成工作。如果要求在8次迭代完成,那么就需要增加人手,消减功能或者加班了。