2008-02-08 10:06:00 benbenqingqing1 阅读数 2744
  • SCRUM敏捷开发视频教程

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

    10436 人正在学习 去看看 CSDN讲师
 敏捷开发agile development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

      敏捷开发是全新理论吗?答案莫衷一是。细心的人们可以发现,敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发,这两种在任何一本软件工程教材中都会被提到的方法,在敏捷开发模式中扮演了很重要的角色。再向前追溯,我们还也可见到瀑布式与快速原型法的影子,也许还有更多。

      改善,而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华,去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中,我们每两周都会得到一个可以工作的软件,”Fowler介绍,“这种非常短的循环,使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”

      也许是因为时间关系,Fowler只说出了这些优势中的一部分。允许开发过程中的需求变化、通过早期迭代可以较早发现风险、使代码重用变得可行、减少项目返工……借鉴了众多先进方法和丰富经验,拥有的众多优势使得敏捷开发看来已经成为解决软件危机的标准答案。

      问题与思考
      然而,我们不得不面对的现实却是,模式与方法的优化并不意味着问题的终结。作为一种开发模式,敏捷开发同样需要面对众多挑战。

      大项目的拆分意味着更多子项目的出现,协调这些同步或异步推进的子项目,合理的资源调配都将变得更加复杂。另外,在当前项目和项目组普遍“增容”的情况下,遇到的问题同样成倍增长。人的重要性被提到了更高的高度,而缺乏有效协调手段,减少人员流动和项目变更对整个项目造成的影响也将成为一大挑战……新方法带来众多便利的同时,也相应引发了几乎同样多的问题。

 

      敏捷开发(agile development)概念从2004年初开始广为流行。Bailar非常支持这一理论,他采取了"敏捷方式"组建团队:Capital One的"敏捷团队"包括3名业务人员、两名操作人员和5~7名IT人员,其中包括1个业务信息指导(实际上是业务部门和IT部门之间的"翻译者");另外,还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过"敏捷开发"的培训,具备相关的技能。

      每个团队都有自己的敏捷指导(Bailar聘用了20个敏捷指导),他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段,团队人员密切合作,开发有规律地停顿--在9周开发过程中停顿3~4次,以评估过程及决定需求变更是否必要。在Capital One,大的IT项目会被拆分成多个子项目,安排给各"敏捷团队",这种方式在"敏捷开发"中叫"蜂巢式(swarming)",所有过程由一名项目经理控制。

      为了检验这个系统的效果,Bailar将项目拆分,从旧的"瀑布式"开发转变为"并列式"开发,形成了"敏捷开发"所倡导的精干而灵活的开发团队,并将开发阶段分成30天一个周期,进行"冲刺"--每个冲刺始于一个启动会议,到下个冲刺前结束。

      在Bailar将其与传统的开发方式做了对比后,他感到非常兴奋--"敏捷开发"使开发时间减少了30%~40%,有时甚至接近50%,提高了交付产品的质量。"不过,有些需求不能用敏捷开发来处理。" Bailar承认,"敏捷开发"也有局限性,比如对那些不明确、优先权不清楚的需求或处于"较快、较便宜、较优"的三角架构中却不能排列出三者优先级的需求。此外,他觉得大型项目或有特殊规则的需求的项目,更适宜采用传统的开发方式。尽管描述需求一直是件困难的事,但经过阵痛之后,需求处理流程会让CIO受益匪浅。

      敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,他们认为:

  • 个体和交互 胜过 过程和工具
  • 可以工作的软件 胜过 面面俱到的文档
  • 客户合作 胜过 合同谈判
  • 响应变化 胜过 遵循计划

并提出了以下遵循的原则:

  • 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
  • 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
  • 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
  • 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
  • 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
  • 在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。
  • 工作的软件是首要的进度度量标准。
  • 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
  • 不断地关注优秀的技能和好的设计会增强敏捷能力。
  • 简单是最根本的。
  • 最好的构架、需求和设计出于自组织团队。
  • 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

一、敏捷开发方法

(一) 说明
本文是阅读Alistair Cockburn的Agile Software Development和William C. Wake的XP Explored的一些笔记和想法,Agile Software Development是一组软件开发方法的总称,包括(Crystal , Extreme Programming , Adaptive software development等等)。敏捷开发方法又称为“轻量级”开发方法。

下面这段话摘自Martin Fowler的一篇文章:

从无到繁重再到敏捷
多数软件开发仍然是一个显得混乱的活动,即典型的“边写边改” (code and fix)。设计过程充斥着短期的,即时的决定,而无完整的规划。这种模式对小系统开发其实很管用,但是当系统变得越大越复杂时,要想加入新的功能就越来越困难。同时错误故障越来越多,越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段,有时甚至有遥遥无期之感,从而对项目的完成产生严重的影响。
我们使用这种开发模式已有很长时间了,不过我们实际上也有另外一种选择,那就是“正规方法”(methodology)。这些方法对开发过程有着严格而详尽的规定,以期使软件开发更有可预设性并提高效率,这种思路是借鉴了其他工程领域的实践。
这些正规方法已存在了很长时间了,但是并没有取得令人瞩目的成功,甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐,要是按照它的要求来,那有做太多的事情需要做,而延缓整个开发进程。所以它们通常被认为是“繁琐滞重型”方法,或Jim HighSmith 所称的“巨型”(monumental)方法。
作为对这些方法的反叛,在过去几年中出现了一新方法。尽管它们还没有正式的名称,但是一般被称为“敏捷型”方法。对许多人来说,这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡,使得能以不多的步骤过程获取较满意的结果。
敏捷型与滞重型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档,对于一项任务,它们通常只要求尽可能少的文档。从许多方面来看,它们更象是“面向源码”(code-oriented)。事实上,它们认为最根本的文档应该是源码。
但是,我并不以为文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表象,它其实反映的是更深层的特点:
? 敏捷型方法是“适配性”而非“预设性”。 重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划,然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实,它们的目的就是成为适应变化的过程,甚至能允许改变自身来适应变化。
? 敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。
我认为以上两个特点很好的概括了敏捷开发方法的核心思想:适应变化和以人为中心

(二) 方法背后的思想

Alistair Cockburn在Agile Software Development中讲述了敏捷开发方法背后的思想

人们掌握过程(process)可以分为3个阶段:
1 following 遵循一个定义好的process
2 detaching 知道不同process的适用范围,在不同的场合使用不同的process
3 fluent 不关心是否遵循特定的process,知道在什么情况下采用什么动作

软件开发是一个充满发明和交流的协作性游戏(cooperative game of invertion and communication)。软件开发的首要目标是生产出软件,遵循特定的过程和模型只是手段,只要传递了足够的信息,手段是次要的。交流的效果要远远重于交流的形式(Effect of communication is more important than the form of communication)。
一般软件开发有两个目标:1 尽快的生产出软件2 为下一个team或项目做准备,有时这两个目标是矛盾的,我们要在这两个目标之间寻求平衡

在软件开发中,人的因素要远远大于过程和技术。人是有缺陷的:
1 容易犯错误,因此必须在错误扩散之前找到并改正错误
2 当觉得可能失去较多的时候,不愿意冒险
3 重新构造而不愿意重复使用已有的东西
4 难于坚持一个习惯

针对个人因素的几个建议:
1 具体的模型较抽象的模型更容易理解
2 从一个例子开始是容易的
3 通过观察他人的成果学习
4 要有足够的不受打扰的时间
5 分配的工作要与个人意向,能力匹配
6 不正确的奖励会有坏作用,从长期看个人兴趣比奖励更重要,培养在工作中的自豪感:
1) pride in work参与工作的自豪感,通常参与一个重要的工作会有自豪感
2) pride in accomplishment 完成工作的自豪感,长期未完的工作会使士气低落
3)pride in contribution 为他人贡献的自豪感
7 鼓励关心其他人的工作和整体的工作

