2018-07-15 10:25:21 wer0735 阅读数 522
  • SCRUM敏捷开发视频教程

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

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

转载:https://yq.aliyun.com/articles/130605

敏捷开发(Agile Development) 随着“敏捷”一词出现在越来越多的项目中,于是,敏捷开发本身也被赋与了越来越多的意义,而敏捷的真正内涵反而变得越来越模糊。如何迈出敏捷开发第一步?是按照敏捷宝典、操作指南或是教父语录,还是因地制宜、因项目定方法?完成所有这些工作后,我们就真的“敏捷”了吗?

  一、前言

  Agile是指企业能够对外部环境做出速捷、有效的反应,是未来企业的必备素质。21世纪企业面临的竞争环境将是一个不断变化、不可预测的环境。由于高新技术的出现和更迭越来越快,产品的生命周期日益缩短,企业要面对这样的新的竞争环境,抓住市场机遇,迅速开发出用户所需要的产品,就必须实现敏捷反应。

  狭义地讲,敏捷企业就是将柔性的先进制造技术、熟练掌握生产技能、有知识的劳动力以及促进企业内部和企业之间的灵活管理三者集成在一起,对千变万化的市场机会做出快速、有效的响应。敏捷企业强调人、组织和技术的有机结合。通过这三者的紧密结合,敏捷企业可以发挥最佳的整体效益。评价一个企业敏捷性的具体指标是时间、成本、稳健性(Robustness)和适应范围。对敏捷企业的广义理解,可以认为敏捷企业是一个CIMS(计算机集成制造系统)、动态联盟、并行工程、仿真制造、高素质员工等多方面的系统集成,是一个基于CIMS、在CMS基础上发展起来的一个更高层次的集成大系统。

  二、变味的敏捷

  敏捷是大家在一起高效率地工作,清除所有沟通上的障碍,关注于增值的活动,从而使得开发更加成功。敏捷是大家肩并肩地工作,而不是什么都通过文档。敏捷是管理者积极地参加到项目管理中而不是整天去写状况报告,用那个来监督到底发生了什么事情。敏捷是开发人员和涉众(项目开发中涉及的从需求到最后交付的各种人员)在一起制定实际的计划,而不是用复杂的微软Project去制定一些几乎没人看的进度表。

  公平地说,很难设想敏捷术能如何发挥作用,尤其是在一些软件开发本身都问题重重的传统组织中,被误导过的敏捷更是难以帮上什么忙。

  敏捷开发,看到过这个词时,很多人一直没有什么深刻的体会,也没有仔细去研究到底什么才是敏捷开发。而一直在很多人的思想里,敏捷开发的印象就是,开发速度比较快。没错,做互联网的,快确实是一个制胜的法宝,那么敏捷开发似乎也就是在互联网应用的开发中最适合的方法了。那么敏捷开发中的参与者应该是什么状态?这似乎成了一直以来困扰很多管理者的严重问题。可以说,在敏捷开发中,并没有觉得有多敏捷,进度一拖再拖,问题一个接着一个,让我觉得我们是在进行慌乱开发。为什么会这样?

  另外,关于实施敏捷的效果也是充满置疑之声。我们经常看到一些号称Agile的国内项目,按照菜谱、操作指南和教父语录的提示,采用了许多花哨的技巧和实践(做法),是啊,表面上确实Agile了,那么结果呢?项目还是不能按时完成,甚至严重超支和超时,这能叫“敏捷”吗?

  三、敏捷十戒

  1、天报制度

  就算是进行远程开发或是两地使用开发,项目组的成员每天至少碰一次,不管是当面的,还是通过其它方式,如通过电话、email、Skype或其它。进行敏捷开发的时间,任何团队都不能以任何理由进行孤立的开发。

  2、例会制度

  即使每天通过Email给主管汇报工作,但有时主管还是无法及时准确的掌握项目组成员的状况及工作量。此时,通过每周一小时左右的例会将会有效的解决此问题。通过例会,大家面对面的就某些问题进行共同的探讨与讨论,找到共同的解决方案。

  3、版本控制

  如果没有一台干净的电脑来进行团队代码管理的话,则很有可能导致代码的混乱。而每天只须花很少的时间,哪怕一天一次,进行及时的数据提交与代码提交,则可以有效的保证团队之前代码的同步及代码的备份。

  4、需求失灵

  即使手里拿着30页且客户进行了签字的需求说明,有可能仍然不知所措。相对起那些良好的设计、精确的分析等,与客户持续的沟通、及时的反馈、不断的演示这些工作显得更加的有效果。可以有效的获得需求变化,减少误解,更加准确的把握用户的需求。

