20世纪60年代:软件做坊,软件规模小,以做坊式开发为主;
70年代:软件危机,硬件飞速发展,软件规模和复杂度激增,引起软件危机;
80年代:软件过程控制,引入成熟生产制造管理方法,以“过程为中心”分阶段来控制软件开发(瀑布模型),必定程度上缓解了软件危机;
90年代:重型过程,软件失败的经验促使过程被不断增长约束和限制,软件开发过程日益“重型化”,开发效率下降、响应速度发慢;
2001~今:敏捷正在流行,随着信息时代到来,需求发化更快,交付周期成为企业核心竞争力,轻量级的,更能适应发化的敏捷软件开发方法被广泛承认并迅速流行。框架
咱们一直在实践中探寻更好的软件开发方法,
身体力行的同时也帮助他人。由此咱们创建了以下价值观:
工具
个体和互动 高于 流程和工具
工做的软件 高于 详尽的文档
客户合做 高于 合同谈判
响应变化 高于 遵循计划
测试
也就是说,尽管右项有其价值,
咱们更重视左项的价值。
url
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler |
James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick |
Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas |
一、咱们最重要的目标,是经过持续不断地及早交付有价值的软件使客户满意。spa
二、欣然面对需求变化,即便在开发后期也同样。为了客户的竞争优点,敏捷过程掌握变化。设计
三、常常地交付能够工做的软件,相隔几星期或一两个月,倾向于采起较短的周期。blog
四、业务人员和开发人员必须相互合做,项目中的每一天都不例外。进程
五、激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。ci
六、不论团队内外,传递信息效果最好效率也最高的方式是面对面的交流。资源
七、可工做的软件是进度的首要度量标准。
八、敏捷过程倡导可持续开发。责任人、开发人员和用户要可以共同维持其步调稳定延续。
九、坚持不懈地追求技术卓越和良好设计,敏捷能力由此加强。
十、以简洁为本,它是极力减小没必要要工做量的艺术。
十一、最好的构架、需求和设计出自与自组织团队。
十二、团队按期地反思如何能提供成效,并依次调整自身的举止表现。
专一:因为咱们在一段时间内只专一于少数几件事情,因此咱们能够很好地合做并得到优质的产出。咱们可以更快地交付有价值的事项。
公开:在团队合做中,你们都会表达咱们作得如何,以及遇到的障碍。咱们发现将担心说出来是一件好事,由于只有这样才能让这些担心及时获得解决。
尊重:由于咱们在一块儿工做,分享和成功失败,这有助于培养并加深互相之间的尊重,并帮助彼此成为值得尊重的人。
承诺:因为对本身的命运有更大的掌握,咱们会有更坚强的信念得到成功。
勇气:由于咱们不得单打独斗,咱们可以感觉到支持,并且掌握更多的资源。这一切赋予咱们勇气去迎接更大的挑战。
Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。它把开发组织成被称为Sprint的工做周期。这些迭代每一个都不超过4周(最多见的是两周),而且无间歇地相继进行。Sprint是受时间箱限制的,不管工做完成与否它们都会在特定日期结束,而且从不延长。一般由Scrum团队来选定一个Sprint的时长,而且对于他们全部的Sprint都使用这一时长,直到这个团队能力提升,可使用较短周期。在每一个Sprint的初始,跨职能团队(大约7名成员)从排好优先级的列表中选择事项(客户需求)。团队对于在Sprint结尾他们相信本身能够交付哪些目标集合达成一致意见,这些交付应该是有形的而且能被真正“完成”的。在Sprint过程当中不能够增长新事项,Scrum在下一Sprint时才接受变化,当前这么短的一个Sprint周期里只注重于短小、清晰、相对固定的目标。团队天天都进行简短会面来检验工做进程,并调整后续步骤以确保完成剩余工做。在Sprint结尾,团队与利益关系人一块儿回顾这个Sprint,并演示所构建的产品。团队成员从中获取能够结合到下一Sprint中的反馈。Scrum强调在Sprint结尾产生真正“完成”了的可工做产品。在软件领域是指已经集成的、彻底测试过的、已经为最终用户生成文档的、潜在可交付的系统。说了这么多看一下Scrum框架图就明白了。
一、敏捷宣言:个体和互动 高于 流程和工具,工做的软件 高于 详尽的文档,客户合做 高于 合同谈判,响应变化 高于 遵循计划
二、12条敏捷原则
三、5个价值观:专一、公开、尊重、承诺、勇气
四、Scrum是一个框架,不是方法论