在一个团队之间,交流是最重要的,实践证明面对面的实时的交流是最有效的,对交流的延误会损失信息,白板是最好的交流工具,交流工具的先进并不能提高交流效果。文档的作用是记录和备忘,不能通过文档交流。

敏捷开发方法要避免的过程设计的几个常见错误
1 对所有的项目使用同一种过程
2 没有弹性
3 过于沉重
4 增加不必要的“必须完成”(“should do” is really should?)
5 没有经过实践检验

敏捷开发方法过程设计的几个原理:
1 交互的面对面的交流是代价最小,最迅速的交换信息的方法
2 超过实际需要的过程是浪费的
3 大的团队需要重量级方法
4 处理重大问题的项目需要重量级方法强调
5 增加反馈和交流可以减少中间产品和文档的需求
6 轻量级方法更强调理解(understanding),自律(discipline)和技能(skill),重量级方法更强调文档(documentation),过程(process)和正式(formality)
understanding指整个团队关于项目的全部知识,包括讨论的过程,documentation只能记录其中的一部分
discipline是指个人主动的完成工作,process指个人根据指令完成工作
skill指具有良好技能的人可以省略中间的产品,formality指必须按照规定步骤完成工作

7 确定开发中间的瓶径,提高它的效率
对于瓶径处的工作应该尽量加快,减少重复,(使用更熟练的人,使用更多的人,使用更好的工具,使瓶径处的工作的深入尽量稳定)对于非瓶径处的工作可以多一些重复,在输入还不确定的情况下也可以尽早开始。

这些原理的几个结论:
1 向一个项目增加人员要花费较大代价(constly),因为原有人员和新人员之间的交流要花费大量时间
2 团队的规模经常是跳跃的,例子:需要6个熟练的程序员,但是只有4个,于是增加不熟练的程序员,结果团队的大量时间花费在培训不熟练的程序员上面,最后增加到了20个不熟练的程序员。
3 应该侧重于提高团队的技能而不是扩充团队
4 对不同的项目使用不同的过程
5 在适用的条件下,轻量级的方法优于重量级的方法
6 对不同的项目要裁减过程

敏捷开发方法的原则是“刚刚好”(Light and Sufficient)


(三) Crystal

Crystal是Alistair Cockburn提出的一组开发方法,分为Crystal Clear,Crystal Yellow, Crystal Orange和Crystal Red分别适用于不同的项目。项目可以按照参加的人员和重要性划分。重要性根据项目中的错误引发的后果分为:
C Loss of comfort (某些不舒适)
D Loss of discretionary money (经济损失)
E Loss of Essential Money (严重经济损失)
L Life Critical (生命危险)
一个项目称为C6说明参加人员在6人以下,重要性是C级,D20说明人员在6-20人,重要性是D级。

Crystal Clear适用于 C6,D6项目
Crystal Yellow适用于 C20,D20,E20项目
Crystal Orange 适用于 C40,D40,E40项目
Crystal Red 适用于 C80,D80,E80项目

Crystal Clear

适用于一个办公室内的一个小组

角色有: sponsor发起人,任务下达者
Senior Designer-Programmer 高级设计开发人员
Designer-Programmer 设计开发人员
User 用户
其中一个人是项目协调者(Project Coordinator)。Senior Designer-Programmer是关键人员

策略:
1 软件的开发采用有规则的周期性递增方法,每2-3个月提交(deliver)一个版本
2 使用里程碑(milestone)跟踪进度(包括delvier和开发期间的重大决定)
3 自动回归测试(automated regression test)
4 用户直接参与
5 每个release有两个user viewings(用户审核?)
6 在上一个步骤足够稳定(stable enough to review)时立即开始下一个步骤,尽量并行开发
7 在每个周期的开始和中间进行产品和过程调整

过程产品(指整个过程产生的所有产品,包括软件和文档)
1 软件释放顺序(release sequence)
2 用户审核的计划
3 用户案例(usecase)或需求描述
4 设计框架和必要的说明
5 界面草图
6 基本的对象模型
7 执行代码
8 migration code
9 测试用例
10 用户手册
11 local matters有项目组决定:
上述product的摸班
编码和用户界面的标准
回归测试的标准和细节
其他文档
需要的工具:
版本控制工具
白板(最好可打印)


Crystal Orange

角色:sponsor 发起人
business export/usage export 业务专家
technical facilitator 技术专家
business analyst/designer 业务分析和设计人员
project manager 项目管理
architect 系统架构人员
Design Mentor 设计指导人员
Lead Designer-Programmer 主要设计编码人员、
Other Designer-Programmer设计编码人员
UI Designer 用户界面设计人员
Writer 文档写作人员
Tester 测试人员

策略:
同Crystal Clear (周期可以为3-4个月)
过程产品:
需求文档
计划
状态报告
用户界面设计文档
基本对象模型
外部接口标准
用户手册
源代码
测试用例
migration code
local matters 同Crystal Clear


(四) The Agile Alliance

敏捷联盟是17位不同敏捷开发方法的提倡者共同成立的,目的是推进敏捷开发方法的研究和应用,他们并不要求强制使用某种开发方法,而是提出了敏捷开发的几个核心价值和基本原则:
core value:

Individuals and interactions over processes and tools
个人和交流重于过程和工具
Working software over comprehensive documentation
正在运行的软件本身重于复杂的文档
Customer collaboration over contract negotiation
与客户的沟通和交流重于使用合同约束客户
Responding to change over following a plan
对变化的快速响应重于跟随计划

principles

1 最高目标是通过快速的和经常的发布软件满足客户的需要
2 提交软件的周期为几个星期到几个月
3 产生正确的软件是衡量进度的首要标准
4 主动接受需求的改变而不是拒绝
5 商务人员和开发人员工作在一起
6 个人必须有动力,要创造环境支持他们的要求,信任他们
7 最有效的交流方法是面对面的交流
8 最好的结构,需求和设计来自于自组织的团队(self-organizing team),允许任何人提出想法和建议
9 持续改进设计和编码
10 鼓励正常工作,减少长时间加班
11 保持简单,减少不必要的部分,认识到简单的设计比复杂的设计更难(simple design is harder to produce)
12 定期调整过程,获得更高效率


(五) Extreme Programming

Extreme Programming(XP,极限编程) 是一种轻量级的软件开发方法,它使用快速的反馈,大量而迅速的交流,经过保证的测试来最大限度的满足用户的需求。XP强调用户满意,开发人员可以对需求的变化作出快速的反应。XP强调team work。项目管理者,用户,开发人员都处于同一个项目中,他们之间的关系不是对立的,而是互相协作的,具有共同的目标:提交正确的软件。XP强调4个因素:
交流(communication),XP要求程序员之间以及和用户之间有大量而迅速的交流
简单(simplicity),XP要求设计和实现简单和干净
反馈(feedback)通过测试得到反馈,尽快提交软件并根据反馈修改
勇气(courage)。勇敢的面对需求和技术上的变化

XP特别适用于需求经常改变的领域,客户可能并系统的功能并没有清晰的认识,可能系统的需求经常需要变动。
XP也适用于风险比较高的项目,当开发人员面对一个新的领域或技术时,XP可以帮助减低风险
XP适用于小的项目(人员上),人员在2-12人之间,XP不适用于人员太多的项目,事实上,在需求经常变化或风险比较高的项目中,少量而有效的XP开发人员效率要远远高于大量的开发人员。

下面是XP的开发流程


XP的原则和实践:

1 Planning:

