2012-10-03 11:42:50 JJiaoAo 阅读数 14
  • SCRUM敏捷开发视频教程

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

    10429 人正在学习 去看看 CSDN讲师
[size=medium]
[b]共振[/b]
共振是以无我、无住精神推广敏捷时的具体做法。

很容易被简单理解为循序渐进,但这样理解不全面,这也是为什么会出现“共振”这个奇怪的词汇。之前的无我、无住,也都很难找到完整替代的又没有歧义的词汇或语句。

[b]循序渐进[/b]
很多人都梦想有一家企业,高层领导支持,企业文化适合,队员个人能力超强,团队合作顺畅,就只差自己这个项目经理去推广敏捷。但睁开眼一看,自己的企业不是如此,因此“我们实际企业不适合推广敏捷”。

很多时候组织架构、产品特征、人员能力都会影响推广敏捷(这些都会出现在一千零一问中),但这只会影响到“实现最好的方法”,并不会影响到“实现更好的方法”。因为实现不了共产主义就躺在奴隶社会睡大觉的人,其实是最没有敏捷精神的人。

[b]循序渐进,是以无住精神推广敏捷的具体做法。[/b]

在掌握了共振的人眼中,这不是一个家“有些敏捷实践无法开展的公司”,而是一家“有些敏捷实践可以开展的公司”。

[b]劝、帮、替别人做事[/b]
还有一种情况,比如“我们项目组学习了敏捷开发方法,但是产品经理却不写用户故事,怎么办?”乃至更加棘手的“你说产品优先级排序的第一要点是按商业计划排序,但我们公司没有产品总监,更是从来没有商业计划,我们该怎么办?”(这些都会出现在一千零一问中)

在每一次沉默的围观事件中,单独拉出任何一个人采访,他都会说“其实我本来想出手相助的,但是看到那么多人选择沉默,我也只好违心地沉默了。”

其实,我们不能想想自己高人一等,但却落入凡夫堆里,空有一腔热血不能施展。而是要想:“这些人多半和我有共同的想法,只是要么缺少具体的做法,或缺少一个人振臂一呼。”

所以当我们发现产品经理不写用户故事,可以先尝试劝说他做好这件事情,兴许他正犯愁自己应该怎样写所以犹豫不决呢;如果他写不好,应该帮助他一起写好,他写好了用户故事,我们开发也会更加顺畅;如果他执迷不悟拒绝帮助,大不了我们替他做好。

千万不要认为自己帮人做事、替人做事吃了亏。

我们之前有个测试人员刚刚转到技术支持部门,大家觉得“写方案”是个累活就推给她写;后来销售说Word版本的方案能看不能讲所以请改成PPT的;后来又推说对方案不熟悉所以直接请你去讲吧……一年后公司政策调整销售竞争上岗,半年时间她就在一个全新领域(就是那个方案要覆盖的领域)打开局面,并成交了公司历史上最大的单子之一,并成为新的销售冠军,收入提高了200%。

[b]劝、帮、替别人做事是以无我精神推广敏捷的具体做法。[/b]

在掌握了共振的人眼中,这不是一家“有些人不能配合我工作的公司”,而是一家“我能配合某些人工作的公司”。

在共振中破除旧我,建立新我
“别人”的范围不止与我们无法控制的外层和上层,也包括自己的队员、师傅的徒弟等等。

无我的人心中没有“应该开除的刺头”,而只有“有才干不能发挥因而应该帮助的队员”;没有“学会后会饿死我的徒弟”,而只有“会接手我的工作以便让我管理更大事务的兄弟”;没有“拒绝做份内工作的其他部门”,而只有“可能被我帮助、替代、乃至纳为下属一起管理的其他部门”。

破除掉旧我建立起来的“新我”不是一个具体的位置,而是一个更高、更好的方向,确切说就是“无我”。否则自己的职业生涯就会又止于某个位置。

比尔盖茨这些当年的程序员之所以能在很短时间内跨越如此多的职位,一个必要条件就是他们从来没有固守“我是一个程序员,因此不应该管……”,而是相信什么都是我要做的事,我可以成为任何人。

尽管这不是一个成功的充分条件,没有这个心量却永远不能成功。

以上三篇是解决一切已知、未知问题的心法,掌握了它们遇到任何问题就不会迷茫、恐惧,也不会只把希望寄托于某大师正好说过这个问题的答案,而是能自己分析解决问题。

