敏捷开发如何提升个人能力_敏捷开发 敏捷个人 - CSDN
精华内容
参与话题
  • 以前,当讲到我们团队采用敏捷开发进行APP迭代的时候,我会把“敏捷”二字打上引号。但是最近总结、反思、参加TAPD分享会、公司组织的敏捷培训以及系统的学习了敏捷的理论知识后,我觉得应该把这个引号给去掉。 本文...

    以前,当讲到我们团队采用敏捷开发进行APP迭代的时候,我会把“敏捷”二字打上引号。但是最近总结、反思、参加TAPD分享会、公司组织的敏捷培训以及系统的学习了敏捷的理论知识后,我觉得应该把这个引号给去掉。
    本文将从 什么是敏捷、待优化的地方及建议 及 总结 三个方向阐述。

    什么是敏捷,我们敏捷吗?

    个人认为,敏捷的核心就是:“小步快走、迭代优化”
    “小”:指Stroy要小、落地开发的Task要小,要可独立提测。这个APP团队逐步做到了。
    “快”:当落地开发的Task足够小,对于整体工作的评估会更加准确,团队对于需求的考虑会更充分,需求变更的可能性会更小,当开发的兄弟专注于开发的时候,快是水到渠成的结果。这个我们有一定进步,但是没有找到方法去衡量速度。
    “迭代优化”:这个是核心中的核心,一直抱着优化的心态对待迭代制度、对待我们的产品、对待我们的代码。。。我们的迭代由两周优化调整成为三周;我们通过持续沟通,需求变更的频率有所减少;开发基本每个迭代都有优化重构的任务规划落地;晨会效果不是很理想,但一直在调整优化方案。。。经过17及18年的持续优化,我们迭代的可控性、可预期性是有很大进步的,开发对于18年迭代的满意度是比17年更高的(没有跟产品、设计聊过这个话题)。
    综上,我认为我们是在落实敏捷开发的。
    是,并不代表好,实际上我们有很多地方需要提升,且提升空间非常大。其主要原因在于,大家对于敏捷的理论并没有深入系统的学习,对于其背后的本质更没有了解。

    待优化的地方及优化建议

    团队互信、团队负责

    • 问题
      当产品、设计不完善、或者产品、设计发生变更的时候,开发的兄弟往往会抱怨PM、设计师的输出质量差,PM、设计师也会质疑开发的开发效率、开发质量。
    • 目标
      产品、设计有问题的时候,开发应该主动去帮忙完善,提建议,一起提高产品、设计的质量;PM、设计师觉得开发效率低、质量差的时候,需要的是帮忙一起分析,差在哪里,能做什么去帮助开发得到提升。出现问题的时候,没有产品、设计、开发、测试,只有我们。这是我们需要构建的核心文化。
    • 如何做
      任何时候,我们不应该强调 产品、设计、开发、测试,而应该强调 我们,我们一起对这个Story、对这个产品负责。如果违背,可以请喝奶茶、或者罚划一周的船等等

    产品目标及价值

    • 问题
      很多兄弟对于产品的整体规划了解不多,PM团队也没有给出便于查阅的年度规划、季度规划,以及做这个产品、需求的价值到底在哪
    • 目标
      有方便查询的年度规划、季度规划,对于PM、设计师、开发、测试,看到之后,知道自己开发产品价值所在,提升大家的价值感
    • 如何做
      • 持续维护的产品目标及价值文档,重点说明产品、需求价值所在。
      • 对于实现了的产品,持续补充维护产品已经体现出来的价值

    敏捷是适应变化的

    • 问题
      很多人认为,敏捷是适应变化的,那我们在迭代中对于需求变更支持不够好,就是不够“敏捷”,这是对于敏捷的误解,对于变化一词的误解。
    • 目标
      • 明确 “敏捷是适应变化的” 含义:在当前需求确定的情况下,我们快速迭代交付产品,根据用户反馈调整产品、优化产品。进入迭代后是不允许有、也不应该有需求变更的。
      • 三周一个迭代,刚进入迭代的需求,就提需求变更,说明该需求质量还达不到进入开发的阶段,该需求应该被打回,而不应该误解“变化”,要求迭代很好的支持这种“变化”。这种“变化”,会导致极大的资源浪费(会影响后端、Android、iOS、测试等),还会让大家的士气受到影响。我们应该一起努力,在进入迭代前优化、完善这类需求。
    • 如何做
      • 加强敏捷理论学习,明确变化的含义。
      • 团队一起努力,提高各阶段交付物的质量(需求文档、设计稿、开发产品、测试质量)

    需求评审会

    • 问题
      我们现在需求评审会,过分强调这个需求是什么样子的,很少说明需求的价值,而说明需求价值的重要性不亚于说明需求是啥
    • 目标
      需求评审会后,大家对于需求有比较清晰的认识,对于需求的价值非常了解
    • 如何做
      需求评审会要明确两个目标:需求是什么需求价值。这个会上不讨论需求该如何实现类问题。

    晨会

    • 问题
      APP团队开晨会,所有人加在一起,差不多15+,如果有产品、设计师参加,得超过20人,这明显是有问题的。而我这样安排的初衷是,APP业务间基本都有交叉,不希望团队开发资源上出现单点问题。升哥有建议过分 阳光物业 和 社区 两块,但是我觉得不合适。只是在晨会频率上做变化调整,很多问题也确实通过晨会沟通尽早发现、尽早解决了。但始终无法改变效率低下的问题。
    • 目标
      晨会中,每个人需要说明的三个核心问题是:1. 昨天做了什么推进迭代 2. 今天准备做什么去推进迭代 3. 在推进迭代过程中遇到了什么问题。核心是参与晨会的人要对其他人的这三个问题听进去,如果有就给出自己的建议,帮助其他人更好的推进迭代。
    • 如何做
      研究表明,一个人同一时间,最多记住七件事情(后来进一步研究表明是四件),为了达到晨会高效的目的,建议晨会人员在 7-2/7+2,即5-9个人。比如APP迭代,结合结对编程思路,后端2人、Android2人、iOS2人、测试1-2人 组建一个迭代落地小组,每个迭代周期,有两个开发迭代小组,推进二者形成良性竞争。

    迭代速度

    • 问题
      我们通过 小步快走中的 提高了评估的准确性,对整个团队的速度有了一定提高,对于团队按期交付产品有了更好的把控。但是对于如何持续提高团队的迭代速度,持续提高团队迭代产出,是没有衡量标尺的。而Scrum中是采用点数去描述Story/Task的工作量,点数是工作量的一个标准度量单位。通过关注一个团队在一个迭代中能够完成的点数,反应团队的迭代速度。通过持续提高一个团队在一个迭代中完成的点数来提高团队的迭代速度
    • 目标
      • 找到自己团队/小组的标尺:点数
      • 可度量的持续提高团队的迭代速度
    • 如何做
      • 需求池中需求优先级是唯一确定需求开发先后顺序的标准(和老板达成一致,老板需求也要纳入这个需求池)
      • 采用统一标尺 点数(类似长度“米”)来评估需求的点数
      • 信任大家,按优先级主动领取需求,通过晨会跟进落实,经过三、四个迭代,大家就知道咱们团队的速度了
      • 有了度量速度的标尺,持续改进影响速度的点,提高迭代速度

    透明

    • 问题
      在整个团队层面,APP团队在透明度方面做的工作是最多的。每个迭代基本都会给全员发 需求评审会通知、需求启动通知、迭代周总结、迭代总结(一两个迭代发一次)。团队所有成员通过查看邮件,基本可以知道当前迭代的进展情况。
    • 目标
      透明的目的在于大家时刻能知道自己团队当前的状况,增加自主意识。通过透明,不同小组间可以相互促进,持续提高。
    • 如何做
      以PDCA或者Scrum的思路推进工作,并透明化所有相关事项,小组内部实现良性循环,小组间、团队内相互学习、实现良性竞争。所有事项包括但不局限于(所有事项都欢迎任何感兴趣的人查看、参加):
      • 产品年度规划、季度规划
      • 产品预期价值、以上线产品已实现价值
      • 团队技术规划、所有技术分享
      • 团队各种会议

    迭代总结会

    • 问题
      迭代总结会的核心是总结好的经验继续保持,总结问题并落实解决,实现持续优化。APP迭代总结会我们做到了把所有问题拿到台面上讲,但是在落实解决上我们做的不好。
    • 目标
      • 总结好的经验,作为团队文化进行传承
      • 总结问题,并讨论落实方案,在新迭代中落实到位,持续优化迭代
    • 如何做
      • 高效发现问题:下个迭代团队做什么,可以让你效率更高。每个人必须回答。
      • 讨论确定最高优先级的问题,并讨论决定可执行的落实方案,以及落实计划、验收计划
      • 讨论问题,绝对禁止针对个人(老板除外),要针对流程、制度去讨论

    关于团队成员技术成长

    • 问题
      我们有很多“大佬”,但我们的大佬基本都是在某方面业务开发中做得出色或者大家认为其技术比较厉害而被称为大佬的。但是我们有哪些大佬在团队层面去持续帮助其他人提高技术的呢?在营造团队技术氛围上有贡献的呢?把一个人的技术提高一倍所需的时间 远超 把团队的能力提高一倍的时间
    • 目标
      “大佬”们要把自己的一部分精力放在持续提高团队成员水平的事情上,营造越来越浓厚的互助氛围
    • 如何做
      • 持续的、有广度的、有深度的 分享坚持下去
      • 打造持续追求更高、更好的氛围
      • 我们有基于产品的开发团队,如APP、Python业务、Python平台、友邻、装修、公共资源等; 也需要有基于职能的团队,如Android、iOS、H5、Java、Python等。基于产品维度和基于职能维度的团队交流同等重要。

    制度上如何保障

    公司大的制度环境,对于 Scrum 并不是完全合适的,那如何在制度上去保障我们团队落地?明确KPI考察方向、采用OKR。。。这个问题需要大家和HR一起思考,“We are a term”,我们一起去解决!

    总结

    敏捷开发,其实就是PDCA方法在软件开发领域的应用,以期实现高质量、可控、可预测的交付产品。其核心在于一个持续优化的闭环。让我们-主动-迭代优化

    参考

    展开全文
  • 摘要: 文章背景,来自于群内周五晚上的一次头脑风暴式的思维碰撞交流活动。 感谢[ 成都-无痕 ]提供话题,同时...在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可...

    摘要: 文章背景,来自于群内周五晚上的一次头脑风暴式的思维碰撞交流活动。 

    感谢[ 成都-无痕 ]提供话题,同时欢迎大家提供话题。 
    “敏捷开发”或工作效率方面话题。

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

    你如何理解敏捷开发?

    敏捷开发其实讲述的是:如何让自己以及团队成为资本家最高效的机器人。 
    1. 公司有没有采用敏捷开发? 
    有采用敏捷开发,或者概念没有提出来,其实干活当中,任务的分发,
    或版本的不断叠加,就是这样的过程按序的过程。

    2. 敏捷开发有那些明显的优势或劣势? 
    明显的优势是产品的叠加按序进行,有利于构建大型的产品或系统。 
    劣势是对项目监督者或架构师整体项目把控的能力要求较高,
    而且在全球或天朝互联网市场竞争日益白热化的前提下,更改的按序的开发,成为一个奢侈品。 
    很多公司都在不断的试错中摸索着前行,就看谁在碰壁之后转头的速度快而已。

    3. 如何判断前端开发效率低下? 
    出现多次的加班,从客观上定格为效率的低下。 
    因为项目的周期是经过预演或可推算的,如果长期加班,就是预演的失败。
    但大多的时候也是从任务分派到团队的成员完成的先后顺序来判断单个成员的效率。 
    还有前端岗位的特殊性,在不断的频繁的修改或界面主题的变化, 
    一个项目把控着如果把心思着重的侧重于界面或用户体验,那是一个填坑恶梦的开始。

    4. 如何提高前端开发效率,在宏观思维方面有什么技巧,在微观代码方面有什么技巧? 
    决定效率的关键因素还是对js基础知识的掌握或js知识网络的搭建,网络越密排错能力越强,效率则越高。 
    宏观方面个人认为就是多交流,多看别人的实现方法,多观察别人的实现思路,多看别人的源码。 
    微观上可以使用流程图的方式提前梳理思路,有空的时候还在firebug,chrome调试工具上多调试,以期来锻炼逻辑能力。

    5. 更开放思维,工作或生活中有那些提高效率的技巧? 
    个人经验工作中人为的短网,关qq,不开邮件是一个必杀的高效率技巧。 
    生活中效率与成本息息相关,如购买同一个衣服多跑几家店是不错的选择。在众多方案中选择一个是有效率低成本的干法。

    6. 跟上下游合作时如何提高效率?上游:UI,产品,下游:后台开发,测试。 
    在开做之前,理清页面的来处出处,细对页面上每个链接,跟产品或设计确认交互的细节,从那儿载入,从那儿关闭,本窗口弹链接,新窗口弹链接。登录前,登录后。 
    公告是全站的,还是





    本文转自豪情博客园博客,原文链接:http://www.cnblogs.com/jikey/p/4186772.html,如需转载请自行联系原作者

    展开全文
  • IT圈子,改变是生存的必备要素之一。计算机领域一直在改变,从基础框架到计算设备,还有几乎每天都涌现出的新技术,这些要求我们必须持续学习新东西。这里将为您介绍一些技巧,以使您在这从未停止的学习之旅更加轻松...

    IT圈子,改变是生存的必备要素之一。计算机领域一直在改变,从基础框架到计算设备,还有几乎每天都涌现出的新技术,这些要求我们必须持续学习新东西。这里将为您介绍一些技巧,以使您在这从未停止的学习之旅更加轻松。 

    如何选择读物 



    程序员需要的技能改变是如此之快,尤其是那些热点的/快速演变的领域,找到这些领域合适的阅读材料有时不那么容易。几点建议: 

    选一个实际的项目 



    记住这句咒语:“我听见的,我忘了;我看见的,我能想起来;我做过的,我理解”。 

    阅读是有益处的,但要想真正的理解某个编程语言/库或者技术,你只能亲自动手,真正的参与到一个使用这种语言/库/技术的项目中。”完成一个项目并在其中运用到你想学的技能或特性”是一个很具体的可衡量的目标,”学习某种语言/库/技术“则太笼统了。一个清晰的目标有助于你了解你的进展。完成一个项目则会使你获得宝贵的经验,有些甚至可以写到个人简历中。尽一切可能来用构建一个完整的项目的方式来学习,而不是根据阅读得来到东西学习一个范例。 

    绝大多数人都知道实际做项目而获得的经验是很必要的。难处在于怎样找到一个点子来开始一个项目。一些建议: 

    • 你这种新技能能否开发出一个家人或者朋友正需要使用的应用?我有几个小侄子,我发现给他们开发游戏是一个学习XNA/Cocos2D的绝佳方式;我很快还会为他们写一个基于Sprite Kit的游戏。
    • 有没有什么开源项目正在使用你所学的新知识?你会发现贡献模块甚至创建项目给开源社区是一个很好的学习手段。有时从一个已有的项目继续工作比从头开始更加容易。
    • 有没有什么盈利/非盈利组织可能用到基于这种新技能的应用?如果是这样,搞定它不但可以使你学习并开发出一个应用,并还可能获得一个用户群来给你提供大量的反馈。

    教别人的同时学习 



    当我在微软作为布道者,想程序员们宣讲时,我常常撰写入门指南的演讲稿和在线材料。有些,我负责的是一些我很熟悉的领域,但微软拥有如此众多的工具和技术,并不断有新的东西涌现出来,我经常发现自己不得不学习新知识才能完成教程。 

    这也成为了一种非常好的手段来促织我学习新东西,因为教这些东西,你必须搞懂它们。由于你得把这些新东西转化容易理解的内容,传递给你的听众,以此为目标促使你必须有合理的学习手段和方法。Floor Drees,一个澳洲的技术宣讲/布道者说到,“坦诚的说,我觉得教别人的过程能促使自己学的飞快,我鼓励每一个人去培训新人,即使你觉得自己也还只是个新人。” 

    如果你能得到合适的研究和学习资料(幸运的是,在微软我通常能很容易的找到),并有足够的时间和工具去试验一些迷你的项目来得到更深入的理解,并且你很喜欢当一名老师(无论一对一或一对多)或者作者,你也许想要尝试教学的过程中来学习。 

    搞定拦路虎 



    当你的开发技能到了一定水准,你会偶尔遇到拦路虎:一些短时间内搞不定或理不清头绪的问题。 

    这是个好事,真的!如果你从不尝试新东西,那当然会发现已有东西对你来说都毫无挑战,这也意味着你没有真的在“求学”。最好的/有价值的学习经历正是那些拼命搞定某一问题的时光。你极尽所能尝试各种方法并最终找到了解决方案,这就好像你在黑暗中探索,努力拼接出一条成功之路,这种能力在日后也会陪伴着你。 

    在这段探索之路,你需要以下几个技巧: 

    • 找找看,确认是否你自己或者别人已经有一个项目解决了相似的问题
    • 利用好在线开发者论坛。Stack Overflow是你的朋友,他这些年帮我解决了好多的问题。很多开发者社团也维护自己的论坛,确保自己检查过这些站点。

    参加课程 



    很多程序员有这样的机会通过“构建自己的项目/看其他人的项目/教授课程“来学习。但这不是所有人的习惯,有人喜欢在教室里接受传统的课程。幸运的是这些同学也有很多可选的方案。 

    很多学校和社团都提供了对外公开的的编程课。如果你所在的城市有一些技术人员或者黑客交流中心,那么在那通常也有针对他们团体的一些编程指南,有时这是免费的。 

    在有些城市,那有新手入门课堂,在那你可以学习一门语言或一项技术,它通常会有一些密集的课程和上手小实验,这种培训通常持续几天或者几周。如果你有商业上的需求,需要对程序员进行某种企业级工具/技术的培训,例如微软/甲骨文/Java或者SOA/云计算/敏捷开发,那么你可能需要找到某个类似Web Age Solution这样的培训机构来帮助你完成。 

     

    转载于:https://www.cnblogs.com/helenR/p/programmer_tech.html

    展开全文
  • 因此,作为一名程序开发人员,我们更要通过不断的学习来提高自己的技能。 如何选择读物 程序员需要的技能改变是如此之快,尤其是那些热点的/快速演变的领域,找到这些领域合适的阅读材料有时不那么容易。几点...

    这个世界唯一不变的就是变化,IT圈子不外如是。计算机领域一直在改变,从基础框架到计算设备,还有几乎每天都涌现出的新技术。因此,作为一名程序开发人员,我们更要通过不断的学习来提高自己的技能。

    如何选择读物

    程序员需要的技能改变是如此之快,尤其是那些热点的/快速演变的领域,找到这些领域合适的阅读材料有时不那么容易。几点建议:

    利用好关注该类技术的那些网站。比如,在我学习iOS的过程中,我一直关注 RayWenderlish.com 和iOSDeveloperTips.com,它们都有定期较新的内容发布。

    如果你是想找些书籍,请尽量选择电子书而不是纸质书,编程是一个变革飞快的行业,除非是Knuth的《计算机程序设计艺术》,很多书几个月就过时了。

    选一个实际的项目

    记住这句咒语:“我听见的,我忘了;我看见的,我能想起来;我做过的,我理解”。

    阅 读是有益处的,但要想真正的理解某个编程语言/库或者技术,你只能亲自动手,真正的参与到一个使用这种语言/库/技术的项目中。”完成一个项目并在其中运 用到你想学的技能或特性”是一个很具体的可衡量的目标,”学习某种语言/库/技术“则太笼统了。一个清晰的目标有助于你了解你的进展。完成一个项目则会使 你获得宝贵的经验,有些甚至可以写到个人简历中。尽一切可能来用构建一个完整的项目的方式来学习,而不是根据阅读得来到东西学习一个范例。

    绝大多数人都知道实际做项目而获得的经验是很必要的。难处在于怎样找到一个点子来开始一个项目。一些建议:

    你这种新技能能否开发出一个家人或者朋友正需要使用的应用?我有几个小侄子,我发现给他们开发游戏是一个学习XNA/Cocos2D的绝佳方式;我很快还会为他们写一个基于Sprite Kit的游戏。

    有没有什么开源项目正在使用你所学的新知识?你会发现贡献模块甚至创建项目给开源社区是一个很好的学习手段。有时从一个已有的项目继续工作比从头开始更加容易。

    有没有什么盈利/非盈利组织可能用到基于这种新技能的应用?如果是这样,搞定它不但可以使你学习并开发出一个应用,并还可能获得一个用户群来给你提供大量的反馈。

    教别人的同时学习

    当我在微软作为布道者,想程序员们宣讲时,我常常撰写入门指南的演讲稿和在线材料。有些,我负责的是一些我很熟悉的领域,但微软拥有如此众多的工具和技术,并不断有新的东西涌现出来,我经常发现自己不得不学习新知识才能完成教程。

    这 也成为了一种非常好的手段来促织我学习新东西,因为教这些东西,你必须搞懂它们。由于你得把这些新东西转化容易理解的内容,传递给你的听众,以此为目标促 使你必须有合理的学习手段和方法。Floor Drees,一个澳洲的技术宣讲/布道者说到,“坦诚的说,我觉得教别人的过程能促使自己学的飞快,我鼓励每一个人去培训新人,即使你觉得自己也还只是个 新人。”

    如果你能得到合适的研究和学习资料(幸运的是,在微软我通常能很容易的找到),并有足够的时间和工具去试验一些迷你的项目来得到更深入的理解,并且你很喜欢当一名老师(无论一对一或一对多)或者作者,你也许想要尝试教学的过程中来学习。

    搞定拦路虎

    当你的开发技能到了一定水准,你会偶尔遇到拦路虎:一些短时间内搞不定或理不清头绪的问题。

    这 是个好事,真的!如果你从不尝试新东西,那当然会发现已有东西对你来说都毫无挑战,这也意味着你没有真的在“求学”。最好的/有价值的学习经历正是那些拼 命搞定某一问题的时光。你极尽所能尝试各种方法并最终找到了解决方案,这就好像你在黑暗中探索,努力拼接出一条成功之路,这种能力在日后也会陪伴着你。

    在这段探索之路,你需要以下几个技巧:

    找找看,确认是否你自己或者别人已经有一个项目解决了相似的问题

    利用好在线开发者论坛。Stack Overflow是你的朋友,他这些年帮我解决了好多的问题。很多开发者社团也维护自己的论坛,确保自己检查过这些站点。

    参加课程

    很多程序员有这样的机会通过“构建自己的项目/看其他人的项目/教授课程“来学习。但这不是所有人的习惯,有人喜欢在教室里接受传统的课程。幸运的是这些同学也有很多可选的方案。

    很多学校和社团都提供了对外公开的的编程课。如果你所在的城市有一些技术人员或者黑客交流中心,那么在那通常也有针对他们团体的一些编程指南,有时这是免费的。

    在 有些城市,那有新手入门课堂,在那你可以学习一门语言或一项技术,它通常会有一些密集的课程和上手小实验,这种培训通常持续几天或者几周。如果你有商业上 的需求,需要对程序员进行某种企业级工具/技术的培训,例如微软/甲骨文/Java或者SOA/云计算/敏捷开发,那么你可能需要找到某个类似Web Age Solution这样的培训机构来帮助你完成。

    推荐阅读

    程序员未来发展三大方向

    20年资深程序员编程经验分享

    展开全文
  • 因此,作为一名程序开发人员,我们更要通过不断的学习来提高自己的技能。 如何选择读物 程序员需要的技能改变是如此之快,尤其是那些热点的/快速演变的领域,找到这些领域合适的阅读材料有时不那么容易。几点...
  • 敏捷开发流程总结

    万次阅读 多人点赞 2010-07-20 15:36:00
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以...
  • 敏捷开发知识体系笔记

    万次阅读 2015-11-06 10:08:55
    敏捷开发知识体系整体框架敏捷开发工程实践项目管理 迭代开发 风险价值生命周期 多级项目规划 完整团队 每日站立会议 任务板 燃尽图 需求管理 需求订单 业务流程草图 用例驱动开发 用户故事 架构 演进的架构 演进的...
  • 敏捷开发 vs 传统模式

    万次阅读 2015-05-28 22:41:00
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发的理解及其可行性分析

    千次阅读 2013-08-28 00:09:02
    我对敏捷开发的一些理解及其可行性分析。
  • 关于个人能力提升

    千次阅读 2019-05-20 08:45:20
    随着软件开发行业的发展逐渐成熟和人才的不断补充,个人提升的瓶颈不再仅仅关注技术,需要有意识的全面提升。 起码超过80%的人注定并没有机会专攻技术路线,因此可能工作5年会达到职业瓶颈,有机会的情况下,要有...
  • 什么是敏捷开发和瀑布开发

    万次阅读 2017-01-13 15:48:44
    敏捷开发(AD:Agile Development )以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可...
  • 这是敏捷开发一千零一问系列的第十四篇。(在这里提问,之一,之二,之三,问题总目录)正逢周末,又是愚人节,群中有人正在加班,想起上次培训中间休息的时候,讨论起这个“敏捷开发加班吗”的问题,虽然后来没有...
  • 敏捷开发的核心思想

    千次阅读 2015-10-12 10:39:08
    结合我们公司的开发经验来看,我个人觉得敏捷开发主要包括几个步骤: 需求制定——》需求分析——》设计编码——》测试、功能验证——》发布版本——》下一个周期 1、需求制定:需求方根据上一个版本,提出的新...
  • 说一下你对敏捷开发的理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,顾名思义,可以通俗...
  • 敏捷个人敏捷开发

    2018-07-15 10:19:21
    转载:https://yq.aliyun.com/articles/408737自2001初成立了敏捷联盟到现在10年的推广,敏捷开发已日渐成为当前IT行业软件开 发的一种主流方法。没有银弹,任何方法都不可能解决所有问题,反而方法应用本身还会带来...
  • 敏捷开发之PO

    千次阅读 2016-07-26 07:55:43
    讲到敏捷开发,那么在每个team里面,都会有一个叫做PO(project owner)的角色.在敏捷开发中,PO这个角色扮演了很关键的作用。首先讲讲PO都会干些什么: 1 PO是开发team与客户之间的桥梁,他负责与客户沟通,并且...
  • 敏捷开发 宣言 思想 认识误区

    千次阅读 2014-12-11 14:16:54
    一个是敏捷开发的宣言 另一篇是稍微具体的方法
  • ThoughtWorks的敏捷开发

    千次阅读 2018-07-23 11:19:45
    ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发...
  • 这是张典型的敏捷开发中 Product Owner 的示意图。 这张图往往使人陷入一场争论: 是领域专家,还是架构师, 来担任 Product Owner? 其实, 争论这个问题, 基本上是只考虑了 “敏捷开发中 Product Owner 的定义”,而...
1 2 3 4 5 ... 20
收藏数 32,245
精华内容 12,898
关键字:

敏捷开发如何提升个人能力