1)user stories。
User stories类似use case,描述用户所见的系统功能,但避免使用大量的文档,user stories由用户编写(不仅限于描述用户界面)。User stories使用用户的语言编写,不使用技术性的语言,每个user stories限于几句话。User stories用于在release plan会议上对开发时间进行评估,也用于产生验收测试(acceptance test),必须使用可以自动进行的验收测试保证软件的正确性。User stories与传统的用户需求的区别在于详细的程度,user stories并不会确定需求的每个细节,它只是用来简单的描述系统功能,供开发人员进行估计开发进度,在开发过程中开发人员和用户会不断的交流以讨论细节问题。User story应该专注于功能,不应该过分注重用户界面等细节。一般一个user storiy在1-3周的时间完成,如果估计超过3周,说明user story太大了,需要细分。

2)release plan.
召开一个release plan会议,产生release plan。Release plan将用于指定每个iteration的计划。开发人员对每个user story估计开发时间(在不被打断,无其他工作情况下的开发时间,包括测试),用户对user stories给出优先级,release plan会议并不制订每个iteration的计划。Release plan要用户,开发人员和管理者都同意,在完成功能范围(scope),使用资源(resource),时间(time)和质量(quality)上达成一致(一般质量是不能改变的)

3) small release
often and small release是XP的一个原则,每个release完成一些用户有意义的功能集合,尽快的提交给用户以获得反馈,及时调整,提交的越晚,调整越困难。
4)project velocity
团队在开发过程中要收集数据,以便于对自己的开发速度进行评估,用于以后的releazse plan

5)iteration
每个small release的周期称为iteration,每个iteration约为1-3周,在一个项目中保持每个iteration的时间相等,不要超前制定计划,每个iteration的计划在iteration的开始时制定。这样能够更灵活的应付变化。不要急于完成本次iteration没有包括的功能。要注重每个iteration的时间限制,当团队觉得不能按时完成iteration时,召开一次iteration plan会议,重新评估,减少一些user stories。

下面是iteration的图示:

 

6)iteration plan
在每个iteration开始的时候召开会议,从release plan中选择还没有实现的用户最迫切需要的user stories。上一个iteration中没有通过验收测试的功能也要在这个iteration中实现。可以根据上一个iteration的实践调整团队速度。User stories和失败的测试被分解成programming task,task使用技术语言编写,作为iteration plan的详细描述。程序员主动领取task并估计完成时间,每个task应该在1-3天内完成,超过3天的task应该被细分。如果整个团队需要的时间多于或少于规定的iteration时间,调整user stories。

7)move people around
不要使每个开发人员局限于一项工作,不要使某项工作依赖于一个开发人员,增加知识共享,减少信息孤岛,多进行交流和培训。当项目中的所有人对所有模块都了解并可以进行开发时是效率最高的,鼓励开发人员在不同iteration中开发不同的模块。

8) stand-up meeting
每天工作开始之前,开5-10分钟的stand-up会议(站立会议),站立的目的是为了强迫节省时间,会议的目的是交流,提出存在的问题,但不要在会议上解决问题。开一个所有人员参加的短会比多个个别人员参加的会议要高效。在会议上提出的问题可以由少数人讨论解决,这个少数人参加的会议如果涉及到代码,可以在计算机前讨论。

9) fix XP when it breaks
XP并不是一成不变的,当团队觉得需要修改的时候,可以根据自己的情况进行修改,任何修改都要经过整个团队的讨论和达成一致

2 Designing

1) Simplicity
保持简单的设计,在完成同样的功能的情况下,选择简单的设计,不要急于设计没有计划的功能,应该认识到:keeping a design simple is hard work

2)system metaphor
使用统一的术语描述系统,在用户,管理者和开发人员之间使用统一的术语。这将使交流清晰。

3)CRC card
使用CRC(Class, Responsibilities, and Collaboration) card进行系统设计,鼓励更多的人参加设计。每个CRC卡片表示系统中一个对象,写上对象的名字,责任和每个责任需要交互的其他对象。可以模拟对象之间的交互。CRC卡片是易于理解的,但是是非正式的,如果需要正式的文档,要将卡片转换为相应的文档。

4) spike solution
使用spike solution减低风险,当遇到技术难题或设计问题时,使用简单的程序进行测试,找出问题,在不同的解决方法之间进行评估。在早期进行实验可以有效的降低风险。

5)never add function early
不要过早的设计没有计划的功能,在一个需求经常变化的环境中,过早的设计经常是没有用的。

6)refactoringwhenever and wherever
XP鼓励对设计和代码经常进行重构Refactoring),目的是去除冗余,提高质量,保持设计简单。重构必须以完全测试为检验条件


3 Coding

1) customer is alaways available
用户是项目组的成员之一,用户的参加贯穿整个开发过程,用户与开发人员之间的交流是重要的

2) coding standard
使用统一的编码标准,这是保持代码整洁和共享代码的基础

3)coding unit test first
test first是XP的一个特点,在编写代码之前先编写单元测试代码,单元测试代码和代码由同一个程序员完成。先编写测试代码可以使程序员更好的理解需求,避免直接编码造成的理解偏差,对需求的不清晰,可以在编写测试代码时就发现。测试代码也是检验程序是否完成的标准。编码工作应该是以下工作的循环:
1 编写测试代码
2 运行测试程序,确认失败
3 编写实现这个测试程序要求功能的代码,不需要实现其他的功能,只需要实现刚刚满足测试程序的功能
4 运行测试程序,确认成功
实践证明,test first方式需要的编码实践少于先编码,后写测试代码

4) Pair Programming
Pair programming是XP的特色,它要求两个程序员在一台计算机上同时进行编程工作。共用鼠标和键盘,通常一个人进行战略上的思考,程序架构和函数,类之间的关系,一个人进行输入和战术上的思考,完成函数和类。两个人可以经常交换角色。Pair programming需要一段时间学习和适应,实践证明pair programming并不消耗更多的时间(人*小时),但是代码的质量得到很大的提高。(避免将两个新手放在一个pair中)

5)sequential integration
要保证源代码库的状态是可标识的,同一时间,只允许一个pair的程序进行整和和测试,这样可以缩小问题产生的范围。不同的pair可以在自己的机器上随时进行整和和测试.

6) integrate often
只要有可能就进行代码整合,周期可以在几个小时,最好不要超过一天。经常的整合可以避免错误的积累,可以增加可重用的代码。在一个pair认为适当的时候并通过了所有的unit test,就可以进行整合,整合后的代码必须通过测试。同一时间,只允许一个pair进行整合。(整合失败是不是要退回原有状态,供其他pair整合??)

7) 共同拥有代码
鼓励每个人对项目中的任何人提出新的想法,任何开发人员对项目中的任何代码都可以进行增加功能,改正错误和重构。没有代码或开发人员成为瓶颈。(我的想法:这确实很难理解,但是这确实是我梦想的目标)。为了达到这个目标,任何的代码都必须有相应的测试代码,任何代码的修改必须100%通过测试。必须加强开发人员的交流和知识共享,必须坚持统一编码标准。Pair programming可以经常交换伙伴。

8)优化工作放在最后
先使系统能够正常工作,不要猜测系统的瓶颈,要实际测量

9)NO overtime
不要长时间的加班,大多数加班并不能挽回已有的延迟,连续超过两个星期的加班说明有问题存在。向一个已经延迟的项目填加人员也不是一个好的选择。

 


4Testing

1)所有的代码都有单元测试
单元测试是XP的基石,XP中的单元测试应该是可以自动进行的,所以可以很快的进行所有的单元测试,单元测试应该在编码之前创建。单元测试的代码和代码一起release,没有单元测试的代码不能够release。使用自动单元测试可以系统整合时节省大量的发现错误和改正的时间。单元测试越完善,节省的时间越多。对面向对象的编程来说,应该对每个类都有单元测试。完善的单元测试也是共同拥有代码的保证。单元测试也是可以经常重构的保证,每次重构后的代码都要重新进行测试
(这里的unit test好象不只限于测试某个模块的功能???,应该可以测试整合起来的整个系统,这样才能保证整合的正确性。)