5、单元测试是QA的工作

  很多开发人员,甚至一些高级的软件开发人员,对于单元测试没有足够的认识,在行动上也没有足够的注意。大家都一致的认为那是QA的事情。就开发人员来讲,单元测试应该是一种白箱测试,能从功能上充分的测试软件的功能性。而对QA来说,只能是一种黑箱测试,无法深入的去分析代码的优势,只是从用户的角度进行功能上的测试而已。

  6、质量保证是QA的责任

  自从有了质量管理这个词以及后来产生的质量管理部门后,很多开发人员就理所当然的认为质量保证是QA的责任了。其实每一个人都需要对软件的质量负责,特别是开发人员。Bug越最早发现,那么解决它的成本就越低。

  7、项目进度风险控制

  也许一个项目需要18个月左右才能完成,但在没完成之前,谁也无法进行比较准确的时间估计。无法确定需要多长的时间进行设计、编码及软件组件的组合。但进行项目设计、实现及融合的人应该相对比较准确的掌握与估计项目的时间。因此,需要进行项目进度的风险控制,风险总是存在的,但要进行有力与及时的控制。充分意识到项目中可能会存在的风险因素,在制定计划时预留一定的时间,如果在项目进行中出现了没有想到的问题,根据其重要性,考虑压后解决,要在计划的时间内把计划的事情完成好,并为后续解决问题争取更多的时间。

  8、架构师身体力行

  很多软件架构师基本上不写代码,这也许是好事。软件架构师嘛,当然是比较高级的,他们对环境、语言、类库方面都可能比软件开发人员要更加在行,但他们一般不编码。这样的架构师是危险的,特别是那些基本上不与首席开发人员进行沟通或咨询的架构师,离项目失败可能已经不远了。

  9、牵一发而动全身

  很多时间,在功能上做了一个很小的变动,往往导致花费好几天的功夫来进行软件的集成与整合。如果没有持续的整合、及时的回归测试、可靠的整体设计,一些看起来非常微小的修改都有可能导致很大的麻烦。

  10、加大管理执行力

  目前项目中,开发者或者说参与人的状态是混乱的,或者说是慌乱的。那问题在哪里呢?是工作流程出了问题?不应该啊!在项目启动前已经定了一个看似美好的流程,而且是经过参与人讨论一致通过的。那么问题在哪里呢?原来是沟通、传达出了问题,执行力不够。那么,就必须加大执行力,今日事今日毕,这是必须的。

  另外,在一些产品级的软件开发中,觉得要实施敏捷式开发,我觉得也有一个不好解决的问题:没有具体的客户!没有具体的客户,那你的沟通去哪里寻找呢?一般的做法也是给一些有兴趣的用户发布Alpha版本,或者是beta版本的软件。可是当软件都到了Alpha/beta版本的时候,软件还有迭代的余地吗?未必!从我个人理解的角度来看,敏捷开发的适用范围还是很有局限性的。个人认为最适合使用敏捷开发的软件必须要有非常明确的客户才能进行,而有明确客户的情况以定制型软件为主。所以,我觉得最适合用敏捷方式开发的软件应该是——定制软件!

  四、小结

  记得Jim Highsmith在他的《敏捷项目管理》一书中这样写道:敏捷是指在动荡的业务环境中,适应变化并创造变化,从而获得价值的一种能力。同时敏捷是平衡灵活性和稳定性的一种能力。由此可见,望文生义地把“敏捷”理解为“做得快”也颇可商榷。如果缺乏有效的实施指导、忽视严格的敏捷实践,单凭着高层面的理解甚至“文化”就开始盲目前行,往往会因为缺乏对质量的有力保障而失去平衡,最终欲速则不达。


2012-10-08 17:43:32 JJiaoAo 阅读数 156
  • SCRUM敏捷开发视频教程

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

    10426 人正在学习 去看看 CSDN讲师
[size=medium]
[b]问题[/b]
敏捷开发加班吗?

楼下有人问到“敏捷和加班有什么关系”,补充这两句。

