2017-12-03 20:21:19 wk843620202 阅读数 2023
  • SCRUM敏捷开发视频教程

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

    10428 人正在学习 去看看 CSDN讲师
敏捷开发实践总结

前言
敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

什么叫敏捷开发?
敏捷开发(Agile Development)是一种以人为核心迭代循序渐进的软件开发方法。敏捷开发作为CMM神话崩溃后被引入的一套新的软件开发模式。

对概念的理解:
以人为核心:敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。而瀑布开发模型,它是以文档为驱动的,整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据。
迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

敏捷开发的4句宣言
1,个体与交互 胜过 过程与工具
2,可以工作的软件 胜过 面面俱到的文挡
3,客户协作 胜过 合同谈判
4,响应变化 胜过 遵循计划

我对这4句宣言的理解:
产品结果大于形式,先把产品做出来,然后再整理出完善的文档
在互联网软件产品开发过程中,需求是不断发生变化的,需要对原有的计划及时更改,应对变化。

为什么要使用敏捷开发模式?
敏捷开发注重人与人之间的交流和合作,可以快速实现功能,以小步快跑的形式,不断试错,不断调整方向,不断完善产品。总结起来就是:适应变化,不断迭代。

scrum流程图:


scrum 开发中的三种角色:
1,product owner:产品负责人,确定大家要做什么(一般产品经理)。
2,scrum master:scrum的推动者,掌握大节奏的人。
3,team:一般由多个developer组成,开发的主力。

scrum 开发中的三大神器
1,production backlog(产品待办事项列表)
2,print backblog(详细任务列表)
3,sprint burn down(计划走向和实际走向组成燃尽图)

scrum 开发中的四个会议:
1,sprint计划会(理解需要做什么,然后讨论怎么做)
2,每日站会(昨天做了什么,今天打算做什么)
3,sprint 评审会(大家评审sprint产出,然后对待办事项做相应调整)
4, sprint回顾会(讨论哪里完成好,哪里需要改进)

SCRUM敏捷开发流程是什么?

1、Product Backlog(产品需求列表)我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;
2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;
3、Sprint Planning Meeting(Sprint计划会议)有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;
4、Sprint Backlog(迭代任务列表) Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);
5、Daily Scrum Meeting(每日站立会议)在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);
6、Daily Build(每日集成) 做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;
7、Srpint Review Meeting(评审演示会议) 当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);
8、Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;
9,重构 因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。
10,TDD(测试驱动开发)。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。

下面是crum开发流程中的一些场景图:
上图是一个 Product Backlog 的示例,产品需求列表

上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。

上图就是任务看板了,任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)。

作为客户端开发人员在实际的迭代开发过程中,有以下感想和总结:
1,每日的站会迫使人去对昨天的工作做一个小总结和今天的工作计划,无形中让让人做事更加的积极
2,及时是敏捷开发,也要尽可能的有详细的需求
3,在实际的开发过程中也需要写api文档,并且尽可能写上注释,以便于其他人的理解
4,严格按照开发流程去走,但不要流于形式,否则就是浪费时间
5,坚决杜绝以下问题的出现:
需求拍脑袋随意改动,叫快速试错迅速响应用户需求;
代码质量低劣不停出更新版本,叫快速迭代中;
不写正规设计文档,叫降低沟通成本和最好的文档是代码;
领导站身后指挥码农写代码,叫结对编程;
产品质量不靠设计靠测试的,叫测试驱动研发;


参考:


2010-07-20 15:36:00 alvanchen 阅读数 113226
  • SCRUM敏捷开发视频教程

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

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

Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。

敏捷开发宣言——
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
虽然右项也有价值,但是我们认为左项具有更大的价值。