2)代码在release前必须通过所有的单元测试

3) 发现bug后,首先增加测试
在实际运行中发现bug,首先增加acceptance test,然后增加unit test,在增加完测试后在查找和修改代码,增加的测试保证同样的错误不会再出现

4) acceptance test
acceptance test根据user stories在iteration plan会议上创建,它也应该可以自动运行以便可以经常运行。User stories是否完成是以是否通过acceptance test为检验标准。


XP中的角色:

1 customer 用户
在XP中,用户是项目组的一部分,用户负责编写use stories,确定优先级,和开发人员讨论需求,编写accept test,运行accept test,用户驱动iteration(release plan, iteration plan)

2 开发人员
与用户讨论user stories,估计开发时间,将user stories细化成programming task
编写unit test
编码
进行重构
整合及测试,保证100通过

3 manager
负责对外联系,组织团队,获取必要的资源,管理团队

4 tracker
跟踪release plan/iteration plan/acceptance test

5 coach
起顾问指导作用,mentor, monitor and help
A Coach is respected, but also respectful. They’re willing to talk, but also willing to listen. They let the team explore, but provide a guard-rail in case of danger.
监督进展,确保过程和规则,必要时改变过程,帮助解决问题,也可以参加pair programming。

二、敏捷开发的设计原则

关于敏捷开发的设计原则:
单一职责原则SRP:Single Responsibility Principle
开放封闭原则OCP:Open-Close Principle
Liskov替换原则LSP:Liskov Substitution Principle
依赖倒置原则DIP:Dependency Invertion Principle
接口隔离原则ISP:Interface Separate Principle
关于包的设计原则:
重用发布等价原则REP:Reuse Equivalence Principle
共同重用原则CRP:Common Resue Principle
共同封闭原则CCP:Common Close Principle
无环依赖原则ADP:Acyclic Dependency Principle
稳定依赖原则SDP:Stabilization Dependency Principle
稳定性度量公式:I=Ce/(Ca+Ce) (I:不稳定度,Ce:输入耦合度,Ca:输出耦合度)
I取值范围在【0,1】,I=0表示具有最大稳定度;iI=1标识具有最大不稳定度
稳定抽象原则SAP:Stabilization Abstract Principle

 

GOF说--基于对象组合的设计会有更多的对象(而有较少的类)。
如果单纯的看这里,你会明白似乎类较少符合面向对象的逻辑。
但是且慢,我们知道面向对象有一条原则叫单一职责原则--SRP。
这样好像类多又是面向对象思想的体现。
其实最重要的是GOF中的这句话--且系统的行为将依赖对象间的关系而不是被定义在某个类中。
所以类的多少并不是问题的关键,是否职责单一也不是大问题,
最重要的是你现在的那些职责是都多少是不能被别的职责通过某种方式所代替的。
在BOB大叔那里定义职责是变化的原因,因此就可以认为这些变化的原因应该是不可代替的,
也可以说你不能由这个原因推导出别的原因。
只要这个原因间可以做到相互关联,那么你就可以把由于这些变化而引起变化的类组合起来,
而不是把他们规定在新的类中。

开放封闭原则OCP:Open-Close Principle

一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。

因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。

该原则同样适合于非面向对象设计的方法,是软件工程设计方法的重要原则之一。

我们以收音机的例子为例,讲述面向对象的开闭原则。

我们收听节目时需要打开收音机电源,对准电台频率和进行音量调节。

但是对于不同的收音机,实现这三个步骤的细节往往有所不同。

比如自动收缩电台的收音机和按钮式收缩在操作细节上并不相同。

因此,我们不太可能针对每种不同类型的收音机通过一个收音机类来实现(通过重载)这些不同的操作方式。

但是我们可以定义一个收音机接口,提供开机、关机、增加频率、降低频率、增加音量、降低音量六个抽象方法。

不同的收音机继承并实现这六个抽象方法。

这样新增收音机类型不会影响其它原有的收音机类型,收音机类型扩展极为方便。

此外,已存在的收音机类型在修改其操作方法时也不会影响到其它类型的收音机。
图1是一个应用OCP生成的收音机类图的例子:

Liskov替换原则LSP:Liskov Substitution Principle

子类应当可以替换父类并出现在父类能够出现的任何地方。

我们以学生为例,夜校生为学生的子类,因此在任何学生可以出现的地方,夜校生均可出现。

这个例子有些牵强,

一个能够反映这个原则的例子时圆和椭圆,圆是椭圆的一个特殊子类。

因此任何出现椭圆的地方,圆均可以出现。但反过来就可能行不通。 三、敏捷开发技术在电子商务软件中的应用
 
  第一章 背景介绍

  运用替换原则时,我们尽量把类B设计为抽象类或者接口,

让C类继承类B(接口B)并实现操作A和操作B,

运行时,类C实例替换B,这样我们即可进行新类的扩展(继承类B或接口B),

同时无须对类A进行修改。

依赖倒置原则DIP:Dependency Invertion Principle

在进行业务设计时,与特定业务有关的依赖关系应该尽量依赖接口和抽象类,而不是依赖于具体类。

具体类只负责相关业务的实现,修改具体类不影响与特定业务有关的依赖关系。

在结构化设计中,我们可以看到底层的模块是对高层抽象模块的实现(高层抽象模块通过调用底层模块),

这说明,抽象的模块要依赖具体实现相关的模块,

底层模块的具体实现发生变动时将会严重影响高层抽象的模块,显然这是结构化方法的一个"硬伤"。


  面向对象方法的依赖关系刚好相反,具体实现类依赖于抽象类和接口

  为此,我们在进行业务设计时,应尽量在接口或抽象类中定义业务方法的原型,

并通过具体的实现类(子类)来实现该业务方法,业务方法内容的修改将不会影响到运行时业务方法的调用

接口隔离原则ISP:Interface Separate Principle

采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。


  ISP原则是另外一个支持诸如COM等组件化的使能技术。

缺少ISP,组件、类的可用性和移植性将大打折扣。

这个原则的本质相当简单。如果你拥有一个针对多个客户的类,

为每一个客户创建特定业务接口,然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。

以下展示了一个拥有多个客户的类。

它通过一个巨大的接口来服务所有的客户。

只要针对客户A的方法发生改变,客户B和客户C就会受到影响。

因此可能需要进行重新编译和发布。这是一种不幸的做法。

所展示的技术。每个特定客户所需的方法被置于特定的接口中,这些接口被Service类所继承并实现。

