2011-09-05 16:30:40 CHOOSEMYLIFE 阅读数 413
  • SCRUM敏捷开发视频教程

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

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

最近比较流行敏捷开发

我也深入了解了一下

自身权力有限 

也就只能小用了一把

也起到了一点效果

但是遇到需求总是朝令夕改的情况还是毫无办法


敏捷开发的口号是拥抱变化

但却感觉是给了不专业的设计人员或者不懂敏捷开发的人需求无限变化权力


我觉得需求不明确

应该从需求不明确本身找原因,找问题,并且解决问题

尽量让不明确的需求变成明确的需求

而不是把开发制作也拉进来,一起为这个不明确的需求一起浪费时间,金钱和人力

而且每次需求的突然变化,所带来的后果都是由开发人员来承担,就是加班

而提需求的设计人员承担了什么后果呢? 没有


一个好的程序员能顶10个一般的程序员

同理,一个好的设计人员或策划能顶10个好的程序员,100个一般的程序员

因为差的设计会让项目不停的重做,不停的修改,不停的做无用功,甚至项目失败,这是很恐怖的

所以好的专业的策划对一个项目是多么的重要


最后我在想,如果敏捷开发拥抱的是不变,会是一个什么的情况?









2019-01-22 19:56:09 KamRoseLee 阅读数 222
  • SCRUM敏捷开发视频教程

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

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

软件开发遇到重要问题:

  • 学习  是软件开发中一大瓶颈
  • 如何让成员积极主动,负有责任感,能解决问题,并凝聚成一支高效的团队?

敏捷开发历史:

  • 敏捷开发并不现代   起源于20世纪30年代的一些项目(美国航天局水星计划)
  • 最早记载使用在20世纪70年代  最早的有记载的使用迭代和增量开发的主要项目之一,是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码,进行得非常成功。
  • 1976年,第一部阐述敏捷方法的书籍    Tom Gilb在他的著作《软件度量》(“Software Metrics”)一书中阐述了他的迭代和增量开发实践
  • 20世纪80年代正式定义迭代开发螺旋模型  20世纪80年代在1895年,巴里贝母(Barry Boehm)正式定义了使用迭代开发的螺旋模型
  • 20世纪90年代推荐使用迭代和增量开发的出版物和文献显著增加
  • 2001年二月敏捷开发宣言后形成敏捷联盟  一组由17位在DSDM,XP,Scrum,FSD等领域的专家组成的代表团齐聚美国犹他州,寻找这些方法的共同点。最终,这些专家制定并宣布了敏捷开发宣言。由此形成了现在我们所认识的敏捷开发和后来的敏捷联盟

敏捷开发介绍:

敏捷开发(agile development)

     是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,

但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

敏捷开发由几种轻量级的软件开发方法组成

   它们包括:极限编程(XP),Scrum,精益开发(Lean Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Cristal Clear)等等

敏捷开发原则和方法

1)迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短,通常为一到六周。

 

  1. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。
  2. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。
  3. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成, 有些项目则每天都在这么做。

5)开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。

