敏捷开发的道与术---MPD软件工作坊培训感想(上)

注:由麦思博(MSUP)主办的2013年亚太软件研发团队管理峰会(以下简称MPD大会)分别于6月15及6月22日在北京、上海举办,葡萄城的部分程序员参加了上海的会议,本文是参会的一些感受和心得。

这次MPD软件工作坊培训,最大的收获就是培训者引导你了解了为什么,而不是直接告诉你该怎么做。其实只要清楚目标在哪,无论怎么走都是可以到的。

随便百度一下,我们可以了解到项目管理的定义是“在有限资源限定条件下,实现或超过设定的需求和期望”。一句话形成了项目管理的铁三角,需求是范围,资源包括时间和成本。

 

这传承多年的“定义”是对的吗?摩托罗拉的铱星计划,计划发射77颗卫星,最后只发射了66颗卫星就“圆满“完成了目标。可谓成本的项目。电影泰坦尼克号拍摄过程多次拖期,预算超出很多,可谓是个彻底失败的项目。

可是结果呢?好像哪里不对?铱星项目发射的卫星现在全成摆设,而泰坦尼克至今仍然是世界的票房神话。

到底哪里不对呢?

我们的项目管理铁三角里忽略了价值。

就是这里了,我们的目标是创造价值,实现共赢。

好,目标在这里了,到达目标的方法有很多,每个人都会找到方法。敏捷有很多的流派,有很多的实践来帮助人们达到这个目标。了解别人怎么做,最重要的是理解别人为什么这么做。

 

要创造价值,第一问题就是做什么是有价值的。换句话说怎么样才能获得有价值的需求。

来自客户? 客户永远要更快的马车。

客户往往讲不清楚需求,但这些讲不清楚的需求有些甚至是影响整个结构的关键。

来自产品人员的策划? 没人能说明下面的设计放在网页上更受用户喜欢。

来自领导,业务顾问,运营团队?

貌似都不太对。

敏捷项目管理说,来自市场的真实反馈。要得到市场的真实反馈我们需要持续不断的及早的交付有价值的软件。通过市场反馈来获取新的价值。

这点做的就好的应该属于各大互联网公司了。每月每周甚至每天的发布新功能到市场上,搜集用户反馈和反应,除了用户的主动反馈,还包括点击率、浏览量、用户停留时间等访问记录。根据反馈迅速移除没有价值的功能,增强有价值的功能以创造更大的价值。(关于移除功能,甚至关闭一个没有价值的项目,这正是敏捷的魅力所在,它不但可以让项目迅速创造价值,也可以让本不能创造价值的项目迅速失败。个人观点:让一定会失败的项目快速失败可以节省大量的资源,给系统带来的价值甚至更高!但这一点却往往被忽略。认为敏捷必须把项目带向成功,想想铱星项目,如果早早发现没有价值,世界可能都会不一样,至少摩托罗拉公司会不一样吧。)

听起来很美,联系我们的实际却很困难。我们不能立即发布新功能到市场上,我们不能随意的移除没有价值的功能,我们甚至很难从市场获得功能的价值信息。听起来很沮丧。但是,幸运的是,我们知道我们的目标是什么,我们可以千方百计地收集用户反馈,我们可以通过我们的声音影响一些决定,让我们做的事情更有价值。这本身就是双赢的事情,应该会被逐渐的接纳。

回到主题,持续交付很好很强大,但它带来了新的问题。如何保证交付质量,如果交付到市场的软件由于质量问题根本不可用或者几乎不可用,是不可能得到正确反馈的。敏捷答,持续集成,测试驱动开发。

持续集成不说了,我们做的很好。测试驱动开发无论何时何地,一提出都是一个争议性话题,因为这看起来太不敏捷了。一连串的问题,写测试脚本会拖慢进度怎么办?测试脚本的质量又如何保证?测试脚本会对变更产生格外的工作量,怎么办?等等。其实,这也是我心中的疑问。通常得到的答案都是,测试驱动开发产生的工作量都是值得的!好吧,还是那句话,目标在那里,为了实现高质量持续交付的目标我们可以选择的方法很多。加强代码审查,对关键功能,关键模块做自动测试覆盖。甚至包括遗留一些bug但是得到用户反馈之后及时修复。虽然理论上没有测试驱动开发有效,但是我们可以根据自己的实际情况,在投入和收益上找到平衡点,步子小一点也行更不容易跌倒。

综上,敏捷项目的“铁三角“:

更强调了价值和质量。

当然质量是很重要的,但质量并不是越高越好。比如,招聘网站一两个小时不工作,和证券交易系统一两个小时不工作,对用户的影响肯定是不一样的。所以质量的要求要依赖产品和需求的背景。

不可忽视的是,铁三角里没有提到,但是却在敏捷项目管理中至关重要的一环——人。

价值是人创造的,为人服务的,很多敏捷实践是围绕人展开,试图找到一种(一系列)通用的方法来最大限度的发挥人的能量。例如计划游戏,组建自组织团队,信息公开透明化,集体承诺目标。都是调动团队积极性,消除可能影响团队成员贡献的因素。

对于敏捷实践,林林总总,有如十八般兵器,各门武功,都是名家大师的智慧精华。但是如果只知道招式不知道招式的目的,很容易被人一招打倒的。

时间: 2024-10-27 08:30:19

敏捷开发的道与术---MPD软件工作坊培训感想(上)的相关文章

敏捷团队的组织与管理--- MPD软件工作坊培训感想(下)

