什么是敏捷开发

     对于了解什么是敏捷开发,首先要了解什么是"敏捷"。当你询问不同的人群你可能会得到不同的答案。

     假如你询问销售人群,比如说卖办公用品的人群。他会告诉你敏捷就是当你的用户在阐述需求的时候你要在便签上面记下来。其实他此时就是想把便签卖给你。假如你问咨询顾问,你会听到“敏捷”是一种开发软件的方法。你的团队可以学习,如果你购买了他们的服务。
     敏捷的实际定义来自于“敏捷”宣言。宣言指出“敏捷”不是一种方法论,也不是一种开发软件的方法,更不是一个框架或者一个过程。事实上,大多数宣称自己“敏捷”的东西实际上并不是敏捷的。

     首先,“敏捷”是一套价值观和原则。
     围绕着敏捷的大部分讨论都与以下事情有关,各种理论方法,甚至特定的“敏捷”开发软件,尽管这些东西可能会帮助一个团队建立“敏捷”,但这些方法和工具并非“敏捷”。
     举个例子,一个团队可能觉得每日站立例会会有帮助,但是之所以有这种开会形式只是因为团队遵循了“敏捷”的原则和价值观。
     当你明白了这一点时,就很容易看出“敏捷”实际上是一系列的理念。在软件开发工作中,团队可以利用这个理念更好的做决策。当提到敏捷的时候,大家想到了这样那样的方法,其实都让敏捷偏离了本质的含义。不过如果你真的明白了什么是敏捷的时候,会发现“敏捷”用起来其实非常灵活。
     首先敏捷并不会为你做任何的决定,相反,它帮助团队在开发软件的过程中,树立了一种决策原则。“敏捷”宣言只有68个字。
     敏捷宣言说:“我们一直在实践中探寻更好的软件开发方法,身体力行同时也帮助他人。由此我们建立了如下价值观:”,只需要让左侧的原则比右侧的原则更加受到认可我们就能更好的开发软件。

  • 个体和互动 高于 流程和工具
  • 有用的软件 高于 详尽的文档
  • 客户合作 高于 合同谈判
  • 响应变化 高于 遵循计划

     也就是说尽管右边的条目有其价值,我们更加重视左侧的价值。除了宣言以外还有12条敏捷宣言原则,当然了这些原则也是普适的,不是告诉你具体怎么做而是可以让你在特殊的情况下作出正确的决策。

  • 我们最重要的目标是,通过持续不断地及早交付有价值的软件让客户满意。
  • 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
  • 经常交付可以工作运行的软件,相隔几个星期或一两个月,倾向于采取较短的周期。
  • 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  • 激发个体的斗志,以他们为核心搭建项目,提供所需的环境和资源,辅以新人,从而达成目标
  • 不论团队内外,传递信息效果最好效率最高的方式是面对面交谈。
  • 可工作运行的软件是进度的首要度量标准
  • 敏捷过程倡导可持续开发,责任人,开发人员和用户要能够共同维持其步调稳定延续
  • 坚持不懈的追求技术卓越和良好设计,敏捷能力由此增强
  • 以简洁为本,它是极力减少不必要工作量的艺术
  • 最好的架构,需求和设计出自自由组织团队
  • 团队定期地反思如何高效提高成效,并以此调整自身的行为

     由于“敏捷” 是套价值观和原则的集合,所以它实际上是人们开发软件的时候做决策的最好基础。例如想象一下,一个新的项目正在讨论如何从客户那里获得需求,常规的做法是在开发软件前让客户经理写下所有的需求。而对于一个“敏捷”的团队,虽然这样也是可行的但是这并不符合我们的价值观,即客户合作 高于 合同谈判。这也违背了我们的原则,即开发人员每天都应该和客户经理一起工作?
     那么我们如何以符合我们价值观和原则的方式作出这个决定呢。或者想象另一种情况,一个程序猿正在为客户开发一个产品特性,但是这个程序猿发现他需要一个数据库,这个功能才能实现。直觉告诉他应该停止该功能的开发,并构建一个十分强大的数据库,这个数据库为该特性的开发提供条件,并且为以后的其他特性开发提供支持。如果此时这个程序猿信奉“敏捷”价值观并且视图遵循“敏捷”的原则。他会想:“构建新的数据库意味着”这个软件的价值不得不延迟交付给客户看到。如果我能找到一种方法来搞定此开发此特性的所需要的功能,那么这个方法会更好的符合我的原则。
     当你的团队遵循“敏捷”原则的时候,他们每一周会按照这种思维作出数百项决定,这才叫做敏捷。
     在做每一个决策的时候,都要让团队遵循敏捷的原则和价值。这样的决策过程很重要。你不能够指望让事情变得简单,让别人做决策,而你只是盲目的执行他们的决策。另一种团队可能会根据“敏捷”
