软件开发模式之“敏捷开发” - TOMMYHU - 专注互联网开发及运营技术,提供相关资料及软件下载,奇趣网络时事评论!
Jul 29

软件开发模式之“敏捷开发” 不指定

tommyhu , 23:44 , ASP.NET , Comments(0) , Trackbacks(0) , Reads(6280) , Via Original Large | Medium | Small
简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
Highslide JS
敏捷建模的价值观
  敏捷建模(Agile Modeling,AM)的价值观包括了XP的四个价值观:沟通、简单、反馈、勇气,此外,还扩展了第五个价值观:谦逊。
沟通
  建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通。
简单
  画一两张图表来代替几十甚至几百行的代码,通过这种方法,建模成为简化软件和软件(开发)过程的关键。这一点对开发人员而言非常重要-它简单,容易发现出新的想法,随着你(对软件)的理解的加深,也能够很容易的改进。
反馈
  Kent Beck在Extreme Programming Explained中有句话讲得非常好:“乐观是编程的职业病,反馈则是其处方。”通过图表来交流你的想法,你可以快速获得反馈,并能够按照建议行事。
勇气
  勇气非常重要,当你的决策证明是不合适的时候,你就需要做出重大的决策,放弃或重构(refactor)你的工作,修正你的方向。
谦逊
  最优秀的开发人员都拥有谦逊的美德,他们总能认识到自己并不是无所不知的。事实上,无论是开发人员还是客户,甚至所有的 project stakeholder,都有他们自己的专业领域,都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值,都应该被尊重。
更多讯息访问百度百科:http://baike.baidu.com/view/309926.htm
以下文字来源http://rdc.taobao.com/blog/cs/?p=10,感谢原作者的分享!
敏捷开发在部门内的应用
1、每个迭代过程必须有一个release版本是否适用?
从多个方面去考虑这个问题
1)作为一个底层项目开发部门,架构和整体设计至关重要,而这些是否可以通过迭代的过程逐步完善?带来的重复工作量是否可以承受?
2)当前的架构设计是否充分,或者说我们是否有能力在初始阶段对系统的整体性能和风险做出足够的预估?
3)功能的切分是否可以做到细致并在每个迭代周期满足用户的使用需求?

上面三个问题的答案似乎都是否定的,现阶段我们还无法完全按照SCRUM的要求进行项目迭代开发,而这个阶段会持续到TFS||TAIR完善为一个完整的平台为止。

2、有什么替代方案?
1)仍然必须以面向用户提供功能切分的角度进行任务分割
2)一些共有的底层组件需要单独列举出来
3)保证接口的稳定,必要时采用模拟组件完成功能性的验证
4)通常情况下,我们需要对DONE进行重新定义,应该可以将我们的迭代过程中的任务按照阶段进行分类
a)仅提供演示功能的模块框架,其中包含大量模拟组件或者初步完成的代码,这个步骤需要保证整个架构、内部接口的完整,并在逐渐完善功能,最终达到功能完整
b)模拟组件填充
c)性能优化
d)代码结构的优化
………..
针对这四类任务,应该有不同DONE的定义,a类是通过功能的回归,b类是通过单元测试,c类是通过性能及稳定性的测试,d类是通过可读性可持续性的代码review等等。
当然,无论是哪类任务,迭代完成之后的功能回归测试是必不可少的。
5)按照上面所述,每个迭代过程我们提交的是一个经过了功能和性能回归的产品,但是不一定必须可以release

3、完整的系统设计是否可以作为一个迭代周期内的任务?
还是以多个角度去考虑这个问题
1)我们的能力是否可以完成复杂系统的完整设计,同时在实施时能够仅进行少量的修改?
2)当有技术分歧产生时,我们是否有能力通过讨论判断出更加优化的方案?
3)仅进行大的架构设计是否会对后续开发造成影响?
在完成一个复杂系统,同时时间要求相对严格的前提下,很难有人对第一及第二个问题给出肯定的答案,而第三个问题相信通过短时间的头脑风暴及详细讨论,是可以避免影响的。
所以我个人觉得,当确认了整体架构、功能标准后,我们是可以采用跳过完整的详细设计,做着看的手段来进行Scrum迭代开发的。

4、需要进行文档的编写吗?
需要,当然需要,尤其是面对用户的功能使用文档。Scrum注重人与人的直接交流过程,而不相信传统的文档传承,因为其中丢失了太多的信息。
但以我们部门当前的情况,并没有直接面对一个或多个稳定的客户,为了减少类似的重复劳动,软件使用文档需要进行详尽的编写。
部门扩张比较快,团队成员不够稳定的情况下,软件本身的开发者文档也同样需要,但也许我们可以通过提高代码的可读性和使用一些工具直接生成(例如doxygen)来解决这个问题。