注:由麦思博(MSUP)主办的2013年亚太软件研发团队管理峰会(以下简称MPD大会)分别于6月15及6月22日在北京.上海举办,葡萄城的部分程序员参加了上海的会议,本文是参会的一些感受和心得. 今年的大会延续往届模式,以产品创新.团队管理.架构设计.开发管理.测试管理等五个维度作为五个分会场的主题.对于今年来在软件研发中百谈不厌的敏捷开发的问题,大会从团队管理.开发管理等多个角度为与会者全面剖析敏捷开发中所涉及的种种问题,不单单聚焦于敏捷开发本身,更将视线拓展到管理整个敏捷开发团队上. 讲师都

敏捷软件开发之何为敏捷开发

敏捷开发,Agile Development,就是指能够在需求迅速变化的情况下快速开发软件.我们接触最多敏捷实践方式有:极限编程(XP).结对编程.测试驱动开发(TDD)等. 追究敏捷的历史,就必须要提到著名的敏捷开发宣言,2001年,17位业界专家(其中包括我们非常熟悉的Martin, Martin Fowler)组成了一个敏捷联盟,并且创建了一份敏捷联盟宣言,宣扬了4条核心价值观:     1, Individuals and interactions over processes and

谈谈软件项目管理——敏捷开发

敏捷开发(Agile Development) 随着"敏捷"一词出现在越来越多的项目中,于是,敏捷开发本身也被赋与了越来越多的意义,而敏捷的真正内涵反而变得越来越模糊.如何迈出敏捷开发第一步?是按照敏捷宝典.操作指南或是教父语录,还是因地制宜.因项目定方法?完成所有这些工作后,我们就真的"敏捷"了吗? 一.前言 Agile是指企业能够对外部环境做出速捷.有效的反应,是未来企业的必备素质.21世纪企业面临的竞争环境将是一个不断变化.不可预测的环境.由于高新技术的出现和

网易有道笔记负责人谈敏捷开发的实战经验

摘要: 网易有道笔记负责人谈敏捷开发的实战经验:什么时候适合使用敏捷开发呢?我们的经验是需要两点:一.团队有三名或以上的研发工程师;二.团队内有一名合适的Scrum Master. 有道云笔 网易有道笔记负责人谈敏捷开发的实战经验:什么时候适合使用"敏捷开发"呢?我们的经验是需要两点:一.团队有三名或以上的研发工程师;二.团队内有一名合适的Scrum Master. 有道云笔记团队成立于从2010年,从成立伊始我们就一直积极地在实践中尝试Scrum(敏捷开发的一种项目管理方法)的做法.

《高效程序员的45个习惯:敏捷开发修炼之道》

--敏捷开发入门经典-- [内容] <高效程序员的45个习惯:敏捷开发修炼之道(修订版)>总结并生动地阐述了成为高效的开发人员所需具备的45个习惯.思想观念和方法,涵盖了软件开发进程.编程和调试工作.开发者态度.项目和团队管理以及持续学习等几方面. <高效程序员的45个习惯:敏捷开发修炼之道(修订版)>适合所有程序员阅读. [作者] Venkat Subramaniam博士: Agile Developer公司创始人,敏捷开发权威人士.他培训并指导了美国.加拿大.印度和欧洲多国的上

看《Web开发敏捷之道--应用Rails进行敏捷Web开发,第2版》一个疑问。

问题描述 看<Web开发敏捷之道--应用Rails进行敏捷Web开发,第2版>一个疑问:书上第四章说把<%......%>中的结尾标记改为-%>,才可以将%>后面的换行符输出去掉,但实际上我试了试直接用%>也是可以的,请问怎么回事儿? 解决方案 感觉在rails2.0以上,可以不用!解决方案二:书上说的换行符,只会在HTML源码中出现,不会显示在最终页面中.你点右键看生成的HTML源码就知道区别了.解决方案三:<%= simple_format @conte

[免费讲座] 成都软件技术沙龙 - 开启基于Scrum的敏捷开发全新征程讲座

成都软件技术沙龙4月28日活动议程 开启基于Scrum的敏捷开发全新征程 沙龙介绍: 成都软件技术沙龙成立于2008年,致力于发展成都地区软件事业,结交志同道合的软件界朋友,先后与微软.NET俱乐部,微软社区精英计划,天府软件园以及Scrum成都等机构合作,希望能团结成都地区软件同仁共同交流. 4月28日活动 – 开启基于Scrum的敏捷开发全新征程 时间:4月28日下午1点 – 5点 地点:成都天府软件园A区3号楼大会议室 讲座一:自下而上的敏捷实践 大纲: l 持续集成 l TDD l 自动

敏捷开发与项目管理实战之敏捷需求分析

问题背景 敏捷开发中许多活动都是全员参与而非专人参与.需求分析同样也可以是全员参与 的一个活动.这反映了敏捷开发的"个人与交互胜过过程与工具"的价值观.需求分析是在需 求理解的基础上进行的.因此,全员参与需求分析有助于及时发现团队成员对同一个需求理解不一致的 问题,这很大程度上避免了缺陷的引入.另外,也有助于规避人力风险.比如,一个需求的开发者突然 需要请假,其他开发者可以马上顶替他,因为其他人也参与了其负责开发的需求的分析.此外,全员参 与需求分析也有助于全体成员的能力的提升.但问题

敏捷开发(XP, SCRUM)

敏捷方法的核心思想 敏捷方法是适应型(Adaptive),而非可预测型(Predictive).与传统方法不同,敏捷方法拥抱变化,利用变化来发展,甚至改变自己,最后完善自己.也就是要用重构(Refactoring)  敏捷方法是以人为本(people-oriented),而非过程为本(process-oriented).传统方法把开发者看作一个生产要素(分析员,测试员,程序员),拥有大量的中间产品(需求规约,设计模型等),而忽视了作为决定因素的人的特殊性.敏捷开发它只写有必要的文档,或尽量少写文