2012-08-09 01:26:42 HarbinZJU 阅读数 2185
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10427 人正在学习 去看看 CSDN讲师

转自:http://www.infoq.com/cn/news/2009/02/agile-documents/

软件项目中有很多种文档,包括需求文档、设计文档、API文档、缺陷报告、进度报告、移交文档、验收文档等等。

 在传统的软件项目开发中,每个团队成员都要花费很多时间和精力去维护文档及填写各种表格和报告。第二条敏捷宣言是"可工作的软件胜于详尽的文档",据此很多人想当然认为敏捷开发不重视文档。更有甚者,有人为逃避写文档而借口敏捷开发不需要文档,成为所谓的PAP(Pretty Adventuresome Programming)。其实这些人忽略了敏捷开发中有很多实践(比如坐在一起、现场客户、测试驱动开发、客户测试、结对编程、信息化工作间等等),敏捷借助这些实践进行信息交流,起到了文档在传统软件开发中的作用。本文通过分析项目开发中的文档类型与作用来说明敏捷开发中为什么很多文档是不需要的。

首先,需要明确文档的用途,文档是用来交流信息的。关键是团队中信息分享是否及时准确,而这与文档的多少没有必然的联系。就比如James Shore在博文"文档之谜"(http://jamesshore.com/Blog/The-Documentation-Myth.html)里面指出的,很多人指责敏捷开发的文档不够。其实他们忽略了问题的实质,"丰富的文档并不一定是好事,能及时得到答案才是好的"(Myth: Document is good; Reality: Answer is good)。

专业知识或者信息主要分为两类:

  • 可以被整理,文档化的知识,一般只占所有知识的30%。
  • 占70%的存在于人脑中的隐含(Tacit)知识,只能通过人与人之间的交流来分享,口口相传。因此促进团队内部以及团队之间的交流对信息的传播更加有效。

软件项目文档通常有三种:

  • 项目文档,用于项目组内部信息交流,比如需求文档、设计文档、进度报告等。
  • 产品文档,通常是有业务价值的,是客户需要的,比如用户手册或者API文档。
  • 移交文档,在项目移交或者项目不同阶段之间移交的成果物。

产品文档是客户需要的,是产品的一部分,有业务价值,绝对不能省略。应该在迭代中为其安排一个文档任务。

从敏捷角度来看,另外两类文档中的很多种是可以简化或者省略的。

在敏捷开发过程中,

  • 整个团队坐在一起,移交文档变得多余了。精益思想认为移交(Transportation)是很大的一种浪费(参见Mary Poppendieck,精益思想的原则http://www.poppendieck.com/papers/LeanThinking.pdf),首先移交文档会花费很大的精力,其次很多信息会在移交过程中丢失,另外每个阶段还总会添加一些新的信息。所有团队成员(PO, Dev, QA, Doc)坐在一起,用白板进行面对面的沟通,既省时又省力,还有效。(参见Alistair Cockburn,敏捷项目中的沟通 http://www.agilemodeling.com/essays/communication.htm
  • Product Owner跟团队坐在一起,随时回答团队成员的需求问题,是活的文档。
  • 在Sprint计划会议中,团队选择要完成的用户故事(Sprint Backlog上的小卡片),形成Sprint backlog,这其实就是迭代计划。
  • 在发布计划会议中,Product Owner会确定发布内容,形成故事墙,这其实就是较为长期的开发计划。
  • Dev和QA一起设计客户测试(一般用Fit类工具)。重要的用户逻辑被设计成客户测试。这种需求(客户测试)是可以运行的,因此永远不会过时(如果出现问题,持续集成系统立刻就会发出警报)。这比传统意义上的需求文档要有效得多。传统文档有太多的问题,比如很少会有人去测试文档的正确性,很少有人去及时更新文档,很少有人去检查需求覆盖率(其实根本没有办法检查,很多工具想当然的提供一些从需求到实现的追踪,但这岂不又是一种形而上学?)。
  • 在开发中微观的具体的逻辑可以设计成TDD(或者BDD,行为驱动开发http://behaviour-driven.org/))的用例,起到了详细需求文档或者设计文档的作用。
  • 开发人员使用结对编程(很多好处,参见"我喜欢结对编程" http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/,以及 "结对编程:到底有多重要?"http://xprogramming.com/blog/2009/01/28/pair-programming-how-important-is-it/)。健康的系统架构应该是动态的,不断演进的。因此如果把它用文档固定下来,也会出现过期或者不全面的问题。在设计具体模块的时候,团队利用白板设计大体框架并确定方向,然后通过结对编程来具体实现。通过结对编程,可以很好的在团队中分享和演进系统架构信息。
  • 团队在每日站立会议中汇报进度,更新状态以及遇到的问题,所有信息会立刻反映到Sprint Backlog,Burdown chart以及各种图表上,成为信息化工作间的一部分,团队可以据此进行自我调整。
  • 每一次迭代之后举行反省会议,团队自我改进,也可以设计各种各样的手画表格(Ron Jeffries在个人网站上给了一些例子,http://www.xprogramming.com/xpmag/BigVisibleCharts.htm)来监控团队自身的问题。因此传统的审查及统计的文档就变得多余了。
  • 敏捷中高层次的需求通过愿景(Vision)文档体现,这种文档一般只有一页,变化的可能性不大,很容易维护。
  • 高层的系统架构图还是必要的。这种高层次系统架构变化的可能性也是很小的,维护成本也比较低。
  • 代码即文档。很多敏捷大师十分注重架构清晰度以及代码的可读性(比如Robert Martin总结的S.O.L.I.D原则,Robert Martin的Clean Code,以及Kent Beck的"实现模式")。在某种意义上我们写的代码其实就是指导计算机完成任务的式样书。式样书就是为了让别人容易读懂(要不然为什么不用二进制去编写程序,放到机器上就可以运行)。

正如James Shore总结的,获得信息的手段有很多。

最优的手段,代码清楚、单元测试完备、命名规范,因此根本不需要问;

其次,只需要问一下旁边的人,或者打一个电话,就可以立刻得到答案,这也就是为什么敏捷鼓励“坐在一起”和“现场客户”r;

再次,Google一下找到答案,这也不错;

……

很次,可以通过读文档找到答案。可是为了找到答案,需要读的文档越多,效果越差...

2009-03-10 16:18:03 garydoo 阅读数 90
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10427 人正在学习 去看看 CSDN讲师
[size=x-large]敏捷的文档
作者 滕振宇 发布于 2009年2月23日 下午8时42分

软件项目中有很多种文档,包括需求文档、设计文档、API文档、缺陷报告、进度报告、移交文档、验收文档等等。

在传统的软件项目开发中,每个团队成员都要花费很多时间和精力去维护文档及填写各种表格和报告。第二条敏捷宣言是"可工作的软件胜于详尽的文档",据此很多人想当然认为敏捷开发不重视文档。更有甚者,有人为逃避写文档而借口敏捷开发不需要文档,成为所谓的PAP(Pretty Adventuresome Programming)。其实这些人忽略了敏捷开发中有很多实践(比如坐在一起、现场客户、测试驱动开发、客户测试、结对编程、信息化工作间等等),敏捷借助这些实践进行信息交流,起到了文档在传统软件开发中的作用。本文通过分析项目开发中的文档类型与作用来说明敏捷开发中为什么很多文档是不需要的。

首先,需要明确文档的用途,文档是用来交流信息的。关键是团队中信息分享是否及时准确,而这与文档的多少没有必然的联系。就比如James Shore在博文"文档之谜"(http://jamesshore.com/Blog/The-Documentation-Myth.html)里面指出的,很多人指责敏捷开发的文档不够。其实他们忽略了问题的实质,"丰富的文档并不一定是好事,能及时得到答案才是好的"(Myth: Document is good; Reality: Answer is good)。

专业知识或者信息主要分为两类:

* 可以被整理,文档化的知识,一般只占所有知识的30%。
* 占70%的存在于人脑中的隐含(Tacit)知识,只能通过人与人之间的交流来分享,口口相传。因此促进团队内部以及团队之间的交流对信息的传播更加有效。

软件项目文档通常有三种:

* 项目文档,用于项目组内部信息交流,比如需求文档、设计文档、进度报告等。
* 产品文档,通常是有业务价值的,是客户需要的,比如用户手册或者API文档。
* 移交文档,在项目移交或者项目不同阶段之间移交的成果物。

产品文档是客户需要的,是产品的一部分,有业务价值,绝对不能省略。应该在迭代中为其安排一个文档任务。

从敏捷角度来看,另外两类文档中的很多种是可以简化或者省略的。

在敏捷开发过程中,

* 整个团队坐在一起,移交文档变得多余了。精益思想认为移交(Transportation)是很大的一种浪费(参见Mary Poppendieck,精益思想的原则 http://www.poppendieck.com/papers/LeanThinking.pdf),首先移交文档会花费很大的精力,其次很多信息会在移交过程中丢失,另外每个阶段还总会添加一些新的信息。所有团队成员(PO, Dev, QA, Doc)坐在一起,用白板进行面对面的沟通,既省时又省力,还有效。(参见Alistair Cockburn,敏捷项目中的沟通 http://www.agilemodeling.com/essays/communication.htm)
* Product Owner跟团队坐在一起,随时回答团队成员的需求问题,是活的文档。
* 在Sprint计划会议中,团队选择要完成的用户故事(Sprint Backlog上的小卡片),形成Sprint backlog,这其实就是迭代计划。
* 在发布计划会议中,Product Owner会确定发布内容,形成故事墙,这其实就是较为长期的开发计划。
* Dev 和QA一起设计客户测试(一般用Fit类工具)。重要的用户逻辑被设计成客户测试。这种需求(客户测试)是可以运行的,因此永远不会过时(如果出现问题,持续集成系统立刻就会发出警报)。这比传统意义上的需求文档要有效得多。传统文档有太多的问题,比如很少会有人去测试文档的正确性,很少有人去及时更新文档,很少有人去检查需求覆盖率(其实根本没有办法检查,很多工具想当然的提供一些从需求到实现的追踪,但这岂不又是一种形而上学?)。
* 在开发中微观的具体的逻辑可以设计成TDD(或者BDD,行为驱动开发http://behaviour-driven.org/))的用例,起到了详细需求文档或者设计文档的作用。
* 开发人员使用结对编程(很多好处,参见"我喜欢结对编程" http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/,以及 "结对编程:到底有多重要?"http://xprogramming.com/blog/2009/01/28/pair-programming-how-important-is-it/)。健康的系统架构应该是动态的,不断演进的。因此如果把它用文档固定下来,也会出现过期或者不全面的问题。在设计具体模块的时候,团队利用白板设计大体框架并确定方向,然后通过结对编程来具体实现。通过结对编程,可以很好的在团队中分享和演进系统架构信息。
* 团队在每日站立会议中汇报进度,更新状态以及遇到的问题,所有信息会立刻反映到Sprint Backlog,Burdown chart以及各种图表上,成为信息化工作间的一部分,团队可以据此进行自我调整。
* 每一次迭代之后举行反省会议,团队自我改进,也可以设计各种各样的手画表格(Ron Jeffries在个人网站上给了一些例子,http://www.xprogramming.com/xpmag/BigVisibleCharts.htm)来监控团队自身的问题。因此传统的审查及统计的文档就变得多余了。
* 敏捷中高层次的需求通过愿景(Vision)文档体现,这种文档一般只有一页,变化的可能性不大,很容易维护。
* 高层的系统架构图还是必要的。这种高层次系统架构变化的可能性也是很小的,维护成本也比较低。
* 代码即文档。很多敏捷大师十分注重架构清晰度以及代码的可读性(比如Robert Martin总结的S.O.L.I.D原则,Robert Martin的Clean Code,以及Kent Beck的"实现模式")。在某种意义上我们写的代码其实就是指导计算机完成任务的式样书。式样书就是为了让别人容易读懂(要不然为什么不用二进制去编写程序,放到机器上就可以运行)。

正如James Shore总结的,获得信息的手段有很多。

最优的手段,代码清楚、单元测试完备、命名规范,因此根本不需要问;

其次,只需要问一下旁边的人,或者打一个电话,就可以立刻得到答案,这也就是为什么敏捷鼓励“坐在一起”和“现场客户”r;

再次,Google一下找到答案,这也不错;

……

很次,可以通过读文档找到答案。可是为了找到答案,需要读的文档越多,效果越差...

[/size]
2019-08-07 15:20:05 u014519722 阅读数 35
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10427 人正在学习 去看看 CSDN讲师

在了解敏捷开发2.0之前,先来了解常用的4种开发模式

常用的4种开发模式

1.瀑布式开发

瀑布式开发是由WW.Royce 在1970年提出的软件开发模型,是一种比较老的计算机软件开发模式,也是典型的预见性的开发模式。在瀑布式开发中,开发严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤进行,步骤的成果作为衡量进度的方法,例如需求规格、设计文档、测试计划和代码审阅等。 瀑布式开发最早强调系统开发应有完整的周期,且必须完整地经历每个周期内的每个开发阶段,井系统化地考量分析所涉及的技术、时间与资源 投入等。
瀑布式开发的主要问题是它的严格分级导致自由度降低,项目早期即作出承诺会导致对后 期需求的变化难以调整且代价很大,这在需求不明晰并且在项目进行过程中可能有变化的情况 下基本上是不可行的。
在这里插入图片描述

2.迭代式开发

法代式开发也被称为迭代增量式开发,是一种与传统的瀑布式开发相反的软件开发过程, 它弥补了传统开发方式的一些弱点,有更高的成功率。在迭代式开发中,整个开发工作被组织 为一系列短小的、固定长度的小项目,每次选代都包括需求分析、设计、实现与测试。采用迭 代式开发时, 工作可以在需求被完整地确定之前启动, 并在一次选代中完成系统的一部分功能 或业务,再通过客户的反馈来细化需求,并开始新一轮的迭代。
在这里插入图片描述
特点:

  • 每次只设计和实现产品的一部分。
  • 一步一步地完成。
  • 每次设计和实现一个阶段,这叫作一个迭代。

3.螺旋式开发

螺旋式开发是由巴利 · 玻姆 CBa町 Boehm)在 1988 年正式发表的软件系统开发模型,它 兼顾了快速原型的法代特征及瀑布模型的系统化和严格监控,其最大的特点是引入了其他模型 不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减少损失。 同时,在每个法 代阶段构建原型是螺旋模型用来减少风险的方法。 螺旋模型更适合大型的昂贵的系统级的软件 开发, 一开始应用的规模很小,当项目被定义得更好、更稳定时逐渐展开。其核心在于不需要 在刚开始时就把所有事情都定义清楚,可以先定义最重要的功能去实现它,然后听取客户的意 见,再进入下一个阶段,如此不断循环、重复,直到得到满意的产品。螺旋模型在很大程度上 是一种风险驱动的方法体系,因为在每个阶段及经常发生的循环之前,都必须先进行风险评估。
在这里插入图片描述
特点:

  • 制定计划:确定软件目标,选定实施方案,弄清楚项目开发的限制条件。
  • 风险分析: 分析、评估所选方案,考虑如何识别和消除风险。
  • 实施工程:实施软件开发和验证。
  • 客户评估:评价开发工作,提出修正建议,制定下一步计划。

4.敏捷开发

敏捷软件开发又被称为敏捷开发,是一种从 1990 年开始逐渐引起人们的广泛关注的新型软 件开发方式,具有应对快速变化的需求的软件开发能力。它的具体名称、理念、过程、 术语都 不尽相同,相对于非敏捷开发,更强调程序员团队与业务专家之间的紧密协作及面对面沟通, 比单纯通过书面文档沟通更有效,能更频繁地交付新的软件版本,使自我组织、自我约束的团 队能够更好地适应需求的变化,也更注重软件开发过程中人的作用。
在这里插入图片描述
特点:

  • 首要任务是尽早地、持续地交付可评价的软件,以使客户满意。
  • 乐于接受需求变更,即使在开发后期也是如此。敏捷软件开发能够驾驭需求的变化,从
    而为客户赢得竞争优势。
  • 频繁交付可使用的软件,交付的间隔越短越好,可以从几个月缩减到几个星期。
  • 在整个项目开发期间,业务人员和开发人员必须朝夕工作在一起。
  • 围绕那些有推动力的人们来构建项目,给予他们所需的环境和支持,并且相信他们能够
    把工作做好。
  • 开发团队及在开发团队内部进行最快速、有效的传递信息的方法是面对面交谈。
  • 可使用的软件是进度的主要衡量指标。
  • 提倡可持续发展。出资人、开发人员及使用者应该共同维持稳定的开发速度。
  • 为了增强敏捷能力,应持续关注技术上的杰出成果和良好的设计。
  • 简洁,最小化那些没有必要投入的工作量是至关重要的。
  • 最好的架构、需求和设计都源于自我组织的团队。
  • 团队定期反思如何变得更有战斗力,然后相应地转变井调整其行为。

总结瀑布式开发:

对比以上4种开发模式,总结如下:

  • 瀑布式开发:在从需求到设计、从设计到编码、从编码到测试、从测试到提交的每个开发阶段都要做到最好,特别是在前期阶段设计得越完美,提交后的损失就越少。然而现 在的系统很复杂且多变,所以很难在现实中应用瀑布式开发。
  • 迭代式开发:不要求每个阶段的任务都做到最好,可以容忍一些不足,先不去完善它, 将主要功能先搭建起来,以最短的时间及最少的损失完成一个不完美的成果直至提交, 然后通过客户或用户的反馈信息,在这个不完美的成果上逐步进行完善。
  • 螺旋开发:在很大程度上是一种风险驱动的方法体系,因为在每个阶段及经常发生的循 环之前,都必须先进行风险评估。
  • 敏捷开发:和迭代式开发相比,两者都强调在较短的开发周期内提交软件,但是,敏捷 开发的周期可能更短且更强调队伍中的高度协作。敏捷方法有时被误认为是无计划性和 纪律性的方法,实际上更确切的说法是敏捷方法强调适应性而非预见性,适应性的方法 主要用于快速适应需求的变化。当项 目的需求有变化时,团队能够迅速应对新的需求。

DevOps

目前对 DevOps 有太多的说法和定义,不过它们都有一个共同的思想:解决开发者与运维 者之间曾经不可逾越的鸿沟,增强开发者与运维者之间的沟通和交流。
DevOps 是通过自动化的基本设施、自动化的工作流程和持续可测量的应用性能,来整合开 发团队和运维团队,以达到更高的合作效率和生产率。
精益管理的7个原则:

  • 消除浪费
  • 增强学习
  • 延迟决策
  • 快速交付
  • 团队授权
  • 内置完整性
  • 考虑全局
    DevOps可以用一个公式表达:
    文化观念的改变+自动化工具=不断实应快速变化的市场
    核心价值:
  • 更快速的交付,响应市场的变化。
  • 更多地关注业务地改进与提升。
  • 在这里插入图片描述

敏捷开发2.0

敏捷开发2.0是相对于敏捷开发而言地,敏捷开发意味着让我们全面拥抱需求地变化,但是对于瞬息万变地市场反馈还远远不够足以应对,因此为了更加快速地发现问题和得到市场地快速反馈,引入了持续集成(Continuous Integration,CI)和持续交付(Continuous Delivery,CD),来更加高效地进行敏捷开发,即敏捷开发2.0。

  • 持续集成:是一种软件开发实践,要求团队成员经常集成其工作,每个人至少每天集成一次会导致每天有多个集成。集成是通过自动化的构建进行验证的,这些构建运行回归测试,以尽快检测集成中的错误。团队慢慢会发现,这种方法有利于集成问题的大幅减少,更快地实现有凝聚力的软件开发方式。
  • 持续交付是在持续集成的基础上,将集成后的代码部署到更贴近真实的运行环境的预生产环境中。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中进行测试。如果代码没有任何问题,则可以继续部署到生产环境中 。
  • 持续部署:是持续交付的更高级阶段,即所有通过了自动化测试的改动都自动地部署到生产环境中。大多数公司如果没有受制度的约束或其他条件的影响,则都应该以持续部署为目标。 在很多业务场景里, 一种业务需要等待其他功能完成了才能上线, 这使得持 续部署不可能实现。虽然可以使用功能转换解决很多这样的问题,但并不是每次都会这样。 所以,持续部署是否适合某个公司是基于该公司的业务需求的,而不是技术限制。

敏捷开发 2.0 要求将大而全的项目拆分成小的相对独立的服务, 从一开始就不仅仅只关注自动化部署,还要关注整个项目是否具备自动化的、可快速扩展的、完善的容错机制,以及零宕机和便捷的监控管理。为了实现敏捷开发 2.0, 我们需要采用持续部署、 微服务和 容器这三种技术方案。

  • 持续部署:能够持续自动反馈应用程序的提交状态,减少错误等; 同时为产品的交付提供了质量保证,能快速投入市场。
  • 微服务:使技术选型、构架系统更自由;开发更快速、周期更短: 服务更容易扩展。
  • 容器: 使部署成百上千的微服务更加容易,系统更加稳定。

敏捷开发2.0流程

在这里插入图片描述

2018-10-06 07:42:27 yaojiawan 阅读数 388
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10427 人正在学习 去看看 CSDN讲师

瀑布模式和敏捷模式

     瀑布和敏捷模式是软件开发的两种方式,十多年前软件工程的书上介绍软件生命周期总是描述成“需求,分析,设计,编码,测试和维护几个不同的阶段。这就是瀑布模式(Waterfall Model),主张在动手编码之前,将所有的事情搞明白,编写详细的文档,很多开发人员好象是在开发文档,而不是开发软件,因为要到开发的后期,才可以看到软件的“模样”。

       瀑布模式能够保证软件的质量。它适合目标确定的软件开发,比如军事软件,汽车电子产品,仿制一个现有的产品。而且需要一位能力非常强大的系统分析员,编写出各种文档。

   但是当你开始设计一个创新的产品,或者为客户设计一个全新的产品,使用 瀑布模式就不适合了,比较再高明的系统分析师也不可能将事情完全想明白,况且客户对自己想要的产品也是模糊不清的。在提需求的时候往往像一个小男孩进入了玩具店,什么都想要。但是一旦产品出来后,又发现这些功能又不是它想要的。

  于是,人们又提出了所谓敏捷模式(Agile Model)。这里,我们谈谈在嵌入式系统开发中如何推行敏捷模式。

我们关心敏捷模式的另一个原因是 小团队本来就缺乏系统分析员这样的大牛。不如转向敏捷模式吧!

软件敏捷开发方法

网络上有大量关于软件敏捷开发的内容,好像都只是说一些概念。维基百科上讲的比较全面了,核心大约下面几点。

敏捷开发的理念

  • 个体和交互胜过工具和过程(Individuals and Interactions over processes and tools
  • 可以运行的软件胜过详细的文档(Working Software over comprehensive documentation
  • 客户合作胜过合同谈判(Customer Collaboration over contract negotiation
  • 响应变化胜过遵循计划(Responding to Change over following a plan

敏捷开发的概念

  • 从早期开始就向客户持续递交有价值和测试过的软件
  • 欢迎修改需求,哪怕是在后期。
  • 频繁递交可以运行的软件(将从每月缩短到每周)
  • 通过持续的客户/研发者校正,来管控需求。
  • 提倡面对面交流。
  • 评估进度的主要尺度是可工作的软件。
  • 商务人员和开发人员每天都相互合作。
  • 简洁是基础,是尽量减少工作量的艺术。
  • 最佳的架构,需求和设计来自于自我组织的团队。

嵌入式系统的敏捷开发

嵌入式系统涉及了软件和硬件。而且硬件是不那么容易不断迭代的活。 在嵌入式系统设计过程中采纳敏捷开发方式呢?我们觉得的可行,下面谈谈我们的做法和体会。

  • 采用top-down 设计方式。

     为了尽快地向客户呈现产品的性能,采取自顶向下的设计方式是最有效的。在桌面系统,移动App和web 应用程序开发中,首先是完成前端用户界面设计。让客户第一时间看到产品的样子,以便和客户确定需求中偏差。然后再开发后端系统。

  • 使用面向对象程序设计语言。

     同样地,在代码开发中,为了和团队其它成员之间的交流,明确API 定义。最好的方式是采用面向对象程序设计语言。第一步首先定义各种类(class),程序主要数据和成员函数。必要的时候,可以使用仿真的方法,在类成员函数中生成仿真数据。团队其它成员可以在第一时间首先调用和测试这些类,是否符合需求。

      对于基于网络的产品而言,在设计的初期,首先定义协议的方式,消息的数据结构和语义。使前后端尽早实现通信。

    团队成员之间通过类定义和消息定义实现沟通和交流。

  • 软件仿真硬件。

      嵌入式软件工程师痛苦的事情是长时间等待硬件的完成,而且由于硬件设计的拖延,往往留给软件工程师软硬件调试的时间十分有限。为了不被硬件开发拖后腿,影响敏捷设计的实施,比较好的方式是使用软件来仿真硬件。虽然增加了代码的工作量,但是完全是值得的。千万不要等待硬件板子来了才开工,那往往就免不了加班了。

  • 模块化硬件

     为了尽快地实现硬件底层驱动的开发,使用模块化电脑板是一个好的方法,在实践中,软件工程师已经大量地使用类似arduino这样的开发板以及各种接口扩展板来搭试硬件平台,调试底层驱动程序,一旦完成之后,移植到目标硬件系统上轻松多了。

Mbed OS 适合敏捷开发

Mbed OS 是Arm 公司为其Cortex-M 处理器开发的一个开源操作系统。我觉得它是更适合作为嵌入式设备敏捷开发的OS。

使用C++ 程序设计语言的RTOS

      Mbed OS 的程序库,硬件接口驱动都使用了类来定义。学习和使用起来十分方便,使应用程序的开发者摆脱了硬件细节。事实上,我们在开发应用程序的过程中,也采取了类似Mbed OS API 的方式,使用类定义软硬模块,将实现细节封闭了起来,使团队的其它人员很块可以重复调用这些类。这一做的另一个好处是我们团队中原来编写JavaScript/HTML5 前端的工程师和NodeJS 的软件工程师也毫无障碍地编写起嵌入式设备的软件了。使全栈工程师延申到了嵌入式设备。他们可以一气呵成实现设备到云端的架构实现。

生态和社区已经建立

尽管Mbed OS 在国内还不普及,但是它在国外已经有了大量的开发者,社区中可以找到大量可以直接使用的程序库和应用程序的实例。

比arduino 更强大

      Mbed OS 毕竟是在32位 cortex-M 系列处理器上运行的OS,cortex-M 比起8位 CPU 性能更高,外围电路更好丰富。另一方面,Mbed OS 对于网络和安全的支持也非常强大,能够轻松实现HTTP RestFull API,MQTT,SSL等。Arm 公司也提供了 pelion 云端服务。

硬件:模块化电脑

     嵌入式系统开发过程中,硬件永远是拖后腿的角色,我常常开玩笑说,等它等到我把写的代码都忘了。如何提高硬件的研发速度,是必须解决的瓶颈问题。

解决这些问题的好方法就是采取模块化设计方式。实际上,模块化是敏捷架构的重要组成部分。前面提到:改变是敏捷开发的重要部分,甚至宣称”欢迎改变“,其实硬件是最难改变的,而模块化设计使的改变更加容易。

事实上,大量的嵌入式设备的硬件都是大同小异的,无非需要一些串口,Ethernet,wifi,以及数字IO,ADC 等等。真正不同的是其中的软件。硬件工程师不断地从事重复性的设计工作。当产品不是大批量生产的,完全可以使用模块电脑来作为嵌入式设备的硬件平台。modular-2 就是这样的一台模块化嵌入式电脑。我们为软件开发者提供了大量常用的IO接口模块和网络通信模块。如果遇到特别的接口电路,硬件工程师也只要设计一块IO模块就完成了,大大减少了硬件开发的工作量。

   modular-2 不仅提高了嵌入式设备的研发效率,使敏捷开发的方法能够在嵌入式设备研发中得到有效地应用。同时,它可以作为产品快速部署到应用现场。快速地呈现给客户一个完整的软硬件结合的产品。这是modular-2 模块化设计带来的好处。

使用了modular-2 之后,我们原先需要开发数个月的项目压缩到了一到两周就完成了。实际上,有的项目我们一个晚上就完成了,使得客户非常吃惊。

  另一方面, 面对客户项目,许多工程师一个人就可以独立地完成。减少了大量协调,沟通的麻烦。降低了嵌入式系统研发的入门门槛,大学毕业生经过短期培训,阅读一些前辈的代码,就能够独立工作。公司的研发力量大大加强。

2010-10-16 15:46:00 chgaowei 阅读数 8551
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10427 人正在学习 去看看 CSDN讲师

“鸡肋——食之无味,弃之可惜”,软件开发过程文档遭遇了鸡肋一样的境遇。

目前敏捷软件开发过程非常流行。相对于软件开发过程文档,敏捷软件开发过程更加重视可运行的程序。
关于软件开发过程文档,两个极端都是不可取的:一是严格要求过程文档,把过程文档作为开发过程的一个必然输出,而不考虑文档是否真正的起作用,即“过度文档”。二是完全放弃文档,不进行任何的记录。“过度文档”偏离软件开发的实质,会造成人力的极大浪费;放弃文档则会丢失开发中的关键信息,不利于产品后期的维护。
我们需要在上面两者之间做一个权衡。这里可以引用“二八定律”:用20%的文档,记录80%的内容。这样用最小的投入,获取最大的价值。
20%的文档要记录那些东西?
1、产品需求描述。
毋容置疑,这是最重要的一个信息。关于产品需求描述,可以写两个文档,一个是需求的整体描述;一个是功能特征表文档。功能特征表对整体需求进行分解,便于后期跟踪需求。

2、软件架构描述,软件实体作用及相互联系。
系统整体结构描述,包括系统包括多少实体,每个实体的作用,实体间的交互机制等。一般要配备图形说明。

3、程序内部结构,逻辑模块,交互。
软件实体内部逻辑模块的划分,各个模块的作用,以及各个模块间的交互机制。

4、数据库设计。
数据库,表达,字段的设计。

5、通信协议。
软件实体间交互消息描述,比如,SIP,XML等。

6、关键数据结构函数。
能够反映软件实体逻辑结构的关键数据结构定义,函数。

7、复杂问题解决方案。
对于复杂需求的解决,需要多个软件实体,或者多个逻辑模块交互实现。这些方案非常值得记录,可以方便后续产品的维护。

文档写作时间可以灵活一些,可以在项目开发过程中进行,如果开发进度非常紧张,也可以开发完成后在补充文档。如果维护过程中,对产品进行了大的更改,要及时的刷新文档,保持文档与程序的同步。

写文档过程中,文档的内容要放在首位,不可以在美工,格式上浪费过多的时间。

 

 

没有更多推荐了,返回首页