如果针对客户A的方法发生改变,客户B和客户C并不会受到任何影响,也不需要进行再次编译和重新发布。

 

  1.1 电子商务背景

  随着企业信息化的不断进步,电子商务在中国也越来越得到更多的认可,电子商务的应用也越来越多,但是很多企业对电子商务的概念和应用还不是很清楚,行业内对电子商务的研究模式和实施方法也存在很多问题。因此很多企业在实施电子商务系统的过程中都处在探索和摸索当中,对于项目开发方来说也有着极大的风险性和挑战性。

  1.2 电子商务软件开发存在的问题

  由于电子商务软件开发存在很大的风险性,而且电子商务的应用也出在不断摸索当中,没有很多成熟的模式可以参考,所以没有实践的指导可能会导致的项目噩梦。缺乏有效的实践会导致不可预测性、重复的错误以及努力的白白浪费。延期的进度、增加的预算和低劣的质量致使客户对我们丧失信心。更长时间的工作却生产出更加低劣的软件产品,也使得开发人员感到沮丧。我们希望这些方法这次还会有效,从而消除我们的恐惧。然而,项目并没有简单到使用一些约束和人为制品就能够可靠地防止错误的地步。当连续地犯错误时,我们会对错误进行诊断,并在过程中增加更多的约束和人为制品来防止以后重犯这样的错误。一个大而笨重的过程会产生它本来企图去解决的问题。它降低了团队的开发效率,使得进度延期,预算超支。它降低了团队的响应能力,使得团队经常创建错误的产品。

  1.3 敏捷开发技术概述

  敏捷式开发采用适应性方法,而传统的软件工程学采用的是预测性方法。敏捷式开发是以人为主的,而传统的工程学是以过程为主的。

  1.4 敏捷开发的现实意义

  适应性和预测性的区别存在于软件工程学对软件开发过程的描述中。在传统的工程学里,核心的概念就是把设计和构建这两个过程分开进行。在软件开发的过程中,我们很难想象,如何真正把设计和编程完全区分过来。软件工程学领域,所有在这里从事工作的人员,都把设计的过程想象成用图表、图象的方式来描述结果的过程。还有一个更重要的问题就是说,软件本身的需求是在变化的。一个项目在开发过程中需求会出现变化,需求的变化从根本上推翻了工程学方法所建立的一个基础。当工程学的人尽量减少或者控制系统将来发生变化的可能,他越这样做问题就越容易出现。既然我们没办法避免变化的发生,那么我们就想找到一种新的方法能够更有效地适应这种变化现象。这也就是敏捷式开发方法所要达到的效果。

  第二章 敏捷开发技术的应用

  2.1 敏捷开发技术的几种主要类型

1.XP(Extreme Programming -- 极限编程

2.Cockburn的水晶系列方法

3.开放式源码

4.Highsmith的适应性软件开发方法〔ASD〕

   2.2 敏捷开发技术的特点和优势

  1.个体和交互胜过过程和工具

  人是获得成功的最为重要的因素。如果团队中没有优秀的成员,那么就是使用好的过程也不能从失败中挽救项目,但是,不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作,那么即使拥有一批优秀的成员也一样会惨败。团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环境,然后期望团队自动凝聚在一起的错误。相反,应该首先致力于构建团队,然后再让团队基于需要来配置环境。

  2.可以工作的软件胜过面面俱到的文档

  没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档,来对系统及其设计决策的依据进行描述。然而,过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间,并且要使这些文档和代码保持同步,就要花费更多的时间。如果文档和代码之间失去同步,那么文档就会变成庞大的、复杂的谎言,会造成重大的误导。虽然从代码中提取系统的原理和结构信息可能是困难的,但是代码是惟一没有二义性的信息源。在团队成员的头脑中,保存着时常变化的系统的脉络图(road map)。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。

  3.客户合作胜过合同谈判

  不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述,然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件项目的尝试都以失败而告终。有时,失败是惨重的。告诉开发团队想要的东西,然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来,这对于公司的管理者来说是具有诱惑力的。然而,这种操作模式将导致低劣的质量和失败。成功的项目需要有序、频繁的客户反馈。项目的需求基本处于一个持续变化的状态。大的变更是很平常的。在这期间,也会出现整个功能块被减掉,而加进来另外一些功能块。然而,合同和项目都经受住了这些变更,并获得成功。成功的关键在于和客户之间真诚的协作,并且合同指导了这种协作,而不是试图去规定项目范围的细节和固定成本下的进度。

  4.响应变化胜过遵循计划

  响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时,应该确保计划是灵活的并且易于适应商务和技术方面的变化。计划不能考虑得过远。

  2.3 敏捷开发技术的12个原则

1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

2.即使到了开发的后期,也欢迎改变需求。

3.经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好

4.在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。

5.围绕被激励起来的个人来构建项目。

6.在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。

7.工作的软件是首要的进度度量标准。

8.敏捷过程提倡可持续的开发速度。

9.不断地关注优秀的技能和好的设计会增强敏捷能力。

10.简单使未完成的工作最大化。

11.最好的构架、需求和设计出自于自组织的团队。

12.每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

  2.4 敏捷开发技术的适用范围

1.项目团队的人数不能太多

2.项目经常发生变更

3.高风险的项目实施

4.开发人员可以参与决策

  第三章 敏捷开发技术在电子商务软件的实际应用案例

  3.1 案例说明:钢铁贸易企业的网上期货订货系统开发实施

  项目背景:国内某大型国有钢铁贸易企业,其业务形式大部分采用期货订货,客户群也比较广泛,订货时间相对比较稳定,一般集中在月底的10天左右。该企业原来开发了一套适合自己企业运作的贸易企业ERP系统,但是仅仅是在公司内部使用,功能也很有限,不能够很好的和客户进行信息交流,往往客户在集中订货的时候,因为订货量巨大,而且时间集中,所以造成该企业的业务人员忙的团团转,而且经常会发生排队订货的现象,同时由于是期货订货,所以该企业还得向上游供应商订货,这样一来一去,给工作带来极大的不便,也容易造成混乱和漏洞。

  因此,介于用户这样的情况,需要开发一套网上期货订货系统,将订货的整个环节都打通,真正实现24小时订货。减少人工干预,通过和几个系统之间的集成,做到实时的信息流通。但是这样一个系统对于该企业来说,毕竟是第一回,国内也没有相关成熟的案例和模型,所以实施存在极大的风险性。而且其他同行业的竞争对手也在着手打造这样的一个系统,所以尽早建立网上订货系统,对于提高顾客的忠诚度和满意度都是大有裨益的,所以对工期的要求也非常严格。

  根据以上情况,决定采用敏捷开发技术来实施这个项目。

  3.2 项目组织机构

  建立联合实施团队,由电子商务公司的项目实施人员和客户方的关键用户一起构成,统一受客户方的常务副总指挥。

  工作方式:在客户现场办公,在调研的同时做需求,根据系统架构和功能划分,边做设计边做开发。

  沟通方式:每天下班前半个小时,所有项目组成员必须座在一起沟通交流,对每天的工作进行总结和经验交流。每周召开一次推进和培训会议,在不断的开发过程中进行对用户的业务知识,系统知识,和操作的培训,为将来系统的运行维护打下更好的基础。

  3.3 项目实施过程

  第一轮循环实施周期两个月,不但搭建了整个应用的整体框架,还实现了两大品种的单向期货订货流程。

  第二轮循环实施周期两个月,打通了向供应商的期货订货环节,并且实现了另外两个品种的订货。同时逐步将前期做好的系统向用户做推广使用,在不断完善的过程中,对本阶段的项目开发实施做修正。

  第三轮循环实施周期三个月。由开发人员和客户方的关键用户对期货订货系统进行完善和优化。

  3.4 项目实施效果

1. 客户方由于实施了该项目,给订货用户和公司业务员带来很大的便利,效率大大提高,再也没有排队订货的状况,再也没有业务员通宵达旦的处理订货需求,再也不会和供应商之间发生信息失真的现象。系统的快速实施和推进,使得客户对该系统也越来越依赖,同时该公司的销售业绩也率攀新高。

2.由于采用了敏捷开发技术,极大的降低了开发成本,大大提高了开发的效率。尽管在整个项目实施过程中存在大量的变更和修正,但是这样的开发方式可以很有效的避免带来更多负面的扯皮现象。

3.因为项目成员由高水平的开发人员参加,所以对客户的业务理解非常深入,在实际的项目开发当中,不但承担了具体开发的工作,还向客户方提出很多很好的建议改进措施,以便业务更加优化,操作更加顺畅。一方面,客户方从中收益,另外一方面,开发人员的能力也得到了极大的提高。

  第四章 敏捷开发技术在电子商务软件的推广

1. 电子商务软件实施的高风险性

软件开发行业目前同时存在两种情况,它既是一个非常成功的又是具有很多问题的行业。

2. 在跨平台系统的移植上的应用

电子商务系统经常会出现跨平台的移植。重要的一点就是从功能角度讲,移植前后是否一致。一些敏捷开发中的最佳实践也是可以使用的,比如你可以把所有的需求以测试的方式提炼出来。很多项目都是使用这种方式而且非常成功。而且使用这种叠盖式方式,也能够从项目进程的角度看移植进程有多快。

3. 在电子商务软件外包公司的应用

软件外包是非常普遍的。在实践中发现敏捷式开发对外包也是非常有效的方法。实践中敏捷式开发比一般的开发方式估算的方法更快,而且用的人要少一些。

  希望中国更多的软件公司可以采用敏捷开发技术,使我们的软件产业能够得到更加快速的提高和发展!作者: 徐祎 就职于东方钢铁电子商务有限公司,职务为首席项目经理。目前就读上海交通大学MBA班 )

