敏捷开发系列_项目经理在敏捷开发中的作用敏捷开发 - CSDN
  • 乍一听,“敏捷开发”这个词很新鲜,其实不然。早在2001年2月,就作为一种相对新颖的产品开发模式,提出了“敏捷开发”这一概念。到底什么是“敏捷开发”呢? 诞生  也就是2001年的2月(没有考据),有17名之多的...
         乍一听,“敏捷开发”这个词很新鲜,其实不然。早在2001年2月,就作为一种相对新颖的产品开发模式,提出了“敏捷开发”这一概念。到底什么是“敏捷开发”呢?

    诞生

         也就是2001年的2月(没有考据),有17名之多的软件工程师在美国犹他州的Snowbird举行会议,讨论轻量级软件开发方法,并发布了《敏捷软件开发宣言》。这标志着敏捷开发的诞生。这一模式随后被硅谷创业公司大量应用,并于近几年被引入国内,让中国的工程师们有机会接触这一新奇的开发模式。

    敏捷宣言

    • 个体和交互重于过程和工具
         敏捷方法认为,人是软件开发中最重要的因素,开发团队要能做到团结协作,人与人面对面的交流、沟通,是最快速、最有效的途径。
    • 可以工作的软件重于面面俱到的文档
         文档的意义在于为程序服务,过多的文档需要开发人员花费大量的时间去维护,而且还要确保文档与代码的实时性,否则就失去了文档的意义。而问题也就在于,开发人员没有把时间、精力放到最重要的任务上,能力、资源没有最大化的发挥效能。敏捷方法认为,文档应当短小精悍、易于维护,而且主题突出。
    • 客户协作重于合同谈判
         做过软件开发的人都知道,客户对产品的需求是不断变化的,试图一开始就规定项目的细节和进度,显然是不现实的,只有开发团队和客户彼此精诚合作,常与沟通,频繁的客户反馈,才能促使项目的成功。
    • 随时响应变化重于循规蹈矩
         客户的需求在产品的开发阶段是不断变化的,即使谈判时确定的需求,也可能会根据某些因素而发生巨大的改变。因此,敏捷方法认为,在制定计划时应尽可能的简洁、灵活,以适应技术和需求方面的变动。当然,所有的未知的因素是不可能考虑周全的,这就要求我们在制定计划时,留出一定的缓冲期,来应对这些未知情况。

    核心思想

         说了这么多,到底什么是“敏捷开发”呢?其实,简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目经常被拆分为多个子项目或多个步骤来完成,而一个步骤又称为一次迭代,在每一次迭代完成之后,都会产生一个可交付的产品。这样做有效的分解了整个项目的复杂度,便于实现产品交付目标,同时在项目的早起,就能拿出初具雏形的产品。
         敏捷开发方法的核心思想概括起来,就是“以人为本”和“适应变化”。
    • 以人为本
         敏捷方法认为,人是软件开发中最重要的因素。对于人来说,软件开发应该是一种愉快而又轻松的事情,它们注重调动自我的能动性,以积极、愉悦、乐观的心态完成开发,并培养人的自豪感。敏捷开发的理念是充分的信任开发团队能够很好的完成任务,这是管理的中心主题。
    • 适应变化
         传统的软件开发强调的是,足够清晰的需求,制定详细的文档,按照预定的计划逐一进行开发、测试。这样的方式在制定好计划之后拒绝变化,无法应对客户对需求的实时更改,后续的维护必将会付出巨大的代价。
         而敏捷方法则是以最简的方式来迎接变化,客户在整个开发过程中都是参与者,开发团队能够在最短的时间内得到客户的反馈,不断适应需求的变更,从而使得最终的产品能够充分的符合客户的要求。

    管理工具

         俗话说,工欲善其事,必先利其器。没有一个好的工具,事倍功半是必然的。目前,已经有一些项目管理工具用于敏捷开发,可以用他们来帮助规划、跟踪,分析和整合工作。
         这些工具在敏捷开发中扮演着重要的角色,也是知识管理的一种方法。通常包括:版本控制整合,进度跟踪,工作分配,集成发布,迭代规划,论坛和软件缺陷的报告和跟踪。
         我们项目中用到的两款项目管理工具,其一是国内的公司出品的Web版的开源软件——禅道(ZenTao),它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体,是一款专业的研发项目管理软件,完整地覆盖了项目管理的核心流程。还有一款是国外的Atlassian公司出品的项目与事务跟踪工具——JIRA,被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

    方法

    • XP
    • SCRUM
    • Crystal Method
    • FDD
    • ASD
    • DSDM
    • RUP
    • LD

    结束语

         由于我也是第一次接触敏捷开发,我将与大家一同学习敏捷的真谛,在项目中运用敏捷的思想,真正做到开发敏捷、思维敏捷。在这个关于敏捷开发的系列之旅中,第一站主要是简单的介绍了一下敏捷开发,让大家对他有一个整体的了解。
         后续的文章,我会结合各个不同的敏捷方法,同时在项目中吸收的经验、教训,都会与大家一起分享,一同来探讨有关敏捷的真谛。

    展开全文
  • android 敏捷开发系列(二)——《敏捷开发架构图》 首先为大家解释里面的几个概念 Frame 整个项目的框架、组织者。里面并没有实际的代码,只是通过配置文件决定了项目需要哪几个模块 Model 模块,项目的组成部分,...

    原创作品,转载请注明出处http://blog.csdn.net/baodinglaolang/article/details/10042857

    android 敏捷开发系列(二)——《敏捷开发架构图》


    书接上回,首先奉上敏捷开发的架构图



    首先为大家解释里面的几个概念


    Frame 整个项目的框架、组织者。里面并没有实际的代码,只是通过配置文件决定了项目需要哪几个模块

    Model 模块,项目的组成部分,通常表示单一或部分功能集合

    Component 组件,包含Model的UI以及需求逻辑,在android敏捷开发中包含(Activity、Service、BroadCast Receiver、Provider

    Lib lib库,为Component提供了具体的实现,封装了其需要的各种方法


    从图中我们看到,

    首先Frame包通过配置文件决定项目的模块,这样来满足我们上话提到的各种需求,

    此处的Model是我强加来的,其实Frame只需要依赖Component即可以构成项目,因为从依赖链看往往Component会依赖一个特定Lib,但是从逻辑看Component + Lib才完整。所以建议大家把Component + Lib想象成一个Model。

    然后每一个模块又通常被分为独立的组件和Lib,这样的好处很明显,通常变化的只有组件,而Lib一但完成只需要维护其稳定即可,当项目界面需要大变化的或需要我们向三方提供此模块功能的时候可以直接提供此Lib,也就是我们说的SDK

    最后是我们项目积累封装好的各中jar包,例如图上提到的HTTP、FILE等工具类,可以直接被依赖进来,提高了复用率,我们还可以随时丰富其接口,供大家使用。


    敏捷开发的的架构基本是这样,他充分体现了灵活、高效,怎么样,赶快阅读博主的第三篇《android 敏捷开发 环境搭建》,一起开始我们的敏捷开发之旅!

    传送门

    android 敏捷开发系列(一)——《啥是敏捷开发

    android 敏捷开发系列(三)——《环境部署》
    展开全文
  • 本博将通过 讲解敏捷开发概念->敏捷开发架构思想->开发环境搭建->项目源码敏捷开发构建、拆分 等逐步带您走进android敏捷开发的世界。 学敏捷开发,开启 架构师之路..(夸张了呵呵,其实没有,这是基础) 注:本系列...

    原创作品,转载请注明出处http://blog.csdn.net/baodinglaolang/article/details/9530695


    说起敏捷开发,大家或多或少会有些印象。而在android上的敏捷开发可能还并未普及。

    博主将与大家共同讨论一起交流android上的敏捷开发、框架搭建等知识。

    本博将通过   讲解敏捷开发概念->敏捷开发架构思想->开发环境搭建->项目源码敏捷开发构建、拆分 等逐步带您走进android敏捷开发的世界。

    学敏捷开发,开启 架构师之路..(夸张了呵呵,其实没有,这是基础)

    注:本系列基于 maven、nexus、hudson、git等工具实现。

    首先让我们了解一下什么是敏捷开发。

    什么是敏捷开发

    简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    --摘自百度百科

    博主认为其核心是:原子+稳定+复用=敏捷开发。拿实际项目来说,稍大一点的项目可能涉及到多种功能多种发行版本

    以下可能是您的现状:

    1.所有源码在一个工程,臃肿庞大,命名各异

    2.每次都为分布在各地的工具方法而整篇的查找项目源码

    2.为客户BT的需求一遍又一遍的拆分、整合那些固化功能

    3.为新的产品开发copy旧的代码无限复制粘贴

    4.在旧版本fix bug后呆呆的把变更一遍又一遍的在高版本上修复(也许还忘记修复)

    5.浪费大量的时间在每次编译整个项目上(编译整体项目可能需要数分钟,而编译单模块也许只需要数十秒)

    6.com.xxx.xxx.A.java,这TM到底是那个功能的类(挨个问同事吧)

    7.不知到如何提升自己

    如果您有以上困扰,很好,因为春天很快就要到了,因为我们有敏捷开发。


    敏捷开发带给我们什么

    1.清晰框架结构

    2.高度复用接口

    3.灵活的模块组合

    4.高速稳定的产品迭代

    5.UI与逻辑的解藕

    6.低廉的维护成本


    举例来说:

    某网聊软件(可想像成微信)中功能包括

    1.文字、语音通讯

    2.联系人管理

    3.朋友圈

    4.摇一摇

    5. ....

    多个功能在项目中很容易分成多个模块来交给工程师实现,普通的工作方法我们不再赘述,试想一下,如果这每个功能看作一个模块,每个模块可独立运行并且可以被任意项目集成,那么,也许公司的音乐播放器项目加入朋友圈说不定也不错呢,而这一切只需要配置一些xml而已。


    敏捷开发设计到的很多,为了让大家从概念到操作了解清晰,请关注博主第二篇《项目敏捷开发架构图》


    传送门

    android 敏捷开发系列(二)——《敏捷开发架构图》

    android 敏捷开发系列(三)——《环境部署》

    展开全文
  • 上篇文章,我们探讨了什么是敏捷开发,以及敏捷开发的方法学。在这篇文章中,我们将继续讨论敏捷开发中的问题——XP极限编程。 在讨论之前,先让我们来了解一下XP极限编程产生的背景,软件业所具有的共同的问题。 ...
    上篇文章,我们探讨了什么是敏捷开发,以及敏捷开发的方法学。在这篇文章中,我们将继续讨论敏捷开发中的问题——XP极限编程。

    在讨论之前,先让我们来了解一下XP极限编程产生的背景,软件业所具有的共同的问题。

    背景

    • 软件越来越复杂
    • 需求越来越多变
    • 过程越来越规范
    了解了背景之后,那么就会想问,到底什么是极限编程呢?下面我们就做一个简单的介绍。

    XP概述


    极限编程(eXtreme Programming),是一种全新的、轻量级的、灵巧的软件开发方法,是一种软件工程方法学。它强调程序设计团队与业务专家之间的紧密协作、面对面的沟通(比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好的适应需求变化的代码编写和团队组织方法,更注重软件开发中人的作用。

    核心价值观

    • 沟通(Communication)
         问题往往是由于开发人员与设计人员、设计人员与客户之间的沟通不畅造成的。XP认为项目成员之间的沟通是项目成功的关键,并把沟通看作项目中间协调与合作的主要推动因素。因此,项目相关人员之间进行充分、多渠道(最好面对面)的沟通是很有必要的。

    • 简单(Simplicity)
         XP假定未来不能可靠地预测,在现在考虑它从经济上是不明智的,所以不应该过多考虑未来的问题而是应该集中力量解决燃眉之急。 在系统可运转的前提下,做最简洁的工作,坚定的专注于最小化解决方案;在开发中不断的优化设计,时刻保持代码简洁、无冗余。需求尽量的简单,设计尽量的简单,代码尽量的简单,文档尽量的简单。

    • 反馈(Feedback)
         尽快获得用户的反馈,并且越详细越好,使得开发人员能够保证自己的成果符合用户的需要。强调各种形式的反馈:小交付、短迭代、测试先行等。XP认为系统本身及其代码是报告系统开发进度和状态的可靠依据。系统开发状态的反馈可以作为一种确定系统开发进度和决定系统下一步开发方向的手段。

    • 勇气(Courage)
         这是最重要的核心价值。因为XP强调要“拥抱变化”,因此对于用户的反馈,提倡积极面对现实和修改问题的勇气,如放弃已有代码,改进系统设计等;勇敢的重构;所有人拥有代码;敢于极限(把好的方法做到极致)。XP认为,软件开发中,人是最重要的一个方面。在一个软件产品的开发中,人的参与贯穿其整个生命周期,是人的勇气来排除困境,让团队把局部的最优抛之脑后,达到更重大的目标。

    12个实践原则

    • 规划策略(Planning Game)
         以业务优先级和技术估计为基础,决定下一版本发布的范围。


    • 结对编程(Pair Programming)
         结对编程是一种编程模式。两个程序员并排坐在一台电脑前,面对同一个显示器,使用同一个键盘,同一个鼠标一起工作。他们一起分析,一起设计,一起写测试用例,一起编码,一起单元测试,一起整合测试(Integration Test),一起写文档等。基本上所有的开发环节都一齐肩并肩地,平等地,互补地进行开发工作。

         结对编程是让两个人共同设计和开发代码的实践。结对者是全职合作者,轮流执行键入和监视;这提供了持续的设计和代码评审。不是两个人做一个人的事情。 

    • 测试(Testing)
         测试驱动开发,是指在编码开始之前,首先将测试写好,而后再进行编码,直至所有的测试都得以通过。即所谓的先测试,再编码;代码未动,测试先行。 通常包括,Unit Test、Acceptance Test( Functional Test )、Nightly Test、Stress Test等。

    • 重构(Refactoring)
         重构是XP的一个重要组成部分。所谓重构是指在不改变代码外在行为的前提下对代码做出的修改,以改进代码的内部结构。重构是一种有纪律的、经过训练的、有条不紊的代码整理方法,可以将整理过程中不小心引入错误的可能性降到最低。改进软件的设计,Refactoring帮助重新组织代码,重新清晰地体现结构和进一步改进设计。

    • 简单设计(Simple Design)
         系统应设计得尽可能简单。

    • 代码集体所有权(Collective Code Ownership)
         代码集体所有权强调的是整个团队,而非个人,即“我们”的代码,而不是“我”的代码。 团队中的任何人都可以改动任何一段代码,但改动后的代码必须通过所有相关的测试。

    • 持续集成(Continuous Integration)
         持续集成的思想是任何时候只有一项任务完成,就集成新代码,构造系统并测试。持续集成是每日构建\每晚构建的一种极限形式,是XP的重要基础。

         测试先行是持续集成的一个重要前提。持续集成指不断地把完成的功能模块整合在一起。目的在于不断获得客户反馈以及尽早发现BUG。随时整合,越频繁越好;集成及测试过程的自动化程度越高越好。每次只有一个PAIR在整合,而且必须运行功能测试。

         需注意,持续集成需要良好的软件配置变更管理工具的有效支持。 
     


    • 现场客户(On-site Customer)
         客户是Team成员,在开发现场和开发人员一起工作。传统的客户任务一般是讲解需求,运行验收测试,接收发布的系统。

    • 小型发布(Small Release)
         发布过程应该尽可能地自动化、规范化。不断地发布可用的系统可以告诉客户你在做正确的事情。客户使用发布的系统,可以保证频繁地反馈和交流。保证客户有足够的依据调控开发过程(增加、删除或改变User Story)。降低开发风险。随着开发的推进,发布越来越频繁。所有的发布都要经过功能测试。 

    • 每周40小时工作制(40-Hour Work)
        “不加班,不熬夜”。XP要求项目团队人员每周工作时间不能超过40小时,加班不得连续超过两周,否则反而会影响生产率。

    • 编码规范(Code Standards)
         XP 强调通过指定严格的代码规范来进行沟通,尽可能减少不必要的文档。类型包括:格式、代码结构、命名约定、错误处理、注释等。 

    • 系统隐喻(System Metaphor)
         XP通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。XP不需要事先进行详细的架构设计。

    开发过程


    用户代表提出用户故事,项目组据此进行讨论、提出隐喻,在此活动中有可能要进行系统结构的Spike。在隐喻和用户故事的基础上,根据用户设定的优先级制订交付计划,然后开始多个迭代过程,在迭代期内产生的新用户故事不在本迭代内解决,以保证开发不受干扰。经验收测试通过后交付使用。



    适用范围


    XP适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题,以最大的灵活性和最小的 代价来满足用户未来的需求,XP在平衡短期和长期利益之间做了巧妙的选择。

    结束语


    XP用自己的实践,在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。XP的思想启发我们如何学习和对待快速变化、多样的开发技术。

    展开全文
  • 敏捷开发系列中,把一种开发流程命名为Scrum,其实就意味着,这种敏捷开发的流程,就像是大家在一起打橄榄球,敏捷的动作、富有战斗的激情、人人你争我抢的拼搏精神。这些无一不是现在开发中迫切需要的东西。

    由来


    为什么是Scrum?Scrum原本的意思是橄榄球运动的一个专业术语,指:“在橄榄球比赛中,双方前锋站在一起紧密相连,当球在他们之间投掷时他们奋力争球”。在敏捷开发系列中,把一种开发流程命名为Scrum,其实就意味着,这种敏捷开发的流程,就像是大家在一起打橄榄球,敏捷的动作、富有战斗的激情、人人你争我抢的拼搏精神。这些无一不是现在开发中迫切需要的东西。




    概念


    什么是Scrum?Scrum是一种灵活的软件管理过程,它可以帮助驾驭迭代、递增的软件开发过程,主要用于产品开发或工作管理。Scrum于1995年提出,并在2001年同其他方法论一起组成“敏捷联盟(Agile Alliance)” 。Scrum提供了一种经验方法,它使得团队成员能够独立地,集中地在创造性的环境下工作。


    特点

    • 敏捷的流程,可用于管控研发工作
    • 现有设计流程的总结
    • 以团队为基础,是一种在需求迅速变化情况下迭代的、增量的开发系统和产品的方法
    • 控制由利益和需求冲突导致混乱的流程
    • 改善交流、协调合作的最优方式
    • 检测产品开发和生产过程中障碍并将其去除的方式
    • 最大化生产率的一种方法
    • 适用于单一的项目到整个组织。Scrum可以控制并组织多件具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。 
    • 让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲,并让他们发挥到最佳水平。 


    Sprint(迭代)

    • Scrum的项目过程由一系列的Sprint组成
    • Sprint的长度一般控制在2~4周
    • 通过固定的周期保持良好的节奏
    • 产品的设计、开发、测试都在Sprint期间完成
    • Sprint结束时交付可以工作的软件
    • 在Sprint过程中不允许发生变更


    开发流程


    Scrum敏捷开发,是对流程控制比较严格的。每个环节都有一套完整的过程和严格的时间控制,我们项目组的主要开发过程如下图所示:



    角色


    ScrumMaster

    • 保证Scrum团队可以遵守Scrum的价值,实践和规范
    • 帮助Scrum团队和组织采用Scrum模式进行项目流程组织
    • 指导并带领团队变得更加高效,实现更高质量
    • 保护团队不要受到外界因素的干扰
    • 保证各个不同角色之间的良好协作,消除障碍
    • 帮助PO更好的利用团队的能力
    • 不要管理团队

    产品负责人PO(Product Owner)

    • PO是一个人并只能由一个人来担任
    • 负责管理产品待办事项表(Product Backlog)并保证其对于客户和团队保持透明度
    • 对产品待办事项表进行优先级排序
    • 与团队一起来进行工作量估算
    • 对于项目的成功负责并保证投资回报率(ROI)

    团队Team

    • 最佳团队大小:5~9人
    • 多功能团队:程序员,测试人员,设计师,数据库管理员和架构师
    • 保证团队成员全职参与开发
    • 自我管理,没有头衔之分,不组建子团队
    • 成员更替只能在迭代之间进行,更佳方式是在发布之间进行
    需要注意的是,第三点提到的全职参加是指完成了分配到的任务额即为全职参加。并不是指全程参加。


    迭代会议


    每日站立会议

    • 站立进行
    • 在固定的时间,固定的地点
    • 问题:你昨天完成了哪些工作?今天要完成哪些工作?遇到了什么困难?
    • 仅仅作为信息沟通用途,不解决任何问题
    • 不向任何人汇报
    • 15分钟

    迭代计划会议

    • 进行迭代规划
    • PO向团队介绍Product Backlog
    • 团队在PO的协助下充分了解Product Backlog
    • 确定迭代目标和迭代合约
    • 对Product Backlog进行细分并创建Story(一个具体的任务)

    迭代评审会议

    • 团队展示完成的功能并收集反馈
    • 对未完成的功能进行描述并说明原因
    • PO接受/不接受当前迭代
    • 邀请所有人,包括客户参与
    • 4小时

    迭代回顾会议

    • 哪些做的好
    • 哪些做的不好
    • 哪些可以改进
    • 进团队成员参与
    • 4小时

    项目管理工具

    • 禅道
    • JIRA
    • 其他。。。

    在项目初期,我们用到的管理工具是国内的一款开源软件——禅道,在项目初期,这款软件还是很强大的。开发团队在迭代计划会议中细化Product Backlog中的任务,生成一个个小的Story,然后由PO把这些Story更新到项目管理工具上(禅道)。

    然后组员登录该系统,根据喜好选择并领取任务,需要注意的是,每个成员可以领取多个任务,但每天只能有一个任务是“处理中”状态,这能确保组员能够专心完成某一个任务,而不用三心二意。如果这个任务和其他任务有依赖,则可以与PO协商之后,把该任务先改为“挂起”状态,开始另一个任务。

    随着开发的进行,我们的管理工具由禅道换成了JIRA,对于Scrum来说,JIRA更加的适合一些,因为JIRA在设计理念中就已经包括了Product Backlog、Sprint、Story等这些元素。同样的,由PO建立Story,组员去自由选择领取喜欢的Story进行开发。



    适用的项目 


    刚刚了解Scrum的朋友,经常会有这样的疑问:到底什么样的项目适合使用Scrum呢?我们也一直在探讨。首先,我们来看一下关于过程的定义。过程控制通常有两种形式,一种是预定义过程,另一种则是经验性过程。

    预定义过程

    • 每一项工作都可以被完全理解
    • 给予合理的输入定义,每次便可以得到相同的输出
    • 过程启动后,允许运行直到结束,每次运行产生相同的结果
    预定义过程的示例比如:生产混凝土的过程,只要原料配比确定,加入的顺序以及搅拌动作、搅拌时间确定,那么产出的结果将完全一样。

    传统的瀑布开发模式是基于预定义过程来设计的。

    经验性过程

    • 过程是不能够完全预定义好
    • 结果是不可预知的
    • 生产过程是不可重复的
    • 通过不断的检查和调整使得过程能够产出我们需要的结果
    经验性过程的示例比如:一场足球赛,我们不可能规定好每个人的动作,我们也不能预测比赛的结果,我们只能通过激励,通过不断检视和调整团队,让他们发挥到更好的水平,以达成战胜对手的目标。

    Scrum是一个经验性过程,它的核心是在项目的整个过程中提供给项目的参与者以及干系人高度的透明性,基于透明性来进行不断的检查和调整,通过不断的检查和调整持续的优化过程和产出结果,提升团队交付能力,以此达到按时交付高质量的,客户真正需要的产品。

    适合管理复杂的项目


    基于上述的对比,显而易见的是管理这种复杂的项目,我们不可能在一开始把整个的过程预先定义好,项目的结果如何,我们也很难再一开始就完全预知,项目存在很多的不确定性,整个项目过程也是不可能重复进行的。所以,管理这样的项目需要使用Scrum这样的经验性的过程来达到更好的效果。


    一点经验


    关于迭代计划会议


    在Scrum敏捷开发中,迭代计划会议是项目开始之前很重要的一个会议,它决定了项目能否顺利的执行下去。而且,在迭代计划会议上,PO、架构师、开发小组成员要对Product Backlog中的需求进行细化分解,分解成最小的任务,最好是彼此没有依赖(期望值,一般这个很难实现)。任务越小,完成每一个任务花费的时间也就会越少。在分解任务时,需要小组成员给该任务评估开发时间,即用多长时间能够完成该任务(Story)。

    开发中的沟通问题


    在开发中,组员之间、组员与ScrumMaster之间、以及组员与客户之间的沟通是相当重要的,如果在开发中,遇到什么不确定的需求或者问题,要及时的与ScrumMaster反应,以免做一些无用之功,时间对于Scrum成员来说是很宝贵的。ScrumMaster应该确保每个成员每天的有效工作时间,为每一个成员排除一切阻碍他们开发的困难,及时发现,及时沟通,及时解决。


    结语


    最后,说一点别的东西。就目前软件开发的现状来说,需求的变更是很平常的事情,初期客户由于不了解自己具体所要的系统,而描述的不清楚,但随着开发的进行,随着沟通的增多,客户会越来越清楚想要开发的系统,因此在开发中经常会变更需求。

    对于变更需求,传统的开发方式已经很难应对这种情况了。而敏捷开发就是应对这种需求变更最好的方式,以最小的核心需求进行开发,同时每一个迭代之后,都会以最新的需求作为目标,因此每一个迭代都会与客户的目标很接近,最终会完美的交付客户需求的系统。这就是敏捷开发的魅力所在,以最小的代价,完成最伟大的作品。

    展开全文
  • 1,提要 软件开发是一个系统工程,包括最初的可行性分析、再到设计、开发、测试、维护等整个生命周期。在这个过程中某些阶段的失误或说是变化,都可能增加...传统瀑布模式和新型的敏捷开发就是其中最常用的方法,后
  • 敏捷开发漫画全系列

    2010-10-28 21:44:00
    原文转自:http://www.systhinker.com/html/85/n-21485.html 敏捷开发系列漫画(一):并行迭代开发模型 【概述】 敏捷开发系列漫画希望以活泼... 敏捷开发系列漫画(二):如何安排迭代计划 【概述】 敏捷开发系列漫画
  • 敏捷开发4大价值观 个体与交互胜于流程与工具 可工作的软件胜于面面俱到的文档 客户协作胜于合同谈判 响应变化胜于遵循计划
  • 过去,几乎所有的软件开发项目都采用瀑布模型。这种编程方法酷似工厂装配线,...敏捷软件开发以及似乎无穷无尽的变种方法已越来越常见。现在它们成了主流的编程方法。 我们在本文中介绍了十种最流行的软件开发方法的功
  • Scrum敏捷开发流程主要包扩三个角色、四个会议和个三物件。 三个角色 Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。 Scrum 团队是自组织、跨职能的完整...
  • 上一站,我们简单的谈了谈FDD,了解了什么是特征驱动开发,以及它核心的整体模型,在我看来,它是一种有效但有一些复杂的敏捷开发方法,对于小团队来说,实施起来有些困难。然而,今天我们要认识的是一种新的开发...
  • 敏捷开发之旅的第三站,我想要和大家一起分享FDD特征驱动开发方法。 特征驱动开发——Feature Driven Development 还是老规矩,讨论之前,我们先了解一下什么是Feature?什么是FDD? Feature ...
  • 版本管理是非常重要的,但很多公司或者程序员根本对这个版本管理毫无概念。今天,有渔老师就来讲下我在团队中使用的版本管理发布流程。 一、软件 1、版本命名规范 软件版本号由四部分组成,第一个1为主版本号,第...
  • 企业现在大量采用敏捷开发,以加快项目进度及更好地显示其价值。 Gartner应用架构、开发和整合峰会下个月在悉尼召开。Gartner公司研究总监NathanWilson在会议前夕表示,敏捷方法如果使用得当,是有能力改变IT业务...
  • 一个团队在一起Coding时,就怕发生这样的事情:同1个文件你改了,我也改了,他也改了,最后怎么同步呢?以前用clearcase时,A把文件checkout了,其他人就不能提交,保证了代码的唯一性。但现在用git后,大家都可把...
  • 原则,力求各司其职,简单明了。 1. 测试人员提交bug ⑴ 标题: [ 模块名称 ] 问题描述 ⑵ 内容: 问题重现步骤的描述,最好贴上图片。 因为一图胜万言。...⑶ 指定责任人: 根据bug指定责任人。...
  • 书接上文,上次我们了解了敏捷开发的架构,但是利用我们普通的开发工具Eclipse的Ant构建是无法完成项目依赖等工作的,所以在开发之前我们需要准备好以下开发环境  maven + nexus + hudson + git 注:本文基本环境 ...
  • 这是敏捷开发一千零一问系列的第十四篇。(在这里提问,之一,之二,之三,问题总目录)正逢周末,又是愚人节,群中有人正在加班,想起上次培训中间休息的时候,讨论起这个“敏捷开发加班吗”的问题,虽然后来没有...
  • 敏捷开发和迭代开发

    2019-06-27 17:05:44
    敏捷开发与迭代式开发是整体与局部的关系 敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试...
1 2 3 4 5 ... 20
收藏数 35,977
精华内容 14,390
关键字:

敏捷开发系列