• 敏捷12条原则

    2018-08-02 22:36:31
    没有什么方法可以保证团队一定能开发出完美的软件,敏捷的团队也是同样地,所以,有一系列的原则来帮助敏捷团队。 最优先要做的是尽早、持续地交付有价值的软件,让客户满意。 欣然面对需求变化,即使在开发后期。...

        没有什么方法可以保证团队一定能开发出完美的软件,敏捷的团队也是同样地,所以,有一系列的原则来帮助敏捷团队。

    1. 最优先要做的是尽早、持续地交付有价值的软件,让客户满意。
    2. 欣然面对需求变化,即使在开发后期。敏捷过程利用变化为客户维持竞争的优势。
    3. 频繁地交付可工作的软件,从数周到数月,交付周期越短越好。
    4. 在团队内外,面对面交谈是最有效,也是最高效的沟通方式。
    5. 在整个项目过程中,业务人员必须和开发人员每天都在一起工作。
    6. 以受激励的个体为核心构建项目。为他们提供所需的环境和支持,相信他们可以把工作做好。
    7. 可工作的软件是衡量进度的首要标准。
    8. 敏捷过程倡导可持续开发。
    9. 坚持不懈的追求技术卓越和良好的设计,以此增强敏捷的能力。
    10. 简单是尽最大可能减少不必要工作的艺术,是敏捷的根本。
    11. 最好的架构、需求和设计来自自组织的团队。
    12. 团队定期反思如何提升效率,并依此调整自己的行为。

    客户总是对的吗

        一个好的开发团队要交付给客户真正需要的东西,而不是提供给他们要的东西。亨利.福特曾经说过一句话“如果我问人们想要什么,他们肯定会说想要更快地马(而不是汽车)”。这个事情说明客户无法在一开始就告诉你他想要的是一辆汽车而不是一匹更快地马。敏捷所说的12条原则的初衷就是让团队构建用户真正需要的产品,有价值的软件。但是每个人都会看到软件中不同的价值,那么就要求每个人都想想其他利益相关人,想他们各自关心的事情,想想软件会给他们带来的价值。任何新产品在第一次面市的时候都是功能不全面的,尤其市面上没有同类产品的时候,随着时间以及版本的更替,产品会解决越来越多的问题,以及会变的越来越好用,我们现在去看当初的产品肯定很容易就看出来其中的问题,但是在项目刚刚开始的时候是很难思考全面的。

        按我现在说的做,而不是按我之前说的做

        很多公司,包括我现在所处的公司也是同样,做一个项目或者产品的时候会在一开始组织专门的人员找齐全部利益相关人开会讨论,然后将所有的信息整合到一起形成一份说明书,然后再发送到各利益相关人那里进行评审,然后再开会讨论,再出一份更好的说明书,一次一次的可能要耗费好几天,最终形成一份各方面都满意的说明书。拿给开发团队评估工期,综合各方面可能要12个月之久,但是各利益人都觉得很不错,因为一年之后就可以拿到一个非常棒的产品。经过一年的奋斗,开发团队终于交付了产品,产品与说明书相差无几,准确地展现了各利益人所要的功能。但是结果呢,往往一年的时间市场已经变化,一年前很被市场需要的软件并不被当前的市场所需要。

        市场存在着变数,一些变数在项目初期是可以被发现的,但是更多的变数都是在项目开始的时候无法被发现的。但是说明书已经制定了,而开发团队又不喜欢自己做的东西不停的变化。所以团队要快速地响应市场以及各利益相关人的变化,敏捷的几项原则就是帮助团队应对这种变化的。

    原则1:最优先要做的是尽早、持续地交付有价值的软件,让客户满意

        敏捷团队最重要的事情就是给客户交付可工作的软件。而这条原则就包含三点,尽早发布软件、持续交付价值以及让客户满意。

        没有什么事情的完美的。尽管在项目一开始每个人都想一次性的提出全部的需求,但是问题在于客户在真正拿到可工作的软件之前,都不清楚应该提什么样的需求。所以就要求开发团队尽早的交付,尽早的给客户一个可工作的软件,即便是仅交付了一个可工作的特性,也是一种突破。这对整个团队都是有益的,因为客户可以给出有价值的反馈,这样开发团队才能朝着正确地方向推进项目。

        尽早交付也有一个缺点,就是最初交付给客户的软件完成度非常的低。很多客户很难忍受一个仅有部分功能,还有可能存在大量BUG的软件,这些客户往往认为既然交付就要交付完整地产品。敏捷的核心价值观里有一句,客户协作高于合同谈判。这就要去客户也要能够和开发团队一起成长,一起协作,共同逐步完善产品。如果客户非常官僚,那么团队就必须全新的变更管理流程,这要去与客户重新进行一轮合同谈判。真正与客户协作的团队可以在开发过程中任意进行任何有必要地改变,这也是持续交付的意义所在。而团队确定哪些特性能交付价值的唯一方法就是与客户协作,并利用前一次迭代收到的反馈。从短期看,团队可以通过尽早交付价值让客户满意,从长期看,交付最终产品的时候可以使得价值最大化。

    原则2:欣然面对需求变化,即使是在开发后期。敏捷过程利用变化为客户维持竞争优势

        我以前的工作是数据安全,公司比较小,是给别人做项目的,而做项目的弊端就是会面临着大量的变化,尤其是老板不会顾及工作量,也不会改变截止时间,当这个样子有大量的变化时,开发人员就一定会有情绪,从而形成恶性循环。

        为什么会使得开发人员抱怨不止,因为在需求变更之前,开发人员会认为项目进展的很好,而且可能做了很多决策:如何规划产品结构,要开发什么产品,向客户承诺交付什么。结果一个项目外的人突然告诉你这个计划里有错误,而且是你的锅。给开发人员说它错了,是很难接收的。尤其说的人还享受着他的服务,就好比,你做了一盘菜给别人吃,那个人一边津津乐道的吃,还一边骂你做的菜难吃如屎。开发人员对自己所做的工作都是有一种自豪感的:我们交付的产品我们能负责,而且能满足用户的需求。而变化就是在质疑这种自豪感。瞬间就会感觉自己的努力没有得到尊重。

        而开发人员如何才能够接收变化。简单地说就是站在客户的角度去看待问题。其实客户也不愿意给开发人员提出变化,因为这就是要求他们承认自己在一开始犯了错误,让开发人员白做了很多事情。正因如此,往往客户都是很晚才来告诉开发人员变化,因为他们知道自己带来的是坏消息,这是让人很难堪的行为,客户还要为整个变化买单。所以,将心比心,开发和客户都要做一些不可能的事情,开发人员被要求读懂客户的心,客户被要求能预测未来。

        要做到能够欣然接收变化,就要意识到以下几点:

    • 不要认为有变化就要有人要倒霉。每个人都要求知道犯错了以后就立即改正而不是期待一开始就做到完美。
    • 我们是一条绳上的蚂蚱。每个人包括客户都要对全部需求以及变化负责,争论谁对谁错是没有意义的,抱怨变化是没有意义的。
    • 我们不把变化拖到最后。谁都不愿意犯错误,但是这是难免的,那么就要尽早修复,将损失降到最低。
    • 我们不要再把变化当做犯错。在当时的信息环境下,能做到那个程度已经很好了,出了错事才会让路变得更加明朗。
    • 我们通过变化学到东西。变化才是团队成长最有效的方式。

    原则3:频繁交付可工作的软件,从数周到数月,交付周期越短越好

        对于敏捷实践者来说,传统的实践方法被称作“命令-控制”。这种方式与军事的命令-控制的方式是一致的。“命令”指的是项目经理给团队分配任务的方式。尽管并不是所有成员都向项目经理汇报,但是项目经理仍然可以控制所有人的任务分配。“控制”指的是项目经理管理变化的方式。无论是项目内的变化还是员工休假、机器故障,亦或是其他一些无关的变化,都在项目经理的监控之内。当变化时对其进行评估,更新项目计划,在进度安排和文档中引入变化带来的改变,给团队分配新的任务,管理利益干系人的期待,不要让人感到意外。使用敏捷的传统项目负责人不愿意欣然接受变化的原因就是害怕变化引起的混乱。

        那么,如何才能又能欣然的接受变化,又能不引入混乱?关键在于频繁发布可工作的软件。团队将迭代的周期缩短,在每一轮迭代结束的时候,都可以交付一个可以使用或者演示的软件,然后计划下一个迭代要干什么,这样一个可预测的进度安排和持续检查可以帮助团队尽早掌握变化,同时也创建了一个没有责备的氛围。传统项目经理最大的困难就是监视变化,每日审查和迭代回顾相当于让整个团队帮助项目经理尽早的发现变化,避免将变化放在项目的晚期,从而防止这些变化对项目造成更严重的影响。

        传统的瀑布式流程一旦定义好需求就把开发团队和客户完全隔离开,而敏捷团队采取的则完全不同,后者始终与客户交互。这样就可以及时响应变化,开发出更好地产品。但是每当发现项目确实需要修改的时候,都有一半人返回去更新规格说明书,以保证计划保持最新的状态。越来越多的人觉得文档太多,但是每当想砍掉一些内容的时候,就会有人说如果不写某项功能、需求、设计或测试用例,那么就会有人产生误解。如果最终的实现不正确,他们就会因此遭到谴责。于是,文档中的任何一部分看上去都是必要地,因为少了任何一部分团队都有可能开发出错误的软件。

        自古以来,各个团队都对文档写多少而感到困惑,一直都在努力找到一种平衡。那么对于敏捷团队来说,文档写的够项目开发用就可以了,具体要参看团队要解决的问题以及沟通的情况。一个原则就是如果某种文档不能给团队开发软件带来帮助,而且也没有必须写的原因,那么敏捷团队就不写这种文档。例如监管的要求、投资者的要求、高级经理的要求或者其他利益干系人的要求。不过在传统瀑布式项目中,完整文档的全部意义就在于更好地应对变化,但是遗憾的是对于大部分团队来说,完整地文档往往给管理变化带来阻碍。团队在项目开始的时候要花大量的时间努力预测未来会发生什么,并完整地记录下来。项目执行的时候,他们需要不停地维护已经写好的文档,并记录所有新开发的内容。如果对于正在开发的产品有了新的理解,他们还需要返回去修订所有受影响的文档。随着时间的推移,过时的文档就会越来越多,团队需要花很大的功夫去维护这些过时的文档。况且各个人去编写的时候又会把视角割裂引进去。

    原则4:在团队内外,面对面交谈是最有效、也是最高效的沟通方式。

        我们为什么要写文档,并不是因为要写出来一份东西,而是要把我的想法告诉你,使得我脑子里地想法和你脑子里地想法仅可能的接近。为什么面对面的交谈是最有效的,而且大于文档。因为我们都知道,一份完整地文档是很难实现的,而且是非常耗时的,到最后完成的文档又不一定在项目中有用。然而面对面去交谈,就很容易形成头脑的风暴,很容易让大家的思想达到统一,这正是交谈的良好方式,一有什么变化就可以立即进行讨论。

        团队沟通的终极目标是形成一种集体意识,在成员之间建立不必直说也能领悟的共同知识。一个团队能够形成集体意识,越能共享同样地视角,就越容易对同样地问题形成一致的答案。这酒为团队构筑了处理变化的坚实基础,可以跳过冲突,立即编写代码,而且不会因为维护文档而分心。

    原则5:在整个项目中,业务人员和开发人员必须每天在一起工作。

        为了完成出色的软件,开发团队需要与业务人员进行大量面对面的讨论,业务人员了解需要什么软件,因为他们在没有软件的情况下开展了同样地工作,有了业务人员的陪伴,研发人员可以及时更改自己的开发方向,但是业务人员往往希望开上一两次会就解决剩下的问题,因为他们同样也有自己的工作。

        如何解决这个问题,首先双方要都认识到,团队要给公司开发带来价值的软件。完成后的软件应该值得公司的投入。如果软件带来的价值超过了开发软件的成本,那么公司就值得在这项开发上面投入资金。一个好的项目应该有足够的价值让业务人员赶到值得投入精力。所以业务人员应该与开发人员坐在一起工作,尽早的处理变化,因为后期修改的成本会很高。而业务人员应该很喜欢跟敏捷的团队一起合作,因为传统的开发团队把业务人员看做谈判的客户,而敏捷团队则是与客户合作的,在项目进行过程中客户具有平等的发言权。

    原则6:以受激励的个体为核心构建项目,为他们提供环境和支持,相信他们可以把工作做好。

        如果团队里地每一个人都认为自己开发的软件是很有价值的,是能够给公司带来利益的,那么这个团队就会越来越好。相反,如果团队成员看不到软件的价值,或者他们没有因为开发优秀软件而得到奖励,那么在这种情况下,项目就会失败,因为项目中最重要的是人。现在大多数公司的考核与绩效往往不利于员工开展高效的敏捷方法。

        大多数公司的问题为:
    1、在代码审查中,如果不断发现bug,那么这个程序员就会得到糟糕的评价,如果没有发现bug,那么这个程序员就会得到奖励。(这会导致程序员在代码审查中不愿意去寻找bug。)

    2、根据发现bug的数量去奖励测试人员。(这会导致测试人员挑刺并且奖励报告的质量。这种方式还会使得程序员和测试人员之间产生敌对情绪,会阻碍程序员和测试员之间的合作。)

    3、根据业务分析员产出的文档量去判定其绩效评级(而不是根据他们与团队分享的知识量评评级)

    所以以这种绩效去考核程序员,最终出来的内容肯定不会好,一个很好的团队应该根据成员对团队的贡献去进行考核,鼓励贡献多的人员。比如认识到软件并没有解决的某个业务问题并将其修复的程序员,以及能够发现代码或架构中的问题并提交给团队的测试人员。

        不好的氛围容易引发一种一心自保(Cover Your Ass,CYA)的态度,在这种态度下,测试人员会努力确保每一项需求都有测试覆盖,而不去考虑测试到底能不能对软件的质量有所帮助。程序员会严格遵循需求文档中的每一个字,而不去认真想一想自己开发的功能是不是真正给用户带来价值。在这样的公司经理自然想找一个“始作俑者”为那些因变化而产生的额外工作量而负责。当这种趋势不可避免的时候,团队里的成员会逐渐转向编写“防御性文档”以保护自己。为了避免糟糕的考核或惩罚,他们可以把责任撇向他们所遵循的那部分文档。

        过于详尽的文档会增加需求含糊以及团队成员之间误解和沟通的风险。敏捷团队最有效的沟通方式就是面对面的沟通,并且输出最少的文档,让开发人员和业务人员每天工作在一起,尽快的交付最大价值的产品,并且在团队中每一位成员都会有项目的责任感,因为他们都要对项目负责,并且他们都可以为项目做出正确地决定。

    原则7:可工作的软件是衡量进的的首要标准

        好的团队合作会确保所有人在任何时刻都了解项目的进展。

        在传统的“命令-控制”项目经理眼中,要想掌控项目的进展就要让成员经常更新项目的状态。但是状态汇报是很难获得项目的真正状态。汇报本身就不是一种完美的沟通工具,而且还带有很浓重的政治色彩,而且所有的项目经理到知道有时候需要在状态汇报中略去一些会让经理和团队主管难堪的东西,而别人常常需要用这些信息进行决策。

        所以,最好的汇报方式就是一个可工作的软件,只要真切的看到了软件在眼前工作,那么你就“得到了”项目的进展。当看到软件中缺少或者不满意的部分,相关人员就会主动去沟通下一步的计划了。敏捷团队在每一轮迭代结束的时候交付可工作的软件,通过真实地产品向大家展示具体成果,团队可以让大家掌握项目进展的最新情况,而且这种方式几乎不可能让人产生误解。

    原则8:敏捷过程倡导可持续开发。赞助商、开发人员和用户要能够共同、长期维持其步调,稳定向前

        很多团队就会出现一种现象,每当截止日期临近的时候,就会出现拼命的加班,尤其是在晚上和周末。这种做法是不可靠的,一个团队可以拼命工作几个星期干更多地活,但是团队的工作效率一般都会再这段时间过后一落千丈。人们会感到疲劳,而且由于加班而耽误的事情,最终都会找上门来,然后就会付出更多的时间和精力去处理。因此敏捷团队要做的就是可持续的开发节奏。会预留时间,并且制定一个切实可靠的计划,通过迭代。因为每次预估的都是接下来一周、两周的公布工作内容,而且承诺的仅是可以交付的内容,所以就不会动不动的加班,从而形成一种良性循环。

        可持续的开发节奏就是给予团队足够的开发时间,让成员不需要工作到深夜,也不需要周末加班的节奏。

    原则9:坚持不懈的追求技术卓越和设计优越,以此增强敏捷的能力

        计划做的太夸张并不是老加班的唯一原因,有的时候看起来是一个很简单地功能,当做起来就觉得有点难度,而随着越做越深入,就觉得这是一个坑。然后发布了以后本来可以轻松的转向其他的事情,但是却要不停的修复这个功能的bug以及打补丁。所以从长久来看设计良好的代码会大量减少后续的维护工作。但是这并不是意味着在软件一开始就进行完整地设计。而一个良好的程序员会再编写的时候不停的寻找设计和代码的问题,一旦发现问题,就会立即进行修复。在项目的开发过程中,只需要在当下多花一点点时间编写可靠的代码并及时修复问题,那么留下来的这份代码库在未来就会非常好的维护。

    原则10:简单是尽最大可能减少不必要工作的艺术,是敏捷的根本

        在开发软件的时候,要尽量的简单,解除耦合性,因为如果项目比较复杂,那么在向项目中添加新的代码的时候就会让项目变得越来越复杂,因为有了依赖关系,变化导致系统另一部分发生变化的可能性会提升,后面还有可能导致第三个变化,到最后就会形成多米诺效应。而产出好的代码的方式就是以最少计划启动项目,但是人们往往认为没有良好的计划,那么将来面对变化的时候就会很头疼,因为如果现在就开始编码的花,那么以后遇到变化的话,就有可能删除现在的代码。

       避免这种现象的方法就是迭代式的编程,每轮迭代都开发没有太多依赖或者不必要依赖的代码系统。编码的时候如果团队仅基于一些智能实现单一功能的小型自包含单元进行设计,那么就可以很好地避免多米诺效应。那么哪些单元是很有必要的,就要去业务人员与开发人员经常的进行沟通,确保只开发有价值的特性,因为后期维护一些没有价值的特性往往比这些特性给公司带来的价值要高。

    原则11:最好的架构、需求和设计来自自组织的团队

        有大量事前设计的团队非常容易做出过于复杂的设计。因为在设计和架构的阶段就要尽全力就必定意味着要构建可以做到的最棒的架构。如果提出的需求比较少而且设计太简单,那么从直觉上就会给人一种偷工减料的感觉。只有他们拿出一份巨大的需求文档和一个复杂的设计才不会让人质疑。过于复杂的设计又会舍得后期做变化的时候陷入恶性循环。

        那么一个比较好的方式就是组织自组织的团队(self-organizing team),没有明确地需求和设计环节。这个团队会一起对项目进行规划,并且会作为一个团队进行改进计划,没有明确地领导,也就没有很多的干预项,他们会把项目分解成多个部分,从能给公司带来最大价值的部分着手,然后再考虑详细的需求、设计和架构。这样的团队所有人都会对架构进行设计,每个人都有责任,每个人都说的算。这样的团队就很容易循序渐进,从而设计出一个增量式的方案。

    原则12:团队定期反思如何提升效率,并依此调整

        一个敏捷团队如果不能持续地改进构建软件的方式,那么团队就不算敏捷。敏捷的团队会不断的对项目进行检查,不断的进行优化,他们会从项目中学习,通过检查的结果对未来进行改造。而且他们并不只是在项目结束的时候这么做,他们会每天都在寻找需要改进的地方。增强团队实力的唯一方式就是经常回顾自己已经做的事情,然后评估作为一个团队这些事情做得怎么样,最后提出改进的计划。要经常回顾过去,看看哪些事情做对了,哪些事情做错了。这需要揪出具体的问题和错误,而很少有人会对公然指出其他的错误而感到自在。随着时间的推移,团队中的成员会对这件事情感到越来越自然。最终,大家会认为这是提意见而不是挑刺。

        很多团队认为他们并没有时间去进行这件事情,他们在一个项目结束了以后就会立即投入下一个项目中,认为与其花时间在这个上面还不如投入到下一个项目中。那么就要求团队在制定计划的时候就给项目结束后预留一些时间来进行回顾,因为这件事情很重要,团队成员可以从这其中吸取教训,提高效率。

    整合所有的原则

        一个好的敏捷团队是要整合所有的原则,而不是从中寻找几个实践,整合这些实践的关键在于团队的思维方式,敏捷的价值观和原则是思维背后的动力。敏捷团队不仅要诚实的回顾开发软件的方式,还要回顾成员交流的方式,以及与公司其他同事交流的方式。首先要理解原则,然后要理解其中的原理,还要在工作中不断的评估和改进。

       一些比较牛的开发人员往往遇到这样的事情:本来开发了一段很棒的代码,结果某个根本不懂编程的人要求做出一个修改,你就不得不把这段代码弄乱然后打上补丁,之后就进行了一个沮丧的恶性循环。这个时候开发人员就会很容易被敏捷的团队所吸引。在敏捷团队中,会不断的与客户沟通,不断的做计划,在计划与沟通中,就过滤到一些棘手的问题,并且不断改变自己的编程方向,编写一些耦合性低得代码,以及一些价值高的产品,从而就可以在后期从容的面对变化。

        并且敏捷团队的沟通方式可以让开发人员真正的进步,因为他们的团队很可能是自组织团队,每个人都会去进行自主的学习,因为团队的知识决定了项目的宽度,并且团队成员自己会决定让团队正常运转的沟通内容,这不仅可以开发出更好地产品,而且你还可以向坐在身边的开发人员取长补短。

    展开全文
  • 敏捷不是某一种方法论、过程或框架,更不是字面意义上的敏捷,而是一组价值观与原则

     敏捷不是某一种方法论、过程或框架,更不是字面意义上的敏捷,而是一组价值观与原则。

    敏捷开发的核心理念:

    • 敏捷开发的核心理念:敏捷开发的核心理念就是以最简单有效的方式快速地达成目标,并在这个过程中及时地响应外界的变化,做出迅速的调整。
    • 敏捷开发的第一条价值观就是“ 以人为本”,强调“ 个体(人)” 及“ 个体” 间的沟通与协作在软件开发过程中的重要性。这个顺序不是偶然而为之的,敏捷开发将重视个体潜能的激发和团队的高效协作作为其所推崇的第一价值观。
    • 敏捷开发的第二条价值观就是“ 目标导向”。同其他众多管理理论和模型一样,敏捷开发认同目标导向是成功的关键,因为没有目标也就无所谓成功。敏捷开发的价值观中清楚地阐明,软件开发的目标是“ 可工作的软件”,而不是面面俱到的文档。而遗憾的是,很多软件项目已经在纷繁的文档之中迷失了自己的目标。
    • 敏捷开发的第三条价值观就是“ 客户为先”。虽然敏捷开发强调的第一价值观是“ 以人为本”,但敏捷宣言的缔造者们并没有忘记客户,相反他们真正的理解客户的需求、懂得如何与客户合作。敏捷价值观里强调的“ 客户为先”即不是简单地把客户当作“ 上帝”、刻板的推崇“ 客户至上”,客户要求什么、我们就做什么;也不是把客户当作“ 谈判桌上的对手” 甚至“ 敌人”,去斗智斗勇。敏捷价值观把客户当成了合作者和伙伴,把自己的使命定位为“ “ 帮助客户取得竞争优势”。
    • 敏捷开发的第四条价值观就是“ 拥抱变化”。人们常说“ 世界上唯一不变的就是变化”,大多数人也相信事实确实如此。而以往很多的软件项目却忽视了这一点,或者更准确地说是他们不愿意“ 正视”。他们总是试图用详尽的计划去预先穷举这些变化,然后又试图通过严格遵循计划来控制变化的发生,而结果往往是被不断涌现的变化击垮。敏捷开发价值观中承认变化是软件开发的一部分、并相信正是客户在不断变化其需求的过程中明晰了其真正的需要。因而敏捷开发欢迎变化、拥抱变化,并可坦然应对变化,正是这些变化为客户和项目带来了价值。
    • 最后,还应记住敏捷宣言中的最后一句话:“ 尽管右项有其价值,我们更重视左项的价值”—敏捷宣言并未否定或贬损“ 右项” 的价值,在敏捷开发的价值观中承认“ 流程和工具”、“ 详尽的文档”、“ 合同谈判” 以及“ 遵循计划” 的重要性,只是两相比较,“ 更重视左项的价值”。

    敏捷开发的十二条原则:

    1)我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
    2)欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
    3)经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
    4)业务人员和开发人员必须相互合作,项目中的每一天都不例外。
    5)激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
    6)不论团队内外,传递信息效果最好和效率最高的方式是面对面的交谈。
    7)可工作的软件是进度的首要度量标准。
    8)敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
    9)坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
    10)以简洁为本,它是极力减少不必要工作量的艺术。
    11)最好的架构、需求和设计出自组织团队。
    12)团队定期地反思如何能提高成效,并依此调整自身的举止表现。
    - 敏捷开发原则是对敏捷价值观的解释和实践,它将敏捷的价值观落实到具体的可操作的原则之上,遵循这十二条原则,是敏捷软件开发项目得以成功的基石。
    - 这十二条原则囊括了软件项目管理的所有基本流程,而且这些流程足够具体,它告诉我们项目管理的第一步就是要明确目标,而软件项目的终极目标就是“ 不断地及早交付有价值的软件使客户满意”;它提示我们软件工程的起始点是需求,而需求的固有特征就是不断变化,敏捷开发过程要响应变化;它强调“ 可工作的软件是进度的首要度量标准”,因而需要以尽可能短的周期“ 经常地交付可工作的软件”;它重视相关干系人的协调(“ 业务人员和开发人员必须相互合作”、“ 责任人、开发人员和用户要能够共同维持其步调稳定延续”),重视激发个人潜能(“ 激发个体的斗志”),要求团队使用最高效的沟通方式(“ 面对面的交谈”);它推崇技术变革所具备的强大能量(“ 坚持不懈地追求技术卓越和良好设计”);它强调精益生产(“ 简洁为本”),要求项目采用自组织团队管理模式,并指出“ 定期总结反思” 是校准团队行为、最终达成目标的有效途径。

    展开全文
  • 敏捷开发12条敏捷原则 欢迎转载,转载请注明:转载自敏捷个人网站   1。我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意  规划迭代故事时必须按照优先级安排,为客户先提供最有价值...

    敏捷开发之 12条敏捷原则

    欢迎转载,转载请注明:转载自敏捷个人网站

     

    1。我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意

       规划迭代故事时必须按照优先级安排,为客户先提供最有价值的功能。通过频繁迭代能与客户形成早期的良好合作,及时反馈提高产品质量。敏捷小组关注完成和交付具有用户价值的功能,而不是孤立的任务。以前我们都用需求规格说明书或者用例来编写详细的需求,敏捷使用用户故事来罗列需求。用户故事是一种表示需求的轻量级技术,它没有固定的形式和强制性的语法。但是有一些固定的形式可以用来参考还是比较有益的。敏捷估算中使用了这个模板:“作为【用户的类型】,我希望可以【能力】以便【业务价值】“。使用基于用户故事的需求分析方法时,仍可能需要原型和编写文档,只是工作重点更多的转移到了口头交流。 

     


     

    2。即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
      敏捷过程参与者不怕变化,他们认为改变需求是好事情,因为这些改变意味着我们更了解市场需求。 

     

      

     

    3。经常性的交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好
      迭代是受实践框限制的,意味着即使放弃一些功能也必须按时结束迭代。只要我们可以保证交付的软件可以很好的工作,那么交付时间越短,我们和客户协作就越紧密,对产品质量就更有益。虽然我们多次迭代,但并不是每次迭代的结果都需要交付给用户,敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些功能,增加的每个功能都是经过编码、测试,达到了可发布的质量标准的。
      另外敏捷开发项目中对开发阶段没有什么重要的分割,没有先期的需求阶段,然后是分析阶段,架构设计阶段,编码测试阶段等,在项目真正开始后,每次迭代中都会同时进行所有的上述阶段工作。

     


     

    4。在整个项目开发期间,业务人员和开发人员必须天天都在一起工作
      软件项目不会依照之前设定的计划原路执行,中间对业务的理解、软件的解决方案肯定会存在偏差,所以客户、需求人员、开发人员以及涉众之间必须进行有意义的、频繁  的交互,这样就可以在早期及时的发现并解决问题。 


     

    5。围绕被激励起来的个来构建项目。给他们提供所需要的环境和支持,并且信任他们能够完成工作。
      业务和技术是引起不确定的二个主要方面,人是第三个方面。而业务和技术又必须由人来执行,所以能够激励人来解决这些问题是解决不确定性的关键。只要个人的目标和团队的目标一致,我们就需要鼓舞起每个人的积极性,以个人为中心构建项目,提供所需的环境、支持与信任。 


     
     

    6。在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈
      在十几或者二十几个人组成的大团队中,文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人(大团队实施敏捷时也会分成多个小的敏捷团队),所以大量的文档交流其实并不是很经济的做法。此时面对面的交谈反而更快速有效。 


    7。

    工作的软件是首要进度度量标准。
      一般的工作都比较容易衡量任务进展,比如让你去搬运1吨的石头,我只要去称一下你已经搬运的石头重量就知道你完成多少了。而对于软件来说,在软件没有编码、测试完成之前,我们都不能因为代码编写了多少行,测试用例跑了多少个就去度量这个功能是否完成了。衡量这个功能是否完成的首要标准就是这个功能可以工作了,对用户来说已经可以应用了。

      

    8。敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
      很多人都认为软件开发中加班是很正常的,不加班反而不正常,我对此有点不理解,这个可能是国情所致吧。敏捷过程希望能够可持续的进行开发,开发速度不会随着迭代的任务不同而不同,不欣赏所谓的拼一拼也能完成的态度,开发工作不应该是突击行为。我们不能指望说突击这个项目后就可以轻松了,因为完成一个项目后会接踵而来下一个项目,而只要还是拼拼的态度,下一个项目依旧会让你的组员再次突击。这时不知道有人会不会说,那我们就一直加班,也是“持续的开发速度”啊,这时可要注意了,持续加班智慧导致人疲劳、厌倦,保持长期恒定的速度也只是一种理想而已。 


    9。不断地关注优秀的技能和好的设计会增强敏捷能力。
      敏捷过程有很多好的技术实践可以加强产品敏捷能力,很多原则、模式和实践也可以增强敏捷开发能力。 《敏捷软件开发-原则、模式与实践》一书中介绍了很多设计,感兴趣的可以去仔细看看。 


     

    10。简单----使未完成的工作最大化的艺术----是根本的。
      我们不可能预期后面需求会如何变化,所以不可能一开始就构建一个完美的架构来适应以后的所有变化。敏捷团队不会去构建明天的软件,而把注意力放在如何通过最简单的方法完成现在需要解决的问题。这时有人会说,我已经预计到了肯定存在哪些需求扩展点,我们在一开始是否需要考虑呢?这时团队需要根据自己的理解去决定是否考虑,如果深信在明天发生了这个问题也可以轻易处理的话,那么就最好先不考虑。 


     

    11。最好的构架、需求和设计出自与自组织的团队

    敏捷中有很多种实践,大家都知道,迭代式开发是主要的实践方法,而自组织团队也是主要的实践之一。在自组织团队中,管理者不再发号施令,而是让团队自身寻找最佳的工作方式来完成工作。要形成一个自组织团队其实比较难。CSDN采访Mishkin Berteig中说到 自组织团队的第一个要素就是必须有一个团队,而不仅仅是一群人。一群人是一帮在一起工作的人,他们彼此之间并没有太多的沟通,他们也并不视彼此为一体。项目一开始,我们就会组建“团队”,但很多时候由构架师、需求人员、开发人员和测试人员组成的是一群人而已。他还认为,团队的形成必须经历几个时期。在经历了初期的磨合后,成员才会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩,而且这些规矩是不言而喻的。比如,每个人都知道上午九点来上班,都会主动询问别人是否需要帮助,也都会去主动和别人探讨问题。如果团队成员之间能够达成这样的默契,那么这个团队将成为一个真正高效的工作团队。在这样的团队中,成员之间相互理解,工作效率非常高。在自组织团队中,团队成员不需要遵从别人的详细指令。他们需要更高层次的指导,这种指导更像是一个目标,一个致力于开发出更好的软件的目标。总之,自组织团队是一个自动自发、有着共同目标和工作文化的团队,这样的团队总是在向它的组织做出承诺。但是,实现这些承诺对于自组织团队来说非常重要。否则,一旦出现问题,团队成员之间就会出现信任危机。
      虽然敏捷开发小组是以小组为整体来工作的,但是还是有必要指明一些承担一定任务的角色。第一个角色是产品所有者(Product Owner)。产品所有者的主要职责包括:确认小组所有成员都在追求一个共同的项目前景,确定功能的优先级以便总是在处理最具有价值的功能,以及作出决定使得对项目的投入可以产生良好的回报。可以对应为以前开发中的“产品经理”。另一角色是开发团队(developer),这里的开发人员包括了架构师、设计师、程序员、需求人员、测试人员、文档编写者等,有时产品所有者也可以被看作是开发人员。还有一个重要角色就是项目经理(project manager)。敏捷开发的项目经理会更多的关注领导而不是管理。在某些项目中,项目经理可能同时也是开发人员,少数时候也会担任产品所有者。

      

    12。每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整
      由于很多不确定性因素会导致计划失效,比如项目成员增减、技术应用效果、用户需求的改变、竞争者对我们的影响等都会让我们作出不同的反应。 敏捷不是基于预定义的工作方式,而是基于经验性的方式,对以上这些变化,小组通过不断的反省调整来保持团队的敏捷性。

     

    展开全文
  • 敏捷开发12条原则敏捷开发12原则1。尽早(想到马上动手)、 持续交付 有价值的软件2。开发后期允许需求变更 (引发代码修复)3。经常交付(汇报完成的每个阶段)4。开发期间 业务人员与开发人员一起工作5。围绕...

    敏捷开发12原则

     

    中文翻译版: 
    1。尽早(想到马上动手)、 持续交付 有价值的软件
    2。开发后期允许需求变更 (引发代码修复)
    3。经常交付(汇报完成的每个阶段)
    4。开发期间 业务人员与开发人员一起工作
    5。围绕受激励的个人
    6。团队内最有效的信息传递方式---Face To Face Communication 
    7。用可工作软件恒量进度
    8。可持续开发速度(有领导激励)
    9。不断学习并提高
    10。简洁
    11。好的架构(出于自己的团队)
    12。反省 调整

     

    英文原版:

    One: Action Earlier 、Keeping Give The Value Of Software
    Two:Allow Change Demand At Last Develop (Cause Code Repair)
    The: Exchange Often (Report The Finish Statu)
    Fou: Make a team 
    Fiv: Around Someone Who Was Inspired
    Six: Most Effectual Pass Method Of Mseeage ---Face To Face
    Sev: Enable-software  Constant Schedule
    Eig: Keeping  Pace Of Empolder
    Nig: Learning And Improve
    Ten: Succinctness
    Ele: Well Framework
    Twe: Self-examination  Regulate

     

     

    具体分析如下:

    1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

    规划迭代故事时必须按照优先级安排,为客户先提供最有价值的功能。通过频繁迭代能与客户形成早期的良好合作,及时反馈提高产品质量。敏捷小组关注完成和交付具有用户价值的功能,而不是孤立的任务。以前我们都用需求规格说明书或者用例来编写详细的需求,敏捷使用用户故事来罗列需求。用户故事是一种表示需求的轻量级技术,它没有固定的形式和强制性的语法。但是有一些固定的形式可以用来参考还是比较有益的。敏捷估算中使用了这个模板:“作为【用户的类型】,我希望可以【能力】以便【业务价值】“。使用基于用户故事的需求分析方法时,仍可能需要原型和编写文档,只是工作重点更多的转移到了口头交流。

     

    2.即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

    敏捷过程参与者不怕变化,他们认为改变需求是好事情,因为这些改变意味着我们更了解市场需求。

     

    3.经常性的交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。

    迭代是受实践框限制的,意味着即使放弃一些功能也必须按时结束迭代。只要我们可以保证交付的软件可以很好的工作,那么交付时间越短,我们和客户协作就越紧密,对产品质量就更有益。虽然我们多次迭代,但并不是每次迭代的结果都需要交付给用户,敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些功能,增加的每个功能都是经过编码、测试,达到了可发布的质量标准的。

    另外敏捷开发项目中对开发阶段没有什么重要的分割,没有先期的需求阶段,然后是分析阶段,架构设计阶段,编码测试阶段等,在项目真正开始后,每次迭代中都会同时进行所有的上述阶段工作。

     

    4.在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。

    软件项目不会依照之前设定的计划原路执行,中间对业务的理解、软件的解决方案肯定会存在偏差,所以客户、需求人员、开发人员以及涉众之间必须进行有意义的、频繁 的交互,这样就可以在早期及时的发现并解决问题。

     

    5.围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持,并且信任他们能够完成工作。

    业务和技术是引起不确定的二个主要方面,人是第三个方面。而业务和技术又必须由人来执行,所以能够激励人来解决这些问题是解决不确定性的关键。只要个人的目标和团队的目标一致,我们就需要鼓舞起每个人的积极性,以个人为中心构建项目,提供所需的环境、支持与信任。

     

    6.在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。

    在十几或者二十几个人组成的大团队中,文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人(大团队实施敏捷时也会分成多个小的敏捷团队),所以大量的文档交流其实并不是很经济的做法。此时面对面的交谈反而更快速有效。

     

    7.工作的软件是首要进度度量标准。

    一般的工作都比较容易衡量任务进展,比如让你去搬运1吨的石头,我只要去称一下你已经搬运的石头重量就知道你完成多少了。而对于软件来说,在软件没有编码、测试完成之前,我们都不能因为代码编写了多少行,测试用例跑了多少个就去度量这个功能是否完成了。衡量这个功能是否完成的首要标准就是这个功能可以工作了,对用户来说已经可以应用了。

     

    8.敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

    很多人都认为软件开发中加班是很正常的,不加班反而不正常,我对此有点不理解,这个可能是国情所致吧。敏捷过程希望能够可持续的进行开发,开发速度不会随着迭代的任务不同而不同,不欣赏所谓的拼一拼也能完成的态度,开发工作不应该是突击行为。我们不能指望说突击这个项目后就可以轻松了,因为完成一个项目后会接踵而来下一个项目,而只要还是拼拼的态度,下一个项目依旧会让你的组员再次突击。这时不知道有人会不会说,那我们就一直加班,也是“持续的开发速度”啊,这时可要注意了,持续加班智慧导致人疲劳、厌倦,保持长期恒定的速度也只是一种理想而已。

     

    9.不断地关注优秀的技能和好的设计会增强敏捷能力。

    敏捷过程有很多好的技术实践可以加强产品敏捷能力,很多原则、模式和实践也可以增强敏捷开发能力。 《敏捷软件开发-原则、模式与实践》一书中介绍了很多设计,感兴趣的可以去仔细看看。

     

    10.简单——使未完成的工作最大化的艺术——是根本的。

    我们不可能预期后面需求会如何变化,所以不可能一开始就构建一个完美的架构来适应以后的所有变化。敏捷团队不会去构建明天的软件,而把注意力放在如何通过最简单的方法完成现在需要解决的问题。这时有人会说,我已经预计到了肯定存在哪些需求扩展点,我们在一开始是否需要考虑呢?这时团队需要根据自己的理解去决定是否考虑,如果深信在明天发生了这个问题也可以轻易处理的话,那么就最好先不考虑。

     

    11.最好的构架、需求和设计出自与自组织的团队。

    敏捷中有很多种实践,大家都知道,迭代式开发是主要的实践方法,而自组织团队也是主要的实践之一。在自组织团队中,管理者不再发号施令,而是让团队自身寻找最佳的工作方式来完成工作。要形成一个自组织团队其实比较难。CSDN采访Mishkin Berteig中说到 自组织团队的第一个要素就是必须有一个团队,而不仅仅是一群人。一群人是一帮在一起工作的人,他们彼此之间并没有太多的沟通,他们也并不视彼此为一体。项目一开始,我们就会组建“团队”,但很多时候由构架师、需求人员、开发人员和测试人员组成的是一群人而已。他还认为,团队的形成必须经历几个时期。在经历了初期的磨合后,成员才会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩,而且这些规矩是不言而喻的。比如,每个人都知道上午九点来上班,都会主动询问别人是否需要帮助,也都会去主动和别人探讨问题。如果团队成员之间能够达成这样的默契,那么这个团队将成为一个真正高效的工作团队。在这样的团队中,成员之间相互理解,工作效率非常高。在自组织团队中,团队成员不需要遵从别人的详细指令。他们需要更高层次的指导,这种指导更像是一个目标,一个致力于开发出更好的软件的目标。总之,自组织团队是一个自动自发、有着共同目标和工作文化的团队,这样的团队总是在向它的组织做出承诺。但是,实现这些承诺对于自组织团队来说非常重要。否则,一旦出现问题,团队成员之间就会出现信任危机。

    虽然敏捷开发小组是以小组为整体来工作的,但是还是有必要指明一些承担一定任务的角色。第一个角色是产品所有者(Product Owner)。产品所有者的主要职责包括:确认小组所有成员都在追求一个共同的项目前景,确定功能的优先级以便总是在处理最具有价值的功能,以及作出决定使得对项目的投入可以产生良好的回报。可以对应为以前开发中的“产品经理”。另一角色是开发团队(developer),这里的开发人员包括了架构师、设计师、程序员、需求人员、测试人员、文档编写者等,有时产品所有者也可以被看作是开发人员。还有一个重要角色就是项目经理(project manager)。敏捷开发的项目经理会更多的关注领导而不是管理。在某些项目中,项目经理可能同时也是开发人员,少数时候也会担任产品所有者。

     

    12.每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

    由于很多不确定性因素会导致计划失效,比如项目成员增减、技术应用效果、用户需求的改变、竞争者对我们的影响等都会让我们作出不同的反应。 敏捷不是基于预定义的工作方式,而是基于经验性的方式,对以上这些变化,小组通过不断的反省调整来保持团队的敏捷性。

     

     

    展开全文
  • 【什么是敏捷开发?】资深程序员之路(5)--agile开发 敏捷开发(scrum, agile)相对于瀑布流开发(waterfull)更适合现在快节奏的商业模式需求,它将一整个项目拆分为相互独立的小块,我们成为sprint(冲刺),每个...

    【什么是敏捷开发?】资深程序员之路(5)--agile开发
    敏捷开发(scrum, agile)相对于瀑布流开发(waterfull)更适合现在快节奏的商业模式需求,它将一整个项目拆分为相互独立的小块,我们成为sprint(冲刺),每个sprint都包含前期的需求分析,开发测试,客户演示和demo优化,UAT,如下图。

    好处:随时保持和客户的交互(双向反馈),确保开发更符合客户实际业务需求。


    【敏捷开发的4大核心价值观?】The Four Values of The Agile Manifesto
    1. Individuals and Interactions Over Processes and Tools

    以人为中心,强调团体(内部团队+外部客户)沟通协作

    2. Working Software Over Comprehensive Documentation

    传统的项目管理大量时间被消耗在记录产品开发和最终交付,如技术规范、技术要求、技术说明文档、接口设计文档、测试用例文档等拖延了项目交付时间,敏捷不排除文档,它借助User Story敏捷文档需求结合敏捷工作软件使形式更精简,这给开发者明确的工作任务而非陷入细节。

    3. Customer Collaboration Over Contract Negotiation

    客户参与开发过程,包括需求的进一步确认、细节的进一步拟合、定期的演示,能确保产品极大程度地满足客户的业务需求。

     

    4. Responding to Change Over Following a Plan
    传统的项目管理重计划,并将中途客户提出的需求变更视为一种支出,对于大型项目,如果有需求变更需要依据ITIL规范提出变更并经过需求变更委员会审批后(重估成本和IT预算)才能实施;而敏捷开发拥抱变化,并认为变更总是改善项目,为客户提供额外的价值。

    【敏捷开发的12条原则?】敏捷开发之 12条敏捷原则 | 周金根博客

    1. Customer satisfaction through early and continuous software delivery

     

    2. Accommodate changing requirements throughout the development process

    3. Frequent delivery of working software

    4. Collaboration between the business stakeholders and developers throughout the project

    5. Support, trust, and motivate the people involved

    6. Enable face-to-face interactions

    7. Working software is the primary measure of progress

    8. Agile processes to support a consistent development pace

    9. Attention to technical detail and design enhances agility

    10. Simplicity

    11. Self-organizing teams encourage great architectures, requirements, and designs

    12. Regular reflections on how to become more effective

    【敏捷开发的框架的核心概念?】敏捷项目管理流程-Scrum框架最全总结
    1. User Stories
    End User关于产品的要求,常用如下格式表示一个完整的User Story:

    As a/an role, I want/need(features), so that(benefits).
    通常,在收集user story的同时,会要求客户注明可接受条件(acceptance criterias),作为软件实施的Basic Requirement/MVP(Most viable product)。

    2. Product Backlogs - 产品待办项(未完成项/存量)

    The collection of all user stories, we called product backlogs.

    3. Realeas List<Backlogs>

    从Product Backlogs挑出需要实施的User,并按照优先级Must/Should/Could/Won't排序,并规定每个task需要完成的时间,如:1hr/2hrs/4hrs/8hrs | 2ds/3ds/5ds/10ds | 1m/2ms/3ms/6ms.

    3. Team Roles
    将scrum的roles分为三个层次:
    Product Owner: 将正确的功能放入Product Backlogs的人。
    Scrum Master: 相当于项目经理,需要确保项目进度,协调客户与团队并主持scrum daily meetings等。

    Team: include developers, testers, customers, executives.

    4. Sprints

    指Realease Planning,一般一个Sprint周期为2d-1m。

    5. Burndown Charts (燃尽图)

     

     

     

    展开全文
  • 敏捷开发12条原则

    2017-03-14 20:10:09
    我们遵循以下原则: We follow these principles: 1.我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。 Our highest priority is to satisfy the customer through early and ...
  • 敏捷开发12条原则 敏捷开发的核心原则之一是在每个sprint结束时交付可用的软件。 团队可以通过定义可靠的用户故事接受标准 ,以团队形式致力于冲刺, 自动化测试 ,演示冲刺结果以及成熟其他实践以确保代码完整并...
  • 敏捷开发宣言《敏捷宣言》我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观:个体与交互 重于 过程和工具 可用的软件 重于 完备的文档 客户协作 重于 ...敏捷开发十...
  • 敏捷开发12原则

    2018-07-25 17:08:27
    2-欢迎对需求提出变更 - 即使在项目开发后期,要善于利用需求变更,帮助客户获得竞争优势; 3-要不断交付可用的软件,周期从几周到几个月不等,越短越好 4-项目过程中,业务人员与开发人员必须在一起 5-要善于...
  • 敏捷开发原则及方法

    2020-03-10 11:46:37
    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。...敏捷开发原则包括: ①最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 ②即使到了开发的后期,也欢迎改变需求。敏捷过...
  • 敏捷软件开发原则、模式与实践(全) 敏捷软件开发原则、模式与实践(全) 敏捷软件开发原则、模式与实践(全) 敏捷软件开发原则、模式与实践(全) 敏捷软件开发原则、模式与实践(全)
  • 敏捷软件开发原则、模式与实践(全) 敏捷软件开发原则、模式与实践(全)
  • 前段时间出了中文版的敏捷宣言和敏捷原则,于是来跟下风,按照自己的认识和理解,也来翻译下敏捷软件开发遵循的原则。 我们最优先做的工作是通过尽早地、持续地交付有价值的软件来使客户满意; 即使到了开发的...
  • 敏捷开发原则

    2019-06-26 03:43:41
    即使到了开发的后期也欢迎改变需求敏捷过程,利用变化来为客户创造竞争优势。 原则三 经常性的交付,可以工作的软件交付的间隔可以从几周到几月交付的时间间隔越短越好。 原则四 在整个项目开发期间业务人员和开发...
  • 敏捷开发过程中必须遵循的原则 1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 初期交付的系统中所包含的功能越少,最终交付的系统的质量就越高。--构建高质量产品。 2.即使到了开发...
  • 曾担任C++ Report杂志主编多年,也是设计模式和敏捷开发运动的主要倡导者之一。 Micah Martin Robert C. Martin之子,也是经验丰富的软件工程师,曾任Object Mentor公司的咨询师,现任8th Light公司总裁。擅长.NET、...
  • 2019独角兽企业重金招聘Python工程师标准>>> ...
1 2 3 4 5 ... 20
收藏数 39,238
精华内容 15,695