我需要敏捷吗:不必关心敏捷的六大理由

本文列举了六个关于为何不必关注敏捷开发的理由,同时深入探讨了这些观点背后的误区,并解释了敏捷如何帮助项目应对不确定性和变化。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

当“敏捷”日益成为整个软件业的热门词汇,作为优秀的开发者、成功的项目经理,我们是否有足够的理由不去关心敏捷?我们帮你列出了6个“不必关心敏捷”的理由,以及对这些理由的深入解释。

如果这些理由仍然不能打消你对敏捷的兴趣,首届“敏捷中国”开发者大会即将来到你的身边。你现在就可以报名参加本次大会,与Martin Fowler和众多敏捷专家面对面交流。

  • 理由1:项目需求? 客户即上帝!

我们的需求来自对客户目标的仔细分析和准确理解, 并严格的将其付之实现,通过签订合同的方式,可以在一开始的时候就明确项目范围,这样也避免了不必要的责任,鉴于我们对待客户要求的严肃态度, 这将是我们不关心敏捷的第1个理由。

通常,软件开发者需要的是精确理解客户需求,并且以合同的方式明晰这些需求,而敏捷项目使用QuickStart来进行这一过程, QuickStart是一个建立对于业务目标共同理解的过程, 其不仅仅是让需求制定者明白客户需求, 也是让客户明白什么是自身需求的过程。 即使是客户,对现有业务过程的理解也并不完全一致,从而带来不同的需求。 然而非常普遍的一种情况是,由于各种因素的制约(文化,理解度, 时间)用户的需求并未完全展露, QuickStart正是一个利用一种行之有效的方法发掘客户需求,将客户利益最大化的过程,而非简单的遵循客户要求。

  • 理由2:项目回报? 我们的客户很有耐心!

客户制定了项目期限,我们需要的只是按期交付,我们的客户总是会耐心等待最后的交付时刻。鉴于我们的客户深谙没有钱不搞信息化的道理,这将是我们不关心敏捷的第2个理由。  

敏捷项目的初始需求是投资回报的基线,通过开发过程中频繁的客户反馈,敏捷使客户来掌舵项目,利用对项目新的认识,对外部环境变化的及时响应来构建更好的系统,以改善投资回报。并且通过尽可能早的交付,敏捷项目使早期部署和早期投资回报变成可能

  • 理由3:市场变化? 超出我们的考虑范围!

总而言之,我们是开发者,我们的客户在需求完成的时候就从人变成了具有法律效力的合同,不管市场怎样,合同确保了我们一方的收益。客户应当为自己的失误决策买单。这将是我们不关心敏捷的第3个理由。

通常,项目80%的工作会按计划完成,在这种情况下,项目的负责人面临着一个艰难的决策,如果在花费了80%的预算后,环境发生变化,项目进入一 个进退两难的境地,我们是否要抱着最后一丝希望来继续开发? 敏捷项目通过渐进开发方式和使用交付情况估算项目进度的方法避免了这样的情况,这些方式提供了真实可靠的反馈而非字面上的进度,过度乐观的商业计划在敏捷 项目中将变得十分明显,这样项目负责人可以有机会更早的重新审视项目的成本和收益,尽早在未陷入投资泥潭的时候抽身而退。

  • 理由4:项目质量? 功能才是用户价值所在!

们需要面对的是客户制定的最终期限,以及在此期限内需要完成的功能,这才是最头疼的根源。通常我们和客户会因为缺少的功能而产生纠纷,对于某些质量问题我 们和客户都认为可以通过fix bug的形式消除,鉴于项目质量并非我们亟待解决的问题,这将是我们不关心敏捷的第4个理由。  

软件开发之中需要控制的4个变数是成本,时间,范围和质量, 大多数的敏捷项目选择控制范围。 所有的敏捷项目都强调交付高质量的软件,而敏捷项目使用的极限编程确保了这一点地实现。

  • 理由5: 项目管理? 一切尽在掌握!

我们有严密制定的计划,并且项目经理会监督并确保计划中的每一项可以按时完成,而且我们也同时认为公司的知识产权就存在于设计文档和代码中,定当控制能接 触到这信息的人群,避免无形资产的流失。 鉴于我们同样能够很好的控制项目以及对无形资产的良好控制,这将是我们不关心敏捷的第5个理由。

