敏捷开发的核心价值观是,软件开发最重要的是给用户提供有价值的.可以工作的软件.如何保证提供有价值的软件,是通过反馈机制来完成的.这一点,我们体会很深.自从采用敏捷开发以后,我们比以前更有意识地希望得到各种反馈,包括来自外部和内部的.我们产品的大部分功能都直接来自客户的需求,并按优先级排序.我们有Beta 项目,在开发中期就给客户试用并得到反馈.并且我们在公司的内部网上也部署了最新的版本,并不断更新,得到了大量的用户反馈.可以工作的软件,含义就是软件是可交付给客户使用的.我们每4 周一个Sprin

转:http://www.open-open.com/lib/view/open1330413325514.html 最近把之前学习 Scrum 的资料整理为一篇文档,在接下来的团队和项目开发中,根据项目的情况引入 Scrum 的一些实践,提高团队成员之间的协作能力和项目的交付质量. 参考资料: <轻松Scrum之旅—敏捷开发故事>.<敏捷无敌> 硝烟中的Scrum 和 XP 火星人敏捷开发手册 Scrum-Checklists 维基百科:http://zh.wikipedia.o

近期研究前 Scrum 数据编译的文件,在接下来的团队和项目开发.项目根据该引入 Scrum 一些练习,提高团队成员和项目之间的交付质量的合作. 参考资料: <轻松Scrum之旅-敏捷开发故事>.<敏捷无敌> 硝烟中的Scrum 和 XP 火星人敏捷开发手冊 Scrum-Checklists 维基百科:http://zh.wikipedia.org/wiki/Scrum Scrum 工具 禅道 JIRA+GreenHopper Scrum 中的角色 Scrum Master--项目

产品经理-需求分析-用户故事-敏捷开发 详解 用户故事是从用户的角度来描述用户渴望得到的功能.一个好的用户故事包括三个要素:1. 角色:谁要使用这个功能.2. 活动:需要完成什么样的功能.3. 商业价值:为什么需要这个功能,这个功能带来什么样的价值.作为一个<角色>, 我想要<活动>, 以便于<商业价值>As a <Role>, I want to <Activity>, so that <Business Value>. 用户故事的

Scrum团队:由产品负责人.开发团队和Scrum Master组成. 是跨职能的自组织团队 自组织团队自己选择如何最好地完成工作,而不是由团队外的人指导 跨职能团队拥有完成工作所需要的全部技能,不需要依赖团队以外的人 这种团队模式的目的是最大限度地优化灵活度.创造力和生产效率 三大角色: Scrum管理-五事件 Scrum 管理: 所有事件是有时间盒限定的 每个事件都有时间限制的 一旦Sprint开始,它的周期也就固定下来了,不能缩短或者延长 Scrum 管理五事件包括: Sprint 计划会

一晃眼,有两年没有写博客了,回顾前两年,各种奔波,各种忙碌,也有不少的收获.从今天开始,我要把这些收获都分享在这里. 其实这两年,对我影响最大的是开发流程.总所周知,一个好的开发流程,对于项目的进行,更新和维护都起着至关重要的作用.Scrum适用于一些开发周期长,需求不明确,或者随时间渐进明确,频繁更新的项目.然而,现在国内的一些公司,甚至一些大公司,都对这块不太重视,或者做得不够透彻.从而程序猿们天天加班,苦不堪言. 我们先来看张我通过实际经验画的图流程图,红色圈圈出来的是我认为比较容易忽略的

敏捷发展到今天已经在软件行业得到了广泛认可,但大多数敏捷方法都是为了解决某一特定问题而总结出来的特定方法或实践,一直缺乏一个可以将整个开发过程串接起来的成体系的方法.用户故事驱动的敏捷开发(User Story Driving Agile Development – UDAD)就是这样一套方法和实践,希望能够在软件开发的各个过程都提供最有效的方法让希望采用敏捷的团队能够有一个整体的方法论作为指导. 如何你对敏捷还缺乏了解,可以阅读以下文档: 关于敏捷开发 UDAD中采用了以下几个已经被广泛认可的

XP+devOps开发模式与scrum敏捷开发对比,docker虚拟化 我们现在用的就是典型的XP+devOps模式,已经放弃scrum了 现在还很多公司弄docker虚拟化docker非常复杂,当然如果只是用别人的只用记一个docker命令就行了docker虚拟化消耗额外的系统资源较少 传统虚拟化会占用一点系统资源.通常日志是写在挂载进去的盘 或者直接通过其它协议扔给日志中心服务器传统虚拟化 启动 销毁 部署 时间都较长docker部署这些就很短 把一个应用(nginx php node) 等