此后的问题及分析,均建立在上述三者之上。或许今后还能总结出第四个词汇,但现在暂时只有无我、无住、共振这三者就够了。
[/size]

ref:http://blog.csdn.net/cheny_com/article/details/7190099
2008-10-17 10:51:21 heweiyabeijing 阅读数 221
  • SCRUM敏捷开发视频教程

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

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

       我曾经管理和经历过使用所谓“敏捷开发”的两个相对比较大的项目。之所以是“所谓的敏捷开发”,掺杂了不少了自己的实现和理解,见笑了。

       第一个所谓的敏捷开发的项目是迫不得已的,因为项目前期投入大而且人事变卦(其它公司挖墙角),后期没有足够的时间来完成项目,所以我自告奋勇承接这个项目,CALL,其实就是为了年底能够领到更多的奖金。这个项目总价是100W,其中30多W是硬件,30多W是公关(灰色)费用,老板给我的成本价是15W,而且很认真的给我算出这个数。当时老板给我的条件是:公司资源随便支配,其中开发资源计在成本之内,三个月交付,这个时期内最少有三个重要的里程碑,每个里程碑必须完成工作的35%,包括质量检查。

        我的做事方法,一个能力跟我相当的程序员,一个能力一般且很仔细的程序员,一个测试工程师,另外还有一个是美工,还有客户方至少有一个到现场帮助测试或者业务讲解。然后在中关村某公寓封闭开发。

         我们挤在一个不大的会议室里,都在一张桌子上办公,开发程序有点像流水线,第一个是我,我写程序快,经验多,i当然BUG也多。因为是J2EE程序,我在前一周都是在写所有表的增删改查,其中MODEL和DAO这一层自动生成,controller这一块写了通用的增删改查,页面也是简单的增删改查。然后就是其它两个程序员帮助我修改一下错误和BUG。测试人员在写测试用例,美工在和客户方交流用户的操作体验。总之,我想要说的话是:敏捷开发当中,敏捷的生产过程非常非常重要

         。我们经常交流,且有一种努力创业的想法。

         。有能力的程序员,让他写一些通用的方法和JS。(随便是google或者baidu上去抄)

         。客户方帮助我们不少。每个人都了解业务,有的想去卖仪器(哈哈,客户是做仪器的)

         。我们没有单元测试,每个人做完既定的功能后就提交功能测试,我们每个人的BUG很多,但是后面就很少。

         。我们完成一个相对独立的模块后,就提交给实用户,到现场进行试用。

         当然也少不了零食,看板,使用xplaner做管理。

          结果:我们不到两个月完成项目的85%以上,如果不算BUG的话,应该是在90%以上,然后退回到公司过着朝九晚五的生活。年终我也领到了两个多月工资的奖金。一个字爽。客户如期上线。

         黑五总结:跟着我的几个哥们,很讨厌我,他们最希望加薪,我只给他们的福利是每天120元/所有人的消费标准,每天工作10个小时左右,工资每天加100元,星期六星期天加200元(可以选择过星期天)。经过这个事后,他们很疲惫,虽然他们的技术提高很快,但是对公司的不满也每天增加,终于不出半年走掉一个,不出半年,又走掉一个。

         个人感想:敏捷开发的方法是老板喜欢看到的,因为敏捷开发方法节约成本,快速交付。但是对于员工来说,这种管理让人感觉压力很大,有点变态的感觉。我想如果一个人长期处于这种敏捷的开发当中,而自己没有自由的空间时,员工的不满会与日俱增的。尤其我们IT程序员跟现在的小姐一样,青春就哪么几年还在变态中渡过,所以从员工角度来说敏捷开发不是很好。

          我同时又想到了“计件工资”,又扩大了思维想到了“联产责任承包制”,又想到了“事业部”。感觉敏捷开发应该和员工的利益直接关联。于是我又想到了长得漂亮“出台率”巨高,美妓李师师......

          可能,敏捷开发的路可能还很远,对企业的管理方式也会不断的变化。这家伙,搞的天天跟考试一样。

          至今,找到的新工作也在敏捷的氛围当中进行,看看我的BLOG的更新时间你就知道我有多忙,为了生存,奉献身体,奉献青春。

          个人想法,仅供参考,不要人身攻击。

           链接:敏捷生产

