2014-11-27 12:31:08 cheny_com 阅读数 274
火星人敏捷开发手册—27895人已学习
课程介绍    
201411270716166935.jpg
    本课程讲师是CSDN下载总量超过一万人次的《火星人敏捷开发手册》的作者,课程中将以PPT+视频方式讲解《手册》,适合个人学习、敏捷开发现场培训预习、企业推广敏捷开发等场景。除了《手册》中的原有内容外,还将包括讲师正式培训中相应的一些内容,以便深度了解Scrum敏捷开发的全过程。
课程收益
    
讲师介绍
    陈勇更多讲师课程
    具有丰富的工程技术与项目管理实践经验,从其程序员、项目经理、CMMI/FPA功能点估算/敏捷咨询师、事业部总监、副总经理等各种技术与管理岗位获得的一手经验,令其可以站在企业管理者的高度,以更广的视角来理解敏捷开发,并能配合和推动非研发部门协作推广敏捷。
课程大纲
    1.15分钟Scrum扫盲  15:10
    2.Scrum中的工作产品  15:11
    3.Scrum中的角色  15:08
    4.Scrum 计划会之讲解故事  15:09
    5.Scrum 计划会之扑克牌估算  15:13
    6.每日立会  15:09
    7.看板与燃尽图  15:11
    8.Scrum 评审会与反思会  15:09
大家可以点击【查看详情】查看我的课程
2011-10-17 06:30:15 zhoujg 阅读数 697

    估计和规划在软件开发中是必不可少的活动,那敏捷方式下我们如何做呢?以下是今年5月份内部做的一个培训PPT,希望对大家有所帮助。

 

敏捷个人俱乐部QQ群:40961321  加入敏捷个人俱乐部QQ群说明

敏捷个人线上线下活动PPT及照片做成的视频共享

推荐:你可能需要的在线电子书   

我的微博:http://weibo.com/openexpressapp

敏捷个人sina围裙:http://q.t.sina.com.cn/135484  


2010-03-23 23:04:00 firePhoenix1981 阅读数 1049

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

老师首先打击了一下原来的瀑布开发流程的弱点:很难应对需求的变更,不容易与客户澄清需求的理解,可交互性差,参与性差,很多的文档实际上发挥不了持续的作用。稍后开始了好几个游戏,可以说是玩了一天的纸飞机。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开发流程的威力,需要应用一系列的敏捷开发的软件设计方法,比如说封闭/开放准则,依赖倒置准则,单一职责等等。明天他也许会将这方面的内容。

2010-03-26 13:32:00 cheny_com 阅读数 4399

前几天写培训PPT,突然发现不知道把敏捷宣言放在那里好。

因为看上去,敏捷宣言中既有体现价值观的内容,也有直接的操作层面上的内容。大家请看(前后删除了一些):

 

个体与互动 胜于 过程与工具

可工作软件 胜于 复杂文档

用户协作 胜于 合同谈判

响应变化 胜于 遵循计划

 

如果感觉看不太明显,那么我们来两个对照版本,就会感觉更加清晰。

 

“价值观”版本的敏捷宣言

 

客户价值 胜于 软件和文档#1

受激励的个体 胜于 过程与工具#2

 

#1是关于需求管理的价值观,包含了多层含义,基本上是4条敏捷宣言的后3条+其他,包括:

1.1 可工作软件 可以向客户交付价值、验证价值是否被实现

1.2 用户协作 保证软件更好地体现客户价值

1.3 响应变化 产生客户价值

1.4 按优先级交付 全包客户价值最大化

1.5 迭代式交付 确保价值交付

……

 

#2是关于计划管理的价值观,很接近原来宣言的第一条,包含了:

2.1 开发团队自己估算 产生激励

2.2 时间盒 产生激励

2.3 同行压力(以跨职能团队而非个人进行估算和跟踪) 产生激励

……

 

“操作”版本

 

就是上面的1.1……2.1等,很接近。

