`
阅读更多

原则与实践

这是一个令人兴奋的敏捷时刻!我们的行业第一次找到了一种真正的、可持续的方法来解决软件开发团队一直在努力解决的问题。
  敏捷团队使用简单、直接的实践,这些实践已经被证明可以在实际项目中工作。但是等一下…如果敏捷是如此伟大,为什么每个人都不这么做呢?事实证明,在现实世界中,一个对一个团队非常有效的实践会给另一个团队带来严重的问题,不同之处在于团队的心态。所以准备好改变你对项目的看法吧!

 

思维方式必须与方法相结合

 在这个世界上没有“完美”的方法来构建伟大的软件!
在采用敏捷实践、方法和方法之后,一些团队已经取得了很大的成功,并看到了很大的改进,而其他团队则在努力。我们已经了解到,不同之处在于团队成员的思维方式。那么,如果您想要为自己的团队获得这些出色的敏捷结果,您该怎么做呢?你如何确保你的团队有正确的心态?这就是敏捷宣言的由来。当您和您的团队围绕其价值观和原则进行思考时,您开始对敏捷实践及其工作方式进行不同的思考,并且它们开始变得更加有效。  

Scrum的规则

 Scrum的规则很简单, 有效地使用它并不是那么简单。
  Scrum是最常见的敏捷方法论,有很好的理由:Scrum的规则简单易学。大多数团队不需要很多时间来收集组成Scrum规则的事件 (Scrum events)、角色 (Scrum Roles) 和工件 (Scrum Artifacts)。但是为了让Scrum真正有效,他们需要真正理解Scrum的价值观 (Values) 和敏捷宣言原则 (Agile Manifesto),这有助于他们进入一个有效的心态。因为尽管scrum看起来很简单,但scrum团队不断检查 (Inspection) 和适应 (Adoptation) 的方式却是一种全新的项目思考方式。  

一般公认的Scrum实践

 敏捷团队使用简单的计划工具来处理他们的项目。
Scrum团队一起计划他们的项目,以便团队中的每个人都致力于每个Sprint的目标。为了保持团队的集体承诺,整个团队作为一个团队,计划 (Planning)、估计(Estimation) 和跟踪 (Tracking) 需要简单易行。从用户故事 (User Stories) 和计划扑克 (Planning Poker) 到速度 (Velocity) 和燃尽图表 (Burndown Chart),Scrum团队总是知道他们已经做了什么,剩下要做什么。准备好学习让Scrum团队了解情况并控制他们构建的工具!  

拥抱变革

 軟件團隊在構建優秀代碼時會取得成功。
即使是拥有优秀开发人员的优秀软件团队也会遇到代码问题。当小代码变成一系列级联更改,或者日常代码提交导致数小时的修复或合并冲突时,曾经令人满意的工作会变得烦人、乏味和令人沮丧。   这就是XP的用武之地。XP是一种敏捷的方法论,它专注于构建沟通良好的有凝聚力的团队,并创建一个轻松、充满活力的环境。当团队构建简单而不复杂的代码时,他们可以接受变更而不是害怕变更。

 

消除浪费和管理流程

 敏捷团队知道他们总是可以改进他们的工作方式。
  他们使用精益的心态 (Lean Mindset) 来发现他们在哪些方面花时间在那些不能帮助他们实现价值的事情上。然后他们就可以清除那些减缓他们前进速度的浪费。   許多具有精益思維的團隊使用看板 (Kanban) 設置工作進度限制 (WIP) 並創建拉動系統 (Pulling System),以確保人們不會因為工作量不大而受到牽制。準備好學習如何看待您的軟件開發過程,因為整個系統可以幫助您構建更好的軟件!  

 Scrum的基本功

 

 
0
0
分享到:
评论
相关资源推荐
  • Scrum 敏捷软件开发模型(不断完善中) 下面是我对于 Scrum 的学习、理解及总结,参考了 Scrum 指南和一些书籍,并加入了自己的一些理解,希望对自己有用。 Scrum 是以经验过程控制理论为依据,采用迭代、增量的方法来提高产品开发的可预见性并控制风险。Scrum 的三大支柱支撑起每个经验过程控制的实现。 第一大支柱是高透明度 高透明度确保管理结果的人看得到那些影响结果的过程方面。这些过程方面不仅要透明,而且那些被观察到
  • 敏捷其实很简单(10)--自组织团队是怎样炼成的 前面几期用了很大一个篇幅来讲Scrum Master的工具箱,这是因为笔者本人曾经做过几年的SM,对这个职位可以说是感触颇深,而SM也是一个Scrum Team非常重要的一个角色,他可以保证团队始终走在正确的敏捷之路上,帮助团队成员正确理解敏捷及相关实践。所以在这了,内容多了一些。那么今天我们要来看一下Scrum中的第三个角色—团队。讲到团队,特别是敏捷团队,就要提到自组织团队这个概念了。我本人也在
  • Scrum实践指南:一个可运行的Scrum是怎样的       在目前的互联网公司,敏捷(Agile)的概念已经有相当的普及,人人都在谈,似乎不谈敏捷就不那么互联网了。几乎所有的互联网公司都不同程度的实施了敏捷。采用敏捷开发的方法也有很多,主要包括极限编程(XP)、Scrum、水晶方法(Crystal Methods)、自适应软件开发(ASD)、特性驱动开发(FDD)、动态系统开发(DSDM)、轻量级RUP、测试驱动开发(TDD)等等。而在众多的敏...
  • Scrum中的团队速率 转载地址:http://www.scrumcn.com/agile/scrum/4602.html 一轮迭代完成的故事点就是项目的速率。为这个项目做计划时,我们可以用已知的速率,我们也可以自己假想一个速率。速率是一个有用的管理工具,所以在每轮迭代结束和迭代中监控团队的速率是很重要的。 测量速率 多数故事很容易清点:团队在迭代中完成了这些故事,所以他们的点数全部计算在内。假如一
  • 完成 - 高绩效敏捷团队的必杀秘笈 敏捷方法已经在软件开发和交付中获得了主导性地位。但即便使用敏捷方法,你是否还在经历着项目延期、质量低下、超出预算等问题?软件开发迭代中总是有这样那样的问题?你是否怀疑敏捷到底能否给你带来期望的成功?近来,在一个有关敏捷中“完成”的在线讲座中,针对当前敏捷实践中存在的问题,Scrum的创始人之一——Jeff Sutherland——总结了敏捷实践中的这些问题的原因,并指出了解决的办法——重新定义“完成”(Definition of Done,DoD)。本文是根据Jeff讲座内容整理而得。
  • 敏捷软件开发scrum介绍 敏捷软件开发最近几年越来越火。跟传统软件开发相比有什么优点呢。今天我们就来聊一聊。 首先我们来看下什么叫做敏捷敏捷软件开发过程 软件开发过程是指设计软件开发过程中涉及的一系列活动,指导开发组一步一步的进行软件开发。 包括传统的瀑布过程、螺旋过程、原型过程、敏捷过程等。 敏捷则是一类过程的统称。之所以把他们都称之为敏捷,是因为它们有共同的特点。 敏捷过程讲究快速迭代快速试错,将一个大...
  • 成功的Scrum组织以特性团队为主 Scrum迭代开发、增量交付的开发方法建筑在Scrum团队之上,Scrum团队中的开发团队应当是特性团队,而不是组件团队。离开特性团队Scrum就难以实现迭代开发、增量交付。深入了解组件团队的固有问题,准确理解什么是特性团队,对于指导组织转型至关重要。什么是特性团队?按照Ken Rubin的定义,特性团队是一个跨职能、跨组件的团队,能够从产品待办列表中抽取并完成最终客户想要的特性。Ken Rub...
  • 组织敏捷转型——项目经理和职能经理如何转身 推进组织转型时,经理转型是重点,更是难点。按照责任区分,经理可分为项目经理和职能经理。项目经理转型组织敏捷转型,铺面而来的就是项目经理转型的问题。项目经理何去何从?在传统组织中,项目管理职责由项目经理一人承担。项目经理是项目团队成员的上级,主要采用命令控制式的管理风格,管理单独的项目成员,而不是让项目团队成员们自我管理。在Scrum组织中,传统的项目管理职责由产品负责人、ScrumMaster、开发
  • 敏捷开发实战(二)--你真的了解Scrum吗? 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum敏捷开发方法。。。
  • Scrum敏捷实践之旅系列(一)用户故事概念       敏捷开发对需求规划的要求是很高的,首先需求是打散的,一个大的项目需求会拆分成很多小的功能完整的需求,以便排定优先级去逐个实现,敏捷开发提升了开发效率,但是对需求规划的要求更高了,就是对产品的需求规划能力提出了更高的要求,必须有清晰的思路,很强的需求规划能力才行,这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计。        敏捷开发是通过“用户故事”这个东东来实
  • SCRUM敏捷团队的故事(SCRUM: The Story of an Agile Team)——(1) Scrum是最经常使用的一种敏捷技术。它不是编码相关的;相反,它更侧重于组织和项目管理。如果你有空,让我告诉你关于我所工作的团队,和我们团队如何采用Scrum技术。 一个小故事 Scrum的根源实际上早于敏捷时代。   Scrum的根源实际上早于敏捷时代。第一次提到这种技术可以追溯到1986年,由 Hirotaka Takeuchi 和 Ikujiro Nonaka为商业产品开发所提出的
  • Scrum敏捷估算 无论是团队研发一款产品或者开发某一个项目,我们都需要回答“我们大概什么时间能够完成?”, 或者到某一个时间点,我们能够做到什么程度, 因此和传统的开发模式一样,我们在工作开始之前需要对我们需要做的事情进行工作量的估算。 敏捷估算的特点:         团队集体估算         在Scrum的开发过程中,团队共担责任,集体承诺每个Sprint的工作,因此对于工作量的估
  • 测试人员如何在scrum团队中高效协作? 在传统的瀑布式开发 中,测试人员经常因进入测试阶段的条件不满足而需要较长的等待。而在Scrum敏捷开发中,测试人员需要尽可能早的开展工作,“等待”在Scrum开发的测试中已属一种错误概念。  测试人员应具备三方面的能力:编码,测试和分析。不同的
  • Scrum敏捷开发之角色 Scrum中有三种角色:产品负责人Product Owner,Scrum Master和Scrum团队,他们的职责分别是: 产品负责人(Product Owner) 确定产品的功能和完成时间;对产品的收益负责;根据市场需求确定产品功能的优先级;在每个Sprint开始之前,可以修改功能需求和优先级;有权决定接受或否决各Sprint的工作成果。        Produ
  • Scrum 之 四大支柱和价值观 Scrum的四大支柱 1.迭代开发         在Scrum的开发模式下,我们将开发周期分成多个1-4周的迭代,每个迭代都交付一些增量的可工作的功能。迭代的长度是固定的,如果我们选择了1周的迭代,那么保持它的长度不要发生变化,在整个产品开发周期内每个迭代都是1周的长度。这里需要强调的是在每个迭代必须产出可工作的增量功能,而不是第一个迭代做需求、第二个迭代做设计、第三
  • Scrum敏捷体系及认证课程 敏捷是一套价值观与原则,Scrum敏捷的框架、是基于团队的组织架构,帮助企业和团队落地。ACP的认证可以帮助个人增长敏捷的知识与技能,但要真正落地,则需Scrum帮助实施。Scrum也是一套经验性的流程,最吻合Agile的价值观和理念。这就是为什么我们学完ACP还得学Scrum的重要原因。 国际Scrum联盟Scrum认证体系 CSM认证: CSM即Certified Scrum Ma
  • 什么是DoD 文章出处:  http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod 对于运作良好的Scrum团队来说,DOD是关键之一。 你可以参照以下几点来对照你的团队的DOD。  确保你团队的DOD符合这些标准,将确保你的团队不仅在功能方面,同时在质量方面,都能够交付真正完成的feature。 DOD是对软件有价值
  • 敏捷开发的Scrum晨会实践 hursing所在的公司推行敏捷开发有两年多了,其中最让人直接感受到的就是scrum晨会。从生搬硬套到过程创新,令大家由抵触变成积极响应,这个过程真的很花费心思。 09年12月,hursing开始在自己的团队推行晨会。当时团队是刚成立的,很小,包括hursing自己在内的2个老人+2个新人,基本上hursing得指导所有的事情。事实上,团队小到不开晨会hursing也知道他们在做什么,所
  • 敏捷其实很简单(5)一个称职的PO应该做和不应该做的 今天我们先讲一下在scrum运营中非常重要的一个角色---PO。首先我们了解一下PO的概念:(Product Owner)是Scrum中十分重要的一个角色,是连接业务用户及Scrum团队的中间纽带。
  • 敏捷实践开Daili Scrum站会的思考 Daily Scrum的问题当你问一个初创敏捷开发团队“你们会开站立会吗”,经常会碰到这样的回答“我们的开发团队对开站会比较抵触,团队本来就在一起坐着,认为站立会太形式化,没有什么价值”。还碰到过实行过两年以上的敏捷研发团队,也经常说到“开高质量的站会很难”。敏捷团队到底怎么开高品质站立会?先看看敏捷教练口中的站立会(Daily Scrum)。敏捷教练说站立会“在15分钟内,团队站着开。““Scr...
Global site tag (gtag.js) - Google Analytics