有些程序员认为,敏捷开发从制度上要求不加班(可持续的步调),因此会说“老板,现在你不是推敏捷开发吗,那我们就不能加班了,因为敏捷开发不能加班。”结果肯定是:“敏捷要敏捷,加班也要继续加班。”

“存在的就是合理的”,既然加班,至少还是有目的或好处的,要想把加班废除掉,就必须找到比加班更合理的东西,让它取而代之地存在,而不要在制度上抬杠。

“它”是什么呢?

[b]分析[/b]
说不加班,那么原来加班产生的生产率,现在怎么弥补?

说加班,那么怎么理解敏捷12原则中“可持续的步调”这句话?

在解决这个问题之前,先看看为什么加班。

[b]“加班是因为生产力不足”[/b]

这个是最常见的理解,除了加班,还有一个就是招人,招人+加班,来解决生产力问题。

不过,为什么有些公司,人数众多,天天加班,但面临倒闭呢?

神奇的是,倒闭之前,还会裁员,重新把生产力降低下去;而裁员行为常常被肯定,比如每当上市企业裁员,股价还会普遍上升(当然之前肯定跌过)。

到底生产力降低和股价上升之间的关系是什么呢?为什么两者有很明显的矛盾?

这一切在敏捷开发里边有答案,但是不很直接,因为发明敏捷开发的人,都不关心股价。

[b]“加班是因为要做的东西太多”[/b]

诺基亚的盛衰是个鲜明的例子。

诺基亚在20年前最低靡时期的业务,是后来鼎盛时期所有人加班都做不完的,为什么呢?因为那时候诺基亚从事纸浆、化工、家电、家具……等无数行业,每个都舍不得放下。

诺基亚的崛起,是从它开始舍弃上百种业务而专心电信领域后开始的。而诺基亚的衰落,则是从它在电信领域又用有上百种产品后开始的。

简单地“拥有上百个行业或产品”并不会直接导致企业衰落,但是将导致企业臃肿,专业性降低,决策层无法理解不同行业,进而导致决策层效率下降,市场感知力下降,最终导致企业衰落。

最后用两句话简单地再理解一下这个观点:

MS在Windows里边做的功能,Google加班也做不完;Nokia在手机里边做的功能,苹果加班也做不完。

方案
前面的比较容易做,后面的比较彻底。

[b]方案1[/b]

对项目经理而言,无论现在是否在加班,以及是否有能力解决“加不加班”的现状,都要去思考一个问题:[b]现在加班开发的事情是重要的吗?它们从哪里来的?[/b]

很多时候,我们感觉加班的做的事情以及加班本身都是来自外部的要求,我们无能为力,但实际上我们可能有些事情没做好,比如:

1. 在之前为了迎合领导的要求而抢进度,导致质量低劣,不得不加班……

2. 由于一门心思开发而不关心业务,导致产品经理把业务越来越说明了之后返工很多,导致加班……

3. 由于不关心产品经理是否对需求进行了排序就进行开发,结果发现次要的功能一大堆,重要的功能还没做,导致加班……

……

造成上述问题的主要原因是,在“我们”之外都有一个“他们”,要么是领导,要么是产品经理,或者销售,总之由于“他们没有做好自己的工作”,导致我们加班。

解决这个问题,需要我们相当开放,以尝试帮助他们的心态指出问题。

这很困难,但在之三(见目录)中我们提到,千万别认为别人是不讲理的、不明智的、不接受帮助的,用心迈出第一步是最关键的。

[b]方案2[/b]

[b]产品经理要真正理解产品的核心价值。[/b]

很多“新产品”在成功后,都会发现原来只是一些很小的功能导致了其成功,QQ,Google,百度,Iphone,都是如此。

如果一个产品经理,坚持“我们的功能全面超过竞争对手”才能成功,那么这个产品经理是没有价值的,因为傻子也能做出这个判断。

[b]好的产品经理,是那些知道,还能说出为什么某些少数功能更重要的产品经理。[/b]