操作版本很接近敏捷12原则,没什么新意。尽管这些原则是“原则”,但某些情况下某些原则可能得不到实现,但你依然可以继续敏捷。

但价值观版本的宣言就不同了,不能违背。

 

本文的目的,是推广前面提到的“价值观”版本敏捷宣言。

 


 

“价值观”版本的敏捷宣言到底有什么用?

 

“价值观”比4条式宣言更接近敏捷的精神层面,换言之,很多敏捷操作都可以违反但依然可以称为敏捷,但如果无法体现敏捷价值观,就真的不是敏捷了。

 

请看下面两个经常被问到的问题(请先尝试在4条老版本的敏捷宣言找答案):

 

1. 进度质量成本需求你砍哪个?

2. 在固定需求固定价格的合同项目里边可以采用敏捷吗?

 

 别看“价值观”版本的宣言更简单,但答案却更容易找到。

 

1. 需求。因为需求是唯一可能被砍却不太伤及客户价值的一个(因为多数需求都不常用)。延期一倍,缺陷多多,成本超支,每一个对客户或公司都可能是不可忍受的。

 

2. 可以。倘若项目一切顺利,敏捷能使客户得到更多价值(更贴切更重要的需求);倘若项目延期、超支,敏捷能最大限度保证老板能拿回一部分尾款(因为我们手里有一个客户能使用的有价值的产品);如果老板没有办法用部分需求拿回部分尾款,则敏捷使他更容易判断距离完成所有需求还要多久;如果到了山穷水尽的状态,敏捷使得客户更可能选择给部分钱买部分功能凑合实现一些价值(何况是真正重要的那部分价值)而非鱼死网破,但我还没听说客户给部分钱买设计文档的……

 

再来看几个被问过的问题(也是先尝试在老版本的敏捷宣言找答案):

 

3. (政府)客户执意需要一个WORD版本的需求才能结项,即使我们认为没有必要,因为我们软件都做完了给客户用上了,怎么办?

(补充信息:客户很重视这些文档吗?是的,会有他们上级的审批、备案,否则项目无法向上级报告结束。)

 

答:显然,这些文档对客户很有价值(无论我们怎样理解),所以这是要向他们交付的“可工作产品”的一部分。当然,既然是有价值的,在签订合同的时候,请向他们就这些文档的编写报价。

 

4. (游戏研发,策划=PO)策划人员让我们开发某些功能,但评审会上他们看了产品后不满意,把这个功能给砍了,让大家积极性很受挫,怎么办?

 

答:对“满意不满意”而言,不需要一个真正“可工作的产品”(测试过-无缺陷-随时可以上线的),因此应该提前商量实现到什么状态策划可以判断是否满意,以最大程度节省工作量。而由于知道不需要一个“可工作的产品”而是“可帮助判断研发方向”的产品,团队对于功能的命运会有所心理准备,并为“这个功能被砍掉”而感觉交付了价值(因为避免了走向错误的方向导致玩家流失)。这是一个典型的“客户价值 胜于 可工作软件”的例子。

注:EA等厂家均有“可工作产品”的不同标准,因为游戏产品总是变化太多,方向模糊。

 

再来看看下面这个笔者设想过又否定了的开发模型(估计Ken也想过但也否定了):

 

5. 这个模型基本和Scrum相同,唯一的差异是:没有Sprint,大家总是开发最高优先级的需求;当中途……其实没有中途,因为没有Sprint……发生变更时,PO会找到Team,描述一个新的需求,设定其优先级,并按优先级“插入”到Backlog中;团队仍然自行估算工作量,PO也接受;比这个需求更优先的需求不会受到影响,而不优先的则被打断(如果开始了)或推迟(如果没开始)。

 

分析:这个模型完全符合老版本的四条,在“响应变化”上甚至更胜一筹,但是?

但是这个模型中缺少因时间盒产生的激励,人们整体缺少里程碑的感觉,找不到点停下来看看自己的承诺是否完成了。而且由于预期可能有更优先的功能出现,团队可能会对已经完成估算并设定了完成日期的任务漫不经心。

