2007-10-27 22:00:00 softart 阅读数 390
  • SCRUM敏捷开发视频教程

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

    10415 人正在学习 去看看 CSDN讲师
2007年04月02日 16:48:00

很久没有写Blog,很多朋友、同事和同学都在问我 为什么还不更新?越来越不敏捷了!哈哈

其实最近还是在学习和实践敏捷开发,特别是研究敏捷开发过程中的测试方法。

上周末刚刚给公司的一个部门培训了敏捷开发。讲了一天的敏捷开发,从理论到自己的亲身实践体会,带着学员做了不少游戏,感觉气氛非常活跃,大家情绪高涨,学员普遍反映不错。虽然站了一天,但是一点也不觉得疲惫。

不过还有一些需要加强的地方,User Story的小品似乎不是很形象有趣,TDD过程也有点冗长繁琐。不过,毕竟这是第一次培训,相信以后一定会改进的更好!



Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1549549


2016-08-12 13:38:43 diyal 阅读数 1483
  • SCRUM敏捷开发视频教程

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

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

##游戏敏捷开发项目管理之我见(三) 沟通

一、沟通过程中的思路
这里写图片描述
1、询问信息

* 明确要问什么,沟通一定要带着目的性,否则就是扯闲篇了。最好是列好条例。
* 信息是否完备,沟通的信息是否完备了,是否都得到自己想要的答案了。
* 信息是否准确?是否掺杂感情色彩,或是片面之词。

2、工作任务

* 安排的工作任务,明确需要对方知道的信息有哪些?安排一个模块开发,首先要让对方知道,这个模块是要干什么,什么时候完成,任务否否紧急,你的诉求是什么,是否有困难,困难的解决方案是什么,通过什么帮助或者调整可以解决这些这些困难?如果delay了怎么办等等。
* 确定对方已经理解,最好是通过反问的方式来确定
* 最重要的是明确任务完成的时间节点,开发者肯定会觉得这个时间没办法给出,毕竟在什么都没干的情况下,谁都不敢轻易给出具体时间。所以最好是在开发者给出的时间留出一定的弹性。

二、沟通技巧,说话的艺术

1、不要说“但是”,而要说“而且”
“我觉得这种想法很好,而且,如果在这里再稍稍改动一下的话,也许会更好……”

2、不要说“首先”,而要说已经
跟老板汇进度,“首先”一词出口,就让人觉得你还有很多事要做,却不会认为你已经做了一些事情了。而且这样的讲话会给人一种悲观的感觉,而往往项目开发需要良好积极乐观的氛围。
“是的,我已经相当熟悉这项工作了……”

3、不要说“错”,而要说“不对”
一个leader最让人钦佩的,是让成员甘心情愿付出,当然犯错误是在所难免的,所以我们必须要注意的是,不要说“错”,而是说“不对”,这样在语气上,更让人接受。总之不管什么情况,你要有跟成员一起面对错误的态度。
“你这样做的确是有不对的地方,咱们最好是为此承担责任”

4、不要说“仅仅”
在一次Bug修改会议,或是一个需求评审的时候,你是这样说的“这仅仅是我的一个建议……”
这样说是绝对不可以的,这样一来,你的想法、功劳包括你的价值都会大大贬值。本来利于项目,团队的一个主意,反而让同事觉得你的自信心不够。
“这就是我的建议”

5、不要说“本来”
你和你的谈话对象对某件事持不同看法,你却轻描淡写“我本来持不同看法的”。这样不但没突出你的立场,反而让你没了立场。类似还有“的确”和“严格来讲”
有威信的领导都是直截了当“对此我有不同看法”

6、不要说“务必”而是“请你”
7、不要再说“老实说”

2012-04-01 14:35:43 cheny_com 阅读数 15062
  • SCRUM敏捷开发视频教程

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

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