之前曾经提到过一个面试市场经理的案例(http://blog.csdn.net/cheny_com/article/details/6773962),那个市场经理的大致观点,也是“只要我们向市场工作投入足够的资金,我们的市场工作才能/就能做好”,同样道理也是不可取的。

上面这两条,是敏捷开发最可能大展身手的地方,以交付核心客户价值为目的,而非交付超过竞争对手的功能,是避免加班的最直接方法。

当产品经理想向老板提议让开发组加班的时候,一定要问自己:“所有这些功能都是必需的吗?”因为对脑力劳动而言,加班只能产生不超过20%的生产率提升,而在产品中找出来20%垃圾功能,是易如反掌的事情。

[b]方案3[/b]

[b]对于产品总监,要理解行业的最紧迫问题,寻求用户突破口,规划产品线。[/b]

在行业中最重要的是用户,而非个别功能了。

最初做互联网的时候,人们都是做“门户网站”的,因为门户网站包罗万象,谁的门户大,谁的用户似乎就多。

但发展到现在,国际和国内的门户网站都衰落了,那些仍然存在的,主营业务也不再是门户本身。

国外包罗万象的Yahoo和AOL都衰落了,国内网易和搜狐在做游戏(70%以上的收入),新浪在玩房产和微博,腾讯嘛……没有QQ,QQ.com就什么都不是了。

“门户网站”实际上本来是一个包罗万象的产品线,为什么不灵呢?因为无论玩游戏,交朋友,查资料……这些似乎在门户网站都能做的事情,都有更好更直接的地方,最终人们离开了门户,去了哪些地方。

所以,如果一个产品总监崇尚完整的产品线、尽可能多的产品等等,很大程度上表明他无法确定哪个产品才是未来的方向,所以只好无原则地扩张。

[b]广种薄收不好吗?不好。[/b]

在围棋里边有一种“负目”的说法,就是如果有一片棋形状不好,敌人就会在攻击中围出自己的空,这种棋在清点目数(就是所占空间)的时候,甚至会被先判断成负数。

多余的产品不但不盈利,还分散了开发力量、资金、资源,增加了管理成本。由于互联网时代有“无重经济”的特性,市面上多数产品只能存活前几种,多余的产品全部都是负资产。

08年前我们走访一家游戏公司的时候,得知他们拥有600人的研发团队(在当年属于大的,超过了金山和搜狐),同时在研发40种游戏,出来的时候和行业销售交流了一下看法,感觉平均一个游戏投入15个人,多数还都是MMORPG,恐怕做不出什么好游戏来,再加班也不可能。而事实也果真如此,2010年这家公司发生了很大的人员流失现象,到现在也没有叫得出名字的好游戏上市。以他们的研发数量和资金数量,重点攻克少数产品还是不难的。

你可能会说:“要找到这样一个能做出判断的人太难了”。但是毕竟一家公司只需要一个两个,与其动用如此庞大的人力财力去广种薄收,不如寻找、培养这样一个人,或一些人。而且实际上,世界上并非存在“能做到”和“不能做到”的两种人,多数企业陷入困境都是属于一种“集体无意识”状态;如果企业有意识这样做了,就会发现原来自己企业里边有很多很有大局观和眼光的人。

[b]方案4[/b]

这个是最顶层的布局问题之一,就是缩减行业,建立行业优势。

诺基亚和三星当年都干过,就是集中兵力,占据某些少数行业的优势。这两家企业当年都是多面手,都半死不活,都是在消减行业后一举成为世界级企业的。

实际上世界上无数大型公司,如果让我们列举每个公司都产品,我们会发现能说出2个的公司不多,3~5个的几乎就没有了。也就是说这些公司多数就凭借一两款产品就包打天下了。

[b]方案5[/b]

也是布局问题:分而治之策略。

三星是一家奇怪的公司,他是少数从事多个行业而又能兴盛的企业。

尽管砍掉了很多多余的行业,但三星今天仍然从事着若干传统行业,不过他们采取了分而治之的策略,就是各自干各自的,自己思考自己的问题,自己获得自己的利益。

尽管三星集团的总市值很高,但与诺基亚、微软当年的顶峰值相比,还有差距,换言之后两者在庞大的体量下,仍然采用中央集权式管理,问题就层出不穷。

比如让做单机操作系统出身的高层去决策互联网时代的MSN问题,让做模拟电路出身的高层去决策智能平板的必要性,难免不出问题。

苹果和Google采取了分而治之的策略,就是采用与开发者共赢的Store策略,让开发者自己去决策应该开发什么,应该开发成什么样子。
[/size]

ref:http://blog.csdn.net/cheny_com/article/details/7418481
2008-10-26 23:01:00 poson 阅读数 2592
  • SCRUM敏捷开发视频教程

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

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

 

  1、压力比较大。每天早上总是要说点什么。不能说昨天什么也没有做吧

  2、不知道天天开晨会,leader会不会有急功近利的倾向。

  3、督促自己合理利用自己的时间

  4、可以知道同事在做什么,到什么样的进度了。

  5、早上不会迟到,很快能够进入工作状态。

 

 

2011-05-05 21:22:12 hyj956948933 阅读数 152
  • SCRUM敏捷开发视频教程

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

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

    在敏捷开发当中有一个每日站会,开会的时间不是很长。基本是总会昨天做了什么时事,遇到了什么问题,然后今天准备做什么事情。

    由于是第一次使用这种模式开发,刚开始很不习惯,感觉这些事情好像用一封邮件就可以解决了,没必要开什么每日站会,甚至有点浪费时间,而且我们在前面开会的时间都不好把握, 有时开得很长,然后一天上午基本做不了什么事情。

    虽然很不情愿,但事情还是得照例做,会还是照例开。

    经过几个星期后,发现慢慢就习惯了,同时也发现这个每日站会解决了很多问题。

    首先说明一点,我们团队当中基本是实习生,没有什么开发经验,同时项目要求不是很急,于是就出现了如下问题:

    1. 开始团队成员之间互相了解不够,甚至讲话都很少,都保持异常低调。。。

    2. 发现有些天根本没做项目的事情,而是做其它与项目无关的事情去了。

    3. 每天的总结与计划都一样,甚至每个人做的事情基本都差不出,在发言时,有时就一名话带过,如,我和他做的一样,然后就没有下文了。汗。

    4. 反感是"一传十,十传百",暂且让我这么说吧!

 

    以上的问题,从不同的角度折射出敏捷开发中每日站会的好处:

    1. 时刻了解团队成员的工作情况

    2. 沟通-- 让我们更加了解对方,了解项目

    3. 遇到问题时,大家讨论,团队的力量,很快就会有解决方案。

    4. 每日计划-- 自己不会盲目,不会找不到事情。

    5. 如果当天没有安排,小组长肯定根据实际情况帮你安排一些事情。

    6. 至于时间的把握,会随便的每日站会次数的增加,相应的也会有所改进。

 

以上是我参加敏捷开发一个月以来的小小的总结,如果有写得不好地方,还请原谅。

 

    以后可能还会有改进。

2013-03-07 20:18:12 viscent_huang 阅读数 878
  • SCRUM敏捷开发视频教程

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

    10426 人正在学习 去看看 CSDN讲师
   很多刚刚转向管理岗位的人员,对于项目进度如何把控,往往不知所从。关于进度,比较容易让人想到的是询问、以及要求写日报、周报之类的。这些措施首先是不完全的。因为进度管理不仅仅是获取进度信息、更重要的是还要核实进度信息。就好比说这一样个任务,你让某人去下载一个软件的安装程序。
你要的是Linux版的。等他下载完了Windows版的,指不定他就告诉你这件任务完成了。
   其次,这些措施效率太低,试想一下,一个30人的团队,如果每个人进度你都去询问一般,那结果是什么呢?况且,别人可能还嫌你烦。另外一方面,一旦发现进度有所滞后,比如较计划滞后,或者某件任务可以花更少的时间时,还要采取一些矫正措施。就是说,还要一定的控制措施。比如,有一个测试人员准备测试一个Linux定时任务脚本。
我让他通报下进度,他说还在等待。那么,他在等什么呢?因为他把他准备测试的定时任务设置为每2小时运行一次。我对他说,把那个定时任务设置为每5分钟运行一次从测试的角度来看是否也是一样的效果呢(这个脚本所需的执行时间通常只需要几秒钟)。事实上,我事先就料到他会那么做,所以特意及时要求其通报下进度。


另外,在安排项目计划的时候,就要把进度管理考虑进来。在项目执行过程中,还需要时刻关注进度风险。


IBM developerWorks上面有篇有关如何把控进度的文章,以作者的实际的项目管理经验写的。感兴趣的可以参考:


《敏捷项目管理实战之进度管理》:
http://www.ibm.com/developerworks/cn/rational/r-cn-agileprojectprogressmanagement
没有更多推荐了,返回首页