项目管理者联盟 | 中国工程管理网 | 中国研发管理网   会员中心 资料库 博客 圈子

PMI-ACP®认证

适合敏捷开发项目
敏捷项目管理最佳实践

网络课程

PMI-PBA®认证

重视项目商业分析
商业价值与需求分析能力

网络课程

NPDP®认证

产品管理国际认证
全球产品管理最佳实践

网络课

PMP®认证

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

PgMP®认证

大型复杂项目全球标准
定位高级项目管理层

网络班

PfMP®认证

链接战略与项目
实现组织资源投资回报

全球直播

软考项目管理

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

论坛
价值源于交流与分享
会员区:
登陆ID 密  码
功能区: 公告建议 | 帖子搜索 | 管理团队 | 荣誉版主 | 帮助手册






 项目型组织  项目管理  工程项目  科技项目  项目化管理  管理软件  资格认证  职业休闲
EPM体系与流程 综合集成管理 总承包管理 IT软件开发 项目型制造 P3E/P6 PMP | PgMP 职业发展探讨
组织与人力资源 进度,范围,成本 国际工程 生物制药 专业服务 微软PROJECT IPMP | PRINCE2 管理学堂
项目管理信息化 团队建设与沟通 房地产 汽车设计开发 生活项目 PowerOn专版 软考项目管理 英语角|读书版
多项目与大项目 质量与风险 监理与咨询 手机数码 文体娱乐 注册建造师 房车吃游
PMO建设与管理 采购与合同 工程设计 项目管理硕士 闲聊版|商务版
俱乐部北京 | 大连 | 福州 | 广州 | 杭州 | 南京 | 山东 | 上海 | 深圳 | 四川 | 天津 | 武汉 | 西安 | 郑州 | 申请成立 TOP榜精华 | 最新 | 最热 | 会员

版面信息

说明:失败的IT项目比比皆是,进度延迟,预算超支,客户需求多变,成员加班抱怨...IT项目(软件开发.,信息系统实施等)寻求新生

本版版主

camer
登录:2013/7/2
次数:867
注册:2003/3/3
发帖:2745
dorothy
登录:2016/12/15
次数:804
注册:2004/9/6
发帖:993
steveli2008
登录:2009/5/26
次数:464
注册:2003/5/12
发帖:1026
zhf_karen
登录:2015/6/2
次数:346
注册:2005/6/13
发帖:469

俱乐部导航

北京大连福州广州杭州
南京山东上海深圳四川
天津武汉西安郑州 

联盟·近期活动

社区热点

华师大CTO学院:科创生态建设与创.
宏发电声江玫瑰谈PgMP:“下好一盘.
PgMP:交付能力与创造未来的项目管.
开放讲座|《项目组合管理与PfMP认证
开放讲座|项目组合管理与PfMP认证
开放讲座|PgMP:项目管理思维与方法
开放讲座|《项目组合管理与PfMP认证
网络讲座|《项目组合管理与个人职业
开放讲座|《项目组合管理与PfMP认证
网络直播|产品经理的四大核心技能提

精彩专题

如何做好项目沟通计划

软件项目质量管理

国际工程索赔与反索赔

更多:

推荐信息

·项目经理沙龙俱乐部
·推荐项目管理公开课程
·联盟VIP会员服务
·联盟99元大课堂
·建造师课程辅导免费试听

社区圈子

HG信用盘0出租
圈主:de123
行业:综合应用

集团企业生态体.
圈主:ETPPM
行业:综合应用

生态系统体系下.
圈主:ETPPM
行业:综合应用

西安IT项目管理
圈主:muzud
行业:IT软件

房地产项目管理
圈主:13935823
行业:房地产

联系社区管理员

咨询电话 010-82273401/11
斑竹申请 admin@mypm.net


版权所有 © 2003-2004
京ICP证070584号 
BBS业务许可2007第353号 
最佳显示模式:1024*768像素
项目管理与PMP认证
为什么软件开发方法论让你觉得糟糕? [发表于 2014/10/5]
状态 开放帖 浏览量 1209   
该帖子同步发自圈子:管理者论坛 (访问该圈子)