这是敏捷开发一千零一问系列的第十四篇。(在这里提问之一之二之三问题总目录

正逢周末,又是愚人节,群中有人正在加班,想起上次培训中间休息的时候,讨论起这个“敏捷开发加班吗”的问题,虽然后来没有作为课后投票入选,但这里也完整回答一下。

问题

敏捷开发加班吗?

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

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

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

“它”是什么呢?

分析

说不加班,那么原来加班产生的生产率,现在怎么弥补?

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

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

“加班是因为生产力不足”

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

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

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

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

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

加班是因为要做的东西太多

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

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

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

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

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

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

方案

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

方案1

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

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

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

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

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

……

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

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

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

方案2

产品经理要真正理解产品的核心价值。

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

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

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

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

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

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

方案3

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

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

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

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

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

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

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

广种薄收不好吗?不好。

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

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

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

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

方案4

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

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

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

方案5

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

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

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

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

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

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

 

4和5写得比较简要,因为和敏捷开发没有太大的关系,但是和加班很有关系。

如果很符合自己的想法,想了解更多的分析,请在未来半年关注一个策划中的系列,叫做“互联网时代的商业伦理系列”,里边会分析过去10年到未来20年间公司的员工与老板/生产部门与销售部门/生产商与用户/生产商与合作伙伴/生产商与竞争对手之间的正在形成的全新伦理关系。

2010-02-10 09:37:00 cheny_com 阅读数 3013
  • SCRUM敏捷开发视频教程

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

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

历时2周才完成的敏捷游戏研发过程海报。

整体思路是在游戏研发过程中应用Scrum敏捷方法进行管理,在其他大团队/长周期项目,或普通团队实施Scrum时也可以借鉴。

最上面的标题对应Scrum的各个活动,左边则以概念-活动-实践-文化-目标来诠释各个活动的精华内容。如果想从头读到尾,请按各个文字框中间的连接箭头逐个阅读。

中下部的大图和Scrum常见的图差不多,但由于游戏团队往往是大型团队,必定存在Scrum of Scrums 的情况,所以中间产生了一个分组-集成的过程。

最右下角的三个文本框长周期研发……等(也就是顺着箭头倒数三个框)描述了大团队长周期项目的Scrum过程。这在游戏研发中非常常见。

下面则是一些直观的例子,来解释Scrum产生的各种“工作产品”的外观。

 

 

纸质海报索取及下载位置:

http://community.techexcel.com.cn/010DevSuite/070Agile_Scrum/010Posts/020Agile_Posters 

2010-03-23 23:04:00 firePhoenix1981 阅读数 1049
  • SCRUM敏捷开发视频教程

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

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

这两天得参加一个敏捷开发的培训。培训师是一个美国人,还是哈佛的研究生,这可是这辈子第一次见到一个活的哈佛人啊,呵呵!老兄一上来就和中国套近乎,再次印证了美国人“虚伪”的观点。

老师首先打击了一下原来的瀑布开发流程的弱点:很难应对需求的变更,不容易与客户澄清需求的理解,可交互性差,参与性差,很多的文档实际上发挥不了持续的作用。稍后开始了好几个游戏,可以说是玩了一天的纸飞机。PPT里面最主要的就是那么两张,如果能过完全理解,那么敏捷开发流程方面的东西也就掌握得差不多了。IDP里面有很多角色定义,负责开发流程里面的不同职责。SCRUM里面也有:SCRUM Master和planner,master是team的保镖一样,负责监督SCRUM流程,保护和指导开展sprint迭代;planner负责定义产品特性及其优先级,也负责特性的acceptance标准;team成员都对自己负责的task负责,无人督促你,所有成员都是平等的,如果master对你居高临下,你可以讲“hei, just do your own job!”。

一个sprint周期:team决定从产品的backlog里面选取哪些(要考虑优先级)放在下个sprint里面完成;对挑选的任务进行分解,尽可能详尽可量化;各成员领取任务;开发、test;发布并且retrospective这个sprint的流程:哪些实践我们没有做;哪些下次不能再做了;哪些需要继续保持。retrospective是一个重要的活动,他能使得开发团队持续的成长。sprint实践里面另外一个主要的活动就是每天的站立会议,各成员需要向其他人阐明昨天自己的进展,是否对其他人有需求或需要帮助之类。和IDP一样,SCRUM也需要很多的表格需要填写以跟踪任务和进度,不同的是,不用写那么多的文档了。

还能回忆起一些要点,有的是同事的提问:

1)team里面只要有人理解architecture的意图和实现要求就行,不强求每个人都能理解,training是一个日常的行动,不必要单独作为一个sprint进行;

2)开发开始后,task就不能改变,如果planner发现当前的feature有问题,需要等到这个sprint结束后进行调整;

3)team成员对自己的task负全责;

我感觉scrum开发成功一个关键是各个成员都要负起全责。另外并是说遵守scrum开发的准则就能将它做好,因为最终完成的事软件,要发挥scrum开发流程的威力,需要应用一系列的敏捷开发的软件设计方法,比如说封闭/开放准则,依赖倒置准则,单一职责等等。明天他也许会将这方面的内容。

Scrum两天培训小结

阅读数 3161

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