敏捷开发实践_c#敏捷开发实践 - CSDN
  • 敏捷开发实践(一)--谈谈我对敏捷开发的理解

    万次阅读 热门讨论 2015-05-31 09:58:51
    随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习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的流程,敬请关注。

    展开全文
  • 敏捷开发实践总结

    千次阅读 2017-12-03 20:21:15
    敏捷开发实践总结 前言 敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和...
    敏捷开发实践总结

    前言
    敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

    什么叫敏捷开发?
    敏捷开发(Agile Development)是一种以人为核心迭代循序渐进的软件开发方法。敏捷开发作为CMM神话崩溃后被引入的一套新的软件开发模式。

    对概念的理解:
    以人为核心:敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。而瀑布开发模型,它是以文档为驱动的,整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据。
    迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

    敏捷开发的4句宣言
    1,个体与交互 胜过 过程与工具
    2,可以工作的软件 胜过 面面俱到的文挡
    3,客户协作 胜过 合同谈判
    4,响应变化 胜过 遵循计划

    我对这4句宣言的理解:
    产品结果大于形式,先把产品做出来,然后再整理出完善的文档
    在互联网软件产品开发过程中,需求是不断发生变化的,需要对原有的计划及时更改,应对变化。

    为什么要使用敏捷开发模式?
    敏捷开发注重人与人之间的交流和合作,可以快速实现功能,以小步快跑的形式,不断试错,不断调整方向,不断完善产品。总结起来就是:适应变化,不断迭代。

    scrum流程图:


    scrum 开发中的三种角色:
    1,product owner:产品负责人,确定大家要做什么(一般产品经理)。
    2,scrum master:scrum的推动者,掌握大节奏的人。
    3,team:一般由多个developer组成,开发的主力。

    scrum 开发中的三大神器
    1,production backlog(产品待办事项列表)
    2,print backblog(详细任务列表)
    3,sprint burn down(计划走向和实际走向组成燃尽图)

    scrum 开发中的四个会议:
    1,sprint计划会(理解需要做什么,然后讨论怎么做)
    2,每日站会(昨天做了什么,今天打算做什么)
    3,sprint 评审会(大家评审sprint产出,然后对待办事项做相应调整)
    4, sprint回顾会(讨论哪里完成好,哪里需要改进)

    SCRUM敏捷开发流程是什么?

    1、Product Backlog(产品需求列表)我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;
    2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;
    3、Sprint Planning Meeting(Sprint计划会议)有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;
    4、Sprint Backlog(迭代任务列表) Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);
    5、Daily Scrum Meeting(每日站立会议)在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);
    6、Daily Build(每日集成) 做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;
    7、Srpint Review Meeting(评审演示会议) 当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);
    8、Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;
    9,重构 因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。
    10,TDD(测试驱动开发)。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。

    下面是crum开发流程中的一些场景图:
    上图是一个 Product Backlog 的示例,产品需求列表

    上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。

    上图就是任务看板了,任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)。

    作为客户端开发人员在实际的迭代开发过程中,有以下感想和总结:
    1,每日的站会迫使人去对昨天的工作做一个小总结和今天的工作计划,无形中让让人做事更加的积极
    2,及时是敏捷开发,也要尽可能的有详细的需求
    3,在实际的开发过程中也需要写api文档,并且尽可能写上注释,以便于其他人的理解
    4,严格按照开发流程去走,但不要流于形式,否则就是浪费时间
    5,坚决杜绝以下问题的出现:
    需求拍脑袋随意改动,叫快速试错迅速响应用户需求;
    代码质量低劣不停出更新版本,叫快速迭代中;
    不写正规设计文档,叫降低沟通成本和最好的文档是代码;
    领导站身后指挥码农写代码,叫结对编程;
    产品质量不靠设计靠测试的,叫测试驱动研发;


    参考:


    展开全文
  • 原文地址:https://www.zhihu.com/question/54626462管理工具:1.需求管理工具confluence 是一个基于...2.基于敏捷管理的sprint、backlog、开发task、bug管理工具jira 是一个基于java的issue(问题、事项)管理器,...

    原文地址:https://www.zhihu.com/question/54626462

    管理工具:

    1.需求管理工具

    confluence 是一个基于java企业知识平台,基本上是一个企业博客,他有一些工作流管理功能,也支持很多插件(如UML、思维等等),容易定制。

    2.基于敏捷管理的sprint、backlog、开发task、bug管理工具

    jira 是一个基于java的issue(问题、事项)管理器,类似的产品有禅道,github也有简单的issue管理,支持很多插件,而且可定制。

     3.代码管理

    gitlab 是一个类似于github的东西,它是采用ruby开发的,支持自己的一套智能提交,并且非常开放,易于集成。

    4.部署打包

    jenkins 是一个java实现的持续集成工具,图标是一个绅士小老头很搞笑,在我这边一般它会工作在触发后执行打包脚本,进行自动化的集成部署,完成后会发送邮件提示,通知结果。后期我这边将它和nexus进行了整合,改变了一些使用方法,但是大致还是这样子。虽然这个是java写的,但是完全可以用作其他语言的持续部署,它很神奇,很省心,也很易用。


    费用?

    jira & confluence & 插件

    也应该看到了,我这边用的是正版,不推荐D版,请支持正版。
    官方有费用的介绍,国内有代理,可以开发票是可以比较方便走账的,价格相对而言还是比较可观。
    最低有10人10美元授权,其实巧妙分组使用此授权可以在更多人数的团队中使用(就是说不是一套JIRA),但记得其实人家授权协议中是不同意这样子做的(其实我也没仔细看)。

    插件
    插件大多支持试用一段时间,大可以装上试用下,感觉好了再付费。
    google可以搜到很多人的评价,在 http://stackoverflow.com 和 Hot Questions - Stack Exchange 中也有很多评论可以参考,慢慢搜索就行了。

    对硬件的要求?

    内存:
    在实际使用中发现,jira 和 confluence 很吃内存,分配小内存使用起来效果并不好,我在内部服务器上配置了48G内存,给乱七八糟的服务去使用,使用起来体验还可以。

    处理器:
    对于cpu等吃的并不厉害。

    硬盘:
    对于硬盘 iops 相对于内存次要敏感,我这边是配置了两张 ssd 做的 raid1(mdadm做的),使用中感觉还可以。

    网络:
    延时还是要低些吧,你放到美国的vps上300多ms的延时估计用起来是不会开心的。

    在实践中需要应用的其他工具或产品?

    linux服务器 应该不是必须的?据说可以用windows?我没考证过,所以写在这里吧。

    tomcat 这是apache下的开源项目,是一个 JSP/Servlet 容器(就是跑java网站用的服务端),另外还有jboss等,但是我们用不到ejb,所以tomcat是个好选择。

    nginx web服务端,也可以作为反向代理(实际上用作反向代理比较多)

    postgresql 一款学院派风格的关系型数据库(虽然也支持nosql),性能很不错,使用起来坑也比较少,对于一些特性他比mysql兼容的好,我这边大量在使用。这个不是必须的,用mysql,sqlserver(这个我没试过)是可以替代的。虽然他支持nosql数据库,但还是不要用的比较好。

    双向证书验证 一般的https是单向的,即服务端装证书,客户端验证,而双向证书顾名思义就是双向的,客户端也要有,服务端会验证客户端的证书,没证书,访问不了。
    我这边吧服务都放在了公网,虽说代码本身是不怕同僚离职时带走,但是考虑到其他方面这显然不太安全,所以采用了双向认证的方案。
    在实施中吧个人证书与自建CA的根证书分发给同僚,进行安装后即可访问,但是没有证书访问页面就会404,制造出没有这个页面的假象。

    自建CA 因为采用了公网部署双向证书验证的方案,口袋里又没有钱都去用正规CA的证书,所以这个基本不可少。

    可选技术?

    docker 这个当下非常火,不必多说了。在实际使用中我尝试过吧这几个项目部署到docker里,但是就体验来说效果不好。在实际使用中主要是吧 docker 来结合 spring cloud 来使用。

    nexus 一个开放的自建maven,可以代理中央服务器,也可以上传内部的包让团队成员共享与使用,做java方面的开发这个可谓是不可不用。

    ss-local 这个我不展开了,毕竟你懂的。这是一个神奇的梯子工具的客户端,我在内部服务器(即跑这些应用的服务器,而不是内网中的服务器)中进行了部署,连接到东京的linode,来给nexus加速。在安装这一堆乱七八糟的过程中使用此神器可以大大加速下载速度,如果你在国外应该用不到这个。

    privoxy 一个代理服务器,ss-local提供的是一个socks5代理,但是毕竟用socks5很多地方不方便,比如终端下并不能简单的使用,而很多应用也只支持使用http代理,所以就用它来进行socks 到 http 的转换。

    jira git 插件 一个可以和git库进行集成的插件,对双向证书支持不好,只能在nginx给此插件开小灶不走双向认证。

    jira gantt-charts 插件 一个jira展示甘特图的插件,体验很不错,排版容易混乱,但并不影响使用。

    confluence draw.io 插件 画图用的,基本上常见的图都支持,但是体验一般,可以安装其他插件进行优势互补。

    jira 和 confluence 中文汉化包 顾名思义,对于像是我这种只有小学英语水平的人尤为重要。

    zsh 一个神奇的shell,用他来增加终端使用git的体验

    oh-my-zsh 顾名思义,用zsh几乎必备

    如何使用这一堆乱七八糟?

    至于集成与账号创建等我会在配置安装章节进行阐述,在此只提供一个用例。

    感觉码字好麻烦,只写基于默认的情况下一种符合大多数情况的案例吧,供大家参考:

    项目定下来后首先用 jira 建立项目,首推:

    这个使用起来效果是很不错的。另外你也可以很方便的建立自己的类型,让他符合自己的需求,但在此不展开了。

    然后进行必要的项目配置,这里的甘特图选项请设置好,要不甘特图有些功能会有问题。

    创建版本

    然后跑到 confluence 建立库,推荐选择这个:
    同理也可以建立自己的来用(不复杂,摸索下即可)。
    选好项目关联好,并创建:

    这时候一般会开个会议大家考虑下战略、任务怎么分配以及怎么下手去干,这时候创建一个会议记录。


    对会议内容进行记录。
    在参会内容中对参与人员进行'@'即可: 

    其他按照模板项进行填充,其中行动项请务必填写,这个很实用。

    这样子保存后参会人就会收到提示,如果配置了邮箱提醒还会看到邮件。
    然后扫中展示的行动项,建立jira任务:

    此时会看到已经关联。
    jira中也已经有了
    分配好经办人,新建一个sprint并且把任务拖进去将经办人分配好,在此例中分配给我了我自己。如果要拆分子任务也请此时进行。

    然后开始sprint,这时在甘特图中已经可以看到了,在active sprints中也可以拖动任务了。

    任务拖动到其他阶段后,confluence就会更新,

    大家都能看到做到哪里以及做的怎么样了。
    在这里因为要求做需求,创建一个产品要求在里面。左侧 产品要求->Create product requirement 把需要的项目都填好。
    问题过滤器中这里就直接获得所有没结束的,实际使用中可以按需要获得,比如获得属于这个需求的,等等。
    我采用的是列表展示20条,这会导致排版不好看,但是实用些,如果感觉不舒服可以换形式,或者减少展现字段。


    剩下的按照模板填写。
    保存后就会看到调用的问题
    一个比较可用的方案是自定义模板,但是在此就不展开了,有需要可以查看官方教程。
    决策日志,和回顾等大同小异我不再赘述。
    开发过程中,一定要使用jira的智能提交,这非常好用。
    在gitlab中创建版本库,并且添加必要的README等等,另外就是配置好 Project services 集成好jira 

    点击 test 试试看是不是配置正确。点击issues 来试试是否能跳到展现页面。
    在gitlab里给这个项目加入一个JIRA的新成员
    去jira git 插件中查看webhooks 

    吧webhooks给设定好(在你的jira中git插件里面查看,就上面那个)
    保存测试成功了才可以。
    回到JIRA去更新下GIT插件的索引

    把项目克隆到本地然后测试一下智能提交,确定ok。
    为了方便演示智能提交加上这个项目还没README,所以就拿加入README来演示,首先在JIRA创建一个任务并且开始做这个任务。
    然后我们来做这个任务(这里你也看到我用了zsh和oh-my-zsh,其实是可以用ga gp 之类的,你也可以用用看)
    这里很显然我配置过key,没有配置请先配置。
    (平时我使用了ssh的~/.ssh/config 配置文件来设定服务器的,此处可以直接使用常见的git形式,不必像这里一样去ssh://,此处仅为演示,实际使用推荐还是采取ssh config配置文件+远程地址无关的形式比较好,因为这样子换域名换端口,同僚可以不必一个一个去修改git的config,而是改一个 ssh config 即可)
    这时如果你在另外一个屏幕上开着JIRA的话应该已经自动移到Done里面了(并不需要刷新)
    甘特什么的也已经更新了,要是关注过问题的人也会收到提醒。
    这种神奇的效果就是刚刚那句 commit 命令,这个就叫做智能提交,gitlab-shell会去调用gitlab,gitlab又去通过刚刚设定的web钩子去拽一下jira,jira去刷新库(以下不再赘述运行过程,不必要的感觉),这个实际使用中体验还是不错的。这里用的这个是改变当前状态的。格式是:
    git commit -m "JIRA的任务KEY #目的状态 解释"
    

    如果你有多个任务可以用空格间隔重复前半部分,不需要提交多次。
    对于智能提交jira官方是有详尽说明的,我放连接,需要的可以去慢慢研究,一般在使用中我是会弄个环境变量或者脚本来方便提交 issue key ,毕竟有的项目会把KEY搞得很长,输入起来并不是很方便,有的同僚是采取IDEA中设定ISSUE的方式,这些都是比较好的办法。
    Atlassian Documentation

    (如果没有设定过本地 git 的 config 请按照gitlab下面的步骤来做一下,不去设定的话会发现提交后不会关联到对应用户,它是按照邮箱进行的索引,所以邮箱是尤为重要的)

    (另外扯一句题外话,我曾经见过一些同行,不知道代码洁癖还是有要求怎么的,git提交错了,push了,消尖了脑袋去改git的提交,莫非跟绩效挂钩?在我看来这是大可不必的,提交错了重新提交一次即可,大可不必在这里钻牛角尖,要不天天改提交,哪天手抖输敲错了就心塞了反而麻烦。至于代码审核也请不要基于提交为单位展开,要不真会逼人去改提交,而且代码审核这种事最好是上下文都要看到才好,不知道上下文的话突然插进来不要谈审核,哪里是那里都不知道。)




    展开全文
  • 敏捷开发实践

    千次阅读 2013-10-11 22:07:56
    包含有很多内容,详细定义可以点击 , 敏捷开发http://en.wikipedia.org/wiki/Agile_software_development  瀑布模型 http://en.wikipedia.org/wiki/Waterfall_model,本文主要是讲在开发团队中实践敏捷开发, ...

    敏捷开发是一套软件开发的方法学,或者方法框架,包含有很多内容,详细定义可以点击 ,

    敏捷开发  

    瀑布模型 



    本文主要是讲在开发团队中实践敏捷开发:

    1 角色

    在瀑布模型中,所有的流程是预先定义的,角色更是根据流程而划分,如下图



    在敏捷中,定义的角色有

    利益相关者(stakeholder) 产品所有者(product owner) 开发团队(developer team(scrum master)) 角色被分为三类:在开发团队中包含了Business Analysis、 Developer 、Tester、 Technical Architect、UserInterfaceDesigner,这些在瀑布中根据流程固定下来的角色,现在完全变成一个Team,鼓励Team之间相互沟通,用产品来驱动整个开发过程,而不是用流程来保证角色,来完成开发。对于利益相关者需要关心产品,可交付可使用的产品。对于产品所有者,他需要去规划这个产品,从开发团队获得反馈。


    2 概念

    sprint 直译是冲刺,作为一个开发过程,一般是2-4周。敏捷是一套通过快速迭代,来完成可交付产品开发的方法,过长会让sprint目标过于复杂,过短则完成不了计划任务。

    story 直译是故事,在开发过程中,对白板(storyboard)的应用,形象直观,把每一个需求,用story来描述清楚,这是一个product ower整理出来的,想要干什么的过程,其不用关心技术,只是描述清楚what即可。

    task 直译是任务,每一个story,都可以分为若干个task,task是对问题的how的描述,是developer team完成开发工作用,将task再分成子task,有助于细化问题。每个开发人员都需要对assign给自己的task,完成时间评估,而不是由项目管理人员评估。


    3 流程

    敏捷开发,不像瀑布强调流程,它有一些keyword,如下

    1 sprint planning meeting

    2 stand  up scrum meeting(daily  meeting)

    3 product review meeting 

    4 refine meeting 



    敏捷开发是价值驱动(value-driven)的,完成可交付的产品是敏捷开发目标,而完成的方法是通过原型快速迭代,去逼近用户想要的产品 。其核心价值有一下五个: 

    承诺(commitment)
    开发(openness)
    专注(focus)
    尊重(respect)
    勇气(courage) 


    PS:图片缩得不清晰了,下载流程图(.vsd)的点击


    Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizingcross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The Agile Manifesto[1]introduced the term in 2001.

    展开全文
  • 关于敏捷开发实践的三本好书

    千次阅读 2012-02-18 23:44:38
    本人做过2个项目的敏捷开发ScrumMaster,经历了其中的酸甜苦辣,有了很多实践经验教训后,发现下面3本书能够帮助实践敏捷的兄弟的功力更上一层楼。很快我会把我的一些敏捷开发实践心得分享给大家。 《敏捷...
  • 前言:在 上一篇 TFS2015敏捷开发实践 中,我们给大家介绍了TFS2015中看板的基本使用和功能,这一篇中我们来看一个具体的场景,如何使用看板来运行一个sprint。Sprint是Scrum对迭代的称谓,也是Scrum中团队协作的一...
  • 敏捷开发实践(3) — 培养敏捷开发团队 Agile = 适应性 + 持续可能性 敏捷开发的真谛是适应变化的情况,让开发持续,并改善其过程。它并不是单纯的用来缩短发布时间,提高工作效率,增强产品品质的手段,而是...
  • 敏捷开发实践(2) — 敏捷软件开发者的习惯 敏捷开发的最小单位就是参与敏捷开发的个人。将这些敏捷开发者聚集起来,就形成了敏捷开发团队。 正如上回介绍的,敏捷开发是一种以人为核心、迭代、循序渐进的开发...
  • 《C#敏捷开发实践》是一本相当不错的良心之作。本书分为两个部分: 第一部分:讲了敏捷开发的一些原则,书中列举了一些很不错的实现例子。本书主要使用的是Scrum的敏捷开发流程 第二部分:通过一个具体开发过程中...
  • 我的敏捷开发实践—— 拥抱变化的产品开发流程【IT168 专稿】随着Agile敏捷开发的流行,越来越多的公司采用敏捷开发用于软件产品和应用的开发。笔者的产品开发团队在两年前开始采用敏捷开发方法,一直实践到现在,并...
  • 敏捷开发实践初体验

    千次阅读 2013-03-18 21:44:47
    得益于从二月末开始独立带项目,决心引入自己修炼了很久的神功“敏捷开发”。好在团队成员配合,领导不反对,执行的还算顺利,转眼间三个迭代已经过去,着这里总结一下。   第一个迭代周期  第一个周期的主要...
  • 敏捷开发实践(5)-有些工具不得不用

    千次阅读 热门讨论 2014-04-15 21:01:01
    敏捷开发,贵在敏捷,如何敏捷?我们需要一系列成熟的工具去帮助我们敏捷。 这篇文档不写技术,就是纯粹地说工具,介绍我们实施scrum过程中,起到关键作用的工具。 1、Jira或物理看板 Jira配合JIRA Agile...
  • [敏捷开发实践] Scrum Master的职责

    千次阅读 2019-08-25 00:06:24
    [敏捷开发实践] Scrum Master的职责 Scrum Master 是仆人式领导者,能够为Scrum团队提供支持,让团队功能完善并高效运作。 作为Scrum框架规则的维护者,帮助项目团队和组织遵守Scrum价值观和实践; 以被动和主动...
  • 读《大规模敏捷开发实践

    千次阅读 2015-06-08 20:38:02
    初识敏捷开发是在2006年,那时愉快的加入了毕业后第二家公司,一家打算在中国开展外包业务的美国公司。其业务形式就是让在美国的总部接当地的IT单子,然后拿到中国来做。 中国分支的名字也很高大上,Global ...
  • C#敏捷开发实践_开场

    千次阅读 2017-01-31 22:07:22
    还有两天就又要开始新一年的工作了,决定用这两天看下如上的这个本书,先开个头,以督促自己尽早读完并总结。
  • 案例:我的敏捷开发实践.doc

    千次阅读 2009-09-15 13:31:00
    项目背景2006年年初,一位客户联系我的公司,希望能够为其企业创建一个企业网站项目。根据客户的简单描述,这个项目本质上就是一个内容管理系统,并集成了论坛、FTP和电子邮件等功能,因此不算复杂。...
  • 敏捷开发实践—任务看板

    千次阅读 2018-12-04 15:05:58
    –如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后,如果估计发生了变化,任务会根据变化在任务墙上做相应的调整。 通常的任务板是下面这个样子: 任务墙被...
  •  随着Agile敏捷开发的流行,越来越多的公司采用敏捷开发用于软件产品和应用的开发。笔者的产品开发团队在两年前开始采用敏捷开发方法,一直实践到现在,并取得不错的成果,包括:产品功能更加符合市场和业务...
  • 敏捷开发实践体会

    千次阅读 2011-04-08 12:41:00
    其实,我所在的开发团队采用敏捷中Scrum方法已经有些日子了,对此也有颇多来自实际实践中的感触,草草几笔在此简单总结一下,就当是个备忘录: 0. 敏捷方法改变是一种工作方式 如果要在你的开发团队中引入敏捷,首先...
  • 随着Agile敏捷开发的流行,越来越多的公司采用敏捷开发用于软件产品和应用的开发。笔者的产品开发团队在两年前开始采用敏捷开发方法,一直实践到现在,并取得不错的成果,包括:产品功能更加符合市场和业务人员的...
1 2 3 4 5 ... 20
收藏数 60,314
精华内容 24,125
关键字:

敏捷开发实践