敏捷开发实践都基于一个简单的周期

  1. 测试先行开发1)写一个失败的测试2)编写代码让测试通过3)运行测试---通过了吗?4)如果测试仍然失败,回到步骤2
  2. 日常工作流程1)在每日的站立会议中,设置团队需要完成的任务2)执行这些任务3)第二条对任务的执行情况和遇到问题进行沟通4)总结经验教训,调整第二天的工作计划
  3. 测试驱动需求1)将需求转变为测试 2)进行软件开发 3)运行这些测试,如果测试通过,任务完成,如果没有回到2
  4. 迭代 1)设定一个 完成状态 2)找到一系列需求,构成迭代待办事项,并承诺完成3)一一解决待办事项4)迭代结束,一一检查每个事项是否达到,“完成状态”,如果是,标记完成,否则将他们放回待办事项中,以待日后处理。
  5. 演示 通常在迭代末进行演示,客户可以利用这个机会,验证针对预期需求的实现是否真正地解决了当前的问题 1)确定需求的业务价值  2)定义需求 3)实现需求 4)验证实现的功能是否满足业务需要
  6. 回顾1)确定团队的工作方法 2)在迭代中应用这方法 3)反思总结实践过程中的好坏方面 4)找到一些更加有效的方法,确定什么时间,谁负责实行
  7. 版本发布 1)创建该版本的远景,并设定需要达到的业务目标2)创建该版本的待办事项3)通过多次迭代来发布该版本4)为部署,并为下一个版本收集反馈信息
  8. Scrums的Scrum会议  会议来进行信息同步,通过沟通和讨论来展示自己的进度和解决遇到的问题,这能提高大家感知整个企业的变化,从而积极应变
  9. 管理检验 1)与那些产品所有者或者项目负责人一起,定义项目或者是某个版本的验收标准 2)在团队开发过程中,保证这些验收标准随时可见,使项目始终朝着期望的方向发展3)回忆会议中,一起评估标准4)让产品所有者或项目负责人和团队一起工作,保证在每一个迭代中针对这些验收标准进行检验

几种敏捷实践:

  1. 自组织团队  整个团队紧密合作,同心协力,主动承担责任,竭尽所能去完成工作,响应各种变化
  2. “联合驻扎”团队  团队成员在一起工作,经常进行小组讨论,随时可以听到各种谈话,潜移默化中就了解到发生的事情
  3. 跨职能团队  来自不同背景的人组成一个团队,自始至终地进行开发来解决一个问题。因为大家在一起紧密协作,各自的专长就会得到分享和传播
  4. 结对编程   两个人一起,齐心协力完成一些任务,这个是共享经验和专长的极致体现
  5. 信息辐射器  这种大幅图表存在的唯一目的就是把重要的信息传达给每一个人
  6. 唤醒式文档  为了更好的沟通,敏捷团队成员共同撰写文档,日后每次阅读这些文档,都可以唤起大家对讨论内容和相关背景的记忆。
  7. 站立会议 在敏捷团队中,大家每天都会彼此交流自己完成什么,遇到了什么问题,明天计划如何,这就保证了所以成员步调协调一致

敏捷实践的主要动力来源:

主要动力来源:带给客户价值

  1. 缩短上市时间
  2. 增加产品使用行(市场价值)
  3. 提高产品质量
  4. 提高灵活性
  5. 增强透明度
  6. 降低成本
  7. 延迟产品生命周期
2019-10-25 11:01:17 janeqi1987 阅读数 22
  • SCRUM敏捷开发视频教程

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

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

敏捷开发

 

瀑布开发

 

很多支持敏捷的同学会说瀑布缺乏与业务的沟通和迭代次数,所以如果在项目的后期才发现要更改需求的话,则项目可能会失败或需要重新启动。这张图好像也解释了瀑布开发经常所面临的困境。

“瀑布”对“敏捷”的驳斥

敏捷本身不是项目管理框架,也不是“方法论”。它是一套与产品开发相关的原则和价值,特别是互联网产品经常会采用敏捷的方法来进行开发。但是,有一些基于敏捷原则的方法,这些方法是产品开发方法,而不是项目管理框架。

说到需求变更,瀑布也可以走需求变更,提变更申请,按照环节一步一步走,去规划工作量。虽然比敏捷是要慢一些,但是我整个流程是可靠的!为什么就说瀑布是死板的,不符合时代的呢?

似乎瀑布的做法也没有错误,我们何不按照这样的步骤,来完成我们的工作呢?这样的过程听起来是如此的可靠。看,我有明确的阶段;看,我有明确的审批;看,我有明确的变更流程。以瀑布模式进行开发的项目有这么多,已经证明了这是一个有效的实施方法,难道不是么?