的原则和价值做决策,并且以特定的方式结束他们的工作。只是简单的去模仿其他团队的行为和做法不会让你的团队更加的“敏捷”。
     二战后,美拉尼西亚的原始岛民们,想起了战争中看到的货机投放补给品的景象。于是仿造飞机场,希望天上有货机投放补给品到岛上。他们砍掉森林,并且用稻草铺垫地面,制作一个标准的飞机跑道。他们甚至还用竹子做了一个类似飞机控制塔的结构让人坐在里面并且戴着椰子做成的所谓的“耳机”。谈到“敏捷”的时候大家很容易产生这种模仿行为,你很容易就看到强大的“敏捷”团队是如何工作的,但是实际上他们的工作方法是遵循“敏捷”的原则和价值观的结果。真实的原因其实就是他们用什么方法工作其实并不重要,重要的是了解他们为什么使用。
     事实上随着时间的推移,一个优秀的“敏捷”团队,可能会改变或者完善他们的做法。比如一个团队开始在用“Scrum”模式,但是后来发现“看板”模式是一种更好的向客户交付价值的方法。一个团队可能开始会每天在站立中开会,后来决定让每一个人都坐着,单纯因为效果更好。另一个团队可能先使用计划扑克估算用户故事的开发量,后来决定不再看用户的故事,而是简单的将用户故事分割成为几个大致相同的开发量。并不是说了解哪些优秀的团队实践没有用,只是说你不能让团队去套用一个所谓的“敏捷”实践。遵循原则和价值观才能变成“敏捷”团队,所以你必须要找到那些支持原则和价值观的实践。您选择的实践方式决定了你是“敏捷”,还是不“敏捷”如果你选择了某种做法,是因为它好像遵循了“敏捷”原则,这可能是一个好的开始。但是如果原则是错误的,即使是一样的实践也并非会带来好的结果。

讲了这么大一篇文章,所以敏捷到底是什么?“敏捷”是一套价值观和原则
怎样成为“敏捷”团队?遵循“敏捷”的价值观和原则做决策。决策过程就是成为“敏捷”团队的秘密。“敏捷”的价值观和原则足够的普适,可以让不同的类型的公司和团队根据自己的情况开发软件。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Scrum基本知识 读前预习内容  Scrum概觅  Scrum是什么意思?  Scrum敏捷方法一分钟扫盲  Scrum敏捷方法丨的工作产品  Scrum敏捷方法丨的觇色  猪不鸡的故亊 Scrum过程 读前预习内容  创建和维护产品待开収项(Product Backlog)  迭代计划会 产品负责人准备什么?讲览什么?  迭代计划会 团队怎样估算?  扑克牉估算(Planning Poker)  办公环境  每日立会(Standup Meeting)  评审会(Review Meeting)  反思会(Retrospective Meeting) 用户故事 扩展阅诺  何为用户故亊  面向用户价值编写用户故亊  用户建模  优先级排序(待续)  用户故亊的分类  用户故亊的产生不组细结极  用户故亊不MVC 敏捷计划 扩展阅诺  敏捷计划流程  可用时间计算  迭代计划  迭代意向表  故亊讲览不估算 敏捷日常跟迚 扩展阅诺  故亊板,看板  燃尽图(Burndown Chart)  跟迕图不渐迕评审  跟迕表  拥抱发化?迓是迭代期内无发更? 敏捷生态系统 扩展阅诺  需求管理  客户价值导向-可工作软件-响应发化  计划不跟踪  跨职能团队-共同估算-每日立会-同行压力  需求优先级排序-迭代期内无发更-团队承诹 敏捷绩效考核 扩展阅诺  考核对象的发化  为团队设定目标,讥团队把控绅节 智慧敏捷 扩展阅诺  精益生产的吭示  写丌写文档?  敏捷实践的表象不内涵
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值