2011-05-01 20:45:00 Fortunately 阅读数 350
  • SCRUM敏捷开发视频教程

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

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

 

一 敏捷开发介绍
1、敏捷开发与传统软件工程的比较
传统软件工程:规范化的文档,持续改进的软件过程
敏捷开发:密切的交流与合作,逐步细化的开发过程
2、敏捷开发四条核心价值观
(1)个体和交互胜过过程和工具
敏捷开发很强调个人能力,它以沟通和个人能力代替了定义死了的过程
(2)可以工作的软件胜过面面俱到的文档
它强调迭代式的开发,以开发的一个个版本形象的说明了需求,便于客户联想,也便于团队沟通演示
(3)客户合作胜过合同谈判
这条有过项目经验的人都能理解,与客户成为朋友比固定死的合同有用得多
(4)响应变化胜过遵循计划
它强调沟通,从而更积极的拥抱变化,并随时调整
3、敏捷开发的基本原则
(1)尽早、持续交付有价值的中间软件
(2)响应变化给客户创造竞争优势
(3)业务人员与开发人员一起工作
它的目的是强调大家建立频繁密切的交流,这是一种帮助大家沟通的方法,这里的业务人员是指需求人员
(4)团队内部面对面的沟通
(5)根据完成了的功能调整工作进度
(6)重构代码,保持代码健壮
(7)尽快完成目前已知的需求
强调把不了解的需求放到以后,不考虑太多可能性,不考虑太多可能性是指不考虑变化的可能性,先做好已知的,定义好的,持续形成新版本,客户可能会想到需要什么,很多客户并不是一开始就知道自己要什么 ,你给他一个东西用用,他会觉得好,还需要什么 ,或者哪里不好,需要改动 ,很多时候客户有很多需求,我们需要做的是帮他找到重点,理清流程,帮助客户提高主要的工作的效率才是目的。
4、主要的敏捷方法-极限编程(以下简称XP)
极限编程的实践
(1)客户作为团队的成员
客户是指定义产品特性并排列优先级的人。他应该时刻和团队在一起。
(2)短交付周期
迭代是指需求定义-功能现实-测试验收-发布的一个循环。短交付周期强调一次迭代最好不要超过两周。
(3)结对编程
功能的实现由2名程序员在同一台机器上实现,以促进知识在团队间的传播,保证代码的健壮性。这点我个人认为很难实现,习惯问题。
(4)测试驱动开发
首先编写测试代码,开发的目的就是为了使测试通过。
(5)尽量简单的设计
在不需要数据库之前用文本文件来作数据存储。只有在迫切需要的时候才来改变。用最简单的方法实现当前的需求。
(6)代码重构
每天进行代码的重构来保证代码的健壮性
(7)持续集成
将所有模块经常性的整合,以及时发现与系统有冲突的问题 ,据说微软的每日构造甚至到了变态的地步,要求每天集成测试,发现问题,就算是凌晨也会找到你,要你立即修改。

 

2008-08-26 13:20:00 pursuer_zhao 阅读数 662
  • SCRUM敏捷开发视频教程

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

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

敏捷软件开发有四条宣言:
1个体和交互胜过过程和工具:宣言要求建立优秀的团队,注重沟通;对于工具,先尝试简单的小工具,直到其不能满足需求在考虑更换。

这个宣言的前提首先对是团队管理人员提出了很高的要求:有很强的沟通能力,保证能和每个团队成员进行有效的沟通,能够很好调动、协作团队成员完成工作。能够做到公平、公正同时构建一个好的工作氛围、搭建一个有效的工作平台,让每个成员能够充分发挥个人才能。

其次,对于工具的使用,前提是团队管理人员能够控制或有权选择工具。因为很多公司,各种工具、软件的使用是由IT/IS,部门来控制的。

2可以工作的软件胜过面面俱到的文档:指出文档应该论述系统的高层结构和概括的设计原理。直到迫切需要并且意义重大时才来编制文档。在给新的团队成员传授知识方面,提出最好的两份文档是代码和团队。

 

 

说实在的,我很赞成这样并很乐意这样做。但是,这有一个前提,每个开发人员都了解软件的总体设计和各自要实现部分的细节,并和团队其他成员保持充分有效的沟通;每个开发人员的代码能够最大程度上保持一致并足够优雅;团队成员有高度的责任感,尤其是在给新成员传授知识时。

 