另外被敏捷所诟病的瀑布项目经常失败通常是发生了非常严重的错误情况下才会产生。实际上只有在对项目的控制很差的情况下才会发生这种情况。瀑布型项目没有迭代和用户的多次反馈也是不正确的 - 很多项目可以通过产品原型图的方式和业务部门确认操作的流程,只是很多项目中并没有使用这种方法。

 

焦点碰撞

敏捷模式,两周一个迭代,每个迭代都能进行一定功能模块的交付,让用户更早的看到交付物,虽然只有部分,也可以让用户来提出自己的看法,产生变更的时候,开发人员也可以在下个迭代中进行修改,让用户进行再次的确认。

从这样看来,两者的碰撞就是在交付的及时性上与面对变更的成本上,所看到有极大的变化。瀑布在交付阶段比较靠后,交付的模块比较完整,在面对变更的时候,变更影响范围就比较大,变更的成本就极大。问题发现的阶段越靠后,解决问题所需要付出的成本就更高。这样,就体现出来了敏捷对瀑布在这样的情景下面的优势。

时间和成本,看起来就是敏捷和瀑布在选择时主要考虑的两个方面。未来能更好的指导未来的选择,下面还列出了更详细的敏捷和瀑布的优劣势。

I 敏捷开发的优势

开发的阶段性成果会在开发过程中尽早的进行审查,项目的风险会降低;

适用于需求不明确情况,因为需求不明确,所以需要在不断迭代的过程中来逐步理清需求。

灵活性较高,几乎可以在任何时间进行需求变更;

敏捷鼓励开发人员与业务用户之间进行多频次的沟通,业务用户的不合理需求以及开发人员的错误理解都会在这些频繁的沟通中进行不断审查和更新,

敏捷的协作通常要高得多,通常能开发出更高质量的产品;

适用于快速变化的项目,特别是面向前端业务人员的CRM项目更容易根据业务的变化而变化。

I 敏捷开发的劣势:

敏捷的概念接受度还不算太高,初次尝试可能不会非常成功;

最终交付的内容无法预测,预期和实际完成的内容经常会有很大差异;

敏捷需要高水平的协作以及开发人员和用户之间的定期沟通。 业务和IT人员在沟通前需要做大量的准备工作,但很多情况下业务的沟通时间无法保证;

当存在乙方供应商的情况,敏捷会面临更大的挑战性。 客户通常希望尽早了解他们的项目投入。 预估项目时间和成本难度较高;

在敏捷项目中,最大的问题可能是业务部门永远不希望有最终的截止时间。

I 瀑布开发的优势:

在管理良好的项目中,瀑布可以在早期提供交付的信心;

项目团队成员不需要在同一地点频繁沟通;

在需要大量的设计或分析的情况下瀑布是一种更合适的方法;

如果在基本产品开发之外存在许多接口和依赖关系,瀑布式项目会使用工具来建模和管理这些接口和依赖关系。

I 瀑布开发的劣势:

许多企业和业务人员确实不容易在前期定义清楚需求,早期计划中所依据的假设需求可能存在很大风险;

沟通的风险要高得多 - 特别是很多项目都是前期单向的沟通,后期项目和业务人员的预期差别很大;

瀑布项目的风险一般都很高,因为基于无效假设基础上的需求可能会让项目无限度扩大。 所以你会看到很多瀑布项目都出现成本超出预算或延迟的情况。

结论:

敏捷和瀑布的实施方法差别还是很大的,瀑布几乎可以应用于任何类型的项目,尤其是大型的项目。

敏捷方法今年来越来越受欢迎,尤其是当前SaaS软件当道,特别像Salesforce这样自带开发平台的SaaS产品可以非常容易的搭建初始原型并进行快速迭代,所以我们才会看到有越来越多的企业采用敏捷的方式来进行项目实施。总的来说敏捷并不能完全替代瀑布,它只是给了我们另外一种好的选择。

2015-09-04 11:34:48 u011790275 阅读数 4397
  • SCRUM敏捷开发视频教程

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

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