以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践:
Iteration
迭代开发。可以工作的软件胜过面面俱到的文档。因此,敏捷开发提倡将一个完整的软件版本划分为多个迭代,每个迭代实现不同的特性。重大的、优先级高的特性优先实现,风险高的特性优先实现。在项目的早期就将软件的原型开发出来,并基于这个原型在后续的迭代不断晚上。迭代开发的好处是:尽早编码,尽早暴露项目的技术风险。尽早使客户见到可运行的软件,并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。
IterationPlanningMeeting
迭代计划会议。每个迭代启动时,召集整个开发团队,召开迭代计划会议,所有的团队成员畅所欲言,明确迭代的开发任务,解答疑惑。
Story Card/Story Wall/Feature List
在每个迭代中,架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发,交付提前测试(Pre-Test)。当一个迭代中的所有Story开发完毕以后,测试组再进行完整的测试。在整个测试过程中(pre-test,test),基于Daily build,测试组永远都是每天从配置库上取下最新编译的版本进行测试,开发人员也随时修改测试人员提交的问题单,并合入配置库。
敏捷开发的一个特点是开放式办公,充分沟通,包括测试人员也和开发人员一起办公。基于Story Card的开发方式,团队会在开放式办公区域放置一块白板,上面粘贴着所有的Story Card,按当前的开发状态贴在4个区域中,分别是:未开发,开发中,预测试中,测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card,更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
在开发人员开始开发一个Story时,ta需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,同时开始自动化系统测试脚本的开发。
Standup Meeting
站立会议。每天早上,所有的团队成员围在Story Wall周围,开一个高效率的会议,通常不超过15分钟,汇报开发进展,提出问题,但不浪费所有人的时间立刻解决问题,而是会后个别沟通解决。
Pair Programming
结对编程是指两个开发人员结对编码。结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,一些大的方向不至于出现偏差,一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量。
CI/Daily Build
持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中,自动化编译程序每天至少一次自动从配置库上取下代码,执行自动化代码静态检查(如PCLint),单元测试,编译版本,安装,系统测试,动态检查(如Purify)。以上这些自动化任务执行完毕后,会输出报告,自动发送邮件给团队成员。如果其中存在着任何的问题,相关责任人应该及时的修改。
可以看到,整个开发组频繁的更新代码,出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉,取决于自动化单元测试和系统测试能力是否足够强大,特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作,则新合入代码的隐患将很难被发现,并遗留到项目后期,形成大的风险。而实际上,提升自动化测试的覆盖率是最困难的。
Retrospect
总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。
ShowCase
演示。每个Story开发完成以后,开发人员叫上测试人员,演示软件功能,以便测试人员充分理解软件功能。
Refactoring
重构。因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代,每个跌倒由拆分成很多Story,从架构的角度看,这些Story必须在是有很强的继承性,是可以不断叠加的,不至于后续开发的Story完全推翻了早期开发的代码和架构,同时也不可避免的需要对代码进行不断完善,不断重构。
TDD
测试驱动开发。正如上面讲的,迭代开发的特点是频繁合入代码,频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。

敏捷方法反思:
自己参与的敏捷开发项目总的来说不是很成功,这可能也是业界遇到的通病:
1、对于全新的软件,在项目早期测试人员就参与并实现自动化测试脚本,但实际上软件的界面等非常不稳定,导致测试人员返工的工作量很大。
2、对于全新的软件,资料人员过早参与,后期返工工作量大,原因同第一点。
3、自动化系统测试工作量大,测试人员投入大量的精力在使测试自动化起来,而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样,自动化系统测试脚本也多流于形式,测不出深层次的问题。
4、代码动态检查工具执行不理想,流于形式。没有人对Purify有深刻的理解和应用经验,报告中查出来很多告警,但不知如何消除。
5、由于快速搭建原型,没有在架构上进行严谨的设计,导致后期一直堆砌代码。
6、异地开发模式下无法实现快速构建、快速交付,团队普遍感觉很疲惫。
7、敏捷开发不提倡加班,但实际上不管是CMM还是Agile哪一种开发模式跟是否加班都没有必然联系。