BurnDownChart因为长期无法到底,使人们缺少冲刺感觉。

 

再看看一个相关的问题:

 

6. 在Sprint中不允许变更,但是如果真的来了一个点子,能让原来的某个功能更好(或让原来的某个功能被放弃,注意是某个而非整个Sprint),怎么办?被问了100遍的问题了,绝对是Top5的最常见问题。

 

答:无论选择变更(正如5中所提,下次大家知道会变,就不再承诺完成了)还是不变(眼看着自己在开发一个不好的功能-下个迭代就会被推倒重来;或者明知道功能会被扔到,还继续开发……)都会对团队积极性有所打击,所以?

所以最好的方法是MosCoW方法,就是把Sprint中的功能分为一定要、最好有、关键时刻可以放弃的三类(你不会认为真的还有一类是:必须没有的把?呵呵),若发生变更,接受并扔掉最后一类。前提是,Team总是从第一类开始做。这样两个价值观都被保护了。

 


 

如何看待原来的敏捷宣言?

 

感觉,敏捷宣言更像是口号而非核心价值观的描述。打个比方,“打土豪分田地”、“土豆烧牛肉就是~~主义”、“住瓦房穿绸缎吃细粮”都是口号,易于理解,应者云集,不过只是体现但不等同于核心价值观。

因此理解敏捷的时候,不应该把敏捷宣言当作判断是否敏捷的最终标准,也未必是放之四海皆准则的口号。

比如如果对程序员宣传4条敏捷宣言,基本上会得到一片掌声;但如果向高层领导宣传这四条,多半会得到几个很难回答的问题。但价值观版本的敏捷宣言则是相对安全的。

 

如何运用“价值观”版本的敏捷宣言?

 

价值观版本的敏捷宣言可以看作是是否敏捷的底线。

比如当被问到一个似乎与4条敏捷宣言和12条敏捷原则相左的问题时,基于敏捷价值观可以找到或判断一个潜在的答案是否还“敏捷”。

当然这个判断有时候要动点脑筋,这也是为什么会存在敏捷的生态系统帮助迅速裁定。(请参考本版其他博文)

 

不过价值观版本的宣言有点空,应该在敏捷语境中去理解和应用。

 


 

尾声

 

1. 这两条价值观似乎除了敏捷之外其他方法也会推崇(至少不会否认),为什么这里称之为敏捷的价值观?

 

答:其他方法会更加推崇别的东西,如果只选择用20个文字描述整个方法,绝对不会是这两行。

 

2. 如果客户价值 不等于 公司价值,我应该怎么办?(比如客户执意要加需求还不给钱,应该敏捷还是不敏捷?)

 

答:额……如果一个公司无法把客户价值和自身价值绑定在一起,这个公司一定运营在相当危险的状态,这不是敏捷不敏捷能解决的问题。

这和讨论在发生核战争后是否应该继续使用敏捷开发差不了太多。

如果公司老板是市场、销售出身,请多听并遵从他的判断,他不大会在这种事情上吃大亏的。

如果公司老板是搞技术出身的,这个比较危险了,请他多听并遵从市场、销售的判断吧,能好一点。

2016-09-20 16:03:41 u011692258 阅读数 292

CTO CLUB联合金牌敏捷教练姜信宝、王立杰共同举办『敏捷系列微课堂』,从基础到前沿、从工具到案例,共计13次课,让学员及时掌握敏捷精髓,提高团队效率。欢迎大家参加。

图片描述

扫描下方二维码,即可报名。
图片描述

课程:
198元(13次课,为期4个月,附送讲师PPT、课程整理等、跟讲师随时沟通敏捷问题)

特别说明:
1.请认真填写个人信息(邮箱、微信号、手机号),工作人员会加您扫码入群,谢谢合作,可开培训费发票,咨询电话010-51661202-705
2.我们将在报名结束后的三个工作日内给缴费会员快递发票,一经购买将不予退款但提供发票。

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