四、敏捷开发常用工具
 
工欲擅其事,必先利其器,能利用工具是人与动物的最大区别。然而,大多数商业化工具价格不菲,已经加入WTO好几年了,再用盗版会给企业带来很大的不确定性,并且盗版用多了,往往会失去一种程序员的自豪感,丢掉一种文化。经过几个月的摸索,本着以下原则,偶选择了一些适合中小企业开发的工具,当作自己的工具箱:
(1)适用于中小型企业,中小型项目(<500万),功能适度

(2)易用性好,具备必要的文档

(3)免费或低价

基于这些工具,慢慢形成了一套敏捷开发过程。

(一)、工具简介

下面简单介绍这些工具,这些工具有些偶已经有相当的使用经验,有些正在使用,有些只是刚选定。除直接用于.net开发的工具中外,还包括一些开发相关的软件设计、项目管理工具。偶的主要开发经验是Web开发,桌面开发和原型开发,对Mobile开发不熟悉,也就没这方面的推荐了。

1,运行平台

常用的也就.net framework 1.1, 2.0, 和mono了,都是免费的。从功能、性能及安装基础来讲,自然.net framework要优于mono了。mono是开源的,.net framework类库可以反编译,从透明的角度讲两者都差不多。如果你想在非windows平台上开发,或者想研究运行时的实现,可以研究mono,否则还是用.net framework吧。

2,服务器

我用过的也就IIS5.0,IIS6.0,Apache加一个mod,还有mono的xsp,这也没啥好比较的,自然首选IIS6.0了。不过IIS虽然免费,但是至少得windows server版本才运行得爽,至少得花几千元。XP上的IIS很不爽,据说也能装全版IIS6.0,不过还是得折腾。开发用的话,用Apache加一个.net的mod,或者mono的xsp,还是挺好用的。Apache的缺点是对新版.net framework的支持较IIS6.0滞后。

3,IDE

tnnd,这个选择空间也很小。首选自然是VS 2003或2005,如果VS 2005速成版将来免费的话,偶就选定这个了,或者选价格并不算高的VS 2005 专业版。可恶速成版、专业版中没单元测试,在这里BS微软10000遍。坚决抵制VSTS版!

其它可选的有SharpDevelop和mono develop。对于不开发Web程序的初学者来说,用SharpDevelop其实也挺不错的,集成的Nant,NDoc,NUnit都是很有用的工具。SharpDevelop没断点调试功能,但熟用NUnit的话可以弥补这一不足。如果对类库理解得比较深入的话,采用SharpDevelop,生产力其实也挺高的――即使是进行Web开发。SharpDevelop的缺点之一是暂时没重构功能,在下一个版本里会有。缺点之二是内存占用比较大,还有性能比VS低得多,大项目,大程序可能不爽。我测试过,用SharpDevelop打开一个大于3M的C#源文件(嘿嘿!是csgl还是tao的,忘了),挂了;用VS 2003打开大概要花几十秒。

btw,我个人认为其实就用记事本写中小型(<3000行)的C#程序,效率其实也挺高的,这时候会更加注意类的设计,思路会更清晰一些,当然,速度会慢一些。

4,类库和文档

类库是.net平台的资产。目前.net下成熟的类库比较少,和java比,最大的不足就是这里了。最常用的类库当然是.net framework了,其它各方面的类库在网上都能搜索到一些。类库的关键资产要素是dll和文档。看文档要看一手资料,第一手资料就是源代码或反编译过来的代码,然后就是各类的原始文档,一般是chm格式的。如果看源代码习惯的话,效率会很高,并且,建议用反编译工具看代码,不建议直接看源文件,原因其一是反编译工具提供了很多有用的附加功能,其二是反编译的代码比源文件更真实。常用的反编译工具是Reflector。

.net下的文档是爽死了,比javadoc的pp多了。因此在写代码的时候应该注意,多写///注释,然后用Ndoc自动生成chm文档,多爽呀。

很多开源项目提供源代码和少量的文档,但它的源代码中有大量的///注释,可用NDoc自动生成chm文档。即使没有///注释,采用NDoc生成文档也是很值的。

5,数据库

MS SQL Server Express版应该是免费的,但标准版和企业版价格还是不低的,还是用开源的好。对功能有要求就用PostgreSql,没要求就用MySql。偶现在是GIS项目用PostgreSql,一般项目用MySql。数据库管理用EMS MySQL Manager Lite和EMS PostgreSql Manag

2016-04-14 13:46:35 wudilaile 阅读数 1065
  • SCRUM敏捷开发视频教程

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

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

     作者:老吴      写于:2016-04-08   公众号:ChanPinLaoWu

 

 以前,我写过一篇文章“追溯软件项目失败的根源”,里面讲述了我在做房地产信息平台建设中遇到的各种困难,有需求不明确、需求蔓延、多团队作战、项目时间紧、人员变动、需求变更频繁、沟通不顺畅、信息传递过程失真……

 在项目开发过程中我们经常会遇到各种问题,为了可以使项目顺利推进,做为产品经理,必须十八般兵器样样精通,就算没有机缘学会乾坤大挪移,至少也能打上一趟擒拿手。

        

今天我要说的就是产品经理的擒拿手——敏捷软件开发

 

在软件工程领域,有过很多软件开发模型,如瀑布模型、快速原型模型、增量模型、螺旋模型、演化模型、喷泉模型、RAD模型、敏捷软件开发模型、XP极端模型。这么多的模型各有各的应用场景、各有各的适用范围,但我认为最实用开发模型还是敏捷软件开发。

 

中国式软件开发思路是什么样的呢?从我接触过的大多软件项目来看,基本都有一个共同特点——就是必须快,客户都是急脾气,恨不得今天立项,明天就要你拿出产品来。

 

面对公司和客户如此快节奏的要求,我们有办法吗?人们从生产、生活中总结出来一套即高效又优质的开发模式——敏捷软件开发。

 

什么是敏捷软件开发呢?

敏捷开发是以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系、而又可以独立运行的小项目,并分别完成,从而实现快速开发的目的。


还是具体来说下敏捷开发是如何实现的?

 

1、 将大的系统拆分成子项目。

  以前我们接受过的思想是立项后先要需求调研、分析,调研后出各种调研报告及需求说明书,需求搞定后,再进行概要设计(UE设计、UI设计、交互设计、数据库设计、框架设计),概要设计完成后再进行详细设计……这样一个周期下来,耗费太长,当进度进入下一阶段,当上一阶段有问题时,会影响到整个项目流程的各个阶段。

 

  而敏捷方法是会将大的系统拆分成一个个子项目,再把子系统拆分成子模块,尽量减少模块间的耦合性、增加其内聚性,这样我们可以把团队分成多个小组,各组可以同时作业。另外,当一个模块需求发生变化时,对其它模块的影响也不会太大,以实现降低开发难度的目的。

 

  在之前提到的房产信息网平台建设中,我们就将系统拆分成自行成交、经纪成交、用户权限管理、建委等外部接口、大宗资产、交易管理、平台后台管理、网站前端等模块分别进行需求讨论,需求讨论后再将各模块拆分成各个对象,对象与对象间只是通过公有变量传递信息,尽量减少与外部对象间产生关系。

 