2018-05-24 11:20:45 runOnWay 阅读数 458
  • SCRUM敏捷开发视频教程

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

    10428 人正在学习 去看看 CSDN讲师
    一、敏捷开发是一种开发方式
    敏捷开发,英文是Agile Development,是一种以人为核心、迭代、循序渐进的开发方式,是一种软件开发的流程。它会指导开发人员用规定的环节去一步一步完成项目的开发。由于它采用迭代式开发,所以它主要的驱动核心是人,而不是像瀑布模型那样,以文档为核心。
    敏捷开发更注重的人与人之间的沟通、交流。它认为个体和交互胜过过程和工具,可以工作的软件胜过面面俱到的文档,客户合作胜过合同谈判,响应变化胜过遵循计划。虽然右项也有价值,但是敏捷开发认为左项具有更大的价值。
   迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样一个周期就是一次迭代的过程,同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
   二、几个重要的名词
   Scrum:是一个橄榄球专业术语,意味并列争球。用了这样一个词在敏捷开发中,可以证明,在整个敏捷开发的过程中,团队中的每一个人都要像橄榄球运动员一样迅速、富有战斗激情,在这种氛围下才会达到敏捷开发快速迭代的要求。
   XP:极限编程,是一种轻量、高效、低风险、柔性、可预测、科学而且充满乐趣的开发方式。它强调在更短的周期内,更早地提供具体、持续的反馈信息;在迭代地进行计划编制,首先在最开始迅速生成一个总体计划,然后在整个项目开发过程中不断的发展它;依赖于自动测试程序来监控开发进度,并尽可能早地捕获缺陷;依赖于口头交流、测试和源程序进行沟通;倡导持续的演化式设计;依赖于开发团队内部的紧密协作;尽可能达到程序员短期利益和项目长期利益的平衡。

注:Scrum和XP是敏捷开发的两种方式,Scrum偏重过程,XP偏重实践。

    PO:Product Owner,产品负责人。主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。
    SM:Scrum Master,流程管理员。主要负责整个Scrum流程在项目中的顺利实施和进行,以及扫清挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。
    ST:Scrum Team,开发团队。主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5-10人左右,每个成员可能负责不同的技术方面,但要求每个成员必须要有很强的自我管理能力,同时具有一定的表达能力。成员可以采用任何工作方式,只要能够完成开发任务。
   PB:Product Backlog,产品需求列表。由PO负责,按优先顺序排列产品需求。
   Sprint:冲刺。指一次迭代,每次迭代的周期大约是一个月。
   INVEST原则:是缩写组成,Independent独立的、Negotiable可协商的、Valuable有价值的、 Estimable可估计的、Small小的、Testable可测试的
   三、Scrum开发
   1.首先由PO,制定PB。
   2.ST根据PB,进行工作量的预估和安排。在工作量预估中,可以使用计划筹码,每个筹码代表着完成一个故事的时间,是一个故事点的倍数,一般有1、2、3、5、8这几个数字。每个人对工作的预估在亮出筹码之后,如果有不同意见,不能折中选平均数,而是要各自说出理由,再重新进行预估。
   3.有了PB列表,就需要通过Sprint Planning Meeting来从中挑选出一个Story作为本次迭代完成的目标,然后将这个Story进行细化,一个优秀的Story要遵循INVEST原则,形成Sprint Backlog,然后再继续细化,争取每个细化的任务能在2天内完成。
   4.在ST完成PM上选出的Sprint Backlog过程中,要进行Daily Scrum Meeting,每次会议要控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报昨天完成的工作和承诺今天要完成的任务,如果遇到问题也可以提出问题,表述结束后,要更新自己的燃尽图。
    5.要做到每日集成,每天都要有一个可成功编译、并且可以演示的版本,这就凸显出了持续集成的重要性。
    6.当一个Story完成,也就是Sprint Backlog被完成,就代表一次Sprint完成,要进行Sprint Review Meeting,PO和客户都要参加,每个ST成员都要展示自己完成的任务。
    7.最后就是Sprint Retrospective Meeting,所有成员轮流发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中。

   敏捷开发的快速迭代有很明显的优势,但是对团队的要求也更高,尤其是按时完成任务,对自己的承诺负责这点,如果要保重能够按时完成任务,就要在预估工作量上更加严谨,而不是取折中这种方式,每个人要更加坚持自己的立场,只能够因为合理的逻辑做出计划。