[敏捷开发实践](2) 用于开发和维持复杂产品的敏捷开发框架Scrum 1,Scrum概述 上篇中提到敏捷开发有两种主流的方法,一个是XP,另一个是Scrum,本篇简要介绍Scrum方法.Scrum是一套开发和维护复杂产品的框架或说是管理方法. 我们提到敏捷开发是一个增量的.迭代的开发过程.而在Scrum框架中,整个开发过程我们分解为若干个短的迭代周期,在Scrum中每一个迭代周期,我们称为一个Sprint(原义为冲刺,Scrum中指一个迭代).根据Scrum的建议一般为4周(也可以根据实际产品

什么是SCRUM Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作:把一个开发流程的名字取名为Scrum,我想你一定能想象出你的开发团队在开发一个项目时,大家像打橄榄球一样迅速.富有战斗激情.人人你争我抢地完成它,你一定会感到非常兴奋的. 原始含义 Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球.争球双方各有8个队员参与,各方出3名前锋队员,并肩各站成一横排,面对面躬身互相顶肩,中间形成一条通道,其他前锋队员分别站在后面,后排队员用肩顶住前锋队员的臀部,组成3.2

Scrum是一种敏捷开发的方法 先定一个能达到的小目标 Scrum 团队 包括产品负责人.开发团队和Scrum Master Product Owner 产品负责人:管理代办事项和优先级的唯一负责人. 相关术语 Sprint 敏捷开发的周期,一般情况下需要2-6周时间,最终应该完成一个可演示给客户或者是可发布的产品 Epic 可以认为就是一个大的Stroy, 还没有拆解, 是对大Story的一个描述性标签 提问:Epic和User Story之间的区别是什么? 回答:准确的说,Epic是比用户故

敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力.它们的具体名称.理念.过程.术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作.面对面的沟通(认为比书面的文档更有效).频繁交付新的软件版本.紧凑而自我组织型的团队.能够很好地适应需求变化的代码编写和团队组织方法,也更注重做为软件开发中人的作用. 如果要实行一个很好的scrum,通常要满足两点:一.团队有三名或以上的研发工程师:二.团队内有一名

参考: http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html https://www.zhihu.com/question/35113144/answer/100425349   Scrum是什么? Scrum 是一个用于开发和维护复杂产品的框架 ,是一个增量的.迭代的开发过程.在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是2到4周(互联网产品研发可以

敏捷开发 Scrum 综述 这一星期学习了敏捷开发,然后阅读了相关的书籍,从网上查找了很多相关的资料,对敏捷开发scrum有了更加深刻了理解,对敏捷开发做了如下总结: 一.什么是敏捷开发? 敏捷开发提倡的“增量迭代.及时交付”的思想.这种模式能最大程度地不偏离客户需求的本质. 敏捷不是指某一种具体的方法论.过程或框架,而是一组价值观和原则.符合敏捷价值观和原则的开发方法包括:极限编程( XP), Scrum, 精益软件开发( Lean Software Development), 动态系统开发方

文章对Scrum敏捷开发流程进行系统的分析,希望借此文能够加深你对敏捷开发的认知,更好的展开产品工作. Scrum敏捷开发,是一种敏捷开发框架,是一个增量的.迭代的开发过程,具备可视.可集成和可运行使用的特征.与传统的瀑布式开发模式不同,它更倾向于对一个复杂系统的局部模块做短平快的版本迭代,快速响应预期的市场需求验证. 从图中可以看到,主要流程如下: 产品分析用户需求,按照商业价值依次排序估算,输出计划产品功能列表. 经过计划会议讨论,按照计划面板梳理功能列表,输出产品版本迭代任务. 进入开发迭

本文主要从Scrum的定义和目的.敏捷宣言.Scrum中的人员角色.Scrum开发流程.敏捷的12原则等几方面帮助大家理解Scrum敏捷开发的全过程. 一.Scrum的定义和目的 Scrum是一个用于开发和维护复杂产品的框架,是一个增量的.迭代的开发过程,目的是让开发人员像打橄榄球一样迅猛并充满激情,通过团队合作,提高工作效率.通过团队间的有效交互,为企业创造价值. 二.敏捷宣言 其实,在发表<敏捷宣言>之前,很多的敏捷实践都已经存在且使用了,比如:Scrum.XP.KanBan等.之所以发表

1.敏捷测试流程和传统测试流程 软件测试是贯穿整个软件开发生命周期.对软件产品(包括阶段性产品)进行验证和确认的活动过程,也是对软件产品质量持续的评估过程,其目的是尽快尽早地发现在软件产品(包括阶段性产品)中所存在的各种问题,尽最大可能地消除软件开发过程中所存在的产品质量风险. 传统的软件测试:制定周详的测试计划,测试计划又可能分为单元测试计划.集成测试计划.系统测试计划,甚至验收测试计划,没有评审的测试计划,将无法开展有效的测试互动.瀑布模型的研发流程都是线性方式进行.传统的软件开发模型->瀑

本系列的第一篇[用户故事驱动的敏捷开发 – 1. 规划篇]跟大家分享了如何使用用户故事来帮助团队创建需求的过程,在这一篇中,我们来看看如何使用这些用户故事和功能点形成产品backlog.产品backlog是敏捷开发中用来管理需求列表,排定优先级,形成迭代计划,组织开发/测试和交付过程的工具.可以说,产品backlog是一个敏捷团队管理开发过程的核心,所有的活动和交付物都围绕backlog来进行.一旦需求明确,我们就必须在开发过程中持续的跟踪backlog内容的实现和交付过程,确保我们的想法可以按

为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有两个,一个是进行知识的总结,另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解:所以我决定写一篇扫盲性的博文,同时试着也与园内的朋友一起分享交流一下,希望对初学者有帮助.  什么是敏捷开发? 敏捷开发(Agile Development)是一种以人为核心.迭代.循序渐进的开发方法. 怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,

瀑布式开发.迭代开发,区别[都属于,生命周期模型]         两者都是一种开发模式,就像设计模式一样,考虑的角度不一样,个人感觉谈不到取代一说.         传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到提交大概这样的流程,要求每一个开发阶段都要做到最好.特别是前期阶段,设计的越完美,提交后的成本损失就越少.我现在从事的外包项目就是这样的流程.         迭代式开发,不要求每一个阶段的任务做的都是最完美的,而是明明知道还有很多不足的地方,却偏偏不去完善