2018-06-16 10:05:40 jackyrongvip 阅读数 30
  • SCRUM敏捷开发视频教程

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

    10436 人正在学习 去看看 CSDN讲师
敏捷中的 promise 和 从commitment其实是不同的,具体参考下面两篇文章的说法:

http://www.pmquanzi.com/articlDetails/434.html

https://zhuanlan.zhihu.com/p/31989579


摘抄其中说的不错的一段:
当自己得到这个问题的答案之后,我思考的第二个问题是,在具体的项目实践中,怎么去落地这5个价值观?对于勇气,尊重,专注,开放这4点,我并没有花费很多时间就想到了方案,我相信如果能认同这些价值观,并真正的去思考了,找到落地方案并不难(比如说上一式里的团队契约,就可以一部分落地尊重,公开的价值观)。


但是对于承诺这一点,困扰了我不少时间,因为我发现自己并没有真正理解承诺(commitment)到底是指什么,是在计划会上或者站会上做一个promise,然后必须要是实现它么?那如果没有实现怎么办呢?如果是这样的话为什么不叫promise,而是叫commitment呢?


出于以上困惑,我想到,promise和commitment都是英文,或许我应该去看一看这两个词在英文里到底是怎么用的。然后我就去查了下字典,考虑到commitment的词根是commit,所以我查的是commit(然后我惊喜的发现commit居然还有自杀,犯罪的意思),很不幸我并没有找到答案。


就在这个时候,敏捷小伙伴的微信群里正好有几个老司机在讨论commit的具体含义,超级老司机徐毅提供了一个解释,叫“致力于......”,这个解释让我豁然开朗,至少在自己内心中,我认为我找到了答案(在此为老司机徐毅孜孜不倦的求真精神点一亿个赞)。我用下面这个例子来阐述我对commit的理解。


如果说这个小男生能每天都很早起来为他心爱的小女生做早饭,如果说他能一直陪伴着小女生做两个人都喜欢做的事情,如果说他能经常送小女生喜欢的包包,衣服,化妆品,如果说他能每天晚上给小女生打洗脚水...... 这个时候,我们可以说这个小男生commit了。这也印证了“致力于......”这个解释。


但是,这个小男生这时候兑现了他的promise了么?并没有!因为他的promise是 “I will love you forever”,他得一辈子都爱这个女孩儿才算是兑现承诺。霸王别姬里程蝶衣说 “说的是一辈子,差一年,一个月,一天,一个时辰,都不算是一辈子!”。(怀念一下哥哥)。


理解了commit之后,就知道我们在项目过程中,落地commitment这个价值观的努力方向了:引导团队真正的付出努力去兑现他们的承诺。然而,要真正的付出努力,那就必须是发自内心的承诺,不应该是强迫,不应该是命令,不应该是控制,否则就不是发自内心。要发自内心的承诺,那就需要基于于对目标的真正认同,并意识到自己能为这个目标所能贡献的价值。那怎么样才能让团队真正的认同目标呢?请看 第一式 WHY到怀疑人生 。以上几点,就是一个敏捷教练,或者Scrum Master在引导过程中,对于落地commitment这个价值观的行事原则。


到了这里,同学们或许会问,那如果团队成员确实commit了,是不是没有兑现promise也没关系呢? 当然不是的,我们关注团队成员是否真正的付出努力去兑现承诺,并不意味着我们不需要关注最终的结果。我用下面这个表格来描述我对promise,commitment,和最终结果的关系梳理和落地commitment价值观的策略。
2008-04-02 11:08:00 wxhgood 阅读数 395
  • SCRUM敏捷开发视频教程

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

    10436 人正在学习 去看看 CSDN讲师
马云曾经说过,阿里巴巴的六脉神剑就是阿里巴巴的价值观:诚信、敬业、激情、拥抱变化、团队合作、客户第一。而这六条价值观充分体现了敏捷团队的核心理念和以客户为中心的思想,如果说阿里巴巴的成功是基于这六条价值观,那敏捷开发团队要成功也正是需要敏捷团队最这六条价值观的高度认同。

1.诚信,敬业
敏捷团队强调人,强调自发的学习型团队和组织,但是前提仍然是每个人必须要诚信敬业,每个人都必须重视自己的承诺,对自己的产出工件负责。当诚信,敬业和个体技能是能二选一的时候,仍然需要首先选择态度和责任心。有了这两点才谈得上树立团队价值观和建设团队精神。

2.激情,拥抱变化
这是敏捷强调了核心价值观,对于软件开发中的需求,不变是偶然,变化是必然。我们虽然应该遵循开发计划,但是并不应该排斥需求变化,只要变化是有利于客户价值实现的,都应该以积极心态去面对和拥抱变化。

