敏捷开发学习理解_ios开发中如何理解敏捷性开发 - CSDN
  • 敏捷开发学习心得

    2014-02-15 22:03:03
    过年放假这几天读了一些敏捷开发方面的书籍,基于自己对敏捷开发理解总结出以下几点。本文内容还会进一步整理,暂时先贴出来,权当作是一份备忘吧。也希望对阅读过本文章的挨踢人有些许启发,如果能留言进行进一步...

    过年放假这几天读了一些敏捷开发方面的书籍,基于自己对敏捷开发的理解总结出以下几点。本文内容还会进一步整理,暂时先贴出来,权当作是一份备忘吧。也希望对阅读过本文章的挨踢人有些许启发,如果能留言进行进一步的讨论交流就再好不过了。


    我认为敏捷开发应该围绕如下几点进行:

    1、出了现了一个问题或发现了一个bug,第一重要的事情不应该是想办法确定这个问题是谁造成的,而是应该试图去想办法解决这个问题。因为去争论这个问题是谁造成的没有任何意义,有意义的是如何去解决,让系统能正常的工作起来。

    2、发现一个bug,并且时间紧迫,如果不去了解真正的原因就进行快速修复确实能解决它(在最后添加一行代码或者是对结果进行简单的偏移运算)。但是要知道,千里之堤毁于蚁穴,这样的修复日积月累下来就会使项目代码变得凌乱且晦涩难懂。如果在这样的项目之上添加新功能或者进行其他的改动,将会很难下手。所以,未雨绸缪。建议不要孤立的进行编码,要经常阅读团队中别人写的代码(包括单元测试)。自己要对每个功能写好单元测试,写单元测试能帮助代码进行分层,方便别人阅读与理解。这样,不管是你在修改别人的bug还是别人修改你的bug,会相应的顺手一下。这样坚持下去,即可最大限度的保持项目的保持整洁与清晰。

    3、在设计或者代码中遇到了奇怪的问题,应该花时间去理解代码为什么会是这样的。如果找到了解决方法,但是代码仍然不好理解,那么就鼓起勇气去重构它,使它变得容易理解。如果没有马上理解那段代码,就不要轻易的否定和重写它。那不是勇气,那是鲁莽。

    4、养成立会的习惯。顾名思义,立会即站立着开会,参与者不允许在会议中就坐,这样能保证会议的快速进行。因为一个人坐下之后,会由于感到舒适而使会议持续更长的时间。立会可以在每天十点准时举行,每人发言时间控制在三分钟内,会议内容围绕昨天有哪些收获、今天准备做什么、当前面临着怎样的障碍这三个方面来进行叙述。各项问题不进行深入讨论,防止延长会议时间。如果有深入的必要,可以在会后进行。这样的立会可以让团队成员达成共识,并能保证会议短小精悍不跑题。

    5、要寻找深藏不露的程序bug,进行正式的代码复查其效果是任何已知形式测试的两倍,而且是移除80%缺陷的唯一已知的方法。代码复查由项目团队中的成员来完成,可采用交换复查的方式。代码复查在团队中某一个成员即将提交代码时进行。代码复查内容包括代码能否被读懂和理解、是否有明显的错误、代码的改动是否会对项目其他部分造成影响、是否存在重复的代码、是否存在可以改进和重构的部分。

    6、和客户讨论问题的时候,准备几种可以让客户选择的方案。从业务角度而不是技术角度向客户介绍每种方案的利弊,以及潜在的成本和利益,以及和他们讨论每个选择需要的时间和预算。如果事后他们又想要其他的东西,可以公正的就时间和成本重新进行讨论。

    7、搭建一个演示服务器,每添加一个新的功能或者是对系统进行优化之后,告知客户访问最新的系统。这样系统每一次迭代都能获取客户的反馈意见,这样也基本保证了项目始终是沿着客户的需求进行开发的。保持项目随时可发布很重要。

    8、很多项目都是因为程序代码失控而陷入困境。修复一个bug导致更多的bug,从而又导致了更多的bug修复。这时我们需要一个频繁的反馈,虽然可能不会使代码更好。但是也不会使代码变坏,至少还是像昨天那样可以运行。此处,使用单元测试就是一个非常不错的选择。单元测试应该在增删改某个功能的时候来运行,至少应该在提交代码的时候运行。单元测试中用来测试的数据应该包含边缘数据(比如11:59:59,0:00:00都是比较好的边缘测试数据),并不能放过任何一个失败的测试。

    9、建议采用先测试再实现的方式进行开发,也就是“测试驱动开发”。总是在有一个失败的单元的测试后才开始编码,测试总是先于代码编写。通常这种测试失败的原因是测试的方法不存在或者是方法的逻辑还不足以让测试通过。先写测试,就会站在用户的角度来思考,而不仅仅是一个单纯的实现者。这样做和先编写后测试有很大的区别,你会发现因为自己要使用它们所以才设计了他们。这种方式能让接口的设计更有效。除此之外,还有助于消除过于复杂的设计,可以专注于真正需要完成的工作。

    10、并不意味着单元测试在自己的机器上能运行,就一定能在其他的机器上能运行。不同的环境可能会有不同的结果。这个和操作系统环境有关,甚至可能和硬件环境有关。

    11、在系统开发中辛苦的编写单元测试用来获取代码的反馈,却往往容易忽视了最终用户的反馈。不仅需要和真实的用户进行交谈,还需要耐心的倾听。即使他们说的内容是一些让你觉得非常直观,非常简单的问题。因为每一个用户的抱怨背后都隐藏了一个事实,我们要做的是找出真相,修复真正的问题,而不是对用户发出嘲笑。

    12、用户在使用系统的过程中如果出现什么错误,不要只是简单的弹出一个错误对话框。应该告知用户发生了什么错误,方便用户进行有效的反馈。如果出于保护代码底层的原因不想让用户知道具体的错误信息,也可以在系统后台给技术支持人员发送一份问题的详尽错误报告。

    13、编写能够清晰表达意图的代码,这样的代码清晰易懂,仅凭小聪明写的那些晦涩难懂的程序很难维护。注释虽然能帮助理解,但是有可能会对理解造成干扰。其实,这里也不是说注释不用写,只是不能让别人完全通过注释才能理解所写的代码。最好是采用规范的命名、清晰的流程、简单的编码等方式来达到代码既是注释的效果。

    14、在代码编写或项目开发的时候应使用增量式的开发方法,即每完成一个功能或者方法的时候确保其对应的单元测试能正确通过。这样,在编码的过程中也能实时不断地获取来自代码的反馈。提交代码之前需要保证所有的单元测试能完全通过。

    15、应具有一个自动化测试环境,每天固定的时间开始从svn检出最新版本的源代码进行单元测试。测试完成之后会生成一份测试报表。这样,每天早上就能获取一份关于最新代码的测试报告。时刻了解项目目前的状况。

    16、编写具有内聚的代码,做到一个方法只做一件事情,一个类只包含他自己所应该包含的方法,一个包只包含应有的模块。这样有利于维护。但是内聚的颗粒不能太粗也不能太细,要拿捏的恰到好处。这样有助于对代码的理解,也降低了项目维护的难度。举个例子:当需去储物室寻找一台电脑的时候,打开们一看,里面乱七八糟的什么都有,后来费了很大的气力才把电脑找出来,这就属于颗粒太粗,没有分好类;当需要去储物室寻找一台电脑,打开门一看,里面大大小小的箱子盒子收拾的井井有条,一眼就看见了一个盒子上面写的电脑二字,打开盒子一看,里面是内存、CPU、硬盘、主板……这属于颗粒太细,虽然得到了自己想要的东西,但是不能马上用,还需要自己组装之后才可正常使用。

    展开全文
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。

    随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。

    背景

    我们公司引入敏捷开发的时间并不长,在实施敏捷的过程还存在一些问题,自己在实施敏捷的过程也存在很多的疑惑(毕竟原来没有学过,和真实的经历,体会),所以最近一直在学习敏捷,看敏捷的视频和阅读相关资料,同时结合自己实施敏捷的经验,通过分享博文进行一下简单的总结,目的有四:
    1. 详细的介绍和学习一下敏捷开发
    2. 和CSDN的大牛们一起分享交流,学习,提高一下
    3. 总结实施敏捷过程中的问题,不断反思,不断提高
    4. 最后,希望对不了敏捷的朋友有一定的帮助

    什么是敏捷开发

    敏捷开发(Agile Development)不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。

    怎么理解呢?

    • 首先,敏捷并不是一门具体的技术,而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。

    • 其次,敏捷开发都具有以下共同的特征:

      1. 迭代式开发
      2. 增量交付
      3. 开发团队和用户反馈推动产品开发
      4. 持续集成
      5. 开发团队自我管理
    • 最后,相比于“传统”的瀑布开发模式,敏捷开发是一种“现代”的开发模式。

    具体方式

    上面说了敏捷是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而具体的开发方式有哪些呢?

    Scrum,极限编程(XP)精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。

    除了Scrum和XP,对于上面的其他开发方式,我也只是简单了解,大家可以多查查相关的资料。

    我们可以简单的对比一下Scrum和XP:
    1. 在开发的过程中,你可以采用Scrum方式也可以采用XP方式;
    2. Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的。

    敏捷开发宣言

    《敏捷宣言》

    我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观:

    个体与交互 重于 过程和工具
    可用的软件 重于 完备的文档
    客户协作 重于 合同谈判
    响应变化 重于 遵循计划

    在每对比对中,后者并非全无价值,但我们更看重前者

    敏捷宣言是对敏捷的高度总结和升华,即使现在不理解也没有问题,在实践的过程中我们会逐渐对它有一个深刻的认识。

    敏捷开发十二原则

    在敏捷开发中,我们遵循以下准则:

    1. 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
    2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
    3. 要不断交付可用的软件,周期从几周到几个月不等,且越短越好
    4. 项目过程中,业务人员与开发人员必须在一起工作。
    5. 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
    6. 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
    7. 可用的软件是衡量进度的主要指标。
    8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
    9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
    10. 要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
    11. 最佳的架构、需求和设计出自于自组织的团队。
    12. 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

    敏捷开发宣言比较抽象,但是敏捷开发十二原则就非常具体了,相信用过敏捷的人都知道,上面的十二原则都是开发过程的经验总结。看到十二条原则,一一的对比我们公司在实施敏捷的过程,还存在一些问题,这些问题直接导致了低效率的,不顺畅的敏捷,例如:最后一条,团队要定期反省,这点做的就不好,造成团队的积极性降低,开发效率下降,而且很难作出调整,甚至我开始也是拒绝的,有了这些原则作为指导,我们可以更加从容的实施敏捷。

    敏捷开发十二原则是我们实践的具体指导方针,它可以指导我们实施更加成功的敏捷。当我看到这些内容时,真有一种如饥似渴的感觉,真想一下子都把他们装进我的脑子里。书到用时,方恨少。及时补充自己永远都不晚。

    总结

    敏捷的思想今天算是深入人心了,后面的具体方法就是教会我们如何实施敏捷。有了这些思想,整个世界都开始美好了。

    下篇博文,进入我们的重点简单介绍Scrum以及Scrum的流程,敬请关注。

    展开全文
  • 如何理解敏捷开发

    2019-01-04 16:16:15
    一、什么是敏捷开发敏捷开发,以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 二、敏捷开发的特点 敏捷是以人为中心的软件开发方法,保持简洁的代码,经常性测试以及及时地交付应用的功能...

    一、什么是敏捷开发?

    敏捷开发,以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

    二、敏捷开发的特点

    敏捷是以人为中心的软件开发方法,保持简洁的代码,经常性测试以及及时地交付应用的功能模块。正如敏捷宣言所提到的那样。

    敏捷宣言强调的敏捷软件开发的四大宣言是: 
    1.个体与交互高于流程和工具 
    2·工作软件高于理解文档 
    3·客户协作高于合同协商 
    4·变化响应高于计划遵循 

    结合软件研发实际,四大宣言可以这样理解:

    个体与交互胜过过程与工具

           方法和工具是死的,人是活的,如何没有优秀个人和团队协作,再强大的方法和工具都是摆设。一个使用普通工具的优秀人员会比使用优秀工具的普通人员做得更好,一个具有合作精神、自组织的团队比通过过程规范的团队工作得更好。敏捷中每个成员都需要定时和团队的其他成员一起查看团队的整体进度,计划下一步工作,并一起探讨所遭遇问题的解决方案。自组织团队通过个人能力和协作能力,可以自发的通过各种途径解决开发过程中遇到的问题。

           虽然我们致力于个体和交互,但并不代表就不需要过程与工具了。Scrum、XP等方法本身也有一些方法和过程,每日构造等敏捷实践也需要工具的支持,需要哪些过程和工具由自组织团队制定,而不是由领导制定。

    工作软件高于理解文档 

           在合同中有时会看到分别在需求、设计、开发、测试阶段提供什么文档,支付多少金额等内容,而这些文档对用户来说是不是真的有价值呢?冗长文档对客户来说并不重要,其重要程度比不上一个可以工作的软件。冗长的文档对开发也不重要,没有人有时间去读,而且也不符合敏捷开发的特性,对研发团队来说最好的文档就是代码和团队,通过频繁的提供可以工作的软件,不断地搜集市场反馈,保证软件的市场时效性。

           虽然我们致力于提供可供做的软件,但并不是不要文档。我们在开发过程中仍然需要进行内部交流, 也需要和客户交流,我们仍旧可能需要制作原型,书写一些主要需求和算法,只要可以满足研发团队需求就行。

    客户协作高于合同协商 

           寻求客户合作的价值重于对合同的谈判。软件开发的最终目标是提供给客户满意的软件,而只有客户才更清楚怎么样才能满意,敏捷开发提倡客户和开发团队密切的在一起工作,经常性的根据市场需求对软件提供反馈。各种不同的敏捷方法都会利用短期迭代,通过尽早提供软件来达到与客户频繁沟通和反馈的,这也可以把问题及早暴露出来,以免隐藏的问题在后期造成更大的影响。

           虽然我们致力于客户协作,但为了双方利益和需要仍旧需要进行合同谈判。

    变化响应高于计划遵循  

           敏捷项目承认开发过程中的不确定性,所以不会在开发中制定长时间的复杂计划,它们的成功都是建立在现实反馈的基础上的。每次迭代都是基于上一迭代的完善基础之上进行的,通过不断的响应变化来消除开发中的不确定性。

           在敏捷开发时,我们不应该为了让自己的项目看起来像是按照计划好的样子循序渐进,而花费大量的时间让研发团队去附和计划。相反,敏捷需要的不是计划,而是规划。

           敏捷开发方法是“规划-执行-调整”、“规划-执行-调整”。一个项目的不确定性越高,敏捷开发方法对取得成功就越是至关重要,不断学习和调整是敏捷开发的核心。

           像3355中5会那样,计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理(发生在整个SCRUM周期的任何时间)。阶段性的召开会议,提出当前阶段的问题,根据昨天完成的情况来做出新的调整,根据上一个迭代对新的迭代功能等进行规划。在sprint评审会上,团队除了对当前sprint完成的故事进行show case还需要对剩余的任务卡进行梳理,可以让团队有机会去回顾和识别版本发布的风险。

    敏捷开发的12条原则包括: 
    1.通过早期和连续型的高价值工作交付满足“客户”。 
    2.大工作分成可以迅速完成的较小组成部门。 
    3.识别最好的工作是从自我组织的团队中出现的, 
    4.为积极员工提供他们需要的环境和支持,并相信他们可以完成工作。 
    5.创建可以改善可持续工作的流程。 
    6.维持完整工作的不变的步调。 
    7.欢迎改变的需求,即时是在项目后期。 
    8.在项目期间每天与项目团队和业务所有者开会。 
    9.在定期修正期,让团队反映如何能高效,然后进行相应地行为调整。 
    10.通过完成的工作量计量工作进度。 
    11.不断地追求完善。 
    12.利用调整获得竞争优势。

    大致来讲,12宣言的核心内容就是将一个软件分成多个迭代去完成,在每个迭代开发时,坚持以人为本的原则,在研发过程中坚持人比工具更重要。在研发中坚持完善工作,拥抱市场拥抱变化,根据市场来调整软件的功能。快速变化,高效的做出响应。不断地调整软件,保持市场时效性。

           

           

     

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

    1,提要
    软件开发是一个系统工程,包括最初的可行性分析、再到设计、开发、测试、维护等整个生命周期。在这个过程中某些阶段的失误或说是变化,都可能增加整个软件项目的风险。
    如何在保证效率的基础上还能安计划、保证质量的完成软件项目?于是产生了软件开发的一些方法,这个方法不是指具体有编码阶段的各种设计模式和技巧,而是在整个软件开发策略层面的方法。
    传统瀑布模式和新型的敏捷开发就是其中最常用的方法,后面着重讨论敏捷开发的优缺点和敏捷开发的基础知识。
    2,常用的开发模式
    (1)传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到交付大概这样的流程,要求每一个开发阶段都要做到最好。特别是前期阶段,设计的越完美,提交后的成本损失就越少。下面就是典型的瀑布模型。


    认识敏捷开发
    (3)原型模型,原型化模型第一步就是创建一个快速原型,能够满足项目干系人与未来的用户可以与原型进行交互,再通过与相关干系人进行充分的讨论和分析,最终弄清楚当前系统的需求,进行了充分的了解之后,在原型的基础上开发出用户满意的产品。
    (3)螺旋模型,将瀑布模型和快速原型模型结合,并特别强调项目风险。通常分为四个阶段组成:制定计划、风险分析、实施工程和客户评估。一般第一个原型只是双方交流的参考,随着后面的版本完善,最终达到目标。比较适合大型项目。
    (2)新型的敏捷开发,即迭代式开发,不要求非常完美的需求分析、设计、文档,而是在最短时间内完成一个框架,然后不断迭代,不断测试,直至交付。
    但它并不是不需要文档,不需要从需求、设计、开发、测试这样一个过程,在每个迭代过程中仍然需要做这样的事情。
    但是敏捷开发更加注重人的因素,不像瀑布式开发那样,由专门的需求人员采集用户需求,由设计师完成设计文档。敏捷开发每个人都是需要了解项目的需求,并不断的进行小会议,不断的测试修改,直到提交。
    敏捷开发则是以测试驱动开发,而瀑布式开发是以文档驱动开发。
    下图是Scrum(敏捷开发的一种)敏捷开发模式


    认识敏捷开发
    3,传统开发模式和敏捷开发的优缺点
    主要对比比较常用的瀑布模型和敏捷开发。
    (1)瀑布式开发:
    a.讲求阶段明确,严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一阶段的工作就不展开。 软件生命周期前期造成的Bug的影响比后期的大的多。
    b.特别强调文档,在开发的后期才会看到软件的模样。在这种情况下,文档的重要性仿佛已经超过了代码的重要性。
    c.流水式的开发,瀑布模型把开发人员定义为流水线上的工人。由于各阶段的开发人员只能接触到自己工作范围内的东西,所以对客户需求的理解程度高低不等。对于客户需求变更,编码人员会比设计人员更容易产生很强的抵触情绪。当然好的方面就是按一定规范开发,如果有人员流失,短时间内可以补上去,除了核心的东西有文档参考外,开发过程本身就是在一定框架内的。
    d.进度一目了解,瀑布模型产生的管理文档(计划书,进度表)等,能让不太了解该项目的人也能看懂项目的进度情况(只有能看懂百分比就行),很适合向领导汇报用。所以管理人员比较喜欢瀑布模型,但是开发人员不喜欢,因为它束缚了开发人员的创造性。
    (2)敏捷开发
    a.唯快不破,敏捷即是快之意,不仅思维快节奏,而且行为也是快节奏,因上受到当今快节奏社会的喜爱。
    b.以人为本,和瀑布开发对应的文档为主来说,在敏捷开发中更强调人,在细节开发上个人可以发挥主观性,使用自己善长的技术和模式开发,而非机器式的开发,容易激发团队成员兴趣和创造力。除了项目参与者,人的因素中更考虑到与客户的沟通。每个成员都需要从沟通中,会议交流中,不断实现迭代。
    c.结果第一,不强调文档,突破束缚,软件的最终结果才是重点,文档等都是为软件开发本身服务的,完成了一个优秀的、质量可靠的软件才是敏捷开发的重中之重。
    d.迭代开发,迭代是敏捷开发的核心,不断迭代测试的过程,实际上就是精益求精的过程,正和现在这个社会的工匠精神相吻合。
    e.整合不易,快速迭代,就需要分割整体业务,对于复杂的客户需求,如何兼顾分割与整体,并不容易,这个需要在项目设计之初考虑到。
    4,敏捷开发管理方法
    敏捷开发的管理方法有很多种,比较广泛应用的有XP、Scrum等。既然都是敏捷开发,他们都有共同点,强调高速响应变更、以人为主重视团队成员自身发展,倾向采用迭代式的软件开发生命周期模型。
    敏捷开发中,XP和Scrum的区别:
    a.迭代周期不同,XP的每个Sprint(冲阶)的长度大概为1~2周,而Scrum为2~4周。
    b.迭代周期内专一性不同,XP在一个迭代中,如一个User Story(用户素材,也就是一个用户需求)还未实现,可以考虑另外需求替换,原则是时间当量相等。而Scrum不允许这样,一旦迭代开发会毕,任何需求不允添加进入,并有Master严格把关,使团队不受干扰。
    c.User Story优先级机制不同,XP必须遵守优先级(当然需要先确实优先级),Scrum更灵活,可以不遵循优先级。比如依赖关系中,虽然 US-A高于US-B,但由于要完成A需依赖B,则需要先开发B。
    d.实施中是否采用工程方法问题两者做法不同,Scrum这点上没有工程实践处方,体现的是以人为本,自我创造;而XP必须严格按TDD,自动测试,结对编程,简单设计,重构等约束团队,似乎看起来XP的方式束缚了团队,但需要看这个约束的程度,过细则会让人感觉与“以人为本,自我创新”思想不符,但优点就是一定程度上的规范更有利于保证软件质量。
    一个让人困惑的矛盾, 因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, ...等等”
    通过区别,看出: Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束
    5,总结
    通过了解传统瀑布开发模式和新型敏捷开发模式的差异,理解敏捷开发的在现在快节奏时代有更好的适用性:唯快不破,以人为本。

    展开全文
  • 笔者正在学习《软件工程-实践者的研究方法...敏捷可以应用于任何一个软件过程(沟通、策划、建模、构建和部署),过程的设计应该使项目团队适应于任务,并且使任务流水线化,在了解敏捷开发方法的流动性的前提下进行...

    笔者正在学习《软件工程-实践者的研究方法》这本书,记录下一些读书笔记,共勉!

    1.敏捷

    市场条件变化十分迅速,客户和最终用户的需求在演变,从业者必须使软件工程工作保持敏捷,要限定过程应是灵活机动的、有适应能力的和精益的以适应现代商务的需求。
    敏捷可以应用于任何一个软件过程(沟通、策划、建模、构建和部署),过程的设计应该使项目团队适应于任务,并且使任务流水线化,在了解敏捷开发方法的流动性的前提下进行计划的制定,消除所有最基本软件产品并精简软件开发过程,强调这样一个增量交付策略:根据具体的产品类型和运行环境,尽可能快地将切实可行的软件交付给用户。
    敏捷过程能够降低变更的成本,因为软件以增量方式发布,而且在增量内部变更能得到较好的控制。

    1.1敏捷原则

    (1)我们最优先要做的是通过尽早、持续的交付有价值的软件来使客户满意;
    (2)即使在开发的后期,也欢迎需求变更,敏捷过程利用变更为客户创造竞争优势;
    (3)经常交付可运行软件,交付的时间间隔可以从几个星期到几个月,间隔越短越好;
    (4)在整个项目开发期间,业务人员和开发人员必须天天在一起工作;
    (5)围绕有积极性的个人构建项目,给他们提供所需的环境和支持,并信任他们能够完成工作;
    (6)在团队内部,最富有效果和效率的信息传递方法是面对面交谈;
    (7)可运行软件时进度的首要度量标准;
    (8)敏捷过程提倡可持续的开发速度,责任人、开发者和用户应该能够长期保持稳定的开发速度;
    (9)不断的关注优秀的技能和好的设计会增强敏捷能力;
    (10)简单是必要的;
    (11)最好的架构、需求和设计出自于自组织团队;
    (12)每隔一定时间,团队会反省如何才能更有效的工作,并相应调整自己的行为。

    1.2 人的因素

    敏捷开发关注个人的才智和技巧根据特定人员和团队来塑造过程。要求团队成员及团队本身具备以下一些特点:

    • 基本能力:内在才能和特定的软件技能;
    • 共同目标:团队为完成同一个任务而瞄准同一个目标;
    • 精诚合作:项目组之间、项目内部成员之间精诚合作;
    • 决策能力:具有掌握自身命运的自由;
    • 模糊问题解决能力:不断面对不确定的问题并良好解决;
    • 相互信任和尊重:以形成一个强有力的组织;
    • 自组织:①敏捷团队组织自身以完成工作;②团队组织最能适应当前环境的过程;③团队组织最好的进度安排以按期交付产品。
    1.3 应用最广泛的敏捷过程模型:极限编程 (eXtreme Programming, XP)

    极限编程过程分为策划、设计、编码和测试4个框架活动的规则和实践。

    • 策划:需求获取,使XP团队技术成员理解软件的商业背景,充分感受要求的输出、主要特征和功能。用户的需求产生了多个“故事”,每个“故事”根据优先级有权值。用户可以随时增加、修改故事和故事的权值。
    • 设计:XP设计严格遵守保持简洁的原则;
    • 编码:首先开发用于检测本次增量产品的测试单元,然后编码,最后测试;
    • 测试:“在编码之前简历单元测试是XP方法的关键因素。

    2.理解需求

    理解需求的重要性:“我知道你认为你理解我说的是什么,但是你并不理解的是:我所说的并不是我想要的

    2.1 需求工程 (Requirement Engineering,RE)

    需求工程指致力于不断理解需求的大量任务和技术。需求工程通过执行7个不同的活动来实现:起始、导出、精化、协商、规格说明、确认和管理。

    • 起始:项目起始阶段中,要建立基本的理解,包括对问题、谁需要解决方案、所期望解决方案的性质、与项目利益相关者和开发人员之间达成初步交流合作的效果。
    • 导出:询问客户、用于和其他人,系统和产品的目标是什么、想要实现什么、系统和产品是如何满足业务要求、最终系统是如何用于日常工作;
    • 精化:将起始和导出阶段的信息进行扩展和提炼,开发一个精确的需求模型,用以说明软件的功能、特征和信息的各个方面。
    • 协商:解决客户过高需求与有限业务资源冲突的过程,让客户、用户和其他利益相关者对各自需求排序,按优先级讨论冲突;
    • 规格说明:基于计算机的系统和软件的环境下,属于规格说明对不同的人有不同的含义。一个规格说明可能是一个说明文档、图形化的模型、形式化的数学模型、一组使用场景 、一个原型或上述任意组合。
    • 确认:对需求工程的产品进行评估,检查规格说明,保证无歧义的说明的所有的系统需求、已检测出不一致性并得到纠正、工作产品符合过程、项目和产品建立的标准。
    • 需求管理:用于帮助项目组在项目进展中标识、控制和跟踪需求以及需求变更的一组活动。

    建立规格说明的大纲:
    目录
    版本历史

    1 导言
    1.1 目的
    1.2 文档约定
    1.3 适用人群和阅读建议
    1.4 项目范围
    1.5 参考文献
    2 总体描述
    2.1 产品愿景
    2.2 产品特性
    2.3 用户类型和特征
    2.4 操作环境
    2.5 设计和实现约束
    2.6 用户文档
    2.7 假设和依赖
    3 系统特性
    3.1 系统特性1
    3.2 系统特性2 ……
    4 外部接口需求
    4.1 用户接口
    4.2 硬件接口
    4.3 软件接口
    4.4 通信接口
    5 其他非功能性需求
    5.1 性能需求
    5.2 安全需求
    5.3 保密需求
    5.4 软件质量属性
    6 其他需求
    附录A: 术语表
    附录B: 分析模型
    附录C: 问题列表


    2.2 建立根基

    起始阶段,首先需要确认该项目的利益相关者(直接或间接从正在开发的系统中获益的人),如业务运行管理人员、产品管理人员、市场销售人员、内部和外部客户、最终用户、顾问等。需求工程师应创建一个人员列表。不同的利益相关者提出的需求可能是重复的、矛盾的或者有某种关联的,因此需求工程师的下一步工作是将利益相关者提出的需求进行分类整理。第三步是根据需求的分类和目标,确定在利益相关者之间要团结协作,并与软件工程人员紧密协作。这一步需求工程师需要划分利益相关者和开发人员的职责、标识公共区域(都同意的需求)和矛盾区域。

    2.3 导出需求

    利益相关者和开发团队应该共同完成:确认问题,提供建议,商讨解决方法。

    • 协作收集需求:首先为明确问题并提出解决方案,需要由软件工程师和利益相关者共同参与讨论会议,明确项目的各方面需求、约束列表、性能标准等,尽可能收集需求,并将需求分类整理。
    • 质量功能部署(Quality Function Deployment,QFD):是一种将客户要求转化成软件技术需求的质量管理技术。在此过程中,QFD确认三类需求:正常需求(开会时客户确定的需求)、期望需求(隐含在产品或系统中,但客户没有显式说明,但缺少这些将导致用户不满,如人机交互的容易性、安装的简易性)和令人兴奋的需求(客户期望之外的特点,实现这些将使客户非常满意)。
    • 用户场景:收集需求时,逐步具体化系统功能和特性的整体愿景。
    • 导出工作产品:工作产品包括要求和可行性陈述、系统或产品范围的界限说明、系统技术环境的说明、需求列表、一些使用场景、任何能更好定义需求的原型等。
    2.4 开发用例

    用例讲述了能表达主体场景的故事:最终用户如何在一个特定环境下和系统交互。这个故事可以是叙述性的文本、任务或交互的概要、基于模板的说明或图形表示。用例是从最终用户角度描述了软件或系统。
    撰写用例首先要确定参与者,然后再开发用例。参与者是任何与系统或产品通信的事务,且对系统本身而言参与者是外部的。参与者并不等于系统的最终用户。

    2.5 构建需求模型

    需求模型为基于计算机的系统提供必要的信息、功能和行为域的说明。

    2.6 协商需求

    在多数情况下,让利益相关者以成本和产品投放市场的时间为背景,平衡功能、性能和其他的产品或系统特性。协调的目的是保证所开发的项目计划,在满足利益相关者要求的同时反映软件团队所处真实世界的限制。
    协商需求一般有以下活动:

    • 识别系统或子系统关键的利益相关者;
    • 确认利益相关者“赢”的条件;
    • 就利益相关者“赢”的条件进行协商,以便使其与所有涉及人的一些双赢条件一致。
    2.7 确认需求

    需求模型的每一个元素都已创建后,需要检查一致性、是否有遗漏以及是否有歧义。

    • 每项需求都和系统或产品的整体目标一致吗?
    • 所有的需求都已经在相应的抽象层上说明了吗?
    • 需求是真正必须的,还是另外加上去的,有可能不是系统目标所必须的吗?
    • 每项需求都是有界定并且无歧义的吗?
    • 每项需求是标记了来源吗?
    • 需求之间有冲突的吗?
    • 现实资源环境基础上每项需求都能实现吗?
    • 一旦实现后,是否每项需求都可测试?
    • 需求模型是否恰当反映了将要构建系统的信息、功能和行为?
    • ……

    总结:需求工程的任务是为设计和构建活动建立一个可靠坚固的基础。需求工程发生在于客户沟通活动和为一般的软件过程定义的建模活动过程中。软件团队成员要实施7个不同的需求工程职能:起始、导出、精化、协商、规格说明、确认和管理。

    展开全文
  • 敏捷开发初步了解

    2019-09-02 10:34:44
     笔者也只是一个入行没多久的新手,以下只是笔者自己对于敏捷开发的一些理解,并不全面,如有不同理解/或更深刻的理解可以回复进行互相学习。更深入的理解仍需要长时间实践的沉淀 1. 敏捷开发是什么?  敏捷...
  • 转换到敏捷和迭代开发肯定会有很多的疑问,这些疑问通常是公司管理层对敏捷和迭代开发抱怀疑态度,或者没有信心的主要原因,因此,在本文中,我以问答的方式,试图去整理一下自已对敏捷和迭代开发理解,有不对的...
  • 什么是敏捷开发敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。我理解它仅仅是一种开发方法,更是为了应对激烈竞争和快速需求变化的一种价值观和商业模式。敏捷提倡以人为核心,敏捷...
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。 背景 我们公司引入敏捷开发的时间并不长,在实施敏捷的过程还存在一些...
  • 本文以我在工作中的学习与感悟,配合一些实例解读我对敏捷开发理解。 本文更多的是从一名程序员,一名执行者角度去解读。内容难免浅显与直白,我的目的也是在写本文的过程中通过总结与分析进一步升华对敏捷开发的...
  • 敏捷开发思想

    2019-04-12 22:55:16
    敏捷开发思想SCRUM 是什么?敏捷开发是什么?以人为核心是什么意思?迭代 是什么意思?SCRUM 与 敏捷开发思想有什么关系?敏捷开发的模式分类(摘抄至互联网):SCRUM 的工作流程(摘抄至互联网)流程: SCRUM 是什么? ...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发 vs 传统模式

    2015-05-28 22:41:00
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  • 敏捷开发之Scrum扫盲篇 现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP… 为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum...
  • 什么是敏捷开发

    2017-09-19 14:15:00
    现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...   为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,...
  • ThoughtWorks的敏捷开发

    2018-07-23 11:19:45
    敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发既不是Scrum,也不是XP。 造成这个状态的原因,...
  • 一 引言 近来,在BOSS系统团队敏捷开发熏陶和感染下,对敏捷开发求知是蠢蠢欲动. 心动不如行动. 咱也不能被动接受挨打吧. 这几天向战斗在BOSS一线具体参入人员问了卷,实施敏捷开发大哥们们请教. 感觉是个好东西.它是...
  • 敏捷开发之Scrum扫盲篇 现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP... 为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述...
1 2 3 4 5 ... 20
收藏数 35,042
精华内容 14,016
关键字:

敏捷开发学习理解