谈到敏捷开发, 许多人纠结的第一个问题便是: User Story 如何的划分? 更有不少人, 一遇到在 User Story 上有延迟交付或交付的质量不佳时, 便说是因为 User Story 的拆分不对, 就整天在纠结所谓 User Story 颗粒度大小的问题。

然而, 事实的真相是如何呢?

首先, 先从敏捷开发实践的本身说起:

敏捷开发之所以强调 “敏捷” , 主要是希望藉由 User Story 的划分 , 能帮助开发人员, 有效的管理版本开发上需求的复杂度, 而使开发人员能在最短的时间内 “发现自身的问题”, “发现自身的不足”, “发现因自身的问题、不足与外部的变化所造成的风险” 。

所以, 敏捷开发的核心基础, 最强调的便是: “User Story 必需要是可测的” 与 “User Story 间的持续集成” 。

接下来再谈一下, 人的思维、人的一念之间是如何严重的扭曲了敏捷开发?!

当一个开发人员, 他 (她) 只是在证明自己“没做错事” 时, 而不是在 “发现自身的问题” 时, 那在拆分User Story 上, 便会发生这些场景:

1.       将 User Story 拆的需 3 周甚至一个月以上才能完成; 这样的思维与作法, 只是在证明自身所负责开发的 User Story 是可被 “测试的” 。但, 却只是被 “测试人员可测试的” ; 也就是说, 有的开发人员希望将 User Story 要拆的 “够大”, 只是要掩饰自身无法做 “有效” 的 “开发者自动化测试” 罢了。

2.       将 User Story 拆的只需完成单一且极简单的 “功能点”; 这样的思维与作法, 只是在证明自身所负责开发的 User Story 是可被 “如期交付的” ; 也就是说, 有的开发人员希望要将 User Story 拆的 “够小”, 只是要掩饰自身无法理解与掌握 “完整的业务场景” 与 “软件架构” 罢了。

所以, 我们要纠结的不应该是所谓 User Story 颗粒度大小的问题; 而是应协助开发人员能诚实的发现与面对自身的不足与所面临的问题, 并给予开发人员适当且必要的赋能与协助。因为, 唯有如此, 开发人员的能力提升了, 则开发人员便自然能在 “更短的时间内” “真正有质量 (有品味)” 的完成 “复杂度越高” 的User Story。

所以, 我们要纠结的不应该是所谓 User Story 颗粒度大小的问题; 我们应该真正专注的是: 如何能使开发人员能在 “更短的时间内” “真正有质量 (有品味)” 的完成 “复杂度高” 的 User Story。

 

 

2011-07-31 21:32:06 wireless_com 阅读数 1753
  • SCRUM敏捷开发视频教程

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

    10431 人正在学习 去看看 CSDN讲师
最近帮助一个团队完成转型,实现敏捷开发流程。我发现消极因素主要来源于两个方面:员工和管理人员。

员工不愿意采用敏捷方法主要归结于意识的缺乏和对未知的恐惧。

员工不了解整个项目或者产品的整体规划,尤其是公司愿景和发展路线图。紧迫感不是来自于使命感,而是来自于项目的时间压力。工作流程的创新与产品创新同样重要。而对新员工以及工作经验较少的员工而言,对未知的恐惧占有很大的比重。用新方式开发的话,如果做不好同事会怎么看?会不会丢掉饭碗?因此,关于敏捷的培训和现在支持非常必要。

管理人员不愿意采用敏捷方法主要归结于对权力弱化的担心以及有效时间的匮乏。管理人员在敏捷开发中的角色是什么?做product onwer还是scum master?或许都不合适?那职业发展怎么办?这个问题较为复杂和隐蔽,需要在组织和绩效层面给予支持。而一个重要的借口叫没有时间,这往往是由于安于现状,不清楚实施敏捷到底会带来什么好处,因此,让他们参与产品或解决方案的设计往往是个不错的选择。

关注团队的负面因素,并有效地解决消极抵触问题,影响着敏捷实践的成败。

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