3.团队合作
团队合作的基础是团队中每个人都能够做到诚信和敬业,团队管理者能够承认和尊重团队中每个人的价值。团队合作的重要工具是沟通和交流,而且最好是面对面的沟通和交流。另外在敏捷团队支持原则中还谈到,敏捷团队应该是自组织和自适应的,团队需要不断的进行反思和总结,以支持持续改进。

4.客户第一
软件团队开发的最终目的仍然是开发出能够另客户满意的产品。较之合同谈判,应更注重跟客户合作的价值,而且也只有客户价值实现了企业自身价值和团队价值才能够真正体现。东软在很早就提出了软件创造客户价值的企业文化,该价值观将对所有软件企业和开发团队适用。
 
2011-06-03 12:00:00 cheny_com 阅读数 8385
  • SCRUM敏捷开发视频教程

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

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

作者:陈勇

出处:blog.csdn.net/cheny_com 

 

这是CMMI与敏捷开发比较系列的第二篇(之一之二,之三)。

CMMI

 前面在提到CMMI与敏捷的根本差异时提到CMMI是美国用于筛选其供应商的,而其项目的特点也在于大型团队/强分工/长周期,这样就不难理解CMMI为何提出了以下要求(基于CMMI V1.1):

  • GP1:管理需求
    • SP1:与客户达成一致理解
    • SP2:取得开发团队的承诺
    • SP3:管理变更
    • SP4:追溯不同层次的需求关系
    • SP5:追溯需求与后续工作的关系

笔者之前做过一些军工项目,所以对军工项目有所了解,以下这些词汇在军工项目里边是非常关键的:甲方乙方,系统工程,预算,结帐,多个供应商联合开发,集成,验收……因此: 

  • SP1/SP2带有很强的甲方乙方买卖的色彩
    • “一致”“承诺”是在买卖合同语境下无奈之举,在外包环境中无论做法如何都是必要的。
    • 不应在企业内部开发中也过度强调,比如在自主研发中实施产品经理/开发团队签字等“仪式性”举措。
  • SP3/4带有很强的系统工程的色彩
    • 就是每个项目多半是一个软硬结合的大系统(比如一种型号的飞机),很少有一家企业能完全包揽。Telelogic有一个工具叫做DOORS,其主要客户群就是制造业(包括军工),其核心思想不是敏捷中的那种条目化的需求分析及跟踪/优先级排序(也有),而是系统需求逐级分解/层层对应:整架飞机可能十年前设计的,但今天组装起来,不少一个零件,不多一个零件。在大型系统工程中,按部就班地完成事先预想保证项目成功的必要性远远超过创新性(尤其是飞机已经定位好了,但几个程序员在开发过程中因为“被激励”了所以想进行创新……这在军工项目里边是不可思议的,他们应该以更受控的方式参与创新)
    • SP3突出了在跨企业研发的语境中,一个变化应该被多个可能受到影响的企业理解和实现
    • SP4则突出了多个企业开发,却“不多一个零件,不少一个零件”
  • SP5也带有系统工程的色彩
    • 阿波罗计划有2万家企业的30万人参与,11年完成,这里边就有一个“他们在干什么”的问题,以及“他们能按时完成吗”“有没有漏掉什么需求”的问题

从这一点看,在大型系统工程中,CMMI作为其“神”而存在是很恰当的。尽管有很多人强调军工/航空航天也能应用敏捷开发,但这和Intel说自己参与了奥运会因为奥运会用了Intel Inside的电脑一样,只是“形”和配角而已。笔者认为推广敏捷开发的同好们不应该追求这种虚荣,而是应该在自己擅长的领域先把事情做好。

另一方面,如果实施CMMI的企业并非处于上述语境中,应该恰当地选取适合自己的实践。

 

敏捷-Scrum与XP

仅从需求管理的角度看,可以排一个顺序:CMMI-Scrum-XP,越往前越强调可追溯性/一致性,越往后越强调创新型/灵活性。这个倒没有好坏之分,而是我们想要什么的问题。

Scrum中对需求管理的解决方法与CMMI的要求很相似。注意这里的用词:对Scrum,是一种具体解决方法;而对CMMI,是一种要求。不过CMMI的要求还包括一些GP(Generic Practices通用要求,主要包括计划,角色与技能,记录,对记录的管理等内容),因此不能认为实施了Scrum就满足CMMI的需求管理了(满足CMMI3的含义就是:如果没有别的限制,任何时候都可以参与美国国防部招标了)。

 

