简介
现状
敏捷开发引入中国好多年了，大学时也听老师讲过，把它夸的很好。真实工作中也听过一些技术沙龙、同行业分享，但总体感觉下来就是：大家都知道它好，处理需求变化好，开发快，节省成本，但好像都说不出它是怎样开发？如何敏捷？如何迭代？如何应用并协作？
什么是敏捷
是软件工程方法论，研发的管理就是人事物的管理，怎么保证团队高效？
不仅仅是开发速度上的快，更是团队开发效率高。
2011年2月11~13，在美国犹他州瓦萨奇山区雪鸟滑雪胜地的一个别墅里， 17个软件工程师party、交流之后，共同发起了敏捷软件开发宣言。依次为起点，掀起了全球性的敏捷开发。
宣言主要包含：4个价值观和12条原则。
敏捷解决什么问题
传统软件工程双子星著作：《人月神话》《人件》
传统的软件开发弊端有：
- 团队苦于交付不断延期和预算超支
- 团队受困于bug和低效开发
- 团队受困于维护复杂而又混乱的代码
- 常常交付无法为用户带来价值的软件
- 开发人员陷于不断加班中，疲于推到重来
** 瀑布流开发问题分析 **
- 各个阶段隔离性强
- 后续节点强依赖前节点
- 没有对需求变化做出相应
- 详尽的需求文档代替了必要的沟通
- 和客户处于对立的关系
- 团队成员缺乏沟通和合作
- 没有必要的措施进行过程改进
CMMI影响力再减弱。
践行敏捷的实际效果
简单来说就是多、快、好、省！
- 沟通多
- 协作多
- 迭代多
- 响应快
- 开发快
- 交付快
- 系统好用
- 公司好发展
- 员工成长好
- 省心
- 省力
- 省时
如何实施敏捷
敏捷就是以正确的价值观，原则和实践方法来解决这些问题，达到多快好省。
携程2012年引入敏捷，打破部门界限、按项目划分成10多人的小团队，采用Scrum进行组织。
携程取得效果：
团队生产力更高；开发系统质量更高；更快的交付；更快的上线；用户体验更好；团队幸福感高；高收益；
首先充分理解价值观，在应用中实践这些原则。
敏捷的价值观
** 个体和互动高于流程和工具 **
此原则强调了沟通的重要性，软件开发是以人为单位的团队协作活动，人的协作沟通是很主要的。具体实施就是：从团队合作的角度协调工作，让每个个体都充分发挥积极性。要让每个个体都对当前团队目标，具体任务有清晰认识，都要想问题找办法，每个人都要对团队负责。
敏捷开发的过程中就需要改进互动，寻找提高能力的方法。注重个体！注重沟通互动！注重共识的形成！
** 可工作的软件高于详尽的文档 **
简单来说就是目标驱动！所有工作的最终目标是：交付客户满意的可工作的软件。
以构建软件为目标，不要为写文档而写文档。记录的文档是必要的，而不要写沟通的文档。
要以小步增量开发，架构也要不断迭代实践出来。
** 客户合作 高于 合同谈判 **
让客户，设计，开发良好的工作在一起。
传统的外包公司最为典型。严格以合同为标准，排斥需求变动。
** 响应变化高于遵循计划 **
唯一不变的是需求变化。
敏捷的原则
除4条价值观外，12条原则也很有必要性。原则的目标就是：交付对客户有价值的软件。
** 我们最重要的目标是通过尽早和不断交付有价值的软件使客户满意。 **
** 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化以保持客户的竞争优势。 **
拥抱变化。
** 经常地交付可工作的软件，从几星期到几个月，时间尺度越短越好。 **
** 业务人员和开发人员在整个项目过程中必须每天在一起工作。 **
注重面对面沟通。业务要及时和开发沟通，开发要确保及时准确了解业务。
** 围绕有斗志的人开发项目。给开发者提供适宜的环境，支持他们的需要，并相信他们能够完成任务。 **
通过放手，调动员工能动性。
** 对一个开发团队以及在一个开发团队中，最有效率也最有效果的信息传达方式是面对面的交谈。 **
** 可工作的软件是进度的首要衡量标准。 **
** 敏捷过程提倡可持续开发。出资人、开发人员和用户应该能够延续性地维持同一步调。 **
通过目标驱动，提高效率。
** 对卓越技术与良好设计的不断追求提高敏捷性。 **
提高健壮性，不要过度设计，通过迭代达到完美设计。
** 简单--最大化未完成（不必要）工作量的艺术--至关重要。 **
** 最好的架构、需求和设计源自于自我组织的团队。 **
鼓励每个人都参与到架构设计中。
** 每隔一定时间，团队要反思如何变得更有效率，然后相应地调整和调节自己的行为。 **
网友评论