围绕软件开发实践和方法论,总有很多教条式的口水仗。阶段式(phase-gate)方法能够有效管理软件开发过程的风险,还是说只是风险管理中的花哨噱头?TDD真的能够促生出高品质软件?结对编程是代码评审的有效替代抑或只是增加了商议沟通代价?我想说,虽然缺乏证据判断这些论调的谬处,但有两条常用的法则能够帮助我们选择好的实践,同时,提升我们所提供软件的价值:划小开发周期以及提升反馈效率。

  Michael Feathers给出了以下观点:

  我认为,我们最终还是得倚重开发者的能力,这才是个更重要的考量因素,而非选择哪门语言或纠结于方法论间的细微差别。坦诚地说,我们都清楚这点,但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申,要是人人都可以替代(随便找个人都能顶上),那该有多好呀?但事实并非如些。

  问题是,我们怎样才能找到有(合适)技能的开发者?IT界从未很好地定义个体生产率,从这点来看,那么,要找到合适技能的开发者就是个很难解决的问题。代码行数(Lines of code) – 在现在仍然是一个主流的度量方法 – 深陷“一行代码一个责任”泥潭,这并不是一个好的方法。而度量工作小时数则是鼓励(个人)英雄式举动 – 经验表明,“英雄们”通常就是导致项目延期的人,依赖“英雄”往往是一开始就采取的不该采取的冒险行动,长时间工作导致人变得鲁钝,并导致低质量软件出 现。目前还没有被普遍接受的针对IT专业人才的专业要求系列标准和雇用范式,招聘好的人才,是一门(招聘)艺术,而非(招聘)工程。

  心理学家至少对这个问题进行了研究:为什么IT业的技能很难被掌握和度量?Daniel Kahneman说(Thinking Fast and Slow),掌握技能有两个基本条件:一个环境足够规律以便可预测;有机会通过长时间实践来学习掌握这些规律。

  但是典型的软件项目往往是没有规律及可预测环境的。项目成功的唯一正确度量就是:最终的结果通过整个生命周期里的实施达到了预期目标吗? 很难知道什么关键活动导致了项目成功和失败,很少有人能够通过旧有或现有的项目获得答案。几乎不可能判定哪些决策导致了成功或失败(在人工智能领域,这叫作信度分配问题)。

  这些因素造成了IT专业人员很难掌握引导产品和服务走向成功所需的能力。然而,开发者掌握能帮助他们更高效地达到目标的技巧,将使他们更有动力 – 通常称之为“开发完成”,尽可能快的、不考虑是否功能被集成以及生产就绪。类似的场景也常出现在其他功能性实施领域。

  实际的软件项目是复杂的,没有规律可循,这会导致另一个问题 – 为了证明某种技术、实践和方法论是实际有效而收集相关数据是极度困难的,几乎不可能在脱离收集环境的情况下归纳出这些数据。

  在Laurent Bossavit的好书《The Leprechauns of Software Engineering》中, 他抨击了软件开发的一些惯式,比如“成本变化”(或“缺陷成本”)“曲线”,这些惯式是许多其它的软件开发方法论知识基础,称开发人员生产率的变化是一个数量级(参照确定性金字塔原理)。Laurent Bossavit说明了相关依据 – 很多人依赖从计算机科学专业学生进行的非正式试验或是从无法被有效控制的项目中收集小量数据。这些研究组织的给出的论调基础往往是不健全的,数据缺乏分析,而且,最过分的是调查结果普遍远远超出了他们的适用领域。

  因此,不太可能轻易下论断敏捷开发实践就比瀑布模式之流合适,反之亦然。“方法大师”的见解其实也没太大指导意义,就像Kahneman说的,“人们在想法方面的信心,并非是有效行事可倚重的因素…当评估专家的想法,即使在有规律可循的情况下,你也一定要想清楚是否有合适时机可以引入其想法的可能性”。就像Ben Butler-Cole指出的(why software development methodologies rock),引入一种新方法往往会带来一些影响。

  你可能会认为当我们决定怎样运作一个团队时,我们就陷入了被动。但细想一下为什么软件开发无章可循?为什么在这个环境里很难进行一些试验以及获取技能?什么实践和决定会导致成功或失败?其中的根原因就是:环境是无规律的,做出变更与理解变更带来的结果之间的反馈过程太长了。这里的“变更”一词是指广义上的需求变更、方法变更、开发实践变更、商业计划变更、代码或配置变更等等。

  还是有一些办法帮助缩短周期的,比如当我们应用精益软件开发思想 – 一个很重要的方法。缩短开发周期在大型产品开发中是很重要的:在Bret Victor的精彩视频Inventing on Principle中提到,“如此多的创新被发现,只要你真正理解了你在做什么,你就能发现任何事物”。

  但对我而言就是这样的:我们几乎不可能实践持续改进、学会怎样使团队或个人变得更好、掌握成功创建大型产品与服务所需的技能。除非我们聚焦于尽可能使反馈间隔时间缩短,以便实际洞察其间关联,以及辨别原因和影响。

  事实上,从想法到反馈的周期尽可能短的好处是如此明显和重要,应该把其作为商业模式中要遵循的一个重要原则。如果你纠结于要把你的产品创建成一个用户安装式的软件还是SaaS模式(Software-as-a-Service,软件运营服务模式,软件即服务),这时的想法会自然而然地推动你强烈考虑SaaS模式(有感而发)。如果你要重建你的系统(包含硬件),应该考虑怎样尽快实现原型(how you can get prototypes out as quickly as possible),以及模块化硬件和软件,以便你可以快速和独立地整合。3D printing(三维打印成型技术)技术看起来在这方面有着巨大的用武之地,因为它可以满足软件开发应用实践朝硬件系统(原型呈现)的演进。如果你想如愿以偿地缩短周期,或多或少按多功能型团队(cross-functional teams)方式运作是需要的。

  软件方法论,即使雇用一群牛人并让他们自我组织,也是糟糕的,因为他们时常搞得“cargo-cult”(货物崇拜,敏捷开发里的知名小故事,形而上):我们在做stand-ups(每日站立会议),我们有优先顺序的backlog(优先待办事务),我们甚至看在老天的份上实践了continuous integration(持续集成)。

  我们的到头来的结果为什么还这么差呢?因为你忘了最重要的事情:建立一个学习能力和适应能力都很好的组织。


>>> 由论坛统一发布的广告:
楼主 帅哥约,不在线,有人找我吗?牛草草


职务 无
军衔 主帅
来自 湖北省
发帖 874篇
注册 2005/5/30
PM币 20534
经验 8776点

  
!  您尚未登录,不能回复主题。    现在 登录  注册
关于联盟 | VIP会员 | 培训服务 | PMP认证 | PgMP认证 | 刊物出版 | 沙龙会议 | 人才服务 | 广告投放 | 联系我们 | 友情链接
建设运营:共创时网络
版权所有 京ICP证070584号 BBS业务许可2007第353号