5、有哪些Scrum实践经验可以直接采用?
1)客户作为团队成员
暂时不行,这里的客户指定定义产品特性及排列这些特性的优先级的人,在本组这个专门的角色一直是缺失的,基本上是由大家自发了解应用需求并根据情况自我排期,短期内这种情况尚无法解决,我们需要进行更多的头脑风暴。
2)短交付周期
不行,根据问题1、2探讨的结果,我们需要对交付和完成的概念进行重新定义。
3)验收测试
可行,我们需要尽快和测试部门一起来完成这项工作。
4)结对编程
暂时不行,或者说暂时不作为一项制度执行。这种编程模式的效果尚不确定,欢迎大家进行有益的尝试。
5)测试驱动的开发方法
可行,有利于重构及解耦合,同时督促大家提高自身代码质量,迫切需要实行。
6)集体所有权
可行,但不作为一个制度执行,欢迎大家进行有益的尝试。
7)持续集成
可行,有益于快速发现bug并保证代码的稳定性,但是需要一些特殊工具软件的配合,也许我们可以试用一下阿里云当前正在使用的scons。
8)可持续的开发速度
可行,也必须实行,我会帮大家做好开发规划并努力完成最终的目标,并挡住一些不必要的时间压力。
9)开放的工作空间
暂时不行,我们缺少一些必要的场地条件,但是我们可以使用一些其他的技术手段来绕过去,例如公开的twiki等等,至少可以保证项目内部的讨论不受影响。
10)计划游戏
可行,给开发人员更多的发言权,让大家真正参与工期的安排,碰撞出更多的火花。
11)简单的设计
可行,按照问题三的思考,我们需要加强整体架构的设计,弱化细节的讨论,并在开发过程中逐步迭代完成它,除非这个细节的引入小于后续完善的成本并且我们确定可以通过讨论得到准确的结论。
12)重构
可行并且重要,我们需要保持自身代码尽可能的干净简洁并且高效,在代码review阶段需要着重注意这个方面。
13)隐喻
太过玄幻的概念,暂时不作实行。
总结起来,按照紧迫程度分档如下
迫切需要执行:验收测试、测试驱动、可持续的开发速度
需要执行:持续集成、计划游戏、简单设计、重构
提倡大家做一些尝试:客户作为团队成员、结对编程、集体所有权、开放的工作空间
暂不执行:短交付周期、隐喻

6、下一步我们怎样开展Scrum开发模式工作?
根据兄弟部门的实践经验,Scrum可以有效的对项目周期进行管理,并将团队内部或者资源配置方面的一些问题尽快的暴露出来,提升工作效率。我们需要尽快的在这方面做出尝试。
结合部门内部的情况,我想我们需要采用以下一些具体的手段
1)sprint周期的定义,暂时定为四周,这样一个时间段应该可以保证适应一些突发的变化,可以完成一些底层的构建,同时也不会有太长的工作任务造成效率下降。
2)sprint的计划,对这个迭代周期的工作进行分解、计划,采用一些计划游戏鼓励大家说出自己考虑的问题,也鼓励大家申领自己并不是很熟悉的模块,逐步加强代码共有的程度。
3)每个sprint的review,sprint结束后,我们会对这个迭代周期内的成果进行一次展示,也许是一些测试报告,也许是一些可运行的系统演示,充分向应用方说明当前情况,提升团队荣誉感和影响力。
4)每个sprint的总结,sprint结束后,我们会对整个迭代周期内发生的一些事件进行回顾,讨论优秀的经验,并讨论需要进一步提高的。
5)每天的晨会,在这个会议上实际的工作人员需要明确的说出上次晨会后做了什么,本次晨会后准备做什么,完成这些可能会遇到什么困难。请注意这里不是为了解决问题,而是要把问题暴露出来并由其他人在后续提供帮助,每次晨会的时间需要限定在15分钟内。
6)测试资源的引入,根据问题5进行的讨论,Scrum需要和测试密切的配合,我会全力推进测试部门逐步完善验收测试所需的平台,并努力使测试人员专有化。
7)所需要的一些工具,根据公司当前的状况,我们需要使用以下几种工具来配合Scrum的执行
a)XPlanner 用于进行sprint计划及工作进度展示。
b)ReviewBoard 用于对代码质量进行管理
c)BugFree 用于系统Bug管理
d)Twiki 用于进行一些讨论纪要及燃尽图的记录,保持团队的沟通和对进度的统一认识
e)Scons 用于进行持续集成
▲返回顶部

Add a comment

Nickname

emotemotemotemotemotemotemotemotemotemotemotemotemotemotemotemot