2、 团队与客户呆在一起

为了降低沟通成本,我们团队所有人员直接开到客户现场,随时与客户沟通,通过面对面的沟通,减少了理解偏差。在项目的各个阶段,我们一直与客户保持零距离接触,随时交流、沟通。通过这种办法,可以第一时间获取需求、第一时间解决问题,减少出错的可能性,提高开发效率,保证开发质量。而且,通过这种方式会更容易取得客户信任,客户能够随时了解到项目的工作状态、工作进度。当相互间具备了信任关系后,余下的工作也会变得轻松、愉快。

 

在房产项目里,我们在客户现场办公,定期开会讨论需求和设计,当有一些小的不确定问题,团队成员会直接找到客户相关人确认。在整个项目周期中没有发生过大的需求变化。

 

总结:与客户面对面的交流,降低交流成本,促进相互信任。

 

3、 用建模的方式沟通

利用模型与客户沟通,通过模型来获取用户需求,而不是通过大量的文档,编写文档费时费力,而且效果不好。实际,对于我们大多数人来说并不喜欢花大量时间看各种文字和参数,而模型则会更直观和立体。这里我说的模型不是单指我们平时设计的原型,它包括用例图、类图、部署图、状态图、活动图、包图、对象图、原型图、效果图、E-R图等,利用不同图形表达出产品的不同维度,使产品丰富而立体。

在房产项目里,我们用原型来与客户讨论需求,用ER图来讨论数据库设计,用类图来表达产品的内部对象及交互,用部署图确定硬件部署环境及网络结构,用活动图来说明信息交互流程,用时序图来表达在时间轴下对象间如何交互。通过各种图表来表达产品,利用这种方法会比较直观,而且当发现错误修改起来也比较容易,不像利用文档方式,修改不方便、维护困难,也不利于阅读、理解。

总结:利用模型来代替文档进行交流。

 

4、 迎接变化

“放眼看那座座高楼如同那稻麦

看眼前是人的海洋和交通的堵塞

我左看右看前看后看还是看不过来

这个这个那个那个越看越奇怪

噢……

 

不是我不明白,这世界变化快”

 

  市场环境是产品的风向标,我们要随时关注市场。为了迎合市场,产品也要随时变化。需求变化、设计变化……各种变化让我们焦头烂额,但做为产品人的我们同样也应该接受改变,只有产品的快速变化,才能很好的迎接未来。我们欢迎变化,只要是合理的,哪怕是开发阶段,需求也同样可能发生变化。敏捷开发允许变化,通过变化给客户带来更大的竞争力。敏捷开发利用图表来记录需求,所有代码都采用模块式设计,将不同功能尽量分割,减少关联。这就是它能够、也敢于迎接变化的原因。

在任何项目在任何阶段都会有需求变化,哪怕是开发后期,也同样会产生,我们避免不了,就要想办法面对。

提到了敏捷的一个很重要思想就是“勇于迎接变化”。就有人说了,你一定不是技术出身的吧。做技术的就讨论变化,最不允许的就是确定的需求再修改。当产品经理与技术人员沟通时,当谈的一个复杂性操作时,经常说:“你确定不会修改了吧,如果你确定需求不变,我就做!”,你要答应了,再找技术修改时哪就等于堵死了自己的后路。实际,哪能一定有不修改的需求呢?我们做产品不也是时刻在迎接市场的考验吗?在大海上航行,当风向变化,我们的大船不也得时刻准备掉头,准备调整。变化,本身就是为了适应,没有变化,就等于没有进步。但作为产品经理的我们,能做的应该是利用自己的智慧和敏锐的市场洞察力,尽量的去感知风向,尽量的控制需求,在需求发现初期就做好充足的调研。怕变化,不是办法,在项目初期就要做好灵活可调整的方案,如果需求真的变化了,我们应该怎么办,这才是敏捷的思想,需求的变化,我们谁能阻拦得了呢?

总结:从项目初期就做好迎接变化的准备

 

5、 尽早、持续的交付可运行的阶段性成果

之前我曾经说过,一个项目的失败,一般不是技术原因,多是因为客户对我们失去信任。我们需要持续的、不断的给客户以信任感,一种是我们在客户现场不断的交流、沟通,让客户感受到我们的热度。同样,还需要尽早的、持续的给客户提供相应的成果物(可运行的产品),让客户看到我们的能力。当然,这样还有另一个好处是,能够把问题提早的暴露出来,不要羞羞答答像个小女人,不敢见人,只有提前暴露,才能提早解决,问题越晚暴露越难解决。

在房产项目中,当天完成的内容在编译没问题后,会把修改的功能部署到平台服务器上,以便于客户随时能够看到变化,了解项目进度。如有问题的话,也能够尽早暴露出来。

总结:为了降低项目风险,尽早交付可运行程序

 

6、 面对面的沟通

最快的交流方式就是面对面的沟通,在敏捷开发中,最提倡的方式是减少哪此冗余的、效率低下的沟通方式,用最快速的方法来直接沟通。让技术人员、设计人员、客户等所有团队成员都在一起办公,减少信息交流的断路,让沟通变得顺畅。

在房产项目中,我们当时是对每一位成员以信任的,当有问题不理解,需要交流时,都是直接找我,我不清楚的直接找客户。当有时,我不在时,同事们也会直接与客户进行沟通,任何人都可以直接获取需求。

总结:直接沟通,减少中间环节

 

7、 可工作的软件是最主要的衡量标准

出再多的文档、再多的中间产物,都没有出结果来得真切。客户最观心的不是中间物,而是成果物。对于敏捷软件开发来说,可以工作的软件是评测开发进度的最主要衡量标准。唱的再好,也不如做的好,做事要落地,实实在在、踏踏实实是敏捷开发的核心,不玩花拳绣腿。

总结:做出可交付的软件是项目的核心

 

8、 保持恒定的开发速度

项目开发是一次长跑,短期内迅速的加速,并不是长跑的方式,我们应该持续的、匀速的跑步方式,这样才能保证团队成员能一直坚持到最后。敏捷开发提供可持续的开发速度,这样不仅团队成员不至于疲惫,也有利于制定项目开发进度,控制开发周期。

总结:项目开发过程是长跑,不要一开始就冲刺

 

9、 定期团队优化

我们会每隔一段时间进行一次团队建设,进行批评与自我批评,找出工作中的问题及影响个人与团队发展的瓶颈。我们通过交流、沟通方式找出团队及成员间的问题,然后进行自我调整,通过不断的优化、升级自有团队,打造出一个能战斗的队伍。

总结:建一个能打硬仗的队伍

 

如果项目管理者能够很好的运用敏捷开发思想,就相当于在游戏世界里拥有了法器,美食世界里掌握了烹饪之道。在敏捷开发里还有许多其它思想,但有的思想本人并不太认同,如用“测试驱动开发”,在中国与在国外不同,在国外有CMMI,对测试要求非常高,测试实际就是质量检查部门、质量控制部门,有着很高的权限,对测试人员也是更加尊重和认同。在国内,公司多重开发而轻测试,从你公司测试人员与开发人员的薪水上就能看得出来,谁更受重视。想让测试人员驱动开发,在目前的现状中有些难以做到。有时我想,前人已经总结出了那么多好的思想,确实应该多学学、多看看、多用用,但拿来的思想并不一定全适用,每种思想都有着自己的成长土壤,不是只要多施肥、多浇水就能长出好庄稼。有时,也要看看,植物的习性,是否更适应我们的环境。


