敏捷开发实践(2) — 敏捷软件开发者的习惯

敏捷开发实践(2) — 敏捷软件开发者的习惯

敏捷开发的最小单位就是参与敏捷开发的个人。将这些敏捷开发者聚集起来,就形成了敏捷开发团队。

正如上回介绍的,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法,它以最大可能地发挥团队的作用为目的。根据需要,随时改善,以降低软件开发中的风险。

敏捷开发者的态度

敏捷开发者首先需要有忠实,勤恳的态度,在此之上要有持续改善和迅速达成目标的紧迫感。如何让开发者养成敏捷的心态,如何磨练开发者敏捷的意志,让开发者了解敏捷的习惯很重要。

习惯来自于经验,习惯需要用实践来养成。我们来看看作为敏捷软件开发者必备的4种技能 :

  • 编故事(Creating Stories)

    这里不是让你去写一部小说,而是让开发者站在用户的视点,用用户能理解的词汇描述软件系统的机能,行为。只有理解了用户真正的需求,我们才能写出真正需要的软件。

  • 制定计划(Planning)

    敏捷开发并不是没有计划就投入编码。指定计划也是很重要的,但是与以往的开发计划不同,敏捷的计划是随着开发的实际情况改变而随时制定并改善的。所以说敏捷开发的计划的作成、修改的频度很高,需要尽可能高效地完成每次制定的计划。

  • 测试驱动开发(Test-Driven Development)

    它的基本思想就是在开发功能代码之前,先编写测试代码。也就是说在明确要开发某个功能后,首先思考如何对这个功能进行测试,并完成测试代码的编写,然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能,直到完成全部功能的开发。

  • 重构(Refactoring)

    没有最好,只有更好。软件开发也不例外,任何时候我们都可以对软件代码做任何更动以增加可读性或者简化结构而不影响输出结果。

敏捷开发者的习惯

了解了开发者应该具有的态度,我们就可以从自己开始掌握敏捷开发者的习惯。然后在团队中展开,最终形成敏捷的团队。

构成敏捷习惯的要素
  • 敏捷的心态
  • 敏捷的实践
  • 持续改善
重视各种反馈

通过实践中的反馈,我们可以得到过程中的经验,并对今后的开发产生有益的作用。但是并不是一味的重视实践就好了,需要知道何时从实践和反馈中学习。

为了按阶段,周期性的完成实践及反馈的过程,差生了迭代的概念。

迭代开发

迭代开发方法中,整个开发工作被组织为一系列的短小的、固定长度(如2周)的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法,开发工作可以在需求被完整地确定之前启动,并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求,并开始新一轮的迭代。

迭代的一个很重要思想就是将作业按时间单位来划分,管理。在一定的周期内完成开发的作业。不同的团队可以按照机能划分,并行开展,如下图 :

iterative

比如,一个项目的作业期间是3个月,按2周为单位来开展迭代开发,那么迭代的总数就是6个。并且该期限是严守的,一旦规定好了一般是不能更改的。

回顾改善

每个迭代结束之后,都需要回顾上个迭代中的内容,考虑是否有改善和坚持的地方,以提高接下来迭代中的开发效率。

该回顾需要定期的地实施,并在30分钟到1个小时内完成。一般情况下,在白板上使用KPT方法来总结课题。

  • Keep : 好的,需要今后坚持的
  • Problem : 问题点,需要注意并改善的
  • Try : 下次开始尝试改善的

kpt

