Category: Agile

Agile Software Development

Velocity is Story Points per Sprint?

One colleague was complaining about the Velocity practice, one part is the definition of Velocity, he says: In Scrum, we define velocity as the average of the story points finished by the team in the last “x” sprints. Well, I

Scrum/Agile Starter Kit

If you’re new to Scrum, and wants to know how you can start, this is the post for you. Please kindly comment on this post to provide your thoughts and your recommendations on whatever resources helped you on your journey

敏捷成熟度模型?

说明:本博文最早发布于本人的新浪博客。 到底有没有、是否需要一个敏捷成熟度模型,业内有太多的讨论和纷争,也都有太多的人从不同的角度提出了各不相同的模型。 Martin Proulx在名为“Yet Another Agile Maturity Model (AMM) – The 5 Levels of Maturity”的博文中提出了自己的看法,开篇两段话写得很中肯。他首先引用Esther Derby的观点,“How agile you are doesn’t matter. Whether you are 50 per cent agile, 90 per cent agile or agile through and through (what ever that

总结Scrum实施经验时勿犯归因错误的毛病

说明:本博文最早发布于本人的新浪博客。 最近和@陈加兴以及@孟晓林Ralph交流时,感到比较痛苦,和@拯救与逍遥等朋友的交流则感觉顺畅很多。似乎大家在讨论同一个东西,但又总觉得似乎讨论不到一个点上去,有点各说各话的感觉,非常不给力。也许彼此都觉得对方的逻辑有些许奇怪、不对劲的感觉,却说不出来,也评不下去。今天因为@孟晓林Ralph的一条微博,大家讨论很给力,偏题也很壮观。内容如下“对于一把菜刀而言,它有其特定的属性,而这些属性决定了它适用于什么,可以干什么和不能干什么等;它只是一个被应用者,它被用去干什么完全是握着它的那个人决定的;它代表的是一种解决问题的思路,只有理解了这个思路,才可能把它用的更好。敏捷这个玩意和菜刀有啥区别么?”。其实,很多东西都具备着不同的身份,例如Scrum。 Scrum是一种敏捷软件开发方法,特色在于它是一个框架,具体的骨肉需要额外填充。 Scrum框架是一个工具,用来指导企业、组织的软件开发工作(或任何工作),它有自己的使用手册(参考其定义),但使用者可以根据需要选择自己的使用方式。 Scrum还是一系列认证的品牌,还被当做是光鲜的外套,也被当做是发泄愤怒的靶子,等等。 另外,我自己写东西的风格是希望内容是严谨的,有逻辑性,不犯归因错误的毛病。但目前许多总结Scrum或敏捷实施经验的文章,或多或少,或有意或无意的,都有很多不准确的地方。 实践出真知。没错,Scrum就是从实践中总结出来的,但是再用回到实际环境中使用时,其效果不见得会等同于其来源的那些实践。 找准问题根源。Scrum或敏捷实施失败会有很多原因,将它归咎于任何单一的因素都是不严谨的态度,不管是企业自身环境还是作为工具的Scrum或其他软件开发方式。 传达信息最好专业点。我不太喜欢写哗众取宠的文章,也许过分了点,但我认为任何人都不应该写这样的文章。如果我要总结Scrum实施的经验,我就不会简单的说“Scrum是狗屁”或者“Scrum万岁”。私下的情感发泄需要,但是博客或文章或微博的受众太广泛,而平面文字的理解总是存在被误读的可能,所以需要小心。 接下来我们看看讨论中具体的一些细节(申明:我没有任何攻击他人的意向,同样的错误我自己也会犯,只是拿出来当做例子分析而已,请谅解。)以下文字为节选,为避免误解,请阅读完整的讨论记录,点击如下链接:http://weibo.com/1794616154/eACaMoVgZUP。 陈加兴:不用敏捷我们也能把项目做好,就跟不用某些价值观洗脑我们依然能够做到相互信任与尊重一样。【个人意见】其实“相互信任与尊重”不就是价值观吗?敏捷明确地提及并推崇了一些价值观,但并不是说除了敏捷就没有别的方法论或是啥的提倡这些价值观了。敏捷的特点无非是说,看吧,我自己秉持一些价值观,为了秉持这些价值观,在面临某些选择的时候,我需要用一些原则来指导自己做判断,而这些原则会引导我走向那些符合自身价值观的选择。 孟晓林Ralph:那么请教一下,敏捷所关注的信任、尊重这类“真正重要的地方”的原因是什么呢?难道其他的项目管理方式就不是以信任和尊重为基础和前提条件的么?难道以为需要信任和尊重就要忽视自身的责任么?【个人意见】看到孟兄这条评论时我顿时觉得血液沸腾心跳加速,同样是问号,这三个问题让我非常直接地就认定为是“反问句”,而且感受到一种咄咄逼人的气势,非常难受。其中的第2和第3个问题犯了二分法(binary)的错误。第二个问题潜在的意思是(当然也可能是我误会了),孟兄认为有人或者我在指责其他项目管理方式不以信任和尊重为基础和前提条件,首先就得说我压根没有这个意思,也没有任何地方说过这句话,如果我脾气不好,可能就直接翻脸了,毕竟这有点泼脏水的嫌疑;其次孟兄可能觉得我们说敏捷提倡信任和尊重就意味着别的方法不提倡,这绝对是先入为主的二分法作祟。第三个问题,至少我从来没说过需要信任和尊重就要忽视自身的责任,再没有引用我的具体话语的情况下,反问我是否表达了某个意思,这样的形式不礼貌。而且,孟兄的话语中有把信任尊重和自身责任放在对立面的嫌疑。 陈加兴: 核心要表达的确实有些不清,主要是两点:1.Scrum所关注的有些偏离技术本身,如任务领用中设计阶段没有清晰划出来;2.它所倡导的“价值观”需要更 高心智水平才能真正实践。【个人意见】第一点就显示出对Scrum的误解,因为Scrum自身(请参考Scrum Alliance上的定义)就是一个框架,我的总结是它主要关注项目、组织(人)、事务的管理,而不是具体细节的操作。所以指责它偏离技术本身,这就是个伪命题。第二点,价值观是没有前提的,秉持某种价值观就意味着你要克服现实世界中的困难去做到,而不是意味着要让你的价值观去吻合现实世界。 孟晓林Ralph:呵呵。信任和尊重同样需要前提。【个人意见】同上,我并不认为信任和尊重需要前提。我很难理解这样的观点,这并不符合逻辑。如果你认为对方需要满足某个前提你才能信任,那么在对方满足前提的过程中,你究竟是在信任人家呢还是不信任人家呢?我认为它们需要的是后续观察而已,信任就像是授权,对方靠谱,就多信任多放手一些;对方能力有限或不太靠谱,那么降低点期待,自己多留意多照顾。信任有度,无前提。 孟晓林Ralph:我自认为我的想法很简单,一个事情不是因为某点好他就好,某点不好他就不好,而具体的环境决定了我们最重要的任务到底是什么。【个人意见】这有点唯现实论(我自己造的词,不晓得准不准)的感觉。其实“具体”和“最重要”就是一个很大的话题。而Scrum或者说敏捷就是明确指出了“最重要”的目标,例如“通过持续不断地及早交付有价值的软件使客户满意”,而把具体留给了实施者或实施组织自己,根据企业的具体情况,制定出达成目标的操作方案。 孟晓林Ralph:我认为从概念的角度去解析概念,如若用事实去证明来的稳妥。【个人意见】我非常想解释清楚我对这个观点的看法,能力有限,希望能讲清楚。正所谓很多时候眼见都不为实,更不要说看待事实的角度不同,总结也是很不相同。我主张对于概念的解析应引用其原始的定义,而对于实际操作中的问题,则要分割概念本身以及概念的具体实现,从而RCA(Root Cause Analysis)才不会有失偏颇。如若归因错误,便会证明出一个不同的甚至是错误的观点,其危险性在于通常会引导人把有限的注意力放在错误的地方,浪费掉有限的精力、财力、物力去改进。要Correct RIGHT Thing,必须要先Identify RIGHT Root-Cause。 本文并没有讲解一个知识点或知识体系,是为了我自己可以比较集中的、系统些回答讨论中的一些焦点,如有任何异议或不理解,请通过微博或博客评论和我联系。

何物谓之敏捷,何物冠之敏捷,何物之为敏捷

说明:本博文最早发布于本人的新浪博客。 前段时间在前公司论坛上发帖,介绍敏捷宣言简体中文版本的最新消息,没想到招来一帮“同事”冷嘲热讽、含沙射影,心中颇为不快。幸好时过境迁,我已不是当时当日那个见着别人不理解、不认同,就会冲上去一定要解释到人家理解的那个傻小子,默默地一笑而过,不再在这些不开窍的人身上浪费时间。但是也依然感到非常沮丧,在诺西杭州这个敏捷很早就生根发芽的肥沃土壤中,依然有这么多人没有真正地理清楚敏捷真正的含义,也分不清楚开发失败或成功与敏捷的关系。当时就想着要写这么一篇博客来诠释我心中的理解,也希望能够同样帮助到其他对敏捷感到困惑、疑虑、怀疑或其他任何感受的朋友们更多地理解敏捷,以及敏捷在国内的现状,和如何帮助敏捷发挥实效的方法。 何物谓之敏捷 敏捷的本源自然是那十七位大牛所写的敏捷宣言,也就是http://agilemanifesto.org/网站上的内容,包括四项价值观和十二条原则。如今它已经被翻译成为(英语之外)二十二种不同的语言,其中就包括繁体中文和简体中文。敏捷宣言的内容非常简单,英文版264个单词,中文492个字。如此简短的文字,自然不可能把实际操作中可能遇到的种种情况一一描述,也不可能给出所有可能的解决方案。 价值观描述的即是思维的顺序,例如,在考虑需要制定的流程或是要开发的辅助工具之前,首先要考虑的是我们的人怎么样,在工作中他们有哪些互动,在这些互动中,他们需要些什么样的帮助,哪些地方是我们通过总结一个标准流程能够规范操作的,哪些地方又是我们提供一个工具的话能够大幅提升工作效率的。也即是说,流程和工具要服务于人,而不是人去满足流程去服务于工具。 而原则描述得则是内心的坚持,是排除万难也要做到的事情,也或者说就是没有任何借口去允许违反原则的行为。例如无法经常地交付可工作的软件,原因也许有很多,但是正确的或者说敏捷的态度应该是“让我们来分析一下无法做到的原因,把困难一个一个的解决,力争到xx月xx日能够开始频繁交付”,而诸如“可是编译很慢”、“一直没有所需硬件”、“测试太慢”、“开发的bug太多”的话语都是借口而不是原因。 比较关注细节的人会发现,虽然网站的名字叫做AgileManifesto.org,但正文的标题却是“Manifesto for Agile Software Development”。我们言必谈“敏捷”,却有许多的人没有注意到我们谈的其实是敏捷软件开发。不管怎么弄,搞“敏捷”的一定不能脱离“软件开发”这个核心。“敏捷”是“软件开发”的一个修饰,是一个形容词。 结合形容词这一特性和敏捷宣言的内容(价值观、原则)可知,“敏捷”并非是一个完整的、全面的、事无巨细的流程,而是一种方式,用于创造新流程、改进老流程的思考的方式。把“敏捷”和CMMI等重型流程进行比较的行为可算是伪命题,“水果”和“香蕉”如何可以进行比较? 何物冠之敏捷 目前国内所言的“敏捷”可谓群魔乱舞,似乎只要有那么一丁点儿的沾亲带故就可以言必称“敏捷”,开口闭口“你这样不敏捷”、“我们一定要敏捷”,却讲不出所以然。人类的本性中肯定有趋炎附势这一条,在软件开发领域也不例外。当“敏捷”越来越火热的时候,“敏捷”就成了一块招牌,可以提升品牌、抬高档次、提高收入等等。同样也成为了许多人借刀杀人的工具,在企业全面转型“敏捷”的大环境下,把自己的提议盖上“敏捷”的帽子,使劲地扣在别人的头上,对该提议的任何意见、反对都被冠以“和企业作对”的头衔予以坚决的打击和灭杀。于是乎,企业里人人自危,“敏捷”迅速转变成人所厌恶的花架子。而最令人心碎的则是,那些被所谓“敏捷”人士搞得很郁闷的人找到突破口后就会大发牢骚,例如公司的论坛,而在此时,会愿意挺身而出,希望能帮助大家看清楚问题,理清楚思路,传达正确的认知,从而能够在未来做好敏捷的,则是真正的敏捷人士,相反那些所谓的“敏捷”人士才不会来到这里献丑呢,也许他们有足够的自知之明吧。而众怒难为,任何一个人的挺身而出,都被看做是一个绝不还手的靶子,盛怒之下没有人在意究竟他们是真正的敏捷人士还是所谓的“敏捷”人士,只管蜂拥而上,理论也好、暗算也好、狡辩也好,把对方欺负得体无完肤。该敏捷人士越是热心地想要解释、帮助大家分析、澄清,越是被抨击得厉害。 不只是企业内部,敏捷所形成的这个市场也如是。挂着“敏捷”的狗头,卖着不知所云的服务的有之;怀抱传播敏捷的梦想,传到授业解惑的有之;浑水摸鱼,什么热门卖什么的跟屁虫有之;空洞的大道理售卖,无甚具体实践经验的有之。而那些刚刚听说“敏捷”的人们,根本就不具备明辨是非的能力,也更谈不上知道谁才是真正在推广敏捷,谁又是挂羊头卖狗肉。当市场上的某个热点消逝之后,也会有需求创造另外一个热点,从而围绕它来搭建一个产业,提供一大群人的口粮。敏捷恰恰是这个领域的下一个热点。 让一切变得更糟糕的是话语权的沦陷。网络的特性导致所有人的语言都处在同一个平面,对于“专家”的判断更先困难,包装完善、风光、言语间意义深远是最容易判断但也最容易被误导的标准。靠谱的人都知道,这样的混乱局面,只能退缩到那个最核心的敏捷人士圈子,靠彼此面对面的相识和交流甚至合作来判断其知识和能力。而这一批人为了满足自身的学习和提升需求,把时间分配给了最高效的活动,也即是面对面的交流和实战,要让他们来鼓吹或是正本清源,他们不觉得有多少的价值。自己切实地着手改善企业的软件开发能力,优化企业交付的客户价值,远比在言语之中一逞口头之快,却根本不知道网络的另一头是否有理解、是否会去真正操作敏捷软件开发来得有成就感得多。话不在多,投机则行。言不求絮,先行为上。 所以,叫“敏捷”的不一定敏捷,真正敏捷的不一定称呼自己是“敏捷”。要有自己的是非判断能力,方能走上真正敏捷的康庄大道。 何物之为敏捷 究竟什么才是敏捷呢? 从方法论的角度讲,符合敏捷的条件的,或者说谈得上是敏捷软件开发过程的,包括如下一些:Scrum,极限编程(XP),水晶方法论,特征驱动开发等。最出名的就要属Scrum和XP了。 从某种程度上来说,凡是说“我们用的是敏捷开发方式”的都是瞎说、乱说。敏捷根本就不是实物,何来在使用敏捷之说。靠谱的说法是“我们用的是Scrum开发方式”,或者“我们部分采用了XP中的实践”。可如果要更严谨地说,其实“我们用的是Scrum开发方式”也不对,因为Scrum本身是一个框架,不是一个完整的开发方法论,说“我们用的是基于Scrum,以及一些XP实践的开发方式”要更靠谱一些。 使用最广泛的,也是目前最流行的其实是Scrum+XP的方式。Scrum提供了管理的框架,给出了如何组建开发团队、管理产品开发的进度、需求管理等等各方面的指导性原则和基础,例如要用且仅用一个优先级排序的列表来管理需求,团队必须是5到9个人之间,每一个迭代结束时要召开回顾会议反思如何提高,等等。它刻意地把具体的操作方法留给了使用Scrum的人,因为不同的人在不同的时间在不同的环境里使用Scrum来管理不同的产品开发和团队,需要采取的具体措施会很不一样,而遇到的困难也会不一样。但Scrum自身的一切都能够无缝的、完美的放入。不管是什么样的软件开发,都应该有一个优先级排序的PBL(Product BackLog),对吧?不管是什么样的软件开发,都应该(可以)由5~9人的自组织团队堆叠而成,对吧?也正是因为它这样的特点,和特别设计出的灵活性,它的目标市场其实并不只是在软件开发领域,只要是应对Complex范畴问题的团队、组织,都可以使用Scrum来管理他们的工作。 而XP则是绝对纯粹的软件开发领域方法,他们关注的就是如何又快又好地写出优质的代码并转化成有价值的软件。所以它最为人知的也就是那些非常具体的工程实践,例如测试驱动开发(TDD)、持续集成(CI)、可接受性测试(Acceptance Testing)等等。不过比较遗憾的是,正因为它关注的是实践,其生效的重点也就在“实践”,而不是描述和理解,就是俗语讲的没啥好说的只管做就好了。真正做XP的估摸着也都忙头埋头干活,没啥精力去鼓吹、宣传和推广它。正好被广泛传颂和使用的 Scrum自身并不提及如何开发代码、分析需求,XP的各个实践就是最好的补充,这也间接地造成它的实践反而享有比XP自身更高的知名度和名声。国内随处可见只知TDD却不知XP的人。 其他的一些方法论,则显得略为冷门,不介绍也罢。当然对于志在未来从事伟大的敏捷推广事业的人,多了解了解敏捷的历史,和其他敏捷方法论是有好处的。至于Agile Modeling等在维基百科上同样被列为敏捷方法论的一类,由于它们可以比较好地融入基于Scrum的开发过程,也不描述了。 总而言之,在国内,我们通常所说的敏捷都是在说Scrum+XP的方式。尤其要考虑到在国内敏捷相关大会中分享最多或者被谈论最多的是类似诺基亚西门子网络这样的大型企业敏捷转型的故事和方式,而它们所采取的正是Scrum+XP的方法,更不要提在国内很活跃的Bas Vodde,他和Craig Larman所撰写的转型两部曲主要描述的也是这个方法。 至于所谓的“敏捷”,其定义也就无穷无尽,我有限的脑容量和脑细胞经不起这样的折腾,各位看官若是有闲可以自愿去了解。 敏捷与项目成功的关系 也正是在前公司论坛上的讨论让我感到很心痛,其中有人抨击“敏捷”,有人提到某产品开发就是采用敏捷算是个好例子,有人就说谁要是把那产品开发成功的原因归功给敏捷他就和谁急,马上又有人出来添油加醋地说“敏捷”啥也不是没有员工们的加班和辛苦劳动项目不可能成功,让“敏捷”这种东西滚一边去。 实在是想要让他们好好地想一想,难道以前大家工作得就不努力吗?可为什么项目还是失败呢?现在某个产品开发成功的原因就只有勤奋工作的员工吗?难道所使用的持续集成系统和单元测试以及测试驱动开发的实践,不是敏捷吗?难道敏捷就在提倡不要勤奋工作吗? 项目的成功也就那么几个关键因素:人、方法、工具。 人不好,说什么也没用。敏捷就是在呼喊着让大家把目光回归到人,关注他们的发展,他们工作所需,想尽一切办法帮助他们发挥最大的效率。曾经听到过一个非常可笑的观点“敏捷就是加班”,而这个观点的来源是因为在他的前一家公司老板举着“敏捷”的幌子逼大家加班,可这和真正的敏捷有一毛线的关系啊?敏捷都直接点明了“个人和互动高于 流程和工具”,以及要“激发个体的斗志,以他们为核心搭建项目。” 方法不对,事倍功半。同样的时间,先写代码再测试而后修复bug,和使用TDD的方式,除去学习曲线带来的开销,后者远比前者高效。罔顾更好方法的存在,就好比抓着铁锹的根部挖土,汗流浃背没什么产出,还不肯听从别人的劝告“握住木把柄的头更省力”。敏捷宣言里也赫然可见“坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。” 工具有点像催化剂。人和动物的区别就在于会使用工具,找准切入点,选择合适的工具,就能帮助团队提高生产效率,节约时间投入其他有价值的活动中去。但始终还是应该在先考虑前两者都满足的情况下才寻找工具这个解决方案,不应迷信工具。敏捷宣言里有说“个人和互动高于

敏捷宣言的简体中文版本发布

说明:本博文最早发布于本人的新浪博客。 3月28日,美国的敏捷联盟发布了敏捷宣言的简体中文版本,成为敏捷联盟的翻译敏捷宣言计划正式发布的第二十二种语言(英语原文除外)。 翻译敏捷宣言计划是敏捷联盟内部的一个项目活动,由Henrik Kniberg和Ward Cunningham负责管理,它旨在将敏捷软件开发的宣言传播到世界各地。翻译的内容包括四条价值观以及十二条原则。关于这个计划的更多信息请观看Esther Derby对Henrik的采访视频。翻译计划已经将敏捷宣言的英语原文翻译为包括阿拉伯语、荷兰语、德语、法语、日语、意大利语、葡萄牙语、俄语等在内的二十一种语言,繁体中文版本(由Steven Mak和Chris Tong负责协调)也已经于去年11月正式发布。 简体中文版本由徐毅进行协调,2010年5月22日正式启动,翻译工作的主阵地是位于LinkedIn的“敏捷宣言(简体中文)”讨论组。翻译工作得到了全国各地敏捷爱好者的大力支持,大家通过私下的邮件交流、公开的论坛讨论、邮件讨论组沟通等方式积极参与到宣言的翻译工作中。正式发布的简体中文版本参考了现有文献中现存的译文,包括Bob Martin的经典作《敏捷软件开发——原则、模式与实践》、维基百科上的相应条目、Bas Vodde和Craig Larman的合著《精益和敏捷开发型应用指南》,以及敏捷爱好者们提供的各种版本。 翻译全程的故事将随后整理记录发布于LinkedIn的“敏捷宣言(简体中文)”讨论组,所有参与者的贡献也将被记录入翻译敏捷宣言计划的维基网站。 其他语言版本的翻译状态点击此链接:http://spreadsheets.google.com/pub?key=tVRbFEMo6Z84yoGsTDcKBHg&single=true&gid=0&output=html。 翻译历程: 2010年4月30日敏捷宣言中文版翻译协调人确定 2010年6月10日中文版更新为简体中文和繁体中文两个版本 2010年11月25日“敏捷宣言简体中文版本待发布版” 2011年3月1日“敏捷宣言简体中文版——最终评审” 2011年3月8日“敏捷宣言 简中最终评审版(3月8日修订)” 2011年3月23日“计划于3月28日发布简体中文版的敏捷宣言”

“Agile Coaching” Reading Accomplished

Finished reading the book “Agile Coaching” by Rachel Davies and Liz Sedley, it’s just as described : “This book provides you with deeper knowledge of how agile practices work and how to inspire your team to improve. Discover how to

Ideas Triggered During the APM Training

* General LM is not very relative to product, which leads to the problem of Competence Development: Actually the reason we do competence development should be the needs of product development. But now LMs are in charge of collecting competence

Agile Development and Project Management by IIL

# BeforeReading I just blog the training I participated, and record down what I experienced, observed, it doesn’t mean I support its opinion or suggestions. Because personally I believe software development should be managed in the way of Continuous Product

CSM Training by Kane Mar (21~22 April 2010)

After the Shanghai Scrum Gathering 2010, I went to Chengdu helpping Outsofting on CSM training by Kane Mar. Kane is a Certified Scrum Trainer, he argued combining Scrum and XP with Ken Schwaber at 2001, you can find more information

Top