2012-09-20 14:08:29 violet200211 阅读数 4977
  • SCRUM敏捷开发视频教程

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

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

        9月份的12日下午、1314两天,参加了第七届敏捷开发大会,虽然自己没有做过敏捷项目,但因为现在“敏捷”是流行词,想看看自己公司的项目能不能用,所以就拿着领导的大洋,风风火火的参会去了,接受各位牛人的轮番知识轰炸。

        Neal Ford Agile Architecture& Design

        总觉得演讲的内容与题目不太相符,在讲主要内容之前,引用了很多名人名言,比如戴明的“坏的流程会打击好员工的积极性”,泰勒的科学管理理论等,之后,主要讲了4部分内容:

        1、沟通的重要性,每个团队都要找到适合自己的沟通方式,面对面的沟通时,站在白板前,语言+文字的沟通可能是最好的。

            沟通一定要有反馈,比如敏捷中可能有即时的反馈,每天的反馈,每周的反馈等等。

        2、为什么结对编程有效

            这个最主要的论据是一个人很难同时使用左大脑和右大脑,而结对编程则可以分工,达到同时使用的目的。

        3、反馈与沟通如何结合

            这部分,讲的是具体的实践,比如在构建的时候放一点歌,在办公室里边放玩偶,在工作中创造乐趣等。

        4、为什么敏捷开发是有效的

             因为沟通是闭环的,沟通是高效的,工作是快乐的,所以敏捷开发是有效的。

        回答的问题:

Q1:结对编程时,对人员水平有要求吗?

A1:要尽可能水平相近,以提高生产力为目标

Q2:是否要保持结对的稳定?

A2:最好1~2天换一次,以保持信息的可传承行

Q3:如果是异地,可以形成结对吗?

A3:尽可能在本地,可以以互相出差的方式形成本地结对。

       王红超:大规模敏捷转型

       主要讲的是华为如何开展敏捷转型工作的,听完之后的第一感觉是:“有钱真好”!

      华为是以“业务目标达成”为导向推荐的敏捷,并且把敏捷提高到了战略的高度,在这过程中请了很多业界的牛人做咨询和辅导。

       华为的敏捷转型,简单来说可以分为两步:

       第一步:统一对敏捷的认识

              敏捷 = 理念 + 优秀实践 + 具体应用

              其中,理念指的是敏捷的核心思想,优秀实践指的是经验的积累,而具体应用,指的是能够结合自身灵活应用才是真正的敏捷

              在敏捷中,领导的作用是“激发”团队,而成员是全方位的积极参与者。

        第二步:建立敏捷开展辅导队伍

                建立公司级和产品线级两级敏捷教练体系,引进几乎业界所有的顾问。采用开展日常培训、讲座等等;每年组织年度软件工程大会进行优秀实践的分享;建立内部交流社区等方式促进内部沟通。

        华为在引入敏捷的过程中,也遇到的很多问题,比如新员工大量进入对原来团队的冲击,能力的稀释;研发过载,需要面对交付压力、能力不足、沉重的技术债务等。

        最后的总结是,引入敏捷,一定要务实、理性。

         Ritchard Markelz Global AgileStrategy

        主要讲了敏捷中的领导力及创新,还有为什么要用敏捷。

        敏捷中的领导力主要体现在,把团队看成整体而不是层级,在组织中创建授权,把优秀领导从合格领导中区分出来。将焦点集中在优秀实践和成功模式上,采用激励式询问方式,如什么事我们做的好的,什么是有效的。

      使用敏捷的一个很重要的原因是:客户时敏捷的,客户关心的是如何快速解决问题,因此灵活性和适应性才是其中的关键。

      回答的提问:

Q:敏捷方式中,计划怎么做?

A:分层,更高层的做传统的计划,不具体到细节。

       荣浩:百年历史看管理

       不得不说,荣浩真的是才子,将管理的历史帮我们梳理的简单而清楚,把这些人和事都按照顺序列出来的话,应该就能理清大概的思路了。(理不清楚的,去了解一下这些名字代表的具体事情和理念就知道了)

        亚当·斯密、泰勒、亨利·福特、法约尔、韦伯;摩登时代、霍桑实验;休哈特、PDCA;彼得·德鲁克、列维特、钱德勒;权变理论。

        80年代的日本制造、PDCATDD、精益;90年代的组织瘫痪、流程再造,哈默和钱皮、彼得·圣吉。

        21世纪以来,扁平化的组织结构、全球供应链的挑战及国内最严重的管理的道德问题等等。

       所有的这些都说明了,管理只有恒久的问题,没有终结的答案, 敏捷也不过是解决现在遇到的问题的一个方法而已。

        乔梁:组织转型的十个要点

       主持人介绍时说,这位是传说中的乔帮主,无奈本人孤陋寡闻,愣是没听说过。

       乔帮主说,敏捷实践中,大约有75%的失败率,其中文化变革的范围是其中的原因之一。

       乔帮主还说,因为用英文表达比用中文更好理解一点,所以用英文表了。

      组织文化变革中,只变革需要变革的部分,因为人天性是害怕变革的,只有不满意程度达到一定程度时,才会变革,而变革时,应该先unfreezingunfrozen and moving to a new state 之后再 refreezing

1、Align with business urgency。只解决TOP3的问题,不要去做那些True but useless的事情。

2、Proper leading team。结论性的东西才能推出。

3、Quick assessment。谁执行谁做决定。

4、Define the roadmap and specificactions。

5、Pilot team carefully。因为这个与信心有关,一定要考虑人的积极性和能动性。敏捷中最主要的是开放的心态。

6、Be aware of antibody education。注意生产率与teammotivation 之间的关系。

7、Work as a whole。把团队所有成员弄到一起,坐在一起,对所有的实践,都要体验而不是判断。

8、Visualize everything

9、Metrics is important。结果和过程的数据一定要有,这样才能知道底细和过程。