下面是用敏捷方法来满足CMMI要求的一些对应。

  • GP1:管理需求
    • SP1:与客户达成一致理解
      • 敏捷对需求的理解,较少提到合同的死条文。敏捷假设你已经告诉我你的商业价值,而我正是要交付这些价值。
      • 在Scrum中未提及太多与客户进行需求沟通的过程(这个不等于Scrum要求“不要管理与客户的需求沟通”,只是“我不管”的意思)。在XP中提到了现场客户的解决方案,不过XP的提法不涉及需求的范围这个至关重要的因素,而是更关注要实现的需求是什么的问题。之所以有这个“明显的失误”,是因为敏捷的创始者(们)绝大多数并不负责与客户洽谈合同,当他们开始介入工作的时候,项目已经进入“遵循(一个令人无奈的)合同”的阶段了。
      • 因此在使用敏捷的时候,不能持有“我们已经用敏捷的方法管理与客户的沟通,所以一切应该万事大吉了”的观点,应该补充对需求范围的管理,尤其是在甲方乙方的语境中。需求范围的管理应该基于商业心法,而不是开发心法,在这一点上澳大利亚(SouthenScope方法)/韩国(软件成本估算标准-知识经济部公告)/日本/芬兰都有相应的法律和条文,大致都基于IFPUG或NESMA功能点分析方法(FPA)。
      • 具体应用方法:
        • 使用XP的现场客户时,应配合Scrum的PO制度,也就是说由于甲方(也包含内部的甲方)很难找到一个高度足够,而又能天天处于现场的代表,极有可能导致产品在最终验收时被推翻。引入PO可以缓解现场客户的局限性,尤其是如果建立PO团队,可以有效避免现场客户个体的局限性。
        • 即使使用现场客户,定期利用Scrum中的评审会,引入客户(含内部客户)的高层参与,保证大方向不偏。
        • 如果在甲乙方的语境中,评审会应留下纪要
        • 应该配合早期范围管理,防止需求开发的过程变成需求蔓延的过程。请关注“早期软件成本估算”这个词汇,未来两年中将会出现面向政府行业的中国的一系列国标,也适合其他行业。
    • SP2:取得开发团队的承诺
      • 这是Scrum和XP尤其前者做得很好的地方,即通过计划会来取得开发团队的承诺。
      • 值得注意的是承诺包含两部分,一部分是理解了要做什么,第二部分是要花费多少工作量。因此在缺少充分沟通的情况下,简单地由开发人员提交一个估算清单是不行的。
      • 具体应用方法:
        • 应确保使用Scrum中的共同估算制度,也就是说承诺是一种在充分理解、集体智慧下的产物,而不是给你一个清单,填多了算你赚,填少了算你赔的赌博。
        • 为承诺划定“模糊界限”,也就是使用MoSCoW方法,用一种透明的管理方法平衡冒险、保守、缓冲、激励……等各种矛盾因素
        • 承诺的变更管理,既然承诺=理解+工作量,理解变了,承诺就相应变了。
    • SP3:管理变更
      • 先说一下管理变更的心法,所谓心法,就是做一件事情的时候心里所想的事情。如果变更过程中心法如下,则任何技术管理方法都无解:
        • 甲乙方语境:甲方-不用加钱把这功能加上;乙方-价钱工期已定,千万别变
        • 内部研发语境:高层-加上这功能但工期别变;乙方-工期快到了,千万别变
      • 敏捷既拥抱变化,又迭代期内无变更,其实在一定程度上默认改变了上述语境(但历来敏捷相关文章中都没有说破)。
        • 拥抱变化在于如果你感觉变化有价值,又愿意为变化付出,开发团队乐意效劳。因此不能理解为无条件的拥抱,尤其在甲乙方语境。
        • 迭代期内无变更在于项目(产品)是有其商业目标的,迭代期内无变更表明在迭代前,应该从商业目标出发做出版本计划,从而保证大家不是跟着某个人的脑子在跑而是跟着商业目标在跑。因此如果PO在之前不正确理解商业目标做出计划,而是认为可以随时变化,是对开发团队工作的不尊重,也迟早会造成项目/产品的失败。
        • 关于以上两点另有两篇博文详述。
      • 具体应用方法:
        • 应配合早期需求范围管理方法(参考SP1中),防止变更过程变成不受控的蔓延过程。
        • 应建立长周期的商业目标和版本计划,要变化的是怎么实现,而不是实现什么。在无框架约束下进行变更,是一件非常危险的事情。
        • 应使用MoSCoW方法,平衡变更与承诺的矛盾。
        • 在甲乙方语境下,变更管理应以商务人员的意见为主。
        • 如果是采用XP方法,应引入Scrum的PO制度。尤其是在甲乙方语境下,PO必须是基于企业(供应商)利益思考的,而不是甲方派来的打着“追求客户价值最大化”招牌的卧底。
    • SP4:追溯不同层次的需求关系
      • XP中提到的史诗故事-用户故事较好地支撑了这个实践,不过这个和前面提到的系统工程中的需求拆解不是一个概念,两者目的和颗粒度差别很大。
      • 具体应用方法:
        • 在产品研发语境中,应基于目标客户群(用户建模)和商业目标来导出产品的需求条目和结构,也就是所有功能最后都多少地被某些客户经常使用,并因此促成了采购。有很多产品不断升级但却没有人购买新版本(比如多数人都在用7年前的2003 Office,和更早一点的XP操作系统),就是因为缺少代表产品之神的上级需求;可怕的是无论有没有神,任何产品都能找到需要升级的功能。
    • SP5:追溯需求与后续工作的关系
      • XP中的TDD和持续集成与此非常相关,因为每次测试和集成,都是对某些需求满足情况的验证和证明。
      • Scrum中提到PB的颗粒度较大,到SB中需要拆解为具体任务(也有观点说不拆解的,下详),也支撑了这个实践。
      • 具体应用方法:
        • 面向用户故事(或者说用户价值,用户需求,PB)来进行迭代评审,而不是开发任务。这也是笔者整体偏向在SB中直接使用PB中的故事而不进行任务拆分的原因,因为一旦拆分了任务,极有可能任务全都完成了,故事却不能交付。