3、客户合作胜过合同谈判:要求与客户一起工作,随时捕获客户的需求变化并作出应对。

 

与客户一起工作,实施起来有很大难度,首先,客户有自己的工作,他时间安排不可能总是与团队的时间一致,这会造成效率损失;除非有专门的客户代表能与开发团队一起工作,但这又意味着项目的成本有所增加。

 

4、相应变化胜过遵循计划:详细计划只做两周,三个月的粗略计划,再长时间的计划就更粗略。这样计划就能不花很大成本随需求的变化而变化。

 

这听起来很美好,但具体实施对软件项目初期的架构、设计有很高的要求,要满足这样的随需而变,就要有高度灵活的系统结构和扩展性,否则会陷入两周一次重新设计或实现的恶性循环。

 

我说这些前提并不是否认敏捷软件开发,而是,想说要真正做到敏捷软件开发,不只是要改变目前你的团队正在使用的开发方法,而还要改变你团队的思维方式和工作方式,尤其是团队管理人员及高层领导的思维方式;同时更重要的是要提高你团队成员的水平(软件设计、开发的水平)和能力(沟通能力、把握客户需求的能力)。不要将注意力放在敏捷软件开发方法本身,最好将重点放在团队如何驾驭这种方法来高效地工作!

2011-07-13 12:24:03 cpzhong 阅读数 4726
  • SCRUM敏捷开发视频教程

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

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

回顾(Retrospect)是敏捷开发中的一个必不可少的实践,也是把整个敏捷开发过程连接成一个闭环的关键节点,本文将阐述我们是如何做敏捷回顾的。

敏捷回顾最高指导原则

ž无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及手上的状况,我们理解并坚信:每个人对自己的工作都已全力以赴。

敏捷回顾的目标
ž发现问题,持续改进。

敏捷回顾常碰到的问题

ž唉,又要开总结会了…
ž每次时间都那么长
ž问题讨论来讨论去就那几个,没啥新意
ž都不记得这段时间做过啥了
ž新迭代KO,总结放在一天时间太紧

我们敏捷回顾会议内容
1.产品数据
目的:通过分析用户数据来看我们的产品设计是否赢得了用户的认可
做法:收集前一迭代上线后的相关产品数据,如新功能使用日UV、PV等,当然如果发布后第二天召开回顾会议,可能不能马上收集到相关数据,也可以分析上上迭代的新功能使用情况。

2.项目质量
目的:通过项目过程数据来看质量
做法:分别从冒烟测试通过率、bug分析、集成测试方面来衡量项目质量,找到做的好与不好的原因。bug分析可以通过QC导出统计报表,从多维度进行分析,bug等级,引入层级等方面,如下图:

图1:缺陷引入层级统计
        集成测试可以通过集成测试框架如Hudson,主要关注单元测试覆盖率,通过率以及注释率等指标,如下图:
图2:集成测试情况

3.各抒己见
目的:总结项目中做的好的,不好的
做法:从KEEP(做的好的,要保持的),CHANGE(做的不好的,需要改进的),TRY(可以尝试的)三个方面进行总结。首先回顾下上次总结会议列出来的CHANGE和TRY事项,看看前一迭代做的怎么样;接着总结前一迭代的情况(每个团队成员在回顾会议前都先想好,写到便签条上,防止说的时候人云亦云),将每个人说的汇总,并由大家投票列出哪些可以在下一迭代中改进以及尝试,列出具体的action,建议不要多余三项,否则太发散什么都做不好。如下图:


4.个人总结
目的:督促项目成员自己做总结,看有哪些收获和遗憾,不仅要项目成功,成员也有要有所成长,也便于项目经理后续的任务安排有所侧重
做法:成员轮流发言,总结自己在前一项目中的收获和遗憾,尽量具体,收获指的是工程师在技术方面学到了些什么,总结了才会有成长,遗憾则指的是项目启动时给自己设定的目标或计划没有完成的。

        以上就是我们敏捷回顾中的4个部分,在组织会议上可以适当采取轮流主持,以及准备些水果、零食,利于大家保持放松,经过前一个迭代的紧张开发和测试,通过敏捷回顾稍作休息,整装待发。










对敏捷开发的误解

阅读数 479

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