敏捷项目从不制造表面假象,通过进行短小的迭代以及时刻面对迭代完成后运行中的软件来开展工作,敏捷项目给予项目负责人和客户持续增加的项目能见 度和控制度。 紧密合作以及训练有素的团队更加强了这一点。在敏捷的团队中,增加信息的透明度,共享这些信息是例行公事一般的行为。 即使为此付出额外的努力,敏捷团队也认为是值得的。

  • 理由6:我们的开发者?他们是最佳人选!

我们有很好的开发者,项目也已经经过仔细划分,每一部分的设计者、开发者都是这个位置最佳人选,我们希望用正确的人做正确的事,否则就是浪费资源,这些开 发者的工作合同也确保了他们在项目结束前不会离开,鉴于我们项目小组经过了仔细组织,这将是我们不关心敏捷的第6个理由。  

敏捷项目强调信息共享,并且依赖以团队方式进行的分析,设计和编码而非某个设计者,这将预防开发过于依赖于某个人,这也意味着预防开发瓶颈的出 现,在一个敏捷项目中,任何一个人在任何一个领域工作都是可能的,每个人工作领域的变化取决于业务上的优先级,而不是他所熟练掌握的部分。

如果这些理由仍然不能打消你对敏捷的兴趣, 首届“敏捷中国”开发者大会 即将来到你的身边。你现在就可以 报名参加本次大会 ,与 Martin Fowler 和众多敏捷专家面对面交流。
目录   译者序   第2版前言   第1版前言   第0章不可知和不可说   0.1和解析体验相关的问题   0.1.1解析模式的冲突   0.1.2检测解析模式   0.1.3思考不准确的思想   0.2沟通的不可能性   0.2.1内部重新组织   0.2.2触及共享体验   0.2.3管理不完美的沟通   0.3聆听的三个层次   0.3.1三个层次和方法集   0.3.2三个层次与本书   0.3.3守-破-离   0.4那么,明天我做什么   第0A章不可知和不可说:演进   0A.1沟通和共享的体验   0A.2守-破-离   第1章创造和沟通的合作博弈   1.1软件和诗歌   1.2软件与博弈   1.2.1博弈的类型   1.2.2软件与攀岩   1.2.3创造和沟通的博弈   1.2.4软件与工程化   1.2.5软件与模型构建   1.3再论合作博弈   1.3.1程序员成为沟通专家   1.3.2更快地博弈   1.3.3标识物和道具   1.3.4减少回报   1.3.5对于首要目标的充分度   1.3.6对于积淀的充分度   1.3.7博弈中的博弈   1.3.8开放源码开发   1.4这对我意味着什么   第1A章创造和沟通的合作博弈:演进   1A.1沼泽游戏   1A.2合作中的竞争   1A.3其他领域的合作博弈   1A.4软件工程的重建   1A.4.1这一词汇从哪里来   1A.4.2我们从哪里走错了   1A.4.3重建软件工程   1A.4.4技艺   1A.4.5合作博弈   1A.4.6精益制造   1A.4.7重建后的软件工程   1A.4.8其他工程化中的协作   第2章个人   2.1人是古怪的   2.1.1寻找特征函数   2.1.2古怪性格的元素   2.1.3不可避免的多样性   2.1.4技术的作用   2.1.5相互冲突的共同点   2.2克服失败模式   2.2.1犯错误   2.2.2宁可失败也要选择保守   2.2.3创新而不研究   2.2.4不能始终如一的习惯动物   2.2.5使用纪律和容忍来应对   2.3以一些更好的方式工作   2.3.1具体化   2.3.2实物   2.3.3在某些东西的基础上进行修改   2.3.4观察和聆听   2.3.5支持专注和沟通   2.3.6工作分配要与个性相匹配   2.3.7天赋   2.3.8奖励要能保留乐趣   2.3.9组合奖励   2.3.10反馈   2.4利用成功模式   2.4.1善于四处寻找   2.4.2人们学习   2.4.3可塑性   2.4.4贡献和采取主动   2.4.5组合成功模式   2.4.6英雄也是普通人   2.5明天我该做什么   第2A章个人:演进   2A.1策略平衡   第3章团队的沟通与合作   3.1信息的对流   3.1.1延迟和机会损失成本   3.1.2尔格-秒   3.1.3渗透式沟通   3.1.4穿堂风   3.1.5信息辐射源   3.1.6热空气理论的应用   3.2跨越沟通的鸿沟   3.2.1沟通的形态   3.2.2去掉某些形态所产生的影响   3.2.3利用各种形态   3.2.4黏度与跨越空间的鸿沟   3.3团队就是集体   3.3.1友善和冲突   3.3.2工作时间的公民意识   3.3.3敌意的XP与友善的XP   3.3.4使用胜利来建立“团队”   3.3.5团队文化与亚文化   3.4团队就是生态系统   3.5我明天该做什么   第3A章团队:演进   3A.1一个修订后的办公室布局样本   第4章方法集   4.1一个交付软件的生态系统   4.2方法集中的概念   4.2.1结构术语   4.2.2范围   4.2.3概念术语   4.2.4发布一个方法集   4.3方法集的设计原则   4.3.1常见设计错误   4.3.2在方法集上成功的项目   4.3.3与作者的相关性   4.3.4七条原则   4.4细看XP   4.4.1XP简介   4.4.2剖析XP   4.4.3调整XP   4.5到底为什么使用方法集   4.5.1方法集解决什么问题   4.5.2如何评估一个方法集   4.6明天我应该做什么   第4A章方法集:演进   4A.1方法集与策略   4A.2组织级的方法集   4A.3过程就是循环   4A.4更简单地描述方法集   第5章敏捷与自适应   5.1轻但足够   5.1.1刚好足够   5.1.2对于编制文档的建议   5.2敏捷   5.2.1最佳击球点   5.2.2虚拟团队的麻烦   5.3变得自适应   5.3.1不厌其烦地进行反思   5.3.2方法集成长技术   5.3.3反思研讨会技术   5.4明天我该做什么   第5A章敏捷与自适应:演进   5A.1对于寓意的误解   5A.1.1迭代必须简短   5A.1.2敏捷团队必须驻扎在一起   5A.1.3敏捷团队不需要计划   5A.1.4架构已死;重构是你全部所需要的   5A.1.5我们不需要什么经理   5A.1.6敏捷开发在纪律上要求很低   5A.1.7敏捷只适合最优秀的开发人员   5A.1.8敏捷是既老又新的、失败的、没有尝试过的   5A.2敏捷方法集的演进   5A.2.1XP第2版   5A.2.2Scrum   5A.2.3实用主义和无名的   5A.2.4可预测、计划驱动和其他中心调整   5A.2.5约束理论   5A.2.6精益开发   5A.3新的方法集话题   5A.3.1敏捷项目管理   5A.3.2测试   5A.3.3用户体验设计   5A.3.4规划管控、Burn图和系统工程   5A.3.5用例和用户故事   5A.4经久不绝的问题   5A.4.1最佳击球点和下降   5A.4.2固定价格、固定范围的合同   5A.4.3敏捷、CMMI和ISO9001   5A.4.4何时停止建模   5A.4.5高科技/高接触的工具箱   5A.4.6敏捷的中心   5A.4.7你有多敏捷   5A.4.8引入敏捷   5A.5软件开发之外的敏捷   5A.5.1项目组合管理   5A.5.2客户关系   5A.5.3合同   5A.5.4将变更引入组织   5A.5.5程序员读哈佛商业周刊   5A.5.6建造房屋   5A.5.7机场建设   5A.5.8图书出版   5A.5.9会议组织和敏捷模型的限制   第6章Crystal方法集   6.1对Crystal家族塑形   6.1.1核心Crystal元素   6.2CrystalClear   6.2.1CrystalClear的简要描述   6.2.2CrystalClear的反思   6.3CrystalOrange   6.3.1CrystalOrange的简要描述   6.3.2CrystalOrange的反思   6.4CrystalOrangeWeb   6.4.1CrystalOrangeWeb的简要描述   6.4.2CrystalOrangeWeb的反思   6.5明天我该做什么   第6A章Crystal方法集:演进   6A.1Crystal基因代码   6A.1.1合作博弈的理念   6A.1.2方法集的重点   6A.1.3方法集设计原则   6A.1.4高度成功的项目的7个特性   6A.1.5技术与选择   6A.1.6样本方法集设计   6A.2CrystalClear   6A.3把CrystalClear扩展到Yellow   附录A敏捷软件开发宣言   附录Aa敏捷软件开发宣言和相互依赖声明   附录BNaur、Ehn、宫本武藏   附录BaNaur、Ehn、宫本武藏:演进   附录C后记   参考文献
评论 19
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值