其他说明

 CMMI中的GP的满足,敏捷中较少提及(也没有必要提及),比如所需的技能是否有培训等;如果正好在做CMMI,请做好相关记录。

这些GP并不是说不做项目就不能成功,产品就不能热卖,只是说作为美国国防部(DOD)选择供应商,或许Google转身很快,或许IPad很热卖,但我还是很想找个稳当点的公司来造飞机。

这不是方法论之争,只是商业目标造成的价值观差异而已。

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

2013-07-15 13:45:11 nylx 阅读数 1271
  • SCRUM敏捷开发视频教程

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

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

传统的开发团队通常按角色就行分工, 开发人员只管开发, 测试人员只管测试, 在自己的职责之外的事, 要么是看不见, 要么是觉得不是我的活,我不用去管,做好做坏和我没有关系。

而敏捷软件开发恰恰相反, 更加强调“Whole Team”, 即整个团队对外做出承诺, 团队中的所有人对所有的开发,测试,文档等任务附有责任。

如果不能按时交付高质量的软件, 就是整个团队的责任, 某一个Developer/Tester做的再好也不行。

这就要求团队中的人能互相帮助, 正像华为公司说的“败则拼死相救, 胜则举杯相庆”。 所以团队中的人员最好具备多种技能,Developer能帮助测试,Tester能帮助写点代码, 写点文档...

这样大量的任务就不会挤压在某一个人身上,导致项目失败。

这样问题就来了: 团队中每一个人都必须成为通才吗? 能成为通才吗。

最近看了Mike Cohn的一个ppt,其中的一个例子回答了这个问题, 觉得很精彩, 拿出来和大家分享:


Mike Cohn 用不同类型餐馆的例子来表明了他的看法:

Meconi’s 是一家熟食店, 它有一个订餐员(Order Taker)和很多三明治厨师(Sandwich-maker),  你要去吃午饭的话你觉得体验如何? 我们会看到门外排了很长的队伍 -- 因为只有一个负责订餐的, 她非常繁忙的记录下所有这些订单。 但是一旦下了订单,老兄你估计很快就能吃到了,因为会有9个人冲过来做三明治。  但是我可不想在门外排这么长的队伍, 等这么久, 我们还是去 Bruno 家去看看吧

Bruno 恰恰想法, 它雇佣了9个订餐员,而只有一个三明治厨师, 你的订单很快会被处理, 很明显你不得不等巨长的时间才能吃到。

Ferentino 家似乎有些独特,四个订餐员,四个厨师, 还有五个机动人员(Floater) ---- 即会订餐,也会做三明治。当三明治订单太多的时候, 他们会到后厨去帮忙---也许他们做的不能和厨师一样快, 一样好。 当顾客太多的时候,他们也会冲到前台去帮忙处理订单 -- 他们也许不能做的很完美, 但足够好就行了。

很多餐厅都会明白了这一点: 保留机动人员是个好主意, 但是不是每个人都必须成为Floater.

回到软件行业, 为什么我们的敏捷团队不这样做呢: 让一些专才具备多种技能, 不一定具备团队所要求的所有技能, 只要这些人能平衡好Workload 就够了。
2010-05-27 12:21:36 zhanghsh2010 阅读数 73
  • SCRUM敏捷开发视频教程

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

    10436 人正在学习 去看看 CSDN讲师
1 站立会议全员都需要参与;
2 当值员必须提前准备,识别出问题和风险,做好协调;
3 每个组员汇报进展和当天的计划。对于承诺的任务,需要完全执行;
4 每日站会实践不能超过20分钟;
5 三段论:昨天完成什么,今天计划做什么,困难;
6 成员之间信息共享,每个组员都能了解项目总体进展;
7 不要陷于技术细节的讨论,当值人员应该记录下所有的阻碍并跟踪;
8 把每个问题用跟踪卡片(或在JIRA)跟踪起来。
没有更多推荐了,返回首页