10、Just give it a try。敏捷都是经验主义者,所有的事情都需要试一下并给出反馈。

        钱安川:可视化——敏捷项目管理

        钱老师其实就讲了一个故事,怎么把项目管理用数字表达出来,设计问卷的过程中和问卷的使用过程中遇到的问题,其实跟敏捷不敏捷没有太大的关系。

       仝健:共识、乌合之众和可视化

        仝老师主要通过一个经典的博弈“协同谬误”来说明信息共有的重要性,讲在项目中,信息不共有会产生的问题及信息共有会带来的收益。

        常见的信息共有的方法包括发布信息、公布标准、设定目标和制定规则。

        在项目中,把权限放给每个人,会更有自主性和责任感。

        如果不能解决问题,就把问题暴露出来,让能解决问题的人看到它。

        杜伟忠:利用可视化的工作方式打破部门壁垒

        可视化主要解决部门之间沟通成本高、管理层因为项目过程不透明而对项目组不信任的问题、每个部门都想着自己部门利益的问题。

        张忠:以客户价值为中心的公司级敏捷开发

        张老师主要讲了用友是如何推进敏捷的。在软件行业,研发人员总是很被动的,而敏捷让大家的参与度提高了。而要推进敏捷,必须把敏捷变成一种公司级的价值观。

       用友从2009年开始推进敏捷,已经有3年的时间,2009年的主题是“快速响应”,因为市场与客户都希望能快速响应;2011年的主题是“效益化研发”,公司内技术人员感觉可能不是很明显;2012年的主题是“全面推进”,重在吸引大家,建立内部俱乐部,专题推进等,转变研发视角,更关注市场价值,这时候要站在巨人的肩膀上而不是站在腰眼儿 上。

       用友在敏捷的过程中,也遇到了很多问题,如开发人员压力大(负面反馈具体而大量,实现价值与研发交付无关联等);交付物难以进行实际客户交付;多角色间协调一致的耗费比较大;保证持续发布能力的敏捷工程方法支撑不足;缺少全面支持的研发管理平台等。

       敏捷应该采用阿米巴的方式,自我生长,自我分裂,自主经营。

       如果敏捷最后能做成有趣的研发、与客户紧密关联的研发、幸福的研发就算成是成功了。

        王宇:如何引导团队快速建立信念

        王老师教会我的第一句话是“当学生准备好了,老师自然会出现”,以前总觉得自己是幸运,总是能够在希望学到什么的时候及时出现可以教会自己的人,看到这句话之后突然发现,原来在这件事上,大家都是一样幸运的。同理,当自己没有准备好的时候,即便老师在眼前晃来晃去,在耳边喊来喊去,仍然不可能有收获一样。

        亨利·福特曾经说过,我需要的是一双手,但他带给我一个脑袋。而在我们现在,员工带来的不仅是一个脑袋,更包括了他们的家人、他们的经历、他们的懊恼和忧愁。

        作为敏捷项目的领导,要有能激发出团队信念的信念。而团队最基本的信念,在Scrum里边是:开放、专注、勇气、承诺、尊重,XP中则是:简单、沟通、有序。

        要记住,每个人都是部分正确。教练的作用是在舒适的区域外迈一步。

        阳陆育:做减法的艺术

Louis 主要讲的是CMMI3及以上团队中,如何实现敏捷转型,主要讲了几个公式:

1、自适应流程 = 选择团队熟悉的流程 + 不断修正

2、PMO如何管理 = 敏捷项目管理≠监管

                               = 提供暴露问题的环境 + 专业的流程优化服务

3、质量成本 ≠ 测试成本

                       = 沟通成本 + 团队的学习成本

4、成功的项目 ≠ 做完了的项目

                          = 客户需要的产品 + 用户可接受的方案 + 团队可接受的质量

5、协作 ≠ 消除分工

              = 各司其职 + 紧密沟通

6、开发 ≠ 编码

               = 正确的理解问题 + 提出可接受的设计 + 完成可交付的代码

       在CMMI3及以上团队中做敏捷,要使用做减法的艺术,要提取现有流程资产引入敏捷基础实践逐步剔除控制式监管 + 构建学习型组织 + 引入更多工程实践,其中学习型组织是关键,敏捷之所以能敏捷,就是因为每个人的能力都在提高,而所谓的学习型,则是指把某些人的知识传递给别人并固化下来。

       把现有流程当成资产对待,按照以下方式处理:

1、文档:有区分的对待,有计划的简化。尽量避免write only的文档。

2、检查点:权力下放,减少或者延迟检查。让每个做事情的人成为检查的执行人。

3、测量域:明确目标,服务导向。根据团队的实际情况制定测量域,测量结果要纵向对比而不是横向对比。

4、测试:是开发协助型测试还是验收型(放行性)测试?前者的作用是改进生产的正确率,测试人员是开发人员的助手。

2018-10-23 10:10:39 dongjinkun 阅读数 560
  • SCRUM敏捷开发视频教程

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

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

在备战软考做题的过程中,发现敏捷软件开发方法考的还算比较多,而自己也一直没弄明白!

敏捷开发方法

极限编程XP 是一种轻量级,高效,低风险,不能使编码速度加快
水晶法 每个不同的项目都要一套不同的开发策略,约定和方法论
并列争球法 运用了“迭代”的方法,把每段时间(例如30天)一次的迭代成为一个冲刺,并按需求的优先级别来实现产品,有多个自治组织和自治小组并行的递增来实现产品。
自适应软件开发  

 

 

 

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