软件产品讲学堂

分享人:老吴和他的战友们

微信公众号:ChanPinLaoWu

2017-12-19 22:29:39 libinhong1016 阅读数 185
  • SCRUM敏捷开发视频教程

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

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

当前在项目管理领域有两种管理方式,即传统项目管理和敏捷项目管理。传统的项目管理需要制定严格的计划,遵循既定的流程,此类管理模式通常采用瀑布式或部分迭代开发模型,遵循着计划进行执行和监控,有复杂的流程进行变更控制,管理活动和决策采取中央集中化的模式。而以Scrum为代表的敏捷项目管理更强调应对变化,更适合于解决复杂问题,适应多变的、未知的环境,在客户需求不明确的时候,以在较短的周期内开发出可用的软件为目标。其以持续交付有价值的产品、满足客户需求并帮组客户建立优先竞争优势,从而提升企业项目、产品投资回报。


一、项目流程
通常完整的项目管理流程可以总结为五个过程组:启动、规划、执行、监控、收尾。
传统的项目管理要对项目的所有过程进行管理和风险把控,并要求在不同环节的有文档输入和输出。项目管理主要是对范围、进度、成本、质量、人力资源、沟通、风险、采购和干系人进行管理,传统的项目管理相当于要对启动每个环节都进行启动、规划、执行、监控和收尾的过程。对每个环节都必须要进行严格的规划,在这一过程中将会产生繁琐的流程和大量文档管理、时间成本和人力成本,而且一旦出现规划以外的变更,都需要经过批准后才能执行改变,很容易出现项目延期的情况。
相对于传统项目管理的繁琐的流程和大量文档管理、沟通调整不灵活等现象,敏捷项目管理则简化的多,其主张团队内部的面对面沟通和交流。以 Scrum 为代表,简单、持续集成、不断交付、价值优先、拥抱变化的原则。在面对时刻变化的市场经济和不断发展的技术时变得十分友好。
敏捷项目管理以项目的战略和投资规划为大前提,不断切分项目计划,最后实现最小周期的可行性版本迭代。对复杂或不明确的客户需求进行合理的分割,最终实现总体上的统一。


二、项目风险
项目风险不确定性在任何项目中都存在,一旦发生,将会对项目造成积极或消极的影响,如范围、进度、成本和质量。
传统项目管理要求项目在规划过程中规划风险管理、识别风险,并且对风险进行定性/定量分析,给出风险应对方案。虽然已知的风险可以在被识别和分析后采取应对措施,不管风险情况是否发生,都要求项目风险管理必须给未知风险或者已知却又无法主动管理的风险分配一定的资源储备。
所以,传统项目管理会要求提供风险登记表,并且记录风险应对措施在处理已识别风险及其根源方面的有效性,完成风险再评估和风险审计,直到风险被降到最低。
敏捷项目管理在进行开发任务风险评估时采用的是相对估算而不是绝对估算,为风险留足了应对空间。同时,Scrum集合了一线人员的参与,在不断的经验分享,集思广益中,将小型团队转化成独立的管理者,不断的发现问题,并将问题进行优先排序,方便后续排期修复。
我们可以通过对流程和风险管理分析对比不难发现,当处于快速发展的社会环境、面临复杂而多变的项目时,传统项目管理方式常常面临进度延期、成本超支、质量不过关、客户满意度低、变更频繁等问题,尤其是在软件开发、新产品研发等未知领域,传统的项目管理无法进行适时调整,每次的改动都将面临层层的审请审批,从而使计划外的改变变的困难重重。
而敏捷项目管理可以说是在原本完善的项目管理流程制度上进行了尺度较大的裁剪,从而对敏捷项目团队成员的适应性,自主性提出了较高要求,可以使项目经理将最大限度的项目资源和活动用于产生增值结果上,并允许客户和终端用户来指定价值、交付价值胜过满足约束、领导团队胜过管理任务、适应变化胜过遵循计划、敏捷项目管理不断快速获取反馈,采用迭代、持续集成、不断交付、简单化、面对面交流等特点,使众多企业开始进行敏捷项目管理。

2019-09-21 19:58:30 Jyh_1124384758 阅读数 12
  • SCRUM敏捷开发视频教程

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

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

内容提要:

软件质量与代码质量密切相关,无论是敏捷开发流派还是传统开发流派。

生命周期模型有瀑布型,喷泉型,迭代型,螺旋型等。

一般比较复杂,对安全要求高的大型项目,应采取传统的瀑布型开发。

对于中小型,需要快速投产的项目,应用灵活的生命周期,采用敏捷型开发。

传统开发流派:

1.刻板而严格控制。

2.很多活动和工件,官僚主义气息浓重。

3.文档繁多。

4.长期而详细的计划。

5.过程高于本质核心的工作。

6.面向过程而不是面向人,把人看成机械方法中的插件。

7.预见而不是适应。

敏捷开发流派:

1.个体和交互胜过过程和工具。

以人为本,注重编程中人的自我特长发挥。

2.可以工作的软件胜过面面具到的文档。

强调软件开发的产品是软件,而不是文档。文档是为软件开发服务的,而不是开发的主体。

3.客户合作胜过合同谈判。

客户与开发者的关系是协作,不是合约。

开发者不是客户业务的“专家”,也不是为了开发软件,把开发人员变成客户业务的专家。

要适应客户的需求,就要通过客户合作来阐述实际的需求细节。

4.响应变化胜过遵循计划。

设计周密是为了最终软件的质量,但不表明设计比实现更重要。

要适应客户需求的不断变化,设计也要不断跟进,所以设计不能是“闭门造车”、“自我良好”。

要不断根据环境的变化,修改自己的设计,指导开发的方向。

 

学习如何在命名,函数,注释,代码格式,对象,数据结构,错误处理,边界问题,单元测试,类,系统,并发编程等方面做到整洁。

 

1.2 糟糕的代码会毁掉公司

糟糕的代码称为wading(沼泽),代码应该及时清理,而不是稍后。

LeBlanc法则:稍后等于永不。

 

1.3 糟糕的代码会使进度的延缓程度变得严重,对代码的每次修改都可能会影响到其他两三处代码,使团队生产力持续下降,趋向于零。

当生产力下降,管理层只会增加更多的人手到项目中,期望提高生产力,但是新人并不熟悉也看不懂这糟糕的代码,所以压力越来越大,最终生产力不断下降趋向于零。

花时间保持代码整洁不但有关效率,还有关生存。

程序员如果遵从不了解混乱风险的经理的意愿,也是不专业的做法,就好像病人要求医生手术前别洗手,说那样会浪费时间。

参考博客:https://www.cnblogs.com/chenliangcl/p/7387525.html

2010-08-24 14:06:00 jiulingchen126 阅读数 491
  • SCRUM敏捷开发视频教程

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

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

Java 项目开发过程中,由于开发人员的经验、代码风格各不相同,以及缺乏统一的标准和管理流程,往往导致整个项目的代码质量较差,难于维护,需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。本文将结合敏捷开发周期短,变化快等特点,介绍如何通过在开发过程中采取一系列步骤来保证和提高整个开发团队的代码质量,并阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,成就高质量的代码,减少测试的投入,并促进整个团队的技能提高,最终提高开发效率和质量。

  如图 1 所示,敏捷开发过程经历需求调研,用例分析和用例分解,进入开发迭代阶段。在每个迭代过程中,可以采用以下五个步骤来保证和提高整个项目的代码质量:统一编码规范、代码样式;静态代码分析(static code review);单元测试;持续集成;代码评审和重构(Review & Refactor)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。 

 敏捷开发中高质量Java代码开发实践

图 1. 敏捷开发中的 Java 代码质量保证步骤

软件工程简介

阅读数 2317

敏捷项目管理模式

阅读数 2703

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