进行KPT的步骤

  • 检查上次的Try课题
  • 回忆本次迭代中遇到的课题
  • 按Keep,Problem,Try的形式总结
  • Closing,总结,给白板拍照
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1 主题内容与适用范围 本规范规定了在制订软件质量保证计划时应该遵循的统一的基本要求。 本规范适用于软件特别是重要软件的质量保证计划的制订工作。对于非重要软件或已经开发好的软件,可以采用本规范规定的要求的子集。 2 引用标准 GB/T 11457 软件工程术语 GB 8566 计算机软件开发规范 GB 8567 计算机软件产品开发文件编制指南 GB/T 12505 计算机软件配置管理计划规范 3 术语 下面给出本规范中用到的一些术语的定义,其他术语的定义按GB/T 11457。 3.1 项目委托单位 project entrust organization 项目委托单位是指为产品开发提供资金并通常也是(但有时也未必)确定产品需求的单位或个人。 3.2 项目承办单位 project undertaking organization 项目承办单位是指为项目委托单位开发、购置或选用软件产品的单位或个人。 3.3 软件开发单位 software development organization 软件开发单位是指直接或间接受项目委托单位委托而直接负责开发软件的单位或个人。 3.4 用户 user 用户是指实际使用软件来完成某项计算、控制或数据处理等任务的单位或个人。 3.5 软件 software 软件是指计算机程序及其有关的数据和文档,也包括固化了的程序。 3.6 重要软件 critical software 重要软件是指它的故障会影响到人身安全会导致重大经济损失或社会损失的软件。 3.7 软件生存周期 software life cycle 软件生存周期是指从系统设计对计算机软件系统提出应用需求开始,经过开发,产生一个满足需求的计算机软件系统,然后投入运行,直至该软件系统退役为止。其间经历系统分析与软件定义、软件开发以及系统的运行与维护第三个阶段。其中软件开发阶段一般又划分成需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试以及安装与验收等六个阶段。 3.8 验证 verification 验证是指确定软件开发周期中的一个给定阶段的产品是否达到上一阶段确立的需求的过程。 3.9 确认 validation 确认是指在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程。 3.10 测试 testing 测试是指通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。 3.11 软件质量 software quality 软件质量是指软件产品中能满足给定需求的各种特性的总和。这些特性称做质量特性,它包括功能度、可靠性、易使用性、时间经济性、资源经济性、可维护性和可移植性等。 3.12 质量保证 quality assurance 质量保证是指为使软件产品符合规定需求所进行的一系列有计划的必要工作。 4 软件质量保证计划编制大纲 项目承办单位(或软件开发单位)中负责软件质量保证的机构或个人,必须制订一个包括以下各章内容的软件质量保证计划(以下简称计划)。各章应以所给出的顺序排列;如果某章中没有相应的内容,则在该章标题之后必须注明“本章无内容”的字样,并附上相应的理由;如果需要,可以在后面增加章条;如果某些材料已经出现在其他文档中,则在该计划中应引用那些文档。计划的封面必须标明计划名和该计划所属的项目名,并必须由项目委托单位和项目承办单位(或软件开发单位)的代表共同签字、批准。计划的目次是: 引言 管理 文档 标准、条例和约定 评审和检查 软件配置管理 工具、技术和方法 媒体控制 对供货单位的控制 记录的收集、维护和保存 下面给出软件质量保证计划的各个章条必须具有的内容。 4.1 引言 4.1.1 目的 本条必须指出特定的软件质量保证计划的具体目的。还必须指出该计划所针对的软件项目(及其所属的各个子项目)的名称和用途。 4.1.2 定义和缩写词 本条应该列出计划正文中需要解释的而在GB/T 11457中尚未包含的术语的定义,必要时,还要给出这些定义的英文单词及其缩写词。 4.1.3 参考资料 本条必须列出计划正文中所引用资料的名称、代号、编号、出版机构和出版年月。 4.2 管理 必须描述负责软件质量保证的机构,任务及其有关的职责。 4.2.1 机构 本条必须描述与软件质量保证有关的机构的组成。还必须清楚地描述来自项目委托单位、项目承办单位软件开发单位或用户中负责软件质量保证的各个成员在机构中的西相互关系。 4.2.2 任务 本条必须描述计划所涉及的软件生存周期中有关阶段的任务,特别要把重点放在描述这些阶段所应进行的软件质量保证活动上。 4.2.3 职责 本条必
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值